Mailing-List: contact dev-help@brooklyn.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of hzbarcea@gmail.com designates
 209.85.223.182 as permitted sender)
Message-ID: <559A85B1.6020909@gmail.com>
Date: Mon, 06 Jul 2015 09:42:09 -0400
From: Hadrian Zbarcea <hzbarcea@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: dev@brooklyn.incubator.apache.org
Subject: Re: brooklyn downstream-parent
References: 
 <CABQFKi1_zrCOVz0VrWh2UmnkMEV_3EZPQ1v+h7EFrV46eyJJoA@mail.gmail.com>
 <558E1A1B.2020407@gmail.com> <558E1F4D.3080906@gmail.com>
 <CANaN7bHBEiABB9hBhCrs_Ma+sGPQ=811Cyf73J6a++b6x+Kq2g@mail.gmail.com>
 <558F4957.6040304@gmail.com> <55911498.1080707@CloudsoftCorp.com>
 <55912660.2000404@gmail.com> <559129E4.8020405@CloudsoftCorp.com>
 <55912D2D.8060309@gmail.com> <55913306.6040301@CloudsoftCorp.com>
 <559136E2.6080405@gmail.com> <55913A00.9060305@CloudsoftCorp.com>
 <5599E60E.2000005@gmail.com> <559A7343.4030607@CloudsoftCorp.com>
In-Reply-To: <559A7343.4030607@CloudsoftCorp.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

(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
>>>>>>>>>>> <hzbarcea@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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>