brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: brooklyn downstream-parent
Date Mon, 06 Jul 2015 02:21:02 GMT
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.
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

Mime
View raw message