Re: [Maven 4] Collapsing mvnDebug into mvn

[Stephen Connolly]

I’m fine with a breaking change.

I also think batch mode debugging is a special case, we could go with

—batch-debug

If you really want to debug batch mode and that way —debug can be
incompatible with —batch and then we don’t worry about it

On Sat 31 Jul 2021 at 16:06, Michael Osipov  wrote:

> Well, I have just tried.
>
> Not providing a timeout is just like providing timeout=0. The socket
> will wait forever.
> If your provide a timeout and don't connect after a timeout, this will
> happen:
> > Listening for transport dt_socket at address: 8000
> > ERROR: transport error 203: timed out waiting for connection
> > JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal
> error [transport.c:326]
> >
> > D:\Entwicklung\Projekte\maven-integration-testing>if ERRORLEVEL 1 goto
> error
>
> So our timeout idea does not work.
> We need another idea or accept the breaking change if we want to
> repurpose --debug.
>
> M
>
>
> Am 2021-07-31 um 16:32 schrieb Robert Scholte:
> > CI can have multiple Maven versions.
> > Mistakes will happen: users might add --debug assuming verbose logging.
> > With an Environment Variable the CI server can globally suppress the
> option to debug.
> > I'm also fine with a NO_DEBUG option, but I'd like to have a global way
> to suppress the impact.
> >
> > Robert
> >
> >
> > On 31-7-2021 16:08:36, Michael Osipov  wrote:
> > Am 2021-07-31 um 11:22 schrieb Robert Scholte:
> >> Right, it is suspend, I misinterpreted the description of server.
> >>
> >> Can we introduce an environment variable for it, so CI servers can set
> it to 0?
> >
> > Let me summarize:
> > If --debug is passed everything will work as before: wait forever
> > If --debug --batch-mode is passed the VM will wait for at most 30 s.
> > This value can be modified by a new environment variable.
> >
> > Question: Why would a CI system set this to 0 if it is not going to
> > debug the process?
> >
> > M
> >
> >> Robert
> >> On 30-7-2021 21:46:46, Michael Osipov wrote:
> >> I guess you mean suspend and not server.
> >> Your idea may work, but still is problematic. If the breakpoint is quite
> >> early you will miss in your IDE and then you need to start over.
> >> I think -B and --debug are special cases and I believe that a timeout is
> >> acceptible since the build is halted, but more importantly will continue
> >> *automatically* after it. Just like waiting for a network resource which
> >> might be slow.
> >>
> >> M
> >>
> >> Am 2021-07-30 um 18:31 schrieb Robert Scholte:
> >>> I wonder if this is a realistic issue. In the cases I know with the
> batch-mode the interactive part is skipped and code falls back to defaults.
> >>> If there are issues, they're more much likely to happen in the
> interactive mode.
> >>> Maybe a more reasonable solution is to use server="n" (default) for
> batch mode, server="y" for interactive mode: no delay in batchmode and
> still the option to attach a remote debugger.
> >>>
> >>> thanks,
> >>> Robert
> >>>
> >>>
> >>> On 30-7-2021 16:56:15, Michael Osipov wrote:
> >>> Am 2021-07-30 um 14:31 schrieb Stephen Connolly:
> >>>> So now I cannot debug Maven issues that happen when running in batch
> mode?
> >>>> We should document that specific case uses MAVEN_OPTS
> >>>
> >>> Not now, nothing has been committed/merged yet. This is just a PoC.
> >>> Robert and me thought about this. We could add an environment var which
> >>> circumvents the batch mode if you really want to debug in batch mode.
> An
> >>> alternative would be if you running in batch mode runjdwp would receive
> >>> a timeout value in milliseconds to wait for a debugger to attach. Say
> 30
> >>> 000 ms and then the process will continue. In interactive mode, the JVM
> >>> will wait forever.
> >>> See here:
> >>>
> https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/conninv.html#Invocation
> >>>
> >>> WDYT?
> >>>
> >>>> On Tue 27 Jul 2021 at 16:01, Michael Osipov wrote:
> >>>>
> >>>>> So you say that -B will implicitly disable --debug without any
> further
> >>>>> notice?
> >>>>>
> >>>>> I logically agree that batch contradicts debug which requires
> >>>>> interaction with the suspen

Re: [Maven 4] Collapsing mvnDebug into mvn

[Stephen Connolly]

So now I cannot debug Maven issues that happen when running in batch mode?
We should document that specific case uses MAVEN_OPTS

On Tue 27 Jul 2021 at 16:01, Michael Osipov  wrote:

> So you say that -B will implicitly disable --debug without any further
> notice?
>
> I logically agree that batch contradicts debug which requires
> interaction with the suspended VM. Both does not make sense.
>
> Note: Colors are easier now. They now work just like people are used
> with grep --color...
>
> Am 2021-07-27 um 16:27 schrieb Robert Scholte:
> > batch mode means no interaction, but the debug-flag is an interaction
> (java process is waiting for input).
> > So it doesn't make sense to have both activated.
> > This will prevent CI jobs to hang when using --debug (if they assume
> this means logging at debug level)
> > batch implies disabling colours, but if you *only* want to disable
> colors, you should use -Dstyle.color=never
> >
> > Robert
> > On 27-7-2021 13:56:45, Michael Osipov  wrote:
> > OK, let me sum up what you are proposing:
> >
> > Am 2021-07-27 um 12:39 schrieb Robert Scholte:
> >> I actually like the idea of renaming --debug/-X to --verbose/-X and
> we're actually lucky.
> >> When renaming we can add a message that --debug for logging at debug
> level has been renamed to --verbose.
> >
> > A preceding commit will rename --debug to verbose. This PR will reuse
> > --debug instead of -dj/--debug-java. I assume that most do -X and not
> > --debug, but that's a wild guess.
> >
> >> Due to the nature of debugging (waiting until remote debugger is
> attached) the message will be visible so users can easily kill the running
> process and restart Maven with the new command.
> >> In case of batch-mode as done by CI servers I think we can ignore the
> --debug-flag, so if they were using the --debug flag, they'll just get less
> logging.
> >
> > Here you expect that -B and --debug (new) are mutually exclusive? I
> > don't know how likely it is, but maybe someone whats to debug w/o
> > colors, send to file or omit the progress.
> > Is that what you have in mind?
> >
> > M
> >
> >> On 26-7-2021 21:00:26, Michael Osipov wrote:
> >> Hi folks,
> >>
> >> I was recently working on MNG-7075 and while the solution is straight
> >> forward [1], it just feels awkward. For a long time I had the idea that
> >> the mvnDebug script can be completely collapsed into mvn with a single
> >> switch.
> >> Therefore, I have created a draft PR [2] which works in the Windows
> >> command prompt and the Bourne shell. It completely obsoletes MNG-7075,
> >> mvnDebug and a nice bonus: When mvnDebug is run, output still refers to
> >> 'mvn', e.g., 'mvn -r ' this is inconsistent until now, but will be
> >> consistent in the future. mvnDebug would remain as-is, but would emit a
> >> warning that it is deprecated.
> >> mvnDebug is used ony by Maven developers like us and of course
> >> extension/plugin devs. The majory are just users which don't care.
> >>
> >> Note: I am not happy with -dj, but wasn't able to come up with something
> >> better for the moment. I would prefer --debug to be renamed to --verbose
> >> and --debug to be recycled as Java debug mode, but that is likely
> >> impossible, I guess.
> >>
> >> WDYT?
> >>
> >> Michael
> >>
> >> [1] https://github.com/apache/maven/pull/515
> >> [2] https://github.com/apache/maven/pull/517
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Stephen Connolly]

3.8.1 as we already burned and accidentally released 3.8.0

Though if we could go back in time to before the vote was started, it
should have been 3.6.4 IMO... but since the release manager went with
3.8.0, that’s the train we’re on

FTR the release manager’s decision on version number has always been final
in my mind (obviously consulting the community is better for fostering the
community, but in my book the version number is not for voting... the
release manager picks the number and then the vote is called)

On Sun 28 Mar 2021 at 10:47, Romain Manni-Bucau 
wrote:

> Hi all,
>
> Before we reroll the failed 3.8.0 I'd like we discuss openly the next
> versioning since it seems we didn't reach a consensus yet and trying to not
> create too much friction for users and in the community.
>
> As a reminder the only feature the release will get is to prevent HTTP repo
> (in favor of HTTPS ones). In that regard it is a breaking change if users
> rely on HTTP repo but a security fix (I don't come back on the HTTP ->
> HTTPS move IT ecosystem got recently here).
>
> So it seems there are multiple versioning options:
>
> 1. 3.6.4: seems natural since it is a security fix, enables companies to
> get this fix respecting a project versioning policy without having to
> upgrade and avoids us to have to maintain 3.6 + 3.7/3.8 and soon 4.x.
> Indeed it requires a very well documented paragraph about this change and
> how to workaround it (local proxy/mirror is a trivial one for example) but
> it will be the case whatever version we pick anyway IMHO.
> 2. 3.7.0: since it is a breaking change it can seem natural too (but has
> the pitfall to likely require a backport in 3.6 anyway, due to the
> versioning policies which can prevent some users to upgrade to a 3.7)
> 3. 3.8.0: was the vote, seems the rational was that originally we
> targetting mvnw in 3.7 and since we didn't make it 3.8 was used. Have to
> admit I'm not sure of this reasoning more than that (cause for me if we
> don't have a planned feature we can either try to push/wait for it or
> postpone it but not skip a version due to that) so if anyone wants to
> complete the reasoning here it would be great.
>
> Indeed my preference is for 3.6.4 which has the most advantages for
> everyone and no additional drawbacks compared to 3.7 or 3.8 options until
> we try to push to get mvnw in which would mean 3.7 becomes more natural
> (and likely imply a 3.6.x maintenance version).
>
> Goal of this thread is to feel the overall trend and see if we can refine
> the proposals (for example: can we drop 3.8 one and only keep 3.7 and 3.6
> or - best - can we refine it to a single version after some exchanges).
> If we keep a few proposals after some days, what about a vote where the
> majority wins - we would just need to define how we count,
> bindings/committers/all (my preference being last one indeed)?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
-- 
Sent from my phone

Re: Artifact installation and versions

[Stephen Connolly]

So there’s a setting for the repo which allows controlling whether to
deploy plain snapshot or timestamp snapshots

https://maven.apache.org/pom.html#repository

Specifically `uniqueVersion`

IIRC there was a deliberate break of that to always be true in Maven 3.0.x
for reasons that only Benjamin knew, and I doubt we could entice him back
to explain.

It may be the case that we restored the behaviour in 3.1.x or it could be
that it was an actual bug introduced in 3.0.x and then fixed for 3.1.x or
maybe I’m imagining things and the two poms you’re comparing have a
different uniqueVersion value

HTH

On Tue 7 Jul 2020 at 17:13, Anders Hammar  wrote:

> My understanding is that it's "SNAPSHOT" when installing to the local repo
> but a snapshot version when deploying to a remote repo. But a rarely look
> in the local repo so I could be wrong.
>
> /Anders (mobile)
>
> Den tis 7 juli 2020 13:08Elliotte Rusty Harold  skrev:
>
> > Let me correct that. On further investigation it seems the Maven 3.1
> > artifact installer writes
> >
> > expanded-snapshot-2.0-SNAPSHOT.jar
> >
> > whereas the Maven30Installer would write
> >
> > expanded-snapshot-2.0-20130710.122148-1.pom
> >
> > Is this working as intended?
> >
> > On Mon, Jul 6, 2020 at 5:05 PM Elliotte Rusty Harold  >
> > wrote:
> > >
> > > This is a long shot, but does anyone happen to know whether anything
> > > changed with respect to pom installation between Maven 3.0 and 3.1? In
> > > particular, I'm seeing in a test of the copy dependencies Mojo that
> > >
> > > expanded-snapshot-2.0.pom
> > >
> > > is written into the expected location but
> > >
> > > expanded-snapshot-2.0-20130710.122148-1.pom
> > >
> > > is not. Does this ring any bells with anyone? Is there any chance
> > > we're deliberately no longer writing snapshot versions into the local
> > > repository?
> > >
> > > Context: https://github.com/apache/maven-dependency-plugin/pull/78/
> > >
> > >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elh...@ibiblio.org
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
-- 
Sent from my phone

Re: Maven moving to the next level: the build/consumer pom

[Stephen Connolly]

On Mon 6 Jul 2020 at 17:48, Hervé BOUTEMY  wrote:

> Le lundi 6 juillet 2020, 11:33:05 CEST Mark Derricutt a écrit :
> > Hervé,
> >
> > If you configure IntelliJ (projecting much Mark?) to use Maven
> > 3.7.0-SNAPSHOT as it’s maven version, does that work?
> keeping internal Maven version was giving an impression of working,
> probably
> due to cache given updates in parent pom version were not reflected
> updating to 3.7.0-SNAPSHOT just made the import fail...
>
> honestly, given the new pom.xml was an invalid pom.xml with previous
> version,
> I doubt any IDE will work with the new pom.xml without some rework


AIUI netbeans might. But eclipse will not and IntelliJ most certainly will
not as it doesn’t even use Maven to parse the model and is consequently
completely unaware of custom packaging types producing classpath relevant
artifact’s.


>
> Regards,
>
> Hervé
>
> >
> > I tend to configure my IJ to use my built SNAPSHOT when testing out Maven
> > releases.
> >
> > Mark
> >
> > On 6 July 2020 at 8:21:57 PM, Hervé BOUTEMY (herve.bout...@free.fr)
> wrote:
> >
> > What is expected is IDE maintainers to check what they need to do at IDE
> > level to support these new POMs that only build with Maven
> 3.7.0-SNAPSHOT.
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: custom default lifecycle per project

[Stephen Connolly]

On Sat 4 Jul 2020 at 16:54, Romain Manni-Bucau 
wrote:

> Le sam. 4 juil. 2020 à 16:38, Stephen Connolly <
> stephen.alan.conno...@gmail.com> a écrit :
>
> > On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau 
> > wrote:
> >
> > > Well, there are two points I'd like to emphasis:
> > >
> > > 1. I dont think we should wait for 2 majors to get that as a feature,
> > would
> > > be too late IMHO
> >
> >
> > Well does my dynamic phases PR do what you need?
> >
>
> Partly if you think to priority one, it moves the issue a bit further due
> to priority usage which is not great in practice compare to names +
> requires to use 100, 200 etc to be able to inject plugin between two others
> in children with the project becoming more complex. Think we must have an
> explicit control here even with complex hierarchies.


If you need that much control then you’re doing something wrong.

How often do you need more than 3-4 plugin executions in strict ordered
succession?

That sounds like a dedicated plugin use case

>
>
>
> >
> > > 2. Pom model is based on inheritance whereas years showed composition
> and
> > > reuse is saner so IMHO it does not belong to pom but .mvn
> >
> >
> > Your proposal would only work if all projects shared the same packaging
> as
> > Hervé pointed out that the lifecycle is pulled in based on packaging.
> >
>
> No cause you define the packaging to use in  the pom already - since maven
> 2 IIRC - so you can define as much packagings as you want in .mvn. To be
> concrete, it just enables to have an exploded extension in the project
> instead of requiring it to be packaged as a jar. Does not reinvent the
> wheel ;).
>
>
> > What you probably want is .mvn/${packaging}/lifecycle.xml so you can
> > override custom
> >
> > A bug you may encounter is where phase names are not common across the
> > reactor
> >
>
> Yep, build/extension must enforce common checkpoints (package, install,
> deploy out of my head) for all modules. Not a big deal if validated during
> initialize phase I think.
>
>
> >
> > >
> > > Le sam. 4 juil. 2020 à 10:19, Robert Scholte  a
> > > écrit :
> > >
> > > > Stephen had an idea for it in Model 5.0.0[1], and IIRC I still had my
> > > > concerns.
> > > > It is still a draft with a lot of ideas, that hasn't really been
> > > discussed
> > > > yet, because it was still out of reach.
> > > > However, we're getting closer
> > > >
> > > > Robert
> > > >
> > > >
> > > > [1]
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0#POMModelVersion5.0.0-%3Cproject%3Eelement
> > > > On 4-7-2020 09:03:08, Romain Manni-Bucau 
> > wrote:
> > > > I agree I mixed both in my explanationcause they only make sense
> > > > together for a build as shown by the pre/post recurrent request which
> > > aims
> > > > to enrich the lifecycle to bind custom plugins.
> > > >
> > > > Today projects are no more just about creating a jar - war are no
> more
> > > > about java etc... - most of the time (frontend, living doc, build
> time
> > > > generation, security validation, ). Indeed you can force to bind
> > > > plugins to existing phases but it is quite hard, unatural and rarely
> > > > maintainable in time: whatever you do, you want a custom packaging
> > using
> > > a
> > > > custom lifecycle (to be able to run separately phases of the build -
> > and
> > > > sometimes independently, mvn frontend not depending of mvn package or
> > mvn
> > > > compile would be neat but not required for me).
> > > >
> > > > So the extension i have in mind will handle both or wouldnt be
> usable.
> > > >
> > > > About loosing the convention, after fighting for 7 years to not
> respect
> > > it,
> > > > I think the ecosystem changed and we must accept it as bazel and
> gradle
> > > do.
> > > > Does not mean we break ourself, we keep our default, it just means an
> > > > application must be able to redefining its own lifecycle+packaging
> > (which
> > > > is a pair named a build ;)).
> > > >
> > > > Think we can't stack plugin on a single phase anymore, having 5+
> > plugins
> > > on
> > > > pre-package is very hard to maintain and share in a team - p

Re: custom default lifecycle per project

[Stephen Connolly]

On Sat 4 Jul 2020 at 10:21, Romain Manni-Bucau 
wrote:

> Well, there are two points I'd like to emphasis:
>
> 1. I dont think we should wait for 2 majors to get that as a feature, would
> be too late IMHO


Well does my dynamic phases PR do what you need?


> 2. Pom model is based on inheritance whereas years showed composition and
> reuse is saner so IMHO it does not belong to pom but .mvn


Your proposal would only work if all projects shared the same packaging as
Hervé pointed out that the lifecycle is pulled in based on packaging.

What you probably want is .mvn/${packaging}/lifecycle.xml so you can
override custom

A bug you may encounter is where phase names are not common across the
reactor


>
> Le sam. 4 juil. 2020 à 10:19, Robert Scholte  a
> écrit :
>
> > Stephen had an idea for it in Model 5.0.0[1], and IIRC I still had my
> > concerns.
> > It is still a draft with a lot of ideas, that hasn't really been
> discussed
> > yet, because it was still out of reach.
> > However, we're getting closer
> >
> > Robert
> >
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0#POMModelVersion5.0.0-%3Cproject%3Eelement
> > On 4-7-2020 09:03:08, Romain Manni-Bucau  wrote:
> > I agree I mixed both in my explanationcause they only make sense
> > together for a build as shown by the pre/post recurrent request which
> aims
> > to enrich the lifecycle to bind custom plugins.
> >
> > Today projects are no more just about creating a jar - war are no more
> > about java etc... - most of the time (frontend, living doc, build time
> > generation, security validation, ). Indeed you can force to bind
> > plugins to existing phases but it is quite hard, unatural and rarely
> > maintainable in time: whatever you do, you want a custom packaging using
> a
> > custom lifecycle (to be able to run separately phases of the build - and
> > sometimes independently, mvn frontend not depending of mvn package or mvn
> > compile would be neat but not required for me).
> >
> > So the extension i have in mind will handle both or wouldnt be usable.
> >
> > About loosing the convention, after fighting for 7 years to not respect
> it,
> > I think the ecosystem changed and we must accept it as bazel and gradle
> do.
> > Does not mean we break ourself, we keep our default, it just means an
> > application must be able to redefining its own lifecycle+packaging (which
> > is a pair named a build ;)).
> >
> > Think we can't stack plugin on a single phase anymore, having 5+ plugins
> on
> > pre-package is very hard to maintain and share in a team - plus it doesnt
> > really makes sense on a build point of view.
> >
> > Indeed we can add phases as we have process classes after compile,
> > prepackage before package etc.. but it stays arbitrary for maven project
> > dev and does not reflect the agility projects take these days IMHO and if
> > done in our core delivery it would slow down most build for no gain so it
> > must be in user land IMHO.
> >
> > Hope it makes more sense presented this way.
> >
> >
> >
> > Le sam. 4 juil. 2020 à 05:28, Hervé BOUTEMY a
> > écrit :
> >
> > > first: thanks for sharing
> > >
> > > from a high level point of view, the risk I see is to loose our
> > > conventions.
> > > But let's try and see before judging
> > >
> > > I think there are 2 topics currently mixed:
> > > - default lifecycle phases:
> > > do you want to add or remove phases? [1]
> > > - default plugin bindings:
> > > clearly, you want to have specific default bindings. On default
> > > bindings, as
> > > they are defined per-packaging [2] (that's what is triggered behind
> > > packaging
> > > in pom.xml)
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > [1] https://maven.apache.org/ref/3.6.3/maven-core/lifecycles.html
> > >
> > > [2]
> https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html
> > >
> > > Le vendredi 3 juillet 2020, 09:20:25 CEST Romain Manni-Bucau a écrit :
> > > > Hi everyone,
> > > >
> > > > Wonder if we already discussed defining the lifecycle in the project
> > > (maybe
> > > > in $root/.mvn).
> > > > High level the need is to be able to change the default lifecycle in
> > the
> > > > root pom without having to define a custom extension - in other words
> > it
> > > is
> > > > about having a built-in extension.
> > > > The typical need is to add a mojo in the default lifecycle (add
> > frontend
> > > > magement for ex) or replace some plugins by others (for example
> > compiler
> > > by
> > > > scalac plugin, surefire by spec2 plugin for a scala based project
> > > etc...).
> > > > The way I'm seeing it is to let the xml defining the lifecycle be put
> > in
> > > > .mvn/default-lifecycle.xml - I don't know if we want to use the
> prefix
> > > > (default here) as a reference you can put in the pom but at least
> > default
> > > > makes sense IMO.
> > > > The lifecycle.xml itself would likely be extended to add some
> > > precondition
> > > > to each plugin (if 

Re: jenkins triggers

[Stephen Connolly]

Infra changed the hostname and url to subscribe to so the plugin is being
updated... until then you’re relying on polling every 8h or something like
that

On Thu 12 Mar 2020 at 20:37, Elliotte Rusty Harold 
wrote:

> Thanks. It did eventually kick off, but it certainly wasn't immediate,
> more like several hours.
>
> On Thu, Mar 12, 2020 at 3:26 PM Robert Scholte 
> wrote:
> >
> > It should happen immediately. If not, then you have some options:
> > - Log in on Jenkins and call "Scan Multibranch Pipeline Now" (or
> dedicated branch if it exists)
> > - Go to  https://selfserve.apache.org/ and select "Synchronize Git
> Repositories"
> >
> > Robert
> >
> >
> > On 12-3-2020 13:10:26, Elliotte Rusty Harold  wrote:
> > How does Jenkins decide whether/when to run tests on any particular
> > branch? I've pushed a number of commits to a branch this morning but
> > the last build it ran from that branch was about 11 hours ago.
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: More checkstyle API changes

[Stephen Connolly]

On Mon 23 Dec 2019 at 15:44, Benjamin Marwell  wrote:

> Furthermore,
>
> if we do not drop using that method, maven will throw an exception. Maven
> will, not checkstyle.
>
> I do not think that should be happening (from a user perspective).
>
> It's an easy fix for maven. As soon as the checkstyle Plugin required
> checkstyle 8.24 or higher, it the plugin should go to 4.x (new major
> version). Simple as that.


Let’s not bump any plugin to 4.x at this time. Better if we can hold that
version number for plugins using Maven 4 as a baseline

>
>
> I am even willing to implement a Checkstyle version check to explain the
> incompatibilities of checkstyle 8.24 and above. It's not much work and will
> be helpful to users. Seeing some error ("TreeeWalker  does not allow the
> subelement LineLength") is not helpful by itself. It's easy to document and
> easy to detect.
>
> Also, why not ask the checkstyle team to adapt semantic versioning? Asking
> doesn't cost anything afaik.
>
>
> On Mon, 23 Dec 2019, 15:35 Falko Modler,  wrote:
>
> > Hi Mark,
> >
> > > The maven-checkstyle-plugin is rather pretty much hardcoded to a
> > specific checkstyle version. While you _could_ technically exchange the
> > checkstyle dependency it is not really intended.
> >
> >
> > Are you sure it is not really intended? It is actually _documented_:
> >
> >
> https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/upgrading-checkstyle.html
> >
> > I've been using it this way for many years and I am sure many other
> > users have done the same.
> >
> > Best regards,
> >
> > Falko
> >
> >
> > Am 23.12.2019 um 12:57 schrieb Mark Struberg:
> > > But the main purpose is not to have multiple frameworks run with it.
> > That's the main difference to surefire.
> > >
> > > The maven-checkstyle-plugin is rather pretty much hardcoded to a
> > specific checkstyle version. While you _could_ technically exchange the
> > checkstyle dependency it is not really intended.
> > >
> > > The 'compatibility' layer is rather only important for the checkstyle
> > configuration. That part should really remain stable. If not, we have to
> up
> > to major version.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >> Am 23.12.2019 um 12:34 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com>:
> > >>
> > >> Point is it is the only way to not break end user since it gives us
> the
> > >> control of which version to select depending user config and java
> > version.
> > >> Which we dont ask any change to user im fine either ways though.
> > >>
> > >> Le lun. 23 déc. 2019 à 12:28, Benjamin Marwell  a
> > >> écrit :
> > >>
> > >>> I not think that would be a benefit, because removing the class
> loader
> > call
> > >>> will also work with older versions of checkstyle.
> > >>> Also, of the plugin is just a wrapper, why even bother to detect if
> the
> > >>> checkstyle.xml and checkstyle dependency will work together?
> > >>>
> > >>> Or am I missing something?
> > >>>
> > >>> On Mon, 23 Dec 2019, 09:32 Romain Manni-Bucau, <
> rmannibu...@gmail.com>
> > >>> wrote:
> > >>>
> >  What about loading checkstyle from a dependency resolver and use a
> > custom
> >  classloader with an integration per version (a bit like surefire).
> It
> >  enables to use any version and even detect an user override in
> plugin
> > >>> deps.
> >  Le lun. 23 déc. 2019 à 09:27, Benjamin Marwell 
> a
> >  écrit :
> > 
> > > Hi Enrico,
> > >
> > > that would mean a lot of incompatibilities which I wanted to avoid.
> > > If the checkstyle jar is updated first (8.xx), maven users wouldn't
> > be
> >  able
> > > to use a current version for quite a while, because the Maven
> plugin
> >  would
> > > throw NoSuchMethodExceptions. I wanted to avoid this.
> > >
> > > On the other hand, if the Maven plugin gets updated and released
> > first,
> > > there is more time for users to migrate to a more recent maven
> > plugin.
> > > Hence my PR.
> > >
> > > I really do not see the benefit of updating the checkstyle jar
> first
> > >>> and
> > > this having a period of time where Maven users cannot use a recent
> >  version
> > > of checkstyle at all.
> > >
> > > Maybe I did express the issue with checkstyle 8.24 in a wrong way.
> > >>> Users
> > > can already use it if they rewrite their checkstyle.xml. it's just
> > that
> >  the
> > > maven plugin should not update the default checkstyle version to
> not
> >  break
> > > any default setups and force users to rewrite their checks.
> > >
> > >
> > >
> > >
> > > On Mon, 23 Dec 2019, 08:45 Enrico Olivelli, 
> > >>> wrote:
> > >> Ben,
> > >> What about having a release of checkstyle with all of the
> requested
> > > changes
> > >> and then update maven plugin and then release it?
> > >> Checkstyle maven plugin is just a wrapper over checkstyle library.
> > >>
> > >> The best way would be 

Re: [RESULT] [VOTE] Release Apache Maven Source Plugin version 3.2.1

[Stephen Connolly]

Nope on PMC quorum, but here’s my +1 to make it legal

On Sat 21 Dec 2019 at 14:19, Hervé BOUTEMY  wrote:

> Hi,
>
> The vote has passed with the following result:
>
> +1 : Karl Heinz Marbaise, Mark Struberg, Hervé Boutemy
>
> PMC quorum reached
>
> I will promote the artifacts to the central repo.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: [VOTE] Release Apache Maven Source Plugin version 3.2.1

[Stephen Connolly]

On Tue 17 Dec 2019 at 08:14, Hervé BOUTEMY  wrote:

> I forgot to mention:
> notice that thanks to maven-release-plugin 3.0.0-M1, the
> project.build.outputTimestamp property was automatically updated 2 times
> during the release:
> - [1] during the release preparation phase
> - [2] when preparing next development iteration
>
> We have now the expected developer experience: everything is automatic
> (after init = manually defining an initial property value) and the
> timestamp is as meaningful as possible


Can I -as a developer- have
https://github.com/apache/maven-source-plugin/blob/e8eaa79e273c5d2b2e02eb1b8a964b2160081e0e/pom.xml#L84
as an empty property on `master` and have it only populated with a
timestamp for the release tag?

>
>
> Regards,
>
> Hervé
>
> [1]
> https://github.com/apache/maven-source-plugin/commit/a59a2e481f7d8e46f2abbd339d2d27e9b2964eba
>
> [2]
> https://github.com/apache/maven-source-plugin/commit/e8eaa79e273c5d2b2e02eb1b8a964b2160081e0e
>
> Le lundi 16 décembre 2019, 19:55:47 CET Hervé BOUTEMY a écrit :
> > for those interested, I add the "Reproducible Builds (free) Bounty" :)
> >
> > instructions:
> > - use JDK 8 on an Unix (and please share if you find a trick to build on
> > Windows, geting the same result) - please install locally
> > maven-buildinfo-plugin
> > https://github.com/apache/maven-studies/tree/maven-buildinfo-plugin -
> build
> > with "mvn -Papache-release,run-its -Dgpg.skip verify buildinfo:save" -
> > check the content of target/buildinfo against reference in attachment If
> > you don't want to install maven-buildinfo-plugin, you can check the
> output
> > checksums by hand, there are only 3 files to check in such a simple
> > mono-module project: maven-source-plugin-3.2.1.jar,
> > maven-source-plugin-3.2.1-source-release.zip and
> > maven-source-plugin-3.2.1-sources.jar
> >
> > Regards,
> >
> > Hervé
> >
> > Le lundi 16 décembre 2019, 19:37:00 CET Hervé BOUTEMY a écrit :
> > > Hi,
> > >
> > > We solved 2 issues:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317924;
> > > ve rsion=12346480=Text
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1545/
> > >
> https://repository.apache.org/content/repositories/maven-1545/org/apache/m
> > > av
> > >
> en/plugins/maven-source-plugin/3.2.1/maven-source-plugin-3.2.1-source-rel
> > > eas e.zip
> > >
> > > Source release checksum(s):
> > > maven-source-plugin-3.2.1-source-release.zip sha512:
> > >
> 4d7252839cc74dae8100a47adadbe6fc2c8f4d57e930fa695e4e6c75a8571b1246a63aa25d
> > > e
> > > 0cf2d73601e599faea2a31be43b1fe442e36d463702d885ccf8b7
> > >
> > > Staging site:
> > > https://maven.apache.org/plugins-archives/maven-source-plugin-LATEST/
> > >
> > > Guide to testing staged releases:
> > >
> https://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for at least 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Yearly JIRA cleanup

[Stephen Connolly]

On Thu 12 Dec 2019 at 17:31, Robert Scholte  wrote:

> IIUC since Jira uses the ASF LDAP, there's no extra need for Brian to do
> this anymore. All should be in place by now.
>

I think we have some crazy permissions that Brian manages. Ldap just fixes
the account name to match across systems AIUI

>
> thanks,
> Robert
> On 12-12-2019 15:20:24, Stephen Connolly 
> wrote:
> On Mon 9 Dec 2019 at 20:53, Elliotte Rusty Harold
> wrote:
>
> > On Mon, Dec 9, 2019 at 3:18 PM Michael Osipov wrote:
> > >
> > > Am 2019-12-08 um 18:08 schrieb Elliotte Rusty Harold:
> > > > Please don't. There are certainly some real and important issues in
> > > > there. More importantly, users spent a great deal of effort and time
> > > > to file those. Bulk closing them tells those users we don't value
> > > > their feedback or effort. It is useful to triage these issues and
> > > > consider them individually. Doubtless many of these issues are
> already
> > > > fixed, moot, or things we expressly chose not to do. However this
> > > > should be decided case by case. We can't simply close our eyes and
> > > > pretend they're all irrelevant.
> > >
> > > Hi Elliotte,
> >
> > > We have almost 2000 open issues. How would you reasonably sieve between
> > > them? even if you allocate 10 min per ticket, you would need two months
> > > of work to triage them.
> > >
> >
> > Use the time we have to fix as much as we can. Leave the rest open.
> > Some will never be touched but some will be when someone encounters
> > the same problem and finds the bug again. It's better to leave it open
> > and unaddressed than to close it without giving it a fair look.
> >
> > As to time spent triaging, it's worth considering whether permissions
> > could be opened up further. Right now, almost anyone can file a bug
> > but few people can resolve and close them. I can't, for example, even
> > when I see one that's clearly no longer relevant. :-(
>
>
> As soon as Brian fixes your JIRA permissions you’ll be able too... your
> committer status is only freshly minted! (welcome/congrats)
>
> Another issue is the lack of a clearly defined process for triage. We
> should document what we mean by triage and what outcomes we expect. That
> could even include closing stale issues after a check for active reporters
>
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > 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

Re: Yearly JIRA cleanup

[Stephen Connolly]

On Mon 9 Dec 2019 at 20:53, Elliotte Rusty Harold 
wrote:

> On Mon, Dec 9, 2019 at 3:18 PM Michael Osipov  wrote:
> >
> > Am 2019-12-08 um 18:08 schrieb Elliotte Rusty Harold:
> > > Please don't. There are certainly some real and important issues in
> > > there. More importantly, users spent a great deal of effort and time
> > > to file those. Bulk closing them tells those users we don't value
> > > their feedback or effort. It is useful to triage these issues and
> > > consider them individually. Doubtless many of these issues are already
> > > fixed, moot, or things we expressly chose not to do. However this
> > > should be decided case by case. We can't simply close our eyes and
> > > pretend they're all irrelevant.
> >
> > Hi Elliotte,
>
> > We have almost 2000 open issues. How would you reasonably sieve between
> > them? even if you allocate 10 min per ticket, you would need two months
> > of work to triage them.
> >
>
> Use the time we have to fix as much as we can. Leave the rest open.
> Some will never be touched but some will be when someone encounters
> the same problem and finds the bug again. It's better to leave it open
> and unaddressed than to close it without giving it a fair look.
>
> As to time spent triaging, it's worth considering whether permissions
> could be opened up further. Right now, almost anyone can file a bug
> but few people can resolve and close them. I can't, for example, even
> when I see one that's clearly no longer relevant. :-(


As soon as Brian fixes your JIRA permissions you’ll be able too... your
committer status is only freshly minted! (welcome/congrats)

Another issue is the lack of a clearly defined process for triage. We
should document what we mean by triage and what outcomes we expect. That
could even include closing stale issues after a check for active reporters

>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: [VOTE] Release Apache Maven version 3.6.3

[Stephen Connolly]

* Works on the projects I tested against
* Commits look to either be "obvious to one skilled in the art" /
"sufficiently small" / "from somebody with an CLA on file" / "from someone
who has demonstrated intent to have the change licensed under Apache
License"
* NOTICE looks correct to me

+1

On Thu, 21 Nov 2019 at 20:06, Robert Scholte  wrote:

> Hi,
>
> This will be a regression release based on some critical issues discovered
> in Maven 3.6.2
>
> We solved 10 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12346152=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1542/
>
>
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz
>
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.zip
>
>
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.3/source/apache-maven-3.6.3-src.tar.gz
>
>
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.3/source/apache-maven-3.6.3-src.zip
>
>
> Source release checksum(s):
>
> apache-maven-3.6.3-bin.tar.gz sha512: 
> c35a1803a6e70a126e80b2b3ae33eed961f83ed74d18fcd16909b2d44d7dada3203f1ffe726c17ef8dcca2dcaa9fca676987befeadc9b9f759967a8cb77181c0
>
> apache-maven-3.6.3-bin.zip sha512: 
> 1c095ed556eda06c6d82fdf52200bc4f3437a1bab42387e801d6f4c56e833fb82b16e8bf0aab95c9708de7bfb55ec27f653a7cf0f491acebc541af234eded94d
>
>
> apache-maven-3.6.3-src.tar.gz sha512: 
> 14eef64ad13c1f689f2ab0d2b2b66c9273bf336e557d81d5c22ddb001c47cf51f03bb1465d6059ce9fdc2e43180ceb0638ce914af1f53af9c2398f5d429f114c
>
>
> apache-maven-3.6.3-src.zip sha512: 
> b23b7ae7392eca28ec124cf8ad24bb27405aea5d252d9305bb37a6e317947cc7dc15a564958a113ab75e2010e16c293d6e7c44f7d41d7bad7635d2d76eb4d1ac
>
> Staging site:
> http://maven.apache.org/ref/3-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: Dynamic phases proposal

[Stephen Connolly]

Ok I figured out dynamic lookup from plexus:

$ mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T19:33:14+01:00)
Maven home: /usr/local/Cellar/maven/3.5.4/libexec
Java version: 1.8.0_152, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home/jre
Default locale: en_IE, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
$ mvn validate
[ERROR] The project uses experimental features that require exactly Maven
3.7.0-SNAPSHOT -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException

