Re: Dynamic phases proposal

[Robert Scholte]

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

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

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

Re: Skip project when generating archetypes

[Lukasz Lenart]

Done, JIRA ticket is here https://issues.apache.org/jira/browse/ARCHETYPE-583


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

pon., 11 lis 2019 o 20:44 Robert Scholte  napisał(a):
>
> Github is not our issue management system, could you create a JIRA issue at 
> https://issues.apache.org/jira/browse/ARCHETYPE
>
> thanks,
> Robert
> On 11-11-2019 20:40:33, Lukasz Lenart  wrote:
> Here is draft PR
>
> https://github.com/apache/maven-archetype/pull/33
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> -
> 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: Scripting Maven Plugin ?

[Robert Scholte]

I'd say start a release. As it is based on JSR223 is should be very easy for 
any scripting language to be supported.

Robert
On 11-11-2019 22:29:26, Enrico Olivelli  wrote:
Hi,
we have a plugin, the maven-scripting-plugin that has never been released !!

https://github.com/apache/maven-scripting-plugin

Many months ago I tried to help the plugin as it had a contribution.

Shall we cut a release or shall we drop it ?

In case of a release, I can do it, but I will need PMC help to setup the
website and that kind of stuff.

Is there a real value for this?

Enrico

[RESULT] [VOTE] Release Apache Wagon version 3.3.4

[Hervé BOUTEMY]

Hi,

The vote has passed with the following result:

+1 : Michael Osipov, Olivier Lamy, Enrico Olivelli, Hervé Boutemy

-1: Vladimir Sitnikov

We'll fix the wagon-http-<>-shaded.jar licensing issue in a next release: many 
options available require some time to select the best approach

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

Re: [VOTE] Release Apache Wagon version 3.3.4

[Hervé BOUTEMY]

here is my +1

Regards,

Hervé

Le dimanche 3 novembre 2019, 21:04:16 CET Hervé BOUTEMY a écrit :
> Hi,
> 
> We solved 5 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122
> rsion=12345956=Text
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20sta
> tus%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1535/
> https://repository.apache.org/content/repositories/maven-1535/org/apache/mav
> en/wagon/wagon/3.3.4/wagon-3.3.4-source-release.zip
> 
> Source release checksum(s):
> wagon-3.3.4-source-release.zip sha512:
> 1484d17bede842ed45ae3642ccb12f585489a95604fd100a4fddea05e39b0d0471a3d878c82
> 52cc2a29fcdc4f3d2ec0dd25629842ea4443d7557e488b0f3c25f
> 
> Staging site:
> https://maven.apache.org/wagon-archives/wagon-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

Scripting Maven Plugin ?

[Enrico Olivelli]

Hi,
we have a plugin, the maven-scripting-plugin that has never been released !!

https://github.com/apache/maven-scripting-plugin

Many months ago I tried to help the plugin as it had a contribution.

Shall we cut a release or shall we drop it ?

In case of a release, I can do it, but I will need PMC help to setup the
website and that kind of stuff.

Is there a real value for this?

Enrico

Re: [VOTE] Release Apache Wagon version 3.3.4

[Enrico Olivelli]

+1 (non binding) from me in the current form.
I have tested on Linux (Fedora 30) + jdk8 (1.8.0_222, vendor: AdoptOpenJDK)

The licensing issue can be addressed in a new release, we have ideas and we
are working on it.
In my opinion it is not good to block this release.
Wagon Http is used and distributed directly in Maven Core and we can fix
LICENSE/NOTICE files in the zip/tars of Maven Core in 3.6.3 or even 3.6.4

Enrico

Il giorno mer 6 nov 2019 alle ore 07:48 Enrico Olivelli 
ha scritto:

