eclipse compile errors

Andreas Dietrich adi at aspicon.de
Mon Mar 7 14:51:17 UTC 2011


  Hi,

I would consider myself as a novice user although we are using and 
rarely slightly modifying RHQ sources since several months now.

To give you an idea how much insight we have, what the struggles were 
and which ideas discussed here we would like to see I'll start as follows:


Examples of what we modified/investigated:

- added some debugging code regarding the alert processing

- modified the Mobicents plugin regarding SMS content

- debugging some Exceptions occuring with constraints on measurements
-- side note to this: actually the db measurements table keys depend on 
a java.util.Date / Oracle DATE object => thus if you select more than 
one measurement within a millisecond, e.g. via some bulk query of 
measurements of the same schedule for the same resource, you get a key 
violation (e.g. a Logreader reading 3 lines in a ms that are reported as 
measurements)

- fixing some NullPointerExceptions


How we are using Eclipse (for some projects JDeveloper):

- using working sets (we have many projects, some are dependent on each 
other)
- using the Java perspective / Package explorer for projects like RHQ
- using Mercurial for source control
- using ANT for build management
- we are not using Maven in general


Struggles / ease of use we had working with RHQ sources:

1. searching/scrolling through all the RHQ packages is cumbersome => we 
created some working sets for the classes / packages we worked on
2. the first impression is a bit more monolithic than a modular one 
(although of course you can see a lot of modularity on the package/file 
system level)
3. building some modified sources/packages is rather easy with Maven 
(released in the target dir of each module)
    => we released them by simply overwriting the *.jar files in the 
production install, e.g. server gui jar, mobicents plugin jar, server 
core jar
4. writing custom agent and server plugins is rather easy


We think an auto-import of different Eclipse projects with useful 
working sets would be nicer than what is there now.

Kind regards
Andreas :-)


On 03/07/2011 03:17 PM, Lukas Krejci wrote:
> 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 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