eclipse compile errors

John Mazzitelli mazz at redhat.com
Mon Mar 7 13:26:52 UTC 2011


> Btw. what is the purpose of bundling the project files with the source code
> apart from adding to the stuff the devs need to remember to update?

Because a new community developer can git clone and immediately load the 
project into eclipse without worrying about yet another step they have 
to do to start coding in RHQ. The instructions are already daunting (see 
the Building RHQ wiki page and the Advanced Build wiki page), let's not 
make it even harder on them to get started.

> An eclipse project can be obtained either using m2eclipse by importing the root pom.xml
> or just by doing mvn eclipse:eclipse on the command line.

First, I've never seen those tools work 100% completely - the Eclipse 
maven plugin (though I haven't tried it in a while) always seems broken 
to me. It never worked right - and again, let's not make it harder on 
people to start working in the RHQ code. If we have to ask people to 
install and know how to use an Eclipse plugin (that is potentially 
buggy), it's just asking them to jump thru more hoops.

> One of the main reasons why I went away from the bundled project was the fact
> that having each module in a standalone project (which is what m2eclipse or
> the generated project files do) gives a much clearer idea about the inter-
> module deps (and forces you to honor them/be aware of them) than having
> everything mixed together in one uber-project as we do in the bundled project
> (and be able to use server-side code in a plugin without IDE notifying you).

I never liked the idea of having over 100 separate projects in my 
Eclipse IDE (how many modules do we have now? 112?). So for community 
developers to start coding RHQ, they have to now have 100+ projects in 
their Eclipse project tree??? Which will probably overwhelm their other 
projects in the IDE, unless they setup a separate workspace (which 
means, yet another step for the dev to do to start coding in RHQ - see 
above :)

> Other nice thing you can do is to close all the projects and by opening only
> the one you work on (the deps are opened automatically), you very much
> decrease the in-IDE compile times, validation times, etc.

This requires the RHQ dev to understand the dependencies in order to 
know which ones to close and which ones to open so they can work in a 
piece of code - and until you understand the module hierarchy, you're 
probably gonna be so confused as to just leave everything open.

Now, it is perfectly acceptable for devs who are more advanced in the 
RHQ world to do what you suggest (like you) - sure you can use these 
tools to get Eclipse to do all of that, but let's not REQUIRE new 
community developers to have to do all of that and know all of that just 
to get started.

Maintaining an uber .project/.classpath within the source code is a 
convenience to those that don't want to setup 100+ separate projects in 
Eclipse and a "let's be nice to new community developers" feature.


More information about the rhq-devel mailing list