RFC: Generate the .classpath file eclipse

Joseph Marques jmarques at redhat.com
Tue Jan 19 06:21:27 UTC 2010


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
>



More information about the rhq-devel mailing list