suggestions/comments/complaints on build system wanted

[mazz]

It seems like a few folks recently have had problems building RHQ/Jopr from source.

While the people who develop RHQ/Jopr on a daily basis have the build system fully understood and can use it with not much of a problem, it seems like it might not be such an easy system to pick up and use on day one for those new to it.

So, first, here are two pages that talk about the build system:

http://support.rhq-project.org/display/RHQ/Building+RHQ
http://support.rhq-project.org/display/RHQ/Advanced+Build+Notes

But the purpose of this post is to be pro-active and solicit the community for comments that you have about the maven build system and module layout used by RHQ and Jopr.

So, if you have recently built (or tried to build) RHQ and Jopr from source:

1) What did you find easy to use?
2) What did you find hard to use?
3) What complaints do you have?
4) What suggestions do you have to make it better?

[nsyed4]

Right of the bat, I remember the following:
1. Easy to Use: Maven
Hard to use, complaints and suggestion:
1. There is a confusion of which file to edit in order to override the usual defaults from the pom.xml. Is it the ~/.m2/settings.xml or the <rhq.home>/etc/m2/settings.xml file. For me, the former one worked. This should be clear in the documentation.

2. Using Oracle 10g instead of PostgreSQL. This wasn't hard to use but the documentation was not sufficient. There are two or three ways of doing this including using the -Dojdbc option or editing the settings.xml file. Also, documentation should include where to deploy the ojdbc14.jar. Sometimes I needed to create a directory structure for it in the ~/m2/repo. that matches to that in settings.xml. And some more information about the comparibility of ojdbc14.jar with Jdk1.5 and Java SE 6 is required.

[mazz]

Thanks! This is exactly the kinds of things I was hoping to get.

For the record:

The /etc/m2/settings.xml is only supposed to be an "example". Changing it has no effect. This is actually a Maven configuration file - Maven wants it in your home directory by default (~/.m2/settings.xml). So the thought process here was you copy /etc/m2/settings.xml into your ~/.m2 directory and modify the ~/.m2 copy. We'll make this more clear in the build docs.

As for Oracle, we'll definitely beef those docs up. Because of the licensing restrictions, we can't ship with the ojdbc driver itself, which makes it harder than it needs to be to do this.

[nsyed4]

I have one more comment; it's about logging.
1. The documentation does not have reference to which logging system is used to generate log messages. Is it Apache Log4j or Java's default logger.
2. How do I change the logging levels. Eg. From INFO to ERROR. Where is the properties file?
3. Is there a way to override the logging implementation since our preference is Apache Log4J.

Thanks.

[mazz]

OK, these are questions regarding plugin development I assume.

1) the agent and all plugins we ship use commons logging with log4j. You will see conf/log4j.xml in the agent. That's the file you touch. Note: if you start with RHQ_AGENT_DEBUG=true in your environment, we switch to using an internal log4j-debug.xml. If you look in the agent .jar file in /lib (the actual enterprise-agent .jar) you'll see a few log4j.xmls built in. These are used for the "debug" prompt command (e.g. you can say "debug -f log4j-warn.xml" if you want to use the built in config that only shows WARNS and ERRORs). At the agent prompt, type "help debug".

2) conf/log4j.xml - which is used by default (unless you overrode it as I mentioned above)

3) We use log4j, so you will be good to go.

[mazz]

One other build "quirk" we need to explicitly document, something Joe and I just found out tonight.

When you do a full build, you MUST do it from the root directory (i.e. trunk/). Do NOT run "mvn install" from trunk/modules because that will not perform a full build - specifically, if we've updated 3rd party dependencies, building out of root is required to rebuild the project metadata that contains the dependency versions.

You can build the individual modules as you are performing development duties (i.e. if you are only touching the core/domain objects, doing a "mvn install" from the trunk/modules/core/domain is OK, as long as you know about the possibility of the 3rd party dep version changes).

But, if you are just wanting to perform a full distribution build from source, you must do so from the root directory.