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, 29 Jun 2015 11:25:43 GMT
This latter option was my preference, to maintain the spirit of what's 
done now. It is the most complicated solution though, even for users. 
That's why I suggested (a) as a degenerate variation of this approach. 
And (b) too, to some extent.

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

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

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

So what's it gonna be?
Hadrian


On 06/29/2015 07:01 AM, Aled Sage wrote:
> +1
>
> It was a real pain to write + maintain the pom in a bunch of downstream
> projects (which used Brooklyn for various integrations).
>
> I also therefore favour (c).
>
> If we did (a), then we could also create a new repo outside of Apache
> Brooklyn (e.g. in [1]), containing an equivalent of downstream-project,
> that various community integrations could optionally extend (*). That
> sounds sub-optimal, but manageable.
>
> Aled
>
> (*) Having these community integrations goes with the mentality that
> Apache Brooklyn contains the core + some integrations, but that the
> wider community will over time create+share more integrations in their
> own repos (rather than having to pull-request all integrations to Apache
> Brooklyn).
>
> [1] https://github.com/brooklyncentral
>
>
> On 29/06/2015 10:49, Alex Heneveld wrote:
>>
>> Hi Hadrian, All-
>>
>> For background, for those who don't know -- the aim of the
>> downstream-parent project is to minimize what a user needs to put into
>> their POM to build a project.
>>
>> The main things are:
>>
>> * dependency on brooklyn-all
>> * building OSGi
>> * setting up logback correctly
>> * dependency on brooklyn test utils
>> * convenient test groups (integration, live, etc)
>> * specifying versions of libraries brought in (this should probably be
>> removed, it's a repetition)
>>
>> The easiest option is probably to bake this in to the archetype --
>> Hadrian's (a).  That could make downstream project POMs tedious to
>> maintain -- but that's a well-known problem with POMs anyway.
>>
>> I don't see (b) `<scope>import</scope>` working as I don't think we
>> can do a lot of the above purely with <dependencyManagement> which is
>> what I understand import scope to do (although I'm not that familiar
>> with it).
>>
>> I think there is a third option which Hadrian hinted att:
>>
>>     (c) Change downstream to be parented by brooklyn-parent, adding
>> what we need to add/customise for the list above.  Then in the
>> archetype's sample pom we override those items which aren't relevant
>> (e.g. license, apache release items; if someone does want apache
>> release, they add them back) and add those things which might be
>> needed but can't be put in the downstream-parent pom (e.g. the
>> snapshot repos, commented out, so people can enable them easily if
>> they way).
>>
>> I'm happy with either (a) or (c), with a slight preference for (c).
>>
>> Best
>> Alex
>>
>>
>> On 28/06/2015 02:09, Hadrian Zbarcea wrote:
>>> This is not an easy one and imho would require some community choice
>>> before implementing a solution.
>>>
>>> 1. To be able to release downstream-parent, it would have to have the
>>> proper configuration, specifically for the release and gpg maven
>>> plugins, that comes actually from the org.apache:apache:17 parent.
>>> 2. Consequently, the downstream parent should have either
>>> org.apache:apache:17 or even better
>>> org.apache.brooklyn:brooklyn-parent as a parent.
>>> 3. The downstream-parent is only used in the quickstart archetype.
>>>
>>> There is questionable value in having a downstream-parent that users
>>> would have to change anyway if it caries the apache scp and release
>>> configurations that wouldn't apply for a user's project.
>>>
>>> The only 2 solutions I can think of are to:
>>> a. Get rid of the downstream parent and move all the necessary
>>> incantations in the quickstart archetype.
>>> b. Transform the downstream-parent (and maybe come up with a better
>>> name for it) into a <scope>import</scope> pom [1].
>>>
>>> I think this is a blocker for the release.
>>>
>>> Thoughts?
>>> Hadrian
>>>
>>> [1]
>>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
>>>
>>>
>>> On 06/27/2015 04:05 AM, Andrea Turli wrote:
>>>> Thanks Hadrian,
>>>>
>>>> I've also found this one while googling for another project [1], so
>>>> either
>>>> Apache parent or nothing should fix the issue.
>>>>
>>>> HTH,
>>>> Andrea
>>>>
>>>> [1]:
>>>> http://central.sonatype.org/pages/apache-maven.html#deprecated-oss-parent
>>>>
>>>>
>>>> On Sat, 27 Jun 2015 at 05:58 Hadrian Zbarcea <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