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