brooklyn downstream-parent (was: No 0.7.0-rc1 release today)

[Alex Heneveld <al...@cloudsoftcorp.com>]

Hi Hadrian, All-

For background, for those who don't know -- the aim of the 
downstream-parent project is to minimize what a user needs to put into 
their POM to build a project.

The main things are:

* dependency on brooklyn-all
* building OSGi
* setting up logback correctly
* dependency on brooklyn test utils
* convenient test groups (integration, live, etc)
* specifying versions of libraries brought in (this should probably be 
removed, it's a repetition)

The easiest option is probably to bake this in to the archetype -- 
Hadrian's (a).  That could make downstream project POMs tedious to 
maintain -- but that's a well-known problem with POMs anyway.

I don't see (b) `<scope>import</scope>` working as I don't think we can 
do a lot of the above purely with <dependencyManagement> which is what I 
understand import scope to do (although I'm not that familiar with it).

I think there is a third option which Hadrian hinted att:

     (c) Change downstream to be parented by brooklyn-parent, adding 
what we need to add/customise for the list above.  Then in the 
archetype's sample pom we override those items which aren't relevant 
(e.g. license, apache release items; if someone does want apache 
release, they add them back) and add those things which might be needed 
but can't be put in the downstream-parent pom (e.g. the snapshot repos, 
commented out, so people can enable them easily if they way).

I'm happy with either (a) or (c), with a slight preference for (c).

Best
Alex


On 28/06/2015 02:09, 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 <hz...@gmail.com> 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.

Re: brooklyn downstream-parent

[Hadrian Zbarcea <hz...@gmail.com>]

Still needs a bit more work and cleanup, but here's a variation of my 
proposal that addresses Alex's comment:

1. Kept my ./parent/pom.xml. It's a standard practice in many other 
projects to have a ./parent, but I am not opposed to moving it to 
./usage or other place. For now I want to finish the changes.
5. I left the downstream pom untouched, per Alex's request (just changed 
its parent). This has the advantage of allowing a simpler migration of 
downstream projects.
6. Pending.

I didn't create a PR yet, because there's a bit more work, but you can 
find my changes in my fork [1], the release-08 branch. It's relatively 
stable (not sure what to do about the sandbox yet). Please let me know 
if you would prefer to create a PR and merge it before the upstream 
deviates to much from my fork.

Reviews and comments much appreciated,
Hadrian

[1] https://github.com/hzbarcea/incubator-brooklyn



On 07/06/2015 10:01 AM, Alex Heneveld wrote:
>
> Hi Hadrian,
>
> Thanks.  I get you on (6).  This is independent of the downstream issue
> though isn't it?  In some cases it would be straightforward to introduce
> (e.g. software/) but in other cases (e.g. usage/) it would be hard as
> the logical separation represented by the package structure does not
> lead to a dependency separation.  So I think be pragmatic about how/where.
>
> Maybe we want to have a few pom projects inside  usage/parent/  to
> handle the separation of concerns to clean up the 2k loc pom. There are
> certainly some low-hanging cleanups but a lot of those 2k loc are needed
> I think ... POM XML is verbose.
>
> Best
> Alex
>
>
> On 06/07/2015 14:42, Hadrian Zbarcea wrote:
>> (6) means that there is no pom.xml in ./usage, ./storage, ./utils, etc.
>> Which means that if I want to build that part I'd have to either build
>> projects one by one, or use the appropriate profile in the (currently)
>> parent pom.xml.
>>
>> I usually try to go with smaller, incremental changes because they are
>> both easier to digest for others and it's easier to find regression
>> bugs. For large projects I started to rely a lot on `git bisect`.
>>
>> In this case I would very much like to start with simplifying the
>> poms. I don't think I've seen a 2k loc pom before. CTR doesn't help
>> either.
>>
>> However, after a merge from upstream and an upgrade of my linux box I
>> am now getting the exception below. Dunno yet if it's my box or
>> something else.
>>
>> java.rmi.server.ExportException: Port already in use: 40129; nested
>> exception is:
>>         java.net.BindException: Address already in use
>>
>>
>> Cheers,
>> Hadrian
>>
>>
>>
>> On 07/06/2015 08:23 AM, Alex Heneveld wrote:
>>>
>>> Hadrian-
>>>
>>> I like (d).  My thoughts with (c) was simply that it is easier for us to
>>> do just now and for many use cases it's fine.  That is, for all the
>>> downstream projects I've used it has been a useful starting point.  So
>>> I'm motivated by getting a binary release out ASAP with a structure
>>> where we can clean up the pom parentage as we move to 0.8.0.
>>>
>>> Are there show-stopping issues with (c) ?  What's the MVP to make (d)
>>> work ?
>>>
>>> Re your (d) on--
>>> 1) I'd use /usage/parent instead of /parent
>>> 5) I like having the downstream pom just for readabilty
>>> 6) What do you mean here?
>>>
>>> I agree with 2,3,4,7.
>>>
>>> Best
>>> Alex
>>>
>>>
>>> On 06/07/2015 03:21, Hadrian Zbarcea wrote:
>>>> After spending quite a bit of time on this it looks to me like (c) has
>>>> very little chances to succeed. It would bring a ton of baggage to the
>>>> downstream pom and I have no idea how that would impact downstream
>>>> projects.
>>>>
>>>> The cleanest solution and the one I favour more and more is (d), which
>>>> is:
>>>>
>>>> 1. Move brookyn-parent to a ./parent directory
>>>> 2. Have an org.apache.brooklyn:brooklyn pom in the root directory
>>>> 3. the o.a.b:brooklyn would have o.a:apache:17 as a parent
>>>> 4. brooklyn-parent would have brooklyn as a parent
>>>> 5. downstream would be either removed or have brooklyn as a parent,
>>>> with the necessary change in the archetype
>>>> 6. Introduce pom (sub)projects in subdirectories
>>>> 7. Remove most of the profiles in brooklyn-parent
>>>>
>>>> Dealing with a close to 2k line parent pom was no fun, but more
>>>> importantly I suspect it may hinder adoption a bit as the chances of
>>>> breaking things is significant.
>>>>
>>>> Thoughts?
>>>> Hadrian
>>>>
>>>>
>>>>
>>>> On 06/29/2015 08:28 AM, Alex Heneveld wrote:
>>>>>
>>>>> If you're happy with that then I'm doubly so!
>>>>>
>>>>> --A
>>>>>
>>>>>
>>>>> On 29/06/2015 13:15, Hadrian Zbarcea wrote:
>>>>>> Should we declare consensus then on going with (c) and improve later
>>>>>> as necessary? Sounds like it.
>>>>>>
>>>>>> Hadrian
>>>>>>
>>>>>> On 06/29/2015 07:59 AM, Alex Heneveld wrote:
>>>>>>>
>>>>>>> Hadrian, Aled,
>>>>>>>
>>>>>>> Personally I think (c) is easiest for users, at least I've found
>>>>>>> it so
>>>>>>> when working with downstreams -- it means their POM is pretty
>>>>>>> simple,
>>>>>>> unless they wish otherwise.  Also I think it could be pretty
>>>>>>> quick to
>>>>>>> implement (unless you've tried it Hadrian and hit obstacles I don't
>>>>>>> see?).
>>>>>>>
>>>>>>> Your other suggestion
>>>>>>>
>>>>>>>      (d)  Introduce a clearer separation of POM responsibilities so
>>>>>>> brooklyn-downstream can have a simpler inheritance pattern
>>>>>>>
>>>>>>> is an interesting one, technically it is cleaner and it might
>>>>>>> well be
>>>>>>> nicer for users if the inheritance is clear.  However I'm hopeful
>>>>>>> that
>>>>>>> in most cases they don't need to look at the POM hierarchy ... it
>>>>>>> just
>>>>>>> works.  And if they do for now at least we can use comments to give
>>>>>>> them
>>>>>>> a steer.  Maybe in 0.8.0 it makes sense to do a refactoring along
>>>>>>> the
>>>>>>> lines you suggest.  (There is definitely some stuff in
>>>>>>> brooklyn-parent
>>>>>>> which a downstream project doesn't need, but I don't think any of
>>>>>>> it is
>>>>>>> harmful.)
>>>>>>>
>>>>>>>
>>>>>>> Aled, yeah I wondered about your option, let's call it
>>>>>>>
>>>>>>>      (e)  have a downstream-parent managed outside the Apache
>>>>>>> project
>>>>>>>
>>>>>>> But was unsure about the pain of managing its version and the
>>>>>>> appropriateness of an artifact *in* Apache which references a POM
>>>>>>> outside of it.
>>>>>>>
>>>>>>>
>>>>>>> Also I think it's useful to have this in this release to minimise
>>>>>>> disruption to downstream projects as they upgrade to 0.8.0.
>>>>>>>
>>>>>>> Best
>>>>>>> Alex
>>>>>>>
>>>>>>>
>>>>>>> On 29/06/2015 12:34, Hadrian Zbarcea wrote:
>>>>>>>> Mails crossed paths. I am curious about some feedback on the (d)
>>>>>>>> option.
>>>>>>>>
>>>>>>>> That is imho a better variation of (c) if we care that much about
>>>>>>>> simplifying the life of downstream users. There is also the
>>>>>>>> option of
>>>>>>>> going with (c), or (a) actually for this release and shoot for
>>>>>>>> (d) in
>>>>>>>> the next release.
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>> Hadrian
>>>>>>>>
>>>>>>>> On 06/29/2015 07:20 AM, Alex Heneveld wrote:
>>>>>>>>>
>>>>>>>>> Hadrian,
>>>>>>>>>
>>>>>>>>> Cool that you tried this.  I think any solution will make
>>>>>>>>> using-your-own-parent tedious as merging two POMs is ugly if even
>>>>>>>>> possible -- but it's a use case we should consider. So we should
>>>>>>>>> do (c)
>>>>>>>>> but in the sample POM have a comment to say what the parent brings
>>>>>>>>> (list
>>>>>>>>> in my last mail) to help people who want to replace it with their
>>>>>>>>> own
>>>>>>>>> parent.
>>>>>>>>>
>>>>>>>>> Best
>>>>>>>>> Alex
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 29/06/2015 12:05, Hadrian Zbarcea wrote:
>>>>>>>>>> Hi Alex,
>>>>>>>>>>
>>>>>>>>>> Actually something like (c) is what I tried over the weekend, but
>>>>>>>>>> didn't want to continue without more discussions on the list. (c)
>>>>>>>>>> requires a bit more work than a (a), but has the major
>>>>>>>>>> advantage of
>>>>>>>>>> keeping things consistent. The only major problem I see with
>>>>>>>>>> (c) is
>>>>>>>>>> that I don't think it could be used as a subproject, i.e. the
>>>>>>>>>> user
>>>>>>>>>> changing with a parent of their own. Is this a limitation
>>>>>>>>>> we're ok
>>>>>>>>>> with?
>>>>>>>>>>
>>>>>>>>>> Hadrian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 06/29/2015 05:49 AM, Alex Heneveld wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Hadrian, All-
>>>>>>>>>>>
>>>>>>>>>>> For background, for those who don't know -- the aim of the
>>>>>>>>>>> downstream-parent project is to minimize what a user needs to
>>>>>>>>>>> put
>>>>>>>>>>> into
>>>>>>>>>>> their POM to build a project.
>>>>>>>>>>>
>>>>>>>>>>> The main things are:
>>>>>>>>>>>
>>>>>>>>>>> * dependency on brooklyn-all
>>>>>>>>>>> * building OSGi
>>>>>>>>>>> * setting up logback correctly
>>>>>>>>>>> * dependency on brooklyn test utils
>>>>>>>>>>> * convenient test groups (integration, live, etc)
>>>>>>>>>>> * specifying versions of libraries brought in (this should
>>>>>>>>>>> probably be
>>>>>>>>>>> removed, it's a repetition)
>>>>>>>>>>>
>>>>>>>>>>> The easiest option is probably to bake this in to the
>>>>>>>>>>> archetype --
>>>>>>>>>>> Hadrian's (a).  That could make downstream project POMs
>>>>>>>>>>> tedious to
>>>>>>>>>>> maintain -- but that's a well-known problem with POMs anyway.
>>>>>>>>>>>
>>>>>>>>>>> I don't see (b) `<scope>import</scope>` working as I don't
>>>>>>>>>>> think we
>>>>>>>>>>> can
>>>>>>>>>>> do a lot of the above purely with <dependencyManagement>
>>>>>>>>>>> which is
>>>>>>>>>>> what I
>>>>>>>>>>> understand import scope to do (although I'm not that familiar
>>>>>>>>>>> with
>>>>>>>>>>> it).
>>>>>>>>>>>
>>>>>>>>>>> I think there is a third option which Hadrian hinted att:
>>>>>>>>>>>
>>>>>>>>>>>      (c) Change downstream to be parented by brooklyn-parent,
>>>>>>>>>>> adding
>>>>>>>>>>> what we need to add/customise for the list above. Then in the
>>>>>>>>>>> archetype's sample pom we override those items which aren't
>>>>>>>>>>> relevant
>>>>>>>>>>> (e.g. license, apache release items; if someone does want apache
>>>>>>>>>>> release, they add them back) and add those things which might be
>>>>>>>>>>> needed
>>>>>>>>>>> but can't be put in the downstream-parent pom (e.g. the snapshot
>>>>>>>>>>> repos,
>>>>>>>>>>> commented out, so people can enable them easily if they way).
>>>>>>>>>>>
>>>>>>>>>>> I'm happy with either (a) or (c), with a slight preference for
>>>>>>>>>>> (c).
>>>>>>>>>>>
>>>>>>>>>>> Best
>>>>>>>>>>> Alex
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 28/06/2015 02:09, 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
>>>>>>>>>>>>> <hz...@gmail.com>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