Much nicer!



On Fri, 22 Nov 2019 at 16:12, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I have advanced the PoC a bit more by adding an experiments mechanism.
>
> To use the dynamic phases PoC you now need to:
>
> 1. Build and install Maven on the branch
> 2. Add the experiments extension in .mvn/extensions.xml, e.g.
>
> 
> http://maven.apache.org/EXTENSIONS/1.0.0; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0
> http://maven.apache.org/xsd/core-extensions-1.0.0.xsd;>
>
>   
> org.apache.maven
> maven-experiments
> 3.7.0-SNAPSHOT
>   
>
> 
>
> 3. Update your pom to use the new dynamic phases.
>
> The reason for the experiments extension is to guard against assuming the
> phases will work and prevent "normal" versions of Maven from producing a
> bad build.
>
> Here's a build with the extension enabled:
>
> [INFO] Enabling experimental features of Maven 3.7.0-SNAPSHOT
> [INFO] Experimental features enabled:
> [INFO]   * dynamic-phases
> [INFO] Scanning for projects...
> [INFO]
> 
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] foo
>  [jar]
> [INFO] bar
>  [jar]
> [INFO] test
> [pom]
> [INFO]
> [INFO] --< localdomain:foo
> >---
> [INFO] Building foo 1.0-SNAPSHOT
>  [1/3]
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ foo
> ---
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> /Users/stephenc/tmp/test/foo/src/main/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ foo ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources
> (default-testResources) @ foo ---
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> /Users/stephenc/tmp/test/foo/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
> foo ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ foo ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ foo ---
> [WARNING] JAR will be empty - no content was marked for inclusion!
> [INFO]
> [INFO] --- maven-antrun-plugin:1.3:run (2) @ foo ---
> [INFO] Executing tasks
>  [echo] beat you
> [INFO] Executed tasks
> [INFO]
> [INFO] --- maven-antrun-plugin:1.3:run (1) @ foo ---
> [INFO] Executing tasks
>  [echo] hi
> [INFO] Executed tasks
> [INFO]
> [INFO] --- maven-antrun-plugin:1.3:run (4) @ foo ---
> [INFO] Executing tasks
> [INFO]
> [INFO] --- maven-antrun-plugin:1.3:run (3) @ foo ---
> [INFO] Executing tasks
>  [echo] bye
> [INFO] Executed tasks
> [INFO]
> 
> [INFO] Reactor Summary for test 1.0-SNAPSHOT:
> [INFO]
> [INFO] foo  FAILURE [
>  2.745 s]
> [INFO] bar  SKIPPED
> [INFO] test ... SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> 

Re: Dynamic phases proposal

[Stephen Connolly]

ealm.ClassRealm.loadClass(ClassRealm.java:247)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
... 47 more

I'd like to make the error message nicer, but I'll need to dig further into
Sisu. In any case it has the desired effect of preventing building a
project that uses the experiment with a version of Maven that does not
support the experimental features.

The main point of experiments is to provide a way for people to try out a
feature *that requires adapting your project to use that feature* in a safe
way that prevents users from accidentally building with a different version
of Maven. My goal would be to maybe release a
3.7.0-alpha-rfc-dynamic-phases-1 build of Maven with this experiment turned
on to gather wider feedback. Anyone using the feature would then be fully
aware that the experiment may end up different when we actually decide what
we want to do, but can then easily try it out without a big song and dance.

