+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 <[email protected]>
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.
