Quantcast

.classpath files within drools trunk

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

.classpath files within drools trunk

Randy Secrist
There are a number of references to M2_REPO in eclipse .classpath files which are appear to no longer be used by the MVN build (for at least the test case + install phase).  I'm assuming it is because the CI loop is fine but the eclipse stuff has not been maintained.

Would any committers here be interested if I patched out the artifacts within the .classpath files which I don't think we need anymore and sent up the diff?

or - 

should we remove the .classpath and .project?

or - 

should we enable the sonatype maven plugin within the .project files?

Some examples are:
drools-decisiontables/.classpath has
 - antlr
 - cglib
 - stringtemplate
 - hamcrest-core
 - hamcrest-library
 - jmock-legacy
 - jmock
 - objenesis

Let me know what you guys think ...

-- Randy Secrist
GE Healthcare

_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: .classpath files within drools trunk

Michael Neale
I think the past approach was not to have them - and instead let mvn eclipse generate them - but somehow they got checked in along the way. At least it used to be that way.

On Sat, May 8, 2010 at 1:25 PM, Randy Secrist <[hidden email]> wrote:
There are a number of references to M2_REPO in eclipse .classpath files which are appear to no longer be used by the MVN build (for at least the test case + install phase).  I'm assuming it is because the CI loop is fine but the eclipse stuff has not been maintained.

Would any committers here be interested if I patched out the artifacts within the .classpath files which I don't think we need anymore and sent up the diff?

or - 

should we remove the .classpath and .project?

or - 

should we enable the sonatype maven plugin within the .project files?

Some examples are:
drools-decisiontables/.classpath has
 - antlr
 - cglib
 - stringtemplate
 - hamcrest-core
 - hamcrest-library
 - jmock-legacy
 - jmock
 - objenesis

Let me know what you guys think ...

-- Randy Secrist
GE Healthcare

_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev




--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com

_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: .classpath files within drools trunk

Mark Proctor
On 08/05/2010 05:13, Michael Neale wrote:
I think the past approach was not to have them - and instead let mvn eclipse generate them - but somehow they got checked in along the way. At least it used to be that way.
Maven use to not be able to build the eclipse files in the entire trunk would not build. So from time to time we generate and commit the .project and .classpath to keep them up to date.

Mark

On Sat, May 8, 2010 at 1:25 PM, Randy Secrist <[hidden email]> wrote:
There are a number of references to M2_REPO in eclipse .classpath files which are appear to no longer be used by the MVN build (for at least the test case + install phase).  I'm assuming it is because the CI loop is fine but the eclipse stuff has not been maintained.

Would any committers here be interested if I patched out the artifacts within the .classpath files which I don't think we need anymore and sent up the diff?

or - 

should we remove the .classpath and .project?

or - 

should we enable the sonatype maven plugin within the .project files?

Some examples are:
drools-decisiontables/.classpath has
 - antlr
 - cglib
 - stringtemplate
 - hamcrest-core
 - hamcrest-library
 - jmock-legacy
 - jmock
 - objenesis

Let me know what you guys think ...

-- Randy Secrist
GE Healthcare

_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev




--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
_______________________________________________ rules-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/rules-dev


_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: .classpath files within drools trunk

Jervis Liu
Mark Proctor wrote:
> On 08/05/2010 05:13, Michael Neale wrote:
>> I think the past approach was not to have them - and instead let mvn
>> eclipse generate them - but somehow they got checked in along the
>> way. At least it used to be that way.
> Maven use to not be able to build the eclipse files in the entire
> trunk would not build. So from time to time we generate and commit the
> .project and .classpath to keep them up to date.
>
Personally I prefer not to have these .project and .classpath files
checked in. They are annoying. For example, I always use "mvn
eclipse:clean eclipse:eclipse" to generate eclipse project. When I do a
svn commit, these .project and .classpath files always show up as
modified, I have to manually exclude these files from commit list.