> Thank you Vladimir.
> This problem affects Maven core binary package, as you already reported.
>
> For the source release we do not have a real problem as we did not
> copy/paste Jsoup code.
>
> For binary release (that actually is not part of the official VOTE), the
> jar we are deploying to Maven central, I think we can only bundle the
> LICENSE file of Jsoup inside the jar such LICENSE file includes the NOTICE
> we are talking about.
>
> This is really some task we should document in maven shade plugin website,
> or at least mention that whoever embeds another library to handle this kind
> of problem
>
> I wonder if we could enhance the pom in the future to report machiene
> readable statements like 'the artifact will include a binary copy of this
> other third party pom'
> (I apologize, I don't want to pollute the vote thread, but this is somehow
> related)
> Enrico
>
> Il mer 6 nov 2019, 00:38 Tibor Digana  ha scritto:
>
>> The MIT license can be included in the project
>> https://www.apache.org/legal/resolved.html
>> Are we talking about the file /META-INF/DEPENDENCIES in JAR?
>>
>> On Tue, Nov 5, 2019 at 8:10 PM Vladimir Sitnikov <
>> sitnikov.vladi...@gmail.com> wrote:
>>
>> > > Staging repo:
>> > > https://repository.apache.org/content/repositories/maven-1535/
>> >
>> > -1 since
>> >
>> >
>> https://repository.apache.org/content/repositories/maven-1535/org/apache/maven/wagon/wagon-http/3.3.4/wagon-http-3.3.4-shaded.jar
>> > violates licensing terms for the third-party code.
>> > One of the violations is org.jsoup:jsoup.
>> >
>> > I know releases may not be vetoed (
>> > https://www.apache.org/foundation/voting.html#ReleaseVotes )
>> > However, there's
>> >
>> > > http://www.apache.org/legal/release-policy.html#licensing
>> > >Every ASF release MUST comply with ASF licensing policy. This
>> requirement
>> > is of utmost importance
>> >
>> > Vladimir
>> >
>>
>

[VOTE] Release Apache Maven EAR Plugin version 3.0.2

[Karl Heinz Marbaise]

Hi,

We solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317422=12343262

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MEAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1537

https://repository.apache.org/service/local/repositories/maven-1537/content/org/apache/maven/plugins/maven-ear-plugin/3.0.2/maven-ear-plugin-3.0.2-source-release.zip

Source release checksum(s):

maven-ear-plugin-3.0.2-source-release.zip sha512:
cd62f363822124db80af1af4f95100e6b854a73e3b496eb8eb92ac04ff78a7565fb3db30b14948b3c1af5805777bd581bfc2154de248b3e2b031a12c511c1404

maven-ear-plugin-3.0.2-source-release.zip sha1:
e447d75233b223a4b311129783a4c53f419a38bb

Staging site:
https://maven.apache.org/plugins-archives/maven-ear-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

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: Skip project when generating archetypes

[Robert Scholte]

Github is not our issue management system, could you create a JIRA issue at 
https://issues.apache.org/jira/browse/ARCHETYPE

thanks,
Robert
On 11-11-2019 20:40:33, Lukasz Lenart  wrote:
Here is draft PR

https://github.com/apache/maven-archetype/pull/33


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

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

Re: Skip project when generating archetypes

[Lukasz Lenart]

Here is draft PR

https://github.com/apache/maven-archetype/pull/33


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

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

Re: Dynamic phases proposal

[Stephen Connolly]

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
> 

Re: Maven Enforcer Release-3.0.0-M3

[Karl Heinz Marbaise]

Hi Elliotte,

On 11.11.19 19:55, 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.


This is a milestone which is not finally the whole work intended to be
done for 3.0.0 which will take more time todo but the last release is a
little bit too long ago...so the -M3 release contains already fixed
issues which bothers people...just reading/hearing the community.

The final work can be done without bothering the people for issues which
already have been fixed. That make them happy.

Kind regards
Karl Heinz Marbaise




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

Re: Skip project when generating archetypes

[Lukasz Lenart]

W dniu pon., 11.11.2019 o 19:24 Robert Scholte 
napisał(a):

> bq. Now an empty archetype is added to the catalog.
>
> So this is what should be fixed, don't introduce a skip-parameter for it.


Hm... I can try to detect project packaging but I am not sure if everyone
is using maven-archetype [1] these days or rather pom.

[1]
https://maven.apache.org/archetype/archetype-packaging/


Regards
Łukasz


-- 
(mobile)

Re: Maven Enforcer Release-3.0.0-M3

[Elliotte Rusty Harold]

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

Maven Enforcer Release-3.0.0-M3

[Karl Heinz Marbaise]

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

Re: Skip project when generating archetypes

[Robert Scholte]

bq. Now an empty archetype is added to the catalog.

So this is what should be fixed, don't introduce a skip-parameter for it.

Robert
On 11-11-2019 18:39:38, Lukasz Lenart  wrote:
Hi,

Is there an option to skip a project when updating local catalog? I
have a multi-module project and I would like to skip the parent
project when updating the catalog. Now an empty archetype is added to
the catalog.

I noticed that there is option but it's used to skip
integration tests, not the project itself.

If there is no such option I can prepare a PR.


Thanks in advance
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

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

Re: Surefire 3.0.0-M4 release?

[Romain Manni-Bucau]

This is not the point Tibor and I'll just repeat it a last time: there are
fixes in this version - rerun is not one - and we agreed one month ago to
let it be released as a milestone. There is no real way to excuse the fact
we missed it cause of other featurethis is exactly why it is milestones
and not final releases.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 11 nov. 2019 à 18:08, Tibor Digana  a
écrit :

> Romain, You have to understand also me, users, contributors. You are not
> alone. Olivier is also not alone.
> See the others, e.g. Enrico, Jonathan, Matt, etc. They are greatly
> communicating, understanding, and they are petitioned what it means to
> accept requirements from others and making a compromises!
> I think Olivier undeerstood it very well on Slack and he made a compromise.
> We all understand that he needs to use this version in Jenkins project and
> he understands that the issue SUREFIRE-1584 is incomplete and that's what
> we are fixing right now because it is worth to spend a day to say that the
> rerun works for parameterized tests as well. The users want it and it is
> not so time spending issue acctualy.
>
> On Mon, Nov 11, 2019 at 5:50 PM Romain Manni-Bucau 
> wrote:
>
> > @Tibor: I'd like to gently remind you that we - asf - are community
> driven
> > and holding a release is generally bad if it does not bite us after which
> > is the case there. As mentionned by Olivier we already agreed to release
> > and it got delayed for no reason compared to the original agreement.
> Please
> > understand this is not about the work you are doing - we can discuss it
> at
> > another moment since, as you mentionned we don't fully agree here, but
> the
> > point there was totally different and user centric. Please take care to
> > re-read and see you just forked that thread alone. No big deal while the
> > release pops up next week but no need to start an argument too ;).
> >
> > 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 lun. 11 nov. 2019 à 17:26, Tibor Digana  a
> > écrit :
> >
> > > Roman, it does not make sense to continue with you because you do not
> > > understand the whole track with this project, and again nobody said
> > > anything about architecture. It's your permanent opinions and very bad
> > > attitude. So it is waste of the time to continue to explain the same
> > things
> > > over rand over again to You.
> > > Read emails and understand them first or or just watch the ML if you do
> > not
> > > want to understand it.
> > >
> > > On Mon, Nov 11, 2019 at 5:21 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > @Tibor: point is more that we don't need to hold a milestone for a
> > > feature,
> > > > we can just release and let fixes get out and get this huge
> > architectural
> > > > change in another milestone. Only valid reason to delay a release is
> > IMO
> > > a
> > > > regression or a major change we can't revert later (3.0.0 would be in
> > > this
> > > > bucket, not a milestone).
> > > >
> > > > 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 lun. 11 nov. 2019 à 16:54, Tibor Digana 
> a
> > > > écrit :
> > > >
> > > > > The reason of M4 was to introduce TCP communication.
> > > > > Meanwhile first we wanted to cut the release one month ago but we
> > > > postponed
> > > > > it and we were waiting for clarifying license issues and fixed J13
> > > issue
> > > > > yesterday.
> > > > > I was working on TCP/Pipes together with Jonathan Bell and we
> wanted
> > to
> > > > > make it in M4 which was our plan but we still have only 35% of the
> > > total
> > > > > work and there are several things which are too detailed to
> mention.
> > So
> > > > > this has to continue and my estimation is that we need to spend 20
> > > days.
> > > > We
> > > > > were working on it quite intensively in the background created few
> > PRs
> > > > and
> > > > > moved the code from one PR to another and clarified it.
> > > > > Yesterday I proposed 

Skip project when generating archetypes

[Lukasz Lenart]

Hi,

Is there an option to skip a project when updating local catalog? I
have a multi-module project and I would like to skip the parent
project when updating the catalog. Now an empty archetype is added to
the catalog.

I noticed that there is  option but it's used to skip
integration tests, not the project itself.

If there is no such option I can prepare a PR.


Thanks in advance
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

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

Re: Archetypes: problem updating local catalog

[Łukasz Lenart]

Looks like I was wrong, everything is ok when using the latest Archetype Plugin.

On 2019/11/03 15:02:56, Lukasz Lenart  wrote:
> Hi,>
>
> I'm working on Struts Archetypes [1] and discovered that running:>
>
>   mvn clean install archetype:update-local-catalog>
>
> will create/update "~/.m2/repository/archetype-catalog.xml" but using 
> command:>
>
>   mvn archetype:generate -DarchetypeCatalog=local>
>
> reads data from "~/.m2/archetype-catalog.xml" which doesn't exist.>
>
> Do I have to manually copy the file? Is it by design or maybe it's a bug?>
>
> [1] https://github.com/apache/struts-archetypes>
>
>
> Regards>
> Łukasz>
>
> ->
> 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: Surefire 3.0.0-M4 release?

[Tibor Digana]

Romain, You have to understand also me, users, contributors. You are not
alone. Olivier is also not alone.
See the others, e.g. Enrico, Jonathan, Matt, etc. They are greatly
communicating, understanding, and they are petitioned what it means to
accept requirements from others and making a compromises!
I think Olivier undeerstood it very well on Slack and he made a compromise.
We all understand that he needs to use this version in Jenkins project and
he understands that the issue SUREFIRE-1584 is incomplete and that's what
we are fixing right now because it is worth to spend a day to say that the
rerun works for parameterized tests as well. The users want it and it is
not so time spending issue acctualy.

On Mon, Nov 11, 2019 at 5:50 PM Romain Manni-Bucau 
wrote:

