Re: Maven Enforcer Release-3.0.0-M3

[Tibor Digana]

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 then they have nice version. Somebody can still use the RC and he will
never see a bug because not everybody is using different versions of
JMS/Artemis publisher and subscriber.

So the model can be anything but this model does not mean that we want to
intentionally break the users.
We can propose more alternatives and finally the result will be naming
conventions, when/how to use them

T

On Tue, Nov 12, 2019 at 1:01 PM Elliotte Rusty Harold 
wrote:

> I'm a little nervous about this is being messages to and being
> understood by developers. How stable is a milestone release? If it's
> not stable, they shouldn't be seeing as abroad an adoption as they
> are. If it is stable, then why not give it a full release as 3.0.0.
> (or whatever) and add more in 3.1.0, 3.2.0, etc.?
>
> On Tue, Nov 12, 2019 at 6:51 AM Tibor Digana 
> wrote:
> >
> > Hi Elliotte,
> >
> > I am also using milestones in Surefire, as you may have noticed, because
> > the complete work is too big and for one release.
> > As for instance, milestones are fantastic for the major versions like in
> > 3.0.0 because it is the only chance when you can break some backwards
> > compatibility in plugin configuration.
> > That's our case. For instance the system properties for config parameters
> > of plugins share the same because they do not have prefixes. So i put the
> > prefix in the system property and that's what i break, a little. It was
> > just an example, but this is the principle that i understand and we
> > untilize it in the milestones.
> >
> > T
> >
> > On Mon, Nov 11, 2019 at 7:55 PM Elliotte Rusty Harold <
> elh...@ibiblio.org>
> > wrote:
> >
> > > What is the significance of the M2/M3 classifier in the version
> > > string? It's not obvious to me whether this is a release version or
> > > not.
> > >
> > > Is there a reason not to call this simply 3.0.0 or 3.0.1?
> > >
> > > On Mon, Nov 11, 2019 at 1:50 PM Karl Heinz Marbaise  >
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > I've seen there are a lot of fixes in the meantime in the current
> state
> > > > so I would like to cut a release and the end of the week.
> > > >
> > > > So if someone has any objections please raise your hand.
> > > >
> > > > Kind regards
> > > > Karl Heinz Marbaise
> > > >
> > > > -
> > > > 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
> > >
> > >
>
>
>
> --
> 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: 3.6.3 release?

[Hervé BOUTEMY]

Hi Mickael,

Working on last issues: should be able to launch a release soon.

Regards,

Hervé

Le mardi 12 novembre 2019, 15:57:56 CET Mickael Istria a écrit :
> Hi all,
> 
> What's the status here? Any ETA for 3.6.3 release?
> 
> Cheers





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

Re: Dynamic phases proposal

[Andreas Sewe]

Stephen Connolly wrote:
> https://cwiki.apache.org/confluence/display/MAVEN/Dynamic+phases
> 
> Thoughts?

Very nice. I like this a lot. In particular, it still feels like Maven
with its well-known phases rather than like the "every project rolls
their own" approach of Ant or Gradle.

And to answer one specific question from your proposal: "Do we need a
differentiation between validate and initialize?"

I would argue that the answer is Yes; the two phases are for different
things.

To initialize I would bind something like buildnumber:create or pretty
much all of the build-helper-maven-plugin's goals. My intuition would be
that the initialize phase is where you programmatically augment the
project model.

