Re: Are snapshots available in some Maven repo?

[Mickael Istria]

Hi,

master seems by far enough to me, and I think support for specific other
branches should be considered in another future step if it happens to be
requested one day.
About nightly, I think it's usually not such a good rule. I wrote about it
some time ago when I started to deal with release engineering for a bunch
of Eclipse projects:
https://mickaelistria.wordpress.com/2011/12/07/call-a-spade-a-spade-and-a-nightly-a-snapshot/
. My recommandation would be to use the "Poll SCM" Jenkins feature
configured to check SCM @hourly or so. This should overall produce less
builds than a nightly (leading to less things to re-download and re-try for
clients without actual payload change, so it's more energy-efficient and
easier for testing), and also gives more agility by reducing the feedback
loop.

Cheers,

Re: Are snapshots available in some Maven repo?

[Enrico Olivelli]

+1 for master and nightly, timezone is not so important

Enrico

Il gio 10 gen 2019, 21:44 Stephen Connolly 
ha scritto:

> I say if we are doing automatic snapshot deployment, master branch only and
> either weekly or daily or on every commit... pick one for all our projects.
>
> Other branches would just confuse things so keep them as manual deployment
> and if doing that require the branch name included in the version number.
>
> On Thu 10 Jan 2019 at 20:14, Olivier Lamy  wrote:
>
> > We already had this discussion so many times and it always turns to non
> > ended complicated discussion with very complicated cases which NEVER
> happen
> > here
> > So the most important is: We must take it easy and avoid
> overthinking!.
> > +1 for every night a master snapshot or every master changes.
> > but please keep it simple
> >
> >
> > On Fri, 11 Jan 2019 at 06:34, Dan Tran  wrote:
> >
> > > how about just deploy nightly snapshot of active 'main' branch ( ie
> > > master)?
> > >
> > > -D
> > >
> > >
> > > On Thu, Jan 10, 2019 at 9:03 AM Robert Scholte 
> > > wrote:
> > >
> > > > Now that we use branches actively, it is way more important where a
> > > > SNAPSHOT is coming from.
> > > > I've seen it too often that people thought they were testing with a
> > > > version from a specific branch, but that it was redeployed with
> another
> > > > version.
> > > > The first steps are done to rewrite the pom-file during publication,
> > and
> > > > that might be exactly what we need here: when we're on a branch, the
> > > > branchname should be added to the version.
> > > > Call it work in progress for better support.
> > > >
> > > > thanks,
> > > > Robert
> > > >
> > > > On Thu, 10 Jan 2019 10:50:57 +0100, Stephen Connolly
> > > >  wrote:
> > > >
> > > > > On Thu, 10 Jan 2019 at 09:11, Mickael Istria 
> > > wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> Eclipse m2e, as a consumer of Maven as a library, would love to
> see
> > > the
> > > > >> latest HEAD from master published automatically as SNAPSHOTs soon
> > > after
> > > > >> every change is made. This seems like a requirement to enable
> > > continuous
> > > > >> feedback from m2e to Maven.
> > > > >> Publishing some other branches or commits doesn't seem interesting
> > to
> > > > >> Eclipse m2e at the moment.
> > > > >>
> > > > >
> > > > > My point is that we need a clearly defined policy as to exactly
> what
> > > > > branch(es) are automatically pushed and when.
> > > > >
> > > > > That policy could be *one* of:
> > > > > * "master" if there are SCM changes detected on Sunday at 00:00 UTC
> > > > > * "master" if there are SCM changes detected at 00:00 UTC
> > > > > * "master" as soon as SCM changes are detected
> > > > > * "integration" as soon as SCM changes are detected
> > > > > * etc
> > > > >
> > > > > We just need to be crystal clear exactly what policy we are
> > following.
> > > > > Right now the policy we are following is:
> > > > >
> > > > > * Manually from whatever branch is appropriate and only when there
> > is a
> > > > > request for them to be published.
> > > > >
> > > > > There are good and valid reasons for any of these policies (or
> indeed
> > > > > other
> > > > > alternative policies). The problems occur if you try to mix policy.
> > > > >
> > > > > For example, if I as a developer know that snapshots could be
> > published
> > > > > at
> > > > > any time then I can choose between `always` and `never` as the
> update
> > > > > policy depending on whether I want to focus on diagnosing issues
> on a
> > > > > consistent base or discovering issues on shifting sand.
> > > > >
> > > > > If I know that snapshots will only ever be published once a week
> > then I
> > > > > can
> > > > > leave the update policy at the default of daily because I'll need
> to
> > > > > rebuild my mental context on the next week anyway and it's only the
> > > first
> > > > > build on Monday's that will have the time kill.
> > > > >
> > > > > So the thing that we need to do is decide if we want to change our
> > > > > policy,
> > > > > if yes, then decide what we want to change it to *and* both
> implement
> > > it
> > > > > consistently and publish it clearly.
> > > > >
> > > > > Finally we have the ASF legal requirements that mean we need to
> > clarify
> > > > > to
> > > > > all that -SNAPSHOTs are not actually releases and are only made
> > > available
> > > > > for validation prior to VOTE threads... because currently
> -SNAPSHOTs
> > > are
> > > > > rare this is not a big issue... if we have the CI pushing
> -SNAPSHOTs
> > > at a
> > > > > regular cadence the risk of *users* starting to use -SNAPSHOTs as
> > > > > releases
> > > > > rises so we would need to find ways to mitigate such risks
> > > > >
> > > > >
> > > > >>
> > > > >> Cheers,
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: 