> @Tibor: I'd like to gently remind you that we - asf - are community driven
> and holding a release is generally bad if it does not bite us after which
> is the case there. As mentionned by Olivier we already agreed to release
> and it got delayed for no reason compared to the original agreement. Please
> understand this is not about the work you are doing - we can discuss it at
> another moment since, as you mentionned we don't fully agree here, but the
> point there was totally different and user centric. Please take care to
> re-read and see you just forked that thread alone. No big deal while the
> release pops up next week but no need to start an argument too ;).
>
> 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 lun. 11 nov. 2019 à 17:26, Tibor Digana  a
> écrit :
>
> > Roman, it does not make sense to continue with you because you do not
> > understand the whole track with this project, and again nobody said
> > anything about architecture. It's your permanent opinions and very bad
> > attitude. So it is waste of the time to continue to explain the same
> things
> > over rand over again to You.
> > Read emails and understand them first or or just watch the ML if you do
> not
> > want to understand it.
> >
> > On Mon, Nov 11, 2019 at 5:21 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > @Tibor: point is more that we don't need to hold a milestone for a
> > feature,
> > > we can just release and let fixes get out and get this huge
> architectural
> > > change in another milestone. Only valid reason to delay a release is
> IMO
> > a
> > > regression or a major change we can't revert later (3.0.0 would be in
> > this
> > > bucket, not a milestone).
> > >
> > > 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 lun. 11 nov. 2019 à 16:54, Tibor Digana  a
> > > écrit :
> > >
> > > > The reason of M4 was to introduce TCP communication.
> > > > Meanwhile first we wanted to cut the release one month ago but we
> > > postponed
> > > > it and we were waiting for clarifying license issues and fixed J13
> > issue
> > > > yesterday.
> > > > I was working on TCP/Pipes together with Jonathan Bell and we wanted
> to
> > > > make it in M4 which was our plan but we still have only 35% of the
> > total
> > > > work and there are several things which are too detailed to mention.
> So
> > > > this has to continue and my estimation is that we need to spend 20
> > days.
> > > We
> > > > were working on it quite intensively in the background created few
> PRs
> > > and
> > > > moved the code from one PR to another and clarified it.
> > > > Yesterday I proposed to Jonathan that it does not make sense to work
> on
> > > our
> > > > taks like a hell because it would prolong the development which would
> > > take
> > > > too long.
> > > > So this is the whole reason, otherwise we could already include
> > TCP/Pipes
> > > > into M4.
> > > > T
> > > >
> > > >
> > > >
> > > > On Mon, Nov 11, 2019 at 2:29 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > +1 to release next week, no reason to wait since it is another "m"
> > > > release
> > > > > IMHO
> > > > >
> > > > > Le lun. 11 nov. 2019 à 12:44, Olivier Lamy  a
> > écrit
> > > :
> > > > >
> > > > > > That will be great.
> > > > > > If you don't have time before end of the week. I'm happy to help
> > and
> > > do
> > > > > it.
> > > > > > cheers
> > > > > > Olivier
> > > > > >
> > > > > > On Mon, 11 Nov 2019 at 21:35, Tibor Digana <
> tibordig...@apache.org
> > >
> > > > > wrote:
> > > > > >
> > 

Re: Surefire 3.0.0-M4 release?

[Romain Manni-Bucau]

@Tibor: I'd like to gently remind you that we - asf - are community driven
and holding a release is generally bad if it does not bite us after which
is the case there. As mentionned by Olivier we already agreed to release
and it got delayed for no reason compared to the original agreement. Please
understand this is not about the work you are doing - we can discuss it at
another moment since, as you mentionned we don't fully agree here, but the
point there was totally different and user centric. Please take care to
re-read and see you just forked that thread alone. No big deal while the
release pops up next week but no need to start an argument too ;).

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 11 nov. 2019 à 17:26, Tibor Digana  a
écrit :

> Roman, it does not make sense to continue with you because you do not
> understand the whole track with this project, and again nobody said
> anything about architecture. It's your permanent opinions and very bad
> attitude. So it is waste of the time to continue to explain the same things
> over rand over again to You.
> Read emails and understand them first or or just watch the ML if you do not
> want to understand it.
>
> On Mon, Nov 11, 2019 at 5:21 PM Romain Manni-Bucau 
> wrote:
>
> > @Tibor: point is more that we don't need to hold a milestone for a
> feature,
> > we can just release and let fixes get out and get this huge architectural
> > change in another milestone. Only valid reason to delay a release is IMO
> a
> > regression or a major change we can't revert later (3.0.0 would be in
> this
> > bucket, not a milestone).
> >
> > 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 lun. 11 nov. 2019 à 16:54, Tibor Digana  a
> > écrit :
> >
> > > The reason of M4 was to introduce TCP communication.
> > > Meanwhile first we wanted to cut the release one month ago but we
> > postponed
> > > it and we were waiting for clarifying license issues and fixed J13
> issue
> > > yesterday.
> > > I was working on TCP/Pipes together with Jonathan Bell and we wanted to
> > > make it in M4 which was our plan but we still have only 35% of the
> total
> > > work and there are several things which are too detailed to mention. So
> > > this has to continue and my estimation is that we need to spend 20
> days.
> > We
> > > were working on it quite intensively in the background created few PRs
> > and
> > > moved the code from one PR to another and clarified it.
> > > Yesterday I proposed to Jonathan that it does not make sense to work on
> > our
> > > taks like a hell because it would prolong the development which would
> > take
> > > too long.
> > > So this is the whole reason, otherwise we could already include
> TCP/Pipes
> > > into M4.
> > > T
> > >
> > >
> > >
> > > On Mon, Nov 11, 2019 at 2:29 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > +1 to release next week, no reason to wait since it is another "m"
> > > release
> > > > IMHO
> > > >
> > > > Le lun. 11 nov. 2019 à 12:44, Olivier Lamy  a
> écrit
> > :
> > > >
> > > > > That will be great.
> > > > > If you don't have time before end of the week. I'm happy to help
> and
> > do
> > > > it.
> > > > > cheers
> > > > > Olivier
> > > > >
> > > > > On Mon, 11 Nov 2019 at 21:35, Tibor Digana  >
> > > > wrote:
> > > > >
> > > > > > @Olivier as we clarified this Slack. The release will be fast. No
> > > > delay!
> > > > > >
> > > > > > On Mon, Nov 11, 2019 at 12:07 PM Olivier Lamy 
> > > > wrote:
> > > > > >
> > > > > > > Why? delay again
> > > > > > > I thought 1 month ago we agreed ago to move non finished stuff
> to
> > > > > > 3.0.0-M5
> > > > > > > and release 3.0.0-M5 later.
> > > > > > >
> > > > > > >
> > > > > > > On Mon, 11 Nov 2019 at 20:59, Tibor Digana <
> > tibordig...@apache.org
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > Pls don't do it.
> > > > > > > > I will cut it and move some issues to M5 but I need Matt to
> > > finish
> > > > > his
> > > > > > > > work. I am in contact with Mat.
> > > > > > > > I talked about it with the contributor Jonathan Bell about
> > > > reasoning.
> > > > > > > > T
> > > > > > > >
> > > > > > > > On Mon, Nov 11, 2019 at 11:41 AM Olivier Lamy <
> > ol...@apache.org>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi
> > > > > > > > > Starting again this thread as we agreed but I didn't do it.
> > > > > > > > > 

Re: Surefire 3.0.0-M4 release?

[Tibor Digana]

Roman, it does not make sense to continue with you because you do not
understand the whole track with this project, and again nobody said
anything about architecture. It's your permanent opinions and very bad
attitude. So it is waste of the time to continue to explain the same things
over rand over again to You.
Read emails and understand them first or or just watch the ML if you do not
want to understand it.

On Mon, Nov 11, 2019 at 5:21 PM Romain Manni-Bucau 
wrote:

> @Tibor: point is more that we don't need to hold a milestone for a feature,
> we can just release and let fixes get out and get this huge architectural
> change in another milestone. Only valid reason to delay a release is IMO a
> regression or a major change we can't revert later (3.0.0 would be in this
> bucket, not a milestone).
>
> 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 lun. 11 nov. 2019 à 16:54, Tibor Digana  a
> écrit :
>
> > The reason of M4 was to introduce TCP communication.
> > Meanwhile first we wanted to cut the release one month ago but we
> postponed
> > it and we were waiting for clarifying license issues and fixed J13 issue
> > yesterday.
> > I was working on TCP/Pipes together with Jonathan Bell and we wanted to
> > make it in M4 which was our plan but we still have only 35% of the total
> > work and there are several things which are too detailed to mention. So
> > this has to continue and my estimation is that we need to spend 20 days.
> We
> > were working on it quite intensively in the background created few PRs
> and
> > moved the code from one PR to another and clarified it.
> > Yesterday I proposed to Jonathan that it does not make sense to work on
> our
> > taks like a hell because it would prolong the development which would
> take
> > too long.
> > So this is the whole reason, otherwise we could already include TCP/Pipes
> > into M4.
> > T
> >
> >
> >
> > On Mon, Nov 11, 2019 at 2:29 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > +1 to release next week, no reason to wait since it is another "m"
> > release
> > > IMHO
> > >
> > > Le lun. 11 nov. 2019 à 12:44, Olivier Lamy  a écrit
> :
> > >
> > > > That will be great.
> > > > If you don't have time before end of the week. I'm happy to help and
> do
> > > it.
> > > > cheers
> > > > Olivier
> > > >
> > > > On Mon, 11 Nov 2019 at 21:35, Tibor Digana 
> > > wrote:
> > > >
> > > > > @Olivier as we clarified this Slack. The release will be fast. No
> > > delay!
> > > > >
> > > > > On Mon, Nov 11, 2019 at 12:07 PM Olivier Lamy 
> > > wrote:
> > > > >
> > > > > > Why? delay again
> > > > > > I thought 1 month ago we agreed ago to move non finished stuff to
> > > > > 3.0.0-M5
> > > > > > and release 3.0.0-M5 later.
> > > > > >
> > > > > >
> > > > > > On Mon, 11 Nov 2019 at 20:59, Tibor Digana <
> tibordig...@apache.org
> > >
> > > > > wrote:
> > > > > >
> > > > > > > Pls don't do it.
> > > > > > > I will cut it and move some issues to M5 but I need Matt to
> > finish
> > > > his
> > > > > > > work. I am in contact with Mat.
> > > > > > > I talked about it with the contributor Jonathan Bell about
> > > reasoning.
> > > > > > > T
> > > > > > >
> > > > > > > On Mon, Nov 11, 2019 at 11:41 AM Olivier Lamy <
> ol...@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > > > Hi
> > > > > > > > Starting again this thread as we agreed but I didn't do it.
> > > > > > > > So I'd like to cut release 3.0.0-M4 by the end of this week.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, 14 Oct 2019 at 11:40, Tibor Digana <
> > > tibordig...@apache.org
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > The SUREFIRE-1689 progress has been finished until the CI
> > build
> > > > > > > succeeds.
> > > > > > > > > T
> > > > > > > > >
> > > > > > > > > On Sun, Oct 13, 2019 at 10:27 AM Robert Scholte <
> > > > > > rfscho...@apache.org>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Ah, there it is :)
> > > > > > > > > >
> > > > > > > > > > On Sun, 13 Oct 2019 08:21:53 +0200, Romain Manni-Bucau
> > > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > > Didnt expect my comment about shade to take so much
> space
> > > in
> > > > > this
> > > > > > > > > thread
> > > > > > > > > > > but yes we rely on asm for relocation:
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java#L453
> > > > > > > > > > >
> > > > > > > > > > > Le dim. 13 oct. 2019 à 00:20, Robert Scholte <
> > > > > > 

Re: Surefire 3.0.0-M4 release?

[Romain Manni-Bucau]

@Tibor: point is more that we don't need to hold a milestone for a feature,
we can just release and let fixes get out and get this huge architectural
change in another milestone. Only valid reason to delay a release is IMO a
regression or a major change we can't revert later (3.0.0 would be in this
bucket, not a milestone).

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 11 nov. 2019 à 16:54, Tibor Digana  a
écrit :

> The reason of M4 was to introduce TCP communication.
> Meanwhile first we wanted to cut the release one month ago but we postponed
> it and we were waiting for clarifying license issues and fixed J13 issue
> yesterday.
> I was working on TCP/Pipes together with Jonathan Bell and we wanted to
> make it in M4 which was our plan but we still have only 35% of the total
> work and there are several things which are too detailed to mention. So
> this has to continue and my estimation is that we need to spend 20 days. We
> were working on it quite intensively in the background created few PRs and
> moved the code from one PR to another and clarified it.
> Yesterday I proposed to Jonathan that it does not make sense to work on our
> taks like a hell because it would prolong the development which would take
> too long.
> So this is the whole reason, otherwise we could already include TCP/Pipes
> into M4.
> T
>
>
>
> On Mon, Nov 11, 2019 at 2:29 PM Romain Manni-Bucau 
> wrote:
>
> > +1 to release next week, no reason to wait since it is another "m"
> release
> > IMHO
> >
> > Le lun. 11 nov. 2019 à 12:44, Olivier Lamy  a écrit :
> >
> > > That will be great.
> > > If you don't have time before end of the week. I'm happy to help and do
> > it.
> > > cheers
> > > Olivier
> > >
> > > On Mon, 11 Nov 2019 at 21:35, Tibor Digana 
> > wrote:
> > >
> > > > @Olivier as we clarified this Slack. The release will be fast. No
> > delay!
> > > >
> > > > On Mon, Nov 11, 2019 at 12:07 PM Olivier Lamy 
> > wrote:
> > > >
> > > > > Why? delay again
> > > > > I thought 1 month ago we agreed ago to move non finished stuff to
> > > > 3.0.0-M5
> > > > > and release 3.0.0-M5 later.
> > > > >
> > > > >
> > > > > On Mon, 11 Nov 2019 at 20:59, Tibor Digana  >
> > > > wrote:
> > > > >
> > > > > > Pls don't do it.
> > > > > > I will cut it and move some issues to M5 but I need Matt to
> finish
> > > his
> > > > > > work. I am in contact with Mat.
> > > > > > I talked about it with the contributor Jonathan Bell about
> > reasoning.
> > > > > > T
> > > > > >
> > > > > > On Mon, Nov 11, 2019 at 11:41 AM Olivier Lamy 
> > > > wrote:
> > > > > >
> > > > > > > Hi
> > > > > > > Starting again this thread as we agreed but I didn't do it.
> > > > > > > So I'd like to cut release 3.0.0-M4 by the end of this week.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, 14 Oct 2019 at 11:40, Tibor Digana <
> > tibordig...@apache.org
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > The SUREFIRE-1689 progress has been finished until the CI
> build
> > > > > > succeeds.
> > > > > > > > T
> > > > > > > >
> > > > > > > > On Sun, Oct 13, 2019 at 10:27 AM Robert Scholte <
> > > > > rfscho...@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Ah, there it is :)
> > > > > > > > >
> > > > > > > > > On Sun, 13 Oct 2019 08:21:53 +0200, Romain Manni-Bucau
> > > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > > Didnt expect my comment about shade to take so much space
> > in
> > > > this
> > > > > > > > thread
> > > > > > > > > > but yes we rely on asm for relocation:
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java#L453
> > > > > > > > > >
> > > > > > > > > > Le dim. 13 oct. 2019 à 00:20, Robert Scholte <
> > > > > rfscho...@apache.org
> > > > > > >
> > > > > > > a
> > > > > > > > > > écrit :
> > > > > > > > > >
> > > > > > > > > >> On Sat, 12 Oct 2019 13:44:48 +0200, Romain Manni-Bucau
> > > > > > > > > >>  wrote:
> > > > > > > > > >>
> > > > > > > > > >> > Le sam. 12 oct. 2019 à 13:33, Robert Scholte <
> > > > > > > rfscho...@apache.org>
> > > > > > > > a
> > > > > > > > > >> > écrit :
> > > > > > > > > >> >
> > > > > > > > > >> >> As far as I know, surefire won't touch the Plexus
> Java
> > > code
> > > > > > that
> > > > > > > > > >> >> requires
> > > > > > > > > >> >> ASM.
> > > > > > > > > >> >> It is ONLY required when the runtime is Java 8 or
> lower
> > > AND
> > > > > you
> > > > > > > > > need
> > > > > > > > > >> to
> > > > > > > > > >> >> read the module descriptors.
> > > > > > > > > >> >>
> > > > > > > > > >> >> Maven Shade 