Mark, the Maven eclipse project generation problem you mentioned, does
it still exist or has it been fixed in the newer version of maven?

Jervis

> Mark
>>
>> On Sat, May 8, 2010 at 1:25 PM, Randy Secrist
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     There are a number of references to M2_REPO in eclipse .classpath
>>     files which are appear to no longer be used by the MVN build (for
>>     at least the test case + install phase).  I'm assuming it is
>>     because the CI loop is fine but the eclipse stuff has not been
>>     maintained.
>>
>>     Would any committers here be interested if I patched out the
>>     artifacts within the .classpath files which I don't think we need
>>     anymore and sent up the diff?
>>
>>     or -
>>
>>     should we remove the .classpath and .project?
>>
>>     or -
>>
>>     should we enable the sonatype maven plugin within the .project files?
>>
>>     Some examples are:
>>     drools-decisiontables/.classpath has
>>      - antlr
>>      - cglib
>>      - stringtemplate
>>      - hamcrest-core
>>      - hamcrest-library
>>      - jmock-legacy
>>      - jmock
>>      - objenesis
>>
>>     Let me know what you guys think ...
>>
>>     -- Randy Secrist
>>     GE Healthcare
>>
>>     _______________________________________________
>>     rules-dev mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>>
>> --
>> Michael D Neale
>> home: www.michaelneale.net <http://www.michaelneale.net>
>> blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-dev
>  

_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: .classpath files within drools trunk

Mark Proctor
On 08/05/2010 15:40, Jervisliu wrote:

> Mark Proctor wrote:
>    
>> On 08/05/2010 05:13, Michael Neale wrote:
>>      
>>> I think the past approach was not to have them - and instead let mvn
>>> eclipse generate them - but somehow they got checked in along the
>>> way. At least it used to be that way.
>>>        
>> Maven use to not be able to build the eclipse files in the entire
>> trunk would not build. So from time to time we generate and commit the
>> .project and .classpath to keep them up to date.
>>
>>      
> Personally I prefer not to have these .project and .classpath files
> checked in. They are annoying. For example, I always use "mvn
> eclipse:clean eclipse:eclipse" to generate eclipse project. When I do a
> svn commit, these .project and .classpath files always show up as
> modified, I have to manually exclude these files from commit list.
>
> Mark, the Maven eclipse project generation problem you mentioned, does
> it still exist or has it been fixed in the newer version of maven?
>    
I think it's ok now, we can probably delete the files.

Mark

> Jervis
>    
>> Mark
>>      
>>> On Sat, May 8, 2010 at 1:25 PM, Randy Secrist
>>> <[hidden email]<mailto:[hidden email]>>  wrote:
>>>
>>>      There are a number of references to M2_REPO in eclipse .classpath
>>>      files which are appear to no longer be used by the MVN build (for
>>>      at least the test case + install phase).  I'm assuming it is
>>>      because the CI loop is fine but the eclipse stuff has not been
>>>      maintained.
>>>
>>>      Would any committers here be interested if I patched out the
>>>      artifacts within the .classpath files which I don't think we need
>>>      anymore and sent up the diff?
>>>
>>>      or -
>>>
>>>      should we remove the .classpath and .project?
>>>
>>>      or -
>>>
>>>      should we enable the sonatype maven plugin within the .project files?
>>>
>>>      Some examples are:
>>>      drools-decisiontables/.classpath has
>>>       - antlr
>>>       - cglib
>>>       - stringtemplate
>>>       - hamcrest-core
>>>       - hamcrest-library
>>>       - jmock-legacy
>>>       - jmock
>>>       - objenesis
>>>
>>>      Let me know what you guys think ...
>>>
>>>      -- Randy Secrist
>>>      GE Healthcare
>>>
>>>      _______________________________________________
>>>      rules-dev mailing list
>>>      [hidden email]<mailto:[hidden email]>
>>>      https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>
>>>
>>> --
>>> Michael D Neale
>>> home: www.michaelneale.net<http://www.michaelneale.net>
>>> blog: michaelneale.blogspot.com<http://michaelneale.blogspot.com>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>        
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rules-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>      
> _______________________________________________
> rules-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>    