NOTE: the pom rewriting that Robert has scheduled for 3.7.0 is IMHO not
appropriate for this kind of experiment as it doesn't affect the actual
build behaviour. If we have implemented pom rewriting correctly, users
should not notice and shouldn't need to update their pom. Dynamic phases
does require the pom to be updated, hence why it needs a more heavy-handed
enforcement through extensions (also the enforcer plugin wouldn't guarantee
execution on all lifecycles, so if you did something in after:clean
enforcer wouldn't have run)

-Stephen

On Fri, 15 Nov 2019 at 21:16, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

>
>
> On Fri 15 Nov 2019 at 15:18, Robert Scholte  wrote:
>
>> I have to admit that when trying to figure out from a Maven perspective
>> it felt like post-X should be called with pre-X too, but that opinion has
>> changed.
>> Why would anybody call pre-X? I'd say to bring the system ready to do
>> custom X stuff, so it should stop here executing any other phases.
>> However, when pre-X fails, I can imagine that post-X should be called
>> too, as Maven wasn't able to bring the system in the right state.
>>
>> The problem lies in that Maven restarts the lifecycle. If only we could
>> do something like
>> - run up until pre-X (pause the lifecycle execution)
>> - do your custom stuff
>> - finish with the post-X
>>
>> Thinking about some kind of pause... This way at least we won't break the
>> lifecycle and leave it clean.
>>
>
> That’s easy. Have a Maven-pause-plugin that just waits for you to press
> enter. Bind it to integration-test in a profile and presto!
>
> But that removes the need for the current explicit phases of pre- and post-
>
> TBH I think we need to lay down the plan that we want to go towards. It
> will take a while to change existing phases, in part because removing
> phases is a breaking change. You can have 3rd part plugins that bind
> executions to multiple phases, expecting those phases to both exist and
> have specific execution behaviour.
>
> Hence why I think we should go all the way technically, but leave the
> lifecycle mostly as-is (modulo adding any new phases and flagging existing
> phases as deprecated).
>
> Half measures will only prolong to pain for users.
>
> If instead we say: “here’s where we were, here’s where we’re going and
> this is how we get there” people can incorporate that and adapt
>
> Messing about with one phase, that’s just hacks. Adding the ability to
> define phase execution guarantees... that’s where we want to go. Adding the
> ability to control plugin execution order within phases... that’s where we
> want to go... is the syntax where we want to go? Probably not, but it’s how
> we can get there
>
>>
>>
>> On 15-11-2019 11:07:23, Stephen Connolly 
>> wrote:
>> On Fri 15 Nov 2019 at 09:18, Robert Scholte wrote:
>>
>> > On 13-11-2019 21:46:04, Stephen Connolly
>> > wrote:
>> > On Wed 13 Nov 2019 at 19:29, Robert Scholte wrote:
>> >
>> > > The name of the branch contains MNG-5668, but it contains much more.
>> > > I'd likely lead to comments like "great", without being explicit
>> saying
>> > > which part(s).
>> > > I am aware there's all proposals touch the same code, but can be
>> released
>> > > isolated from each other.
>> > > e.g. if the enums-value are changed to "pre-" and "post-" it should
>> work
>> > > for the existing phases, which means we could already use it quite
>> soon
>> > > (still need to test it myself, though)
>> > > I also want to provide a counter proposal, but that takes time and
>> for me
>> > > there are other issues more importan

Re: Dynamic phases proposal

[Stephen Connolly]

On Fri 15 Nov 2019 at 15:18, Robert Scholte  wrote:

> I have to admit that when trying to figure out from a Maven perspective it
> felt like post-X should be called with pre-X too, but that opinion has
> changed.
> Why would anybody call pre-X? I'd say to bring the system ready to do
> custom X stuff, so it should stop here executing any other phases.
> However, when pre-X fails, I can imagine that post-X should be called too,
> as Maven wasn't able to bring the system in the right state.
>
> The problem lies in that Maven restarts the lifecycle. If only we could do
> something like
> - run up until pre-X (pause the lifecycle execution)
> - do your custom stuff
> - finish with the post-X
>
> Thinking about some kind of pause... This way at least we won't break the
> lifecycle and leave it clean.
>

That’s easy. Have a Maven-pause-plugin that just waits for you to press
enter. Bind it to integration-test in a profile and presto!

But that removes the need for the current explicit phases of pre- and post-

TBH I think we need to lay down the plan that we want to go towards. It
will take a while to change existing phases, in part because removing
phases is a breaking change. You can have 3rd part plugins that bind
executions to multiple phases, expecting those phases to both exist and
have specific execution behaviour.

Hence why I think we should go all the way technically, but leave the
lifecycle mostly as-is (modulo adding any new phases and flagging existing
phases as deprecated).

Half measures will only prolong to pain for users.

If instead we say: “here’s where we were, here’s where we’re going and this
is how we get there” people can incorporate that and adapt

Messing about with one phase, that’s just hacks. Adding the ability to
define phase execution guarantees... that’s where we want to go. Adding the
ability to control plugin execution order within phases... that’s where we
want to go... is the syntax where we want to go? Probably not, but it’s how
we can get there

>
>
> On 15-11-2019 11:07:23, Stephen Connolly 
> wrote:
> On Fri 15 Nov 2019 at 09:18, Robert Scholte wrote:
>
> > On 13-11-2019 21:46:04, Stephen Connolly
> > wrote:
> > On Wed 13 Nov 2019 at 19:29, Robert Scholte wrote:
> >
> > > The name of the branch contains MNG-5668, but it contains much more.
> > > I'd likely lead to comments like "great", without being explicit saying
> > > which part(s).
> > > I am aware there's all proposals touch the same code, but can be
> released
> > > isolated from each other.
> > > e.g. if the enums-value are changed to "pre-" and "post-" it should
> work
> > > for the existing phases, which means we could already use it quite soon
> > > (still need to test it myself, though)
> > > I also want to provide a counter proposal, but that takes time and for
> me
> > > there are other issues more important.
> >
> >
> > How would you handle the use case that we’ve already had reported:
> >
> > As a user I want to test my integration tests in my IDE by running `mvn
> > integration-test` so that the test environment is not torn down and I can
> > debug and rerun the tests until I’m ready
> >
> > Robert Scholte:
> > I'd say if they want to set up there environment for the integration
> > tests, they'd be running pre-integration-test.
> > Next select in the IDE the test to execute. I don't see an issue here.
> > Calling pre-integration-test implies NOT running post-integration-test.
>
>
> I disagree. I think if you run the pre- phase then you should have the
> post- also run
>
> I think we could have a differential failure mode in the pre-phases though.
> Iow a pre- phase failure returns a different exit code than the actual
> phase itself
>
> >
> >
> > Every time I explain people about how Maven works with phases, they are
> > amazed it doesn't run the post-phase. I doubt we'll see issues if we
> switch
> > to expected behavior.
> >
> > Based on the different views, I hope to see more involvement of PMC
> > members, because this will be a turning point that probable cannot be
> > undone.
> >
> >
> > With the new phases, the existing pom will still work, and some user
> opting
> > into after:integration-test knows what they are getting
> >
> >
> > >
> > > My biggest fear is that this will result in an All-Or-Nothing, and I
> like
> > > to prevent that. If the try-finally part works as expected we can
> extract
> > > that part and prepare for one of the next Maven releases.
> >
> >
> > I’d like to understand your fear better. I’ve been 

Re: Dynamic phases proposal

[Stephen Connolly]

On Fri 15 Nov 2019 at 09:18, Robert Scholte  wrote:

> On 13-11-2019 21:46:04, Stephen Connolly 
> wrote:
> On Wed 13 Nov 2019 at 19:29, Robert Scholte wrote:
>
> > The name of the branch contains MNG-5668, but it contains much more.
> > I'd likely lead to comments like "great", without being explicit saying
> > which part(s).
> > I am aware there's all proposals touch the same code, but can be released
> > isolated from each other.
> > e.g. if the enums-value are changed to "pre-" and "post-" it should work
> > for the existing phases, which means we could already use it quite soon
> > (still need to test it myself, though)
> > I also want to provide a counter proposal, but that takes time and for me
> > there are other issues more important.
>
>
> How would you handle the use case that we’ve already had reported:
>
> As a user I want to test my integration tests in my IDE by running `mvn
> integration-test` so that the test environment is not torn down and I can
> debug and rerun the tests until I’m ready
>
> Robert Scholte:
> I'd say if they want to set up there environment for the integration
> tests, they'd be running pre-integration-test.
> Next select in the IDE the test to execute. I don't see an issue here.
> Calling pre-integration-test implies NOT running post-integration-test.


I disagree. I think if you run the pre- phase then you should have the
post- also run

I think we could have a differential failure mode in the pre-phases though.
Iow a pre- phase failure returns a different exit code than the actual
phase itself

>
>
> Every time I explain people about how Maven works with phases, they are
> amazed it doesn't run the post-phase. I doubt we'll see issues if we switch
> to expected behavior.
>
> Based on the different views, I hope to see more involvement of PMC
> members, because this will be a turning point that probable cannot be
> undone.
>
>
> With the new phases, the existing pom will still work, and some user opting
> into after:integration-test knows what they are getting
>
>
> >
> > My biggest fear is that this will result in an All-Or-Nothing, and I like
> > to prevent that. If the try-finally part works as expected we can extract
> > that part and prepare for one of the next Maven releases.
>
>
> I’d like to understand your fear better. I’ve been playing with the PoC a
> bit, and TBH it just feels right.
>
> For sure I’d prefer a schema change to encoding in a string, but I’m also
> inclined towards string encoded dependency GAVs for 5.x so that wouldn’t be
> the worst if we went that way.
>
> With pom rewriting, I think we could do a 4.1.0 model version that moved
> the execution point and priority to attributes, by writing as a 4.0.0 with
> the string encoded form... iow rewriting in 4.x allows us to tidy up the
> schema as long as it has a 1:1 mapping to a 4.0.0 modelVersion that gets
> deployed.
>
>
> >
> > Robert
> >
> >
> >
> >
> >
> > On 12-11-2019 10:25:42, Stephen Connolly
> > wrote:
> > On Tue 12 Nov 2019 at 07:34, Robert Scholte wrote:
> >
> > > This is not just MNG-5668, but also contains several non-existing
> issues,
> > > that should be mentioned explicitly as they will have huge impact:
> > >
> > > - support before:/after: prefix for phase-binding
> > >
> > > - introduce priority
> > > - reduce phases (this one hasn't been implemented, but seems to be the
> > > reason behind before:/after:)
> >
> >
> > All detailed in the proposal on the wiki:
> > https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases
> >
> > Reducing phases would be a big change and not before 4.x at least (maybe
> > 5.x more realistically... at least we’d need to deprecate the phases for
> a
> > good while before removing any)
> >
> >
> > >
> > > I would like see separate branches for all of them, as they all have
> > their
> > > own discussion.
> >
> >
> > The whole point of a PoC is the get feedback. I don’t see utility in
> > separate branches as they are all touching the same code.
> >
> > Once we get feedback we can decide where we want to go from there.
> >
> >
> > >
> > > Robert
> > > On 11-11-2019 20:31:44, Stephen Connolly
> > > wrote:
> > > https://github.com/apache/maven/tree/mng-5668-poc is my POC
> > implementation
> > > for anyone interested in trying it out.
> > >
> > > Here's a pom that builds with the PoC
> > >
> > >
> > > 4.

Re: Dynamic phases proposal

[Stephen Connolly]

On Wed 13 Nov 2019 at 19:29, Robert Scholte  wrote:

> The name of the branch contains MNG-5668, but it contains much more.
> I'd likely lead to comments like "great", without being explicit saying
> which part(s).
> I am aware there's all proposals touch the same code, but can be released
> isolated from each other.
> e.g. if the enums-value are changed to "pre-" and "post-" it should work
> for the existing phases, which means we could already use it quite soon
> (still need to test it myself, though)
> I also want to provide a counter proposal, but that takes time and for me
> there are other issues more important.


How would you handle the use case that we’ve already had reported:

As a user I want to test my integration tests in my IDE by running `mvn
integration-test` so that the test environment is not torn down and I can
debug and rerun the tests until I’m ready

With the new phases, the existing pom will still work, and some user opting
into after:integration-test knows what they are getting


>
> My biggest fear is that this will result in an All-Or-Nothing, and I like
> to prevent that. If the try-finally part works as expected we can extract
> that part and prepare for one of the next Maven releases.


I’d like to understand your fear better. I’ve been playing with the PoC a
bit, and TBH it just feels right.

For sure I’d prefer a schema change to encoding in a string, but I’m also
inclined towards string encoded dependency GAVs for 5.x so that wouldn’t be
the worst if we went that way.

With pom rewriting, I think we could do a 4.1.0 model version that moved
the execution point and priority to attributes, by writing as a 4.0.0 with
the string encoded form... iow rewriting in 4.x allows us to tidy up the
schema as long as it has a 1:1 mapping to a 4.0.0 modelVersion that gets
deployed.


>
> Robert
>
>
>
>
>
> On 12-11-2019 10:25:42, Stephen Connolly 
> wrote:
> On Tue 12 Nov 2019 at 07:34, Robert Scholte wrote:
>
> > This is not just MNG-5668, but also contains several non-existing issues,
> > that should be mentioned explicitly as they will have huge impact:
> >
> > - support before:/after: prefix for phase-binding
> >
> > - introduce priority
> > - reduce phases (this one hasn't been implemented, but seems to be the
> > reason behind before:/after:)
>
>
> All detailed in the proposal on the wiki:
> https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases
>
> Reducing phases would be a big change and not before 4.x at least (maybe
> 5.x more realistically... at least we’d need to deprecate the phases for a
> good while before removing any)
>
>
> >
> > I would like see separate branches for all of them, as they all have
> their
> > own discussion.
>
>
> The whole point of a PoC is the get feedback. I don’t see utility in
> separate branches as they are all touching the same code.
>
> Once we get feedback we can decide where we want to go from there.
>
>
> >
> > Robert
> > On 11-11-2019 20:31:44, Stephen Connolly
> > wrote:
> > https://github.com/apache/maven/tree/mng-5668-poc is my POC
> implementation
> > for anyone interested in trying it out.
> >
> > Here's a pom that builds with the PoC
> >
> >
> > 4.0.0
> > localdomain
> > foo
> > 1.0-SNAPSHOT
> >
> >
> >
> > maven-antrun-plugin
> >
> >
> > 1
> > before:integration-test
> >
> > run
> >
> >
> >
> >
> >
> >
> >
> >
> > 2
> > before:integration-test[1000]
> >
> > run
> >
> >
> >
> >
> >
> >
> >
> >
> > 3
> > after:integration-test
> >
> > run
> >
> >
> >
> >
> >
> >
> >
> >
> > 4
> > integration-test
> >
> > run
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sun, 27 Oct 2019 at 10:55, Robert Scholte wrote:
> >
> > > TLDR: We can do better than, but who is in control? lifecycle-owner,
> > > plugin-owner or pom-owner?
> > >
> > > I think we all recognize the issues we're trying to solve, but to me
> this
> > > proposal is not the right solution.
> > >
> > > In general there are 2 issues:
> > > 1. provide a mechanism that makes sure some executions are called even
> > its
> > > matching main phase fails.
> > > 2. provide a mechanism then ensures the order of executions.
> > >
> > > The problem of issue 1 is described 

Re: Dynamic phases proposal

[Stephen Connolly]

On Wed 13 Nov 2019 at 19:29, Robert Scholte  wrote:

> The name of the branch contains MNG-5668, but it contains much more.
> I'd likely lead to comments like "great", without being explicit saying
> which part(s).
> I am aware there's all proposals touch the same code, but can be released
> isolated from each other.
> e.g. if the enums-value are changed to "pre-" and "post-" it should work
> for the existing phases,


That would be a mistake in my opinion. We don’t know what people have
assumed about the post-integration-test phase. I think if we are addressing
finally it needs to be in a “new” phase.

Plus how do we distinguish between someone running `mvn integration-test`
and `mvn post-integration-test` for sure someone running `mvn verify`
should probably have finally behaviour in the event of the integration-test
failing... but that would require quite a bit of hacks to the build plan
whereas dynamic phases is just about decorating each phase as it is

which means we could already use it quite soon (still need to test it
> myself, though)
> I also want to provide a counter proposal, but that takes time and for me
> there are other issues more important.
>
> My biggest fear is that this will result in an All-Or-Nothing, and I like
> to prevent that. If the try-finally part works as expected we can extract
> that part and prepare for one of the next Maven releases.
>
> Robert
>
>
>
>
>
> On 12-11-2019 10:25:42, Stephen Connolly 
> wrote:
> On Tue 12 Nov 2019 at 07:34, Robert Scholte wrote:
>
> > This is not just MNG-5668, but also contains several non-existing issues,
> > that should be mentioned explicitly as they will have huge impact:
> >
> > - support before:/after: prefix for phase-binding
> >
> > - introduce priority
> > - reduce phases (this one hasn't been implemented, but seems to be the
> > reason behind before:/after:)
>
>
> All detailed in the proposal on the wiki:
> https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases
>
> Reducing phases would be a big change and not before 4.x at least (maybe
> 5.x more realistically... at least we’d need to deprecate the phases for a
> good while before removing any)
>
>
> >
> > I would like see separate branches for all of them, as they all have
> their
> > own discussion.
>
>
> The whole point of a PoC is the get feedback. I don’t see utility in
> separate branches as they are all touching the same code.
>
> Once we get feedback we can decide where we want to go from there.
>
>
> >
> > Robert
> > On 11-11-2019 20:31:44, Stephen Connolly
> > wrote:
> > https://github.com/apache/maven/tree/mng-5668-poc is my POC
> implementation
> > for anyone interested in trying it out.
> >
> > Here's a pom that builds with the PoC
> >
> >
> > 4.0.0
> > localdomain
> > foo
> > 1.0-SNAPSHOT
> >
> >
> >
> > maven-antrun-plugin
> >
> >
> > 1
> > before:integration-test
> >
> > run
> >
> >
> >
> >
> >
> >
> >
> >
> > 2
> > before:integration-test[1000]
> >
> > run
> >
> >
> >
> >
> >
> >
> >
> >
> > 3
> > after:integration-test
> >
> > run
> >
> >
> >
> >
> >
> >
> >
> >
> > 4
> > integration-test
> >
> > run
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sun, 27 Oct 2019 at 10:55, Robert Scholte wrote:
> >
> > > TLDR: We can do better than, but who is in control? lifecycle-owner,
> > > plugin-owner or pom-owner?
> > >
> > > I think we all recognize the issues we're trying to solve, but to me
> this
> > > proposal is not the right solution.
> > >
> > > In general there are 2 issues:
> > > 1. provide a mechanism that makes sure some executions are called even
> > its
> > > matching main phase fails.
> > > 2. provide a mechanism then ensures the order of executions.
> > >
> > > The problem of issue 1 is described in MNG-5668, but not the final
> > > solution.
> > > MNG-5668 proposes to give this power to the *lifecycle-owner*, whereas
> > > stage 2 proposes to give the power to the *pom-owner*.
> > > Both agree on the same thing: by default these post-phases should be
> > > triggered even after failure of the matching main phase. This is
> actually
> > > already expected behavior, so I don't expect re

Re: Maven Enforcer Release-3.0.0-M3

[Stephen Connolly]

Oh I forgot, Surefire further complicates things as it has an API that
needs to be implemented by providers, so we need to try and encode that
API's breaking changes into our version number also... a lot of stuff to
try and encode in a version  number... I fear semver is not up to the job

On Wed, 13 Nov 2019 at 13:44, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I think the fundamental problem here is that we (i.e. maven developers) do
> not have a shared understanding of how we want to use version numbers.
>
> There are a group of people who want to use semantic versioning such that
> the major version is only incremented for "breaking" changes, minor version
> for "enhancements" and "patch" version for "bug fixes".
>
> There is another group of people who want to use the major version to
> indicate the Maven release line that the plugin targets... as that is a
> hard breaking change, the minor version for "enhancements" that may require
> changes to your pom (i.e. soft breaking since to update the plugin you have
> to change the pom anyway) and the "patch" version for "bug fixes" and
> "opt-in enhancements"
>
> We cannot keep both of these groups happy without spinning our wheels.
>
> The next release of surefire will break backwards compatibility (because
> it drops support for Maven 2.x) so it's going to get called 3.x.y
>
> We would like not to end up with Surefire 4.x.y before Maven 4.x, thus the
> people who stick to strict semver will want to roll all the breaking
> changes into 3.0.0 because any additional breaking changes would force a
> 4.0.0 (which the people who want to use the major version number to
> indicate Core release line would object to)
>
> My vote is that we should just say we are not using SemVer. Plugins use a
> scheme whereby:
>
> * Major version is minimum Core release line required to run the plugin
> * Minor version indicates that you may have to change your pom.xml
> configuration
> * Patch version should just be better (and don't assume the first release
> will be 0, because failed release votes should bump the patch like we do
> for core.)
>
> This would unblock us here (i.e. these would not be milestones) and
> anything that stops us seeing a x.y.0 release as special and thus causing
> us to hold back until it's ready is a bad thing IMHO
>
> *BUT* with all that said, whoever is running the release gets to call the
> version number. Unless someone other than Tibor steps up and cuts a release
> we have to put up with the version number he decides... but any committer
> at any time could step up and cut a release and call a vote (just respect
> to the community norms stops people "stealing" the release manager role
> from someone who is holding it)
>
>
>
> On Wed, 13 Nov 2019 at 12:31, Elliotte Rusty Harold 
> wrote:
>
>> To my thinking, a release candidate is believed to be done. All
>> features are complete and no unshippable bugs are known. An RC is
>> posted to give users a chance to shake out any unknown bugs. If no
>> unknown bugs are found then the RC is the release, module a version
>> change.
>>
>> A milestone, by contrast, is a step on the way and is definitely not
>> feature complete.
>>
>> The way you're describing Maven's milestone releases they sound like
>> the outcome of a big bang release process. There are certain features
>> that have to go in to a milestone, and the product won't ship until
>> they're done. Only, some features and bug fixes are needed before then
>> so you ship the product anyway and call it a milestone. It's a bit of
>> a wishy washy middle ground.
>>
>> As a user I find this scheme confusing. I'd prefer a more
>> straightforward versioning scheme: if it's ready for end users then
>> there's no classifier, just 3.0.0, 3.0.1, 3.1.0, etc. If it's not call
>> it 3.1.0-beta or some such. It doesn't make a big difference to the
>> code that gets shipped when, just how it's labeled for end users.
>>
>> As a developer I definitely prefer to release features and bug fixes
>> sooner rather than later. I also find smaller, more frequent releases
>> a lot easier to manage than once a year big bang releases. As long as
>> the external facing API is stable--in the case of Maven this
>> essentially means the syntax of the pom.xml file--there's no reason
>> not to ship with every significant improvement. If you're planning on
>> 10 improvements in a product, and two are done, ship it, assuming none
>> of the remaining eight are going to break anything incompatibly. Ths
>> does assume the release process is 

Re: Maven Enforcer Release-3.0.0-M3

[Stephen Connolly]

I think the fundamental problem here is that we (i.e. maven developers) do
not have a shared understanding of how we want to use version numbers.

There are a group of people who want to use semantic versioning such that
the major version is only incremented for "breaking" changes, minor version
for "enhancements" and "patch" version for "bug fixes".

There is another group of people who want to use the major version to
indicate the Maven release line that the plugin targets... as that is a
hard breaking change, the minor version for "enhancements" that may require
changes to your pom (i.e. soft breaking since to update the plugin you have
to change the pom anyway) and the "patch" version for "bug fixes" and
"opt-in enhancements"

We cannot keep both of these groups happy without spinning our wheels.

The next release of surefire will break backwards compatibility (because it
drops support for Maven 2.x) so it's going to get called 3.x.y

We would like not to end up with Surefire 4.x.y before Maven 4.x, thus the
people who stick to strict semver will want to roll all the breaking
changes into 3.0.0 because any additional breaking changes would force a
4.0.0 (which the people who want to use the major version number to
indicate Core release line would object to)

My vote is that we should just say we are not using SemVer. Plugins use a
scheme whereby:

* Major version is minimum Core release line required to run the plugin
* Minor version indicates that you may have to change your pom.xml
configuration
* Patch version should just be better (and don't assume the first release
will be 0, because failed release votes should bump the patch like we do
for core.)

This would unblock us here (i.e. these would not be milestones) and
anything that stops us seeing a x.y.0 release as special and thus causing
us to hold back until it's ready is a bad thing IMHO

*BUT* with all that said, whoever is running the release gets to call the
version number. Unless someone other than Tibor steps up and cuts a release
we have to put up with the version number he decides... but any committer
at any time could step up and cut a release and call a vote (just respect
to the community norms stops people "stealing" the release manager role
from someone who is holding it)



On Wed, 13 Nov 2019 at 12:31, Elliotte Rusty Harold 
wrote:

> To my thinking, a release candidate is believed to be done. All
> features are complete and no unshippable bugs are known. An RC is
> posted to give users a chance to shake out any unknown bugs. If no
> unknown bugs are found then the RC is the release, module a version
> change.
>
> A milestone, by contrast, is a step on the way and is definitely not
> feature complete.
>
> The way you're describing Maven's milestone releases they sound like
> the outcome of a big bang release process. There are certain features
> that have to go in to a milestone, and the product won't ship until
> they're done. Only, some features and bug fixes are needed before then
> so you ship the product anyway and call it a milestone. It's a bit of
> a wishy washy middle ground.
>
> As a user I find this scheme confusing. I'd prefer a more
> straightforward versioning scheme: if it's ready for end users then
> there's no classifier, just 3.0.0, 3.0.1, 3.1.0, etc. If it's not call
> it 3.1.0-beta or some such. It doesn't make a big difference to the
> code that gets shipped when, just how it's labeled for end users.
>
> As a developer I definitely prefer to release features and bug fixes
> sooner rather than later. I also find smaller, more frequent releases
> a lot easier to manage than once a year big bang releases. As long as
> the external facing API is stable--in the case of Maven this
> essentially means the syntax of the pom.xml file--there's no reason
> not to ship with every significant improvement. If you're planning on
> 10 improvements in a product, and two are done, ship it, assuming none
> of the remaining eight are going to break anything incompatibly. Ths
> does assume the release process is automated and lightweight, but
> that's a good thing to have in any case.
>
> On Tue, Nov 12, 2019 at 10:21 PM Tibor Digana 
> wrote:
> >
> > Elliote,
> >
> > It is stable. We do not want to break users, but we split the global
> > picture for the version Y.0.0 into multiple complete stages (not
> > incomplete!), but the Y.0.0 becomes a bunch of these Mx.
> > It does not mean that a bugfix is incomplete or appears across multiple
> > versions.
> > I think you have another view and another scope of the work in your mind.
> >
> > For me Mx is only a naming conventions.
> > This team is calling it milestone Mx and not RCs.
> > Many OSS projects are releasing RCs. Not sure why we do not.
> >
> > If the Wildfly project is going to cut a new major version, they release
> > RC.
> > For me it is a kind of "give it a try in users" and then they fix the
> > realistic issues which could not be found by the integration tests.
> > And 

Re: Dynamic phases proposal

[Stephen Connolly]

On Tue 12 Nov 2019 at 07:34, Robert Scholte  wrote:

> This is not just MNG-5668, but also contains several non-existing issues,
> that should be mentioned explicitly as they will have huge impact:
>
> - support before:/after: prefix for phase-binding
>
> - introduce priority
> - reduce phases (this one hasn't been implemented, but seems to be the
> reason behind before:/after:)


All detailed in the proposal on the wiki:
https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases

Reducing phases would be a big change and not before 4.x at least (maybe
5.x more realistically... at least we’d need to deprecate the phases for a
good while before removing any)


>
> I would like see separate branches for all of them, as they all have their
> own discussion.


The whole point of a PoC is the get feedback. I don’t see utility in
separate branches as they are all touching the same code.

Once we get feedback we can decide where we want to go from there.


>
> Robert
> On 11-11-2019 20:31:44, Stephen Connolly 
> wrote:
> https://github.com/apache/maven/tree/mng-5668-poc is my POC implementation
> for anyone interested in trying it out.
>
> Here's a pom that builds with the PoC
>
>
> 4.0.0
> localdomain
> foo
> 1.0-SNAPSHOT
>
>
>
> maven-antrun-plugin
>
>
> 1
> before:integration-test
>
> run
>
>
>
>
>
>
>
>
> 2
> before:integration-test[1000]
>
> run
>
>
>
>
>
>
>
>
> 3
> after:integration-test
>
> run
>
>
>
>
>
>
>
>
> 4
> integration-test
>
> run
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sun, 27 Oct 2019 at 10:55, Robert Scholte wrote:
>
> > TLDR: We can do better than, but who is in control? lifecycle-owner,
> > plugin-owner or pom-owner?
> >
> > I think we all recognize the issues we're trying to solve, but to me this
> > proposal is not the right solution.
> >
> > In general there are 2 issues:
> > 1. provide a mechanism that makes sure some executions are called even
> its
> > matching main phase fails.
> > 2. provide a mechanism then ensures the order of executions.
> >
> > The problem of issue 1 is described in MNG-5668, but not the final
> > solution.
> > MNG-5668 proposes to give this power to the *lifecycle-owner*, whereas
> > stage 2 proposes to give the power to the *pom-owner*.
> > Both agree on the same thing: by default these post-phases should be
> > triggered even after failure of the matching main phase. This is actually
> > already expected behavior, so I don't expect real issues when
> implementing
> > this adjusted behavior.
> > To me after:integration-test is just an alias for post-integration-test,
> > both should work the same way.
> >
> > Issue 2 is a more common problem: controlling the order of executions.
> > In some cases it is pretty hard or even impossible to get the preferred
> > order. The latter happens when 2 goals of the same plugin must be
> executed
> > and a goal of another plugin are competing within the same phase.
> >
> > So let's first take a look at a phase: is there a clear definition?
> > "A phase is a step in what Maven calls a 'build lifecycle'. The build
> > lifecycle is an ordered sequence of phases involved in building a
> project".
> > "Lifecycle phases are intentionally vague, defined solely as
> > validation, testing, or deployment, and they may mean different things to
> > different projects."
> > Phases are intended to be called from the commandline, and within the pom
> > you define you can control what should happen before or during that
> phase.
> >
> > To me changing the content of the -element is a codesmell as it
> > becomes more than just a phase, and we start programming. Why do we need
> it?
> > In the end it is all about ensuring the order of plugin executions.
> > Stage3+4 proposes to give the power to the *pom-owner*,
> > whereas MPLUGIN-350[2] proposes to give this power to the *plugin-owner*.
> > IIUR Gradle does not have this issue, because their plugins are aware of
> > input and output. They ensure that if the output plugin X is the input of
> > plugin Y, than X is executed before Y.
> > And we should do the same. And this comes with benefits: we can decide if
> > executions within a project can be executed in parallel. And the pom
> stays
> > as clean as it is right now.
> >
> > In cases when there's a better ownership than the pom-owner, I would
> > prefer to choose that solution. I already notice how people (don't) build
> > up their knowle

Re: Dynamic phases proposal

[Stephen Connolly]

ly
> If somebody called the pre-PHASE, there's no reason to end with the
> post-PHASE?
>
> [1] https://issues.apache.org/jira/browse/MNG-5668
> [2] https://issues.apache.org/jira/browse/MPLUGIN-350
> On 26-10-2019 14:20:50, Stephen Connolly 
> wrote:
> On Sat 26 Oct 2019 at 10:50, Robert Scholte wrote:
>
> > To avoid confusion, let's call it stages.
> >
> > Stage 1: Always call post-bound executions (MNG-5665[1])
> > Stage 2: before and after
> > Stage 3: priorities (MNG-3522[2])
> > Stage 4: transitional lifecycle
>
>
> I have a prototype of stages 1-3 nearly (80%) done... just have to polish
> up and validate the bound executions with some tests
>
>
> >
> > For both all you need to start evaluating the value of phase.
> > For now we can assume that after:clean is just another label for
> > post-clean and will have exactly the same effect.
> > MNG-5665 contains a proposal to change the xml, but we shouldn't do that
> > (yet). Let's start with a hardcoded list of postphases (or in case a goal
> > fails, see if a post-x phase exists). Stage 1 is to make it work, stage 2
> > to make it configurable.
> > IIRC you cannot ask from inside a Mojo if is was called explicitly or
> > because it was bound to a phase, nor can you ask for the value of this
> > phase. I kind of like this, plugins shouldn't care about this.
> > However, inside Maven it will become important at which phase it is to
> > know if there are more executions to call OR create blocks of executions.
> > Now it is just a list of executions: loop and fail fast.
> >
> > thanks,
> > Robert
> >
> > [1] https://issues.apache.org/jira/browse/MNG-5665
> > [2] https://issues.apache.org/jira/browse/MNG-3522
> > On 25-10-2019 21:33:14, Stephen Connolly
> > wrote:
> > Robert,
> >
> > I would be fine splitting out into, pardon the pun, phases:
> >
> > Phase 1: before and after
> > Phase 2: priorities
> > Phase 3: transitional lifecycle
> >
> > Might have a phase 1.5 of before:* and after:* to catch the start of a
> > lifecycle and the end of a lifecycle...
> >
> > On Fri 25 Oct 2019 at 20:30, Stephen Connolly <>
> > stephen.alan.conno...@gmail.com [mailto:stephen.alan.conno...@gmail.com
> ]>
> > wrote:
> >
> > Robert, Michael, Tibor, let’s continue here (though I asked Infra and
> it’s
> > fine that anyone in the community can join our Slack)
> >
> > On Fri 25 Oct 2019 at 20:01, Stephen Connolly <>
> > stephen.alan.conno...@gmail.com [mailto:stephen.alan.conno...@gmail.com
> ]>
> > wrote:
> >
> > https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases [
> > https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases]
> >
> > Thoughts?
> > --
> >
> > Sent from my phone
> > --
> >
> > Sent from my phone
> > --
> >
> > Sent from my phone
>
> --
> Sent from my phone
>

Re: ***UNCHECKED*** Re: Hard requirements

[Stephen Connolly]

On Fri 1 Nov 2019 at 21:37, Elliotte Rusty Harold 
wrote:

> Pass 1:
> https://github.com/apache/maven-site/compare/master...elharo:patch-34
>
> This might not be accurate. In particular I am assuming that if there
> are two requirements for [1.0,2.0] and (3.0,5.0) that something will
> be picked.


If the same dependency is pulled into the tree in different places and the
intersection of ranges is an empty set then the build fails.

This might not be accurate. If this instead fails the
> build, please let me know. Comments are probably most convenient on
> the PR. Thanks all.
>
> *** {Dependency Version Requirement Specification}
>
>   Dependencies' <<>> elements define version requirements,
> which are used to compute effective dependency
>   versions. Version requirements have the following syntax:
>
>   * <<<1.0>>>: "Soft" requirement on 1.0. Use 1.0 if no other version
> appears earlier in the dependency tree.
>
>   * <<<[1.0]>>>: "Hard" requirement on 1.0. Use 1.0 and only 1.0, even
> if other versions come before this dependency in
> the tree. If multiple hard versions conflict, fail the build.
>
>   * <<<(,1.0]>>>: Soft requirement on any version \<= 1.0
>
>   * <<<[1.2,1.3]>>>: Soft requirement on any version between 1.2 and
> 1.3 inclusive.
>
>   * <<<[1.0,2.0)>>>: 1.0 \<= x \< 2.0; soft requirement on any version
> between 1.0 inclusive and 2.0 exclusive.
>
>   * <<<[1.5,)>>>: Soft requirement on any version greater than or equal to
> 1.5.
>
>   * <<<(,1.0],[1.2,)>>>: Soft requirement on any version less than or
> equal to 1.0 than or greater than
> or equal to 1.2, but not 1.1. Multiple requirements are comma-separated
>
>   * <<<(,1.1),(1.1,)>>>: Soft requirement on any version except 1.1;
> for example because
> it is known not to have a critical vulnerability.
>
>
> On Fri, Oct 25, 2019 at 4:43 PM Stephen Connolly
>  wrote:
> >
> > On Tue 22 Oct 2019 at 11:30, Elliotte Rusty Harold 
> > wrote:
> >
> > > The docs at
> > >
> https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification
> > > say:
> > >
> > > 1.0: "Soft" requirement on 1.0 (just a recommendation, if it matches
> > > all other ranges for the dependency)
> > > [1.0]: "Hard" requirement on 1.0
> > >
> > > However, I don't think anywhere do we actually explain what a soft or
> > > a "Hard" requirement is. If someone can clarify this for me, I'll
> > > update the docs accordingly.
> > >
> >
> > Ranges only come into affect when you have multiple dependencies using
> > ranges.
> >
> > When you use ranges, Maven tries to satisfy all the requests.
> >
> > A soft version is like: “I’d like this if I can have it”
> >
> > A hard version is: “only this or die”
> >
> > If your dependency tree has dependency foo being brought in by multiple
> > dependencies:
> >
> > Maven first gets the intersection of all ranges
> >
> > If there is more than one version left in the intersection, Maven looks
> at
> > the “nearest” soft version requests and if that fits the range it will
> use
> > that.
> >
> > If your range is just a single version, that means only that version will
> > do, hence it becomes a hard specification.
> >
> > Now having said all that, ranges have - to date - proven problematic. In
> > general it is better to avoid ranges at all... and that includes hard
> > version numbers.
> >
> > Hopefully in Maven 5.0.0 we can find a way to make ranges at least
> > usable... but the reality is ranges are a hard problem in and if
> themselves.
> >
> > >
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elh...@ibiblio.org
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > --
> > Sent from my phone
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Next Generation Integration Testing for Plugins/Core

[Stephen Connolly]

On Tue, 29 Oct 2019 at 22:16, Romain Manni-Bucau 
wrote:

> Le mar. 29 oct. 2019 à 22:58, Karl Heinz Marbaise  a
> écrit :
>
> > Hi Romain,
> >
> > On 29.10.19 22:40, Romain Manni-Bucau wrote:
> > > Hi Karl
> > >
> > > Not sure id do a MavenIT annotation - test is enough probably - but i
> > > like jupiter style.
> >
> > MavenIT[1] annotation contains more information like global/local cache,
> > the default goals which are used for the build, debugging or not (just
> > to mention some; I think there will be more).
> >
> > Also so the MavenTest annotation is needed to define specific things for
> > Maven like activeProfiles etc.
> >
> > [1]:
> >
> >
> https://github.com/khmarbaise/maven-it-extension/blob/master/src/main/java/org/apache/maven/jupiter/extension/MavenIT.java
> >
> > See also:
> >
> >
> >
> https://github.com/khmarbaise/maven-it-extension/blob/master/src/test/java/org/apache/maven/jupiter/it/MavenIntegrationIT.java
>
>
>
> You can alias @MavenTest for that no? This is what i had in mind. Like
> @ShadeTest decorated with @MavenTest to set defaults.
>
> So you reduce thz number of annotations.
>
> That said it is not a blocker.
>
>
> >
> >
> > >
> > > Im less exited by assertj but it is probably a habit thing.
> >
> > I'm not sure if I see your issue with AssertJ. Have you used it? AssertJ
> > brings clear expression and readable tests in general and gives me a
> > simple way to create custom assertions to support special parts for a
> > Maven build like Log file, project structure, target directory contents,
> > content of archive files etc. ?
> >
> > like this:
> >
> >   assertThat(result)
> > .project()
> >   .hasTarget()
> > .withEarFile()
> >.containsOnlyOnce("META-INF/MANIFEST.MF");
> >
> > I've never seen a assertion framework which makes it possible to write
> > tests in a more or less fluent way ...
> >
>
> I did use it a few and dropped it since it does not bring much i  most
> cases.
> Asserts stay simple and chaining them just hit autoformatting limitations
> in general.
> Also assertj had some dependency conflicts - fixed now IIRC.
> So staying minimal was good.
>
> The side note being: do you need it or can you back your dsl with jupiter
> assertions? No strong need ;).
>
>
> > What would be your choice?
> >
>
> Just an available model, fluent if you want, but no additional dep.
> Default Assertions is enough for most cases, in particular with streams and
> lambdas.
>
>
> >
> > >
> > > Wonder if you evaluated to run in a fake filesystem like jimfs or so
> and
> > > enable the pom+files to be defined on the test method?
> >
> > This is exactly where I have decided against at the moment cause
> > construction of a full maven project with all it's pom file(s)
> > directories source code etc. is based on the things I want to solve to
> > complicated...we already have such things[2] also in plexus testcase you
> > can do such things or more easier today just use mockito ...
> >
>
> Hmm, this is not comparable.
> Mockito is like not writing tests, jimfs is launching a real build on a
> fake in memory filesystem, no mocking for maven.
>
>
> > Currently I have gone the path to have a convention where to find the
> > projects which are used to be tested like maven-invoker-plugin already
> > does ...and can also being executed manually within the directory
> > without any change ...helps a lot in case error hunting ...
> >
> > Can you explain the hint about fake filesystem like jimfs a little bit
> > more cause I don't know jimfs etc. and what you have in mind?
> >
>
> Jimfs is a FileSystem implementation so if maven uses java.nio.file api
> then we can run on an in memory FS and configure it from any metamodel we
> want.
>
> It would be close to this sftp testing api
>
> https://github.com/rmannibucau/rule-them-all/blob/master/src/test/java/com/github/rmannibucau/rules/test/sftp/TestSftpRule.java#L32


That would prevent the tests from running Maven in a different JVM... Not
sure if the JUnit extension supports that, but knowing the libraries likely
used I suspect it does


>
>
>
> >
> > [2]:
> >
> >
> https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/index.html
> >
> >  > > Goal would be to
> > > not split setup and asserts (given and then colocalized, then being the
> > > mvn exec).
> >
> > Maybe I misunderstand that? Can you give an example ?
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> >
> > >
> > > Hope it makes sense.
> >
> >
> > >
> > > Le mar. 29 oct. 2019 à 21:47, Karl Heinz Marbaise  > > > a écrit :
> > >
> > > Hi to all,
> > >
> > > I've invested some time to get a thing working in a different way
> > which
> > > nags me for a long time.
> > >
> > > Integration tests for maven plugins and for maven core...
> > >
> > > So created a prototype based on a JUnit Jupiter extension.
> > >
> > > The following is the JUnit Jupiter extension (currently very hacky
> > code;
> > > not 

Re: Docker image with initialized local cache saves 50 seconds in startup

[Stephen Connolly]

My script is for my cases. I'm just saying it's not rocket science, others
are doing it already

On Wed, 30 Oct 2019 at 13:31, Tibor Digana  wrote:

> Stephen, yeah something like you do in your scrip but it must not be a
> personal owner. Even Carloss is person who makes this deployment to
> DockerHub but his images are used by the entire world and we should decide
> whether we would agree with him to have such images under his
> responsibility or our responsibility as the Apache group. Then the script
> would be official and we can cut the release of Maven and the Docker image
> will be ready for the downloads together with the Maven distribution. So
> the users will always know that it is consistent deployment and they
> wouldn't expect that the image is missing for the new version.
>
> So here we should decide on who will be the deployer of these images with
> the cache. And the technical solution is smaller problem I would say.
>
> On Wed, Oct 30, 2019 at 10:28 AM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > On Wed 30 Oct 2019 at 08:21, Tibor Digana 
> wrote:
> >
> > > It's the situation when you have maven plugins in repo and it means
> that
> > > all custom plugins/deps can be still downloaded as before.
> > > Nothing exists like this in the world and we are talking about the
> > > approaches.
> > >
> >
> > Cough cough cough
> >
> >
> >
> https://github.com/stephenc/docker-git-java8-maven-vim/blob/168b9968deae418ca3fd63c63038e896255c6fe8/Dockerfile#L50
> >
> > There are issues, but it does shave a bit of time... though we end up
> > adding our common dependencies into the seed pom so that it is an
> effective
> > speed up
> >
> >
> > >
> > > I added Karl, Herve and Stephen in CC because we talked about this
> issue
> > > in ASF CON and Twitter.
> > >
> > > On Wed, Oct 30, 2019 at 6:36 AM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > >> Hi Tibor,
> > >>
> > >> It has two issues:
> > >>
> > >> 1. It will not be the right plugin versions in 90% of the cases
> (except
> > >> demo ;))
> > >> 2. It will miss all custom plugins
> > >>
> > >> Now question is: what happens if you mount your local repo when
> running
> > >> docker? It works as expected. Means we could use a custom entrypoint
> > >> printing a warning banner if it is not done probably instead of
> > incrasing
> > >> the image size without being sure to reach the original goal.
> > >>
> > >> Wdyt?
> > >>
> > >> Romain
> > >>
> > >> Le mer. 30 oct. 2019 à 02:03, Tibor Digana  a
> > >> écrit :
> > >>
> > >> > If you use Docker images with Maven with no mapping of cache to the
> > >> > volumes, you may notice that Maven downloads the plugins for the
> build
> > >> > lifecycle.
> > >> >
> > >> > This slows down the build because a lot of artifacts and plugins are
> > >> > initially downloaded.
> > >> > This takes 50 seconds which might be even longer than the productive
> > >> build
> > >> > itself (compiler, package, ...).
> > >> >
> > >> > We discussed this topic with Herve and Karl at the Apache CON 2019
> the
> > >> last
> > >> > time.
> > >> >
> > >> > Sometime the presentations were funny because the audience had to
> > wait a
> > >> > minute while the console was black where the Maven was downloading
> the
> > >> > plugins in the background.
> > >> > Nobody was sure what happened that time, whether the console hanged
> or
> > >> the
> > >> > Cloud server hanged, or another issue happened with the network.
> > >> >
> > >> > I made a test and triggered the default lifecycle on Maven and I
> > >> realized
> > >> > that the cache was really very little, cca 12 MB.
> > >> > So this little cache in the container would save 50 seconds which is
> > the
> > >> > improvement we are discussing.
> > >> >
> > >> > From the use point of view, the user would use a new base image `
> > >> > 3.6.2-jdk-14-prefetched` which is my idea.
> > >> >
> > >> > There are multiple technical solutions (range of plugins, extra pom,
> > >> > internal Maven plugin versions, etc).
> > >> >
> > >> > We understood that the best idea would be to have the image with the
> > >> cache
> > >> > in new Docker images produced by Carloss Sanchez.
> > >> >
> > >> > We are discussing this topic in [1] but we do not have a consensus
> on
> > >> who
> > >> > will develop the Docker scripts and how.
> > >> >
> > >> > We can continue here and we can propose a solution.
> > >> >
> > >> > [1] https://github.com/carlossg/docker-maven/issues/130
> > >> >
> > >> >
> > >> > Cheers
> > >> > Tibor17
> > >> >
> > >>
> > > --
> > Sent from my phone
> >
>

Re: Docker image with initialized local cache saves 50 seconds in startup

[Stephen Connolly]

On Wed 30 Oct 2019 at 08:21, Tibor Digana  wrote:

> It's the situation when you have maven plugins in repo and it means that
> all custom plugins/deps can be still downloaded as before.
> Nothing exists like this in the world and we are talking about the
> approaches.
>

Cough cough cough

https://github.com/stephenc/docker-git-java8-maven-vim/blob/168b9968deae418ca3fd63c63038e896255c6fe8/Dockerfile#L50