Re: brooklyn downstream-parent

[Alex Heneveld <al...@cloudsoftcorp.com>]

Hi Hadrian,

Thanks.  I get you on (6).  This is independent of the downstream issue 
though isn't it?  In some cases it would be straightforward to introduce 
(e.g. software/) but in other cases (e.g. usage/) it would be hard as 
the logical separation represented by the package structure does not 
lead to a dependency separation.  So I think be pragmatic about how/where.

Maybe we want to have a few pom projects inside  usage/parent/  to 
handle the separation of concerns to clean up the 2k loc pom. There are 
certainly some low-hanging cleanups but a lot of those 2k loc are needed 
I think ... POM XML is verbose.

Best
Alex


On 06/07/2015 14:42, Hadrian Zbarcea wrote:
> (6) means that there is no pom.xml in ./usage, ./storage, ./utils, etc.
> Which means that if I want to build that part I'd have to either build 
> projects one by one, or use the appropriate profile in the (currently) 
> parent pom.xml.
>
> I usually try to go with smaller, incremental changes because they are 
> both easier to digest for others and it's easier to find regression 
> bugs. For large projects I started to rely a lot on `git bisect`.
>
> In this case I would very much like to start with simplifying the 
> poms. I don't think I've seen a 2k loc pom before. CTR doesn't help 
> either.
>
> However, after a merge from upstream and an upgrade of my linux box I 
> am now getting the exception below. Dunno yet if it's my box or 
> something else.
>
> java.rmi.server.ExportException: Port already in use: 40129; nested 
> exception is:
>         java.net.BindException: Address already in use
>
>
> Cheers,
> Hadrian
>
>
>
> On 07/06/2015 08:23 AM, Alex Heneveld wrote:
>>
>> Hadrian-
>>
>> I like (d).  My thoughts with (c) was simply that it is easier for us to
>> do just now and for many use cases it's fine.  That is, for all the
>> downstream projects I've used it has been a useful starting point.  So
>> I'm motivated by getting a binary release out ASAP with a structure
>> where we can clean up the pom parentage as we move to 0.8.0.
>>
>> Are there show-stopping issues with (c) ?  What's the MVP to make (d)
>> work ?
>>
>> Re your (d) on--
>> 1) I'd use /usage/parent instead of /parent
>> 5) I like having the downstream pom just for readabilty
>> 6) What do you mean here?
>>
>> I agree with 2,3,4,7.
>>
>> Best
>> Alex
>>
>>
>> On 06/07/2015 03:21, Hadrian Zbarcea wrote:
>>> After spending quite a bit of time on this it looks to me like (c) has
>>> very little chances to succeed. It would bring a ton of baggage to the
>>> downstream pom and I have no idea how that would impact downstream
>>> projects.
>>>
>>> The cleanest solution and the one I favour more and more is (d), which
>>> is:
>>>
>>> 1. Move brookyn-parent to a ./parent directory
>>> 2. Have an org.apache.brooklyn:brooklyn pom in the root directory
>>> 3. the o.a.b:brooklyn would have o.a:apache:17 as a parent
>>> 4. brooklyn-parent would have brooklyn as a parent
>>> 5. downstream would be either removed or have brooklyn as a parent,
>>> with the necessary change in the archetype
>>> 6. Introduce pom (sub)projects in subdirectories
>>> 7. Remove most of the profiles in brooklyn-parent
>>>
>>> Dealing with a close to 2k line parent pom was no fun, but more
>>> importantly I suspect it may hinder adoption a bit as the chances of
>>> breaking things is significant.
>>>
>>> Thoughts?
>>> Hadrian
>>>
>>>
>>>
>>> On 06/29/2015 08:28 AM, Alex Heneveld wrote:
>>>>
>>>> If you're happy with that then I'm doubly so!
>>>>
>>>> --A
>>>>
>>>>
>>>> On 29/06/2015 13:15, Hadrian Zbarcea wrote:
>>>>> Should we declare consensus then on going with (c) and improve later
>>>>> as necessary? Sounds like it.
>>>>>
>>>>> Hadrian
>>>>>
>>>>> On 06/29/2015 07:59 AM, Alex Heneveld wrote:
>>>>>>
>>>>>> Hadrian, Aled,
>>>>>>
>>>>>> Personally I think (c) is easiest for users, at least I've found 
>>>>>> it so
>>>>>> when working with downstreams -- it means their POM is pretty 
>>>>>> simple,
>>>>>> unless they wish otherwise.  Also I think it could be pretty 
>>>>>> quick to
>>>>>> implement (unless you've tried it Hadrian and hit obstacles I don't
>>>>>> see?).
>>>>>>
>>>>>> Your other suggestion
>>>>>>
>>>>>>      (d)  Introduce a clearer separation of POM responsibilities so
>>>>>> brooklyn-downstream can have a simpler inheritance pattern
>>>>>>
>>>>>> is an interesting one, technically it is cleaner and it might 
>>>>>> well be
>>>>>> nicer for users if the inheritance is clear.  However I'm hopeful 
>>>>>> that
>>>>>> in most cases they don't need to look at the POM hierarchy ... it 
>>>>>> just
>>>>>> works.  And if they do for now at least we can use comments to give
>>>>>> them
>>>>>> a steer.  Maybe in 0.8.0 it makes sense to do a refactoring along 
>>>>>> the
>>>>>> lines you suggest.  (There is definitely some stuff in 
>>>>>> brooklyn-parent
>>>>>> which a downstream project doesn't need, but I don't think any of
>>>>>> it is
>>>>>> harmful.)
>>>>>>
>>>>>>
>>>>>> Aled, yeah I wondered about your option, let's call it
>>>>>>
>>>>>>      (e)  have a downstream-parent managed outside the Apache 
>>>>>> project
>>>>>>
>>>>>> But was unsure about the pain of managing its version and the
>>>>>> appropriateness of an artifact *in* Apache which references a POM
>>>>>> outside of it.
>>>>>>
>>>>>>
>>>>>> Also I think it's useful to have this in this release to minimise
>>>>>> disruption to downstream projects as they upgrade to 0.8.0.
>>>>>>
>>>>>> Best
>>>>>> Alex
>>>>>>
>>>>>>
>>>>>> On 29/06/2015 12:34, Hadrian Zbarcea wrote:
>>>>>>> Mails crossed paths. I am curious about some feedback on the (d)
>>>>>>> option.
>>>>>>>
>>>>>>> That is imho a better variation of (c) if we care that much about
>>>>>>> simplifying the life of downstream users. There is also the 
>>>>>>> option of
>>>>>>> going with (c), or (a) actually for this release and shoot for 
>>>>>>> (d) in
>>>>>>> the next release.
>>>>>>>
>>>>>>> WDYT?
>>>>>>> Hadrian
>>>>>>>
>>>>>>> On 06/29/2015 07:20 AM, Alex Heneveld wrote:
>>>>>>>>
>>>>>>>> Hadrian,
>>>>>>>>
>>>>>>>> Cool that you tried this.  I think any solution will make
>>>>>>>> using-your-own-parent tedious as merging two POMs is ugly if even
>>>>>>>> possible -- but it's a use case we should consider. So we should
>>>>>>>> do (c)
>>>>>>>> but in the sample POM have a comment to say what the parent brings
>>>>>>>> (list
>>>>>>>> in my last mail) to help people who want to replace it with their
>>>>>>>> own
>>>>>>>> parent.
>>>>>>>>
>>>>>>>> Best
>>>>>>>> Alex
>>>>>>>>
>>>>>>>>
>>>>>>>> On 29/06/2015 12:05, Hadrian Zbarcea wrote:
>>>>>>>>> Hi Alex,
>>>>>>>>>
>>>>>>>>> Actually something like (c) is what I tried over the weekend, but
>>>>>>>>> didn't want to continue without more discussions on the list. (c)
>>>>>>>>> requires a bit more work than a (a), but has the major 
>>>>>>>>> advantage of
>>>>>>>>> keeping things consistent. The only major problem I see with 
>>>>>>>>> (c) is
>>>>>>>>> that I don't think it could be used as a subproject, i.e. the 
>>>>>>>>> user
>>>>>>>>> changing with a parent of their own. Is this a limitation 
>>>>>>>>> we're ok
>>>>>>>>> with?
>>>>>>>>>
>>>>>>>>> Hadrian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 06/29/2015 05:49 AM, Alex Heneveld wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Hadrian, All-
>>>>>>>>>>
>>>>>>>>>> For background, for those who don't know -- the aim of the
>>>>>>>>>> downstream-parent project is to minimize what a user needs to 
>>>>>>>>>> put
>>>>>>>>>> into
>>>>>>>>>> their POM to build a project.
>>>>>>>>>>
>>>>>>>>>> The main things are:
>>>>>>>>>>
>>>>>>>>>> * dependency on brooklyn-all
>>>>>>>>>> * building OSGi
>>>>>>>>>> * setting up logback correctly
>>>>>>>>>> * dependency on brooklyn test utils
>>>>>>>>>> * convenient test groups (integration, live, etc)
>>>>>>>>>> * specifying versions of libraries brought in (this should
>>>>>>>>>> probably be
>>>>>>>>>> removed, it's a repetition)
>>>>>>>>>>
>>>>>>>>>> The easiest option is probably to bake this in to the 
>>>>>>>>>> archetype --
>>>>>>>>>> Hadrian's (a).  That could make downstream project POMs 
>>>>>>>>>> tedious to
>>>>>>>>>> maintain -- but that's a well-known problem with POMs anyway.
>>>>>>>>>>
>>>>>>>>>> I don't see (b) `<scope>import</scope>` working as I don't
>>>>>>>>>> think we
>>>>>>>>>> can
>>>>>>>>>> do a lot of the above purely with <dependencyManagement> 
>>>>>>>>>> which is
>>>>>>>>>> what I
>>>>>>>>>> understand import scope to do (although I'm not that familiar 
>>>>>>>>>> with
>>>>>>>>>> it).
>>>>>>>>>>
>>>>>>>>>> I think there is a third option which Hadrian hinted att:
>>>>>>>>>>
>>>>>>>>>>      (c) Change downstream to be parented by brooklyn-parent,
>>>>>>>>>> adding
>>>>>>>>>> what we need to add/customise for the list above. Then in the
>>>>>>>>>> archetype's sample pom we override those items which aren't
>>>>>>>>>> relevant
>>>>>>>>>> (e.g. license, apache release items; if someone does want apache
>>>>>>>>>> release, they add them back) and add those things which might be
>>>>>>>>>> needed
>>>>>>>>>> but can't be put in the downstream-parent pom (e.g. the snapshot
>>>>>>>>>> repos,
>>>>>>>>>> commented out, so people can enable them easily if they way).
>>>>>>>>>>
>>>>>>>>>> I'm happy with either (a) or (c), with a slight preference for
>>>>>>>>>> (c).
>>>>>>>>>>
>>>>>>>>>> Best
>>>>>>>>>> Alex
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 28/06/2015 02:09, 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
>>>>>>>>>>>> <hz...@gmail.com>
>>>>>>>>>>>> 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.

