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