There are issues, but it does shave a bit of time... though we end up
adding our common dependencies into the seed pom so that it is an effective
speed up


>
> I added Karl, Herve and Stephen in CC because we talked about this issue
> in ASF CON and Twitter.
>
> On Wed, Oct 30, 2019 at 6:36 AM Romain Manni-Bucau 
> wrote:
>
>> Hi Tibor,
>>
>> It has two issues:
>>
>> 1. It will not be the right plugin versions in 90% of the cases (except
>> demo ;))
>> 2. It will miss all custom plugins
>>
>> Now question is: what happens if you mount your local repo when running
>> docker? It works as expected. Means we could use a custom entrypoint
>> printing a warning banner if it is not done probably instead of incrasing
>> the image size without being sure to reach the original goal.
>>
>> Wdyt?
>>
>> Romain
>>
>> Le mer. 30 oct. 2019 à 02:03, Tibor Digana  a
>> écrit :
>>
>> > If you use Docker images with Maven with no mapping of cache to the
>> > volumes, you may notice that Maven downloads the plugins for the build
>> > lifecycle.
>> >
>> > This slows down the build because a lot of artifacts and plugins are
>> > initially downloaded.
>> > This takes 50 seconds which might be even longer than the productive
>> build
>> > itself (compiler, package, ...).
>> >
>> > We discussed this topic with Herve and Karl at the Apache CON 2019 the
>> last
>> > time.
>> >
>> > Sometime the presentations were funny because the audience had to wait a
>> > minute while the console was black where the Maven was downloading the
>> > plugins in the background.
>> > Nobody was sure what happened that time, whether the console hanged or
>> the
>> > Cloud server hanged, or another issue happened with the network.
>> >
>> > I made a test and triggered the default lifecycle on Maven and I
>> realized
>> > that the cache was really very little, cca 12 MB.
>> > So this little cache in the container would save 50 seconds which is the
>> > improvement we are discussing.
>> >
>> > From the use point of view, the user would use a new base image `
>> > 3.6.2-jdk-14-prefetched` which is my idea.
>> >
>> > There are multiple technical solutions (range of plugins, extra pom,
>> > internal Maven plugin versions, etc).
>> >
>> > We understood that the best idea would be to have the image with the
>> cache
>> > in new Docker images produced by Carloss Sanchez.
>> >
>> > We are discussing this topic in [1] but we do not have a consensus on
>> who
>> > will develop the Docker scripts and how.
>> >
>> > We can continue here and we can propose a solution.
>> >
>> > [1] https://github.com/carlossg/docker-maven/issues/130
>> >
>> >
>> > Cheers
>> > Tibor17
>> >
>>
> --
Sent from my phone

Re: [VOTE] JDK 8 Minimum Requirement for Maven 3.7.0

[Stephen Connolly]

+1

On Tue 29 Oct 2019 at 20:11, Karl Heinz Marbaise  wrote:

> Hi to all,
>
> based on the discusion this is the formal VOTE to lift the minimum of
> Maven Core with version 3.7.0 to JDK 8 minimum.
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

Because maintaining Java 7 is a barrier to new contributors. It is tricky
enough to get Java 8 set up for some developers. Every version we support
adds complexity for contributors. Personally, I think we should be thinking
about dropping even Java 8 if we wait until next year and just follow the
latest LTS line... but I am happy to keep with Java 8 as a baseline for
now. Java 7 is only supported for a limited number of environments right
now, whereas Java 8 has multiple vendors supporting it against multiple
platforms at least until mid 2023.

We hold back the entire community if we stick on a base version for too
long.

On Tue, 29 Oct 2019 at 13:00, Michael Osipov <1983-01...@gmx.net> wrote:

> Why not have 3.7.0 plugin updates and other non-technical stuff, have it
> parallely maintained for some time and move with Maven 3.8.0 to Java 8
> next year?!
>
> Does that sound like a plan? I'd be happy with that. I'd also expect
> an announcement on dev@, announce@ and users@.
>
> Michael
>
> > Gesendet: Dienstag, 29. Oktober 2019 um 13:49 Uhr
> > Von: "Stephen Connolly" 
> > An: "Maven Developers List" 
> > Betreff: Re: [DISCUSS] Maven 3.7.0
> >
> > On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > We already have a version policy:
> > >
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
> > >
> >
> > (while that page says draft, the proposal was on-list in 2014 and just
> > converted into a wiki page afterwards - hence why the examples use 2014
> > dates)
> >
> >
> > > > The development line of Maven core should require a minimum JRE
> version
> > > that is no older than 18 months after the end of Oracle's public
> updates
> > > for that JRE version at the time that the first version of the
> development
> > > line was released, but may require a higher minimum JRE version if
> other
> > > requirements dictate a higher JRE version.
> > >
> > > End of public updates for Java 8 from Oracle was January 2019, thus if
> we
> > > cut a new minor version we would be Java 8 but not Java 7.
> > >
> > >
> > > On Tue, 29 Oct 2019 at 12:28, Tibor Digana 
> wrote:
> > >
> > >> Stephen, we are in loop.
> > >> Of course I know these technical things.
> > >> But I am saying, and I am not alone (Michael Osipov too), that I agree
> > >> with
> > >> sources 1.8, but there must be1.  the Vote with milestones regarding
> Maven
> > >> and another Vote regarding plugins, and 2. written list of pros/cons
> > >> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
> > >> another professions as well in the team).
> > >> You know, with video calls, all these public emails would be gone
> within
> > >> one or two hours, I am sure!
> > >> I am also sure that we will have another code preferences and
> therefore we
> > >> should have some guideline. For instance, I like to have clear OOP in
> the
> > >> public class/interfaces and Lambda in private code. And there are a
> lot of
> > >> stuff, like parallel streams ala thread pool of non-daemon threads,
> > >> performance of streams (when, how stream is constructed, etc), Date
> Time
> > >> API is new as well.
> > >>
> > >> No benefit for the community with J7 sources but yes with J8 code.
> Believe
> > >> me, this is true. Michael mentioned that as well.
> > >>
> > >
> > > Not true. Java 8 bytecode adds additional metadata that speeds up
> > > classloading (but only when the class graph is all Java 8)
> > >
> > >
> > >>
> > >> It is also true that we have a lot of bugs, and it is true that Maven
> > >> needs
> > >> to have breakthrough features like reproducible build and User POM,
> Docker
> > >> prefetched cache, etc.
> > >> I have no argument against these things. The only problem that I have
> and
> > >> Michael has is the way how this is managed but it is the only trivial
> > >> problem that we can solve between us.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
> > >> stephen.alan.conno...@gmail.com> wrote:
> > >>
> > >> > You cannot have Java 8 sources produce Java 7 bytecode with the
> Java 8's
> > >> > javac.

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

On Tue, 29 Oct 2019 at 12:49, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> We already have a version policy:
>> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
>>
>
> (while that page says draft, the proposal was on-list in 2014 and just
> converted into a wiki page afterwards - hence why the examples use 2014
> dates)
>

https://lists.apache.org/thread.html/41a693d0e5787fa8af33ab0724a95c3ed0374fe2d860c2357a5565a9@1392995450@%3Cdev.maven.apache.org%3E


>
>> > The development line of Maven core should require a minimum JRE version
>> that is no older than 18 months after the end of Oracle's public updates
>> for that JRE version at the time that the first version of the development
>> line was released, but may require a higher minimum JRE version if other
>> requirements dictate a higher JRE version.
>>
>> End of public updates for Java 8 from Oracle was January 2019, thus if we
>> cut a new minor version we would be Java 8 but not Java 7.
>>
>>
>> On Tue, 29 Oct 2019 at 12:28, Tibor Digana 
>> wrote:
>>
>>> Stephen, we are in loop.
>>> Of course I know these technical things.
>>> But I am saying, and I am not alone (Michael Osipov too), that I agree
>>> with
>>> sources 1.8, but there must be1.  the Vote with milestones regarding
>>> Maven
>>> and another Vote regarding plugins, and 2. written list of pros/cons
>>> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
>>> another professions as well in the team).
>>> You know, with video calls, all these public emails would be gone within
>>> one or two hours, I am sure!
>>> I am also sure that we will have another code preferences and therefore
>>> we
>>> should have some guideline. For instance, I like to have clear OOP in the
>>> public class/interfaces and Lambda in private code. And there are a lot
>>> of
>>> stuff, like parallel streams ala thread pool of non-daemon threads,
>>> performance of streams (when, how stream is constructed, etc), Date Time
>>> API is new as well.
>>>
>>> No benefit for the community with J7 sources but yes with J8 code.
>>> Believe
>>> me, this is true. Michael mentioned that as well.
>>>
>>
>> Not true. Java 8 bytecode adds additional metadata that speeds up
>> classloading (but only when the class graph is all Java 8)
>>
>>
>>>
>>> It is also true that we have a lot of bugs, and it is true that Maven
>>> needs
>>> to have breakthrough features like reproducible build and User POM,
>>> Docker
>>> prefetched cache, etc.
>>> I have no argument against these things. The only problem that I have and
>>> Michael has is the way how this is managed but it is the only trivial
>>> problem that we can solve between us.
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>> > You cannot have Java 8 sources produce Java 7 bytecode with the Java
>>> 8's
>>> > javac.
>>> >
>>> > -target must be >= -source
>>> >
>>> > So to say:
>>> >
>>> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>>> >
>>> > Is not possible, you'll get something like:
>>> >
>>> > $ javac Test -source 1.8 -target 1.7
>>> > javac: source release 1.8 requires target release 1.8
>>> >
>>> > While we could use something like
>>> https://github.com/luontola/retrolambda
>>> > its usage is not without significant risks. You really need to be very
>>> > careful in how you use it, and the effort is IMHO far exceeding the
>>> risk.
>>> > Much better to just say Maven 3.7.0 is requires the runtime JVM be
>>> Java 8+,
>>> > use toolchains if you need to compile or unit tests with older JDKs.
>>> >
>>> > We have agreed before that upgrading the Maven minor or major version
>>> would
>>> > affect the JREs that Maven can run on. Basically following a one and
>>> one
>>> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
>>> forced
>>> > to Java 8 as minimum anyway in other words, our us

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

On Tue, 29 Oct 2019 at 12:47, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> We already have a version policy:
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy
>

(while that page says draft, the proposal was on-list in 2014 and just
converted into a wiki page afterwards - hence why the examples use 2014
dates)


> > The development line of Maven core should require a minimum JRE version
> that is no older than 18 months after the end of Oracle's public updates
> for that JRE version at the time that the first version of the development
> line was released, but may require a higher minimum JRE version if other
> requirements dictate a higher JRE version.
>
> End of public updates for Java 8 from Oracle was January 2019, thus if we
> cut a new minor version we would be Java 8 but not Java 7.
>
>
> On Tue, 29 Oct 2019 at 12:28, Tibor Digana  wrote:
>
>> Stephen, we are in loop.
>> Of course I know these technical things.
>> But I am saying, and I am not alone (Michael Osipov too), that I agree
>> with
>> sources 1.8, but there must be1.  the Vote with milestones regarding Maven
>> and another Vote regarding plugins, and 2. written list of pros/cons
>> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
>> another professions as well in the team).
>> You know, with video calls, all these public emails would be gone within
>> one or two hours, I am sure!
>> I am also sure that we will have another code preferences and therefore we
>> should have some guideline. For instance, I like to have clear OOP in the
>> public class/interfaces and Lambda in private code. And there are a lot of
>> stuff, like parallel streams ala thread pool of non-daemon threads,
>> performance of streams (when, how stream is constructed, etc), Date Time
>> API is new as well.
>>
>> No benefit for the community with J7 sources but yes with J8 code. Believe
>> me, this is true. Michael mentioned that as well.
>>
>
> Not true. Java 8 bytecode adds additional metadata that speeds up
> classloading (but only when the class graph is all Java 8)
>
>
>>
>> It is also true that we have a lot of bugs, and it is true that Maven
>> needs
>> to have breakthrough features like reproducible build and User POM, Docker
>> prefetched cache, etc.
>> I have no argument against these things. The only problem that I have and
>> Michael has is the way how this is managed but it is the only trivial
>> problem that we can solve between us.
>>
>>
>>
>>
>>
>> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>> > You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
>> > javac.
>> >
>> > -target must be >= -source
>> >
>> > So to say:
>> >
>> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>> >
>> > Is not possible, you'll get something like:
>> >
>> > $ javac Test -source 1.8 -target 1.7
>> > javac: source release 1.8 requires target release 1.8
>> >
>> > While we could use something like
>> https://github.com/luontola/retrolambda
>> > its usage is not without significant risks. You really need to be very
>> > careful in how you use it, and the effort is IMHO far exceeding the
>> risk.
>> > Much better to just say Maven 3.7.0 is requires the runtime JVM be Java
>> 8+,
>> > use toolchains if you need to compile or unit tests with older JDKs.
>> >
>> > We have agreed before that upgrading the Maven minor or major version
>> would
>> > affect the JREs that Maven can run on. Basically following a one and one
>> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
>> forced
>> > to Java 8 as minimum anyway in other words, our users should be
>> > expecting us to go Java 8 as baseline.
>> >
>> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana 
>> wrote:
>> >
>> > > Stephen, what issue with current toolchain you mean?
>> > >
>> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
>> > > stephen.alan.conno...@gmail.com> wrote:
>> > >
>> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana 
>> > > wrote:
>> > > >
>> > > > > Robert, I saw the code. The class has a method which returns
>> Lambda
>> > > > > function. The whole class was designed with OOP. The OOP is a good
>> > > t

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

We already have a version policy:
https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy

> The development line of Maven core should require a minimum JRE version
that is no older than 18 months after the end of Oracle's public updates
for that JRE version at the time that the first version of the development
line was released, but may require a higher minimum JRE version if other
requirements dictate a higher JRE version.

End of public updates for Java 8 from Oracle was January 2019, thus if we
cut a new minor version we would be Java 8 but not Java 7.


On Tue, 29 Oct 2019 at 12:28, Tibor Digana  wrote:

> Stephen, we are in loop.
> Of course I know these technical things.
> But I am saying, and I am not alone (Michael Osipov too), that I agree with
> sources 1.8, but there must be1.  the Vote with milestones regarding Maven
> and another Vote regarding plugins, and 2. written list of pros/cons
> regarding J8 and 3. developer guideline for J8 (for devs, consultants,
> another professions as well in the team).
> You know, with video calls, all these public emails would be gone within
> one or two hours, I am sure!
> I am also sure that we will have another code preferences and therefore we
> should have some guideline. For instance, I like to have clear OOP in the
> public class/interfaces and Lambda in private code. And there are a lot of
> stuff, like parallel streams ala thread pool of non-daemon threads,
> performance of streams (when, how stream is constructed, etc), Date Time
> API is new as well.
>
> No benefit for the community with J7 sources but yes with J8 code. Believe
> me, this is true. Michael mentioned that as well.
>

Not true. Java 8 bytecode adds additional metadata that speeds up
classloading (but only when the class graph is all Java 8)


>
> It is also true that we have a lot of bugs, and it is true that Maven needs
> to have breakthrough features like reproducible build and User POM, Docker
> prefetched cache, etc.
> I have no argument against these things. The only problem that I have and
> Michael has is the way how this is managed but it is the only trivial
> problem that we can solve between us.
>
>
>
>
>
> On Tue, Oct 29, 2019 at 1:04 PM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
> > javac.
> >
> > -target must be >= -source
> >
> > So to say:
> >
> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> >
> > Is not possible, you'll get something like:
> >
> > $ javac Test -source 1.8 -target 1.7
> > javac: source release 1.8 requires target release 1.8
> >
> > While we could use something like
> https://github.com/luontola/retrolambda
> > its usage is not without significant risks. You really need to be very
> > careful in how you use it, and the effort is IMHO far exceeding the risk.
> > Much better to just say Maven 3.7.0 is requires the runtime JVM be Java
> 8+,
> > use toolchains if you need to compile or unit tests with older JDKs.
> >
> > We have agreed before that upgrading the Maven minor or major version
> would
> > affect the JREs that Maven can run on. Basically following a one and one
> > back for Oracle supported JDKs, thus 3.7.0 per that policy would be
> forced
> > to Java 8 as minimum anyway in other words, our users should be
> > expecting us to go Java 8 as baseline.
> >
> > On Tue, 29 Oct 2019 at 10:28, Tibor Digana 
> wrote:
> >
> > > Stephen, what issue with current toolchain you mean?
> > >
> > > On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> > > stephen.alan.conno...@gmail.com> wrote:
> > >
> > > > On Tue, 29 Oct 2019 at 08:02, Tibor Digana 
> > > wrote:
> > > >
> > > > > Robert, I saw the code. The class has a method which returns Lambda
> > > > > function. The whole class was designed with OOP. The OOP is a good
> > > thing
> > > > > which you should follow and follow this approach and not to return
> > the
> > > > > labda function. Basically it is a precedense created in the PR
> saying
> > > > that
> > > > > now J8 has to be used in the bytecode.
> > > > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > > > >
> > > >
> > > > That is not possible using the current toolchains. Let's just go with
> > > Java
> > > > 8. There seems no good reason to hold back
> > > >
> > > >
> > > > >
> > >

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

You cannot have Java 8 sources produce Java 7 bytecode with the Java 8's
javac.

-target must be >= -source

So to say:

> So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!

Is not possible, you'll get something like:

$ javac Test -source 1.8 -target 1.7
javac: source release 1.8 requires target release 1.8

While we could use something like https://github.com/luontola/retrolambda
its usage is not without significant risks. You really need to be very
careful in how you use it, and the effort is IMHO far exceeding the risk.
Much better to just say Maven 3.7.0 is requires the runtime JVM be Java 8+,
use toolchains if you need to compile or unit tests with older JDKs.

We have agreed before that upgrading the Maven minor or major version would
affect the JREs that Maven can run on. Basically following a one and one
back for Oracle supported JDKs, thus 3.7.0 per that policy would be forced
to Java 8 as minimum anyway in other words, our users should be
expecting us to go Java 8 as baseline.

On Tue, 29 Oct 2019 at 10:28, Tibor Digana  wrote:

> Stephen, what issue with current toolchain you mean?
>
> On Tue, Oct 29, 2019 at 11:11 AM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > On Tue, 29 Oct 2019 at 08:02, Tibor Digana 
> wrote:
> >
> > > Robert, I saw the code. The class has a method which returns Lambda
> > > function. The whole class was designed with OOP. The OOP is a good
> thing
> > > which you should follow and follow this approach and not to return the
> > > labda function. Basically it is a precedense created in the PR saying
> > that
> > > now J8 has to be used in the bytecode.
> > > So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
> > >
> >
> > That is not possible using the current toolchains. Let's just go with
> Java
> > 8. There seems no good reason to hold back
> >
> >
> > >
> > > On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte 
> > > wrote:
> > >
> > > > The outcome is quite clear to me. There no clear 'No' to add this
> > > > build/consumer feature into 3.7.0, so we'll add it which implies we
> > must
> > > > move to Java 8 due to new APIs with Java 8 class signatures.
> > > >
> > > > But first we need to deliver a 3.6.3 regression release.
> > > >
> > > > Robert
> > > >
> > > > On 29-10-2019 05:53:25, Romain Manni-Bucau 
> > > wrote:
> > > > +1, the risk is more or less 0 since we can still use branches for
> > > > potential fixes for "old" projects using frozen java and maven
> versions
> > > > anyway
> > > >
> > > > Guess we can even be very precautionous doing 1. an upgrade to
> bytecode
> > > > version without any code change (to change the major version in
> > > bytecode),
> > > > 2. a M1 to let users test it if some still doubt.
> > > >
> > > > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> > > >
> > > > > so what is the status of this?
> > > > > will we discuss in 2025 about being able to use java 8 apis or do
> we
> > > have
> > > > > to wait 2030?
> > > > > Sorry to be sarcastic but not moving forward it's certainly a
> reason
> > > why
> > > > we
> > > > > do not have more people participating in the project
> > > > > It is so frustrating to be stuck with old apis...
> > > > >
> > > > >
> > > > >
> > > > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > > > >
> > > > > > I have to fully agree on Michael Osipov. This discussion is
> > > > > > contraproductive from the time perspective.
> > > > > > He explained the situation in Maven very clearly that we have
> over
> > > 1800
> > > > > > bugs and here we are talking about javac compiler version which
> > does
> > > > not
> > > > > > fix these bugs.
> > > > > > We know that our community is quite big but we also know that we
> > have
> > > > > only
> > > > > > few several developers who regularily provides fixes for the bug
> > and
> > > > they
> > > > > > do it for free!
> > > > > > So my advice is to leave these talks alone about technology lobby
> > > (seen
> > > > > on
> > > > > > ML from outside as well) and rather concentrate on the bug

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

On Tue, 29 Oct 2019 at 08:02, Tibor Digana  wrote:

> Robert, I saw the code. The class has a method which returns Lambda
> function. The whole class was designed with OOP. The OOP is a good thing
> which you should follow and follow this approach and not to return the
> labda function. Basically it is a precedense created in the PR saying that
> now J8 has to be used in the bytecode.
> So I vote -1 for J8 bytecode, and I vote +1 for J8 source code!
>

That is not possible using the current toolchains. Let's just go with Java
8. There seems no good reason to hold back


>
> On Tue, Oct 29, 2019 at 8:25 AM Robert Scholte 
> wrote:
>
> > The outcome is quite clear to me. There no clear 'No' to add this
> > build/consumer feature into 3.7.0, so we'll add it which implies we must
> > move to Java 8 due to new APIs with Java 8 class signatures.
> >
> > But first we need to deliver a 3.6.3 regression release.
> >
> > Robert
> >
> > On 29-10-2019 05:53:25, Romain Manni-Bucau 
> wrote:
> > +1, the risk is more or less 0 since we can still use branches for
> > potential fixes for "old" projects using frozen java and maven versions
> > anyway
> >
> > Guess we can even be very precautionous doing 1. an upgrade to bytecode
> > version without any code change (to change the major version in
> bytecode),
> > 2. a M1 to let users test it if some still doubt.
> >
> > Le mar. 29 oct. 2019 à 04:06, Olivier Lamy a écrit :
> >
> > > so what is the status of this?
> > > will we discuss in 2025 about being able to use java 8 apis or do we
> have
> > > to wait 2030?
> > > Sorry to be sarcastic but not moving forward it's certainly a reason
> why
> > we
> > > do not have more people participating in the project
> > > It is so frustrating to be stuck with old apis...
> > >
> > >
> > >
> > > On Thu, 10 Oct 2019 at 04:36, Tibor Digana wrote:
> > >
> > > > I have to fully agree on Michael Osipov. This discussion is
> > > > contraproductive from the time perspective.
> > > > He explained the situation in Maven very clearly that we have over
> 1800
> > > > bugs and here we are talking about javac compiler version which does
> > not
> > > > fix these bugs.
> > > > We know that our community is quite big but we also know that we have
> > > only
> > > > few several developers who regularily provides fixes for the bug and
> > they
> > > > do it for free!
> > > > So my advice is to leave these talks alone about technology lobby
> (seen
> > > on
> > > > ML from outside as well) and rather concentrate on the bug. We have
> > seen
> > > > that the users/contributors handled performance issues and fixed them
> > > which
> > > > means that these contributors got very good proficiency level!
> > > >
> > > > On Wed, Oct 9, 2019 at 7:56 PM Alexander Ashitkin <>
> > > ashitkin.a...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Totally disagree on the point. Writing java7 code after 8 makes you
> > > feel
> > > > > suffering - because instead of expressive stream based operations
> and
> > > > > lambdas you write pointless iterators and copy collections.
> > > > > It is purely subjective opinion that lambdas make code less
> readable
> > -
> > > at
> > > > > least there is an absolutely opposite opinion
> > > > >
> > > > > Thank you
> > > > > Aleks
> > > > >
> > > > > On 2019/10/03 12:47:35, Paul Hammant wrote:
> > > > > > Who codes for 18 months before discovering that qa/prod are not
> > > > > compatible,
> > > > > > anymore? Especially if Google ship a use-this-Pom starter.
> > > > > >
> > > > > > On Thu, Oct 3, 2019 at 1:44 PM Elliotte Rusty Harold <>
> > > > elh...@ibiblio.org
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Theoretically that would work. In practice though, every
> project
> > > I've
> > > > > > > seen convert to Java 8 rapidly starts adding lambdas that make
> > the
> > > > > > > code more obfuscated for no good reason and soon introduces
> hard
> > > > > > > dependencies on Java 8, intentionally or otherwise. At a bare
> > > > minimum,
> > > > > > > a CI environment that runs Java 7 is required.
> > > > > > >
> > > > > > > On Thu, Oct 3, 2019 at 8:25 AM Paul Hammant
> > > > wrote:
> > > > > > > >
> > > > > > > > Would jdk 8 for maven itself and a target of 7 for the
> compiler
> > > > > (etc) for
> > > > > > > > maven-using projects be ok?
> > > > > > > >
> > > > > > > > On Thu, Oct 3, 2019 at 1:15 PM Elliotte Rusty Harold <>
> > > > > elh...@ibiblio.org
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Strong -1 on Java 8 as the minimum version. Google Cloud
> > > Platform
> > > > > has
> > > > > > > > > lots of products and customers that still require Java 7.
> If
> > > > Maven
> > > > > > > > > requires Java 8, we'd have to stick to the latest of
> > whichever
> > > > > release
> > > > > > > > > does support Java 7 for at least a year and I'm guessing
> > > longer.
> > > > > > > > >
> > > > > > > > > On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <>
> > > > > 

Re: Dynamic phases proposal

[Stephen Connolly]

On Sat 26 Oct 2019 at 10:50, Robert Scholte  wrote:

> To avoid confusion, let's call it stages.
>
> Stage 1: Always call post-bound executions (MNG-5665[1])
> Stage 2: before and after
> Stage 3: priorities (MNG-3522[2])
> Stage 4: transitional lifecycle


I have a prototype of stages 1-3 nearly (80%) done... just have to polish
up and validate the bound executions with some tests


>
> For both all you need to start evaluating the value of phase.
> For now we can assume that after:clean is just another label for
> post-clean and will have exactly the same effect.
> MNG-5665 contains a proposal to change the xml, but we shouldn't do that
> (yet). Let's start with a hardcoded list of postphases (or in case a goal
> fails, see if a post-x phase exists). Stage 1 is to make it work, stage 2
> to make it configurable.
> IIRC you cannot ask from inside a Mojo if is was called explicitly or
> because it was bound to a phase, nor can you ask for the value of this
> phase. I kind of like this, plugins shouldn't care about this.
> However, inside Maven it will become important at which phase it is to
> know if there are more executions to call OR create blocks of executions.
> Now it is just a list of executions: loop and fail fast.
>
> thanks,
> Robert
>
> [1] https://issues.apache.org/jira/browse/MNG-5665
> [2] https://issues.apache.org/jira/browse/MNG-3522
> On 25-10-2019 21:33:14, Stephen Connolly 
> wrote:
> Robert,
>
> I would be fine splitting out into, pardon the pun, phases:
>
> Phase 1: before and after
> Phase 2: priorities
> Phase 3: transitional lifecycle
>
> Might have a phase 1.5 of before:* and after:* to catch the start of a
> lifecycle and the end of a lifecycle...
>
> On Fri 25 Oct 2019 at 20:30, Stephen Connolly <
> stephen.alan.conno...@gmail.com [mailto:stephen.alan.conno...@gmail.com]>
> wrote:
>
> Robert, Michael, Tibor, let’s continue here (though I asked Infra and it’s
> fine that anyone in the community can join our Slack)
>
> On Fri 25 Oct 2019 at 20:01, Stephen Connolly <
> stephen.alan.conno...@gmail.com [mailto:stephen.alan.conno...@gmail.com]>
> wrote:
>
> https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases [
> https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases]
>
> Thoughts?
> --
>
> Sent from my phone
> --
>
> Sent from my phone
> --
>
> Sent from my phone

-- 
Sent from my phone

Re: Dynamic phases proposal

[Stephen Connolly]

On Fri 25 Oct 2019 at 22:48, Tamás Cservenák  wrote:

> I am referring to this sentence:
> "The logic of using :  in these prefix names is that it would expressly be
> impossible to invoke these dynamic pseudo phases from the CLI as Maven will
> interpret any attempt to invoke them as $plugin:$goal and look for a
> maven-before-plugin  or maven-after-plugin".
>

We can put specific checks in to give friendly error messages, but
fundamentally Maven will treat a CLI argument with one colon as a plugin
goal to execute separate from the lifecycle

We want the before and after phases to not be directly invoked via CLI or
invoker, and because you cannot have a phase with this name, it’s safe to
reuse


>
>
> On Fri, Oct 25, 2019 at 11:13 PM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > On Fri 25 Oct 2019 at 21:41, Tamás Cservenák 
> wrote:
> >
> > > The fixed phases were one of the main strengths of Maven, and with this
> > > automatism it could really be enhanced.
> > >
> > > My dislike: the `before:goal` invocation is being "projected" to non
> > > existent plugin invocation. This sounds like a hack. Could we clear
> that
> > > part up?
> >
> >
> > Could you explain what you mean? I’m not seeing what you are saying
> >
> >
> > >
> > > T
> > >
> > > On Fri, Oct 25, 2019 at 10:23 PM Emmanuel Bourg 
> > wrote:
> > >
> > > > Le 25/10/2019 à 21:01, Stephen Connolly a écrit :
> > > > > https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases
> > > > >
> > > > > Thoughts?
> > > >
> > > > Sounds interesting. You may want to forbid the before/after prefix on
> > > > the deprecated phases (such as after:pre-clean).
> > > >
> > > > The name of the phases use to start with a verb, that would no longer
> > be
> > > > true with the proposed 'sources' and 'resources' phases. Since it
> isn't
> > > > that common to invoke these phases directly from the command line
> maybe
> > > > the longer name could be retained to preserve the consistency
> > > > (generate-sources, etc).
> > > >
> > > > Emmanuel Bourg
> > > >
> > > > -
> > > > 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