Re: brooklyn downstream-parent

[Hadrian Zbarcea <hz...@gmail.com>]

(6) means that there is no pom.xml in ./usage, ./storage, ./utils, etc.
Which means that if I want to build that part I'd have to either build 
projects one by one, or use the appropriate profile in the (currently) 
parent pom.xml.

I usually try to go with smaller, incremental changes because they are 
both easier to digest for others and it's easier to find regression 
bugs. For large projects I started to rely a lot on `git bisect`.

In this case I would very much like to start with simplifying the poms. 
I don't think I've seen a 2k loc pom before. CTR doesn't help either.

However, after a merge from upstream and an upgrade of my linux box I am 
now getting the exception below. Dunno yet if it's my box or something else.

java.rmi.server.ExportException: Port already in use: 40129; nested 
exception is:
         java.net.BindException: Address already in use


Cheers,
Hadrian



On 07/06/2015 08:23 AM, Alex Heneveld wrote:
>
> Hadrian-
>
> I like (d).  My thoughts with (c) was simply that it is easier for us to
> do just now and for many use cases it's fine.  That is, for all the
> downstream projects I've used it has been a useful starting point.  So
> I'm motivated by getting a binary release out ASAP with a structure
> where we can clean up the pom parentage as we move to 0.8.0.
>
> Are there show-stopping issues with (c) ?  What's the MVP to make (d)
> work ?
>
> Re your (d) on--
> 1) I'd use /usage/parent instead of /parent
> 5) I like having the downstream pom just for readabilty
> 6) What do you mean here?
>
> I agree with 2,3,4,7.
>
> Best
> Alex
>
>
> On 06/07/2015 03:21, Hadrian Zbarcea wrote:
>> After spending quite a bit of time on this it looks to me like (c) has
>> very little chances to succeed. It would bring a ton of baggage to the
>> downstream pom and I have no idea how that would impact downstream
>> projects.
>>
>> The cleanest solution and the one I favour more and more is (d), which
>> is:
>>
>> 1. Move brookyn-parent to a ./parent directory
>> 2. Have an org.apache.brooklyn:brooklyn pom in the root directory
>> 3. the o.a.b:brooklyn would have o.a:apache:17 as a parent
>> 4. brooklyn-parent would have brooklyn as a parent
>> 5. downstream would be either removed or have brooklyn as a parent,
>> with the necessary change in the archetype
>> 6. Introduce pom (sub)projects in subdirectories
>> 7. Remove most of the profiles in brooklyn-parent
>>
>> Dealing with a close to 2k line parent pom was no fun, but more
>> importantly I suspect it may hinder adoption a bit as the chances of
>> breaking things is significant.
>>
>> Thoughts?
>> Hadrian
>>
>>
>>
>> On 06/29/2015 08:28 AM, Alex Heneveld wrote:
>>>
>>> If you're happy with that then I'm doubly so!
>>>
>>> --A
>>>
>>>
>>> On 29/06/2015 13:15, Hadrian Zbarcea wrote:
>>>> Should we declare consensus then on going with (c) and improve later
>>>> as necessary? Sounds like it.
>>>>
>>>> Hadrian
>>>>
>>>> On 06/29/2015 07:59 AM, Alex Heneveld wrote:
>>>>>
>>>>> Hadrian, Aled,
>>>>>
>>>>> Personally I think (c) is easiest for users, at least I've found it so
>>>>> when working with downstreams -- it means their POM is pretty simple,
>>>>> unless they wish otherwise.  Also I think it could be pretty quick to
>>>>> implement (unless you've tried it Hadrian and hit obstacles I don't
>>>>> see?).
>>>>>
>>>>> Your other suggestion
>>>>>
>>>>>      (d)  Introduce a clearer separation of POM responsibilities so
>>>>> brooklyn-downstream can have a simpler inheritance pattern
>>>>>
>>>>> is an interesting one, technically it is cleaner and it might well be
>>>>> nicer for users if the inheritance is clear.  However I'm hopeful that
>>>>> in most cases they don't need to look at the POM hierarchy ... it just
>>>>> works.  And if they do for now at least we can use comments to give
>>>>> them
>>>>> a steer.  Maybe in 0.8.0 it makes sense to do a refactoring along the
>>>>> lines you suggest.  (There is definitely some stuff in brooklyn-parent
>>>>> which a downstream project doesn't need, but I don't think any of
>>>>> it is
>>>>> harmful.)
>>>>>
>>>>>
>>>>> Aled, yeah I wondered about your option, let's call it
>>>>>
>>>>>      (e)  have a downstream-parent managed outside the Apache project
>>>>>
>>>>> But was unsure about the pain of managing its version and the
>>>>> appropriateness of an artifact *in* Apache which references a POM
>>>>> outside of it.
>>>>>
>>>>>
>>>>> Also I think it's useful to have this in this release to minimise
>>>>> disruption to downstream projects as they upgrade to 0.8.0.
>>>>>
>>>>> Best
>>>>> Alex
>>>>>
>>>>>
>>>>> On 29/06/2015 12:34, Hadrian Zbarcea wrote:
>>>>>> Mails crossed paths. I am curious about some feedback on the (d)
>>>>>> option.
>>>>>>
>>>>>> That is imho a better variation of (c) if we care that much about
>>>>>> simplifying the life of downstream users. There is also the option of
>>>>>> going with (c), or (a) actually for this release and shoot for (d) in
>>>>>> the next release.
>>>>>>
>>>>>> WDYT?
>>>>>> Hadrian
>>>>>>
>>>>>> On 06/29/2015 07:20 AM, Alex Heneveld wrote:
>>>>>>>
>>>>>>> Hadrian,
>>>>>>>
>>>>>>> Cool that you tried this.  I think any solution will make
>>>>>>> using-your-own-parent tedious as merging two POMs is ugly if even
>>>>>>> possible -- but it's a use case we should consider.  So we should
>>>>>>> do (c)
>>>>>>> but in the sample POM have a comment to say what the parent brings
>>>>>>> (list
>>>>>>> in my last mail) to help people who want to replace it with their
>>>>>>> own
>>>>>>> parent.
>>>>>>>
>>>>>>> Best
>>>>>>> Alex
>>>>>>>
>>>>>>>
>>>>>>> On 29/06/2015 12:05, Hadrian Zbarcea wrote:
>>>>>>>> Hi Alex,
>>>>>>>>
>>>>>>>> Actually something like (c) is what I tried over the weekend, but
>>>>>>>> didn't want to continue without more discussions on the list. (c)
>>>>>>>> requires a bit more work than a (a), but has the major advantage of
>>>>>>>> keeping things consistent. The only major problem I see with (c) is
>>>>>>>> that I don't think it could be used as a subproject, i.e. the user
>>>>>>>> changing with a parent of their own. Is this a limitation we're ok
>>>>>>>> with?
>>>>>>>>
>>>>>>>> Hadrian
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/29/2015 05:49 AM, Alex Heneveld wrote:
>>>>>>>>>
>>>>>>>>> Hi Hadrian, All-
>>>>>>>>>
>>>>>>>>> For background, for those who don't know -- the aim of the
>>>>>>>>> downstream-parent project is to minimize what a user needs to put
>>>>>>>>> into
>>>>>>>>> their POM to build a project.
>>>>>>>>>
>>>>>>>>> The main things are:
>>>>>>>>>
>>>>>>>>> * dependency on brooklyn-all
>>>>>>>>> * building OSGi
>>>>>>>>> * setting up logback correctly
>>>>>>>>> * dependency on brooklyn test utils
>>>>>>>>> * convenient test groups (integration, live, etc)
>>>>>>>>> * specifying versions of libraries brought in (this should
>>>>>>>>> probably be
>>>>>>>>> removed, it's a repetition)
>>>>>>>>>
>>>>>>>>> The easiest option is probably to bake this in to the archetype --
>>>>>>>>> Hadrian's (a).  That could make downstream project POMs tedious to
>>>>>>>>> maintain -- but that's a well-known problem with POMs anyway.
>>>>>>>>>
>>>>>>>>> I don't see (b) `<scope>import</scope>` working as I don't
>>>>>>>>> think we
>>>>>>>>> can
>>>>>>>>> do a lot of the above purely with <dependencyManagement> which is
>>>>>>>>> what I
>>>>>>>>> understand import scope to do (although I'm not that familiar with
>>>>>>>>> it).
>>>>>>>>>
>>>>>>>>> I think there is a third option which Hadrian hinted att:
>>>>>>>>>
>>>>>>>>>      (c) Change downstream to be parented by brooklyn-parent,
>>>>>>>>> adding
>>>>>>>>> what we need to add/customise for the list above. Then in the
>>>>>>>>> archetype's sample pom we override those items which aren't
>>>>>>>>> relevant
>>>>>>>>> (e.g. license, apache release items; if someone does want apache
>>>>>>>>> release, they add them back) and add those things which might be
>>>>>>>>> needed
>>>>>>>>> but can't be put in the downstream-parent pom (e.g. the snapshot
>>>>>>>>> repos,
>>>>>>>>> commented out, so people can enable them easily if they way).
>>>>>>>>>
>>>>>>>>> I'm happy with either (a) or (c), with a slight preference for
>>>>>>>>> (c).
>>>>>>>>>
>>>>>>>>> Best
>>>>>>>>> Alex
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 28/06/2015 02:09, 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
>>>>>>>>>>> <hz...@gmail.com>
>>>>>>>>>>> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

