(6) means that there is no pom.xml in ./usage, ./storage, ./utils, etc.
Which means that if I want to build that part I'd have to either build
projects one by one, or use the appropriate profile in the (currently)
parent pom.xml.
I usually try to go with smaller, incremental changes because they are
both easier to digest for others and it's easier to find regression
bugs. For large projects I started to rely a lot on `git bisect`.
In this case I would very much like to start with simplifying the poms.
I don't think I've seen a 2k loc pom before. CTR doesn't help either.
However, after a merge from upstream and an upgrade of my linux box I am
now getting the exception below. Dunno yet if it's my box or something else.
java.rmi.server.ExportException: Port already in use: 40129; nested
exception is:
java.net.BindException: Address already in use
Cheers,
Hadrian
On 07/06/2015 08:23 AM, Alex Heneveld wrote:
Hadrian-
I like (d). My thoughts with (c) was simply that it is easier for us to
do just now and for many use cases it's fine. That is, for all the
downstream projects I've used it has been a useful starting point. So
I'm motivated by getting a binary release out ASAP with a structure
where we can clean up the pom parentage as we move to 0.8.0.
Are there show-stopping issues with (c) ? What's the MVP to make (d)
work ?
Re your (d) on--
1) I'd use /usage/parent instead of /parent
5) I like having the downstream pom just for readabilty
6) What do you mean here?
I agree with 2,3,4,7.
Best
Alex
On 06/07/2015 03:21, Hadrian Zbarcea wrote:
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
<[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.