Re: Dynamic phases proposal

[Stephen Connolly]

On Fri 25 Oct 2019 at 21:41, Tamás Cservenák  wrote:

> The fixed phases were one of the main strengths of Maven, and with this
> automatism it could really be enhanced.
>
> My dislike: the `before:goal` invocation is being "projected" to non
> existent plugin invocation. This sounds like a hack. Could we clear that
> part up?


Could you explain what you mean? I’m not seeing what you are saying


>
> T
>
> On Fri, Oct 25, 2019 at 10:23 PM Emmanuel Bourg  wrote:
>
> > Le 25/10/2019 à 21:01, Stephen Connolly a écrit :
> > > https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases
> > >
> > > Thoughts?
> >
> > Sounds interesting. You may want to forbid the before/after prefix on
> > the deprecated phases (such as after:pre-clean).
> >
> > The name of the phases use to start with a verb, that would no longer be
> > true with the proposed 'sources' and 'resources' phases. Since it isn't
> > that common to invoke these phases directly from the command line maybe
> > the longer name could be retained to preserve the consistency
> > (generate-sources, etc).
> >
> > Emmanuel Bourg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
-- 
Sent from my phone

Re: Hard requirements

[Stephen Connolly]

On Tue 22 Oct 2019 at 11:30, Elliotte Rusty Harold 
wrote:

> The docs at
> https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification
> say:
>
> 1.0: "Soft" requirement on 1.0 (just a recommendation, if it matches
> all other ranges for the dependency)
> [1.0]: "Hard" requirement on 1.0
>
> However, I don't think anywhere do we actually explain what a soft or
> a "Hard" requirement is. If someone can clarify this for me, I'll
> update the docs accordingly.
>

Ranges only come into affect when you have multiple dependencies using
ranges.

When you use ranges, Maven tries to satisfy all the requests.

A soft version is like: “I’d like this if I can have it”

A hard version is: “only this or die”

If your dependency tree has dependency foo being brought in by multiple
dependencies:

Maven first gets the intersection of all ranges

If there is more than one version left in the intersection, Maven looks at
the “nearest” soft version requests and if that fits the range it will use
that.

If your range is just a single version, that means only that version will
do, hence it becomes a hard specification.

Now having said all that, ranges have - to date - proven problematic. In
general it is better to avoid ranges at all... and that includes hard
version numbers.

Hopefully in Maven 5.0.0 we can find a way to make ranges at least
usable... but the reality is ranges are a hard problem in and if themselves.

>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Dynamic phases proposal

[Stephen Connolly]

Robert,

I would be fine splitting out into, pardon the pun, phases:

Phase 1: before and after
Phase 2: priorities
Phase 3: transitional lifecycle

Might have a phase 1.5 of before:* and after:* to catch the start of a
lifecycle and the end of a lifecycle...

On Fri 25 Oct 2019 at 20:30, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Robert, Michael, Tibor, let’s continue here (though I asked Infra and it’s
> fine that anyone in the community can join our Slack)
>
> On Fri 25 Oct 2019 at 20:01, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases
>>
>> Thoughts?
>> --
>> Sent from my phone
>>
> --
> Sent from my phone
>
-- 
Sent from my phone

Re: Dynamic phases proposal

[Stephen Connolly]

Robert, Michael, Tibor, let’s continue here (though I asked Infra and it’s
fine that anyone in the community can join our Slack)

On Fri 25 Oct 2019 at 20:01, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases
>
> Thoughts?
> --
> Sent from my phone
>
-- 
Sent from my phone

Dynamic phases proposal

[Stephen Connolly]

https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases

Thoughts?
-- 
Sent from my phone

Re: Proposal: maven release lifecycle

[Stephen Connolly]

On Sat 5 Oct 2019 at 08:14, Romain Manni-Bucau 
wrote:

> I like the words but fail to see the missing pieces (understand actions to
> do).
>
> Typically today when i release at work i use release plugin enriched with
> github page deployment for the doc using antora + a ftp update of my server
> output capture to have a mock backing openapi/swagger ui + docker ilage
> deployment on docker hub + an intellij plugin deployment on jetbrains
> marketplace etc...adding a flyway migration with a rolling update in a k8s
> cluster is trivial (ops need to say yes though ;)).
>
> So technically it is verbose but doable.
>
> Custom lifecycle definition is not neat, custom build tasks require a build
> hack or using groovy plugin but it works.


Such a pity my ship-maven-plugin never gained traction


>
> Typically, an extension could enable all that based on convention, just
> injecting needed plugins based on the file presence and values of the
> distribution urls.
>
> This is why i ended up thinking we are more on 1. Sugar in release plugin
> and 2. Maybe on a generic extension cretion (it replaces rigid lifecycle
> for such cases these days due to their writing easiness)
>
> Am I missing something?
>
> Le sam. 5 oct. 2019 à 08:23, Marco Schulz  a
> écrit :
>
> > Hello Romain, hello Tibor
> >
> > Thanks for your feedback. I had yesterday a very interesting conversation
> > with
> > Karl Heinz. He gave me some very informative links about deeply maven
> > insights.
> > Before I saw his talk on youtube I thought I have a good knowledge about
> > maven
> > ;-)  now I was lerning a lot of new things.
> >
> > He defined Maven as an plugin execution framework. I like to extend this
> > definition: Maven is a process engine framework and define industrial
> > defacto
> > standards for the software development process. And with this idea in
> mind
> > I
> > think it could be great to define more workflows in a equal manner like
> the
> > build lifecycle. The basic proposal is a first draft and I know some
> > points are
> > missing. I tried to keep the release process as simple as possible. Two
> > positions in this definition was impotent for me.
> >
> > Often companies don't really have well structured release processes. For
> > that
> > reason I would be great to have a workable standard. I have a small Java
> > project
> > on GitHub, an sometimes I also deploy to maven central. If you do this
> the
> > first
> > time a bit complicated process. And publishing on maven central is also a
> > release process. So I had the intention to define some ordered steps like
> > in the
> > build lifecycle to prepare and publish a release.
> >
> > Let me describe an example scenario for a release: After mvn build was
> > successful executed all unit tests are passed, the sprint is finished and
> > as
> > build manager we want to release our artifact. Very important would be an
> > option
> > to take the results from the build lifecycle and prepare the release. As
> > first
> > we need to see that the planned artifact version is not exist in any
> > configured
> > public repository and the pom contains all mandatory information for
> > publishing
> > on maven central(validate). To secure a reproducible build, in a second
> > step we
> > enforce that no SNAPSHOT artifacts are involved, the correct maven
> version
> > is
> > used etc. (the existing enforcer plugin do a great job). After the
> > preconditions
> > are fine we can execute external acceptance tests like JGiven. In another
> > step
> > the JavaDoc got generated. the pgp plugin sing the artifacts and check
> > that the
> > public key is available. The SCM plugin create a tag for the released
> > revision.
> > Difficult parts are auto increment the version number and auto check the
> > scm if
> > the release is produced with the last revision of the code. This actions
> > are by
> > my experience a bit error prune.
> > A release process could have some vocabulary like prepare, perform,
> > deploy. This
> > are just conventions, like it is used in the build lifecycle. To realize
> > this
> > idea, many already existing plugins can used, like the release plugin. In
> > this
> > proposal I was also not mentions external plugins to use like flyway, for
> > database versioning and so on. A lot of things ar imaginable.
> >
> > In future more lifecycles or workflows could be possible. For example a
> > deploy
> > lifecycle and so on. And then maven transform from a plugin execution
> > framework
> > to a process management framework, like Jason van Zyl described in his
> book
> > better build with maven.
> >
> > warm regards to all
> > .marco
> >
> >
> >
> >
> > On Fri, 2019-10-04 at 11:28 +0200, Romain Manni-Bucau wrote:
> > > @Tibor: I agree merging both in one "super" command can be neat (I
> always
> > > run both at once typically) but I disagree with last parts "skip the
> > test"
> > > - maven is also there to enforce tests as a good practise, if you don't
> > > automatically 

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

On Fri, 4 Oct 2019 at 12:39, Aleksandar Kurtakov 
wrote:

> On Fri, Oct 4, 2019 at 2:22 PM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > On Fri, 4 Oct 2019 at 12:03, Michael Osipov  wrote:
> > > I also won't participate in any further in-depth discussion
> > > for 3.7.0 for the reasons I have mentioned previously. I just don't see
> > > it fruitful.
> > > The technical debt we have is huge and we are not able to handle it.
> > >
> >
> > There is a chicken and egg situation though. A lot of the technical debt
> we
> > have is fall-out from being unable to evolve the pom. We cannot evolve
> the
> > pom without being able to split the build vs consumer pom, thus we keep
> > leaking the technical debt.
> >
> > And potential contributors will keep getting pushed away until we
> provide a
> > pom evolution path.
> >
> > We need more contributors, but to get them we need a way to help them
> > scratch their itches.
> >
> > 3.4.0 was the result of a new contributor trying to make progress... but
> > because we didn't have a clear path to solve evolution we ended up
> burning
> > that individual as a contributor.
> >
> > We need an evolution path.
> >
>
> Just Maven user here but involved in a number of other FOSS projects. We
> are seeing significant improvement in number of new contributors and their
> longevity since relaxing a bit the rules to not be all about supporting
> ancient versions of everything. And a project is its contributors - not
> managing to attract new guys and old guys getting tired is probably hardest
> one to solve.
>

There is also the marketing effect of requiring to support old versions.

When you say "oh must work on _insert_really_old_thing_" you are really
saying "we are not modern".

The paradox is that people want to work on modern stuff... but they really
want rock solid stable from the stuff they rely on.

So as a project, Maven needs to try and maintain our reputation for rock
solid stable... but we cannot do that if there is nobody to work on the
project... and getting people to work on the project requires an element of
"we are modern"

Now for a build tool, I think Java 11 is "too modern" right now... but Java
8 is around a long time now... I personally think it has been time to move
for a while now... but we have been lacking the reason (i.e. "lets switch
everything to lambdas is not a good reason") We now have a reason in the
XML APIs that Robert's changes require... thus we move to Java 8 IMHO

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

On Fri, 4 Oct 2019 at 12:03, Michael Osipov  wrote:

> Am 2019-09-28 um 14:05 schrieb Robert Scholte:
> > Hi,
> >
> > TLDR; introduce maven.experimental.buildconsumer and push Java
> > requirement to Java 8
> >
> > now that Maven 3.6.2 is out for a couple of weeks, it seems like we
> > didn't face real regressions.
> > The only one might be tricky is the issue related to Tycho.
> >
> > However, I think we're ready to push Maven to the next level.
> >
> > For those actively reading this list, they should recognize the need for
> > splitting up the pom as it is on the local system versus the pom being
> > uploaded. Once we truly control this mechanism we can think of
> > improvements on model 5.0.0 and new fileformats.
> >
> > I've created and implemented MNG-6656[1]. It also contains a zip with an
> > example (original, patched, README) to understand what's happening.
> >
> > In order to make this successful, we need IDEs and CI Servers to
> > understand and support these changes. The likely need to implement one
> > of the interfaces[2].
> > The new interface uses Java8 Functions (and especially SAXEventFactory
> > is way easier to read+maintain with Java 8). I've tried to keep Maven
> > Java 7 compatible, but that was too hard to do.
> > So I'd like to use this opportunity to move Maven forward and start
> > requiring Java 8.
> >
> > There are some other improvements I'd like to add (those messages will
> > follow), so this will imply that it will take some time before we do a
> > new release.
> >
> > WDTY,
> > Robert
> >
> > [1] https://issues.apache.org/jira/browse/MNG-6656
> > [2] https://github.com/apache/maven/compare/MNG-6656?expand=1
>
> Regardless of how good this sounds/is, we have quite other substantional
> issues to solve first this year, this is not a real world problem which
> needs to be solved instantly:
>
> 1. I would expect a formal vote for the bump and the justification for it.
> 2. Fix behavior changes for 3.7.0, update plugins (infrastructure if you
> like)
> 3. Really really clean up JIRA. We have *1864* unresolved issues! It
> *cannot* go on like that forever. I've been working hard this year to
> push a lot of components like SCM, Wagon, etc. Even in 3.6.2 I have
> addressed 25 issues.
>
> Personally, I don't have any motivation nor the mental/physical fitness
> and especially time to make any substantial contributions except leaving
> comments on JIRA issues or reviewing a PR at most for the next three to
> six months.


I would love to have the energy to work on Maven in the short term... I put
a lot of energy into the PDT proposal, but finding a way to move on that in
the current code base is tricky, hence why I haven't even started!


> I also won't participate in any further in-depth discussion
> for 3.7.0 for the reasons I have mentioned previously. I just don't see
> it fruitful.
> The technical debt we have is huge and we are not able to handle it.
>

There is a chicken and egg situation though. A lot of the technical debt we
have is fall-out from being unable to evolve the pom. We cannot evolve the
pom without being able to split the build vs consumer pom, thus we keep
leaking the technical debt.

And potential contributors will keep getting pushed away until we provide a
pom evolution path.

We need more contributors, but to get them we need a way to help them
scratch their itches.

3.4.0 was the result of a new contributor trying to make progress... but
because we didn't have a clear path to solve evolution we ended up burning
that individual as a contributor.

We need an evolution path.


> This is not intended to diminish your work anyhow, but to express our
> current situation from my personal view.
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

On Fri, 4 Oct 2019 at 09:48, Robert Scholte  wrote:

> Sorry Tibor, but I'm not going to do this.
>
> We've said that simply changing source/target(/release) to 1.8 is not a
> good reason to require Java 8.
> Now with the changes as mentioned in this thread (new APIs based on Java
> Functions) we finally have this good reason.
>
> I'm not going to explain why the move to Java 8 is important. I'm only
> interested in good arguments why to stay on Java 7 and so far I haven't
> seen any.
> People must understand that we're talking about the Java Runtime that
> Maven requires. There's a clear separation between Mavens runtime and the
> JDK. If you want to compile your code with an earlier JDK, that's already
> possible for a long time (but I guess most people simply use the Maven
> Runtime as their JDK).
>
> For those that argue that they must stay on Java 7 for their own projects
> must also keep in mind that with such statement they block the evolution
> of Maven for the whole Java community.
>
> I only saw a negative vote in relation with the Google Cloud Platform.
> Let
> this be a motivation for them to move forward too. Google should have
> enough resources to come up with a solution, either move to Java 8,
> maintain a backported version of Maven or maybe there are other solutions.
>
> Based on the responses on this thread I will continue with the proposed
> changed. A first PR has already been reviewed, and there are still a
> couple of TODO's I need to work on and I'll inform related tools
> regarding
> these changes.
>

+1


>
> I started the thread with one other question: do we need a 3.6.3
> regression release?
>

+1 to asking the question. Unclear to me if there is a need, but we should
certainly ask it especially if 3.7.0 will involve a big change in terms of
separation of the build pom from the consumer pom

