I understand all your points and at least for the sake of not fixing something
that's not broken (much), I am in favor of keeping things as they are, but
still.. ;)
On Monday, March 07, 2011 14:26:52 John Mazzitelli wrote:
> 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.
Ok, so they can open up the project without knowing anything about maven and
our build process, but what is it actually good for? You still need to
understand the module hierarchy and the build relationships (expressed in
maven) to do anything useful. We provide the shortcuts in Eclipse to start
different kinds of builds but again - you have to understand them first to be
able to use them (and be aware of them and know how to import them but that I
think is documented).
I think that by making the module structure invisible to the eclipse users,
we're actually doing them no favors. I do think that exposing the module
structure actually *helps* understanding the code which is quite nicely split
into functional parts.
Yes, if you import the uber-project, you have your source folders (exactly the
same number of them as the number of projects you talk about) but have you
searched for one of the rhq-plugin.xml files? How far away from the actual
code it refers to can it get? ;)
But the main drawback of the uber-project for me is the inability of it to
express the relationships between modules. The IDE will let you use
"ContentManagerBean" in the Apache plugin and you only discover that you
can't
do that during compilation (using maven). The IDE is not aware of the
relationships because the single project just doesn't have them. This
"quality" very much defeats the purpose of an IDE, IMHO.
When a novice user opens the RHQ project with 112 source folders, all he can
tell about RHQ is that it is a huge monolithic project with a huge number of
dependencies when almost the opposite is true.
When the user tries to edit some code, he (and the IDE) isn't aware of the
dependencies between modules (because he's not per-se aware that there even
are some) and the IDE will happily offer to include classes from parts of the
code that are unreachable at the "proper" compile time. That is hugely
confusing, IMHO, because the IDE is supposed to tell you this.
> 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.
I agree with the point of lowering the barrier for entry. But as I said above,
I'm not sure that by providing a *huge* RHQ project we are offering something
to the users that is easy to grasp (or rather as easy as possible).
> 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 :)
Well, you have working sets that you can use to split your projects into
functional parts. m2eclipse even lets you assign the working set during the
import.
But again, what exactly is the difference between having lots of projects (and
thus having another higher level view of the whole picture) and having 1
project with lots and lots of source folders?
> 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.
That is not true. Because the deps are explicit, they are managed by the IDE
and IDE can do stuff for you. If you open an agent plugin, it will
automatically open all the projects in your workspace it is dependent on (and
no others) - the plugin-api, the domain, etc., but certainly not coregui.
Of course, as a novice user, you are probably going to leave everything open,
but having separate projects still helps you comprehend the relationships
because you actually *see* them. Having an uberproject gives you no such
insight.
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.
Agreed. The barrier for entry should be as low as possible but I think we also
need to think about not placing too low.
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.
Again, I generally agree with you with the objection I made several times
above. I am not confident that by hiding the relationships in the project you
are being nice to the novices because you take away the highest level of
abstraction from them.
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel