brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <>
Subject Re: CI & sonatype builds status -- major refactoring will be needed, suggested plan to minimize disruption
Date Wed, 02 Jul 2014 14:15:40 GMT

Richard, All,

Richard has interpreted my intentions and rephrased them correctly.  :)

I have updated the cloudsoft-hosted build machines to publish unofficial 
snapshots using the current non-Apache  io.brooklyn groupId, to .  This should 
resolve the immediate problems with downstream projects which want 
snapshot dependencies (as the ones on Sonatype had otherwise not been 
updated since the switch to Apache git).

Given that a package rename is not required, I'm also in favour of 
changing group ID's soon -- from io.brooklyn to org.apache.brooklyn.  
The only thing I would wait on is being sure we will be able to publish 
snapshot builds (credentials for the org.apache.brooklyn groupId, and 
any compliance issues that entails) because there are downstream 
projects which use these. When that is done I think we agree the  
io.brooklyn  groupId will be deprecated for Apache-incubating Brooklyn 
and all downstream projects depending on snapshots will have to switch 
their groupId (and an announcement will be made to this list).

BTW you can get the unofficial build reports at:

And for example an up-to-the-minute dist in the 
current-but-not-much-longer-to-live-io.brooklyn-namespace is at:


On 02/07/2014 13:02, Richard Downer wrote:
> Just to be clear here - all we are talking about here is pushing Maven
> artifacts to some kind of repository. This is not implying anything
> else to do with the release process.
> So when you say "Cut an 0.7.0 M2 and GA ASAP via the old channels" -
> we are still making an "official" Apache release with an approved,
> signed, .tar.gz of source code hosted by Apache, and *not* uploading
> that to any Maven repository. Cloudsoft may then choose to upload
> artifacts using their own identity and infrastructure, but that is
> done independently of Apache.
> *Alex, please correct me if I have misinterpreted you.*
> If the only blocker is changing the group IDs then I'd be tempted to
> just do it. Let's get as much of our normal process onto Apache
> infrastructure ASAP.
> The Java package name change can come later - as Aled has just pointed
> out, jclouds have yet to do this (I think it's on their roadmap for
> the 2.0 release).
> Richard.
> On 2 July 2014 12:28, Alex Heneveld <> wrote:
>> Hi Andrew, All-
>> Thanks.  I have created the JIRA [1] to have ASF nexus access.
>> However there are some major changes we will have to make before we can use
>> it:
>> * We must publish to a groupId under org.apache.  (I have suggested
>> org.apache.brooklyn.)
>> * We should move all classes to be under package `org.apache.brooklyn`.
>> (This is not a strict requirement from what I see but I think it is best
>> practice.)
>> Clearly this is going to be disruptive for our users.  That said it is
>> probably better to do this relatively soon, but I think we should have a
>> stable release in the old namespace and coordinates first.  So my suggested
>> plan is:
>> 1) Tweak existing (non-ASF) CI servers to build and publish snapshots to
>> sonatype using the old co-ordinates, temporarily
>> 2) Cut an 0.7.0 M2 and GA ASAP via the old channels
>> 3) Then do the mass refactoring to use org.apache.brooklyn and publish an
>> 0.7.0 into Apache.  The groupId is different so there should be no
>> confusion, but we should refrain from doing any code changes apart from
>> Apache compliance so that the 0.7.0 versions are functionally identical
>> modulo the namespaces.  This will make it easier for people to cut over.
>> 4) Turn off non-ASF CI servers.
>> 5) Do all 0.8.0 dev in org.apache.brooklyn namespace (backporting only
>> essential fixes if needed)
>> WDYT?
>> Best
>> Alex
>> [1]
>> On 01/07/2014 22:03, Andrew Kennedy wrote:
>>> Alex, Hi.
>>> Have a look at this.
>>> -
>>> It gives instructions for publishing to the ASF Nexus repository. It looks
>>> like we need to go through the steps listed at #signing-up to gain access
>>> to the server first. I think I have got the POM configured correctly (i.e.
>>> depending form the ASF parent POM) and so publishing snapshots should be
>>> as
>>> simple as 'mvn deploy' once that is done.
>>> If you could raise the appropriate JIRA that would be very helpful, then I
>>> can set up the Jenkins job to deploy things to the ASF snapshot repo.
>>> -
>>> I believe this is mirrored to Sonatype as well.
>>> Cheers,
>>> Andrew.

View raw message