Rafał,

Thanks for the update. We are glad you find Bamboo's Maven 2 support useful.

Cheers,
Anton

Here's link to my project's Bamboo installation, if anyone wants to see it in action: http://objectledge.org/bamboo/

I have installed Bamboo 2.6.2 and set up CI for my open source project consisting of about 30 modules with several layers/clusters of dependencies. I had a very good overall experience. The dependencies were extracted automatically, and build queue behavior with respect to dependency hierarchy was correct as far as I can tell at this point.
The only problem I had was that parent projects and maven2 plugins provided by my project were not recognized as dependencies, but I was able to work around this. See BAM-6906.
In my opinion maven2 support in Bamboo is now at least on par with Hudson.

feedback? been on Hudson for months now. It's fantastic!

2010/1/21 Mark Chaimungkalanont [Atlassian] (JIRA) <jira@atlassian.com>

Folks,

2.5 is now available and has this feature in it.

Please try it out and give us feedback, good, bad and ugly so we can continually improve it.

Cheers,

Mark C

It has been awfully quit here for the last few months. Could Atlassian give an update, planning-wise?

Yes I had considered using the embedder, I'd used the Xpp3Reader to allow parsing as a simplification step as I needed something working fast.
I was originally storing the artifact coordinates separately with a view for exposing them in the project summary and/or allowing searching by each element, but never had the time.

Richard,

thanks for your input! It's great to hear that it's possible to handle at least some of the requirements with a plugin. This can serve both as a stop-gap measure until Atlassian decides to take care of this properly and serve as a development / testing branch for the core functionality that will be needed in the complete solution.

Two remarks: "GAV" is called "artifact coordinates" in Maven-speak, and it can actually include more elements that GroupId, ArtifactId, Version. See my comment #131581 (http://tinyurl.com/cuyzbc) above. Also, I think you don't need to store separate custom property for each dimension of the coordinates. Single structured string would do just fine.

Second, have you considered using embedded Maven to process your POMs? On one hand it can be an overkill, on the other, you can shield yourself from a lot of complexity. You cannot go wrong using the real thing to do your parsing.

I have implemented a plug-in for our internal system that achieves most of the requirements. I need to seek approval from my management before contributing the code, but I can outline the process at this stage.

This is split into two processors, the SnapshotDependencyProcessor (implements CustomBuildProcessor) runs on the remote agent (i.e. the box that actually executed the build), and the SnapshotDependencyPostProcessor (implements CustomBuildProcessorServer) runs on the build manager (the central manager that apportions builds to the agents).
The process is split because the build agent doesn't have access to persist any data between builds, it can just send back a Map of metadata, whereas the manager doesn't have access to the POM (which was checked out from the SCM on the build manager)

1) The SnapshotDependencyProcessor that runs on the remote agent first uses the MavenXpp3Reader to read the POM, then extracts the groupId, artifactId, and version for the parent and all dependencies (at present the process doesn't handle dependencies defined within a profile, but that would be a case of beefing up the Maven POM parsing as mentioned above). I assume that if there are any snapshots in the parent, the parent will also be a snapshot, so the build can rely on the parent's build being triggered (transitive builds if you will).
The SnapshotDependencyProcessor persists data in the build plan to identify the current project's groupId, artifactId and version (the identifiers for a project in Maven, called GAV from now on). It also processes the project's dependencies and parent and persists the GAVs for any SNAPSHOTs found.

2) The SnapshotDependencyPostProcessor compares the GAVs of all snapshots for the latest build with the GAVs for the previous build and if there are any differences (additions/deletions), locates the corresponding build plans (if any) and registers/unregisters dependencies with the corresponding plan as required.

Identifying a corresponding build is managed by checking the GAV values persisted in the custom properties by the SnapshotDependencyProcessor

for (Iterator iter = allBuilds.iterator(); iter.hasNext() {
Build projectBuild = (Build) iter.next();
Map customConfig =
projectBuild.getBuildDefinition().getCustomConfiguration();

if (groupId.equals(customConfig.get("custom.maven.groupId"))
&& artifactId.equals(
customConfig.get("custom.maven.artifactId"))
&& version.equals(customConfig.get("custom.maven.version")))

}
Registering the child build is handled by
dependentBuild.getChildBuilds().add(build);
getBuildManager().saveBuild(dependentBuild);

While the removal is handled by:
dependentBuild.getChildBuilds().remove(build);
getBuildManager().saveBuild(dependentBuild);

The custom properties are all copied from the CurrentBuildResult's custom data into the build definition's custom configuration to be used as the basis for the comparison for the next build (and to identify the plan as a dependency).

This approach means that, once each project has been built once, custom properties have been persisted so it can be identified as a dependency. Then subsequent builds will establish the full dependency tree over the next few builds.

Thanks for your comments Edwin. It certainly helps to reduce frustration levels to have considered comment on the issues.

Of course I appreciate that Atlassian has its own priorities which I am not privvy to, but I do still find some of the past prioritisations rather odd - adding bells and whistles rather than addressing core functionality.

For example:

• jira integration is nice (BAM-2974, BAM-2973, BAM-2971) , but surely the abiltiy to bulk edit plans (BAM-1182) is something that is worth more to a build tool
• and while "Elastic Bamboo" (BAM-3335) certainly sounds nifty, I can't imagine it would be of any use to your corporate customers, whom I assume, are paying your bills. maven integration, however, seems to me fundamental.

cheers,
Craig