The only thing I noticed are confirmations that there are regressions, but
> they are related to third party plugins/extensions/tools. Hopefully they
> can help analyze to help their own product.
> Based on that I'll put my focus fully Maven 3.7.0.
>
> thanks,
> Robert
>
> On Thu, 03 Oct 2019 20:22:06 +0200, Tibor Digana 
>
> wrote:
>
> > The topic related to TLS is only related to runtime, means JDK, which is
> > under the control of the particular user or CI.
> > I guess the user can easily find the answer:
> >
> https://stackoverflow.com/questions/50824789/why-am-i-getting-received-fatal-alert-protocol-version-or-peer-not-authentic
> >
> > The thing is that we need to specify:
> > + advantages of Java 1.8 in code (Lambda, brief code, maybe)
> > + disadvantages of Java 1.8 in code (Streams performance when/how/what
> > approach???)
> >
> > Write notices for developers on the internal Wiki:
> > + toolchains
> > + limitations and solutions for disadvantages
> > + conditions when and how to migrate from J7 to J8
> >
> > and then we should Vote for J8.
> >
> > And there are users who is has J6 and J7 and they may require us to
> > maintain the old version 3.6.x.
> > What to do in this case?
> > Is the toolchain enough? Usually it is in ordinal projects!
> >
> > Cheers
> > T
> >
> >
> > On Thu, Oct 3, 2019 at 5:52 PM Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> >> On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise 
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > On 03.10.19 17:03, Tibor Digana wrote:
> >> > > This is not very serious discussion since we saw users on our
> >> mailing
> >> > > list who said that he is using Java 1.6 compiler and JDK7 in Maven.
> >> >
> >> > Would that change anything? Using JDK 8 for Maven and using JDK 6 for
> >> > compiling/test...
> >> >
> >> >
> >> > > Serious discussion would uncover pros/cons and impact analysis.
> >> > >
> >> > > I would have a problem with Java 1.8 in target and source code but I
> >> > > have problem that we excluded our users from the VOTE.
> >> >
> >> > > Regarding Java 1.7 we clearly uncovered the migration plan,
> >> versions of
> >> > > plugins, core etc. Here nothing like that exists - only that
> >> somebody
> >> > > created a Jira ticket.
> >> >
> >> > Hm...all plugins etc. running on JDK 7+...so in the first step we just
> >> > upgrade the minimum for Maven Core only (3.7.0)... (Apart from
> having
> >> a
> >> > plugin which is JDK8 minimum a

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

On Thu, 3 Oct 2019 at 16:49, Karl Heinz Marbaise  wrote:

> Hi,
>
> On 03.10.19 17:03, Tibor Digana wrote:
> > This is not very serious discussion since we saw users on our mailing
> > list who said that he is using Java 1.6 compiler and JDK7 in Maven.
>
> Would that change anything? Using JDK 8 for Maven and using JDK 6 for
> compiling/test...
>
>
> > Serious discussion would uncover pros/cons and impact analysis.
> >
> > I would have a problem with Java 1.8 in target and source code but I
> > have problem that we excluded our users from the VOTE.
>
> > Regarding Java 1.7 we clearly uncovered the migration plan, versions of
> > plugins, core etc. Here nothing like that exists - only that somebody
> > created a Jira ticket.
>
> Hm...all plugins etc. running on JDK 7+...so in the first step we just
> upgrade the minimum for Maven Core only (3.7.0)... (Apart from having a
> plugin which is JDK8 minimum already).
>
> Plugins can upgrade to JDK 8 minimum as needed/wished afterwards (may be
> we could do a version identification...but at the moment I don't see a
> need for that cause they work on JDK7+).
>

Also, to my mind, unless the plugin specifically needs features in Maven
3.7.0 there is added reason for the plugin to stay on JDK7 until it bumps
the core version of Maven it depends on (or it finds a use-case requiring
Java 8)

Finally, upgrading to Java 8 is basically a must have for easier TLS
certificate validation as the JDK7 distributions do not all have good
current TLS root certs


> Kind regards
> Karl Heinz Marbaise
>
> >
> > Technically I would be interested if somebody could explain what NEW
> > Security API is in Java 1.8 and performance impact of Streams API.
> > That's the impact in the source code.
> > Somebody has other questions too.
> > Then we can write Wiki as well as rules, conditions and plan.
> >
> > Cheers
> > Tibor17
> >
> > On Thu, Oct 3, 2019 at 4:55 PM Karl Heinz Marbaise  > <mailto:khmarba...@gmx.de>> wrote:
> >
> > On 03.10.19 14:15, Elliotte Rusty Harold wrote:
> >  > Strong -1 on Java 8 as the minimum version. Google Cloud Platform
> has
> >  > lots of products and customers that still require Java 7. If Maven
> >  > requires Java 8, we'd have to stick to the latest of whichever
> > release
> >  > does support Java 7 for at least a year and I'm guessing longer.
> >
> > Hm.. first Java 7 is out for eight years now (2011) (End of live) and
> > has no public updates for security/bug fixes etc. since 2015
> >
> > Furthermore Java 8 is out for five years (2014) so to be honest I
> > wouldn't trust an environment which is not upgrading etc. in
> particular
> > in a clould environment...
> >
> > Why hadn't started Google to update their environment over the time
> to
> > JDK 8 etc. (I think they have much more resources than anyone).
> >
> >
> > One more thing is:
> >There is a difference between running Maven to build for example
> >with JDK 8 and running your resulting artifacts (see toolchain
> > comment
> >from Stephen Connolly..
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> >
> > [1]:
> > https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
> >
> >
> >  >
> >  > On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte
> > mailto:rfscho...@apache.org>> wrote:
> >  >>
> >  >> Hi,
> >  >>
> >  >> TLDR; introduce maven.experimental.buildconsumer and push Java
> > requirement
> >  >> to Java 8
> >  >>
> >  >> now that Maven 3.6.2 is out for a couple of weeks, it seems like
> > we didn't
> >  >> face real regressions.
> >  >> The only one might be tricky is the issue related to Tycho.
> >  >>
> >  >> However, I think we're ready to push Maven to the next level.
> >  >>
> >  >> For those actively reading this list, they should recognize the
> > need for
> >  >> splitting up the pom as it is on the local system versus the pom
> > being
> >  >> uploaded. Once we truly control this mechanism we can think of
> >  >> improvements on model 5.0.0 and new fileformats.
> >  >>
> >  >> I've created and implemented MNG-6656[1]. It also contains a zip
> > with an
> >  >> example (origin

Re: [DISCUSS] Maven 3.7.0

[Stephen Connolly]

+1 on Java 8 requirement for Maven runtime (note this still lets you
compile with Java 7 if you are prepared to use toolchains... the complexity
of using toolchains is an argument for improving/revisiting toolchains)

+1 on getting the place for filtering the pom.xml to produce the consumer
pom.xml, but I would go one step further. Enable it by default, but allow
opt-out. Also I would suggest to pick up a feature-flagging technique to
allow a project to opt out just by declaring the `maven.experimental.___`
property in the `pom.xml`. We should be clear that such flags will stop
working once the feature is confirmed solid, but NOBODY will turn the
experimental flag on, especially if it is a system property only flag...
and if we do not have confidence that the feature will work with both the
shade plugin and the gpg plugin then - quite frankly - the feature is not
ready

On Tue, 1 Oct 2019 at 18:31, Robert Scholte  wrote:

> https://github.com/apache/maven/pull/286
>
> On Tue, 01 Oct 2019 13:49:25 +0200, Enrico Olivelli 
>
> wrote:
>
> > Robert,
> > Can you create a PR?
> >
> > Enrico
> >
> > Il mar 1 ott 2019, 07:19 Sylwester Lachiewicz  ha
> > scritto:
> >
> >> +1 for Java 8 - let's kill 7 faster ;-))
> >>
> >> Sylwester
> >>
> >> wt., 1 paź 2019, 02:41 użytkownik Olivier Lamy 
> >> napisał:
> >>
> >> > +1 for Java 8
> >> > it's time now and we will probably having more contributions as
> >> young/cool
> >> > kids prefer using modern tools
> >> > Yup the world is not only made with Old Grumpy grand dad working only
> >> with
> >> > Java 5 :P )
> >> >
> >> > On Tue, 1 Oct 2019 at 04:14, Robert Scholte 
> >> wrote:
> >> >
> >> > > The versions upgrades of plugins are part of another topic, which
> >> are
> >> > > indeed 3.7.0 candidates.
> >> > >
> >> > > As said, the Java 8 update is not just about internal code
> >> improvements
> >> > > or
> >> > > changes. Maven will expose new APIs/SPIs that contain Java 8
> >> Functions,
> >> > > so
> >> > > it must be seen as a requirement to implement the experimental
> >> > > buildconsumer feature.
> >> > >
> >> > > Robert
> >> > >
> >> > > On Sat, 28 Sep 2019 14:23:16 +0200, Tibor Digana <
> >> tibordig...@apache.org
> >> > >
> >> > >
> >> > > wrote:
> >> > >
> >> > > > Hello guys,
> >> > > >
> >> > > > For the user community these two issues are important:
> >> > > > https://issues.apache.org/jira/browse/MNG-6169
> >> > > > https://issues.apache.org/jira/browse/MNG-6548
> >> > > > The Tycho project is the user as well.
> >> > > > The J8 is internal code improvement/change => lower priority
> than
> >> the
> >> > > > user's priority => release order/priorities/dedicated time spent
> >> in
> >> > > > development.
> >> > > >
> >> > > > Have a nice day.
> >> > > >
> >> > > > Cheers
> >> > > > Tibor17
> >> > > >
> >> > > > On Sat, Sep 28, 2019 at 2:08 PM Gary Gregory
> >>  >> >
> >> > > > wrote:
> >> > > >
> >> > > >> I would say that fixing the Tycho issue comes first.
> >> > > >>
> >> > > >> Gary
> >> > > >>
> >> > > >> On Sat, Sep 28, 2019 at 8:04 AM Robert Scholte <
> >> rfscho...@apache.org>
> >> > > >> wrote:
> >> > > >>
> >> > > >> > Hi,
> >> > > >> >
> >> > > >> > TLDR; introduce maven.experimental.buildconsumer and push Java
> >> > > >> > requirement
> >> > > >> > to Java 8
> >> > > >> >
> >> > > >> > now that Maven 3.6.2 is out for a couple of weeks, it seems
> >> like
> >> we
> >> > > >> > didn't
> >> > > >> > face real regressions.
> >> > > >> > The only one might be tricky is the issue related to Tycho.
> >> > > >> >
> >> > > >> > However, I think we're ready to push Maven to the next level.
> >> > > >> >
> >> > > >> > For those actively reading this list, they should recognize the
> >> need
> >> > > >> for
> >> > > >> > splitting up the pom as it is on the local system versus the
> >> pom
> >> > being
> >> > > >> > uploaded. Once we truly control this mechanism we can think of
> >> > > >> > improvements on model 5.0.0 and new fileformats.
> >> > > >> >
> >> > > >> > I've created and implemented MNG-6656[1]. It also contains a
> >> zip
> >> > > with
> >> > > >> an
> >> > > >> > example (original, patched, README) to understand what's
> >> happening.
> >> > > >> >
> >> > > >> > In order to make this successful, we need IDEs and CI Servers
> >> to
> >> > > >> > understand and support these changes. The likely need to
> >> implement
> >> > > >> one of
> >> > > >> > the interfaces[2].
> >> > > >> > The new interface uses Java8 Functions (and especially
> >> > > >> SAXEventFactory is
> >> > > >> > way easier to read+maintain with Java 8). I've tried to keep
> >> Maven
> >> > > >> Java 7
> >> > > >> > compatible, but that was too hard to do.
> >> > > >> > So I'd like to use this opportunity to move Maven forward and
> >> start
> >> > > >> > requiring Java 8.
> >> > > >> >
> >> > > >> > There are some other improvements I'd like to add (those
> >> messages
> >> > will
> >> > > >> > follow), so this will imply that it will take some time
> before
> >> we
> >> > 

Re: Anyone had an error on Eclipse IDE after upgrade maven-jar-plugin to 3.1.2?

[Stephen Connolly]

On Mon, 10 Jun 2019 at 13:36, Mickael Istria  wrote:

> Hi,
>
> On Mon, Jun 10, 2019 at 11:37 AM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > however
> > because of architectural history, Eclipse (last time I checked... some
> > years ago) had issues keeping the main and test classpaths separate
>
>
> This was fixed last year, during development of the "Photon" release:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=526858


Excellent to hear that!


>
>
>
> > and I hate Eclipse as and IDE
>
>
> If one day you're interested in sharing why, you can send the reasons
> behind this hate to whichever Eclipse community channel, or even DM me.
> I'll try to (with the help of the community) turn the hate into bug reports
> and then bugs into patches.
>

It's more a personal preference... and the way the display gets messed up
when debugging... and now I'm use to the IntelliJ crazy, so it seems normal
to me!

Re: Anyone had an error on Eclipse IDE after upgrade maven-jar-plugin to 3.1.2?

[Stephen Connolly]

Tibor,

If one is ranking correctness of integration with Maven of the various IDEs
then IntelliJ is not the "gold standard".

There are two *major* bugs in how IntelliJ handles Maven projects:

1. It does not allow different Java versions for test versus main trees:
https://youtrack.jetbrains.com/issue/IDEA-85478
2. It does not consult ArtifactHandler.isAddedToClasspath() and
consequently generates incorrect classpaths:
https://youtrack.jetbrains.com/issue/IDEA-175538

Both of these force users to contort their Maven projects in strange ways
just to make them work in their IDE.

>From my understanding, from the PoV of a Maven integration, the *gold
standard* IDE is probably NetBeans, largely because it falls back to Maven
to do the lifting. (Granted I do not use NetBeans, so I probably haven't
found the bugs in its integration :-P)

IIUC Eclipse could not have an issue like
https://youtrack.jetbrains.com/issue/IDEA-175538 because m2e doesn't suffer
from NIH syndrome when it comes to parsing the pom.xml files... however
because of architectural history, Eclipse (last time I checked... some
years ago) had issues keeping the main and test classpaths separate, which
is worse than https://youtrack.jetbrains.com/issue/IDEA-85478

(And to defend IntelliJ, there may actually be some good reasons for their
having NIH syndrome with respect to parsing the pom.xml files... but if
you're going to have NIH syndrome you had better put in the work to make
sure things actually work... and 2 years is a long time for
https://youtrack.jetbrains.com/issue/IDEA-175538 to sit there without even
a triage comment)

Now I personally don't like NetBeans as an IDE, and I hate Eclipse as and
IDE, so I continue to use IntelliJ despite its flaws... but I also
recognise that these are personal preferences of mine. IDEs are subjective.

Please try to remember what Clint Eastwood's character says about opinions
in the film Dirty Harry.

On Sat, 8 Jun 2019 at 16:01, Tibor Digana  wrote:

> No, it is not truth. And the price is nothing one cannot survive. IDEA is
> also OSS.
> User exp of IDEA is ideally joined together with Maven and working
> naturally well.
> Try Maven + IDEA and you will see. I used both.
>
> On Sat, Jun 8, 2019 at 4:51 PM Jeff MAURY  wrote:
>
> > because it's much better and oss
> >
> > Le sam. 8 juin 2019 à 10:29, Tibor Digana  a
> > écrit :
> >
> > > Why you use Eclipse. Use InteliJ IDEA. It is professional tool. Every
> > > company has money to buy enterprise IDEA, the company wouln'd say no
> > > because it is price you pay once and you can upgrade to major version
> > > within whole year. You can use it forever without paying more after the
> > > support period of one year you paid before. For instance I had IDEA 14
> > > since 2014 - 2019 without any issue in that tool.
> > >
> > > On Fri, Jun 7, 2019 at 3:32 PM Cristiano  wrote:
> > >
> > > > Hello,
> > > >
> > > > Yesterday I did an upgrade on some dependencies and plugins of my
> > > > company's master POM.
> > > >
> > > > I used the versions-plugin and changed many of the suggested ones.
> > After
> > > > conclude and build on CI without error, I ended up with a strange
> error
> > > > in Eclipse IDE (ubuntu, 201903, jdk11) on every project that has it
> as
> > > > its parent POM.
> > > >
> > > > The error has no description and its title is "Unknown".
> > > >
> > > >
> > > > It took some time to track the culprit down and after I have
> downgraded
> > > > the maven-jar-plugin to 3.1.1 the error was gone.
> > > >
> > > > I'm curious about this...
> > > >
> > > > best regards,
> > > >
> > > >
> > > > Cristiano
> > > >
> > > >
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> >
>

Re: Second MNG-6665: toolchain.xml file should support environment variables

[Stephen Connolly]

+1

On Fri 7 Jun 2019 at 13:22, Robert Scholte  wrote:

> Looking for a second approval
>
> Issue: https://issues.apache.org/jira/browse/MNG-6665 [
> https://issues.apache.org/jira/browse/MNG-6665]
> PR: https://github.com/apache/maven/pull/251 (I'll merge the commits)
> Jenkins result:
> https://builds.apache.org/job/maven-box/job/maven/job/MNG-6665/ [
> https://builds.apache.org/job/maven-box/job/maven/job/MNG-6665/]
>
> This patch was created during the Hackathon at Infosupport.
>
> thanks,
> Robert

-- 
Sent from my phone

Re: [VOTE] Retire Maven Downloader

[Stephen Connolly]

+1

On Fri 7 Jun 2019 at 14:32, Robert Scholte  wrote:

> Hi,
>
> The Apache Maven project consist of about 90 (sub)projects. Due to the
> small number of volunteers and the huge amount of code to maintain we're
> missing enough space to make real progress on all these projects, including
> our ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects
> and decide if it is worth maintaining.
>
> https://maven.apache.org/shared/maven-downloader/ [
> https://maven.apache.org/shared/maven-downloader/] describes the main
> purpose in one line: Provide a super simple interface for downloading a
> single artifact. Well, right now the preferred library to do so is either
> maven-resolver or maven-artifact-transfer.
> There have been only 2 releases, the last one was in December 2006.
>
> I therefore propose that we retire the maven-downloader.
>
> I don't think it makes sense to do a final release. Instead we should
> update the documentation and freeze the codebase.
>
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html [
> https://maven.apache.org/developers/retirement-plan-plugins.html]
>
> The vote is open for 72 hours.
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...
>
>
>
> --
Sent from my phone

Re: [MNG-6667] Hint at Maven upgrade requirement when trying to build a pom.xml with a newer modelVersion

[Stephen Connolly]

Merged

On Sun 2 Jun 2019 at 11:44, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I’m going to add a test where the “newer” pom has an incompatible schema
> with only modelVersion retained to ensure the parser errors get dismissed
> and we bomb early with the modelVersion complaint
>
> On Sat 1 Jun 2019 at 22:05, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> Ok I've switched to a dedicated comparator. The comparator you suggested
>> is not available on the classpath in that module and the other alternatives
>> you suggested could leak unintentionally side-effects.
>>
>> On Sat, 1 Jun 2019 at 16:03, Robert Scholte  wrote:
>>
>>> This is a bit awkward, a modelVersion is not an artifactVersion even
>>> though they have the same characteristics.
>>> Comparison will work, as would JavaVersion.
>>> I'd prefer a dedicated comparator or GenericVersionScheme
>>>
>>> Robert
>>>
>>> [1]
>>>
>>> https://maven.apache.org/resolver/apidocs/org/eclipse/aether/util/version/GenericVersionScheme.html
>>>
>>>
>>>
>>>
>>> On Sat, 01 Jun 2019 14:48:00 +0200, Stephen Connolly
>>>  wrote:
>>>
>>> > CI passed:
>>> > https://builds.apache.org/job/maven-box/job/maven/job/mng-6667/1/
>>> >
>>> > On Sat 1 Jun 2019 at 13:01, Stephen Connolly <
>>> > stephen.alan.conno...@gmail.com> wrote:
>>> >
>>> >> Finally got some time to do some work on Maven again... who knows
>>> how
>>> >> long
>>> >> it will last!!!
>>> >>
>>> >> https://issues.apache.org/jira/browse/MNG-6667
>>> >>
>>> >>
>>> >>
>>> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=7376a99093984c459f6a70cd1f508bbcf5ef26f7
>>> >>
>>> >> WDYT?
>>> >>
>>> >> If CI passes are we good to merge?
>>> >>
>>> >> -Stephen
>>>
>>> -
>>> 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

Re: [MNG-6667] Hint at Maven upgrade requirement when trying to build a pom.xml with a newer modelVersion

[Stephen Connolly]

I’m going to add a test where the “newer” pom has an incompatible schema
with only modelVersion retained to ensure the parser errors get dismissed
and we bomb early with the modelVersion complaint

On Sat 1 Jun 2019 at 22:05, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Ok I've switched to a dedicated comparator. The comparator you suggested
> is not available on the classpath in that module and the other alternatives
> you suggested could leak unintentionally side-effects.
>
> On Sat, 1 Jun 2019 at 16:03, Robert Scholte  wrote:
>
>> This is a bit awkward, a modelVersion is not an artifactVersion even
>> though they have the same characteristics.
>> Comparison will work, as would JavaVersion.
>> I'd prefer a dedicated comparator or GenericVersionScheme
>>
>> Robert
>>
>> [1]
>>
>> https://maven.apache.org/resolver/apidocs/org/eclipse/aether/util/version/GenericVersionScheme.html
>>
>>
>>
>>
>> On Sat, 01 Jun 2019 14:48:00 +0200, Stephen Connolly
>>  wrote:
>>
>> > CI passed:
>> > https://builds.apache.org/job/maven-box/job/maven/job/mng-6667/1/
>> >
>> > On Sat 1 Jun 2019 at 13:01, Stephen Connolly <
>> > stephen.alan.conno...@gmail.com> wrote:
>> >
>> >> Finally got some time to do some work on Maven again... who knows how
>> >> long
>> >> it will last!!!
>> >>
>> >> https://issues.apache.org/jira/browse/MNG-6667
>> >>
>> >>
>> >>
>> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=7376a99093984c459f6a70cd1f508bbcf5ef26f7
>> >>
>> >> WDYT?
>> >>
>> >> If CI passes are we good to merge?
>> >>
>> >> -Stephen
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>> --
Sent from my phone

Re: Drop tests for java 9 and 10?

[Stephen Connolly]

EOL not rolling (autocorrect)

On Sun 2 Jun 2019 at 10:27, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> +1 to Drop. They are rolling
>
> On Sun 2 Jun 2019 at 09:42, Enrico Olivelli  wrote:
>
>> Hi,
>> To me it is not clear if we should keep tests against java 9 and java 10.
>>
>> I think it is mostly a waste of resources and time.
>>
>> Do we have a clear and documented statement about which versions are
>> supported and tested ?
>>
>>
>> Thoughts?
>> Enrico
>>
> --
> Sent from my phone
>
-- 
Sent from my phone

Re: Drop tests for java 9 and 10?

[Stephen Connolly]

+1 to Drop. They are rolling

On Sun 2 Jun 2019 at 09:42, Enrico Olivelli  wrote:

> Hi,
> To me it is not clear if we should keep tests against java 9 and java 10.
>
> I think it is mostly a waste of resources and time.
>
> Do we have a clear and documented statement about which versions are
> supported and tested ?
>
>
> Thoughts?
> Enrico
>
-- 
Sent from my phone

Re: [MNG-6667] Hint at Maven upgrade requirement when trying to build a pom.xml with a newer modelVersion

[Stephen Connolly]

Ok I've switched to a dedicated comparator. The comparator you suggested is
not available on the classpath in that module and the other alternatives
you suggested could leak unintentionally side-effects.

On Sat, 1 Jun 2019 at 16:03, Robert Scholte  wrote:

> This is a bit awkward, a modelVersion is not an artifactVersion even
> though they have the same characteristics.
> Comparison will work, as would JavaVersion.
> I'd prefer a dedicated comparator or GenericVersionScheme
>
> Robert
>
> [1]
>
> https://maven.apache.org/resolver/apidocs/org/eclipse/aether/util/version/GenericVersionScheme.html
>
>
>
>
> On Sat, 01 Jun 2019 14:48:00 +0200, Stephen Connolly
>  wrote:
>
> > CI passed:
> > https://builds.apache.org/job/maven-box/job/maven/job/mng-6667/1/
> >
> > On Sat 1 Jun 2019 at 13:01, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> >> Finally got some time to do some work on Maven again... who knows how
> >> long
> >> it will last!!!
> >>
> >> https://issues.apache.org/jira/browse/MNG-6667
> >>
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=7376a99093984c459f6a70cd1f508bbcf5ef26f7
> >>
> >> WDYT?
> >>
> >> If CI passes are we good to merge?
> >>
> >> -Stephen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [MNG-6667] Hint at Maven upgrade requirement when trying to build a pom.xml with a newer modelVersion

[Stephen Connolly]

CI passed:
https://builds.apache.org/job/maven-box/job/maven/job/mng-6667/1/

On Sat 1 Jun 2019 at 13:01, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Finally got some time to do some work on Maven again... who knows how long
> it will last!!!
>
> https://issues.apache.org/jira/browse/MNG-6667
>
>
> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=7376a99093984c459f6a70cd1f508bbcf5ef26f7
>
> WDYT?
>
> If CI passes are we good to merge?
>
> -Stephen
>
-- 
Sent from my phone

[MNG-6667] Hint at Maven upgrade requirement when trying to build a pom.xml with a newer modelVersion

[Stephen Connolly]

Finally got some time to do some work on Maven again... who knows how long
it will last!!!

https://issues.apache.org/jira/browse/MNG-6667

https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=7376a99093984c459f6a70cd1f508bbcf5ef26f7

WDYT?

If CI passes are we good to merge?

-Stephen

Re: [VOTE] Retire Maven Ant Plugin

[Stephen Connolly]

+1

On Tue 28 May 2019 at 19:54, Robert Scholte  wrote:

> Hi,
>
> The Apache Maven project consist of about 100 (sub)projects. Due to the
> small number of volunteers and the huge amount of code to maintain we're
> missing enough space to make real progress on all these projects, including
> our ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects
> and decide if it is worth maintaining.
>
> The goal of the Apache Maven Ant Plugin it to generate Ant build files
> based on a pom.xml and was released for the last time in December 2014. Due
> to the different ways that Ant and Maven work I don't think it makes
> sense anymore to maintain a plugin to transform Maven files to Ant.
> See https://maven.apache.org/plugins/maven-ant-plugin/ [
> https://maven.apache.org/plugins/maven-ant-plugin/]
>
> To be clear, this is NOT the plugin you can use to run Ant within Maven;
> that's the maven-antrun-plugin.
>
> I therefore propose that we retire the maven-ant-plugin.
>
> I don't think it makes sense to do a final release. Instead we should
> update the documentation and freeze the codebase.
>
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html
>
> The vote is open for 72 hours.
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...

-- 
Sent from my phone

Re: Bumping Checkstyle plugin version to 3.1.0-SNAPSHOT (from 3.0.1-SNAPSHOT)

[Stephen Connolly]

On Sun 21 Apr 2019 at 16:24, Enrico Olivelli  wrote:

> Hi,
> I want to commit this breaking change [1] in checkstyle plugin,
> that is the upgrade [2] to latest checkstyle (8.x) and thus the making
> Java 8 the minimum version for the plugin.
>
> Currently I have 3.0.1-SNAPSHOT on master,
> I think I need to move to 3.1.0-SNAPSHOT.


+1


>
> Is is better to bump the version to 3.1.0-SNAPSHOT and then commit the
> breaking change or commit the change and then commit the new version ?
>
> I feel it is better to change the version to 3.1.0-SNAPSHOT and then
> commit the breaking change.
>
> Any review on the PR is well appreciated as well
>
> Best regards and Happy Easter !
> Enrico
>
> [1] https://github.com/apache/maven-checkstyle-plugin/pull/13
> [2] https://issues.apache.org/jira/browse/MCHECKSTYLE-366
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: [VOTE] Release Apache Maven Version 3.6.1

[Stephen Connolly]

I believe this meets the legal requirements for a release
I have not observed any critical regressions which meets the social
requirements for a release

+1 (binding)

Performance
==

My reference project at work (66 modules, with some craziness)

3.6.0 mvn clean install -DskipTests: Total time:  02:26 min
3.6.1 mvn clean install -DskipTests: Total time:  02:27 min

Commit CLA verification
==

https://github.com/apache/maven/commit/9c946263facbfa851fb646b3fac62cf1d3302ded
looks
small enough and intent to license is present
https://github.com/apache/maven/commit/95401cf7a606daa0982c3fe5a5928cd466230995
is
small enough and intent to license is confirmed on PR

All other commits from outside the Maven TLP originate from ASF committers
so CLA is on-file

-S.

On Tue, 9 Apr 2019 at 09:33, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> $ target/appassembler/bin/sra
> https://repository.apache.org/content/repositories/maven-1496 3.6.1
> Analyzer...
>
> stagingUrl: https://repository.apache.org/content/repositories/maven-1496
> groupId: org.apache.maven
> artifactId: apache-maven
> version: 3.6.1
>
> Source ZIP url exists.
>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-src.zip
>
> Source ZIP SHA1 url exists.
>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-src.zip.sha1
>
> Binary ZIP url exists.
>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.zip
>
> Binary ZIP SHA1 url exists.
>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.zip.sha1
>
> Calculated SHA1 of source ZIP matches published SHA1 of source ZIP.
> ec0618f981f9367f133a29fbfcaa8e073cb8ac85
>
> Calculated SHA1 of binary ZIP matches published SHA1 of binary ZIP.
> 21b21143e72162aaacd2cd14463ab55428f62b32
>
> Git revision of release as determined from
> maven-core-3.6.1.jar:org/apache/maven/messages/build.properties(buildNumber):
> d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555
>
> Files that are present in the source distribution but not in the source
> revision:
> DEPENDENCIES
>
>
> On Thu, 4 Apr 2019 at 20:55, Karl Heinz Marbaise 
> wrote:
>
>> Hi,
>>
>> We have solved 42 issues:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12338966
>>
>> There are issues left in JIRA for Maven core:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1496
>>
>> The distributable binaries and sources can be found here:
>>
>> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/
>>
>> Specifically the zip, tarball and source archives can be found here:
>>
>>
>> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.zip
>>
>> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.tar.gz
>>
>>
>> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-src.zip
>>
>> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-src.tar.gz
>>
>> The release artifacts are staged for distribution in:
>> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.0
>>
>> Source release checksum(s):
>> apache-maven-3.6.1-src.tar.gz
>>
>>sha1: 4e87c962ed505a0158085f99d92a0ade8c7fd197
>> sha512:
>>
>> 11a31022cffa0518584703fffd9fce998332ac5f6c2a50db3b590e90f3bdd1508d9e0cb5ba89a699ef6536b237bcc96166cfde3d45bce6346fa21b05b4d12bf8
>>
>> apache-maven-3.6.1-src.zip:
>>
>>sha1: ec0618f981f9367f133a29fbfcaa8e073cb8ac85
>> sha512:
>>
>> b92d8ed72585c4e05debe4d15eb9ae5dd72e814b6413bcba78d01282c9eccc38e79755654e0d0b4e5a650f0226c116a4a4faad731918a465ad424a2a81582a67
>>
>> Git tag:
>>
>> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555
>>
>> Staging site:
>> https://maven.apache.org/components/ref/3-LATEST/
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: [VOTE] Release Apache Maven Version 3.6.1

[Stephen Connolly]

Not yet... that's just the validator
https://github.com/jvanzyl/source-release-validator that checks things we
have historically failed to check... we should probably try and get JvZ to
tag it as Apache License v2 so we can maintain it here... or better yet
write a more fuller one... vote will be cast shortly, some more tests to
complete

On Tue, 9 Apr 2019 at 09:43, Karl Heinz Marbaise  wrote:

> Hi Stephen,
>
> should I count that as +1 ?
>
> Kind regards
> Karl Heinz Marbaise
> On 09.04.19 10:33, Stephen Connolly wrote:
> > $ target/appassembler/bin/sra
> > https://repository.apache.org/content/repositories/maven-1496 3.6.1
> > Analyzer...
> >
> > stagingUrl:
> https://repository.apache.org/content/repositories/maven-1496
> > groupId: org.apache.maven
> > artifactId: apache-maven
> > version: 3.6.1
> >
> > Source ZIP url exists.
> >
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-src.zip
> >
> > Source ZIP SHA1 url exists.
> >
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-src.zip.sha1
> >
> > Binary ZIP url exists.
> >
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.zip
> >
> > Binary ZIP SHA1 url exists.
> >
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.zip.sha1
> >
> > Calculated SHA1 of source ZIP matches published SHA1 of source ZIP.
> > ec0618f981f9367f133a29fbfcaa8e073cb8ac85
> >
> > Calculated SHA1 of binary ZIP matches published SHA1 of binary ZIP.
> > 21b21143e72162aaacd2cd14463ab55428f62b32
> >
> > Git revision of release as determined from
> >
> maven-core-3.6.1.jar:org/apache/maven/messages/build.properties(buildNumber):
> > d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555
> >
> > Files that are present in the source distribution but not in the source
> > revision:
> > DEPENDENCIES
> >
> >
> > On Thu, 4 Apr 2019 at 20:55, Karl Heinz Marbaise 
> wrote:
> >
> >> Hi,
> >>
> >> We have solved 42 issues:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12338966
> >>
> >> There are issues left in JIRA for Maven core:
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
> >>
> >> Staging repo:
> >> https://repository.apache.org/content/repositories/maven-1496
> >>
> >> The distributable binaries and sources can be found here:
> >>
> >>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/
> >>
> >> Specifically the zip, tarball and source archives can be found here:
> >>
> >>
> >>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.zip
> >>
> >>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.tar.gz
> >>
> >>
> >>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-src.zip
> >>
> >>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-src.tar.gz
> >>
> >> The release artifacts are staged for distribution in:
> >> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.0
> >>
> >> Source release checksum(s):
> >> apache-maven-3.6.1-src.tar.gz
> >>
> >> sha1: 4e87c962ed505a0158085f99d92a0ade8c7fd197
> >> sha512:
> >>
> >>
> 11a31022cffa0518584703fffd9fce998332ac5f6c2a50db3b590e90f3bdd1508d9e0cb5ba89a699ef6536b237bcc96166cfde3d45bce6346fa21b05b4d12bf8
> >>
> >> apache-maven-3.6.1-src.zip:
> >>
> >> sha1: ec0618f981f9367f133a29fbfcaa8e073cb8ac85
> >> sha512:
> >>
> >>
> b92d8ed72585c4e05debe4d15eb9ae5dd72e814b6413bcba78d01282c9eccc38e79755654e0d0b4e5a650f0226c116a4a4faad731918a465ad424a2a81582a67
> >>
> >> Git tag:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555
> >>
> >> Staging site:
> >> https://maven.apache.org/components/ref/3-LATEST/
> >>
> >> Vote open for 72 hours.
> >>
> >> [ ] +1
> >> [ ] +0
> >> [ ] -1
> >>
> >> Kind regards
> >> Karl Heinz Marbaise
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >
> H
>
> Mit freundlichem Gruß
> Karl-Heinz Marbaise
> --
> SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
> Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
> Hauptstrasse 177
> 52146 Würselen   http://www.soebes.de
>

Re: [VOTE] Release Apache Maven Version 3.6.1

[Stephen Connolly]

$ target/appassembler/bin/sra
https://repository.apache.org/content/repositories/maven-1496 3.6.1
Analyzer...

stagingUrl: https://repository.apache.org/content/repositories/maven-1496
groupId: org.apache.maven
artifactId: apache-maven
version: 3.6.1

Source ZIP url exists.
https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-src.zip

Source ZIP SHA1 url exists.
https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-src.zip.sha1

Binary ZIP url exists.
https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.zip

Binary ZIP SHA1 url exists.
https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.zip.sha1

Calculated SHA1 of source ZIP matches published SHA1 of source ZIP.
ec0618f981f9367f133a29fbfcaa8e073cb8ac85

Calculated SHA1 of binary ZIP matches published SHA1 of binary ZIP.
21b21143e72162aaacd2cd14463ab55428f62b32

Git revision of release as determined from
maven-core-3.6.1.jar:org/apache/maven/messages/build.properties(buildNumber):
d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555

Files that are present in the source distribution but not in the source
revision:
DEPENDENCIES


On Thu, 4 Apr 2019 at 20:55, Karl Heinz Marbaise  wrote:

> Hi,
>
> We have solved 42 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12338966
>
> There are issues left in JIRA for Maven core:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1496
>
> The distributable binaries and sources can be found here:
>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/
>
> Specifically the zip, tarball and source archives can be found here:
>
>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.zip
>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-bin.tar.gz
>
>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-src.zip
>
> https://repository.apache.org/content/repositories/maven-1496/org/apache/maven/apache-maven/3.6.1/apache-maven-3.6.1-src.tar.gz
>
> The release artifacts are staged for distribution in:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.0
>
> Source release checksum(s):
> apache-maven-3.6.1-src.tar.gz
>
>sha1: 4e87c962ed505a0158085f99d92a0ade8c7fd197
> sha512:
>
> 11a31022cffa0518584703fffd9fce998332ac5f6c2a50db3b590e90f3bdd1508d9e0cb5ba89a699ef6536b237bcc96166cfde3d45bce6346fa21b05b4d12bf8
>
> apache-maven-3.6.1-src.zip:
>
>sha1: ec0618f981f9367f133a29fbfcaa8e073cb8ac85
> sha512:
>
> b92d8ed72585c4e05debe4d15eb9ae5dd72e814b6413bcba78d01282c9eccc38e79755654e0d0b4e5a650f0226c116a4a4faad731918a465ad424a2a81582a67
>
> Git tag:
>
> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555
>
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven enforcer rules with access to current project

[Stephen Connolly]

You can change the phase the execution is bound to to put it in the
process-classes phase if your rule needs to validate the classes

On Wed, 20 Mar 2019 at 15:43, Elliotte Rusty Harold 
wrote:

> Yesterday one of our developers uncovered a major architectural flaw
> in one of our projects. Before we back up and do something different I
> want to make sure our current thoughts are accurate.
>
> As best we can tell it seems that Maven enforcer rules cannot read the
> code from the current project (the one whose pom.xml includes the
> enforcer rule) because enforcer rules execute in the validation phase
> before the project is compiled.
>
> Is this accurate or is there some way we could execute the enforcer
> rule in the verify phase instead? Or somehow have access to the
> current compiled source code from the validate phase?
>
> If not, we're probably going to have to rewrite our enforcer rule as
> an independent maven plugin.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: versions:use-latest-versions and dependency:copy-dependencies

[Stephen Connolly]

The Maven model of project dependencies is resolved as part of the build
plan because the transitive dependencies could affect the build order.

An example (contrived, but possible).

I have two modules: foo and bar

foo depends on bar

bar depends on a 3rd library that is external to the reactor: manchu

so we have for foo

foo:1.0-SNAPSHOT
-> bar:1.0-SNAPSHOT
-> manchu:1.0

The manchu project happens to add a dependency on bar:1.0

So now we have for foo

foo:1.1-SNAPSHOT
-> bar:1.1-SNAPSHOT
-> manchu:1.1
[-> bar:1.0 but as bar:1.1-SNAPSHOT is nearer, we use that]

Now what happens though if you are working on foo and machu at the same
time?

So you create a new "throwaway" reactor pom:


  manchu
  foo-parent


The build plan would initially (i.e. before we tie in the versions and we
are just building the aggregator) be:

manchu:1.2-SNAPSHOT (because listed first in the  indicative
preferred order)
foo-parent:1.1-SNAPSHOT (because parent of bar)
bar:1.1-SNAPSHOT (because required to be built before foo)
foo:1.1-SNAPSHOT (because this completes foo-parent)

Next we update the dependency of foo to link in the manchu from the reactor

So now we have for foo

foo:1.1-SNAPSHOT
-> bar:1.1-SNAPSHOT
-> manchu:1.2-SNAPSHOT
[-> bar:1.0 but as bar:1.1-SNAPSHOT is nearer, we use that]

The build plan now becomes:

manchu:1.2-SNAPSHOT (because listed first in the  indicative
preferred order)
foo-parent:1.1-SNAPSHOT (because parent of bar)
bar:1.1-SNAPSHOT (because required to be built before foo)
foo:1.1-SNAPSHOT (because this completes foo-parent)

Next we say, oh but we should be using the latest bar when building manchu
so that my IDE can single-step correctly... so now we have

foo:1.1-SNAPSHOT
-> bar:1.1-SNAPSHOT
-> manchu:1.2-SNAPSHOT
[-> bar:1.1-SNAPSHOT but we have that already]

The build plan now becomes

foo-parent:1.1-SNAPSHOT (because parent of bar)
bar:1.1-SNAPSHOT (because required to be built before foo and manchu)
manchu:1.2-SNAPSHOT (because we need to build manchu after bar and before
foo)
foo:1.1-SNAPSHOT (because this completes foo-parent)

There are other ways that the build plan can be affected, more typically
using dependencyManagement to override dependencies. But the long and the
short of it is that when you change dependency versions you could end up
affecting the build plan.

Our current solution to this is that the effective model and the build plan
are locked before we start building. If you want to change the pom then you
would need to either use the maven invoker plugin to fork a new maven
session or use two executions. (and bonus hint, this is one of the reasons
why the release:perform goal uses a forked maven execution, so that the
release poms get parsed)

On Tue, 22 Jan 2019 at 08:08, Anders Nyström  wrote:

> Hi,
>
> I am using versions:use-latest-versions in an early phase
> (generate-sources) in my maven build and it works nice. It updates the
> versions I want, but when I use it together with
> dependency:copy-dependencies that I have in a later phase
> (process-resources) of my maven build something gets wrong. The dependency
> copied is the dependency version used before it was updated with
> versions:use-latest-versions. Its impossible to fix this in the pom and the
> only way to solve it is to have it in two different commandes. like for eg
> mvn clean versions:use-latest-versions && mvn install, this is not good
> because its needs to be done in two different steps. I want the simplest
> possible command like mvn clean install only.
>
> In pom:
> 
> org.codehaus.mojo
> versions-maven-plugin
> 2.7
> 
>
>
> file:///${session.executionRootDirectory}/config/maven-version-rules.xml
>
> 
> 
>
>   generate-sources
>   
>  use-latest-versions
>   
>
> 
>  
> .
> 
> 3.1.1
> org.apache.maven.plugins
> maven-dependency-plugin
> 
>
>   copy-dependencies
>   process-resources
>   
>  copy-dependencies
>   
>   
>
> ${project.distribution.directory}
>  true
>  true
>   
>
> 
>  
> ...
> Output:
> [INFO] --- versions-maven-plugin:2.7:use-latest-versions (default) @ kalle
> ---
> [INFO] Major version changes allowed
> [INFO] artifact se.apa:olle: checking for updates from development
> [INFO] Updated se.apa:olle:jar:2019.1.9559-280 to version 2019.1.9572-287
> .
> Later in output:
> [INFO] --- maven-dependency-plugin:3.1.1:copy-dependencies
> (copy-dependencies) @ kalle ---
> [INFO] Copying olle-2019.1.9559-280.jar to
> 

Re: Releasing Maven enforcer plugin

[Stephen Connolly]

+1

On Wed, 16 Jan 2019 at 12:56, Enrico Olivelli  wrote:

> An user is asking for a release of the enforcer plugin
>
> https://github.com/apache/maven-enforcer/pull/36#issuecomment-447238729
>
> I can prepare the release
>
> Thoughts?
> Enrico
> --
>
>
> -- Enrico Olivelli
>

Re: Enable Travis on Maven Scripting Plugin

[Stephen Connolly]

Go for it. Nobody said no (and forgiveness is sometimes easier than
permission)

Ask infra which they prefer, all in one go or one at a time

On Tue 15 Jan 2019 at 20:36, Enrico Olivelli  wrote:

> ping
>
> Il giorno gio 10 gen 2019 alle ore 20:29 Enrico Olivelli
>  ha scritto:
> >
> > 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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: [jira] [Created] (MPOM-215) Create a new parent POM to lock down plugins versions of default lifecycle bindings

[Stephen Connolly]

false in the executions?

On Tue, 15 Jan 2019 at 16:04, Hervé BOUTEMY  wrote:

> initial content published, as a branch in maven-studies [1]
>
> I have a few issues that currently will block any release:
> 1. how to configure release plugin without leaking into future projects
> that
> will inherit?
> 2. how to configure invoker also to be able to create ITs to check that it
> works as expected?
>
> On documenting, I started the index.apt.
> Currently, packaging plugins do nothing in general, since it's Maven core
> that
> does the job: I'm curious to see how archetype-packaging is injected when
> configured as extension [2]. But I'm sure that we could override Maven
> core's
> default bindings: the only requirement will be to make the effort to
> create
> dedicated packaging artifacts, to avoid putting the whole plugin's
> dependencies in core classloader
>
> feedback welcome
>
> Regards,
>
> Hervé
>
> [1] https://github.com/apache/maven-studies/tree/maven-default-plugins
>
> [2] https://maven.apache.org/archetype/archetype-packaging/
>
> Le lundi 14 janvier 2019, 23:21:05 CET Robert Scholte a écrit :
> > Introducing a new parent might help for some, but not for everybody.
> > If you already have a parent specified, you can't use this.
> > And Maven doesn't support mixins (yet).
> >
> > We need to document how plugins are controlled.
> > These are probably all variants I can think of
> > - pom.xml
> > - via packaging-plugin
> > - parent (custom or new maven-defaults-plugins)
> > - super pom
> > - maven core
> >
> > thanks,
> > Robert
> >
> > On Mon, 14 Jan 2019 12:01:00 +0100, Hervé Boutemy (JIRA) <
> j...@apache.org>
> >
> > wrote:
> > > Hervé Boutemy created MPOM-215:
> > > --
> > >
> > >  Summary: Create a new parent POM to lock down plugins
> > >
> > > versions of default lifecycle bindings
> > >
> > >  Key: MPOM-215
> > >  URL: https://issues.apache.org/jira/browse/MPOM-215
> > >
> > >  Project: Maven POMs
> > >
> > >   Issue Type: New Feature
> > >
> > > Reporter: Hervé Boutemy
> > >
> > > while working on version upgrade of default plugin bindings, we found
> > > that:
> > > 1. a warning should be displayed MNG-6562
> > > 2. a parent POM would be the easiest solution to lock down every
> plugins
> > > at once, instead of letting users lock down each plugin separately
> > >
> > > let's create this parent POM
> > >
> > >
> > >
> > > --
> > > This message was sent by Atlassian JIRA
> > > (v7.6.3#76005)
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> 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]

I think where we want to go is warnings and no version injected. Thus if
you ignore the warnings you get latest version always *and* we don’t have
to update the versions ever. ;-)

Add a CLI option to fail if versions unspecified.

Start publishing base parent poms defining a profile of plugin versions
(and when 5.0.0 comes along they become mixins)

If we publish a base parent pom then users can just follow that. It could
use semver to decide how aggressively to bump versions.

Imho we need to get out of the game of supplying versions to users from the
Maven tool itself

On Sun 13 Jan 2019 at 11:16, Tibor Digana  wrote:

> Robert, your email still was not totally concrete.
> I understand it like this; the warnings proposed by Herve been introduced
> in the nearest version 3.6.x, and an update of default bindings in 3.7.0.
> Do we understand it in the same roadmap?
>
> In my experiences, developers do not read warnings because they do not have
> time and they expect Maven been an executor which should "just work". Even
> nobody cares in the log at all except the end, whether it is BUILD SUCCESS
> or failure. And then the people track failed tests or compilations errors,
> but never the log or warnings on the top, never.
>
> T
>
>
> On Sun, Jan 13, 2019 at 11:37 AM Robert Scholte 
> wrote:
>
> > This is indeed a good approach.
> > The first group doesn't care about this warning, the second one should.
> >
> > Hervé, can you confirm that in case of *only* specifying the latest
> > maven-jar-plugin or maven-war-plugin or other packaging plugin, you won't
> > get these warnings.
> > It really matters where the default lifecycle bindings are comings from:
> > maven-core or packaging plugin.
> >
> > All this is an interesting feature worth for 3.7.0
> >
> > thanks,
> > Robert
> >
> > On Sun, 13 Jan 2019 04:39:15 +0100, Hervé BOUTEMY  >
> >
> > wrote:
> >
> > > we have 2 opposite objectives:
> > > - make default near-empty pom work at best,
> > > - but force people to have defined plugins versions (then not really
> > > empty pom) to get stable build
> > >
> > > and I checked about the warning message: I was wrong, there is no
> > > warning message when plugins without versions are injected by default
> > > lifecycle bindings
> > >
> > > Just test for yourself following pom.xml from any beginner:
> > >   
> > > 4.0.0
> > > com.mycompany.app
> > > my-app
> > > 1.0-SNAPSHOT
> > >   
> > >
> > > it works = what we expect to ease newcomers experience
> > > but there is no warning...
> > >
> > > IMHO, this is where we need to improve the tool, by adding a warning:
> > > I worked on a PoC of DefaultLifecycleBindingsInjector improvement that
> > > displays:
> > > [WARNING]
> > > [WARNING] Some problems were encountered while building the effective
> > > model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> > > [WARNING] Using default plugins versions from bindings:
> > > [org.apache.maven.plugins:maven-clean-plugin,
> > > org.apache.maven.plugins:maven-install-plugin,
> > > org.apache.maven.plugins:maven-resources-plugin,
> > > org.apache.maven.plugins:maven-surefire-plugin,
> > > org.apache.maven.plugins:maven-compiler-plugin,
> > > org.apache.maven.plugins:maven-jar-plugin,
> > > org.apache.maven.plugins:maven-deploy-plugin,
> > > org.apache.maven.plugins:maven-site-plugin]
> > > [WARNING]
> > > [WARNING] It is highly recommended to fix these problems because they
> > > threaten the stability of your build.
> > > [WARNING]
> > > [WARNING] For this reason, future Maven versions might no longer
> > support
> > > building such malformed projects.
> > > [WARNING]
> > >
> > > With this warning, and a parent pom to have an easy fix (instead of 8
> > > plugins versions definition), IMHO, we have what we strongly need.
> > >
> > > And even better, with this warning in place to avoid people to continue
> > > to rely on default plugins versions (because of the nasty warning), I
> > > could find upgrading default plugins versions not an issue any more!!!
> > >
> > > Should we try to go this route?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le dimanche 13 janvier 2019, 00:15:38 CET Stephen Connolly a écrit :
> > >> The original plan was to make plugin version mandatory. Perhaps 3.7.0
> is
> > >> the t

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

[Stephen Connolly]

The original plan was to make plugin version mandatory. Perhaps 3.7.0 is
the time to do that, with a CLI option (to be removed after 3.7.x) to pull
in the 3.6.x default versions if your pom is missing plugin versions.

The warning has been there long enough. Let’s pull the trigger.

On Sat 12 Jan 2019 at 21:34, Tibor Digana  wrote:

> I have a strong reason to update Surefire due to new JRE versions have been
> updated too many times last two years.
> They required a fix done within a few days and some of them are shaking on
> the chair...
> Our Maven Core is stable and Java 9+ ready but the obsolete plugins are
> not.
> I want only the same compatibility with default plugins because people do
> not see these plugins as a distinct community. They are both Maven and
> plugins from us Apache, so they most probably would expect it consistent
> altogether.
> Makes sense?
>
> On Sat, Jan 12, 2019 at 7:24 PM Bernd Eckenfels 
> wrote:
>
> > I think that’s a real bad idea if you have to do local modifications to
> > get to a working build environment. Maven is all about not requiring you
> to
> > do that (anymore). So even requiring a certain Maven Version does not fit
> > in that pattern (although unavoidable if you do not want to work with
> > wrappers).
> >
> > So this means: keep old standard versions and overwrite them always in
> > poms. (And it means the amount of default versions should be reduced or
> at
> > least not add new ones)
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> >
> > 
> > Von: Robert Scholte 
> > Gesendet: Samstag, Januar 12, 2019 5:07 PM
> > An: Maven Developers List
> > Betreff: Re: Update versions of all plugins in default-bindings.xml
> >
> > I had chats with both Adam Bien and Sebastian Daschner asking for a
> better
> > way to work with a simple high-speed throw-away development pom.
> >
> > They are both working a lot with Java EE applications and want to rely on
> > defaults as much as possible.
> > So in a way they don't care about plugin versions.
> > They only case about things in poms that does matter (unique to that
> > project): dependencies
> > However, with Java 9+ stuff they are forced to specify plugins with more
> > recent versions right now.
> >
> > So here comes the idea of extensions: you can put it in your
> maven/lib/ext
> > ONCE and your pom is again as clean as possible.
> >
> > This seems to be a common way of work for some kind of developers and it
> > would make sense if Maven could support this.
> >
> > To me default plugin versions are bound to a minor Maven release, not a
> > major.
> > When starting with Maven and create your first hello world, it should
> work
> > out of the box.
> > Right now if you are using Java 11, you'll probably hit issues because
> > some defaults won't work anymore.
> > That's a bad thing to me and a valid reason to upgrade the plugins.
> >
> > I do understand Hervé concerns. We should motivate people to lock their
> > plugins in their pom.
> > Most of all the packaging-plugin is important. AFAIK all 3.0+ versions
> > contain plugin bindings, in which case it should be good enough if that
> > plugin is at least specified.
> >
> > thanks,
> > Robert
> >
> > On Sat, 12 Jan 2019 16:24:31 +0100, Hervé BOUTEMY  >
> > wrote:
> >
> > > original idea, let's try to evaluate :)
> > >
> > > IMHO this could work for packaging plugins in default lifecycle, that
> are
> > > defined in default-bindings.xml, but would not for other lifecycles
> that
> > > are
> > > configured in components.xml (without copy/pasting content not related
> to
> > > plugins)
> > >
> > > I don't think an extension would be easier to use than a pom.xml, it's
> > > even
> > > IMHO worse since you have to create a new file in a new directory.
> > >
> > > one question is: is there a use case that an extension would permit
> that
> > > a
> > > parent pom would not?
> > > the only case I see is if a user does not want to change his parent pom
> > > (or
> > > cannot): since we don't have "pluginManagement import" (like we have
> for
> > > dependency management).
> > >
> > >
> > > I think for the moment that a parent pom would be more classical,
> easier
> > > to
> > > explain: I don't really see a clear benefit to do the job as an
> extension
> > > instead, this would IMHO make the change harder for users
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le samedi 12 janvier 2019, 15:42:57 CET Robert Scholte a écrit :
> > >> Just wondering, can this be solved by an extension?
> > >>
> > >> So instead of changing this in Maven Core itself, people can add an
> > >> extension to Maven with the latest+stable releases.
> > >>
> > >> Hervé and I already discovered that current focus is mainly on plugins
> > >> right now. We should also work on extensions.
> > >>
> > >> Robert
> > >>
> > >> On Sat, 12 Jan 2019 15:37:23 +0100, Hervé BOUTEMY
> > >> 
> > >>
> > >> wrote:
> > >> > Le vendredi 11 janvier 2019, 12:55:03 CET Tibor Digana 

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: 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: 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?