Re: Surefire 3.0.0-M4 release?

[Tibor Digana]

The reason of M4 was to introduce TCP communication.
Meanwhile first we wanted to cut the release one month ago but we postponed
it and we were waiting for clarifying license issues and fixed J13 issue
yesterday.
I was working on TCP/Pipes together with Jonathan Bell and we wanted to
make it in M4 which was our plan but we still have only 35% of the total
work and there are several things which are too detailed to mention. So
this has to continue and my estimation is that we need to spend 20 days. We
were working on it quite intensively in the background created few PRs and
moved the code from one PR to another and clarified it.
Yesterday I proposed to Jonathan that it does not make sense to work on our
taks like a hell because it would prolong the development which would take
too long.
So this is the whole reason, otherwise we could already include TCP/Pipes
into M4.
T



On Mon, Nov 11, 2019 at 2:29 PM Romain Manni-Bucau 
wrote:

> +1 to release next week, no reason to wait since it is another "m" release
> IMHO
>
> Le lun. 11 nov. 2019 à 12:44, Olivier Lamy  a écrit :
>
> > That will be great.
> > If you don't have time before end of the week. I'm happy to help and do
> it.
> > cheers
> > Olivier
> >
> > On Mon, 11 Nov 2019 at 21:35, Tibor Digana 
> wrote:
> >
> > > @Olivier as we clarified this Slack. The release will be fast. No
> delay!
> > >
> > > On Mon, Nov 11, 2019 at 12:07 PM Olivier Lamy 
> wrote:
> > >
> > > > Why? delay again
> > > > I thought 1 month ago we agreed ago to move non finished stuff to
> > > 3.0.0-M5
> > > > and release 3.0.0-M5 later.
> > > >
> > > >
> > > > On Mon, 11 Nov 2019 at 20:59, Tibor Digana 
> > > wrote:
> > > >
> > > > > Pls don't do it.
> > > > > I will cut it and move some issues to M5 but I need Matt to finish
> > his
> > > > > work. I am in contact with Mat.
> > > > > I talked about it with the contributor Jonathan Bell about
> reasoning.
> > > > > T
> > > > >
> > > > > On Mon, Nov 11, 2019 at 11:41 AM Olivier Lamy 
> > > wrote:
> > > > >
> > > > > > Hi
> > > > > > Starting again this thread as we agreed but I didn't do it.
> > > > > > So I'd like to cut release 3.0.0-M4 by the end of this week.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, 14 Oct 2019 at 11:40, Tibor Digana <
> tibordig...@apache.org
> > >
> > > > > wrote:
> > > > > >
> > > > > > > The SUREFIRE-1689 progress has been finished until the CI build
> > > > > succeeds.
> > > > > > > T
> > > > > > >
> > > > > > > On Sun, Oct 13, 2019 at 10:27 AM Robert Scholte <
> > > > rfscho...@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Ah, there it is :)
> > > > > > > >
> > > > > > > > On Sun, 13 Oct 2019 08:21:53 +0200, Romain Manni-Bucau
> > > > > > > >  wrote:
> > > > > > > >
> > > > > > > > > Didnt expect my comment about shade to take so much space
> in
> > > this
> > > > > > > thread
> > > > > > > > > but yes we rely on asm for relocation:
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java#L453
> > > > > > > > >
> > > > > > > > > Le dim. 13 oct. 2019 à 00:20, Robert Scholte <
> > > > rfscho...@apache.org
> > > > > >
> > > > > > a
> > > > > > > > > écrit :
> > > > > > > > >
> > > > > > > > >> On Sat, 12 Oct 2019 13:44:48 +0200, Romain Manni-Bucau
> > > > > > > > >>  wrote:
> > > > > > > > >>
> > > > > > > > >> > Le sam. 12 oct. 2019 à 13:33, Robert Scholte <
> > > > > > rfscho...@apache.org>
> > > > > > > a
> > > > > > > > >> > écrit :
> > > > > > > > >> >
> > > > > > > > >> >> As far as I know, surefire won't touch the Plexus Java
> > code
> > > > > that
> > > > > > > > >> >> requires
> > > > > > > > >> >> ASM.
> > > > > > > > >> >> It is ONLY required when the runtime is Java 8 or lower
> > AND
> > > > you
> > > > > > > > need
> > > > > > > > >> to
> > > > > > > > >> >> read the module descriptors.
> > > > > > > > >> >>
> > > > > > > > >> >> Maven Shade is a different case: it must parse the Java
> > > > > bytecode
> > > > > > > (and
> > > > > > > > >> >> only
> > > > > > > > >> >> when using minifyJar), hence it needs the latest ASM.
> > > > > > > > >> >>
> > > > > > > > >> >
> > > > > > > > >> > + Relocation ;)
> > > > > > > > >>
> > > > > > > > >> Well, the unexpected answer is actually No, see
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/relocation/SimpleRelocator.java
> > > > > > > > >>
> > > > > > > > >> (but it might be better to do so...)
> > > > > > > > >>
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> >> Robert
> > > > > > > > >> >>
> > > > > > > > >> >> On Sat, 12 Oct 2019 11:35:05 +0200, Tibor Digana
> > > > > > > > >> >> 
> > > > > > > > >> >>
> > > > > > > > >> >> wrote:
> > > > > > > > >> >>
> > > > > > > > >> 

Re: Surefire 3.0.0-M4 release?

[Romain Manni-Bucau]

+1 to release next week, no reason to wait since it is another "m" release
IMHO

Le lun. 11 nov. 2019 à 12:44, Olivier Lamy  a écrit :