Re: brooklyn downstream-parent

[Alex Heneveld <al...@cloudsoftcorp.com>]

Hadrian-

I like (d).  My thoughts with (c) was simply that it is easier for us to 
do just now and for many use cases it's fine.  That is, for all the 
downstream projects I've used it has been a useful starting point.  So 
I'm motivated by getting a binary release out ASAP with a structure 
where we can clean up the pom parentage as we move to 0.8.0.

Are there show-stopping issues with (c) ?  What's the MVP to make (d) work ?

Re your (d) on--
1) I'd use /usage/parent instead of /parent
5) I like having the downstream pom just for readabilty
6) What do you mean here?

I agree with 2,3,4,7.

Best
Alex


On 06/07/2015 03:21, Hadrian Zbarcea wrote:
> After spending quite a bit of time on this it looks to me like (c) has 
> very little chances to succeed. It would bring a ton of baggage to the 
> downstream pom and I have no idea how that would impact downstream 
> projects.
>
> The cleanest solution and the one I favour more and more is (d), which 
> is:
>
> 1. Move brookyn-parent to a ./parent directory
> 2. Have an org.apache.brooklyn:brooklyn pom in the root directory
> 3. the o.a.b:brooklyn would have o.a:apache:17 as a parent
> 4. brooklyn-parent would have brooklyn as a parent
> 5. downstream would be either removed or have brooklyn as a parent, 
> with the necessary change in the archetype
> 6. Introduce pom (sub)projects in subdirectories
> 7. Remove most of the profiles in brooklyn-parent
>
> Dealing with a close to 2k line parent pom was no fun, but more 
> importantly I suspect it may hinder adoption a bit as the chances of 
> breaking things is significant.
>
> Thoughts?
> Hadrian
>
>
>
> On 06/29/2015 08:28 AM, Alex Heneveld wrote:
>>
>> If you're happy with that then I'm doubly so!
>>
>> --A
>>
>>
>> On 29/06/2015 13:15, Hadrian Zbarcea wrote:
>>> Should we declare consensus then on going with (c) and improve later
>>> as necessary? Sounds like it.
>>>
>>> Hadrian
>>>
>>> On 06/29/2015 07:59 AM, Alex Heneveld wrote:
>>>>
>>>> Hadrian, Aled,
>>>>
>>>> Personally I think (c) is easiest for users, at least I've found it so
>>>> when working with downstreams -- it means their POM is pretty simple,
>>>> unless they wish otherwise.  Also I think it could be pretty quick to
>>>> implement (unless you've tried it Hadrian and hit obstacles I don't
>>>> see?).
>>>>
>>>> Your other suggestion
>>>>
>>>>      (d)  Introduce a clearer separation of POM responsibilities so
>>>> brooklyn-downstream can have a simpler inheritance pattern
>>>>
>>>> is an interesting one, technically it is cleaner and it might well be
>>>> nicer for users if the inheritance is clear.  However I'm hopeful that
>>>> in most cases they don't need to look at the POM hierarchy ... it just
>>>> works.  And if they do for now at least we can use comments to give 
>>>> them
>>>> a steer.  Maybe in 0.8.0 it makes sense to do a refactoring along the
>>>> lines you suggest.  (There is definitely some stuff in brooklyn-parent
>>>> which a downstream project doesn't need, but I don't think any of 
>>>> it is
>>>> harmful.)
>>>>
>>>>
>>>> Aled, yeah I wondered about your option, let's call it
>>>>
>>>>      (e)  have a downstream-parent managed outside the Apache project
>>>>
>>>> But was unsure about the pain of managing its version and the
>>>> appropriateness of an artifact *in* Apache which references a POM
>>>> outside of it.
>>>>
>>>>
>>>> Also I think it's useful to have this in this release to minimise
>>>> disruption to downstream projects as they upgrade to 0.8.0.
>>>>
>>>> Best
>>>> Alex
>>>>
>>>>
>>>> On 29/06/2015 12:34, Hadrian Zbarcea wrote:
>>>>> Mails crossed paths. I am curious about some feedback on the (d)
>>>>> option.
>>>>>
>>>>> That is imho a better variation of (c) if we care that much about
>>>>> simplifying the life of downstream users. There is also the option of
>>>>> going with (c), or (a) actually for this release and shoot for (d) in
>>>>> the next release.
>>>>>
>>>>> WDYT?
>>>>> Hadrian
>>>>>
>>>>> On 06/29/2015 07:20 AM, Alex Heneveld wrote:
>>>>>>
>>>>>> Hadrian,
>>>>>>
>>>>>> Cool that you tried this.  I think any solution will make
>>>>>> using-your-own-parent tedious as merging two POMs is ugly if even
>>>>>> possible -- but it's a use case we should consider.  So we should
>>>>>> do (c)
>>>>>> but in the sample POM have a comment to say what the parent brings
>>>>>> (list
>>>>>> in my last mail) to help people who want to replace it with their 
>>>>>> own
>>>>>> parent.
>>>>>>
>>>>>> Best
>>>>>> Alex
>>>>>>
>>>>>>
>>>>>> On 29/06/2015 12:05, Hadrian Zbarcea wrote:
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>> Actually something like (c) is what I tried over the weekend, but
>>>>>>> didn't want to continue without more discussions on the list. (c)
>>>>>>> requires a bit more work than a (a), but has the major advantage of
>>>>>>> keeping things consistent. The only major problem I see with (c) is
>>>>>>> that I don't think it could be used as a subproject, i.e. the user
>>>>>>> changing with a parent of their own. Is this a limitation we're ok
>>>>>>> with?
>>>>>>>
>>>>>>> Hadrian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 06/29/2015 05:49 AM, Alex Heneveld wrote:
>>>>>>>>
>>>>>>>> Hi Hadrian, All-
>>>>>>>>
>>>>>>>> For background, for those who don't know -- the aim of the
>>>>>>>> downstream-parent project is to minimize what a user needs to put
>>>>>>>> into
>>>>>>>> their POM to build a project.
>>>>>>>>
>>>>>>>> The main things are:
>>>>>>>>
>>>>>>>> * dependency on brooklyn-all
>>>>>>>> * building OSGi
>>>>>>>> * setting up logback correctly
>>>>>>>> * dependency on brooklyn test utils
>>>>>>>> * convenient test groups (integration, live, etc)
>>>>>>>> * specifying versions of libraries brought in (this should
>>>>>>>> probably be
>>>>>>>> removed, it's a repetition)
>>>>>>>>
>>>>>>>> The easiest option is probably to bake this in to the archetype --
>>>>>>>> Hadrian's (a).  That could make downstream project POMs tedious to
>>>>>>>> maintain -- but that's a well-known problem with POMs anyway.
>>>>>>>>
>>>>>>>> I don't see (b) `<scope>import</scope>` working as I don't 
>>>>>>>> think we
>>>>>>>> can
>>>>>>>> do a lot of the above purely with <dependencyManagement> which is
>>>>>>>> what I
>>>>>>>> understand import scope to do (although I'm not that familiar with
>>>>>>>> it).
>>>>>>>>
>>>>>>>> I think there is a third option which Hadrian hinted att:
>>>>>>>>
>>>>>>>>      (c) Change downstream to be parented by brooklyn-parent, 
>>>>>>>> adding
>>>>>>>> what we need to add/customise for the list above. Then in the
>>>>>>>> archetype's sample pom we override those items which aren't 
>>>>>>>> relevant
>>>>>>>> (e.g. license, apache release items; if someone does want apache
>>>>>>>> release, they add them back) and add those things which might be
>>>>>>>> needed
>>>>>>>> but can't be put in the downstream-parent pom (e.g. the snapshot
>>>>>>>> repos,
>>>>>>>> commented out, so people can enable them easily if they way).
>>>>>>>>
>>>>>>>> I'm happy with either (a) or (c), with a slight preference for 
>>>>>>>> (c).
>>>>>>>>
>>>>>>>> Best
>>>>>>>> Alex
>>>>>>>>
>>>>>>>>
>>>>>>>> On 28/06/2015 02:09, 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 
>>>>>>>>>> <hz...@gmail.com>
>>>>>>>>>> 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.