Re: Update versions of all plugins in default-bindings.xml

[Hervé BOUTEMY]

As I wrote in many Jira issues over years on this topic, I'm not in favor of 
that

To me, staying with the same default plugins versions from Maven version to 
Maven version is a feature: nobody should expect to change his Maven version 
to change the plugins versions
The best practice is to define plugins versions in your pom.xml (or parent).
Getting very old versions of plugins by default is the best additional feature 
we have after the WARN "plugin version not defined"

Then IMHO, upgrading default plugins versions is a bad idea, is a bad message 
= "you can continue to ignore the WARN on plugins versions and still get 
newest and latest plugins"

this leads IMHO to one (bad) reason for people to require Maven Wrapper


I know, this is counter intuitive, that's why it is required to really take a 
moment to think about it

Regards,

Hervé

Le jeudi 10 janvier 2019, 17:08:57 CET Tibor Digana a écrit :
> Why we use old versions in default-bindings.xml?
> Can we update all versions in 3.6.1 release?
> 
> Here is MNG-6557 which is related to Surefire but I guess this Jira issue
> can be freely related to all plugins.
> 
> WDYT?
> Any objections to update all plugins and assign this issue in 3.6.1?
> 
> Cheers
> Tibor





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Are snapshots available in some Maven repo?

[Stephen Connolly]

I say if we are doing automatic snapshot deployment, master branch only and
either weekly or daily or on every commit... pick one for all our projects.

Other branches would just confuse things so keep them as manual deployment
and if doing that require the branch name included in the version number.

On Thu 10 Jan 2019 at 20:14, Olivier Lamy  wrote:

> We already had this discussion so many times and it always turns to non
> ended complicated discussion with very complicated cases which NEVER happen
> here
> So the most important is: We must take it easy and avoid overthinking!.
> +1 for every night a master snapshot or every master changes.
> but please keep it simple
>
>
> On Fri, 11 Jan 2019 at 06:34, Dan Tran  wrote:
>
> > how about just deploy nightly snapshot of active 'main' branch ( ie
> > master)?
> >
> > -D
> >
> >
> > On Thu, Jan 10, 2019 at 9:03 AM Robert Scholte 
> > wrote:
> >
> > > Now that we use branches actively, it is way more important where a
> > > SNAPSHOT is coming from.
> > > I've seen it too often that people thought they were testing with a
> > > version from a specific branch, but that it was redeployed with another
> > > version.
> > > The first steps are done to rewrite the pom-file during publication,
> and
> > > that might be exactly what we need here: when we're on a branch, the
> > > branchname should be added to the version.
> > > Call it work in progress for better support.
> > >
> > > thanks,
> > > Robert
> > >
> > > On Thu, 10 Jan 2019 10:50:57 +0100, Stephen Connolly
> > >  wrote:
> > >
> > > > On Thu, 10 Jan 2019 at 09:11, Mickael Istria 
> > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Eclipse m2e, as a consumer of Maven as a library, would love to see
> > the
> > > >> latest HEAD from master published automatically as SNAPSHOTs soon
> > after
> > > >> every change is made. This seems like a requirement to enable
> > continuous
> > > >> feedback from m2e to Maven.
> > > >> Publishing some other branches or commits doesn't seem interesting
> to
> > > >> Eclipse m2e at the moment.
> > > >>
> > > >
> > > > My point is that we need a clearly defined policy as to exactly what
> > > > branch(es) are automatically pushed and when.
> > > >
> > > > That policy could be *one* of:
> > > > * "master" if there are SCM changes detected on Sunday at 00:00 UTC
> > > > * "master" if there are SCM changes detected at 00:00 UTC
> > > > * "master" as soon as SCM changes are detected
> > > > * "integration" as soon as SCM changes are detected
> > > > * etc
> > > >
> > > > We just need to be crystal clear exactly what policy we are
> following.
> > > > Right now the policy we are following is:
> > > >
> > > > * Manually from whatever branch is appropriate and only when there
> is a
> > > > request for them to be published.
> > > >
> > > > There are good and valid reasons for any of these policies (or indeed
> > > > other
> > > > alternative policies). The problems occur if you try to mix policy.
> > > >
> > > > For example, if I as a developer know that snapshots could be
> published
> > > > at
> > > > any time then I can choose between `always` and `never` as the update
> > > > policy depending on whether I want to focus on diagnosing issues on a
> > > > consistent base or discovering issues on shifting sand.
> > > >
> > > > If I know that snapshots will only ever be published once a week
> then I
> > > > can
> > > > leave the update policy at the default of daily because I'll need to
> > > > rebuild my mental context on the next week anyway and it's only the
> > first
> > > > build on Monday's that will have the time kill.
> > > >
> > > > So the thing that we need to do is decide if we want to change our
> > > > policy,
> > > > if yes, then decide what we want to change it to *and* both implement
> > it
> > > > consistently and publish it clearly.
> > > >
> > > > Finally we have the ASF legal requirements that mean we need to
> clarify
> > > > to
> > > > all that -SNAPSHOTs are not actually releases and are only made
> > available
> > > > for validation prior to VOTE threads... because currently -SNAPSHOTs
> > are
> > > > rare this is not a big issue... if we have the CI pushing -SNAPSHOTs
> > at a
> > > > regular cadence the risk of *users* starting to use -SNAPSHOTs as
> > > > releases
> > > > rises so we would need to find ways to mitigate such risks
> > > >
> > > >
> > > >>
> > > >> Cheers,
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
-- 
Sent from my phone

Re: Are snapshots available in some Maven repo?

[Olivier Lamy]

We already had this discussion so many times and it always turns to non
ended complicated discussion with very complicated cases which NEVER happen
here
So the most important is: We must take it easy and avoid overthinking!.
+1 for every night a master snapshot or every master changes.
but please keep it simple


On Fri, 11 Jan 2019 at 06:34, Dan Tran  wrote:

