RFC: Generate the .classpath file eclipse

Bryan Kearney bkearney at redhat.com
Tue Jan 19 03:12:39 UTC 2010


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.

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.

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