brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <aled.s...@gmail.com>
Subject Re: brooklyn downstream-parent
Date Mon, 29 Jun 2015 11:01:00 GMT
+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