RFC: Generate the .classpath file eclipse

Jay Shaughnessy jshaughn at redhat.com
Tue Jan 19 21:46:39 UTC 2010


+1 on compromise.

On 1/19/2010 1:21 AM, Joseph Marques wrote:
> On 01/18/2010 10:12 PM, Bryan Kearney wrote:
>    
>> Here is my issue.. if you have to remember to do it in 2 places, folks
>> will forget. For the last few weeks, folks had to manually find
>> plugins which were commented out in order to build.
>>      
> Yes, and I suggested that profiles be used to control which modules get
> included in the reactor, instead of commenting things in and out inside
> the respective parent poms.  There should be a way to check the code out
> and do "mvn -Pall install" and for all modules to be built, thus pulling
> down all necessary dependencies into the m2 repo, and satisfying the
> eclipse classpath.
>    
>> So, I would rather force an extra step which will always work than
>> hope that folks remember to do the extra step.. knowing that only a
>> clean build will catch it.
>>      
> Your solution isn't foolproof either; it still requires (every RHQ
> developer) to perform an extra step, one which I could see some of them
> trying to skip - at initial checkout time, when changing dependencies,
> and then switching braches.  I think both solutions have their cons, but
> the way we're doing it today yields the least overall cost in
> maintaining a sync between maven and eclipse tools.  As a developer, I
> fundamentally disagree with any process that adds more manual steps to a
> build process.
>
> How about a compromise: we continue using the current methodology, but
> come up with a mechanism that detects when the .classpath file deviates
> from the maven dependencies.  This could be written and exposed as a
> unit test which Hudson can run, thus we'll have all the benefits I
> mentioned about a single .classpath file while at the same time
> satisfying your concepts about developers being forgetful (because a
> Hudson build failure will be our self-policing mechanism).
>    
>> More comments below:
>>
>> -- bk
>>
>> On 01/18/2010 05:21 PM, Joseph Marques wrote:
>>      
>>> Users can, if they so choose, mimic your model.  After checking out the
>>> code they can delete the manual files, run mvn eclipse:eclipse on their
>>> own, and modify the .gitignore (at the repository level) properly. Not
>>> counting the one-time modification to the .gitignore, the entire command
>>> would be "rm .project&&  rm .classpath&&  mvn eclipse:eclipse", which
>>> you could easily stick in a script, write as a global function, or alias
>>> for easy execution.
>>>
>>> Here are some off-the-cuff reasons why I don't like it:
>>>
>>> * it adds an additional build step for everyone checking out code who
>>> use eclipse - i'm thinking about newcomers to the project, who general
>>> wants less builds steps...not more
>>>        
>> Yes, but today it is broken. This extra step is better.
>>
>>      
>>> * after a dependency has been changed, it requires re-running the maven
>>> tooling to generate the new eclipse artifacts, then refreshing all of
>>> your projects
>>>        
>> Yup, but I tend to clean/build once a day anyays.
>>
>>
>>      
>>> * if you're switching between git branches that have different
>>> dependencies or modules, you need to re-run the tooling after each
>>> switch, and refresh your projects
>>>        
>> Yes. THe only differnece from today is not havign to re-run the command.
>>
>>      
>>> * it creates dozens of projects, instead of one - i realize this bullet
>>> point will be a matter of personal preference, but do you really feel
>>> that dozens of projects with 1-2 source paths each is that much better
>>> than one project with dozens of source paths?
>>>        
>> I find hte natural order today painful, but then this is personal
>> preference. Plus, today, in the GUI you can introduce dependency
>> violations which the build will reject.
>>
>>      
>>> * requires updating all of our .launch files to point to the correct
>>> relative root
>>>        
>> Yes, this is a negative
>>      
>>> Today, the model is much simpler. If someone modifies a maven
>>> dependency, they should be courteous, take an extra 5 seconds, and
>>> update the .classpath file too. By doing so, all other users that are
>>> following that branch naturally inherit the changes into eclipse when
>>> they git pull. Then, when users switch git branches, they are also
>>> automatically in sync. This style puts the burden on a single person to
>>> keep things in sync - the one who's changing the maven dependency - and
>>> *everybody* else benefits without necessarily even realizing that a
>>> dependency has been changed. Occasionally this will get out of sync, and
>>> whether it takes someone else a day or a month to spot the inconsistency
>>> it's an easy fix that only one person has to do for everyone else to
>>> benefit from.
>>>        
>> When it works, it is simpler. See double work above.
>>
>>      
>>> So, I would object to this patch. In theory it seems nice (keeps
>>> dependencies from maven poms in perfect sync with the .classpath file),
>>> but in practice I think it will create more work for everyone,
>>> especially those that leverage git to bounce between many branches
>>> frequently *cough*.
>>>
>>> On 01/14/2010 03:20 PM, Bryan Kearney wrote:
>>>        
>>>> Here is a patch which will generate the classpath off of the maven
>>>> repo. The main issue this avoids is that if there are plugins which
>>>> are commented out, the .classpath will never be out of sync. The
>>>> process to use this would be:
>>>>
>>>> 1) Check out the code.
>>>> 2) Build it.
>>>> 3) From the root, run mvn eclipse:eclipse
>>>> 4) Go into eclipse, import the directory which you created in (1).
>>>> 4.1) I would create a working set if you have other projects in
>>>> eclipse.
>>>>
>>>> The main differneces/issues:
>>>>
>>>> A) There is now one project per maven pom.
>>>> -- You can see what eclipse looks like before at [1]
>>>> -- You can see what eclipse looks like after at [2].
>>>> B) Empty directories (i.e. the root) are not shown in eclipse
>>>> C) Each directory would need to be added to eGit if you use it.
>>>>
>>>> Comments are welcome.
>>>>
>>>> -- bk
>>>>
>>>> [1] http://bkearney.fedorapeople.org/before.png
>>>> [2] http://bkearney.fedorapeople.org/after.png
>>>>
>>>>
>>>> _______________________________________________
>>>> rhq-devel mailing list
>>>> rhq-devel at lists.fedorahosted.org
>>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>>
>>>>          
>>>
>>>
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel at lists.fedorahosted.org
>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>>        
>>      
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
>
>    


More information about the rhq-devel mailing list