> how about just deploy nightly snapshot of active 'main' branch ( ie
> master)?
>
> -D
>
>
> On Thu, Jan 10, 2019 at 9:03 AM Robert Scholte 
> wrote:
>
> > Now that we use branches actively, it is way more important where a
> > SNAPSHOT is coming from.
> > I've seen it too often that people thought they were testing with a
> > version from a specific branch, but that it was redeployed with another
> > version.
> > The first steps are done to rewrite the pom-file during publication, and
> > that might be exactly what we need here: when we're on a branch, the
> > branchname should be added to the version.
> > Call it work in progress for better support.
> >
> > thanks,
> > Robert
> >
> > On Thu, 10 Jan 2019 10:50:57 +0100, Stephen Connolly
> >  wrote:
> >
> > > On Thu, 10 Jan 2019 at 09:11, Mickael Istria 
> wrote:
> > >
> > >> Hi,
> > >>
> > >> Eclipse m2e, as a consumer of Maven as a library, would love to see
> the
> > >> latest HEAD from master published automatically as SNAPSHOTs soon
> after
> > >> every change is made. This seems like a requirement to enable
> continuous
> > >> feedback from m2e to Maven.
> > >> Publishing some other branches or commits doesn't seem interesting to
> > >> Eclipse m2e at the moment.
> > >>
> > >
> > > My point is that we need a clearly defined policy as to exactly what
> > > branch(es) are automatically pushed and when.
> > >
> > > That policy could be *one* of:
> > > * "master" if there are SCM changes detected on Sunday at 00:00 UTC
> > > * "master" if there are SCM changes detected at 00:00 UTC
> > > * "master" as soon as SCM changes are detected
> > > * "integration" as soon as SCM changes are detected
> > > * etc
> > >
> > > We just need to be crystal clear exactly what policy we are following.
> > > Right now the policy we are following is:
> > >
> > > * Manually from whatever branch is appropriate and only when there is a
> > > request for them to be published.
> > >
> > > There are good and valid reasons for any of these policies (or indeed
> > > other
> > > alternative policies). The problems occur if you try to mix policy.
> > >
> > > For example, if I as a developer know that snapshots could be published
> > > at
> > > any time then I can choose between `always` and `never` as the update
> > > policy depending on whether I want to focus on diagnosing issues on a
> > > consistent base or discovering issues on shifting sand.
> > >
> > > If I know that snapshots will only ever be published once a week then I
> > > can
> > > leave the update policy at the default of daily because I'll need to
> > > rebuild my mental context on the next week anyway and it's only the
> first
> > > build on Monday's that will have the time kill.
> > >
> > > So the thing that we need to do is decide if we want to change our
> > > policy,
> > > if yes, then decide what we want to change it to *and* both implement
> it
> > > consistently and publish it clearly.
> > >
> > > Finally we have the ASF legal requirements that mean we need to clarify
> > > to
> > > all that -SNAPSHOTs are not actually releases and are only made
> available
> > > for validation prior to VOTE threads... because currently -SNAPSHOTs
> are
> > > rare this is not a big issue... if we have the CI pushing -SNAPSHOTs
> at a
> > > regular cadence the risk of *users* starting to use -SNAPSHOTs as
> > > releases
> > > rises so we would need to find ways to mitigate such risks
> > >
> > >
> > >>
> > >> Cheers,
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>


-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Re: Update versions of all plugins in default-bindings.xml

[Enrico Olivelli]

+1 for upgrading all of the plugins
+1 for 3.7.0

Many plugins released recently have improvements in speed and jdk support
Having a new release with all greatest and latest versions will be
very appreciated by users

Enrico

Il giorno gio 10 gen 2019 alle ore 20:50 Stephen Connolly
 ha scritto:
>
> No reason that we cannot call the next release 3.7.0 and include the bump,
> mind you
>
> On Thu 10 Jan 2019 at 16:31, Anders Hammar  wrote:
>
> > IMHO it shouldn't be done in a patch release, but rather a minor release
> > (3.7.0).
> >
> > /Anders (mobile)
> >
> > Den tors 10 jan. 2019 17:09 skrev Tibor Digana :
> >
> > > Why we use old versions in default-bindings.xml?
> > > Can we update all versions in 3.6.1 release?
> > >
> > > Here is MNG-6557 which is related to Surefire but I guess this Jira issue
> > > can be freely related to all plugins.
> > >
> > > WDYT?
> > > Any objections to update all plugins and assign this issue in 3.6.1?
> > >
> > > Cheers
> > > Tibor
> > >
> >
> --
> Sent from my phone

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Update versions of all plugins in default-bindings.xml