> That will be great.
> If you don't have time before end of the week. I'm happy to help and do it.
> cheers
> Olivier
>
> On Mon, 11 Nov 2019 at 21:35, Tibor Digana  wrote:
>
> > @Olivier as we clarified this Slack. The release will be fast. No delay!
> >
> > On Mon, Nov 11, 2019 at 12:07 PM Olivier Lamy  wrote:
> >
> > > Why? delay again
> > > I thought 1 month ago we agreed ago to move non finished stuff to
> > 3.0.0-M5
> > > and release 3.0.0-M5 later.
> > >
> > >
> > > On Mon, 11 Nov 2019 at 20:59, Tibor Digana 
> > wrote:
> > >
> > > > Pls don't do it.
> > > > I will cut it and move some issues to M5 but I need Matt to finish
> his
> > > > work. I am in contact with Mat.
> > > > I talked about it with the contributor Jonathan Bell about reasoning.
> > > > T
> > > >
> > > > On Mon, Nov 11, 2019 at 11:41 AM Olivier Lamy 
> > wrote:
> > > >
> > > > > Hi
> > > > > Starting again this thread as we agreed but I didn't do it.
> > > > > So I'd like to cut release 3.0.0-M4 by the end of this week.
> > > > >
> > > > >
> > > > >
> > > > > On Mon, 14 Oct 2019 at 11:40, Tibor Digana  >
> > > > wrote:
> > > > >
> > > > > > The SUREFIRE-1689 progress has been finished until the CI build
> > > > succeeds.
> > > > > > T
> > > > > >
> > > > > > On Sun, Oct 13, 2019 at 10:27 AM Robert Scholte <
> > > rfscho...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Ah, there it is :)
> > > > > > >
> > > > > > > On Sun, 13 Oct 2019 08:21:53 +0200, Romain Manni-Bucau
> > > > > > >  wrote:
> > > > > > >
> > > > > > > > Didnt expect my comment about shade to take so much space in
> > this
> > > > > > thread
> > > > > > > > but yes we rely on asm for relocation:
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java#L453
> > > > > > > >
> > > > > > > > Le dim. 13 oct. 2019 à 00:20, Robert Scholte <
> > > rfscho...@apache.org
> > > > >
> > > > > a
> > > > > > > > écrit :
> > > > > > > >
> > > > > > > >> On Sat, 12 Oct 2019 13:44:48 +0200, Romain Manni-Bucau
> > > > > > > >>  wrote:
> > > > > > > >>
> > > > > > > >> > Le sam. 12 oct. 2019 à 13:33, Robert Scholte <
> > > > > rfscho...@apache.org>
> > > > > > a
> > > > > > > >> > écrit :
> > > > > > > >> >
> > > > > > > >> >> As far as I know, surefire won't touch the Plexus Java
> code
> > > > that
> > > > > > > >> >> requires
> > > > > > > >> >> ASM.
> > > > > > > >> >> It is ONLY required when the runtime is Java 8 or lower
> AND
> > > you
> > > > > > > need
> > > > > > > >> to
> > > > > > > >> >> read the module descriptors.
> > > > > > > >> >>
> > > > > > > >> >> Maven Shade is a different case: it must parse the Java
> > > > bytecode
> > > > > > (and
> > > > > > > >> >> only
> > > > > > > >> >> when using minifyJar), hence it needs the latest ASM.
> > > > > > > >> >>
> > > > > > > >> >
> > > > > > > >> > + Relocation ;)
> > > > > > > >>
> > > > > > > >> Well, the unexpected answer is actually No, see
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/relocation/SimpleRelocator.java
> > > > > > > >>
> > > > > > > >> (but it might be better to do so...)
> > > > > > > >>
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> >> Robert
> > > > > > > >> >>
> > > > > > > >> >> On Sat, 12 Oct 2019 11:35:05 +0200, Tibor Digana
> > > > > > > >> >> 
> > > > > > > >> >>
> > > > > > > >> >> wrote:
> > > > > > > >> >>
> > > > > > > >> >> > We still use plexus-java:1.0.3 which depends on ASM
> 7.0.
> > > > > > > >> >> > The support for JDk 13 and 14 is in the version 7.2.
> > > > > > > >> >> > We have similar upgrade in
> > > > > > > >> >> > https://github.com/apache/maven-shade-plugin/pull/29
> > > > > > > >> >> >
> > > > > > > >> >> > On Thu, Oct 10, 2019 at 2:53 AM Olivier Lamy <
> > > > ol...@apache.org
> > > > > >
> > > > > > > >> wrote:
> > > > > > > >> >> >
> > > > > > > >> >> >> Hi,
> > > > > > > >> >> >> It's now almost 10 months since last and around 30
> > issues
> > > > > fixed.
> > > > > > > >> >> >> Maybe time for a new release?
> > > > > > > >> >> >> Moving issues still open to 3.0.0-M5?
> > > > > > > >> >> >>
> > > > > > > >> >> >> cheers
> > > > > > > >> >> >> --
> > > > > > > >> >> >> Olivier Lamy
> > > > > > > >> >>
> > > > > > > >> >>
> > > > > >
> > -
> > > > > > > >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > > > >> >> For additional commands, e-mail:
> dev-h...@maven.apache.org
> > > > > > > >> >>
> > > > > > > >>
> > > > > > > >>
> > > > >
> -
> > > > > > > >> To unsubscribe, 

Re: Surefire 3.0.0-M4 release?

[Olivier Lamy]

That will be great.
If you don't have time before end of the week. I'm happy to help and do it.
cheers
Olivier

On Mon, 11 Nov 2019 at 21:35, Tibor Digana  wrote:

> @Olivier as we clarified this Slack. The release will be fast. No delay!
>
> On Mon, Nov 11, 2019 at 12:07 PM Olivier Lamy  wrote:
>
> > Why? delay again
> > I thought 1 month ago we agreed ago to move non finished stuff to
> 3.0.0-M5
> > and release 3.0.0-M5 later.
> >
> >
> > On Mon, 11 Nov 2019 at 20:59, Tibor Digana 
> wrote:
> >
> > > Pls don't do it.
> > > I will cut it and move some issues to M5 but I need Matt to finish his
> > > work. I am in contact with Mat.
> > > I talked about it with the contributor Jonathan Bell about reasoning.
> > > T
> > >
> > > On Mon, Nov 11, 2019 at 11:41 AM Olivier Lamy 
> wrote:
> > >
> > > > Hi
> > > > Starting again this thread as we agreed but I didn't do it.
> > > > So I'd like to cut release 3.0.0-M4 by the end of this week.
> > > >
> > > >
> > > >
> > > > On Mon, 14 Oct 2019 at 11:40, Tibor Digana 
> > > wrote:
> > > >
> > > > > The SUREFIRE-1689 progress has been finished until the CI build
> > > succeeds.
> > > > > T
> > > > >
> > > > > On Sun, Oct 13, 2019 at 10:27 AM Robert Scholte <
> > rfscho...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Ah, there it is :)
> > > > > >
> > > > > > On Sun, 13 Oct 2019 08:21:53 +0200, Romain Manni-Bucau
> > > > > >  wrote:
> > > > > >
> > > > > > > Didnt expect my comment about shade to take so much space in
> this
> > > > > thread
> > > > > > > but yes we rely on asm for relocation:
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java#L453
> > > > > > >
> > > > > > > Le dim. 13 oct. 2019 à 00:20, Robert Scholte <
> > rfscho...@apache.org
> > > >
> > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > >> On Sat, 12 Oct 2019 13:44:48 +0200, Romain Manni-Bucau
> > > > > > >>  wrote:
> > > > > > >>
> > > > > > >> > Le sam. 12 oct. 2019 à 13:33, Robert Scholte <
> > > > rfscho...@apache.org>
> > > > > a
> > > > > > >> > écrit :
> > > > > > >> >
> > > > > > >> >> As far as I know, surefire won't touch the Plexus Java code
> > > that
> > > > > > >> >> requires
> > > > > > >> >> ASM.
> > > > > > >> >> It is ONLY required when the runtime is Java 8 or lower AND
> > you
> > > > > > need
> > > > > > >> to
> > > > > > >> >> read the module descriptors.
> > > > > > >> >>
> > > > > > >> >> Maven Shade is a different case: it must parse the Java
> > > bytecode
> > > > > (and
> > > > > > >> >> only
> > > > > > >> >> when using minifyJar), hence it needs the latest ASM.
> > > > > > >> >>
> > > > > > >> >
> > > > > > >> > + Relocation ;)
> > > > > > >>
> > > > > > >> Well, the unexpected answer is actually No, see
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/relocation/SimpleRelocator.java
> > > > > > >>
> > > > > > >> (but it might be better to do so...)
> > > > > > >>
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >> Robert
> > > > > > >> >>
> > > > > > >> >> On Sat, 12 Oct 2019 11:35:05 +0200, Tibor Digana
> > > > > > >> >> 
> > > > > > >> >>
> > > > > > >> >> wrote:
> > > > > > >> >>
> > > > > > >> >> > We still use plexus-java:1.0.3 which depends on ASM 7.0.
> > > > > > >> >> > The support for JDk 13 and 14 is in the version 7.2.
> > > > > > >> >> > We have similar upgrade in
> > > > > > >> >> > https://github.com/apache/maven-shade-plugin/pull/29
> > > > > > >> >> >
> > > > > > >> >> > On Thu, Oct 10, 2019 at 2:53 AM Olivier Lamy <
> > > ol...@apache.org
> > > > >
> > > > > > >> wrote:
> > > > > > >> >> >
> > > > > > >> >> >> Hi,
> > > > > > >> >> >> It's now almost 10 months since last and around 30
> issues
> > > > fixed.
> > > > > > >> >> >> Maybe time for a new release?
> > > > > > >> >> >> Moving issues still open to 3.0.0-M5?
> > > > > > >> >> >>
> > > > > > >> >> >> cheers
> > > > > > >> >> >> --
> > > > > > >> >> >> Olivier Lamy
> > > > > > >> >>
> > > > > > >> >>
> > > > >
> -
> > > > > > >> >> 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
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
>

