11:22 p.m.
Hi Stefan,
what was your specific motivation for adding the JBoss Repos?
The topic was discussed before [1] with the result, that we will not
hard code any Maven repositories in Hawkular Parent. All we produce and
all we depend on should be on Maven Central.
The only inconvenience with Central is that JBoss Nexus is synced to
central once a day only. The ones wanting to rely on freshly released
artifacts are recommended to add JBoss Nexus to their settings.xml. This
holds also for CI jobs.
Thanks,
Peter
[1] on #hawkular on 2015-01-21, reasons against it are summed in
http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is...
12:08 a.m.
Hello Peter,
This came up on Friday, when me and Mazz worked on getting all the Travis builds to
publish -SNAPSHOT artifacts. The goal was to get the main project (with the pinger) built
both on Travis and locally.
I think it is essential to have the default repositories in the parent pom. Community
users should just do 'clone & mvn' to get started. Anything more complicated
(like changing settings.xml or setting up profiles) is completely unacceptable. Since we
are working with snapshots and have a myriad of projects, the essential repositories need
to be in the parent pom.
If you notice, the repositories are in a profile that can be disabled. So there is a lot
of configuration flexibility for power users (eg. the link you posted below).
Please do not revert these changes.
Thank you,
Stefan
----- Original Message -----
From: "Peter Palaga" <ppalaga(a)redhat.com>
To: "Stefan Negrea" <snegrea(a)redhat.com>
Cc: hawkular-dev(a)lists.jboss.org
Sent: Monday, February 16, 2015 8:22:06 AM
Subject: Maven repositories in Hawkular Parent
Hi Stefan,
what was your specific motivation for adding the JBoss Repos?
The topic was discussed before [1] with the result, that we will not
hard code any Maven repositories in Hawkular Parent. All we produce and
all we depend on should be on Maven Central.
The only inconvenience with Central is that JBoss Nexus is synced to
central once a day only. The ones wanting to rely on freshly released
artifacts are recommended to add JBoss Nexus to their settings.xml. This
holds also for CI jobs.
Thanks,
Peter
[1] on #hawkular on 2015-01-21, reasons against it are summed in
http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is...
1:54 a.m.
Am 16.02.2015 um 16:08 schrieb Stefan Negrea
<snegrea(a)redhat.com>:
I think it is essential to have the default repositories in the parent pom. Community
users should just do 'clone & mvn' to get started.
I agree.
Anything more complicated (like changing settings.xml or setting up
profiles) is completely unacceptable. Since we are working with
I think we may be able to go / do some middle ground that if we can't use the
"profile trick", we at least deliver
pre-configured hawkular-settings.xml files (like we do now for Travis) that users can use
with
mvn -s hawkular-settings.xml install to get going.
What we need to prevent is that the user has to guess and/or copy/paste the settings from
somewhere into ~/.m2/settings.xml,
as many users don't even know what to copy&paste.
2:54 a.m.
----- Original Message -----
From: "Heiko W.Rupp" <hrupp(a)redhat.com>
To: hawkular-dev(a)lists.jboss.org
Sent: Monday, February 16, 2015 10:54:39 AM
Subject: Re: [Hawkular-dev] Maven repositories in Hawkular Parent
> Am 16.02.2015 um 16:08 schrieb Stefan Negrea <snegrea(a)redhat.com>:
> I think it is essential to have the default repositories in the parent pom.
> Community users should just do 'clone & mvn' to get started.
I agree.
> Anything more complicated (like changing settings.xml or setting up
> profiles) is completely unacceptable. Since we are working with
I think we may be able to go / do some middle ground that if we can't use the
"profile trick", we at least deliver
The profile trick works now, that is how it is implemented. There is a profile that gets
activated automatically and can be disabled via a property. So power users have a way to
do exactly what they want without pom changes, while regular users enjoy 'clone &
mvn' with nothing else.
pre-configured hawkular-settings.xml files (like we do now for
Travis) that
users can use with
mvn -s hawkular-settings.xml install to get going.
What we need to prevent is that the user has to guess and/or copy/paste the
settings from somewhere into ~/.m2/settings.xml,
as many users don't even know what to copy&paste.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:49 a.m.
Hi Stefan, inline...
On 02/16/2015 04:08 PM, Stefan Negrea wrote:
Hello Peter,
This came up on Friday, when me and Mazz worked on getting all the
Travis builds to publish -SNAPSHOT artifacts. The goal was to get the
main project (with the pinger) built both on Travis and locally.
Where could I have a look at that effort? I have seen something in
hawkular-bus master, but I do not see it in the main hawkular project.
Are you wanting to make the main hawkular project dependent on
components's SNAPSHOTs?
I think it is essential to have the default repositories in the
parent pom.
Yes, we have all in Maven Central. There is no need to introduce JBoss
Nexus because of the synchronisation delay.
Community users should just do 'clone & mvn' to get
started.
Yes, with the notice that there is this sync window that has a well
known workaround.
Anything more complicated (like changing settings.xml or setting up
profiles) is completely unacceptable. Since we are working with
snapshots and have a myriad of projects, the essential repositories
need to be in the parent pom.
Once again, you really want to introduce -SNAPSHOT deps master branches?
If you notice, the repositories are in a profile that can be
disabled. So there is a lot of configuration flexibility for power
users (eg. the link you posted below).
Yes, we can offer hawkular-settings.xml for power users.
Please do not revert these changes.
I do not see a need for these repos.
Thanks,
Peter
Thank you, Stefan
----- Original Message -----
> From: "Peter Palaga" <ppalaga(a)redhat.com> To: "Stefan
Negrea"
> <snegrea(a)redhat.com> Cc: hawkular-dev(a)lists.jboss.org Sent: Monday,
> February 16, 2015 8:22:06 AM Subject: Maven repositories in
> Hawkular Parent
>
> Hi Stefan,
>
> what was your specific motivation for adding the JBoss Repos?
>
> The topic was discussed before [1] with the result, that we will
> not hard code any Maven repositories in Hawkular Parent. All we
> produce and all we depend on should be on Maven Central.
>
> The only inconvenience with Central is that JBoss Nexus is synced
> to central once a day only. The ones wanting to rely on freshly
> released artifacts are recommended to add JBoss Nexus to their
> settings.xml. This holds also for CI jobs.
>
> Thanks,
>
> Peter
>
> [1] on #hawkular on 2015-01-21, reasons against it are summed in
>
http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is...
>
6:05 a.m.
Once again, you really want to introduce -SNAPSHOT deps master
branches?
For now, in my opinion (which may not be worth much in these discussions) the answer is
"yes." We already saw the problem last week when no one could really build the
integration server without having to manually build all the components themselves (alerts,
inventory, pinger, bus, etc). And we don't want them to be non-snapshots because this
work is moving at a fast pace - we don't want to have to worry about, say, waiting for
Jay/Lucas to bump up their alerts version #, and releasing it.
BTW: we still can't build the integration server because the pinger and
notifier/inventory stuff is in heiko's branches - so you still need to build those.
But soon we should think about getting them in the hawkular repo - that might cause a
heart attack in Lukas K. but if we promise to redo it later, I think he'll survive the
hospital visit. :}
Requiring non-SNAPSHOTS everywhere may work perfectly fine once we have some actual
product out the door, but right now, we are moving so fast to try to get something out
ASAP that we really need to support SNAPSHOT builds.
Again, I am not advocating one way or the other - I'm just pointing out the pain point
I had last week, and the fact that it was the inability to get SNAPSHOTs from the repos is
what was the cause.
6:24 a.m.
On Feb 16, 2015, at 4:05 PM, John Mazzitelli <mazz(a)redhat.com>
wrote:
> Once again, you really want to introduce -SNAPSHOT deps master branches?
For now, in my opinion (which may not be worth much in these discussions) the answer is
"yes." We already saw the problem last week when no one could really build the
integration server without having to manually build all the components themselves (alerts,
inventory, pinger, bus, etc). And we don't want them to be non-snapshots because this
work is moving at a fast pace - we don't want to have to worry about, say, waiting for
Jay/Lucas to bump up their alerts version #, and releasing it.
BTW: we still can't build the integration server because the pinger and
notifier/inventory stuff is in heiko's branches - so you still need to build those.
But soon we should think about getting them in the hawkular repo - that might cause a
heart attack in Lukas K. but if we promise to redo it later, I think he'll survive the
hospital visit. :}
Requiring non-SNAPSHOTS everywhere may work perfectly fine once we have some actual
product out the door, but right now, we are moving so fast to try to get something out
ASAP that we really need to support SNAPSHOT builds.
+1 I think that trying to depend on non-snapshot versions right now would just create a
lot of extra work since things are really fluid right now.
Again, I am not advocating one way or the other - I'm just pointing out the pain
point I had last week, and the fact that it was the inability to get SNAPSHOTs from the
repos is what was the cause.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
6:01 p.m.
I can understand the need.
The main issue with depending on SNAPSHOTs is the non-reproducibility of
the builds - clearly, because a SNAPSHOT of an artifact A can be
distinct at any two instants t1 and t2. This alone is a sufficient
reason for not allowing SNAPSHOT dependencies in any durable public
branches.
Please try to imagine how could you figure out what is the problem with
a SNAPSHOT dependency. By default, there is zero revision info available
in jars and poms.
= Building locally
My personal view (that I do not force to any one) is that it is quite
normal to have to git-pull the components I depend on, build them
locally and then, in my consuming project override the version props to
the SNAPSHOTs (e.g. using a profile in my settings). All steps are
perfectly scriptable and such a script can be written once and shared.
The advantage of this approach is that one always knows what git
revision at which instant was used to build the snapshots. One has the
history of all components at hand for the case that something goes
wrong. It is easy to reset the broken component to the last "known as
correct" state, rebuild and work on one's own stuff in the consuming
project.
= CI
It is nice to know early that some change in upstream component has
broken a consuming project. The CI can either use the script used
locally (easy) or some kind of properly labeled nightly builds
(complicated).
-- Peter
On 01/22/2015 09:11 PM, John Sanda wrote:
> On Feb 16, 2015, at 4:05 PM, John Mazzitelli <mazz(a)redhat.com> wrote:
>
>> Once again, you really want to introduce -SNAPSHOT deps master branches?
>
> For now, in my opinion (which may not be worth much in these discussions) the answer
is "yes." We already saw the problem last week when no one could really build
the integration server without having to manually build all the components themselves
(alerts, inventory, pinger, bus, etc). And we don't want them to be non-snapshots
because this work is moving at a fast pace - we don't want to have to worry about,
say, waiting for Jay/Lucas to bump up their alerts version #, and releasing it.
>
> BTW: we still can't build the integration server because the pinger and
notifier/inventory stuff is in heiko's branches - so you still need to build those.
But soon we should think about getting them in the hawkular repo - that might cause a
heart attack in Lukas K. but if we promise to redo it later, I think he'll survive the
hospital visit. :}
>
> Requiring non-SNAPSHOTS everywhere may work perfectly fine once we have some actual
product out the door, but right now, we are moving so fast to try to get something out
ASAP that we really need to support SNAPSHOT builds.
+1 I think that trying to depend on non-snapshot versions right now would just create a
lot of extra work since things are really fluid right now.
>
> Again, I am not advocating one way or the other - I'm just pointing out the pain
point I had last week, and the fact that it was the inability to get SNAPSHOTs from the
repos is what was the cause.
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9:22 a.m.
On Monday, February 16, 2015 04:05:42 PM John Mazzitelli wrote:
> Once again, you really want to introduce -SNAPSHOT deps master
branches?
For now, in my opinion (which may not be worth much in these discussions)
the answer is "yes." We already saw the problem last week when no one could
really build the integration server without having to manually build all
the components themselves (alerts, inventory, pinger, bus, etc). And we
don't want them to be non-snapshots because this work is moving at a fast
pace - we don't want to have to worry about, say, waiting for Jay/Lucas to
bump up their alerts version #, and releasing it.
BTW: we still can't build the integration server because the pinger and
notifier/inventory stuff is in heiko's branches - so you still need to
build those. But soon we should think about getting them in the hawkular
repo - that might cause a heart attack in Lukas K. but if we promise to
redo it later, I think he'll survive the hospital visit. :}
I merged the changes myself, so the notifier is in hawkular-inventory
(https://github.com/hawkular/hawkular-inventory/pull/12). You know me well -
my soul died a little doing it ;)
Requiring non-SNAPSHOTS everywhere may work perfectly fine once we
have some
actual product out the door, but right now, we are moving so fast to try to
get something out ASAP that we really need to support SNAPSHOT builds.
+1. I bit the bullet with actually depending on the bus in the component code
(the horrors!), because of the same reason - we unfortunately need to move
fast and can't afford to be purist ATM.
That said, all these violations should be filed as release blockers
(https://issues.jboss.org/browse/HWKINVENT-11) ;)
Again, I am not advocating one way or the other - I'm just
pointing out the
pain point I had last week, and the fact that it was the inability to get
SNAPSHOTs from the repos is what was the cause.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
7:42 p.m.
> Once again, you really want to introduce -SNAPSHOT deps master
branches?
For now, in my opinion (which may not be worth much in these discussions)
the answer is "yes." We already saw the problem last week when no one could
really build the integration server without having to manually build all
the components themselves (alerts, inventory, pinger, bus, etc). And we
don't want them to be non-snapshots because this work is moving at a fast
pace - we don't want to have to worry about, say, waiting for Jay/Lucas to
bump up their alerts version #, and releasing it.
BTW: we still can't build the integration server because the pinger and
notifier/inventory stuff is in heiko's branches - so you still need to
build those. But soon we should think about getting them in the hawkular
repo - that might cause a heart attack in Lukas K. but if we promise to
redo it later, I think he'll survive the hospital visit. :}
I merged the changes myself, so the notifier is in hawkular-inventory
(https://github.com/hawkular/hawkular-inventory/pull/12). You know me well -
my soul died a little doing it
Requiring non-SNAPSHOTS everywhere may work perfectly fine once we
have some
actual product out the door, but right now, we are moving so fast to try to
get something out ASAP that we really need to support SNAPSHOT builds.
+1. I bit the bullet with actually depending on the bus in the component code
(the horrors!), because of the same reason - we unfortunately need to move
fast and can't afford to be purist ATM.
That said, all these violations should be filed as release blockers
(https://issues.jboss.org/browse/HWKINVENT-11)
Again, I am not advocating one way or the other - I'm just
pointing out the
pain point I had last week, and the fact that it was the inability to get
SNAPSHOTs from the repos is what was the cause.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
4:56 p.m.
Am 16.02.2015 um 21:49 schrieb Peter Palaga
<ppalaga(a)redhat.com>:
Are you wanting to make the main hawkular project dependent on
components's SNAPSHOTs?
*Named* snapshots.
The underlying issue is that we want on each push to a master branch in one
of the projects to build it with the available dependencies (and the deploy - the
latter is not yet there but being worked on).
To achieve this, we need to have a "cache" that is reachable from Travis or for
internal and community users with the latest dependencies. They should never
need to check out a sub-project they are not interested in to compile the component
they want to work on.
And for the moment the idea is/was to use the snapshots repo of Nexus as this cache.
Of course we could release (with all the expensive release procedure) a 1.x.0 release
of all the components after a successful build, but I think this is not how publishing
to Central is supposed to work and we also so not want to spam it with hundreds of
versions of our stuff.
3367
days inactive
3368
days old
10 comments
6 participants
participants (6)
-
Heiko W.Rupp -
John Mazzitelli -
John Sanda -
Lukas Krejci -
Peter Palaga -
Stefan Negrea