Re: brooklyn downstream-parent

[Hadrian Zbarcea <hz...@gmail.com>]

After spending quite a bit of time on this it looks to me like (c) has 
very little chances to succeed. It would bring a ton of baggage to the 
downstream pom and I have no idea how that would impact downstream projects.

The cleanest solution and the one I favour more and more is (d), which is:

1. Move brookyn-parent to a ./parent directory
2. Have an org.apache.brooklyn:brooklyn pom in the root directory
3. the o.a.b:brooklyn would have o.a:apache:17 as a parent
4. brooklyn-parent would have brooklyn as a parent
5. downstream would be either removed or have brooklyn as a parent, with 
the necessary change in the archetype
6. Introduce pom (sub)projects in subdirectories
7. Remove most of the profiles in brooklyn-parent

Dealing with a close to 2k line parent pom was no fun, but more 
importantly I suspect it may hinder adoption a bit as the chances of 
breaking things is significant.

Thoughts?
Hadrian



On 06/29/2015 08:28 AM, Alex Heneveld wrote:
>
> If you're happy with that then I'm doubly so!
>
> --A
>
>
> On 29/06/2015 13:15, Hadrian Zbarcea wrote:
>> Should we declare consensus then on going with (c) and improve later
>> as necessary? Sounds like it.
>>
>> Hadrian
>>
>> On 06/29/2015 07:59 AM, Alex Heneveld wrote:
>>>
>>> Hadrian, Aled,
>>>
>>> Personally I think (c) is easiest for users, at least I've found it so
>>> when working with downstreams -- it means their POM is pretty simple,
>>> unless they wish otherwise.  Also I think it could be pretty quick to
>>> implement (unless you've tried it Hadrian and hit obstacles I don't
>>> see?).
>>>
>>> Your other suggestion
>>>
>>>      (d)  Introduce a clearer separation of POM responsibilities so
>>> brooklyn-downstream can have a simpler inheritance pattern
>>>
>>> is an interesting one, technically it is cleaner and it might well be
>>> nicer for users if the inheritance is clear.  However I'm hopeful that
>>> in most cases they don't need to look at the POM hierarchy ... it just
>>> works.  And if they do for now at least we can use comments to give them
>>> a steer.  Maybe in 0.8.0 it makes sense to do a refactoring along the
>>> lines you suggest.  (There is definitely some stuff in brooklyn-parent
>>> which a downstream project doesn't need, but I don't think any of it is
>>> harmful.)
>>>
>>>
>>> Aled, yeah I wondered about your option, let's call it
>>>
>>>      (e)  have a downstream-parent managed outside the Apache project
>>>
>>> But was unsure about the pain of managing its version and the
>>> appropriateness of an artifact *in* Apache which references a POM
>>> outside of it.
>>>
>>>
>>> Also I think it's useful to have this in this release to minimise
>>> disruption to downstream projects as they upgrade to 0.8.0.
>>>
>>> Best
>>> Alex
>>>
>>>
>>> On 29/06/2015 12:34, Hadrian Zbarcea wrote:
>>>> Mails crossed paths. I am curious about some feedback on the (d)
>>>> option.
>>>>
>>>> That is imho a better variation of (c) if we care that much about
>>>> simplifying the life of downstream users. There is also the option of
>>>> going with (c), or (a) actually for this release and shoot for (d) in
>>>> the next release.
>>>>
>>>> WDYT?
>>>> Hadrian
>>>>
>>>> On 06/29/2015 07:20 AM, Alex Heneveld wrote:
>>>>>
>>>>> Hadrian,
>>>>>
>>>>> Cool that you tried this.  I think any solution will make
>>>>> using-your-own-parent tedious as merging two POMs is ugly if even
>>>>> possible -- but it's a use case we should consider.  So we should
>>>>> do (c)
>>>>> but in the sample POM have a comment to say what the parent brings
>>>>> (list
>>>>> in my last mail) to help people who want to replace it with their own
>>>>> parent.
>>>>>
>>>>> Best
>>>>> Alex
>>>>>
>>>>>
>>>>> On 29/06/2015 12:05, Hadrian Zbarcea wrote:
>>>>>> Hi Alex,
>>>>>>
>>>>>> Actually something like (c) is what I tried over the weekend, but
>>>>>> didn't want to continue without more discussions on the list. (c)
>>>>>> requires a bit more work than a (a), but has the major advantage of
>>>>>> keeping things consistent. The only major problem I see with (c) is
>>>>>> that I don't think it could be used as a subproject, i.e. the user
>>>>>> changing with a parent of their own. Is this a limitation we're ok
>>>>>> with?
>>>>>>
>>>>>> Hadrian
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 06/29/2015 05:49 AM, Alex Heneveld wrote:
>>>>>>>
>>>>>>> Hi Hadrian, All-
>>>>>>>
>>>>>>> For background, for those who don't know -- the aim of the
>>>>>>> downstream-parent project is to minimize what a user needs to put
>>>>>>> into
>>>>>>> their POM to build a project.
>>>>>>>
>>>>>>> The main things are:
>>>>>>>
>>>>>>> * dependency on brooklyn-all
>>>>>>> * building OSGi
>>>>>>> * setting up logback correctly
>>>>>>> * dependency on brooklyn test utils
>>>>>>> * convenient test groups (integration, live, etc)
>>>>>>> * specifying versions of libraries brought in (this should
>>>>>>> probably be
>>>>>>> removed, it's a repetition)
>>>>>>>
>>>>>>> The easiest option is probably to bake this in to the archetype --
>>>>>>> Hadrian's (a).  That could make downstream project POMs tedious to
>>>>>>> maintain -- but that's a well-known problem with POMs anyway.
>>>>>>>
>>>>>>> I don't see (b) `<scope>import</scope>` working as I don't think we
>>>>>>> can
>>>>>>> do a lot of the above purely with <dependencyManagement> which is
>>>>>>> what I
>>>>>>> understand import scope to do (although I'm not that familiar with
>>>>>>> it).
>>>>>>>
>>>>>>> I think there is a third option which Hadrian hinted att:
>>>>>>>
>>>>>>>      (c) Change downstream to be parented by brooklyn-parent, adding
>>>>>>> what we need to add/customise for the list above.  Then in the
>>>>>>> archetype's sample pom we override those items which aren't relevant
>>>>>>> (e.g. license, apache release items; if someone does want apache
>>>>>>> release, they add them back) and add those things which might be
>>>>>>> needed
>>>>>>> but can't be put in the downstream-parent pom (e.g. the snapshot
>>>>>>> repos,
>>>>>>> commented out, so people can enable them easily if they way).
>>>>>>>
>>>>>>> I'm happy with either (a) or (c), with a slight preference for (c).
>>>>>>>
>>>>>>> Best
>>>>>>> Alex
>>>>>>>
>>>>>>>
>>>>>>> On 28/06/2015 02:09, 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 <hz...@gmail.com>
>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

