You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Alex Heneveld <al...@cloudsoftcorp.com> on 2014/07/01 21:30:28 UTC
CI & sonatype builds status ?
Hi folks,
What's the status of frequent snapshot builds being pushed to Sonatype?
It looks from [1] that the last update is 19 Jun. It's very handy for
downstream projects to have access to recent dependencies.
I know the CI is work in progress. Can I help add support for uploading
the builds?
Thanks
Alex
[1]
https://oss.sonatype.org/content/repositories/snapshots/io/brooklyn/brooklyn-core/0.7.0-SNAPSHOT/
Re: CI & sonatype builds status -- major refactoring will be needed,
suggested plan to minimize disruption
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
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 <al...@cloudsoftcorp.com> 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.
>>>
Re: CI & sonatype builds status -- major refactoring will be needed,
suggested plan to minimize disruption
Posted by Richard Downer <ri...@apache.org>.
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 <al...@cloudsoftcorp.com> 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.
>>
>
Re: CI & sonatype builds status -- major refactoring will be needed,
suggested plan to minimize disruption
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
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.
>>>
>>
>
>
Re: CI & sonatype builds status -- major refactoring will be needed,
suggested plan to minimize disruption
Posted by Aled Sage <al...@gmail.com>.
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.
>>
>
Re: CI & sonatype builds status -- major refactoring will be needed,
suggested plan to minimize disruption
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
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.
>
Re: CI & sonatype builds status ?
Posted by Andrew Kennedy <an...@cloudsoftcorp.com>.
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.
--
-- andrew kennedy ? engineer : http://cloudsoftcorp.com/developers/ ;
On 1 July 2014 20:30, Alex Heneveld <al...@cloudsoftcorp.com> wrote:
> Hi folks,
>
> What's the status of frequent snapshot builds being pushed to Sonatype?
> It looks from [1] that the last update is 19 Jun. It's very handy for
> downstream projects to have access to recent dependencies.
>
> I know the CI is work in progress. Can I help add support for uploading
> the builds?
>
> Thanks
> Alex
>
>
> [1] https://oss.sonatype.org/content/repositories/snapshots/io/brooklyn/
> brooklyn-core/0.7.0-SNAPSHOT/
>