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