Re: brooklyn downstream-parent

[Alex Heneveld <al...@cloudsoftcorp.com>]

If you're happy with that then I'm doubly so!

--A


On 29/06/2015 13:15, Hadrian Zbarcea wrote:
> Should we declare consensus then on going with (c) and improve later 
> as necessary? Sounds like it.
>
> Hadrian
>
> On 06/29/2015 07:59 AM, Alex Heneveld wrote:
>>
>> Hadrian, Aled,
>>
>> Personally I think (c) is easiest for users, at least I've found it so
>> when working with downstreams -- it means their POM is pretty simple,
>> unless they wish otherwise.  Also I think it could be pretty quick to
>> implement (unless you've tried it Hadrian and hit obstacles I don't 
>> see?).
>>
>> Your other suggestion
>>
>>      (d)  Introduce a clearer separation of POM responsibilities so
>> brooklyn-downstream can have a simpler inheritance pattern
>>
>> is an interesting one, technically it is cleaner and it might well be
>> nicer for users if the inheritance is clear.  However I'm hopeful that
>> in most cases they don't need to look at the POM hierarchy ... it just
>> works.  And if they do for now at least we can use comments to give them
>> a steer.  Maybe in 0.8.0 it makes sense to do a refactoring along the
>> lines you suggest.  (There is definitely some stuff in brooklyn-parent
>> which a downstream project doesn't need, but I don't think any of it is
>> harmful.)
>>
>>
>> Aled, yeah I wondered about your option, let's call it
>>
>>      (e)  have a downstream-parent managed outside the Apache project
>>
>> But was unsure about the pain of managing its version and the
>> appropriateness of an artifact *in* Apache which references a POM
>> outside of it.
>>
>>
>> Also I think it's useful to have this in this release to minimise
>> disruption to downstream projects as they upgrade to 0.8.0.
>>
>> Best
>> Alex
>>
>>
>> On 29/06/2015 12:34, Hadrian Zbarcea wrote:
>>> Mails crossed paths. I am curious about some feedback on the (d) 
>>> option.
>>>
>>> That is imho a better variation of (c) if we care that much about
>>> simplifying the life of downstream users. There is also the option of
>>> going with (c), or (a) actually for this release and shoot for (d) in
>>> the next release.
>>>
>>> WDYT?
>>> Hadrian
>>>
>>> On 06/29/2015 07:20 AM, Alex Heneveld wrote:
>>>>
>>>> Hadrian,
>>>>
>>>> Cool that you tried this.  I think any solution will make
>>>> using-your-own-parent tedious as merging two POMs is ugly if even
>>>> possible -- but it's a use case we should consider.  So we should 
>>>> do (c)
>>>> but in the sample POM have a comment to say what the parent brings 
>>>> (list
>>>> in my last mail) to help people who want to replace it with their own
>>>> parent.
>>>>
>>>> Best
>>>> Alex
>>>>
>>>>
>>>> On 29/06/2015 12:05, Hadrian Zbarcea wrote:
>>>>> Hi Alex,
>>>>>
>>>>> Actually something like (c) is what I tried over the weekend, but
>>>>> didn't want to continue without more discussions on the list. (c)
>>>>> requires a bit more work than a (a), but has the major advantage of
>>>>> keeping things consistent. The only major problem I see with (c) is
>>>>> that I don't think it could be used as a subproject, i.e. the user
>>>>> changing with a parent of their own. Is this a limitation we're ok
>>>>> with?
>>>>>
>>>>> Hadrian
>>>>>
>>>>>
>>>>>
>>>>> On 06/29/2015 05:49 AM, Alex Heneveld wrote:
>>>>>>
>>>>>> Hi Hadrian, All-
>>>>>>
>>>>>> For background, for those who don't know -- the aim of the
>>>>>> downstream-parent project is to minimize what a user needs to put 
>>>>>> into
>>>>>> their POM to build a project.
>>>>>>
>>>>>> The main things are:
>>>>>>
>>>>>> * dependency on brooklyn-all
>>>>>> * building OSGi
>>>>>> * setting up logback correctly
>>>>>> * dependency on brooklyn test utils
>>>>>> * convenient test groups (integration, live, etc)
>>>>>> * specifying versions of libraries brought in (this should 
>>>>>> probably be
>>>>>> removed, it's a repetition)
>>>>>>
>>>>>> The easiest option is probably to bake this in to the archetype --
>>>>>> Hadrian's (a).  That could make downstream project POMs tedious to
>>>>>> maintain -- but that's a well-known problem with POMs anyway.
>>>>>>
>>>>>> I don't see (b) `<scope>import</scope>` working as I don't think we
>>>>>> can
>>>>>> do a lot of the above purely with <dependencyManagement> which is
>>>>>> what I
>>>>>> understand import scope to do (although I'm not that familiar with
>>>>>> it).
>>>>>>
>>>>>> I think there is a third option which Hadrian hinted att:
>>>>>>
>>>>>>      (c) Change downstream to be parented by brooklyn-parent, adding
>>>>>> what we need to add/customise for the list above.  Then in the
>>>>>> archetype's sample pom we override those items which aren't relevant
>>>>>> (e.g. license, apache release items; if someone does want apache
>>>>>> release, they add them back) and add those things which might be
>>>>>> needed
>>>>>> but can't be put in the downstream-parent pom (e.g. the snapshot
>>>>>> repos,
>>>>>> commented out, so people can enable them easily if they way).
>>>>>>
>>>>>> I'm happy with either (a) or (c), with a slight preference for (c).
>>>>>>
>>>>>> Best
>>>>>> Alex
>>>>>>
>>>>>>
>>>>>> On 28/06/2015 02:09, 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 <hz...@gmail.com>
>>>>>>>> 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.

Re: brooklyn downstream-parent

[Hadrian Zbarcea <hz...@gmail.com>]

Should we declare consensus then on going with (c) and improve later as 
necessary? Sounds like it.

Hadrian

On 06/29/2015 07:59 AM, Alex Heneveld wrote:
>
> Hadrian, Aled,
>
> Personally I think (c) is easiest for users, at least I've found it so
> when working with downstreams -- it means their POM is pretty simple,
> unless they wish otherwise.  Also I think it could be pretty quick to
> implement (unless you've tried it Hadrian and hit obstacles I don't see?).
>
> Your other suggestion
>
>      (d)  Introduce a clearer separation of POM responsibilities so
> brooklyn-downstream can have a simpler inheritance pattern
>
> is an interesting one, technically it is cleaner and it might well be
> nicer for users if the inheritance is clear.  However I'm hopeful that
> in most cases they don't need to look at the POM hierarchy ... it just
> works.  And if they do for now at least we can use comments to give them
> a steer.  Maybe in 0.8.0 it makes sense to do a refactoring along the
> lines you suggest.  (There is definitely some stuff in brooklyn-parent
> which a downstream project doesn't need, but I don't think any of it is
> harmful.)
>
>
> Aled, yeah I wondered about your option, let's call it
>
>      (e)  have a downstream-parent managed outside the Apache project
>
> But was unsure about the pain of managing its version and the
> appropriateness of an artifact *in* Apache which references a POM
> outside of it.
>
>
> Also I think it's useful to have this in this release to minimise
> disruption to downstream projects as they upgrade to 0.8.0.
>
> Best
> Alex
>
>
> On 29/06/2015 12:34, Hadrian Zbarcea wrote:
>> Mails crossed paths. I am curious about some feedback on the (d) option.
>>
>> That is imho a better variation of (c) if we care that much about
>> simplifying the life of downstream users. There is also the option of
>> going with (c), or (a) actually for this release and shoot for (d) in
>> the next release.
>>
>> WDYT?
>> Hadrian
>>
>> On 06/29/2015 07:20 AM, Alex Heneveld wrote:
>>>
>>> Hadrian,
>>>
>>> Cool that you tried this.  I think any solution will make
>>> using-your-own-parent tedious as merging two POMs is ugly if even
>>> possible -- but it's a use case we should consider.  So we should do (c)
>>> but in the sample POM have a comment to say what the parent brings (list
>>> in my last mail) to help people who want to replace it with their own
>>> parent.
>>>
>>> Best
>>> Alex
>>>
>>>
>>> On 29/06/2015 12:05, Hadrian Zbarcea wrote:
>>>> Hi Alex,
>>>>
>>>> Actually something like (c) is what I tried over the weekend, but
>>>> didn't want to continue without more discussions on the list. (c)
>>>> requires a bit more work than a (a), but has the major advantage of
>>>> keeping things consistent. The only major problem I see with (c) is
>>>> that I don't think it could be used as a subproject, i.e. the user
>>>> changing with a parent of their own. Is this a limitation we're ok
>>>> with?
>>>>
>>>> Hadrian
>>>>
>>>>
>>>>
>>>> On 06/29/2015 05:49 AM, Alex Heneveld wrote:
>>>>>
>>>>> Hi Hadrian, All-
>>>>>
>>>>> For background, for those who don't know -- the aim of the
>>>>> downstream-parent project is to minimize what a user needs to put into
>>>>> their POM to build a project.
>>>>>
>>>>> The main things are:
>>>>>
>>>>> * dependency on brooklyn-all
>>>>> * building OSGi
>>>>> * setting up logback correctly
>>>>> * dependency on brooklyn test utils
>>>>> * convenient test groups (integration, live, etc)
>>>>> * specifying versions of libraries brought in (this should probably be
>>>>> removed, it's a repetition)
>>>>>
>>>>> The easiest option is probably to bake this in to the archetype --
>>>>> Hadrian's (a).  That could make downstream project POMs tedious to
>>>>> maintain -- but that's a well-known problem with POMs anyway.
>>>>>
>>>>> I don't see (b) `<scope>import</scope>` working as I don't think we
>>>>> can
>>>>> do a lot of the above purely with <dependencyManagement> which is
>>>>> what I
>>>>> understand import scope to do (although I'm not that familiar with
>>>>> it).
>>>>>
>>>>> I think there is a third option which Hadrian hinted att:
>>>>>
>>>>>      (c) Change downstream to be parented by brooklyn-parent, adding
>>>>> what we need to add/customise for the list above.  Then in the
>>>>> archetype's sample pom we override those items which aren't relevant
>>>>> (e.g. license, apache release items; if someone does want apache
>>>>> release, they add them back) and add those things which might be
>>>>> needed
>>>>> but can't be put in the downstream-parent pom (e.g. the snapshot
>>>>> repos,
>>>>> commented out, so people can enable them easily if they way).
>>>>>
>>>>> I'm happy with either (a) or (c), with a slight preference for (c).
>>>>>
>>>>> Best
>>>>> Alex
>>>>>
>>>>>
>>>>> On 28/06/2015 02:09, 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 <hz...@gmail.com>
>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

