RFC: Generate the .classpath file eclipse

Joseph Marques jmarques at redhat.com
Mon Jan 18 22:21:04 UTC 2010


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
* 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
* 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
* 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?
* requires updating all of our .launch files to point to the correct 
relative root

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.

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
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://fedorahosted.org/pipermail/rhq-devel/attachments/20100118/6265ca97/attachment.html 


More information about the rhq-devel mailing list