_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: .classpath files within drools trunk

Jervis Liu
Mark Proctor wrote:

> On 08/05/2010 15:40, Jervisliu wrote:
>  
>> Mark Proctor wrote:
>>    
>>    
>>> On 08/05/2010 05:13, Michael Neale wrote:
>>>      
>>>      
>>>> I think the past approach was not to have them - and instead let mvn
>>>> eclipse generate them - but somehow they got checked in along the
>>>> way. At least it used to be that way.
>>>>        
>>>>        
>>> Maven use to not be able to build the eclipse files in the entire
>>> trunk would not build. So from time to time we generate and commit the
>>> .project and .classpath to keep them up to date.
>>>
>>>      
>>>      
>> Personally I prefer not to have these .project and .classpath files
>> checked in. They are annoying. For example, I always use "mvn
>> eclipse:clean eclipse:eclipse" to generate eclipse project. When I do a
>> svn commit, these .project and .classpath files always show up as
>> modified, I have to manually exclude these files from commit list.
>>
>> Mark, the Maven eclipse project generation problem you mentioned, does
>> it still exist or has it been fixed in the newer version of maven?
>>    
>>    
> I think it's ok now, we can probably delete the files.
>
>  
OK, if there are no objects in next 24 hours, I will remove these
.project and .classpath files from svn.

Jervis

> Mark
>  
>> Jervis
>>    
>>    
>>> Mark
>>>      
>>>      
>>>> On Sat, May 8, 2010 at 1:25 PM, Randy Secrist
>>>> <[hidden email]<mailto:[hidden email]>>  wrote:
>>>>
>>>>      There are a number of references to M2_REPO in eclipse .classpath
>>>>      files which are appear to no longer be used by the MVN build (for
>>>>      at least the test case + install phase).  I'm assuming it is
>>>>      because the CI loop is fine but the eclipse stuff has not been
>>>>      maintained.
>>>>
>>>>      Would any committers here be interested if I patched out the
>>>>      artifacts within the .classpath files which I don't think we need
>>>>      anymore and sent up the diff?
>>>>
>>>>      or -
>>>>
>>>>      should we remove the .classpath and .project?
>>>>
>>>>      or -
>>>>
>>>>      should we enable the sonatype maven plugin within the .project files?
>>>>
>>>>      Some examples are:
>>>>      drools-decisiontables/.classpath has
>>>>       - antlr
>>>>       - cglib
>>>>       - stringtemplate
>>>>       - hamcrest-core
>>>>       - hamcrest-library
>>>>       - jmock-legacy
>>>>       - jmock
>>>>       - objenesis
>>>>
>>>>      Let me know what you guys think ...
>>>>
>>>>      -- Randy Secrist
>>>>      GE Healthcare
>>>>
>>>>      _______________________________________________
>>>>      rules-dev mailing list
>>>>      [hidden email]<mailto:[hidden email]>
>>>>      https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael D Neale
>>>> home: www.michaelneale.net<http://www.michaelneale.net>
>>>> blog: michaelneale.blogspot.com<http://michaelneale.blogspot.com>
>>>>
>>>>
>>>> _______________________________________________
>>>> rules-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>>        
>>>>        
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>      
>>>      
>> _______________________________________________
>> rules-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>    
>>    
>
>
> _______________________________________________
> rules-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-dev
>  

_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: .classpath files within drools trunk

salaboy
go ahead.. I personally hate those files!