In contrast, the validate phase is for validating your input (or
environment). Now in the common case (Java), inputs are already
validated by the compiler, but if my compile goal is xml:transform, then
it makes sense to have xml:validate bound to the validate phase, as XSL
Transforms typically don't check that diligently that their input
adheres to some expected format. (It also makes sense to bind
xml:validate bound to test or verify, too, to check the output's format.)

Just my 2 cents.

But overall, a really nice proposal.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: 3.6.3 release?

[Mickael Istria]

Hi all,

What's the status here? Any ETA for 3.6.3 release?

Cheers

Re: Did you see dependabot?

[Martijn Dashorst]

Now there's a LEGAL ticket for that:

https://issues.apache.org/jira/browse/LEGAL-491

With a comment from Mark Thomas that this is no different than a
committer running a local tool, reviewing the commit and pushing it.

Read his comment on the ticket for more information and advice.

Martijn

On Sat, Oct 19, 2019 at 8:51 PM Enrico Olivelli  wrote:
>
> I see value in it.
> But from a legal point of viewthere is no human who sends the PR, so in
> theory we cannot accept such patches, can we?
>
> Enrico
>
> Il sab 19 ott 2019, 20:26 Tibor Digana  ha scritto:
>
> > The dependabot looks interesting, cli has more possibilities than a pure
> > button on GUI.
> > >> does anyone enabled it
> > I am all the ear how it can be enabled.
> >
> > On Fri, Oct 18, 2019 at 3:32 PM Enrico Olivelli 
> > wrote:
> >
> > > Hey guys,
> > > Did you see dependabot on our repos?
> > >
> > > Like this automatic PR
> > >
> > >
> > https://github.com/apache/maven-plugins/pull/147#pullrequestreview-303889692
> > >
> > > I feel this is very useful, but... does anyone enabled it?
> > >
> > > Do we have to set a policy, this suggestions are security related fixes,
> > we
> > > could give them some kind of high priority?
> > >
> > > Enrico
> > >
> >



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

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

Re: Maven Enforcer Release-3.0.0-M3

[Eric Lilja]

I guess the reasoning goes something like this: "I am a plugin developer,
and I want to release a number of changes, a sub-set of which are "breaking
changes". Since all my changes are not ready at the same time and I want to
avoid releasing several major versions close to each other (assuming
semantic versioning is used), I use milestones, to lead up to next major".

- Eric L

On Tue, Nov 12, 2019 at 1:38 PM Enrico Olivelli  wrote:

> Il mar 12 nov 2019, 13:01 Elliotte Rusty Harold  ha
> scritto:
>
> > I'm a little nervous about this is being messages to and being
> > understood by developers. How stable is a milestone release? If it's
> > not stable, they shouldn't be seeing as abroad an adoption as they
> > are. If it is stable, then why not give it a full release as 3.0.0.
> > (or whatever) and add more in 3.1.0, 3.2.0, etc.?
> >
>
> I totally agree with this point.
> Personally I don't like milestones as we are doing with plugins, it is very
> confusing for users.
> If the plugin is good to be used in 'production' (in every day work) than
> we should not call it -Mx.
> If we know it has problems but some user needs it we can call it 'beta'.
>
> Enrico
>
>
>
>
>
>
> > On Tue, Nov 12, 2019 at 6:51 AM Tibor Digana 
> > wrote:
> > >
> > > Hi Elliotte,
> > >
> > > I am also using milestones in Surefire, as you may have noticed,
> because
> > > the complete work is too big and for one release.
> > > As for instance, milestones are fantastic for the major versions like
> in
> > > 3.0.0 because it is the only chance when you can break some backwards
> > > compatibility in plugin configuration.
> > > That's our case. For instance the system properties for config
> parameters
> > > of plugins share the same because they do not have prefixes. So i put
> the
> > > prefix in the system property and that's what i break, a little. It was
> > > just an example, but this is the principle that i understand and we
> > > untilize it in the milestones.
> > >
> > > T
> > >
> > > On Mon, Nov 11, 2019 at 7:55 PM Elliotte Rusty Harold <
> > elh...@ibiblio.org>
> > > wrote:
> > >
> > > > What is the significance of the M2/M3 classifier in the version
> > > > string? It's not obvious to me whether this is a release version or
> > > > not.
> > > >
> > > > Is there a reason not to call this simply 3.0.0 or 3.0.1?
> > > >
> > > > On Mon, Nov 11, 2019 at 1:50 PM Karl Heinz Marbaise <
> khmarba...@gmx.de
> > >
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I've seen there are a lot of fixes in the meantime in the current
> > state
> > > > > so I would like to cut a release and the end of the week.
> > > > >
> > > > > So if someone has any objections please raise your hand.
> > > > >
> > > > > Kind regards
> > > > > Karl Heinz Marbaise
> > > > >
> > > > >
> -
> > > > > 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
> > > >
> > > >
> >
> >
> >
> > --
> > 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: Maven Enforcer Release-3.0.0-M3

[Enrico Olivelli]

Il mar 12 nov 2019, 13:01 Elliotte Rusty Harold  ha
scritto:

> I'm a little nervous about this is being messages to and being
> understood by developers. How stable is a milestone release? If it's
> not stable, they shouldn't be seeing as abroad an adoption as they
> are. If it is stable, then why not give it a full release as 3.0.0.
> (or whatever) and add more in 3.1.0, 3.2.0, etc.?
>

I totally agree with this point.
Personally I don't like milestones as we are doing with plugins, it is very
confusing for users.
If the plugin is good to be used in 'production' (in every day work) than
we should not call it -Mx.
If we know it has problems but some user needs it we can call it 'beta'.

Enrico






> On Tue, Nov 12, 2019 at 6:51 AM Tibor Digana 
> wrote:
> >
> > Hi Elliotte,
> >
> > I am also using milestones in Surefire, as you may have noticed, because
> > the complete work is too big and for one release.
> > As for instance, milestones are fantastic for the major versions like in
> > 3.0.0 because it is the only chance when you can break some backwards
> > compatibility in plugin configuration.
> > That's our case. For instance the system properties for config parameters
> > of plugins share the same because they do not have prefixes. So i put the
> > prefix in the system property and that's what i break, a little. It was
> > just an example, but this is the principle that i understand and we
> > untilize it in the milestones.
> >
> > T
> >
> > On Mon, Nov 11, 2019 at 7:55 PM Elliotte Rusty Harold <
> elh...@ibiblio.org>
> > wrote:
> >
> > > What is the significance of the M2/M3 classifier in the version
> > > string? It's not obvious to me whether this is a release version or
> > > not.
> > >
> > > Is there a reason not to call this simply 3.0.0 or 3.0.1?
> > >
> > > On Mon, Nov 11, 2019 at 1:50 PM Karl Heinz Marbaise  >
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > I've seen there are a lot of fixes in the meantime in the current
> state
> > > > so I would like to cut a release and the end of the week.
> > > >
> > > > So if someone has any objections please raise your hand.
> > > >
> > > > Kind regards
> > > > Karl Heinz Marbaise
> > > >
> > > > -
> > > > 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
> > >
> > >
>
>
>
> --
> 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: Maven Enforcer Release-3.0.0-M3

[Elliotte Rusty Harold]

I'm a little nervous about this is being messages to and being
understood by developers. How stable is a milestone release? If it's
not stable, they shouldn't be seeing as abroad an adoption as they
are. If it is stable, then why not give it a full release as 3.0.0.
(or whatever) and add more in 3.1.0, 3.2.0, etc.?

On Tue, Nov 12, 2019 at 6:51 AM Tibor Digana  wrote:
>
> Hi Elliotte,
>
> I am also using milestones in Surefire, as you may have noticed, because
> the complete work is too big and for one release.
> As for instance, milestones are fantastic for the major versions like in
> 3.0.0 because it is the only chance when you can break some backwards
> compatibility in plugin configuration.
> That's our case. For instance the system properties for config parameters
> of plugins share the same because they do not have prefixes. So i put the
> prefix in the system property and that's what i break, a little. It was
> just an example, but this is the principle that i understand and we
> untilize it in the milestones.
>
> T
>
> On Mon, Nov 11, 2019 at 7:55 PM Elliotte Rusty Harold 
> wrote:
>
> > What is the significance of the M2/M3 classifier in the version
> > string? It's not obvious to me whether this is a release version or
> > not.
> >
> > Is there a reason not to call this simply 3.0.0 or 3.0.1?
> >
> > On Mon, Nov 11, 2019 at 1:50 PM Karl Heinz Marbaise 
> > wrote:
> > >
> > > Hi,
> > >
> > > I've seen there are a lot of fixes in the meantime in the current state
> > > so I would like to cut a release and the end of the week.
> > >
> > > So if someone has any objections please raise your hand.
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > > -
> > > 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
> >
> >



-- 
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: Maven Enforcer Release-3.0.0-M3

[Tibor Digana]

Hi Elliotte,

I am also using milestones in Surefire, as you may have noticed, because
the complete work is too big and for one release.
As for instance, milestones are fantastic for the major versions like in
3.0.0 because it is the only chance when you can break some backwards
compatibility in plugin configuration.
That's our case. For instance the system properties for config parameters
of plugins share the same because they do not have prefixes. So i put the
prefix in the system property and that's what i break, a little. It was
just an example, but this is the principle that i understand and we
untilize it in the milestones.

T

On Mon, Nov 11, 2019 at 7:55 PM Elliotte Rusty Harold 
wrote:

> What is the significance of the M2/M3 classifier in the version
> string? It's not obvious to me whether this is a release version or
> not.
>
> Is there a reason not to call this simply 3.0.0 or 3.0.1?
>
> On Mon, Nov 11, 2019 at 1:50 PM Karl Heinz Marbaise 
> wrote:
> >
> > Hi,
> >
> > I've seen there are a lot of fixes in the meantime in the current state
> > so I would like to cut a release and the end of the week.
> >
> > So if someone has any objections please raise your hand.
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > 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
>
>

Re: JDK 14 - Early Access build 22 is available

[Dalibor Topic]

Hi Tibor,

I'd recommend watching Brian's talk at 
https://www.youtube.com/watch?v=1H4vmT-Va4o for the latest status update 
on Project Valhalla from the JVM Language Summit in August, where JEP 
169 is explored.


Sergey gave a talk at Oracle Code One discussing the performance aspects 
which is available at https://www.youtube.com/watch?v=pS3JAjWKW8Y .


You can follow the work of the expert group on the observers mailing 
list: https://mail.openjdk.java.net/pipermail/valhalla-spec-observers/


Finally, work on JDK 15 will start once JDK 14 reaches rampdown - that 
includes targeting features that are ready for that particular release. 
So it's not really possible to say ahead of time what would make it into 
JDK 15.


You can find the JDK 14 schedule at 
https://openjdk.java.net/projects/jdk/14/ .


cheers,
dalibor topic



On 12.11.2019 11:27, Tibor Digana wrote:

Hi Rory,

Can you explain the progress of the work in Value Objects (JEP-169) and 
proposed final release for it?
You are here, so I want to utilize it and hear what is normally not 
written on your pages.

It is quite important feature for the performance and memory consumption.
Would you introduce it in JDK 15 without the overview switch?
Thx


Cheers
Tibor17


On Tue, Nov 12, 2019 at 11:05 AM Rory O'Donnell 
mailto:rory.odonn...@oracle.com>> wrote:


Hi Robert ,

*OpenJDK builds  - JDK 14 *- Early Access build 22 is available at
http://jdk.java.net/14/

These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
.

   * Release notes
       o https://jdk.java.net/14/release-notes

   * JEPs targeted to JDK 14, so far:

       * JEP 345: NUMA-Aware Memory Allocation for G1
          was Targeted to JDK 14.
       * JEP 349: JFR Event Streaming
          was Integrated.
       * JEP 361: Switch Expressions (Standard)
          was Targeted to JDK 14.
       * JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
         Collector  was
Targeted to JDK 14.
       * JEP 364: ZGC on macOS  was
         Targeted to JDK 14.
       * JEP 365: ZGC on Windows
 moved
         to Candidate.
       * JEP 366: Deprecate the ParallelScavenge + SerialOld GC
         Combination  was Proposed to
         target JDK 14.
       * JEP 367: Remove the Pack200 Tools and API
          was Targeted to JDK 14.
       * JEP 368: Text Blocks (Second Preview)
          moved to Candidate.

   * Changes in this build




*jpackage EA -* Build 14-jpackage+1-67 (2019/11/4)

   * This is an early access build of JEP 343: Packaging Tool
     , aimed at testing a prototype
     implementation of jpackage, which is a new tool for packaging
     self-contained Java applications along with a Java Runtime
Environment.
   * These early-access builds are provided under the GNU General Public
     License, version 2, with the Classpath Exception
     
   * Build 14 is now available http://jdk.java.net/jpackage/
   * Please send feedback via e-mail to
core-libs-...@openjdk.java.net 
     >



-- 
Rgds, Rory O'Donnell

Quality Engineering Manager
Oracle EMEA, Dublin, Ireland



--

Dalibor Topic | Consulting Product Manager
Phone: +494089091214  | Mobile: +491737185961
 | Video: dalibor.to...@oracle.com


Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRB 246209
Geschäftsführer: Ralf Herrmann

 Oracle is committed to developing
practices and products that help protect the environment

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

Maven Surefire/Failsafe Release-3.0.0-M4

[Tibor Digana]

Hi,

There are altogether 43 bugfixes in the JIRA.
I would like to start a new release Vote today evening.

Kind regards,
Tibor17

Re: JDK 14 - Early Access build 22 is available

[Tibor Digana]

Hi Rory,

Can you explain the progress of the work in Value Objects (JEP-169) and
proposed final release for it?
You are here, so I want to utilize it and hear what is normally not written
on your pages.
It is quite important feature for the performance and memory consumption.
Would you introduce it in JDK 15 without the overview switch?
Thx


Cheers
Tibor17


On Tue, Nov 12, 2019 at 11:05 AM Rory O'Donnell 
wrote:

> Hi Robert ,
>
> *OpenJDK builds  - JDK 14 *- Early Access build 22 is available at
> http://jdk.java.net/14/
>
> These early-access, open-source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception
> .
>
>   * Release notes
>   o https://jdk.java.net/14/release-notes
>
>   * JEPs targeted to JDK 14, so far:
>
>   * JEP 345: NUMA-Aware Memory Allocation for G1
>  was Targeted to JDK 14.
>   * JEP 349: JFR Event Streaming
>  was Integrated.
>   * JEP 361: Switch Expressions (Standard)
>  was Targeted to JDK 14.
>   * JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
> Collector  was Targeted to JDK
> 14.
>   * JEP 364: ZGC on macOS  was
> Targeted to JDK 14.
>   * JEP 365: ZGC on Windows  moved
> to Candidate.
>   * JEP 366: Deprecate the ParallelScavenge + SerialOld GC
> Combination  was Proposed to
> target JDK 14.
>   * JEP 367: Remove the Pack200 Tools and API
>  was Targeted to JDK 14.
>   * JEP 368: Text Blocks (Second Preview)
>  moved to Candidate.
>
>   * Changes in this build
> <
> http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B21%22%3A%3A%22jdk-14%2B22%22-%22jdk-14%2B21%22%29=1000
> >
>
> *jpackage EA -* Build 14-jpackage+1-67 (2019/11/4)
>
>   * This is an early access build of JEP 343: Packaging Tool
> , aimed at testing a prototype
> implementation of jpackage, which is a new tool for packaging
> self-contained Java applications along with a Java Runtime Environment.
>   * These early-access builds are provided under the GNU General Public
> License, version 2, with the Classpath Exception
> 
>   * Build 14 is now available http://jdk.java.net/jpackage/
>   * Please send feedback via e-mail to core-libs-...@openjdk.java.net
> 
>
>
>
> --
> Rgds, Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA, Dublin, Ireland
>
>

JDK 14 - Early Access build 22 is available

[Rory O'Donnell]

Hi Robert ,

*OpenJDK builds  - JDK 14 *- Early Access build 22 is available at 
http://jdk.java.net/14/


These early-access, open-source builds are provided under the GNU 
General Public License, version 2, with the Classpath Exception 
.


 * Release notes
 o https://jdk.java.net/14/release-notes

 * JEPs targeted to JDK 14, so far:

 * JEP 345: NUMA-Aware Memory Allocation for G1
    was Targeted to JDK 14.
 * JEP 349: JFR Event Streaming
    was Integrated.
 * JEP 361: Switch Expressions (Standard)
    was Targeted to JDK 14.
 * JEP 363: Remove the Concurrent Mark Sweep (CMS) Garbage
   Collector  was Targeted to JDK 14.
 * JEP 364: ZGC on macOS  was
   Targeted to JDK 14.
 * JEP 365: ZGC on Windows  moved
   to Candidate.
 * JEP 366: Deprecate the ParallelScavenge + SerialOld GC
   Combination  was Proposed to
   target JDK 14.
 * JEP 367: Remove the Pack200 Tools and API
    was Targeted to JDK 14.
 * JEP 368: Text Blocks (Second Preview)
    moved to Candidate.

 * Changes in this build
   


*jpackage EA -* Build 14-jpackage+1-67 (2019/11/4)

 * This is an early access build of JEP 343: Packaging Tool
   , aimed at testing a prototype
   implementation of jpackage, which is a new tool for packaging
   self-contained Java applications along with a Java Runtime Environment.
 * These early-access builds are provided under the GNU General Public
   License, version 2, with the Classpath Exception
   
 * Build 14 is now available http://jdk.java.net/jpackage/
 * Please send feedback via e-mail to core-libs-...@openjdk.java.net
   



--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland

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 knowledge regarding poms. The lifecycle-owner and plugin-owner
> > know much better what they're doing.
> >
> > thanks,
> > Robert
> >
> > Some food for thoughts: consider a developer that wants to run up until
> > pre-integration-test, because he wants to bring his system in a certain
> > state so he can work with IDE to do some work.Can we say that If And Only
> > 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
>