Re: brooklyn downstream-parent

[Alex Heneveld <al...@cloudsoftcorp.com>]

Hadrian, Aled,

Personally I think (c) is easiest for users, at least I've found it so 
when working with downstreams -- it means their POM is pretty simple, 
unless they wish otherwise.  Also I think it could be pretty quick to 
implement (unless you've tried it Hadrian and hit obstacles I don't see?).

Your other suggestion

     (d)  Introduce a clearer separation of POM responsibilities so 
brooklyn-downstream can have a simpler inheritance pattern

is an interesting one, technically it is cleaner and it might well be 
nicer for users if the inheritance is clear.  However I'm hopeful that 
in most cases they don't need to look at the POM hierarchy ... it just 
works.  And if they do for now at least we can use comments to give them 
a steer.  Maybe in 0.8.0 it makes sense to do a refactoring along the 
lines you suggest.  (There is definitely some stuff in brooklyn-parent 
which a downstream project doesn't need, but I don't think any of it is 
harmful.)


Aled, yeah I wondered about your option, let's call it

     (e)  have a downstream-parent managed outside the Apache project

But was unsure about the pain of managing its version and the 
appropriateness of an artifact *in* Apache which references a POM 
outside of it.


Also I think it's useful to have this in this release to minimise 
disruption to downstream projects as they upgrade to 0.8.0.

Best
Alex


On 29/06/2015 12:34, Hadrian Zbarcea wrote:
> Mails crossed paths. I am curious about some feedback on the (d) option.
>
> That is imho a better variation of (c) if we care that much about 
> simplifying the life of downstream users. There is also the option of 
> going with (c), or (a) actually for this release and shoot for (d) in 
> the next release.
>
> WDYT?
> Hadrian
>
> On 06/29/2015 07:20 AM, Alex Heneveld wrote:
>>
>> Hadrian,
>>
>> Cool that you tried this.  I think any solution will make
>> using-your-own-parent tedious as merging two POMs is ugly if even
>> possible -- but it's a use case we should consider.  So we should do (c)
>> but in the sample POM have a comment to say what the parent brings (list
>> in my last mail) to help people who want to replace it with their own
>> parent.
>>
>> Best
>> Alex
>>
>>
>> On 29/06/2015 12:05, Hadrian Zbarcea wrote:
>>> Hi Alex,
>>>
>>> Actually something like (c) is what I tried over the weekend, but
>>> didn't want to continue without more discussions on the list. (c)
>>> requires a bit more work than a (a), but has the major advantage of
>>> keeping things consistent. The only major problem I see with (c) is
>>> that I don't think it could be used as a subproject, i.e. the user
>>> changing with a parent of their own. Is this a limitation we're ok 
>>> with?
>>>
>>> Hadrian
>>>
>>>
>>>
>>> On 06/29/2015 05:49 AM, Alex Heneveld wrote:
>>>>
>>>> Hi Hadrian, All-
>>>>
>>>> For background, for those who don't know -- the aim of the
>>>> downstream-parent project is to minimize what a user needs to put into
>>>> their POM to build a project.
>>>>
>>>> The main things are:
>>>>
>>>> * dependency on brooklyn-all
>>>> * building OSGi
>>>> * setting up logback correctly
>>>> * dependency on brooklyn test utils
>>>> * convenient test groups (integration, live, etc)
>>>> * specifying versions of libraries brought in (this should probably be
>>>> removed, it's a repetition)
>>>>
>>>> The easiest option is probably to bake this in to the archetype --
>>>> Hadrian's (a).  That could make downstream project POMs tedious to
>>>> maintain -- but that's a well-known problem with POMs anyway.
>>>>
>>>> I don't see (b) `<scope>import</scope>` working as I don't think we 
>>>> can
>>>> do a lot of the above purely with <dependencyManagement> which is 
>>>> what I
>>>> understand import scope to do (although I'm not that familiar with 
>>>> it).
>>>>
>>>> I think there is a third option which Hadrian hinted att:
>>>>
>>>>      (c) Change downstream to be parented by brooklyn-parent, adding
>>>> what we need to add/customise for the list above.  Then in the
>>>> archetype's sample pom we override those items which aren't relevant
>>>> (e.g. license, apache release items; if someone does want apache
>>>> release, they add them back) and add those things which might be 
>>>> needed
>>>> but can't be put in the downstream-parent pom (e.g. the snapshot 
>>>> repos,
>>>> commented out, so people can enable them easily if they way).
>>>>
>>>> I'm happy with either (a) or (c), with a slight preference for (c).
>>>>
>>>> Best
>>>> Alex
>>>>
>>>>
>>>> On 28/06/2015 02:09, 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 <hz...@gmail.com>
>>>>>> 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.

Re: brooklyn downstream-parent

[Hadrian Zbarcea <hz...@gmail.com>]

Mails crossed paths. I am curious about some feedback on the (d) option.

That is imho a better variation of (c) if we care that much about 
simplifying the life of downstream users. There is also the option of 
going with (c), or (a) actually for this release and shoot for (d) in 
the next release.

WDYT?
Hadrian

