Our build system currently has some "oddities". The following is a list I compiled from
what I have seen - others may have other pain points or think that points listed are
not issues at all.
- various versions of pom.xml with various ways to express versions,
parents and artifact names (e.g. server side plugins in org.rhq or org.rhq.server,
the old jopr plugins on org.jboss.jopr )
- server side plugins should be moved to /modules/server-side-plugins , next to the
agent plugins, to make them more prominent.
- Message bundles in modules/enterprise/server/jar seem not to be copied to the
dev container if one does mvn -Pdev , but are copied on -Pdev,enterprise
- The enterprise build needs an additional list of things to be copied to a
distribution zip, which is very likely to be out of date when a developer
;adds a new (ss-)plugin or other module below modules/enterprise
- Many artifacts created have maven descriptors in the final archive that is deployed into the server
<archive>
<addMavenDescriptor>false</addMavenDescriptor>
</archive>
- It should be possible to create enterprise builds that can be installed
over a modified rhq-jboss-as, so that users need to download the
AS only once and then apply community builds of RHQ on top of this.
- we should add findbugs to the build process. While this also reports some
false positives, it will also find a lot of issues that are real.
But at least severity 1 and 2 issues are ones we should always look for -
findbugs:check can make the build fail if such bad ones are found.
- hsqldb.jar gets pulled into the portal-war. Even if its is only a few k in size, it does not
belong there
- because we don't use it
- if we'd use it it should go into the server and not the portal war
- Verify other jars in the artifacts build if they are needed or just accidentally pulled in.
- (jsanda) For plugins I have wondered whether it might make sense to create a custom package type. While plugins are just jar files, they do have a specific directory/packing format along with the required plugin descriptor.
- (jsanda) We use the ant plugin in lots of places which leads to lots of copying and pasting. The plugin modules are a good example of this. Those embedded ant scripts are prime candidates for replacement with a maven plugin that could 1) set up the environment for integration tests, 2) package the plugin, and 3) deploy the plugin to the dev-container. In addition to eliminating some duplication in the build, it would also make it easier and faster to set up a new plugin module.
- Fix tests.
- I think I filed two bugs during the release process (I'd have to look
them up) that there's no way can pass. One of them hardcodes plugin
versions to 1.4.0-SNAPSHOT, which don't get built since we're using
3.0.0 as the version now.
- Other tests fail non-deterministically in hudson. I tried to look into
as many as I could last sprint, but hudson in general is still really
unreliable as the state of the build. (from jdob )
- Try to find and remove unused code (like no longer needed JSP / Struts pages and actions
- If we're moving things around I'd like to see the current:
modules/common/jboss-as
modules/plugins/jboss-as
modules/plugins/jboss-as-5
consolidated into:
modules/plugins/jboss/common
modules/plugins/jboss/jboss-as
modules/plugins/jboss/jboss-as-5
In particular, I'd like to see modules/common go away. It's used only for AS plugin code today and I'm not sure there's much use in a general "common" module.
- Also, I'm not positive but I'm fairly sure modules/jopr is no longer serving any purpose. This should be reviewed and removed.
- (ips) Include the container module in the reactor by default (using a 'container' profile that's enabled if java.home sysprop is set (i.e. by default). Developers can then disable this by passing -P'!container'.
- Automate generation of JavaDoc and publishing it for community releases.