You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Hadrian Zbarcea <hz...@gmail.com> on 2015/07/06 04:21:02 UTC
Re: brooklyn downstream-parent
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
Posted by 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
Posted by 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
Posted by 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
Posted by 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.