On the subject of changing the Java package name (which I forgot to mention) - yes this is something that will need to be done and we have discussed this previously. The decisions was that the in-development version of 0.7.0 would *not* have this change, but that it would be done for 0.8.0.
0.7.0 has been brewing for a long time and I don't think there's the appetite to do this right now. It's a major change, it would break our user's code (which would be unfair on those that have been using 0.7.0-M2) and I've no doubt it would take weeks to fully shake out all the bugs from that kind of change. Meanwhile our users are clamouring for a 0.7.0 release as soon as we can :-) Once we've got 0.7.0 released then we'll kick off 0.8.0 development proper and have a discussion about what changes we want to include. Richard. On Tue, 14 Jul 2015 at 09:03 Richard Downer <[email protected]> wrote: > Hadrian, thanks very much for your efforts on this release blocker. > > I'm now back from vacation - I think that Sam is very busy this week so > I'll put the Release Manager hat back on again and get an rc1 done today. > > Along with Svet I'm also in favour of option 1 - we have a release branch > ready and we've already prepped some downstream customers to prepare for > 0.7.0-final, so I'm not keen to change the version. I'm assuming that apart > from the 0.7.0/0.8.0 difference, your changes should backport cleanly to > the release branch. > > Should I be mistaken about the difficulty of this, then I will change my > mind :-) > > Thanks again Hadrian and everyone else who has been looking at this > problem. > > Richard. > > > On Tue, 14 Jul 2015 at 08:58 Svetoslav Neykov < > [email protected]> wrote: > >> I am for 1). As far as I know there's already a release branch with some >> backports. Another option is: >> >> 3. Create a 0.7.0 release off of the current master by changing back the >> version. >> >> Changing the package name should be done sooner rather than later, but >> requires *very* careful planning due to: >> * The need to keep backwards compatibility for existing persistence >> stores. I'd prefer to have >> https://github.com/apache/incubator-brooklyn/pull/738 < >> https://github.com/apache/incubator-brooklyn/pull/738> merged before >> attempting it. >> * Existing 3rd party blueprints better still be usable after the >> change, though this doesn't seem possible. >> >> Svet. >> >> >> > On 14.07.2015 г., at 5:40, Hadrian Zbarcea <[email protected]> wrote: >> > >> > My proposed changes to unblock the release are now complete [1]. They >> are done however on the master, which leaves us with one of the following >> options (if I am not missing something) >> > >> > 1. Backport to a 0.7.0-Mxxx branch >> > 2. Abandon 0.7.0-Mxxx and release at 0.8.0 >> > >> > While either work, I somewhat prefer moving on with #2 as the simplest >> solution. >> > >> > Another thought is that migrating packages from brooklyn.* to >> org.apache.brooklyn.* will be necessary at some point. I suspect best would >> be to do it now before a release. >> > >> > Thoughts? >> > Hadrian >> > >> > [1] https://github.com/apache/incubator-brooklyn/pull/737 >> > >> > >> > On 06/27/2015 09:09 PM, Hadrian Zbarcea wrote: >> >> This is not an easy one and imho would require some community choice >> >> before implementing a solution. >> >> >> >> 1. To be able to release downstream-parent, it would have to have the >> >> proper configuration, specifically for the release and gpg maven >> >> plugins, that comes actually from the org.apache:apache:17 parent. >> >> 2. Consequently, the downstream parent should have either >> >> org.apache:apache:17 or even better org.apache.brooklyn:brooklyn-parent >> >> as a parent. >> >> 3. The downstream-parent is only used in the quickstart archetype. >> >> >> >> There is questionable value in having a downstream-parent that users >> >> would have to change anyway if it caries the apache scp and release >> >> configurations that wouldn't apply for a user's project. >> >> >> >> The only 2 solutions I can think of are to: >> >> a. Get rid of the downstream parent and move all the necessary >> >> incantations in the quickstart archetype. >> >> b. Transform the downstream-parent (and maybe come up with a better >> name >> >> for it) into a <scope>import</scope> pom [1]. >> >> >> >> I think this is a blocker for the release. >> >> >> >> Thoughts? >> >> Hadrian >> >> >> >> [1] >> >> >> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies >> >> >> >> >> >> On 06/27/2015 04:05 AM, Andrea Turli wrote: >> >>> Thanks Hadrian, >> >>> >> >>> I've also found this one while googling for another project [1], so >> >>> either >> >>> Apache parent or nothing should fix the issue. >> >>> >> >>> HTH, >> >>> Andrea >> >>> >> >>> [1]: >> >>> >> http://central.sonatype.org/pages/apache-maven.html#deprecated-oss-parent >> >>> >> >>> On Sat, 27 Jun 2015 at 05:58 Hadrian Zbarcea <[email protected]> >> wrote: >> >>> >> >>>> First thing, the <parent> for the brooklyn-downstream-parent should >> >>>> not be: >> >>>> <parent> >> >>>> <groupId>org.sonatype.oss</groupId> >> >>>> <artifactId>oss-parent</artifactId> >> >>>> <version>9</version> >> >>>> </parent> >> >>>> >> >>>> but the apache parent ultimately. I think this should completely >> resolve >> >>>> the problem. It's a bit late here to test, I'll do it tomorrow. >> >>>> >> >>>> Cheers, >> >>>> Hadrian >> >>>> >> >>>> >> >>>> On 06/26/2015 11:35 PM, Hadrian Zbarcea wrote: >> >>>>> I did try a dryRun myself and did encounter a problem with the >> >>>>> brooklyn-downstream-parent, but of a different nature >> >>>>> "'parent.relativePath' points at wrong local POM", but I suspect >> there >> >>>>> more issues there. From my experience releasing other projects, I >> >>>>> try to >> >>>>> first remove relevant branches from my local maven repo before >> >>>>> preparing >> >>>>> a release. >> >>>>> >> >>>>> I will look at it during the weekend. Somebody should revert the >> >>>>> version >> >>>>> back from 0.8.0-SNAPSHOT though. >> >>>>> >> >>>>> Cheers, >> >>>>> Hadrian >> >>>>> >> >>>>> On 06/26/2015 04:53 PM, Richard Downer wrote: >> >>>>>> So we got all the source code lined up today, and the release >> branch >> >>>>>> made. >> >>>>>> Everything was going very promisingly until I tried to close the >> Nexus >> >>>>>> repository to publish the artifacts and got a rule violation error. >> >>>>>> >> >>>>>> I'll have a look at fixing the problem and re-starting the release >> on >> >>>>>> Monday (unfortunately I won't have any availability to look at this >> >>>>>> over >> >>>>>> the weekend). >> >>>>>> >> >>>>>> In the meantime if anyone is looking for something to do over the >> >>>>>> weekend, >> >>>>>> the exact failure Nexus reported was: >> >>>>>> >> >>>>>> Missing Signature: >> >>>>>> >> >>>> >> '/org/apache/brooklyn/brooklyn-downstream-parent/0.7.0-incubating/brooklyn-downstream-parent-0.7.0-incubating.pom.asc' >> >>>> >> >>>>>> >> >>>>>> does not exist for >> 'brooklyn-downstream-parent-0.7.0-incubating.pom'. >> >>>>>> >> >>>>>> Everything else has a .pom.asc except downstream-parent so it seems >> >>>>>> there's >> >>>>>> something special about this project. >> >>>>>> >> >>>>>> Richard. >> >>>>>> >> >>>> >> >>> >> >> >> -- >> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. >> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP >> >> This e-mail message is confidential and for use by the addressee only. If >> the message is received by anyone other than the addressee, please return >> the message to the sender by replying to it and then delete the message >> from your computer. Internet e-mails are not necessarily secure. Cloudsoft >> Corporation Limited does not accept responsibility for changes made to >> this >> message after it was sent. >> >> Whilst all reasonable care has been taken to avoid the transmission of >> viruses, it is the responsibility of the recipient to ensure that the >> onward transmission, opening or use of this message and any attachments >> will not adversely affect its systems or data. No responsibility is >> accepted by Cloudsoft Corporation Limited in this regard and the recipient >> should carry out such virus and other checks as it considers appropriate. >> >