On 06/29/2015 07:20 AM, Alex Heneveld wrote:
>
> Hadrian,
>
> Cool that you tried this.  I think any solution will make
> using-your-own-parent tedious as merging two POMs is ugly if even
> possible -- but it's a use case we should consider.  So we should do (c)
> but in the sample POM have a comment to say what the parent brings (list
> in my last mail) to help people who want to replace it with their own
> parent.
>
> Best
> Alex
>
>
> On 29/06/2015 12:05, Hadrian Zbarcea wrote:
>> Hi Alex,
>>
>> Actually something like (c) is what I tried over the weekend, but
>> didn't want to continue without more discussions on the list. (c)
>> requires a bit more work than a (a), but has the major advantage of
>> keeping things consistent. The only major problem I see with (c) is
>> that I don't think it could be used as a subproject, i.e. the user
>> changing with a parent of their own. Is this a limitation we're ok with?
>>
>> Hadrian
>>
>>
>>
>> On 06/29/2015 05:49 AM, Alex Heneveld wrote:
>>>
>>> Hi Hadrian, All-
>>>
>>> For background, for those who don't know -- the aim of the
>>> downstream-parent project is to minimize what a user needs to put into
>>> their POM to build a project.
>>>
>>> The main things are:
>>>
>>> * dependency on brooklyn-all
>>> * building OSGi
>>> * setting up logback correctly
>>> * dependency on brooklyn test utils
>>> * convenient test groups (integration, live, etc)
>>> * specifying versions of libraries brought in (this should probably be
>>> removed, it's a repetition)
>>>
>>> The easiest option is probably to bake this in to the archetype --
>>> Hadrian's (a).  That could make downstream project POMs tedious to
>>> maintain -- but that's a well-known problem with POMs anyway.
>>>
>>> I don't see (b) `<scope>import</scope>` working as I don't think we can
>>> do a lot of the above purely with <dependencyManagement> which is what I
>>> understand import scope to do (although I'm not that familiar with it).
>>>
>>> I think there is a third option which Hadrian hinted att:
>>>
>>>      (c) Change downstream to be parented by brooklyn-parent, adding
>>> what we need to add/customise for the list above.  Then in the
>>> archetype's sample pom we override those items which aren't relevant
>>> (e.g. license, apache release items; if someone does want apache
>>> release, they add them back) and add those things which might be needed
>>> but can't be put in the downstream-parent pom (e.g. the snapshot repos,
>>> commented out, so people can enable them easily if they way).
>>>
>>> I'm happy with either (a) or (c), with a slight preference for (c).
>>>
>>> Best
>>> Alex
>>>
>>>
>>> On 28/06/2015 02:09, 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 <hz...@gmail.com>
>>>>> 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.
>>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
>

Re: brooklyn downstream-parent

[Alex Heneveld <al...@cloudsoftcorp.com>]

Hadrian,

Cool that you tried this.  I think any solution will make 
using-your-own-parent tedious as merging two POMs is ugly if even 
possible -- but it's a use case we should consider.  So we should do (c) 
but in the sample POM have a comment to say what the parent brings (list 
in my last mail) to help people who want to replace it with their own 
parent.

Best
Alex


On 29/06/2015 12:05, Hadrian Zbarcea wrote:
> Hi Alex,
>
> Actually something like (c) is what I tried over the weekend, but 
> didn't want to continue without more discussions on the list. (c) 
> requires a bit more work than a (a), but has the major advantage of 
> keeping things consistent. The only major problem I see with (c) is 
> that I don't think it could be used as a subproject, i.e. the user 
> changing with a parent of their own. Is this a limitation we're ok with?
>
> Hadrian
>
>
>
> On 06/29/2015 05:49 AM, Alex Heneveld wrote:
>>
>> Hi Hadrian, All-
>>
>> For background, for those who don't know -- the aim of the
>> downstream-parent project is to minimize what a user needs to put into
>> their POM to build a project.
>>
>> The main things are:
>>
>> * dependency on brooklyn-all
>> * building OSGi
>> * setting up logback correctly
>> * dependency on brooklyn test utils
>> * convenient test groups (integration, live, etc)
>> * specifying versions of libraries brought in (this should probably be
>> removed, it's a repetition)
>>
>> The easiest option is probably to bake this in to the archetype --
>> Hadrian's (a).  That could make downstream project POMs tedious to
>> maintain -- but that's a well-known problem with POMs anyway.
>>
>> I don't see (b) `<scope>import</scope>` working as I don't think we can
>> do a lot of the above purely with <dependencyManagement> which is what I
>> understand import scope to do (although I'm not that familiar with it).
>>
>> I think there is a third option which Hadrian hinted att:
>>
>>      (c) Change downstream to be parented by brooklyn-parent, adding
>> what we need to add/customise for the list above.  Then in the
>> archetype's sample pom we override those items which aren't relevant
>> (e.g. license, apache release items; if someone does want apache
>> release, they add them back) and add those things which might be needed
>> but can't be put in the downstream-parent pom (e.g. the snapshot repos,
>> commented out, so people can enable them easily if they way).
>>
>> I'm happy with either (a) or (c), with a slight preference for (c).
>>
>> Best
>> Alex
>>
>>
>> On 28/06/2015 02:09, 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 <hz...@gmail.com> 
>>>> 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.

Re: brooklyn downstream-parent

[Hadrian Zbarcea <hz...@gmail.com>]

Hi Alex,

Actually something like (c) is what I tried over the weekend, but didn't 
want to continue without more discussions on the list. (c) requires a 
bit more work than a (a), but has the major advantage of keeping things 
consistent. The only major problem I see with (c) is that I don't think 
it could be used as a subproject, i.e. the user changing with a parent 
of their own. Is this a limitation we're ok with?

Hadrian



On 06/29/2015 05:49 AM, Alex Heneveld wrote:
>
> Hi Hadrian, All-
>
> For background, for those who don't know -- the aim of the
> downstream-parent project is to minimize what a user needs to put into
> their POM to build a project.
>
> The main things are:
>
> * dependency on brooklyn-all
> * building OSGi
> * setting up logback correctly
> * dependency on brooklyn test utils
> * convenient test groups (integration, live, etc)
> * specifying versions of libraries brought in (this should probably be
> removed, it's a repetition)
>
> The easiest option is probably to bake this in to the archetype --
> Hadrian's (a).  That could make downstream project POMs tedious to
> maintain -- but that's a well-known problem with POMs anyway.
>
> I don't see (b) `<scope>import</scope>` working as I don't think we can
> do a lot of the above purely with <dependencyManagement> which is what I
> understand import scope to do (although I'm not that familiar with it).
>
> I think there is a third option which Hadrian hinted att:
>
>      (c) Change downstream to be parented by brooklyn-parent, adding
> what we need to add/customise for the list above.  Then in the
> archetype's sample pom we override those items which aren't relevant
> (e.g. license, apache release items; if someone does want apache
> release, they add them back) and add those things which might be needed
> but can't be put in the downstream-parent pom (e.g. the snapshot repos,
> commented out, so people can enable them easily if they way).
>
> I'm happy with either (a) or (c), with a slight preference for (c).
>
> Best
> Alex
>
>
> On 28/06/2015 02:09, 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 <hz...@gmail.com> 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.
>>>>>>
>>>>
>>>
>
>

Re: brooklyn downstream-parent

[Hadrian Zbarcea <hz...@gmail.com>]

This latter option was my preference, to maintain the spirit of what's 
done now. It is the most complicated solution though, even for users. 
That's why I suggested (a) as a degenerate variation of this approach. 
And (b) too, to some extent.

While I was hacking happily at the poms, I realized that all options 
have their pros and cons :), not so simple :).

(c) is indeed the more natural one for us, but not the easiest for users 
either.

There is also a (d) I didn't mention, which is what projects like Camel 
use, kinda. Have a *minimal* brooklyn-parent extending 
org.apache:apache:17. Then have a local-parent (whatever the name) and 
downstream-parent extending brooklyn parent. Then local-parent will be 
used (as parent) for the rest of the project and will have all the 
incantations we don't want to propagate downstream. This is a variation 
of what Aled's proposal that's still internal.

So what's it gonna be?
Hadrian


On 06/29/2015 07:01 AM, Aled Sage wrote:
> +1
>
> It was a real pain to write + maintain the pom in a bunch of downstream
> projects (which used Brooklyn for various integrations).
>
> I also therefore favour (c).
>
> If we did (a), then we could also create a new repo outside of Apache
> Brooklyn (e.g. in [1]), containing an equivalent of downstream-project,
> that various community integrations could optionally extend (*). That
> sounds sub-optimal, but manageable.
>
> Aled
>
> (*) Having these community integrations goes with the mentality that
> Apache Brooklyn contains the core + some integrations, but that the
> wider community will over time create+share more integrations in their
> own repos (rather than having to pull-request all integrations to Apache
> Brooklyn).
>
> [1] https://github.com/brooklyncentral
>
>
> On 29/06/2015 10:49, Alex Heneveld wrote:
>>
>> Hi Hadrian, All-
>>
>> For background, for those who don't know -- the aim of the
>> downstream-parent project is to minimize what a user needs to put into
>> their POM to build a project.
>>
>> The main things are:
>>
>> * dependency on brooklyn-all
>> * building OSGi
>> * setting up logback correctly
>> * dependency on brooklyn test utils
>> * convenient test groups (integration, live, etc)
>> * specifying versions of libraries brought in (this should probably be
>> removed, it's a repetition)
>>
>> The easiest option is probably to bake this in to the archetype --
>> Hadrian's (a).  That could make downstream project POMs tedious to
>> maintain -- but that's a well-known problem with POMs anyway.
>>
>> I don't see (b) `<scope>import</scope>` working as I don't think we
>> can do a lot of the above purely with <dependencyManagement> which is
>> what I understand import scope to do (although I'm not that familiar
>> with it).
>>
>> I think there is a third option which Hadrian hinted att:
>>
>>     (c) Change downstream to be parented by brooklyn-parent, adding
>> what we need to add/customise for the list above.  Then in the
>> archetype's sample pom we override those items which aren't relevant
>> (e.g. license, apache release items; if someone does want apache
>> release, they add them back) and add those things which might be
>> needed but can't be put in the downstream-parent pom (e.g. the
>> snapshot repos, commented out, so people can enable them easily if
>> they way).
>>
>> I'm happy with either (a) or (c), with a slight preference for (c).
>>
>> Best
>> Alex
>>
>>
>> On 28/06/2015 02:09, 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 <hz...@gmail.com>
>>>> 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.
>>>>>>>
>>>>>
>>>>
>>
>>
>

Re: brooklyn downstream-parent

[Aled Sage <al...@gmail.com>]

+1

It was a real pain to write + maintain the pom in a bunch of downstream 
projects (which used Brooklyn for various integrations).

I also therefore favour (c).

If we did (a), then we could also create a new repo outside of Apache 
Brooklyn (e.g. in [1]), containing an equivalent of downstream-project, 
that various community integrations could optionally extend (*). That 
sounds sub-optimal, but manageable.

Aled

(*) Having these community integrations goes with the mentality that 
Apache Brooklyn contains the core + some integrations, but that the 
wider community will over time create+share more integrations in their 
own repos (rather than having to pull-request all integrations to Apache 
Brooklyn).

[1] https://github.com/brooklyncentral


On 29/06/2015 10:49, Alex Heneveld wrote:
>
> Hi Hadrian, All-
>
> For background, for those who don't know -- the aim of the 
> downstream-parent project is to minimize what a user needs to put into 
> their POM to build a project.
>
> The main things are:
>
> * dependency on brooklyn-all
> * building OSGi
> * setting up logback correctly
> * dependency on brooklyn test utils
> * convenient test groups (integration, live, etc)
> * specifying versions of libraries brought in (this should probably be 
> removed, it's a repetition)
>
> The easiest option is probably to bake this in to the archetype -- 
> Hadrian's (a).  That could make downstream project POMs tedious to 
> maintain -- but that's a well-known problem with POMs anyway.
>
> I don't see (b) `<scope>import</scope>` working as I don't think we 
> can do a lot of the above purely with <dependencyManagement> which is 
> what I understand import scope to do (although I'm not that familiar 
> with it).
>
> I think there is a third option which Hadrian hinted att:
>
>     (c) Change downstream to be parented by brooklyn-parent, adding 
> what we need to add/customise for the list above.  Then in the 
> archetype's sample pom we override those items which aren't relevant 
> (e.g. license, apache release items; if someone does want apache 
> release, they add them back) and add those things which might be 
> needed but can't be put in the downstream-parent pom (e.g. the 
> snapshot repos, commented out, so people can enable them easily if 
> they way).
>
> I'm happy with either (a) or (c), with a slight preference for (c).
>
> Best
> Alex
>
>
> On 28/06/2015 02:09, 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 <hz...@gmail.com> 
>>> 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.
>>>>>>
>>>>
>>>
>
>