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.

1. 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 )

2. server side plugins should be moved to /modules/server-side-plugins , next to the
   agent plugins, to make them more prominent.

3. 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

4. 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

5. Many artifacts created have maven descriptors in the final archive that is deployed into the server

   <archive>
      <addMavenDescriptor>false</addMavenDescriptor>
   </archive>

6. 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.

7. 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.

8. 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

9. Verify other jars in the artifacts build if they are needed or just accidentally pulled in.

10. (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.

11. (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.

12. 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 )

13. Try to find and remove unused code (like no longer needed JSP / Struts pages and actions

14. 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.

15. Also, I'm not positive but I'm fairly sure modules/jopr is no longer serving any purpose. This should be reviewed and removed.

16. (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'.

17. Automate generation of JavaDoc and publishing it for community releases.