On Sun, May 9, 2010 at 10:17 PM, Jervisliu <[hidden email]> wrote:
Mark Proctor wrote:
> On 08/05/2010 15:40, Jervisliu wrote:
>
>> Mark Proctor wrote:
>>
>>
>>> On 08/05/2010 05:13, Michael Neale wrote:
>>>
>>>
>>>> I think the past approach was not to have them - and instead let mvn
>>>> eclipse generate them - but somehow they got checked in along the
>>>> way. At least it used to be that way.
>>>>
>>>>
>>> Maven use to not be able to build the eclipse files in the entire
>>> trunk would not build. So from time to time we generate and commit the
>>> .project and .classpath to keep them up to date.
>>>
>>>
>>>
>> Personally I prefer not to have these .project and .classpath files
>> checked in. They are annoying. For example, I always use "mvn
>> eclipse:clean eclipse:eclipse" to generate eclipse project. When I do a
>> svn commit, these .project and .classpath files always show up as
>> modified, I have to manually exclude these files from commit list.
>>
>> Mark, the Maven eclipse project generation problem you mentioned, does
>> it still exist or has it been fixed in the newer version of maven?
>>
>>
> I think it's ok now, we can probably delete the files.
>
>
OK, if there are no objects in next 24 hours, I will remove these
.project and .classpath files from svn.

Jervis
> Mark
>
>> Jervis
>>
>>
>>> Mark
>>>
>>>
>>>> On Sat, May 8, 2010 at 1:25 PM, Randy Secrist
>>>> <[hidden email]<mailto:[hidden email]>>  wrote:
>>>>
>>>>      There are a number of references to M2_REPO in eclipse .classpath
>>>>      files which are appear to no longer be used by the MVN build (for
>>>>      at least the test case + install phase).  I'm assuming it is
>>>>      because the CI loop is fine but the eclipse stuff has not been
>>>>      maintained.
>>>>
>>>>      Would any committers here be interested if I patched out the
>>>>      artifacts within the .classpath files which I don't think we need
>>>>      anymore and sent up the diff?
>>>>
>>>>      or -
>>>>
>>>>      should we remove the .classpath and .project?
>>>>
>>>>      or -
>>>>
>>>>      should we enable the sonatype maven plugin within the .project files?
>>>>
>>>>      Some examples are:
>>>>      drools-decisiontables/.classpath has
>>>>       - antlr
>>>>       - cglib
>>>>       - stringtemplate
>>>>       - hamcrest-core
>>>>       - hamcrest-library
>>>>       - jmock-legacy
>>>>       - jmock
>>>>       - objenesis
>>>>
>>>>      Let me know what you guys think ...
>>>>
>>>>      -- Randy Secrist
>>>>      GE Healthcare
>>>>
>>>>      _______________________________________________
>>>>      rules-dev mailing list
>>>>      [hidden email]<mailto:[hidden email]>
>>>>      https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael D Neale
>>>> home: www.michaelneale.net<http://www.michaelneale.net>
>>>> blog: michaelneale.blogspot.com<http://michaelneale.blogspot.com>
>>>>
>>>>
>>>> _______________________________________________
>>>> rules-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>>
>>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>
>> _______________________________________________
>> rules-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>>
>
>
> _______________________________________________
> rules-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-dev
>

_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev



--
- http://salaboy.wordpress.com
- http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -

_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: .classpath files within drools trunk

Pablo Nussembaum
In reply to this post by Jervis Liu
+1 to delete those files. Then add them to svn:ignore after deleting
them, please.

On Sunday 09,May,2010 11:17 PM, Jervisliu wrote:

> Mark Proctor wrote:
>  
>> On 08/05/2010 15:40, Jervisliu wrote:
>>  
>>    
>>> Mark Proctor wrote:
>>>    
>>>    
>>>      
>>>> On 08/05/2010 05:13, Michael Neale wrote:
>>>>      
>>>>      
>>>>        
>>>>> I think the past approach was not to have them - and instead let mvn
>>>>> eclipse generate them - but somehow they got checked in along the
>>>>> way. At least it used to be that way.
>>>>>        
>>>>>        
>>>>>          
>>>> Maven use to not be able to build the eclipse files in the entire
>>>> trunk would not build. So from time to time we generate and commit the
>>>> .project and .classpath to keep them up to date.
>>>>
>>>>      
>>>>      
>>>>        
>>> Personally I prefer not to have these .project and .classpath files
>>> checked in. They are annoying. For example, I always use "mvn
>>> eclipse:clean eclipse:eclipse" to generate eclipse project. When I do a
>>> svn commit, these .project and .classpath files always show up as
>>> modified, I have to manually exclude these files from commit list.
>>>
>>> Mark, the Maven eclipse project generation problem you mentioned, does
>>> it still exist or has it been fixed in the newer version of maven?
>>>    
>>>    
>>>      
>> I think it's ok now, we can probably delete the files.
>>
>>  
>>    
> OK, if there are no objects in next 24 hours, I will remove these
> .project and .classpath files from svn.
>
> Jervis
>  
>> Mark
>>  
>>    
>>> Jervis
>>>    
>>>    
>>>      
>>>> Mark
>>>>      
>>>>      
>>>>        
>>>>> On Sat, May 8, 2010 at 1:25 PM, Randy Secrist
>>>>> <[hidden email]<mailto:[hidden email]>>  wrote:
>>>>>
>>>>>      There are a number of references to M2_REPO in eclipse .classpath
>>>>>      files which are appear to no longer be used by the MVN build (for
>>>>>      at least the test case + install phase).  I'm assuming it is
>>>>>      because the CI loop is fine but the eclipse stuff has not been
>>>>>      maintained.
>>>>>
>>>>>      Would any committers here be interested if I patched out the
>>>>>      artifacts within the .classpath files which I don't think we need
>>>>>      anymore and sent up the diff?
>>>>>
>>>>>      or -
>>>>>
>>>>>      should we remove the .classpath and .project?
>>>>>
>>>>>      or -
>>>>>
>>>>>      should we enable the sonatype maven plugin within the .project files?
>>>>>
>>>>>      Some examples are:
>>>>>      drools-decisiontables/.classpath has
>>>>>       - antlr
>>>>>       - cglib
>>>>>       - stringtemplate
>>>>>       - hamcrest-core
>>>>>       - hamcrest-library
>>>>>       - jmock-legacy
>>>>>       - jmock
>>>>>       - objenesis
>>>>>
>>>>>      Let me know what you guys think ...
>>>>>
>>>>>      -- Randy Secrist
>>>>>      GE Healthcare
>>>>>
>>>>>      _______________________________________________
>>>>>      rules-dev mailing list
>>>>>      [hidden email]<mailto:[hidden email]>
>>>>>      https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael D Neale
>>>>> home: www.michaelneale.net<http://www.michaelneale.net>
>>>>> blog: michaelneale.blogspot.com<http://michaelneale.blogspot.com>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rules-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>>
>>>>>        
>>>>>        
>>>>>          
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> rules-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>>      
>>>>      
>>>>        
>>> _______________________________________________
>>> rules-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>    
>>>    
>>>      
>>
>> _______________________________________________
>> rules-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>  
>>    
> _______________________________________________
> rules-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/rules-dev
>  
_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: .classpath files within drools trunk

Randy Secrist
In reply to this post by Randy Secrist
Thanks for taking care of these.  Will make life more simple for us.

-- Randy

On Monday 10,May,2010 12:20:04 -0300, Jervisliu wrote:
> +1 to delete those files. Then add them to svn:ignore after deleting
> them, please.


_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: .classpath files within drools trunk

Mark Proctor
examples are not yet part of the main build and need a slightly different .classpath .project generated, so probably best to leave those committed for now - just noticed they where removed.

Mark
On 13/05/2010 01:40, Randy Secrist wrote:
Thanks for taking care of these.  Will make life more simple for us.

-- Randy

On Monday 10,May,2010 12:20:04 -0300, Jervisliu wrote:
> +1 to delete those files. Then add them to <a class="moz-txt-link-freetext" href="svn:ignore">svn:ignore after deleting
> them, please.

_______________________________________________ rules-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/rules-dev


_______________________________________________
rules-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/rules-dev
Loading...