[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

Re: Enable Travis on Maven Scripting Plugin

[Stephen Connolly]

I believe my employer also offers free build services for OSS projects via
our CodeShip offering. If people are concerned about tying PR validation
exclusively to one vendor we should inspect the CloudBees CodeShip
capabilities (includes Docker build agents, which can be very nice...
though I confess I have not tried CodeShip yet, despite it being a product
of my employer)

I think CircleCI also provides some stuff in that line.

We could also investigate GitHub Actions for build validation... but
further down the road that may require getting Microsoft/GitHub to provide
CPU time donations.

On Sun 6 Jan 2019 at 20:04, Sylwester Lachiewicz 
wrote:

> In Maven Resolver we have a sample Travis configuration, so someone can
> test with the forked repo.
> If we go with Travis CI I would be good to have a common configuration for
> all projects (ie to run run-it etc and have .travis.yml excluded from RAT).
> I saw in one Apache project (don't remember now name) where they have a
> separate script to merge PR but prerequisite was to PR from forked repo has
> successful Travis build.
> This way we do not use "our" Apache accounts to run builds and developers
> are free to configure anything (and be responsible) in its own Travis
> accounts.
>
> BR
> Sylwester
>
> pt., 4 sty 2019 o 19:21 Enrico Olivelli  napisał(a):
>
> > 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

Re: Jenkins ASF + Pull Requests + webhooks

[Stephen Connolly]

That is not the problem you think it is. Bitcoin mining is the current
issue. And through Jenkinsfile or Process.exec you can bypass JVM
permissions

On Sun 6 Jan 2019 at 16:44, Tibor Digana  wrote:

> Regarding "pull/1234/head" refs and the security, I think allowing only the
> permission to Maven Central IP address is needed and nowhere else.
> This can be accomplished by the java policy in JRE.
> WDYT?
>
> On Sun, Jan 6, 2019 at 11:09 AM Hervé BOUTEMY 
> wrote:
>
> > I didn't know about these special "pull/1234/head" refs, that are not
> real
> > branches: if these pseudo-branches were synchronized to Gitbox like any
> > branch, the Gitpubsub mechanism could happen at Apache
> > of course, the security implications of running code from these PR
> > branches
> > would still have to be managed...
> >
> > notice: there is a discussion on this on builds@apache [1]
> >
> > Regards,
> >
> > Hervé
> >
> > [1] https://lists.apache.org/list.html?bui...@apache.org
> >
> > Le samedi 5 janvier 2019, 12:34:24 CET Enrico Olivelli a écrit :
> > > Hi Stephen,
> > > I am not a Jenkins expert, but I want to share this idea, maybe it can
> > help.
> > > Can we use GitHub webhooks in order to trigger the creation of a Job
> > inside
> > > Maven-Box ?
> > > This way we don't have to continuously use Github API.
> > > When an user creates/updates a PR we can import the PR and create the
> > > Job, having as repository not gitbox.apache.org but github.com
> > >
> > > In github you have this special refs "pull/1234/head" which points to
> > > the branch on remote fork
> > >
> > > just an idea
> > >
> > > Enrico
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
-- 
Sent from my phone

Re: Enable Travis on Maven Scripting Plugin

[Stephen Connolly]

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

Re: Enable Travis on Maven Scripting Plugin

[Stephen Connolly]

+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

Re: New Committers - community

[Stephen Connolly]

On Thu 3 Jan 2019 at 21:37, Tibor Digana  wrote:

> Why the build cannot be triggered on GitHub or PR?
> It's only a URL.
> If you see the frequency of PRs in Surefire, 1 or 2 PRs/month, this should
> not be a problem since the Windows build takes 1.5 hour and Linux 1 hour.
> Taking JDK 7 and 11, and one Maven version (3.5) is usually enough on Git
> branches and should be fine for PRs as well.


1. The current branch source only discovers branches in gitbox, it doesn’t
discover PRs on GitHub.

2. PRs on GitHub can have “untrusted” code, which shouldn’t be run within
the ASF hardware without review by a committer.

#1 can be solved by me enhancing the Jenkins plugin we use

#2 either means asking committers to trigger builds after reviewing (which
is a manual step and manual steps get forgotten)

So instead we get Travis to do a first round CI for the PRs on GitHub. Then
we can still have #1 and #2 as final pre-merge confirmation... but Travis
gives the contributor immediate feedback on their contribution and that
helps grow the community.


>
> On Thu, Jan 3, 2019 at 10:19 PM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > On Thu 3 Jan 2019 at 20:52, Tibor Digana  wrote:
> >
> > > I already lost the point of this thread.
> > > Still the disk space problem on Windows executors in ASF Jenkins?
> > > If it's this issue, then why the workspace is not investigated directly
> > on
> > > the system with remote access?
> > > Jenkins is very good tool and I do not want to use Travis but Travis is
> > one
> > > step after finding the root cause.
> >
> >
> > We’re not going to be able to use Travis for Surefire (unless we have a
> > “fast” suite of tests)
> >
> > That doesn’t mean we cannot use Travis for the 90 other repos we have in
> > order to get test results of PRs from non-committers.
> >
> >
> > > T
> > >
> > > On Thu, Jan 3, 2019 at 8:39 PM Stephen Connolly <
> > > stephen.alan.conno...@gmail.com> wrote:
> > >
> > > > On Thu 3 Jan 2019 at 18:03, Enrico Olivelli 
> > wrote:
> > > >
> > > > > Il gio 3 gen 2019, 17:38 Mickael Istria  ha
> > > scritto:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I think this discussion is diverging into "trying TravisCI for
> some
> > > > > > plugins" and is loosing focus on the initial question of how to
> > > improve
> > > > > the
> > > > > > build+test flow to get faster feedback as a contributor or as a
> > > > reviewer.
> > > >
> > > >
> > > > Travis will get the build+test flow faster for non-committers.
> > > >
> > > >
> > > > > > Can the GitHub PR builder plugin be enabled on Maven Core ?
> > > >
> > > >
> > > > No, it’s not compatible with how we build, as currently we only build
> > > from
> > > > gitbox not from GitHub so there is no link for Jenkins to see
> > > >
> > > >
> > > > Committers
> > > > > > would be allowed to trigger a test with a single comment once
> they
> > > > > checked
> > > > > > it doesn't cause a security flaw.
> > > > > >
> > > > >
> > > > > It turns out that it is not simple as it could seem because we have
> > > > custom
> > > > > Jenkins plugins to scan all the repos and have a common
> > configuration,
> > > so
> > > > > in order to achieve such goal we need to enhance that plugin,
> please
> > > > > Stephen correct me if I am wrong.
> > > >
> > > >
> > > > Yep I need to enhance the plugin a little... just trying to clear
> stuff
> > > off
> > > > my plate
> > > >
> > > >
> > > > > Travis jumped on this train because it is easy to enable and it is
> > very
> > > > > widespread, and it leaves security problems out of ASF infra.
> > > > > But a check with Travis won't ever cover all jobs we are actually
> > > > starting
> > > > > per-branch.
> > > > > It can be a good compromise to start, but if we have resources to
> > > improve
> > > > > current integration this will be the best choice for the mid term.
> > > > >
> > > > > Enrico
> > > > >
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > --
> > > > >
> > > > >
> > > > > -- Enrico Olivelli
> > > > >
> > > > --
> > > > Sent from my phone
> > > >
> > >
> > --
> > Sent from my phone
> >
>
-- 
Sent from my phone

Re: New Committers - community

[Stephen Connolly]

On Thu 3 Jan 2019 at 20:52, Tibor Digana  wrote:

> I already lost the point of this thread.
> Still the disk space problem on Windows executors in ASF Jenkins?
> If it's this issue, then why the workspace is not investigated directly on
> the system with remote access?
> Jenkins is very good tool and I do not want to use Travis but Travis is one
> step after finding the root cause.


We’re not going to be able to use Travis for Surefire (unless we have a
“fast” suite of tests)

That doesn’t mean we cannot use Travis for the 90 other repos we have in
order to get test results of PRs from non-committers.


> T
>
> On Thu, Jan 3, 2019 at 8:39 PM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > On Thu 3 Jan 2019 at 18:03, Enrico Olivelli  wrote:
> >
> > > Il gio 3 gen 2019, 17:38 Mickael Istria  ha
> scritto:
> > >
> > > > Hi,
> > > >
> > > > I think this discussion is diverging into "trying TravisCI for some
> > > > plugins" and is loosing focus on the initial question of how to
> improve
> > > the
> > > > build+test flow to get faster feedback as a contributor or as a
> > reviewer.
> >
> >
> > Travis will get the build+test flow faster for non-committers.
> >
> >
> > > > Can the GitHub PR builder plugin be enabled on Maven Core ?
> >
> >
> > No, it’s not compatible with how we build, as currently we only build
> from
> > gitbox not from GitHub so there is no link for Jenkins to see
> >
> >
> > Committers
> > > > would be allowed to trigger a test with a single comment once they
> > > checked
> > > > it doesn't cause a security flaw.
> > > >
> > >
> > > It turns out that it is not simple as it could seem because we have
> > custom
> > > Jenkins plugins to scan all the repos and have a common configuration,
> so
> > > in order to achieve such goal we need to enhance that plugin, please
> > > Stephen correct me if I am wrong.
> >
> >
> > Yep I need to enhance the plugin a little... just trying to clear stuff
> off
> > my plate
> >
> >
> > > Travis jumped on this train because it is easy to enable and it is very
> > > widespread, and it leaves security problems out of ASF infra.
> > > But a check with Travis won't ever cover all jobs we are actually
> > starting
> > > per-branch.
> > > It can be a good compromise to start, but if we have resources to
> improve
> > > current integration this will be the best choice for the mid term.
> > >
> > > Enrico
> > >
> > > >
> > > > Cheers,
> > > >
> > > --
> > >
> > >
> > > -- Enrico Olivelli
> > >
> > --
> > Sent from my phone
> >
>
-- 
Sent from my phone

Re: New Committers - community

[Stephen Connolly]

On Thu 3 Jan 2019 at 18:03, Enrico Olivelli  wrote:

> Il gio 3 gen 2019, 17:38 Mickael Istria  ha scritto:
>
> > Hi,
> >
> > I think this discussion is diverging into "trying TravisCI for some
> > plugins" and is loosing focus on the initial question of how to improve
> the
> > build+test flow to get faster feedback as a contributor or as a reviewer.


Travis will get the build+test flow faster for non-committers.


> > Can the GitHub PR builder plugin be enabled on Maven Core ?


No, it’s not compatible with how we build, as currently we only build from
gitbox not from GitHub so there is no link for Jenkins to see


Committers
> > would be allowed to trigger a test with a single comment once they
> checked
> > it doesn't cause a security flaw.
> >
>
> It turns out that it is not simple as it could seem because we have custom
> Jenkins plugins to scan all the repos and have a common configuration, so
> in order to achieve such goal we need to enhance that plugin, please
> Stephen correct me if I am wrong.


Yep I need to enhance the plugin a little... just trying to clear stuff off
my plate


> Travis jumped on this train because it is easy to enable and it is very
> widespread, and it leaves security problems out of ASF infra.
> But a check with Travis won't ever cover all jobs we are actually starting
> per-branch.
> It can be a good compromise to start, but if we have resources to improve
> current integration this will be the best choice for the mid term.
>
> Enrico
>
> >
> > Cheers,
> >
> --
>
>
> -- Enrico Olivelli
>
-- 
Sent from my phone

Re: parallelise not overlapping tasks

[Stephen Connolly]

phases are about the user calling out how far they want to go, not about
sequencing... at least once we get a propper execution graph

On Thu, 6 Dec 2018 at 13:54, Romain Manni-Bucau 
wrote:

> Currently maven can't but I expect a way to do it, either in the next xsd
> as originally proposed or, why not, with a naming convention in the id of
> the execution (my-exec#after#other-exec or something
> like that if we want it before maven 4)
>
> The nice thing is that once done it makes phases pretty much useless (it is
> just about making implicit these dependencies) and it makes the whole build
> parallelizable and not just modules which will often find some bottleneck
> modules in projects building a distribution.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 6 déc. 2018 à 14:44, Mickael Istria  a écrit :
>
> > Hi,
> >
> > > any way we move that topic forward beginning of next year?
> >
> > I guess providing patches would be the best way ;)
> >
> > I'm coming late in this discussion and I'm a newcomer on that list, so I
> > could miss context. This could relate to an effort we are doing in
> Eclipse
> > IDE (and Eclipse m2e) to run module builds in parallel. One question I
> have
> > is how do you know 2 tasks aren't conflicting? We didn't figure out a
> safe
> > way to know that in m2e, maybe I missed something?
> >
> > Cheers,
> >
>

Re: New Committers - community

[Stephen Connolly]

On Sat, 29 Dec 2018 at 20:41, Mickael Istria  wrote:

> I'mglad to see that PR build/merge discussed, it seems to have a good
> potential value for many in simplifying it.
>
> FWIW, at Eclipse Foundation, similar questions were faced and risks
> identified. The result is that at the moment, all PRs from anyone can be
> built on Eclipse infra without much visible restriction. The Foundation
> might have extra guards under the hood but it's not something we developers
> need to care about.
> While this is probably unsafe, it's so far so good. We weren't warned by
> the Foundation about malicious usage of this permissive access to build
> machines.
>

As one of the primary developers of Jenkins and as a member of the Jenkins
CERT team I cannot and do not endorse that viewpoint. Unless and until ASF
infra has throw-away build machines, I do not recommend running CI builds
of PRs from unknown actors (it being trivial to set up a throw-away GitHub
account) on the ASF dedicated build agents. Eclipse is being fools if they
are allowing similar.


> AFAIK, there is no issue from developer POV about GitHub API rates limit.
> I suggest the Apache infra team gets in touch with Eclipse Foundation one
> to sort out whether similar configurations could be implemented in a
> safe-enough way.
>
> The GitHub PR builder plugin already has support for whitelisting users and
> giving them ability to trigger a build from a non-whitelidsted contributor
> with a single «test PR» comment or similar.
> Then build progress and report are reported as expected.
> And, again, TravisCI also does the same in a decent way, with the benefit
> of worrying less about underlying infra and security, and only drawback of
> being discoupled from a specific infra (is it really a drawback?)
>

I think we could easily use TravisCI or one of the cloud CI vendors to
perform trial builds of PRs on GitHub. What is of importance to the ASF is
that the build of ASF hosted code are on ASF hosted hardware... until the
PR is merged it is not ASF hosted code, it exists only on GitHub.


>
> Cheers,
>
>
> --
> Mickael Istria
> Eclipse IDE 
> developer, for Red Hat Developers 
>

Re: New Committers - community

[Stephen Connolly]

On Sat, 29 Dec 2018 at 18:56, Vladimir Sitnikov 
wrote:

> Stephen> Well on other GitHub orgs i’ve seen PR author has Merge
> button once PR is
> Stephen> approved by someone with push rights to the repo... until
> they add a commit
> Stephen> or the merge result changes
>
> It does not work the way you describe.
>
> 1) By default GitHub defaults to "Base permissions" == "read".
> Administrator can set even "base permissions == admin", however that
> is not something that comes by default.
> 2) Repository administrator can configure a branch so it requires a PR
> approval before merge (see
>
> https://help.github.com/articles/enabling-required-reviews-for-pull-requests/
> )
>
> It might happen so that "author has Merge button" is a case when
> repository was configured with "default=write" permissions + "require
> PR approval".
> Indeed that should produce (I have not checked) the behavior you
> describe, however it was never a default mode for GiHub.
>
>
Are you sure? I have lots of repos on different orgs that I am in and for
almost all of them, if the repo is one where I only have read access I can
create the PR but the merge button is unavailable... until the PR is
approved by somebody *who has write permission*... at which point the merge
button magically becomes available to me...

Now you have to know to look out for it, because typically the owner of the
repo approves and then merges the PR in one go... and if I add a new commit
or resolve a merge conflict I lose the merge button until re-approved.

But for some organizations I am involved with, we have the culture of
allowing you to self-merge.

Oh and I know for a fact that these are at least some repos that do not
have branch protection turned on.


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

Re: New Committers - community

[Stephen Connolly]

On Sat 29 Dec 2018 at 18:19, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

>
>
> On Sat 29 Dec 2018 at 18:06, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
>> Stephen> Nah. Once committers have approved the PR then the PR can be
>> merged by the
>> Stephen> creator of the PR even if not a committer... at least that’s
>> the default
>> Stephen> way GitHub PRs work
>>
>> By default one needs push rights on the repository to merge PRs.
>> "Approval" changes nothing. "PR approval" does not differ from any
>> other comment.
>> In other words, non-committers can't merge PRs.
>
>
> Well on other GitHub orgs i’ve seen PR author has Merge button once PR is
> approved by someone with push rights to the repo... until they add a commit
> or the merge result changes
>

Gitbox may be configuring synchronised repos differently, but for interop
with the rest of GitHub we shouldn’t assume approval of a PR by committers
will not enable self-merging


>>
>> Vladimir
>>
>> -
>> 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

Re: New Committers - community

[Stephen Connolly]

On Sat 29 Dec 2018 at 18:06, Vladimir Sitnikov 
wrote:

> Stephen> Nah. Once committers have approved the PR then the PR can be
> merged by the
> Stephen> creator of the PR even if not a committer... at least that’s
> the default
> Stephen> way GitHub PRs work
>
> By default one needs push rights on the repository to merge PRs.
> "Approval" changes nothing. "PR approval" does not differ from any
> other comment.
> In other words, non-committers can't merge PRs.


Well on other GitHub orgs i’ve seen PR author has Merge button once PR is
approved by someone with push rights to the repo... until they add a commit
or the merge result changes

