brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Subject Re: brooklyn downstream-parent
Date Mon, 06 Jul 2015 12:23:31 GMT

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.
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>


-- 
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.

Mime
View raw message