Re: Surefire 3.0.0-M4 release?

[Tibor Digana]

@Olivier as we clarified this Slack. The release will be fast. No delay!

On Mon, Nov 11, 2019 at 12:07 PM Olivier Lamy  wrote:

> Why? delay again
> I thought 1 month ago we agreed ago to move non finished stuff to 3.0.0-M5
> and release 3.0.0-M5 later.
>
>
> On Mon, 11 Nov 2019 at 20:59, Tibor Digana  wrote:
>
> > Pls don't do it.
> > I will cut it and move some issues to M5 but I need Matt to finish his
> > work. I am in contact with Mat.
> > I talked about it with the contributor Jonathan Bell about reasoning.
> > T
> >
> > On Mon, Nov 11, 2019 at 11:41 AM Olivier Lamy  wrote:
> >
> > > Hi
> > > Starting again this thread as we agreed but I didn't do it.
> > > So I'd like to cut release 3.0.0-M4 by the end of this week.
> > >
> > >
> > >
> > > On Mon, 14 Oct 2019 at 11:40, Tibor Digana 
> > wrote:
> > >
> > > > The SUREFIRE-1689 progress has been finished until the CI build
> > succeeds.
> > > > T
> > > >
> > > > On Sun, Oct 13, 2019 at 10:27 AM Robert Scholte <
> rfscho...@apache.org>
> > > > wrote:
> > > >
> > > > > Ah, there it is :)
> > > > >
> > > > > On Sun, 13 Oct 2019 08:21:53 +0200, Romain Manni-Bucau
> > > > >  wrote:
> > > > >
> > > > > > Didnt expect my comment about shade to take so much space in this
> > > > thread
> > > > > > but yes we rely on asm for relocation:
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java#L453
> > > > > >
> > > > > > Le dim. 13 oct. 2019 à 00:20, Robert Scholte <
> rfscho...@apache.org
> > >
> > > a
> > > > > > écrit :
> > > > > >
> > > > > >> On Sat, 12 Oct 2019 13:44:48 +0200, Romain Manni-Bucau
> > > > > >>  wrote:
> > > > > >>
> > > > > >> > Le sam. 12 oct. 2019 à 13:33, Robert Scholte <
> > > rfscho...@apache.org>
> > > > a
> > > > > >> > écrit :
> > > > > >> >
> > > > > >> >> As far as I know, surefire won't touch the Plexus Java code
> > that
> > > > > >> >> requires
> > > > > >> >> ASM.
> > > > > >> >> It is ONLY required when the runtime is Java 8 or lower AND
> you
> > > > > need
> > > > > >> to
> > > > > >> >> read the module descriptors.
> > > > > >> >>
> > > > > >> >> Maven Shade is a different case: it must parse the Java
> > bytecode
> > > > (and
> > > > > >> >> only
> > > > > >> >> when using minifyJar), hence it needs the latest ASM.
> > > > > >> >>
> > > > > >> >
> > > > > >> > + Relocation ;)
> > > > > >>
> > > > > >> Well, the unexpected answer is actually No, see
> > > > > >>
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/relocation/SimpleRelocator.java
> > > > > >>
> > > > > >> (but it might be better to do so...)
> > > > > >>
> > > > > >> >
> > > > > >> >
> > > > > >> >> Robert
> > > > > >> >>
> > > > > >> >> On Sat, 12 Oct 2019 11:35:05 +0200, Tibor Digana
> > > > > >> >> 
> > > > > >> >>
> > > > > >> >> wrote:
> > > > > >> >>
> > > > > >> >> > We still use plexus-java:1.0.3 which depends on ASM 7.0.
> > > > > >> >> > The support for JDk 13 and 14 is in the version 7.2.
> > > > > >> >> > We have similar upgrade in
> > > > > >> >> > https://github.com/apache/maven-shade-plugin/pull/29
> > > > > >> >> >
> > > > > >> >> > On Thu, Oct 10, 2019 at 2:53 AM Olivier Lamy <
> > ol...@apache.org
> > > >
> > > > > >> wrote:
> > > > > >> >> >
> > > > > >> >> >> Hi,
> > > > > >> >> >> It's now almost 10 months since last and around 30 issues
> > > fixed.
> > > > > >> >> >> Maybe time for a new release?
> > > > > >> >> >> Moving issues still open to 3.0.0-M5?
> > > > > >> >> >>
> > > > > >> >> >> cheers
> > > > > >> >> >> --
> > > > > >> >> >> Olivier Lamy
> > > > > >> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > > > >> >>
> > > > > >> >>
> > > > -
> > > > > >> >> 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
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Olivier Lamy
> > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: Surefire 3.0.0-M4 release?

[Olivier Lamy]

Why? delay again
I thought 1 month ago we agreed ago to move non finished stuff to 3.0.0-M5
and release 3.0.0-M5 later.


On Mon, 11 Nov 2019 at 20:59, Tibor Digana  wrote:

> Pls don't do it.
> I will cut it and move some issues to M5 but I need Matt to finish his
> work. I am in contact with Mat.
> I talked about it with the contributor Jonathan Bell about reasoning.
> T
>
> On Mon, Nov 11, 2019 at 11:41 AM Olivier Lamy  wrote:
>
> > Hi
> > Starting again this thread as we agreed but I didn't do it.
> > So I'd like to cut release 3.0.0-M4 by the end of this week.
> >
> >
> >
> > On Mon, 14 Oct 2019 at 11:40, Tibor Digana 
> wrote:
> >
> > > The SUREFIRE-1689 progress has been finished until the CI build
> succeeds.
> > > T
> > >
> > > On Sun, Oct 13, 2019 at 10:27 AM Robert Scholte 
> > > wrote:
> > >
> > > > Ah, there it is :)
> > > >
> > > > On Sun, 13 Oct 2019 08:21:53 +0200, Romain Manni-Bucau
> > > >  wrote:
> > > >
> > > > > Didnt expect my comment about shade to take so much space in this
> > > thread
> > > > > but yes we rely on asm for relocation:
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java#L453
> > > > >
> > > > > Le dim. 13 oct. 2019 à 00:20, Robert Scholte  >
> > a
> > > > > écrit :
> > > > >
> > > > >> On Sat, 12 Oct 2019 13:44:48 +0200, Romain Manni-Bucau
> > > > >>  wrote:
> > > > >>
> > > > >> > Le sam. 12 oct. 2019 à 13:33, Robert Scholte <
> > rfscho...@apache.org>
> > > a
> > > > >> > écrit :
> > > > >> >
> > > > >> >> As far as I know, surefire won't touch the Plexus Java code
> that
> > > > >> >> requires
> > > > >> >> ASM.
> > > > >> >> It is ONLY required when the runtime is Java 8 or lower AND you
> > > > need
> > > > >> to
> > > > >> >> read the module descriptors.
> > > > >> >>
> > > > >> >> Maven Shade is a different case: it must parse the Java
> bytecode
> > > (and
> > > > >> >> only
> > > > >> >> when using minifyJar), hence it needs the latest ASM.
> > > > >> >>
> > > > >> >
> > > > >> > + Relocation ;)
> > > > >>
> > > > >> Well, the unexpected answer is actually No, see
> > > > >>
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/relocation/SimpleRelocator.java
> > > > >>
> > > > >> (but it might be better to do so...)
> > > > >>
> > > > >> >
> > > > >> >
> > > > >> >> Robert
> > > > >> >>
> > > > >> >> On Sat, 12 Oct 2019 11:35:05 +0200, Tibor Digana
> > > > >> >> 
> > > > >> >>
> > > > >> >> wrote:
> > > > >> >>
> > > > >> >> > We still use plexus-java:1.0.3 which depends on ASM 7.0.
> > > > >> >> > The support for JDk 13 and 14 is in the version 7.2.
> > > > >> >> > We have similar upgrade in
> > > > >> >> > https://github.com/apache/maven-shade-plugin/pull/29
> > > > >> >> >
> > > > >> >> > On Thu, Oct 10, 2019 at 2:53 AM Olivier Lamy <
> ol...@apache.org
> > >
> > > > >> wrote:
> > > > >> >> >
> > > > >> >> >> Hi,
> > > > >> >> >> It's now almost 10 months since last and around 30 issues
> > fixed.
> > > > >> >> >> Maybe time for a new release?
> > > > >> >> >> Moving issues still open to 3.0.0-M5?
> > > > >> >> >>
> > > > >> >> >> cheers
> > > > >> >> >> --
> > > > >> >> >> Olivier Lamy
> > > > >> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > > >> >>
> > > > >> >>
> > > -
> > > > >> >> 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
> > > >
> > > >
> > >
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>


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

