[rules-dev] .classpath files within drools trunk

[Jervisliu]

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
>>>> <randy.secrist at gmail.com<mailto:randy.secrist at gmail.com>>  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
>>>>      rules-dev at lists.jboss.org<mailto:rules-dev at lists.jboss.org>
>>>>      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
>>>> rules-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>>        
>>>>         
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>      
>>>       
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>    
>>     
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>