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
https://oss.sonatype.org/content/repositories/snapshots . 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:
http://brooklyn.builds.cloudsoftcorp.com/
And for example an up-to-the-minute dist in the
current-but-not-much-longer-to-live-io.brooklyn-namespace is at:
https://oss.sonatype.org/content/repositories/snapshots/io/brooklyn/brooklyn-dist/0.7.0-SNAPSHOT/brooklyn-dist-0.7.0-20140702.125949-148-dist.tar.gz
Best
Alex
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 <[email protected]> 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] https://issues.apache.org/jira/browse/INFRA-7996
On 01/07/2014 22:03, Andrew Kennedy wrote:
Alex, Hi.
Have a look at this.
- http://www.apache.org/dev/publishing-maven-artifacts.html
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.
- https://repository.apache.org/content/repositories/snapshots/
I believe this is mirrored to Sonatype as well.
Cheers,
Andrew.