Re: Surefire 3.0.0-M4 release?

[Tibor Digana]

Pls don't do it.
I will cut it and move some issues to M5 but I need Matt to finish his
work. I am in contact with Mat.
I talked about it with the contributor Jonathan Bell about reasoning.
T

On Mon, Nov 11, 2019 at 11:41 AM Olivier Lamy  wrote:

> Hi
> Starting again this thread as we agreed but I didn't do it.
> So I'd like to cut release 3.0.0-M4 by the end of this week.
>
>
>
> On Mon, 14 Oct 2019 at 11:40, Tibor Digana  wrote:
>
> > The SUREFIRE-1689 progress has been finished until the CI build succeeds.
> > T
> >
> > On Sun, Oct 13, 2019 at 10:27 AM Robert Scholte 
> > wrote:
> >
> > > Ah, there it is :)
> > >
> > > On Sun, 13 Oct 2019 08:21:53 +0200, Romain Manni-Bucau
> > >  wrote:
> > >
> > > > Didnt expect my comment about shade to take so much space in this
> > thread
> > > > but yes we rely on asm for relocation:
> > > >
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java#L453
> > > >
> > > > Le dim. 13 oct. 2019 à 00:20, Robert Scholte 
> a
> > > > écrit :
> > > >
> > > >> On Sat, 12 Oct 2019 13:44:48 +0200, Romain Manni-Bucau
> > > >>  wrote:
> > > >>
> > > >> > Le sam. 12 oct. 2019 à 13:33, Robert Scholte <
> rfscho...@apache.org>
> > a
> > > >> > écrit :
> > > >> >
> > > >> >> As far as I know, surefire won't touch the Plexus Java code that
> > > >> >> requires
> > > >> >> ASM.
> > > >> >> It is ONLY required when the runtime is Java 8 or lower AND you
> > > need
> > > >> to
> > > >> >> read the module descriptors.
> > > >> >>
> > > >> >> Maven Shade is a different case: it must parse the Java bytecode
> > (and
> > > >> >> only
> > > >> >> when using minifyJar), hence it needs the latest ASM.
> > > >> >>
> > > >> >
> > > >> > + Relocation ;)
> > > >>
> > > >> Well, the unexpected answer is actually No, see
> > > >>
> > > >>
> > > >>
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/relocation/SimpleRelocator.java
> > > >>
> > > >> (but it might be better to do so...)
> > > >>
> > > >> >
> > > >> >
> > > >> >> Robert
> > > >> >>
> > > >> >> On Sat, 12 Oct 2019 11:35:05 +0200, Tibor Digana
> > > >> >> 
> > > >> >>
> > > >> >> wrote:
> > > >> >>
> > > >> >> > We still use plexus-java:1.0.3 which depends on ASM 7.0.
> > > >> >> > The support for JDk 13 and 14 is in the version 7.2.
> > > >> >> > We have similar upgrade in
> > > >> >> > https://github.com/apache/maven-shade-plugin/pull/29
> > > >> >> >
> > > >> >> > On Thu, Oct 10, 2019 at 2:53 AM Olivier Lamy  >
> > > >> wrote:
> > > >> >> >
> > > >> >> >> Hi,
> > > >> >> >> It's now almost 10 months since last and around 30 issues
> fixed.
> > > >> >> >> Maybe time for a new release?
> > > >> >> >> Moving issues still open to 3.0.0-M5?
> > > >> >> >>
> > > >> >> >> cheers
> > > >> >> >> --
> > > >> >> >> Olivier Lamy
> > > >> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> > > >> >>
> > > >> >>
> > -
> > > >> >> 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
> > >
> > >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: Surefire 3.0.0-M4 release?

[Olivier Lamy]

Hi
Starting again this thread as we agreed but I didn't do it.
So I'd like to cut release 3.0.0-M4 by the end of this week.



On Mon, 14 Oct 2019 at 11:40, Tibor Digana  wrote:

> The SUREFIRE-1689 progress has been finished until the CI build succeeds.
> T
>
> On Sun, Oct 13, 2019 at 10:27 AM Robert Scholte 
> wrote:
>
> > Ah, there it is :)
> >
> > On Sun, 13 Oct 2019 08:21:53 +0200, Romain Manni-Bucau
> >  wrote:
> >
> > > Didnt expect my comment about shade to take so much space in this
> thread
> > > but yes we rely on asm for relocation:
> > >
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/DefaultShader.java#L453
> > >
> > > Le dim. 13 oct. 2019 à 00:20, Robert Scholte  a
> > > écrit :
> > >
> > >> On Sat, 12 Oct 2019 13:44:48 +0200, Romain Manni-Bucau
> > >>  wrote:
> > >>
> > >> > Le sam. 12 oct. 2019 à 13:33, Robert Scholte 
> a
> > >> > écrit :
> > >> >
> > >> >> As far as I know, surefire won't touch the Plexus Java code that
> > >> >> requires
> > >> >> ASM.
> > >> >> It is ONLY required when the runtime is Java 8 or lower AND you
> > need
> > >> to
> > >> >> read the module descriptors.
> > >> >>
> > >> >> Maven Shade is a different case: it must parse the Java bytecode
> (and
> > >> >> only
> > >> >> when using minifyJar), hence it needs the latest ASM.
> > >> >>
> > >> >
> > >> > + Relocation ;)
> > >>
> > >> Well, the unexpected answer is actually No, see
> > >>
> > >>
> > >>
> >
> https://github.com/apache/maven-shade-plugin/blob/master/src/main/java/org/apache/maven/plugins/shade/relocation/SimpleRelocator.java
> > >>
> > >> (but it might be better to do so...)
> > >>
> > >> >
> > >> >
> > >> >> Robert
> > >> >>
> > >> >> On Sat, 12 Oct 2019 11:35:05 +0200, Tibor Digana
> > >> >> 
> > >> >>
> > >> >> wrote:
> > >> >>
> > >> >> > We still use plexus-java:1.0.3 which depends on ASM 7.0.
> > >> >> > The support for JDk 13 and 14 is in the version 7.2.
> > >> >> > We have similar upgrade in
> > >> >> > https://github.com/apache/maven-shade-plugin/pull/29
> > >> >> >
> > >> >> > On Thu, Oct 10, 2019 at 2:53 AM Olivier Lamy 
> > >> wrote:
> > >> >> >
> > >> >> >> Hi,
> > >> >> >> It's now almost 10 months since last and around 30 issues fixed.
> > >> >> >> Maybe time for a new release?
> > >> >> >> Moving issues still open to 3.0.0-M5?
> > >> >> >>
> > >> >> >> cheers
> > >> >> >> --
> > >> >> >> Olivier Lamy
> > >> >> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >> >>
> > >> >>
> -
> > >> >> 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
> >
> >
>


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