[Stephen Connolly]

No reason that we cannot call the next release 3.7.0 and include the bump,
mind you

On Thu 10 Jan 2019 at 16:31, Anders Hammar  wrote:

> IMHO it shouldn't be done in a patch release, but rather a minor release
> (3.7.0).
>
> /Anders (mobile)
>
> Den tors 10 jan. 2019 17:09 skrev Tibor Digana :
>
> > Why we use old versions in default-bindings.xml?
> > Can we update all versions in 3.6.1 release?
> >
> > Here is MNG-6557 which is related to Surefire but I guess this Jira issue
> > can be freely related to all plugins.
> >
> > WDYT?
> > Any objections to update all plugins and assign this issue in 3.6.1?
> >
> > Cheers
> > Tibor
> >
>
-- 
Sent from my phone

Re: Enable Travis on Maven Scripting Plugin

[Enrico Olivelli]

I would like to enable Travis on other plugins, maybe I can do it on
plugins which have active prs

Okay?
Enrico

Il lun 7 gen 2019, 02:46 Manfred Moser  ha
scritto:

> Fair enough. If its just for outside contributor PRs I am agree with not
> owning the risk ;-)
>
> Stephen Connolly wrote on 2019-01-04 16:06:
>
> > On Fri 4 Jan 2019 at 22:00, Tibor Digana  wrote:
> >
> >> @Stephen Connolly 
> >>  After such a big investment, especially made on your side, in Jenkins
> >> plugin you developed you do not want to support the GitHub PRs and you
> just
> >> let be to go with TravisCI just like that? I do not think so!
> >
> >
> > I want to add GitHub support to ASF Jenkins too, but PR verification
> should
> > be layers. No harm in having one layer provided by Travis/Codeship/etc
> and
> > the second layer by Jenkins.
> >
> > The other point is even if I add PR support to the ASF Jenkins, it’s not
> > going to be automatic build for non-committers (which is the group of PRs
> > that need the CI feedback most, and with least delay... ie before they
> walk
> > away) as we simply do not have throw-away infra for building PRs that
> could
> > contain bitcoin miners triggered by a unit test, etc.
> >
> > Now if infra wants to set up a dedicated “safe space” for untrusted PRs
> to
> > be built... super... but until that happens, we’ll need something like
> > Travis to take that risk for us.
> >
> >
> >> T
> >>
> >>
> >> On Fri, Jan 4, 2019 at 7:22 PM Stephen Connolly <
> >> stephen.alan.conno...@gmail.com> wrote:
> >>
> >> > +1 from me
> >> >
> >> > On Fri 4 Jan 2019 at 18:21, Enrico Olivelli 
> wrote:
> >> >
> >> > > Hi,
> >> > > I would like to try out Travis on this small plugin:
> >> > > https://github.com/apache/maven-scripting-plugin
> >> > >
> >> > > I have pushed a minimal configuration file
> >> > > I need to ask to Infra, but I need approval from the community and
> >> > PMCs...
> >> > >
> >> > > Can I proceed ?
> >> > >
> >> > > Enrico
> >> > >
> >> > >
> -
> >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >> > >
> >> > > --
> >> > Sent from my phone
> >> >
> >>
> > --
> > Sent from my phone
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --


-- Enrico Olivelli

Re: Create JIRA project for Maven Scripting Plugin

[Enrico Olivelli]

Ping

Il dom 6 gen 2019, 13:27 Robert Scholte  ha scritto:

> Brian,
>
> can you pick this up?
>
> thanks,
> Robert
>
> On Sat, 05 Jan 2019 12:11:41 +0100, Enrico Olivelli 
>
> wrote:
>
> > Can any admin create this project ?
> > for Maven Scripting Plugin
> > https://issues.apache.org/jira/browse/MSCRIPTING
> >
> > Regards
> >
> > Enrico
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
-- 


-- Enrico Olivelli

Re: Are snapshots available in some Maven repo?

[Dan Tran]

how about just deploy nightly snapshot of active 'main' branch ( ie master)?

-D


On Thu, Jan 10, 2019 at 9:03 AM Robert Scholte  wrote:

> Now that we use branches actively, it is way more important where a
> SNAPSHOT is coming from.
> I've seen it too often that people thought they were testing with a
> version from a specific branch, but that it was redeployed with another
> version.
> The first steps are done to rewrite the pom-file during publication, and
> that might be exactly what we need here: when we're on a branch, the
> branchname should be added to the version.
> Call it work in progress for better support.
>
> thanks,
> Robert
>
> On Thu, 10 Jan 2019 10:50:57 +0100, Stephen Connolly
>  wrote:
>
> > On Thu, 10 Jan 2019 at 09:11, Mickael Istria  wrote:
> >
> >> Hi,
> >>
> >> Eclipse m2e, as a consumer of Maven as a library, would love to see the
> >> latest HEAD from master published automatically as SNAPSHOTs soon after
> >> every change is made. This seems like a requirement to enable continuous
> >> feedback from m2e to Maven.
> >> Publishing some other branches or commits doesn't seem interesting to
> >> Eclipse m2e at the moment.
> >>
> >
> > My point is that we need a clearly defined policy as to exactly what
> > branch(es) are automatically pushed and when.
> >
> > That policy could be *one* of:
> > * "master" if there are SCM changes detected on Sunday at 00:00 UTC
> > * "master" if there are SCM changes detected at 00:00 UTC
> > * "master" as soon as SCM changes are detected
> > * "integration" as soon as SCM changes are detected
> > * etc
> >
> > We just need to be crystal clear exactly what policy we are following.
> > Right now the policy we are following is:
> >
> > * Manually from whatever branch is appropriate and only when there is a
> > request for them to be published.
> >
> > There are good and valid reasons for any of these policies (or indeed
> > other
> > alternative policies). The problems occur if you try to mix policy.
> >
> > For example, if I as a developer know that snapshots could be published
> > at
> > any time then I can choose between `always` and `never` as the update
> > policy depending on whether I want to focus on diagnosing issues on a
> > consistent base or discovering issues on shifting sand.
> >
> > If I know that snapshots will only ever be published once a week then I
> > can
> > leave the update policy at the default of daily because I'll need to
> > rebuild my mental context on the next week anyway and it's only the first
> > build on Monday's that will have the time kill.
> >
> > So the thing that we need to do is decide if we want to change our
> > policy,
> > if yes, then decide what we want to change it to *and* both implement it
> > consistently and publish it clearly.
> >
> > Finally we have the ASF legal requirements that mean we need to clarify
> > to
> > all that -SNAPSHOTs are not actually releases and are only made available
> > for validation prior to VOTE threads... because currently -SNAPSHOTs are
> > rare this is not a big issue... if we have the CI pushing -SNAPSHOTs at a
> > regular cadence the risk of *users* starting to use -SNAPSHOTs as
> > releases
> > rises so we would need to find ways to mitigate such risks
> >
> >
> >>
> >> Cheers,
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Are snapshots available in some Maven repo?

[Robert Scholte]

Now that we use branches actively, it is way more important where a  
SNAPSHOT is coming from.
I've seen it too often that people thought they were testing with a  
version from a specific branch, but that it was redeployed with another  
version.
The first steps are done to rewrite the pom-file during publication, and  
that might be exactly what we need here: when we're on a branch, the  
branchname should be added to the version.

Call it work in progress for better support.

thanks,
Robert

On Thu, 10 Jan 2019 10:50:57 +0100, Stephen Connolly  
 wrote:



On Thu, 10 Jan 2019 at 09:11, Mickael Istria  wrote:


Hi,

Eclipse m2e, as a consumer of Maven as a library, would love to see the
latest HEAD from master published automatically as SNAPSHOTs soon after
every change is made. This seems like a requirement to enable continuous
feedback from m2e to Maven.
Publishing some other branches or commits doesn't seem interesting to
Eclipse m2e at the moment.



My point is that we need a clearly defined policy as to exactly what
branch(es) are automatically pushed and when.

That policy could be *one* of:
* "master" if there are SCM changes detected on Sunday at 00:00 UTC
* "master" if there are SCM changes detected at 00:00 UTC
* "master" as soon as SCM changes are detected
* "integration" as soon as SCM changes are detected
* etc

We just need to be crystal clear exactly what policy we are following.
Right now the policy we are following is:

* Manually from whatever branch is appropriate and only when there is a
request for them to be published.

There are good and valid reasons for any of these policies (or indeed  
other

alternative policies). The problems occur if you try to mix policy.

For example, if I as a developer know that snapshots could be published  
at

any time then I can choose between `always` and `never` as the update
policy depending on whether I want to focus on diagnosing issues on a
consistent base or discovering issues on shifting sand.

If I know that snapshots will only ever be published once a week then I  
can

leave the update policy at the default of daily because I'll need to
rebuild my mental context on the next week anyway and it's only the first
build on Monday's that will have the time kill.

So the thing that we need to do is decide if we want to change our  
policy,

if yes, then decide what we want to change it to *and* both implement it
consistently and publish it clearly.

Finally we have the ASF legal requirements that mean we need to clarify  
to

all that -SNAPSHOTs are not actually releases and are only made available
for validation prior to VOTE threads... because currently -SNAPSHOTs are
rare this is not a big issue... if we have the CI pushing -SNAPSHOTs at a
regular cadence the risk of *users* starting to use -SNAPSHOTs as  
releases

rises so we would need to find ways to mitigate such risks




Cheers,


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Update versions of all plugins in default-bindings.xml

[Anders Hammar]

IMHO it shouldn't be done in a patch release, but rather a minor release
(3.7.0).

/Anders (mobile)

Den tors 10 jan. 2019 17:09 skrev Tibor Digana :

> Why we use old versions in default-bindings.xml?
> Can we update all versions in 3.6.1 release?
>
> Here is MNG-6557 which is related to Surefire but I guess this Jira issue
> can be freely related to all plugins.
>
> WDYT?
> Any objections to update all plugins and assign this issue in 3.6.1?
>
> Cheers
> Tibor
>

Update versions of all plugins in default-bindings.xml

[Tibor Digana]

Why we use old versions in default-bindings.xml?
Can we update all versions in 3.6.1 release?

Here is MNG-6557 which is related to Surefire but I guess this Jira issue
can be freely related to all plugins.

WDYT?
Any objections to update all plugins and assign this issue in 3.6.1?

Cheers
Tibor

Re: Are snapshots available in some Maven repo?

[Stephen Connolly]

On Thu, 10 Jan 2019 at 09:11, Mickael Istria  wrote:

> Hi,
>
> Eclipse m2e, as a consumer of Maven as a library, would love to see the
> latest HEAD from master published automatically as SNAPSHOTs soon after
> every change is made. This seems like a requirement to enable continuous
> feedback from m2e to Maven.
> Publishing some other branches or commits doesn't seem interesting to
> Eclipse m2e at the moment.
>

My point is that we need a clearly defined policy as to exactly what
branch(es) are automatically pushed and when.

That policy could be *one* of:
* "master" if there are SCM changes detected on Sunday at 00:00 UTC
* "master" if there are SCM changes detected at 00:00 UTC
* "master" as soon as SCM changes are detected
* "integration" as soon as SCM changes are detected
* etc

We just need to be crystal clear exactly what policy we are following.
Right now the policy we are following is:

* Manually from whatever branch is appropriate and only when there is a
request for them to be published.

There are good and valid reasons for any of these policies (or indeed other
alternative policies). The problems occur if you try to mix policy.

For example, if I as a developer know that snapshots could be published at
any time then I can choose between `always` and `never` as the update
policy depending on whether I want to focus on diagnosing issues on a
consistent base or discovering issues on shifting sand.

If I know that snapshots will only ever be published once a week then I can
leave the update policy at the default of daily because I'll need to
rebuild my mental context on the next week anyway and it's only the first
build on Monday's that will have the time kill.

So the thing that we need to do is decide if we want to change our policy,
if yes, then decide what we want to change it to *and* both implement it
consistently and publish it clearly.

Finally we have the ASF legal requirements that mean we need to clarify to
all that -SNAPSHOTs are not actually releases and are only made available
for validation prior to VOTE threads... because currently -SNAPSHOTs are
rare this is not a big issue... if we have the CI pushing -SNAPSHOTs at a
regular cadence the risk of *users* starting to use -SNAPSHOTs as releases
rises so we would need to find ways to mitigate such risks


>
> Cheers,
>

Re: Are snapshots available in some Maven repo?

[Mickael Istria]

Hi,

Eclipse m2e, as a consumer of Maven as a library, would love to see the
latest HEAD from master published automatically as SNAPSHOTs soon after
every change is made. This seems like a requirement to enable continuous
feedback from m2e to Maven.
Publishing some other branches or commits doesn't seem interesting to
Eclipse m2e at the moment.

Cheers,

Re: How much m2e test suites cover of Maven ?

[Mickael Istria]

Hi all,

Final update about m2e coverage of Maven project: the full test suite now
reports coverage and reports are still visible at
https://sonarcloud.io/component_measures?id=m2e-covering-maven=coverage
. This can help to identify, by comparing it with plain Maven coverage
reports, which area of Maven code are not covered by what's used in IDE,
and to find out some tests to add in order to improve the coverage of
IDE-related parts and reduce risk of migration in IDEs.

One more comment about previous discussion

> how can we verify that Maven changes are still compatible with IDEs?
[...] Hence we are still looking for a way to verify these changes and
their effects on IDEs.

Automatically providing SNAPSHOTs (as another thread is discussing) would
allow m2e to continuously build+test against those snapshots (on a Gerrit
branch like https://git.eclipse.org/r/#/c/133590/ ) and identify some
issues as soon as they're in the snapshots. Additionally to making m2e more
able to provide feedback against development branch, it also facilitates
adoption of newer versions of Maven by m2e since we can work on it more
progressively.

Cheers

Re: Are snapshots available in some Maven repo?

[Stephen Connolly]

The question is more what our policy is.

In my opinion you need one of two policies:

* snapshots are deployed manually
* snapshots are deployed automatically from a specific branch

We have used manual as our policy. If we change that’s fine, but we should
stop manual deployment and clarify the deployment frequency so that people
can set their update policy in their settings.xml appropriately.

A vote would be required imho... and a discuss beforehand.

On Thu 10 Jan 2019 at 06:18, Enrico Olivelli  wrote:

> We should only have to setup a CI job which does
> mvn deploy
>
> AFAIK ASF Jenkins are allowed to push snapshots
>
> Enrico
>
> Il gio 10 gen 2019, 00:34 Mickael Istria  ha scritto:
>
> > On Wednesday, January 9, 2019, Robert Scholte 
> > wrote:
> >
> > > I've just deployed the SNAPSHOTs from current master to
> > > repository.apache.org
> > >
> >
> > Thanks a lot! Could it be done continuously? Technicallu, a CI
> job.checking
> > the repo could tale care of doing it soon after each change without
> further
> > human effort.
> >
> >
> > --
> > Mickael Istria
> > Eclipse IDE 
> > developer, for Red Hat Developers 
> >
> --
>
>
> -- Enrico Olivelli
>
-- 
Sent from my phone