>
>
> Vladimir
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: New Committers - community

[Stephen Connolly]

On Sat 29 Dec 2018 at 17:16, Enrico Olivelli  wrote:

> Il sab 29 dic 2018, 17:25 Stephen Connolly <
> stephen.alan.conno...@gmail.com>
> ha scritto:
>
> > On Sat 29 Dec 2018 at 16:20, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > >
> > >
> > > On Sat 29 Dec 2018 at 15:18, Enrico Olivelli 
> > wrote:
> > >
> > >> Il sab 29 dic 2018, 15:17 Stephen Connolly <
> > >> stephen.alan.conno...@gmail.com>
> > >> ha scritto:
> > >>
> > >> > There is a security issue with building PRs automatically.
> > >> >
> > >> > I can see about adding PR discovery to the existing ASF gitbox
> plugin,
> > >> but
> > >> > we’d need committers to ok the build and have reviewed the code as
> the
> > >> PR
> > >> > could contain attacks to be run from ASF hardware... which is why we
> > >> don’t
> > >> > build PRs at present.
> > >> >
> > >>
> > >> Now I have to review and then push to ASF repo and I have to tell to
> the
> > >> contributor that I will make CI start.
> > >> IMHO a good tradeoff is:
> > >> - a committer adds a 'test this please' comment, or '@asfbot test this
> > >> please' and then a CI job start
> > >> - this job updates the status line of the PR, with a link to the logs
> > and
> > >> the status of the job
> > >>
> > >> How does it sounds to you?
> > >
> > >
> > > Like it’ll burn through the GitHub api rate limit like crazy.
> >
>
> I did not think we have 100 repos
>
> > >
> > > The committer goes to Jenkins and clicks the build button on the PR job
> > > (which is sitting there ready and waiting), done.
> > >
> >
> > Oh and before I forget, clicking build now I’m Jenkins will update the CI
> > status in GitHub for the PR to say in progress and then provide the
> result
> > when available.
> >
> >
> > > Searching through comments on PRs to find commits with a magic comment
> > > string that haven’t been built by Jenkins is certainly what would be
> > > lovely... but right now it would burn the GitHub rate limit (which is
> > 5,000
> > > requests per hour across the whole ASF) right through.
> > >
> >
> > To be clear, the hard part is efficiently finding “missed” comments and
> > associating with the commit hash they belong to. We don’t want an
> approval
> > to allow attack via an update pushed to the PR. So you have to walk all
> the
> > comments and associate with the commit hash they applied to... gets
> tricky.
> >
>
> Yep, I understand, you are right.
>
> Another option is to have a script to launch:
>
> import-pr maven-assembly-plugin #567
>
> Then the script + Jenkins:
> - bind the pr to a JIRA by scanning git log
> - push to ASF (changing 'committer') with a standard name (JIRA id)
> - start a job
> - add a github status line with a link to the logs
> - bonus: the job will change the status line with green/red light
>
> I already have such kind of script in my company (but for
> bitbucket/JIRA/Jenkins and not for such a complex system like Maven CI),
> but the hard part is the job which has to write the status line
>
> Enrico
>
>
> > We could maybe hijack approval state... but that allows merging by the
> > author.
> >
>
> This part is not clear to me. Only 'commiters' can push to the repo.


Nah. Once committers have approved the PR then the PR can be merged by the
creator of the PR even if not a committer... at least that’s the default
way GitHub PRs work. GitBox *may* be enforcing a stricter permissions
model... but I suspect not (because it makes contributions harder... and
the goal of gitbox was to make working from GitHub a first class experience)




>
>
>
> >
> > >
> > >
> > >>
> > >> Enrico
> > >>
> > >>
> > >> > Other projects at ASF probably missed this point in the video series
> > >> > chronicling the development of the plugin...
> > >> >
> > >> > On Sat 29 Dec 2018 at 13:10, Enrico Olivelli 
> > >> wrote:
> > >> >
> > >> > > Hervè,
> > >> > > This is the plugin
> > >> > >
> > >> > >
> > >> >
> > >>
> >
> https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin?desktop=true=unmigr

Re: New Committers - community

[Stephen Connolly]

On Sat 29 Dec 2018 at 16:20, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

>
>
> On Sat 29 Dec 2018 at 15:18, Enrico Olivelli  wrote:
>
>> Il sab 29 dic 2018, 15:17 Stephen Connolly <
>> stephen.alan.conno...@gmail.com>
>> ha scritto:
>>
>> > There is a security issue with building PRs automatically.
>> >
>> > I can see about adding PR discovery to the existing ASF gitbox plugin,
>> but
>> > we’d need committers to ok the build and have reviewed the code as the
>> PR
>> > could contain attacks to be run from ASF hardware... which is why we
>> don’t
>> > build PRs at present.
>> >
>>
>> Now I have to review and then push to ASF repo and I have to tell to the
>> contributor that I will make CI start.
>> IMHO a good tradeoff is:
>> - a committer adds a 'test this please' comment, or '@asfbot test this
>> please' and then a CI job start
>> - this job updates the status line of the PR, with a link to the logs and
>> the status of the job
>>
>> How does it sounds to you?
>
>
> Like it’ll burn through the GitHub api rate limit like crazy.
>
> The committer goes to Jenkins and clicks the build button on the PR job
> (which is sitting there ready and waiting), done.
>

Oh and before I forget, clicking build now I’m Jenkins will update the CI
status in GitHub for the PR to say in progress and then provide the result
when available.


> Searching through comments on PRs to find commits with a magic comment
> string that haven’t been built by Jenkins is certainly what would be
> lovely... but right now it would burn the GitHub rate limit (which is 5,000
> requests per hour across the whole ASF) right through.
>

To be clear, the hard part is efficiently finding “missed” comments and
associating with the commit hash they belong to. We don’t want an approval
to allow attack via an update pushed to the PR. So you have to walk all the
comments and associate with the commit hash they applied to... gets tricky.

We could maybe hijack approval state... but that allows merging by the
author.


>
>
>>
>> Enrico
>>
>>
>> > Other projects at ASF probably missed this point in the video series
>> > chronicling the development of the plugin...
>> >
>> > On Sat 29 Dec 2018 at 13:10, Enrico Olivelli 
>> wrote:
>> >
>> > > Hervè,
>> > > This is the plugin
>> > >
>> > >
>> >
>> https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin?desktop=true=unmigrated-inline-wiki-markup
>> > >
>> > > I see our "maven-box" is using some special "Scan Apache Hosted Git
>> > > Folder Triggers" source
>> > > (https://builds.apache.org/job/maven-box/configure)
>> > > In the Jenkins of my company in a "Multibranch Pipeline" I have a
>> > > "Branch Sources" box with a "GitHub" option which lets me trigger
>> > > builds by using PRs
>> > >
>> > >
>> > > Enrico
>> > >
>> > > Il giorno sab 29 dic 2018 alle ore 13:43 Hervé BOUTEMY
>> > >  ha scritto:
>> > > >
>> > > > Le samedi 29 décembre 2018, 12:40:20 CET Enrico Olivelli a écrit :
>> > > > > Il sab 29 dic 2018, 12:37 Mickael Istria  ha
>> > > scritto:
>> > > > > > On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY <
>> > > herve.bout...@free.fr>
>> > > > > >
>> > > > > > wrote:
>> > > > > > > But in both cases, currently, there is no automatic GitHub PR
>> > > > > >
>> > > > > > integration:
>> > > > > > > Maven committers need to create a branch in the official
>> > > repository to
>> > > > > > > benefit
>> > > > > > > from ASF Jenkins build
>> > > > > >
>> > > > > > Ah ok, I wasn't aware the GitHub repo was "unofficial" and
>> couldn't
>> > > be
>> > > > > > used
>> > > > > > to trigger builds. That sucks...
>> > > > >
>> > > > > Maven migrated to gitbox so actually github is an official repo
>> for
>> > > Maven.
>> > > > > I see the same setup in Zookeeper and Bookkeeper and github pr
>> plugin
>> > > works
>> > > > > like a charm (and I partecipated in setting it up)
>> > > > oh great, that would be nice to have the same setup for Maven repos!
>> > > >
>> > > > >
>> > > > > Enrico
>> > > > >
>> > > > > > Any idea how we could have GitHub PR reviews without this branch
>> > > creation
>> > > > > >
>> > > > > > > by
>> > > > > > > committers, be it at ASF or somewhere else?
>> > > > > >
>> > > > > > Using TravisCI could be a solution.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> -
>> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > > >
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > >
>> > > --
>> > Sent from my phone
>> >
>> --
>>
>>
>> -- Enrico Olivelli
>>
> --
> Sent from my phone
>
-- 
Sent from my phone

Re: New Committers - community

[Stephen Connolly]

On Sat 29 Dec 2018 at 15:18, Enrico Olivelli  wrote:

> Il sab 29 dic 2018, 15:17 Stephen Connolly <
> stephen.alan.conno...@gmail.com>
> ha scritto:
>
> > There is a security issue with building PRs automatically.
> >
> > I can see about adding PR discovery to the existing ASF gitbox plugin,
> but
> > we’d need committers to ok the build and have reviewed the code as the PR
> > could contain attacks to be run from ASF hardware... which is why we
> don’t
> > build PRs at present.
> >
>
> Now I have to review and then push to ASF repo and I have to tell to the
> contributor that I will make CI start.
> IMHO a good tradeoff is:
> - a committer adds a 'test this please' comment, or '@asfbot test this
> please' and then a CI job start
> - this job updates the status line of the PR, with a link to the logs and
> the status of the job
>
> How does it sounds to you?


Like it’ll burn through the GitHub api rate limit like crazy.

The committer goes to Jenkins and clicks the build button on the PR job
(which is sitting there ready and waiting), done.

Searching through comments on PRs to find commits with a magic comment
string that haven’t been built by Jenkins is certainly what would be
lovely... but right now it would burn the GitHub rate limit (which is 5,000
requests per hour across the whole ASF) right through.



>
> Enrico
>
>
> > Other projects at ASF probably missed this point in the video series
> > chronicling the development of the plugin...
> >
> > On Sat 29 Dec 2018 at 13:10, Enrico Olivelli 
> wrote:
> >
> > > Hervè,
> > > This is the plugin
> > >
> > >
> >
> https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin?desktop=true=unmigrated-inline-wiki-markup
> > >
> > > I see our "maven-box" is using some special "Scan Apache Hosted Git
> > > Folder Triggers" source
> > > (https://builds.apache.org/job/maven-box/configure)
> > > In the Jenkins of my company in a "Multibranch Pipeline" I have a
> > > "Branch Sources" box with a "GitHub" option which lets me trigger
> > > builds by using PRs
> > >
> > >
> > > Enrico
> > >
> > > Il giorno sab 29 dic 2018 alle ore 13:43 Hervé BOUTEMY
> > >  ha scritto:
> > > >
> > > > Le samedi 29 décembre 2018, 12:40:20 CET Enrico Olivelli a écrit :
> > > > > Il sab 29 dic 2018, 12:37 Mickael Istria  ha
> > > scritto:
> > > > > > On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY <
> > > herve.bout...@free.fr>
> > > > > >
> > > > > > wrote:
> > > > > > > But in both cases, currently, there is no automatic GitHub PR
> > > > > >
> > > > > > integration:
> > > > > > > Maven committers need to create a branch in the official
> > > repository to
> > > > > > > benefit
> > > > > > > from ASF Jenkins build
> > > > > >
> > > > > > Ah ok, I wasn't aware the GitHub repo was "unofficial" and
> couldn't
> > > be
> > > > > > used
> > > > > > to trigger builds. That sucks...
> > > > >
> > > > > Maven migrated to gitbox so actually github is an official repo for
> > > Maven.
> > > > > I see the same setup in Zookeeper and Bookkeeper and github pr
> plugin
> > > works
> > > > > like a charm (and I partecipated in setting it up)
> > > > oh great, that would be nice to have the same setup for Maven repos!
> > > >
> > > > >
> > > > > Enrico
> > > > >
> > > > > > Any idea how we could have GitHub PR reviews without this branch
> > > creation
> > > > > >
> > > > > > > by
> > > > > > > committers, be it at ASF or somewhere else?
> > > > > >
> > > > > > Using TravisCI could be a solution.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > --
> > Sent from my phone
> >
> --
>
>
> -- Enrico Olivelli
>
-- 
Sent from my phone

Re: New Committers - community

[Stephen Connolly]

There is a security issue with building PRs automatically.

I can see about adding PR discovery to the existing ASF gitbox plugin, but
we’d need committers to ok the build and have reviewed the code as the PR
could contain attacks to be run from ASF hardware... which is why we don’t
build PRs at present.

Other projects at ASF probably missed this point in the video series
chronicling the development of the plugin...

On Sat 29 Dec 2018 at 13:10, Enrico Olivelli  wrote:

> Hervè,
> This is the plugin
>
> https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin?desktop=true=unmigrated-inline-wiki-markup
>
> I see our "maven-box" is using some special "Scan Apache Hosted Git
> Folder Triggers" source
> (https://builds.apache.org/job/maven-box/configure)
> In the Jenkins of my company in a "Multibranch Pipeline" I have a
> "Branch Sources" box with a "GitHub" option which lets me trigger
> builds by using PRs
>
>
> Enrico
>
> Il giorno sab 29 dic 2018 alle ore 13:43 Hervé BOUTEMY
>  ha scritto:
> >
> > Le samedi 29 décembre 2018, 12:40:20 CET Enrico Olivelli a écrit :
> > > Il sab 29 dic 2018, 12:37 Mickael Istria  ha
> scritto:
> > > > On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY <
> herve.bout...@free.fr>
> > > >
> > > > wrote:
> > > > > But in both cases, currently, there is no automatic GitHub PR
> > > >
> > > > integration:
> > > > > Maven committers need to create a branch in the official
> repository to
> > > > > benefit
> > > > > from ASF Jenkins build
> > > >
> > > > Ah ok, I wasn't aware the GitHub repo was "unofficial" and couldn't
> be
> > > > used
> > > > to trigger builds. That sucks...
> > >
> > > Maven migrated to gitbox so actually github is an official repo for
> Maven.
> > > I see the same setup in Zookeeper and Bookkeeper and github pr plugin
> works
> > > like a charm (and I partecipated in setting it up)
> > oh great, that would be nice to have the same setup for Maven repos!
> >
> > >
> > > Enrico
> > >
> > > > Any idea how we could have GitHub PR reviews without this branch
> creation
> > > >
> > > > > by
> > > > > committers, be it at ASF or somewhere else?
> > > >
> > > > Using TravisCI could be a solution.
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: On Maven 4.0.0 and beyond

[Stephen Connolly]

On Sun 23 Dec 2018 at 11:32, Michael Osipov  wrote:

> Am 2018-12-23 um 11:14 schrieb Stephen Connolly:
> > Over the break I *may* get some time to work on the tooling improvements
> > that Robert, Hervé and I identified for the jump to 4.0.0 (namely a
> better
> > way to ensure api binary compatibility for the APIs that core exposes to
> > plugins)
> >
> > If I do get a chance to work on this, it’ll be in a branch until we think
> > it’s “good enough”.
> >
> > The idea is to enable large scale lambdafication and other Java 8
> > improvements in core without breaking plugins.
>
> I'd rather see a big bug/PR sweep than lambafication which does not give
> a huge benefit for the users. What else I'd like to see is edge cases
> covered Christian Schulte started to work on. We can break things this
> time and clean them up.


We need to get people actually involved in the code. Lambdafication and
other modernisation refactoring enable people to get their hands dirty
without committing too much. Asking potential new blood to look at the
harder things will not get us new blood.

Actual committers should be looking at the other changes... though I don’t
believe we can change the pom until 5.0.0 which is why the scope of 4.0.0
is likely:

* modernise the codebase
* Java 8 baseline
* perhaps relocate aether to org.apache.maven
* other behaviour changes that do not affect the pom
* nicer failure message when presented with a newer modelVersion
* native consumer pom support... perhaps also PDT publishing


>
> Michael
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

On Maven 4.0.0 and beyond

[Stephen Connolly]

Over the break I *may* get some time to work on the tooling improvements
that Robert, Hervé and I identified for the jump to 4.0.0 (namely a better
way to ensure api binary compatibility for the APIs that core exposes to
plugins)

If I do get a chance to work on this, it’ll be in a branch until we think
it’s “good enough”.

The idea is to enable large scale lambdafication and other Java 8
improvements in core without breaking plugins.

If we have good reliable tooling, then we hope to be able to encourage
contributions (as you don’t need a CLA for an “obvious” ~10-15 line patch -
intent to submit is sufficient) and get the code base more energised.

-Stephen

P.S. the existing api checker tools do not meet our needs as they check too
much, we only want those classes exposed to plugins and extensions. I think
animal sniffer might be closest to what we need - as it allows defining the
signature scope - but it needs a different execution mode to do what we
need: check that the signature is still valid for a specific classpath.

P.P.S. I also might need to think about Java modules... eg would it make
sense to use modules for Maven 5.0 as an alternative to classworlds?
-- 
Sent from my phone

Re: New committer: Enrico Olivelli

[Stephen Connolly]

Welcome!

On Fri 14 Dec 2018 at 21:07, Robert Scholte  wrote:

> The Project Management Committee (PMC) for Apache Maven
> has invited Enrico Olivelli to become a committer and
> we are pleased to announce that he has accepted.
>
> Being a committer enables easier contribution to the
> project since there is no need to go via the patch
> submission process. This should enable better productivity.
>
> Enrico, welcome and enjoy!
>
> thanks,
> Robert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Meaning of ~~life~~ - end-of-life

[Stephen Connolly]

On Thu, 1 Nov 2018 at 11:57, Mirko Friedenhagen 
wrote:

> Hello,
>
> # Preambel
> * I just opened a PR at Homebrew[0], a package manager for macOS, to
> update Maven to 3.6.0.
> * First thing was, the Download page[1] still states 3.5.4 as latest and
> greatest, which is a bit confusing given the change-date tells me it
> changed just changed today.
> * And as Homebrew supports versioned packages, users may easily install
> the latest micro-versions of minors 3.0, 3.1, 3.2, 3.3 and now of course I
> wanted to add 3.5 to the mix.
> * One of the Homebrew maintainers now wants to remove at least one older
> version. I agreed to start a discussion on this list :-)
> * After some searching I found the 3.0.5 EOL discussion[8], but could not
> get a real conclusion. And today being a public holiday in the catholic
> states of Germany I could not hinder myself to think about the:
>
>
> # Meaning of life - for Maven Core
> * For Maven 2[4] there is a dedicated page what EOL does mean.
> * I think maybe we (I am not very active currently, sorry) should at least
> manifest somewhere the meaning of life of a Maven core release as well.
> * Some ideas follow, YMMV :-)
>
> ## Core gets patched!
> * Looking at Maven's history page[2], I found no minor release was ever
> updated to a new micro version after a new minor was released.
> * So obviously a core version being not in the EOL state does not mean
> that anything will be patched in a micro release (Or does it? Would a
> „blocker" bug found in 3.0.5 lead to a 3.0.6?).
>

A critical security issue *might* be assessed by the PMC as warranting an
update to some of the older release lines, but that would really require
known compatibility issues that seriously block users upgrading to the
latest and greatest Maven Core and a very serious security issue.

Until we hit Maven 4.x and 5.x this should be mostly unlikely to occur...
but I would not hold my breath


> * After a quick look into Jenkins I only found one job for master but not
> for older „stable“ branches. master itself is built with 3.5.4.
> * Are there jobs which still build the older 3.x releases nowadays? Are
> the old tags buildable?
>
>
> ## All Apache plugins and components are working with all cores!
> * Does it mean all Maven plugins and components developed by us are tested
> against 3.0, 3.1, 3.2 and 3.3 and now 3.5 as well as 3.6?
> * Surefire[5] does have an impressing matrix, but I only see 3.5, 3.3 and
> 3.2 but not 3.1 or 3.0.
> * asfMavenTlpPlgnBuild does not include 3.0 or 3.1 either.
>
>
> ## Users may still download the old stuff!
> * This seems to be the case, all 3.X releases are downloadable from the
> dist page[7]
>
>
> ## Users may still find the old documentation!
> * According to the history page[2] old documentation is still available.
>
> I am sure there is more that could be said.
>
> Best Regards
> Mirko
>
> [0] https://github.com/Homebrew/homebrew-core/pull/33572
> [1] https://maven.apache.org/download.cgi
> [2] https://maven.apache.org/docs/history.html
> [3] https://builds.apache.org/view/M-R/view/Maven/job/maven-box/
> [4] http://maven.apache.org/maven-2.x-eol.html
> [5]
> https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-surefire/job/master/
> [6]
> https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/asfMavenTlpPlgnBuild.groovy;hb=HEAD
> [7] https://www.apache.org/dist/maven/maven-3/
> [8] https://markmail.org/message/k4o5nkhrvhb3j5a4
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Download page still shows 3.5.4 as latest and greatest

[Stephen Connolly]

On Thu, 1 Nov 2018 at 11:42, Karl Heinz Marbaise  wrote:

> Hi Mirko,
>
> of course not, cause I haven't written the announcement yet..
>
> I'm currently preparing the release notes (just published a few minutes
> ago)..
>
> Afterwards I will check the pages etc..and afterwards I will do the
> announcement mail...I need to make the announcement mail first cause I
> need to add the announcement mail reference to the release notes page...
>

I normally updated it twice... first without the link, so that the
announcement mail could reference the release notes... then with the
link... a pain, but just about the only way I could prevent people clicking
on broken links (and the mail can take up to 8h before the archive link
picks it up


>
> Kind regards
> Karl Heinz Marbaise
>
>
> On 01/11/18 12:26, Mirko Friedenhagen wrote:
> > Hello,
> >
> > https://maven.apache.org/download.cgi still shows 3.5.4 instead of
> 3.6.0 as latest and greatest.
> >
> > Regards
> > Mirko
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Download page still shows 3.5.4 as latest and greatest

[Stephen Connolly]

On Thu, 1 Nov 2018 at 11:41, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> yep, there is a bunch of steps after the vote and it usually took me a day
> or two for to wait for the mirrors to sync, which is a blocker for calling
> the release available.
>
> This is Karl's first run as release manager
>

For core... he's done plenty of the plugins and shared components... but
core is a "special snowflake"


>
> Patience is a virtue!
>
> On Thu, 1 Nov 2018 at 11:26, Mirko Friedenhagen 
> wrote:
>
>> Hello,
>>
>> https://maven.apache.org/download.cgi still shows 3.5.4 instead of 3.6.0
>> as latest and greatest.
>>
>> Regards
>> Mirko
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: Download page still shows 3.5.4 as latest and greatest

[Stephen Connolly]

yep, there is a bunch of steps after the vote and it usually took me a day
or two for to wait for the mirrors to sync, which is a blocker for calling
the release available.

This is Karl's first run as release manager

Patience is a virtue!

On Thu, 1 Nov 2018 at 11:26, Mirko Friedenhagen 
wrote:

> Hello,
>
> https://maven.apache.org/download.cgi still shows 3.5.4 instead of 3.6.0
> as latest and greatest.
>
> Regards
> Mirko
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven 3.6.0

[Stephen Connolly]

Source distribution builds: Check
Source contributions have ICLAs; have clear intent to commit; or are
sufficiently trivial: Check
Tried some of my more interesting projects: Check

+1 (binding)


On Sat, 27 Oct 2018 at 21:16, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> $ target/appassembler/bin/sra
> https://repository.apache.org/content/repositories/maven-1459 3.6.0
> Analyzer...
>
> stagingUrl: https://repository.apache.org/content/repositories/maven-1459
> groupId: org.apache.maven
> artifactId: apache-maven
> version: 3.6.0
>
> Source ZIP url exists.
>
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-src.zip
>
> Source ZIP SHA1 url exists.
>
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-src.zip.sha1
>
> Binary ZIP url exists.
>
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-bin.zip
>
> Binary ZIP SHA1 url exists.
>
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-bin.zip.sha1
>
> Calculated SHA1 of source ZIP matches published SHA1 of source ZIP.
> 6149f259489acf36e2c04ec0dd713f99336b3346
>
> Calculated SHA1 of binary ZIP matches published SHA1 of binary ZIP.
> 8589fe27a6e0dd831ff967d3a7073bcb6d41b083
>
> Git revision of release as determined from
> maven-core-3.6.0.jar:org/apache/maven/messages/build.properties(buildNumber):
> 97c98ec64a1fdfee7767ce5ffb20918da4f719f3
>
> Files that are present in the source distribution but not in the source
> revision:
> DEPENDENCIES
>
>
> On Sat, 27 Oct 2018 at 18:10, Robert Scholte  wrote:
>
>> +1
>>
>> On Wed, 24 Oct 2018 21:50:02 +0200, Karl Heinz Marbaise
>>  wrote:
>>
>> > Hi,
>> >
>> > We have solved 26 issues:
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12338966
>> >
>> > There are issues left in JIRA for Maven core:
>> >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>> >
>> > Staging repo:
>> > https://repository.apache.org/content/repositories/maven-1459
>> >
>> > The distributable binaries and sources can be found here:
>> >
>> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/
>> >
>> > Specifically the zip, tarball and source archives can be found here:
>> >
>> >
>> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-bin.zip
>> >
>> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-bin.tar.gz
>> >
>> >
>> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-src.zip
>> >
>> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-src.tar.gz
>> >
>> > The release artifacts are staged for distribution in:
>> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.5.4
>> >
>> > Source release checksum(s):
>> > apache-maven-3.6.0-src.tar.gz
>> >
>> >sha1: 255d8057b7f014222e96137001d4f4aa05d4a7cb
>> > sha512:
>> >
>> 5b4b5ca569d5476f9d6a2b8080927f58da9ca10a04c593df3d8c012e60fdcf7dcf70c4bc5db0d068b3a36785ede62a55fd1778b22ecadcf787485681ddc758a8
>> >
>> > apache-maven-3.6.0-src.zip:
>> >
>> >sha1: 6149f259489acf36e2c04ec0dd713f99336b3346
>> > sha512:
>> >
>> c5794a6723d8d0fc8ff447b42e5a8c13524a44f8508a305d463f811c8039c7e9166d709077c8373d3cf980ce24feaebb2431cb50fb274933ab3bc2a90355
>> >
>> > Git tag:
>> >
>> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=97c98ec64a1fdfee7767ce5ffb20918da4f719f3
>> >
>> > Staging site:
>> > https://maven.apache.org/components/ref/3-LATEST/
>> >
>> > Vote open for 72 hours.
>> >
>> > [ ] +1
>> > [ ] +0
>> > [ ] -1
>> >
>> > Kind regards
>> > Karl Heinz Marbaise
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: [VOTE] Release Apache Maven 3.6.0

[Stephen Connolly]

$ target/appassembler/bin/sra
https://repository.apache.org/content/repositories/maven-1459 3.6.0
Analyzer...

stagingUrl: https://repository.apache.org/content/repositories/maven-1459
groupId: org.apache.maven
artifactId: apache-maven
version: 3.6.0

Source ZIP url exists.
https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-src.zip

Source ZIP SHA1 url exists.
https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-src.zip.sha1

Binary ZIP url exists.
https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-bin.zip

Binary ZIP SHA1 url exists.
https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-bin.zip.sha1

Calculated SHA1 of source ZIP matches published SHA1 of source ZIP.
6149f259489acf36e2c04ec0dd713f99336b3346

Calculated SHA1 of binary ZIP matches published SHA1 of binary ZIP.
8589fe27a6e0dd831ff967d3a7073bcb6d41b083

Git revision of release as determined from
maven-core-3.6.0.jar:org/apache/maven/messages/build.properties(buildNumber):
97c98ec64a1fdfee7767ce5ffb20918da4f719f3

Files that are present in the source distribution but not in the source
revision:
DEPENDENCIES


On Sat, 27 Oct 2018 at 18:10, Robert Scholte  wrote:

> +1
>
> On Wed, 24 Oct 2018 21:50:02 +0200, Karl Heinz Marbaise
>  wrote:
>
> > Hi,
> >
> > We have solved 26 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12338966
> >
> > There are issues left in JIRA for Maven core:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1459
> >
> > The distributable binaries and sources can be found here:
> >
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/
> >
> > Specifically the zip, tarball and source archives can be found here:
> >
> >
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-bin.zip
> >
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-bin.tar.gz
> >
> >
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-src.zip
> >
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-src.tar.gz
> >
> > The release artifacts are staged for distribution in:
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.5.4
> >
> > Source release checksum(s):
> > apache-maven-3.6.0-src.tar.gz
> >
> >sha1: 255d8057b7f014222e96137001d4f4aa05d4a7cb
> > sha512:
> >
> 5b4b5ca569d5476f9d6a2b8080927f58da9ca10a04c593df3d8c012e60fdcf7dcf70c4bc5db0d068b3a36785ede62a55fd1778b22ecadcf787485681ddc758a8
> >
> > apache-maven-3.6.0-src.zip:
> >
> >sha1: 6149f259489acf36e2c04ec0dd713f99336b3346
> > sha512:
> >
> c5794a6723d8d0fc8ff447b42e5a8c13524a44f8508a305d463f811c8039c7e9166d709077c8373d3cf980ce24feaebb2431cb50fb274933ab3bc2a90355
> >
> > Git tag:
> >
> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=97c98ec64a1fdfee7767ce5ffb20918da4f719f3
> >
> > Staging site:
> > https://maven.apache.org/components/ref/3-LATEST/
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>