Makes sense.
Only comment is that *if* we change package name then we should do a
dual-target release, where one looks and feels like previous releases
(old group id and packages) alongside a new one which looks and feels
Apache. This would allow dependent projects to refactor against a
like-for-like target. I think this should be done as the Brooklyn
community while in incubation to minimise disruption.
If we don't need to change package names then the switch-over is trivial
so my concerns would be withdrawn.
--A
On 02/07/2014 12:52, Aled Sage wrote:
Hi Alex,
Please correct if I misunderstood you, but initial responses are:
* We should not produce a 0.7.0-M2 outside of apache - as the brooklyn
community, we should work towards an official apache release.
However, if an external party (e.g. cloudsoft) chose to produce an
interim release (e.g. 0.7.0-cloudsoft.M2) then that is fine.
* Agree with switching to org.apache.brooklyn maven groupId in master.
* For changing package names, folk like jclouds still use org.jclouds.
None of their classes are in an org.apache package.
I lean towards not renaming the packages for the 0.7 release.
Let's discuss that in a separate e-mail thread with appropriate
subject.
* We should not turn off non-ASF CI servers.
The ASF CI servers just run unit tests. For integration and live
tests, we're relying on the machines kindly contributed by Cloudsoft.
Aled
On 02/07/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] 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.
