[discuss] Maven Workflows

[Markus Karg]

Dear Maven Developers,

 

today I'd like to propose a new core feature of Maven: Maven Workflows.

 

Since several time there had been workflow-style plugins, i. e. plugins that
simply execute mojos of other plugins in a particular sequence. Well-known
examples are the Maven Release Plugin (which implements a flow of SCM and
Version operations), the Git-Flow Maven Plugin (which implements a flow of
SCM operations) and in some why the Groovy Maven Plugin (which, besides
custom code, is able to invoke Maven plugin to implement a flow). Some
people start coding custom plugins for more custom flows, other people use
bash scripting to implement their flows using a sequence of mvn invocations,
both with the benefit that neither Maven itself nor Maven-enabled tools
(like IDEs or CI/CD) neither "see" nor "understand" these workflows -- hence
cannot support custom workflows, or only with a lot of more custom code
(like custom IDE plugins). It is time to discuss the ideo of natively
supporting Workflows!

 

What I like to propose is:

 

* Maven core has new interface "Workflow", is able to customize it using
 POM elements.

* A "Workflow" is defined as a sequence of plugin executions. Workflows can
includes  or  to query properties.

* A new "Maven Workflow Plugin", is able to execute workflows.

* IDEs can "see" and execute workflows.

 

This is just a core idea and certainly needs more in-depth thoughts. But so
far, what do you think?

 

-Markus

 

AW: Moving away from Modello

[Markus Karg]

In the very long term I would be +1 for JAXB, as clearly much more Java 
programmers on earth are used to JAXB than with Modello due to it being a 
former part of the JRE. It now is open source at the Eclipse Foundation, so we 
all can contribute to it, which could make it a success story.
But I am with Robert here: We need to start with it from the core. So if there 
is a group of contributors that will change the Maven eco system from the core 
to all plugins, then I would be +1 for that.
But we should stay with modello until there are PRs for core and ALL plugins, 
to prevent a mix.
-Markus


-Ursprüngliche Nachricht-
Von: Gary Gregory [mailto:garydgreg...@gmail.com] 
Gesendet: Mittwoch, 2. Juni 2021 14:38
An: Maven Developers List
Betreff: Re: Moving away from Modello

On Wed, Jun 2, 2021 at 8:30 AM Jochen Wiedmann
 wrote:
>
> On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold  
> wrote:
>
> > What do folks think about slowly moving away from Modello where
> > feasible to simplify the build? Does anyone find Modello a net
> > positive, especially in longterm maintenance, not just in initial code
> > generation?
>
> To me, it sounds feasible to replace Modello with a Sax parser
> (reading), and a Sax
> event generator (writing), that take as input a bean class (either
> written manually,
> or generated by Modello, and do the serialization/deserialization.
>
> Would, most likely, not be a drop-in-replacement, but definitely a medium-term
> solution.

What about JAXB?

Gary

>
> Jochen
>
>
> --
>
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
>
> -- (Terry Pratchett, Thief of Time)
>
> -
> 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

AW: Why no mvn daemon?

[Markus KARG]

Looking at the impressively reduced bootstrap times of modern JDKs with 
features like Automatic AppCDS, I wonder if in the year 2021 this still makes 
sense? In rather near future there will be native precompilation available in 
most JDKs, effectively reducing bootstrap time to few ms. So is it worth 
investing this time and complexity? In the past, yes, up to JDK 8, it 
definitively was. But NOW?

-Markus


-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] 
Gesendet: Montag, 29. März 2021 12:21
An: Maven Developers List
Cc: Jason Dillon
Betreff: Re: Why no mvn daemon?

Up 4 years later ;)

Now mvnd exists and proves it is very interesting to have such a feature,
should it be something which can fit maven standard delivery?
If overall yes we can start by asking mvnd if it can be contributed with
main codebase and if not we can either decide to do our own (hope not ;))
or that maven does not care about caching/optimizations in its "core" and
that it is only done in extensions (I know 3 "main" ones as of today).

Wdyt?

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



Le mer. 9 mars 2016 à 23:58, Jeff Jensen 
a écrit :

> Thanks!  It's running just fine.  :-)  It's very cool.  Really nice
> directory traversal and completion, colors, and commands/features I don't
> know yet!
>
> Very interesting timing diffs (for each casual test, I ran the command for
> each multiple times to seed infra caches):
>  * on some asciidoc gen with "mvn generate-resources", it was about the
> same duration as CLI but after running each about 10 times, mvnshell saved
> about 20% consistently (possibly due to JIT? besides directory traversal,
> this was the first things I did).  This was my key use case for wanting a
> "mvn server" - handling situations like this with repeated runs (asciidoc,
> site, etc.).
>
>  * on a simple "mvn clean", mvnshell was about 2x faster than CLI.
>
>  * on a small module build, "mvn install" was about 20% faster over CLI
> (after a mvn clean for each).
>
> I look forward to trying more things.
>
> Nice to have, thank you Jason!
>
>
> On Wed, Mar 9, 2016 at 4:17 PM, Jason Dillon 
> wrote:
>
> > Jason, if you have a built version, do you mind adding it as a download
> to
> >
> > the release files?
> >
> > I can make a binary of this, though I do plan on fixing it up so that
> > folks can build it in the near future.
> >
> > Build up here for the moment:
> >
> >
> https://www.dropbox.com/sh/yvt1g43r2pr2scj/AADqM__VhJaFf_x57OiUEZXva?dl=0
> >
> > gshell:master should be buildable with just central now, dangling ref to
> > older version of jline for classifer=tests which was unused and polluting
> > the build dependencies.
> >
> > —jason
> >
> >
> >
>


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

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

[Markus KARG]

Nonsense. It is common sense that most criminal acts are spawned from within 
the local network, due to social engineering.
-Markus


-Ursprüngliche Nachricht-
Von: Som Lima [mailto:somplastic...@gmail.com] 
Gesendet: Sonntag, 28. März 2021 15:06
An: Maven Developers List
Betreff: Re: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

> BTW there should be an option to still use unsecure http as many people
run http in their LANs.

I could be wrong but I think the intranet is a tightly coupled  comm system
therefore it is secure by design.



On Sun, 28 Mar 2021, 13:31 Markus KARG,  wrote:

> We should not do any tricks or unexpected behavior but just stick with
> SemVer.
> If there is a need for a security fix, it has to be 3.6.4 and BTW there
> should be an option to still use unsecure http as many people run http in
> their LANs.
> If it contains backwards-compatible features, it has to be 3.7.0.
> If it breaks backwards-compatibility, it has to be 4.0.0.
> In no case it can be 3.8.0.
> If mvnw was proposed for 3.7 but is not here now, then we either have to
> wait with 3.7.0, or we have to tell people that we move mvnw to 3.8 or 4.0.
> I do not see a need for any discussion at all, as SemVer is pretty clear
> about the sole correct answer.
> -Markus
>
> -Ursprüngliche Nachricht-
> Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Gesendet: Sonntag, 28. März 2021 11:47
> An: Maven Developers List
> Betreff: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other
>
> Hi all,
>
> Before we reroll the failed 3.8.0 I'd like we discuss openly the next
> versioning since it seems we didn't reach a consensus yet and trying to not
> create too much friction for users and in the community.
>
> As a reminder the only feature the release will get is to prevent HTTP repo
> (in favor of HTTPS ones). In that regard it is a breaking change if users
> rely on HTTP repo but a security fix (I don't come back on the HTTP ->
> HTTPS move IT ecosystem got recently here).
>
> So it seems there are multiple versioning options:
>
> 1. 3.6.4: seems natural since it is a security fix, enables companies to
> get this fix respecting a project versioning policy without having to
> upgrade and avoids us to have to maintain 3.6 + 3.7/3.8 and soon 4.x.
> Indeed it requires a very well documented paragraph about this change and
> how to workaround it (local proxy/mirror is a trivial one for example) but
> it will be the case whatever version we pick anyway IMHO.
> 2. 3.7.0: since it is a breaking change it can seem natural too (but has
> the pitfall to likely require a backport in 3.6 anyway, due to the
> versioning policies which can prevent some users to upgrade to a 3.7)
> 3. 3.8.0: was the vote, seems the rational was that originally we
> targetting mvnw in 3.7 and since we didn't make it 3.8 was used. Have to
> admit I'm not sure of this reasoning more than that (cause for me if we
> don't have a planned feature we can either try to push/wait for it or
> postpone it but not skip a version due to that) so if anyone wants to
> complete the reasoning here it would be great.
>
> Indeed my preference is for 3.6.4 which has the most advantages for
> everyone and no additional drawbacks compared to 3.7 or 3.8 options until
> we try to push to get mvnw in which would mean 3.7 becomes more natural
> (and likely imply a 3.6.x maintenance version).
>
> Goal of this thread is to feel the overall trend and see if we can refine
> the proposals (for example: can we drop 3.8 one and only keep 3.7 and 3.6
> or - best - can we refine it to a single version after some exchanges).
> If we keep a few proposals after some days, what about a vote where the
> majority wins - we would just need to define how we count,
> bindings/committers/all (my preference being last one indeed)?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> -
> 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

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

[Markus KARG]

>> - Why not 3.7.0?
>> Apache Maven 3.7.0 has been advertised in the past that it would be the
>> first release where you could optionally activate the build/consumer
>> feature: the version containing this feature has been renamed to 4.0.0.
>> Reusing 3.7.0 might lead to confusion, hence we picked the next available
>> minor version.
> But we will deliver 3.8.xxx with no 3.7.xx which should have the
> “advertised” feature.
> Sorry following this reasoning it feels even worst and potentially more
> confusing for users.

I second that. If a feature was proposed for 3.7 and a user downloads 3.8 he 
simply thinks he missed 3.7 and will definitiely expect the feature to exist.

-Markus




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

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

[Markus KARG]

We should not do any tricks or unexpected behavior but just stick with SemVer.
If there is a need for a security fix, it has to be 3.6.4 and BTW there should 
be an option to still use unsecure http as many people run http in their LANs.
If it contains backwards-compatible features, it has to be 3.7.0.
If it breaks backwards-compatibility, it has to be 4.0.0.
In no case it can be 3.8.0.
If mvnw was proposed for 3.7 but is not here now, then we either have to wait 
with 3.7.0, or we have to tell people that we move mvnw to 3.8 or 4.0.
I do not see a need for any discussion at all, as SemVer is pretty clear about 
the sole correct answer.
-Markus

-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] 
Gesendet: Sonntag, 28. März 2021 11:47
An: Maven Developers List
Betreff: [DISCUSS] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

Hi all,

Before we reroll the failed 3.8.0 I'd like we discuss openly the next
versioning since it seems we didn't reach a consensus yet and trying to not
create too much friction for users and in the community.

As a reminder the only feature the release will get is to prevent HTTP repo
(in favor of HTTPS ones). In that regard it is a breaking change if users
rely on HTTP repo but a security fix (I don't come back on the HTTP ->
HTTPS move IT ecosystem got recently here).

So it seems there are multiple versioning options:

1. 3.6.4: seems natural since it is a security fix, enables companies to
get this fix respecting a project versioning policy without having to
upgrade and avoids us to have to maintain 3.6 + 3.7/3.8 and soon 4.x.
Indeed it requires a very well documented paragraph about this change and
how to workaround it (local proxy/mirror is a trivial one for example) but
it will be the case whatever version we pick anyway IMHO.
2. 3.7.0: since it is a breaking change it can seem natural too (but has
the pitfall to likely require a backport in 3.6 anyway, due to the
versioning policies which can prevent some users to upgrade to a 3.7)
3. 3.8.0: was the vote, seems the rational was that originally we
targetting mvnw in 3.7 and since we didn't make it 3.8 was used. Have to
admit I'm not sure of this reasoning more than that (cause for me if we
don't have a planned feature we can either try to push/wait for it or
postpone it but not skip a version due to that) so if anyone wants to
complete the reasoning here it would be great.

Indeed my preference is for 3.6.4 which has the most advantages for
everyone and no additional drawbacks compared to 3.7 or 3.8 options until
we try to push to get mvnw in which would mean 3.7 becomes more natural
(and likely imply a 3.6.x maintenance version).

Goal of this thread is to feel the overall trend and see if we can refine
the proposals (for example: can we drop 3.8 one and only keep 3.7 and 3.6
or - best - can we refine it to a single version after some exchanges).
If we keep a few proposals after some days, what about a vote where the
majority wins - we would just need to define how we count,
bindings/committers/all (my preference being last one indeed)?

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



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

AW: Running maven from inside JVM.

[Markus KARG]

Yes, there is an API to embed Maven.
-Markus


-Ursprüngliche Nachricht-
Von: Som Lima [mailto:somplastic...@gmail.com] 
Gesendet: Sonntag, 28. März 2021 06:26
An: dev@maven.apache.org
Betreff: Running maven from inside JVM.

Hi,

Is it possible to run maven from inside JVM ?

i.e.

Java -jar maven.jar --pom:/home/project/pom.xml  --goals:clean install
package


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

AW: Future of maven scripting plugin, java?

[Markus KARG]

LGTM. Please tell me when done! ;-D
-Markus


-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] 
Gesendet: Donnerstag, 25. Februar 2021 16:16
An: Maven Developers List
Betreff: Re: Future of maven scripting plugin, java?

Le jeu. 25 févr. 2021 à 15:28, Markus KARG  a
écrit :

> Romain,
>
> just to understand your target: In the end what you want is that the Java
> scripting plugin will execute Java source code, just like jshell does? That
> sounds interesting to me.
>

This is more a side effect, the target is to be able to be able to replace
src/main/java//build/*.java + exec-maven-plugin setups which has the
drawback to require dependencies in the actual module (even in scope
provided).
The scripting plugin has the opportunity to normalize that through the
maven-java-scripting-engine which will take this through engine
configuration.
To illustrate the usage: it generates documentation, typed clients (http),
jsonschema, openapi.json, docker images with CDS and much more and in a
customized fashion.
Big gain is to not have to leak all dependencies in the build  and keep
build part of the build isolated (a profile can enable to code in the IDE
but when running mvn xxx it is gone/deactivated).

Side notes:
1. creating a build module is not an option since it is really about having
the build code in the related module and not a "put it all" module which is
very hard to maintain.
2. creating a mojo for these needs is inefficient in terms of maintenance
and customization level (I come from there) and ultra verbose in the pom
compared to this scripting option


Hope it clarifies my goal


>
> -Markus
>
>
> -Ursprüngliche Nachricht-
> Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Gesendet: Donnerstag, 25. Februar 2021 09:59
> An: Maven Developers List
> Betreff: Future of maven scripting plugin, java?
>
> Hi all,
>
> Wonder if maven scripting plugin has some future plans or not.
> Very concretely I'm interested in being able to use java as scripting files
> (something along src/build/scripting in terms of structure in final
> project).
> Since we are in maven we have javac so it is not hard to implement a jsr223
> (with tool provider or not is a detail) but more complicated thing is the
> classpath, it needs the plugin to be able to create a classloader adjusted
> for that kind of execution (potentially compiling the whole scripting
> folder). In terms of impacts it means enabling to configure the script
> engine, ie pass args from the mojo to the getScriptEngine method (typically
> kind of the same as exec maven plugin, ie scope/classpath).
>
> So changes would be:
>
> 1. implement a java script engine
> 2. make the script engine instantiation more configurable
>
> Do you think it is worth it or exec maven plugin is still preferred?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> -
> 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

AW: Future of maven scripting plugin, java?

[Markus KARG]

Romain,

just to understand your target: In the end what you want is that the Java 
scripting plugin will execute Java source code, just like jshell does? That 
sounds interesting to me.

-Markus


-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] 
Gesendet: Donnerstag, 25. Februar 2021 09:59
An: Maven Developers List
Betreff: Future of maven scripting plugin, java?

Hi all,

Wonder if maven scripting plugin has some future plans or not.
Very concretely I'm interested in being able to use java as scripting files
(something along src/build/scripting in terms of structure in final
project).
Since we are in maven we have javac so it is not hard to implement a jsr223
(with tool provider or not is a detail) but more complicated thing is the
classpath, it needs the plugin to be able to create a classloader adjusted
for that kind of execution (potentially compiling the whole scripting
folder). In terms of impacts it means enabling to configure the script
engine, ie pass args from the mojo to the getScriptEngine method (typically
kind of the same as exec maven plugin, ie scope/classpath).

So changes would be:

1. implement a java script engine
2. make the script engine instantiation more configurable

Do you think it is worth it or exec maven plugin is still preferred?

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



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

AW: Maven 4: -pl !... is not recursive

[Markus KARG]

Yes it might be the better solution to keep it backwards compatible and do 
recursive -plr X / -plr !X as a new option.

-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] 
Gesendet: Samstag, 20. Februar 2021 09:20
An: Maven Developers List
Betreff: Re: Maven 4: -pl !... is not recursive

Agree it should be alignde, just wonder how you handle '-N' equivalent if
-pl is recursive (so until there is a solution I'm tempting to think not
being recursive can be saner + at least it is backward compatible to v3
which is also important). If we want a recursive -pl we should probably add
a -plr or so IMHO.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le sam. 20 févr. 2021 à 09:14, Markus KARG  a
écrit :

> I second that. It is counterintuitive. It would be beneficial if -pl !X
> would also exclude ist submodules.
> -Markus
>
>
> -Ursprüngliche Nachricht-
> Von: Falko Modler [mailto:f.mod...@gmx.net]
> Gesendet: Samstag, 20. Februar 2021 01:39
> An: dev@maven.apache.org
> Betreff: Maven 4: -pl !... is not recursive
>
> Hi everyone,
>
> I started playing around with 4.0.0-alpha-1-20210214.163053-40 and I
> realized that -pl X will now also build submodules of X but -pl !X will
> only exclude X, not its submodules.
>
> Isn't this a bit inconsistent?
>
> Cheers,
>
> Falko
>
>
> -
> 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

AW: Maven 4: -pl !... is not recursive

[Markus KARG]

I second that. It is counterintuitive. It would be beneficial if -pl !X would 
also exclude ist submodules.
-Markus


-Ursprüngliche Nachricht-
Von: Falko Modler [mailto:f.mod...@gmx.net] 
Gesendet: Samstag, 20. Februar 2021 01:39
An: dev@maven.apache.org
Betreff: Maven 4: -pl !... is not recursive

Hi everyone,

I started playing around with 4.0.0-alpha-1-20210214.163053-40 and I
realized that -pl X will now also build submodules of X but -pl !X will
only exclude X, not its submodules.

Isn't this a bit inconsistent?

Cheers,

Falko


-
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

AW: uploading to central via ossrh is problematic

[Markus KARG]

Understood, and so I try to make all Apaches understand that we could have a 
subdomain apache.oss.sonatype.org with dedicated infrastructure, just as the 
Eclipse Foundation has with jakarta.oss.sonatype.org, to get rid of these 
troubles. :-)
-Markus


-Ursprüngliche Nachricht-
Von: Matthieu Brouillard [mailto:matth...@brouillard.fr] 
Gesendet: Freitag, 22. Januar 2021 20:14
An: Maven Developers List
Betreff: Re: uploading to central via ossrh is problematic

Markus,

> which is just one of several ways onto Maven Central
The only way for OSS developers not part of big infrastructures.

> As we all do open source and OSSRH is free, maybe we should simply accept
that free stuff might just have some outages currently.
I am not blaming Sonatype at all, on the contrary I am very grateful to
them for offering freely OSSRH.
I just wanted to make some awareness that the community, not having access
to dedicated routes to central other than OSSRH, is suffering that's all.

Matthieu

On Fri, Jan 22, 2021 at 6:46 PM Markus KARG  wrote:

> If you follow the official twitter channel then you will learn that the
> problem is simply the internal load of the free OSSRH service, which is
> just one of several ways onto Maven Central. At the Eclipse Foundation for
> example, we have our own Sonatype-powered instance with separate workload
> limit, so this is something that Apache could reach out for. At the far
> end, I am pretty sure Sonatype will even provide direct push to Maven
> Central using a commercial offering, so there is none of their infra (other
> than the master server) in your way at all.
>
> Having said that, I pushed via OSSRH twice today, it needed endless, but
> in the end it worked. As we all do open source and OSSRH is free, maybe we
> should simply accept that free stuff might just have some outages currently.
>
> -Markus
>
> -Ursprüngliche Nachricht-
> Von: Matthieu Brouillard [mailto:matth...@brouillard.fr]
> Gesendet: Freitag, 22. Januar 2021 18:36
> An: Maven Developers List
> Betreff: Re: uploading to central via ossrh is problematic
>
> Hi Romain,
>
> Thanks for the hint, I do not use the 'maven-deploy-plugin' to reach
> central but I use 'nexus-staging-maven-plugin' as described on
> central/sonatype documentation [1].
> The issues are not coming from uploads but from internal
> publication/staging inside the OSSRH infrastructure as far as I understand
> the problem.
> If there is another way to deploy to central using the standard
> maven-deploy-plugin I'd be glad to test it. Does it require a specific
> setup?
>
> Matthieu
>
> [1]: https://central.sonatype.org/pages/apache-maven.html
>
> On Fri, Jan 22, 2021 at 5:35 PM Romain Manni-Bucau 
> wrote:
>
> > Hi
> >
> > AFAIK maven enables to configure the "uploader" and even to switch it
> > (through wagon) so you can use any retry mecanism...but will not solve a
> > broken server issue, will just fail later from my experience.
> >
> > Le ven. 22 janv. 2021 à 15:47, Matthieu Brouillard <
> matth...@brouillard.fr
> > >
> > a écrit :
> >
> > > Hi Brian & list,
> > >
> > > Sorry but I have to insist on the fact that again yesterday and today
> > OSSRH
> > > is mostly unavailable.
> > > I again tried, like others, to deploy artifacts and it failed.
> > > After pinging on twitter, the OPs have provided again a feedback that
> > > deployments have pilled [1] explaining the timeouts.
> > > I am sure Sonatype is doing its best to resolve those issues but from
> the
> > > community pov there is a real issue with the way we, as maven eosystem
> > > contributors, are expected to deploy to central.
> > > Should a more decentralised workflow be established? I do not know but
> it
> > > has to be discussed & addressed.
> > >
> > > By the way I'll reopen an issue to track again the failures I have
> faced.
> > >
> > > Matthieu
> > >
> > > [1] : https://twitter.com/sonatype_ops/status/1352625400480817153
> > >
> > > On Thu, Jan 21, 2021 at 7:51 PM Brian Fox  wrote:
> > >
> > > > I think that each of those other instances are more unrelated to each
> > > > other, except in some cases massive scale. OSSRH itself is in the
> > > > process of being federated and large projects are given the
> > > > opportunity to move to their own new, or separate instance so their
> > > > load doesn't hurt the many thousands of other builds flowing through
> > > > the system at any given time. In terms of the community though, this
> > > > list is really the place to d

AW: uploading to central via ossrh is problematic

[Markus KARG]

If you follow the official twitter channel then you will learn that the problem 
is simply the internal load of the free OSSRH service, which is just one of 
several ways onto Maven Central. At the Eclipse Foundation for example, we have 
our own Sonatype-powered instance with separate workload limit, so this is 
something that Apache could reach out for. At the far end, I am pretty sure 
Sonatype will even provide direct push to Maven Central using a commercial 
offering, so there is none of their infra (other than the master server) in 
your way at all.

Having said that, I pushed via OSSRH twice today, it needed endless, but in the 
end it worked. As we all do open source and OSSRH is free, maybe we should 
simply accept that free stuff might just have some outages currently.

-Markus

-Ursprüngliche Nachricht-
Von: Matthieu Brouillard [mailto:matth...@brouillard.fr] 
Gesendet: Freitag, 22. Januar 2021 18:36
An: Maven Developers List
Betreff: Re: uploading to central via ossrh is problematic

Hi Romain,

Thanks for the hint, I do not use the 'maven-deploy-plugin' to reach
central but I use 'nexus-staging-maven-plugin' as described on
central/sonatype documentation [1].
The issues are not coming from uploads but from internal
publication/staging inside the OSSRH infrastructure as far as I understand
the problem.
If there is another way to deploy to central using the standard
maven-deploy-plugin I'd be glad to test it. Does it require a specific
setup?

Matthieu

[1]: https://central.sonatype.org/pages/apache-maven.html

On Fri, Jan 22, 2021 at 5:35 PM Romain Manni-Bucau 
wrote:

> Hi
>
> AFAIK maven enables to configure the "uploader" and even to switch it
> (through wagon) so you can use any retry mecanism...but will not solve a
> broken server issue, will just fail later from my experience.
>
> Le ven. 22 janv. 2021 à 15:47, Matthieu Brouillard  >
> a écrit :
>
> > Hi Brian & list,
> >
> > Sorry but I have to insist on the fact that again yesterday and today
> OSSRH
> > is mostly unavailable.
> > I again tried, like others, to deploy artifacts and it failed.
> > After pinging on twitter, the OPs have provided again a feedback that
> > deployments have pilled [1] explaining the timeouts.
> > I am sure Sonatype is doing its best to resolve those issues but from the
> > community pov there is a real issue with the way we, as maven eosystem
> > contributors, are expected to deploy to central.
> > Should a more decentralised workflow be established? I do not know but it
> > has to be discussed & addressed.
> >
> > By the way I'll reopen an issue to track again the failures I have faced.
> >
> > Matthieu
> >
> > [1] : https://twitter.com/sonatype_ops/status/1352625400480817153
> >
> > On Thu, Jan 21, 2021 at 7:51 PM Brian Fox  wrote:
> >
> > > I think that each of those other instances are more unrelated to each
> > > other, except in some cases massive scale. OSSRH itself is in the
> > > process of being federated and large projects are given the
> > > opportunity to move to their own new, or separate instance so their
> > > load doesn't hurt the many thousands of other builds flowing through
> > > the system at any given time. In terms of the community though, this
> > > list is really the place to discuss development of maven itself, so
> > > it's a bit orthogonal.
> > >
> > > On Thu, Jan 21, 2021 at 1:43 PM Matthieu Brouillard
> > >  wrote:
> > > >
> > > > Thanks Brian,
> > > >
> > > > I'll reopen an issue next time I face an upload problem.
> > > >
> > > >
> > > > *> it's not occurring across the entire system *
> > > > Ok but the case was not isolated, it occurred also in the past weeks
> to
> > > > microsoft, redhat, springboot guys and to several anonymous like me
> > that
> > > > try to maintain some oss stuff.
> > > > Moreover, I initially thought that OSSRH timeout was not 'just' a
> > > Sonatype
> > > > issue even if Sonatype is the operator of central & OSSRH (and I
> thank
> > > you
> > > > for that). I saw it as a community problem and thus I just wanted to
> > have
> > > > some feedback from this community.
> > > >
> > > > Matthieu
> > > >
> > > >
> > > >
> > > > On Thu, Jan 21, 2021 at 6:25 PM Brian Fox 
> wrote:
> > > >
> > > > > Hi Matthieu, I think continuing the conversation on your existing
> > > > > ossrh ticket is the right place to resolve this. While it seems
> like
> > > > > you're having recurring issues, it's not occurring across the
> entire
> > > > > system so we need to figure out what the unique issue is.
> > > > >
> > > > > --Brian
> > > > > Cofounder & CTO Sonatype
> > > > >
> > > > > On Thu, Jan 21, 2021 at 7:28 AM Matthieu Brouillard
> > > > >  wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Can a representative provide some information on the topic. Are
> > there
> > > > > > discussions with Sonatype?
> > > > > > Yesterday again OSSRH had troubles [1].
> > > > > > The graphs on https://status.maven.org/ can look ok but I
> suspect
> > > the
> > > > 

[Merge] PR #421: Artifact.getPath() and .setPath()

[Markus KARG]

I have 2 +1 for https://github.com/apache/maven/pull/421, so can somebody
please merge this PR (I am not a committer)?

Thanks!

-Markus

 

AW: Build windows-jdk15

[Markus KARG]

Well, whether or not switching off a build platform should more be a question 
of: Why have we switched it on actually?

-Markus


-Ursprüngliche Nachricht-
Von: Gary Gregory [mailto:garydgreg...@gmail.com] 
Gesendet: Mittwoch, 30. Dezember 2020 15:14
An: Maven Developers List
Betreff: Re: Build windows-jdk15

FWIW, it might be worth switching that Java 15/16-EA build to 17-EA since
17 will be LTS.

FYI, over at Apache Commons, we've found and reported bugs in Java 15 that
have been fixed in 16-EA but that won't be back ported to 15.

Gary


On Wed, Dec 30, 2020, 08:59 Elliotte Rusty Harold 
wrote:

> The Windows JDK 15 instance in jenkins seems irredeemably flaky. It
> fails more often than not for reasons that have nothing to do with the
> code being tested.
>
> As JDK 15 is not a long term support release, and has only minimal
> adoption, can we simply turn off the Windows JDK 15 build?
>
> Personally, I'd love to turn off all JDK 15 and 16 builds, but Windows
> JDK 15 is by far the worst.
>
> --
> 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
>
>


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

AW: Maven 4 / @Inject

[Markus KARG]

>> Regarding javax: No, this was not the free decision of the Jakarta EE WG,
>> this was the SOLE CHOICE we had due to Oracle, as they forbid ALL changes
>> to the javax namespace, so the were FORCED to rename the workspace. Believe
>> me, nobody in the Jakarta EE WG thought that this is a good idea, but we
>> had no other choice.

> Factually it is not true, this is also why there was some polls about
> keeping javax for existing API and use another namespace for new ones.
> This is perfectly legal and oracle had nothing to say about that, just
> plain law and it was clearly stated by EE leaders.
> Anyway, now jakarta got changed I'm not sure it brings much to the maven
> topic so let's put it aside - at least for this thread.

Agreed to putting it aside, as it is not Maven-related.

-Markus
 


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

AW: Maven 4 / @Inject

[Markus KARG]

Regarding javax: No, this was not the free decision of the Jakarta EE WG, this 
was the SOLE CHOICE we had due to Oracle, as they forbid ALL changes to the 
javax namespace, so the were FORCED to rename the workspace. Believe me, nobody 
in the Jakarta EE WG thought that this is a good idea, but we had no other 
choice.

Well, we simply have different opinions here. I clearly am +1 for adopting 
jakarta.inject, simply because it is the de-facto cross-vendor API the major 
stakeholders agreed upon at the Jakarta EE WG (which, BTW, is free for Apache 
to join) and it will develop further in future while javax does not, and I do 
not see why Apache needs to go with something special instead of simply 
adopting the natural successor IN ADDITION to javax.

I would love if Apache would help making Jakarta a success by adopting it and 
ACTIVELY influencing it instead of ignoring or fighting it. That will 
definitively put Apache in a bad situation one day. I do not like the EF, too, 
but in the end, Oracle dictates Java and the EF dictates post-JEE, so we should 
simply live with that truth and make the best out of it in a way that most 
people would just expect.

-Markus


-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] 
Gesendet: Montag, 28. Dezember 2020 17:14
An: Maven Developers List
Betreff: Re: Maven 4 / @Inject

Le lun. 28 déc. 2020 à 16:44, Markus KARG  a écrit :

> I don't like the idea of simply keeping javax "and period" as it looks
> like us not moving forward, since people will learn about the history and
> future of that namespace; it is just NOT ours but that of Oracle / JCP /
> EF. We can keep it, but we definitively should add jakarta as an
> alternative.
>

This is not really true, jakarta was allowed (is still ;)) to keep javax
for all the [;8] specs, including jsr330. Jakarta decided to not do that
and add new features in jakarta package but to break the world, their
choice.
In any case, using jakarta is not a sane option for maven (it shouldnt have
used javax as shown by the related threads on the list) so options are
either to revert to plexus API, introduce a new API or just stay like that
which is the less breaking option.
Since this namespace thing does not bring anything for users it sounds
quite fair for me.
What would be your proposed option? jakarta.inject?
To be explicit, here the options I see:

1. jakarta.inject ("forward"?): clearly -1 for the same reasons cdi-api
just got dropped from maven 4
2. plexus: it goes backward ;). Personally i'm not against it, was finding
it saner overall since it is for code in maven/lib but it is literally
about reverting work done.
3. create a new annotation set (kind of 2 but changing the API to look
"forward")
4. javax.inject: status quo, no regression, no user impact nor restriction.
When jakarta.inject will become adopted it will even make it split between
maven and user code/plugins which is good and what we should stick to IMHO.

This is why I think javax can surprisingly be the sanest for maven.


> -Markus
>
>
> -Ursprüngliche Nachricht-
> Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Gesendet: Montag, 28. Dezember 2020 16:16
> An: Maven Developers List
> Betreff: Re: Maven 4 / @Inject
>
> We can also freeze it, jsr330 never moved and will likely never move (since
> it is the most of the overlapping of underlying vendors) so guess moving to
> jakarta will not halp anything - can only hurt us actually by creating a
> new gap or another "cdi-api" issue - and moving to org.apache.maven will
> require work on maven and all users (which is a ton). I'm also not fan to
> move back to @Requirement/@Component (which is the natural way we would
> solve it I guess since that's what we had before) so maybe just not doing
> anything is a good option. Since we don't use standard jsr330 impl we can
> consider it as part of maven API, period. What do you think?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 28 déc. 2020 à 15:51, Markus KARG  a
> écrit :
>
> > With "dead" I mean: Nobody is allowed to add anything new in that
> namespace
> > -- neither classes nor interfaces nor even new parameters.
> >
> > I would like that Maven 4 accepts both (old and new namespace).
> >
> > -Markus
> >
> >
> >
> >
> > -Ursprüngliche Nachricht-
> > Von: Michael Osipov [mailto:micha...@apache.org]
> > 

AW: Maven 4 / @Inject

[Markus KARG]

I don't like the idea of simply keeping javax "and period" as it looks like us 
not moving forward, since people will learn about the history and future of 
that namespace; it is just NOT ours but that of Oracle / JCP / EF. We can keep 
it, but we definitively should add jakarta as an alternative.
-Markus


-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] 
Gesendet: Montag, 28. Dezember 2020 16:16
An: Maven Developers List
Betreff: Re: Maven 4 / @Inject

We can also freeze it, jsr330 never moved and will likely never move (since
it is the most of the overlapping of underlying vendors) so guess moving to
jakarta will not halp anything - can only hurt us actually by creating a
new gap or another "cdi-api" issue - and moving to org.apache.maven will
require work on maven and all users (which is a ton). I'm also not fan to
move back to @Requirement/@Component (which is the natural way we would
solve it I guess since that's what we had before) so maybe just not doing
anything is a good option. Since we don't use standard jsr330 impl we can
consider it as part of maven API, period. What do you think?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 28 déc. 2020 à 15:51, Markus KARG  a écrit :

> With "dead" I mean: Nobody is allowed to add anything new in that namespace
> -- neither classes nor interfaces nor even new parameters.
>
> I would like that Maven 4 accepts both (old and new namespace).
>
> -Markus
>
>
>
>
> -Ursprüngliche Nachricht-
> Von: Michael Osipov [mailto:micha...@apache.org]
> Gesendet: Montag, 28. Dezember 2020 14:59
> An: dev@maven.apache.org
> Betreff: Re: Maven 4 / @Inject
>
> Am 2020-12-28 um 14:56 schrieb Markus KARG:
> > We are used to "import javax.inject.*" in Maven, but that namespace if
> dead
> > since Jakarta EE 9. Since November the new namespace is released "import
> > jakarta.inject.*". I wonder if Maven 4 really still wants to stick with
> the
> > dead namespace instead, or whether it makes sense that we adopt the new
> > namespace now?
>
> That statement is very harsh. Both will co-exist for at least 10 years
> due to the massive amount of applications in companies. Maven tries to
> clean up stuff. I think this needs to be spared to Maven 5.
>
> -
> 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

AW: Maven 4 / @Inject

[Markus KARG]

With "dead" I mean: Nobody is allowed to add anything new in that namespace
-- neither classes nor interfaces nor even new parameters.

I would like that Maven 4 accepts both (old and new namespace).

-Markus




-Ursprüngliche Nachricht-
Von: Michael Osipov [mailto:micha...@apache.org] 
Gesendet: Montag, 28. Dezember 2020 14:59
An: dev@maven.apache.org
Betreff: Re: Maven 4 / @Inject

Am 2020-12-28 um 14:56 schrieb Markus KARG:
> We are used to "import javax.inject.*" in Maven, but that namespace if
dead
> since Jakarta EE 9. Since November the new namespace is released "import
> jakarta.inject.*". I wonder if Maven 4 really still wants to stick with
the
> dead namespace instead, or whether it makes sense that we adopt the new
> namespace now?

That statement is very harsh. Both will co-exist for at least 10 years 
due to the massive amount of applications in companies. Maven tries to 
clean up stuff. I think this needs to be spared to Maven 5.

-
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

Maven 4 / @Inject

[Markus KARG]

We are used to "import javax.inject.*" in Maven, but that namespace if dead
since Jakarta EE 9. Since November the new namespace is released "import
jakarta.inject.*". I wonder if Maven 4 really still wants to stick with the
dead namespace instead, or whether it makes sense that we adopt the new
namespace now?

-Markus 

AW: Maven Sign Plugin

[Markus KARG]

I understand your concerns (had the same situation), and really would ask the 
PMC to find a solution for that long delays. My motto is "release early, 
release often" but at Apache this seems to be not wanted or not possile. :-(

Let's do it this way: We incubate the plugin until we think it is ripe for 
moving it to Apache and hope the PMC will find a way for quicker release cycles 
until then! :-)

-Markus

-Ursprüngliche Nachricht-
Von: Slawomir Jaranowski [mailto:s.jaranow...@gmail.com] 
Gesendet: Montag, 28. Dezember 2020 14:32
An: Maven Developers List
Betreff: Re: Maven Sign Plugin

I'm really open to help developing / maintaining such a plugin under Apache
Organization.

But as we see the release process in Apache is very slow ... I need it now,
and I don't want to wait for years so I decided to release it by myself.

Probably it is another topic how to make Apache projects more agile and
more friendly for external contributors.

For example I did a few feature / fix for maven-invoker-plugin and I wait
about year for release next version, I don't have knowledge when it can
happen ...

pon., 28 gru 2020 o 14:04 Markus KARG  napisał(a):

> Please turn it into an official Maven plugin, as there are many people out
> there reluctant when it comes to third party due to sustained support etc.!
> :-)
> -Markus
>
>
> -Ursprüngliche Nachricht-
> Von: Slawomir Jaranowski [mailto:s.jaranow...@gmail.com]
> Gesendet: Montag, 28. Dezember 2020 13:09
> An: Maven Developers List
> Betreff: Re: Maven Sign Plugin
>
> Hi,
>
> First version of Sign Maven Plugin was released -
> https://github.com/s4u/sign-maven-plugin
>
> It works with Maven 3.6.x and future version 4.x
>
> If somebody is interested I invite them to test and collaborate.
>
> pon., 14 gru 2020 o 21:42 Slawomir Jaranowski 
> napisał(a):
>
> > Hi,
> >
> > The Idea of making a signature by java code without an external binary is
> > very good.
> >
> > I have plans to automate some  of CI/CD and such plugin will be very
> > useful for me.
> > I can customise it for easy use with CI system
> >
> > So waiting for you,
> > I will release it under my github organization, probably at the end of
> > year. If someone is interested please let me know.
> >
> >
> > pon., 2 lis 2020 o 21:36 Robert Scholte 
> napisał(a):
> >
> >> I want to have another look at Maven Resolver. I don't want to store it
> >> as a file, but stream it directly to a repository.
> >> The goal is now bound to verify, but that's incorrect (it has nothing to
> >> do with verifying integration results).
> >> Looking at it, I think this should not be a maven-plugin, but a Maven
> >> extension, so it can hook itself during deploy, no need for an explicit
> >> goal to call
> >> I need to work it out a bit more.
> >>
> >> thanks,
> >> Robert
> >>
> >> On 19-10-2020 22:47:06, Slawomir Jaranowski 
> >> wrote:
> >> Hi
> >>
> >> What next step do you plan with this plugin?
> >>
> >> I believe that can be usable even now for users.
> >>
> >> It is not too much work to prepare a plugin to work with maven 3.6 so we
> >> can publish it and take feedback from users.
> >>
> >> I think that early release can help users to prepare their project to be
> >> ready for maven 3.7.
> >>
> >> If you wish I will take care about this plugin.
> >>
> >> niedz., 4 paź 2020 o 15:32 Slawomir Jaranowski
> >> napisał(a):
> >>
> >> > First working version is ready:
> >> >
> >> > https://github.com/apache/maven-studies/pull/2
> >> >
> >> > I'm waiting for your opinion
> >> >
> >> > pt., 2 paź 2020 o 17:05 Slawomir Jaranowski
> >> > napisał(a):
> >> >
> >> >> Targeting to maven 3.7.0-SNAPSHOT makes easier access to Transformer
> >> api.
> >> >> So one issue is need to resolve:
> >> >> https://issues.apache.org/jira/browse/MNG-6992
> >> >>
> >> >> Of course it is clear that all "uploaded" files must be signed.
> >> >> Question is - if we should use transformer api only for POM or for
> all?
> >> >>
> >> >> pt., 2 paź 2020 o 15:57 Robert Scholte napisał(a):
> >> >>
> >> >>> All "uploaded" files must be signed, see for instance
> >> >>> https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/
> >> >>> And don't care about older Mav

AW: Maven Sign Plugin

[Markus KARG]

Please turn it into an official Maven plugin, as there are many people out 
there reluctant when it comes to third party due to sustained support etc.! :-)
-Markus


-Ursprüngliche Nachricht-
Von: Slawomir Jaranowski [mailto:s.jaranow...@gmail.com] 
Gesendet: Montag, 28. Dezember 2020 13:09
An: Maven Developers List
Betreff: Re: Maven Sign Plugin

Hi,

First version of Sign Maven Plugin was released -
https://github.com/s4u/sign-maven-plugin

It works with Maven 3.6.x and future version 4.x

If somebody is interested I invite them to test and collaborate.

pon., 14 gru 2020 o 21:42 Slawomir Jaranowski 
napisał(a):

> Hi,
>
> The Idea of making a signature by java code without an external binary is
> very good.
>
> I have plans to automate some  of CI/CD and such plugin will be very
> useful for me.
> I can customise it for easy use with CI system
>
> So waiting for you,
> I will release it under my github organization, probably at the end of
> year. If someone is interested please let me know.
>
>
> pon., 2 lis 2020 o 21:36 Robert Scholte  napisał(a):
>
>> I want to have another look at Maven Resolver. I don't want to store it
>> as a file, but stream it directly to a repository.
>> The goal is now bound to verify, but that's incorrect (it has nothing to
>> do with verifying integration results).
>> Looking at it, I think this should not be a maven-plugin, but a Maven
>> extension, so it can hook itself during deploy, no need for an explicit
>> goal to call
>> I need to work it out a bit more.
>>
>> thanks,
>> Robert
>>
>> On 19-10-2020 22:47:06, Slawomir Jaranowski 
>> wrote:
>> Hi
>>
>> What next step do you plan with this plugin?
>>
>> I believe that can be usable even now for users.
>>
>> It is not too much work to prepare a plugin to work with maven 3.6 so we
>> can publish it and take feedback from users.
>>
>> I think that early release can help users to prepare their project to be
>> ready for maven 3.7.
>>
>> If you wish I will take care about this plugin.
>>
>> niedz., 4 paź 2020 o 15:32 Slawomir Jaranowski
>> napisał(a):
>>
>> > First working version is ready:
>> >
>> > https://github.com/apache/maven-studies/pull/2
>> >
>> > I'm waiting for your opinion
>> >
>> > pt., 2 paź 2020 o 17:05 Slawomir Jaranowski
>> > napisał(a):
>> >
>> >> Targeting to maven 3.7.0-SNAPSHOT makes easier access to Transformer
>> api.
>> >> So one issue is need to resolve:
>> >> https://issues.apache.org/jira/browse/MNG-6992
>> >>
>> >> Of course it is clear that all "uploaded" files must be signed.
>> >> Question is - if we should use transformer api only for POM or for all?
>> >>
>> >> pt., 2 paź 2020 o 15:57 Robert Scholte napisał(a):
>> >>
>> >>> All "uploaded" files must be signed, see for instance
>> >>> https://repo1.maven.org/maven2/org/apache/maven/maven-core/3.6.3/
>> >>> And don't care about older Maven versions, for now just set the
>> >>> prerequisite for Maven to 3.7.0-SNAPSHOT in the pom.
>> >>>
>> >>> On 2-10-2020 14:21:02, Slawomir Jaranowski
>> >>> wrote:
>> >>> But on the other side, plugins must sign other artifacts associated
>> with
>> >>> a
>> >>> given project.
>> >>>
>> >>> So in this way we have two different processes - one for pom with
>> >>> transformation and ather for rest artifacts.
>> >>>
>> >>> Maybe all project artifacts should go through the transformation
>> process
>> >>> then we can have one way for all.
>> >>>
>> >>> Anyway, first we should resolve how to access Transformers from the
>> >>> plugin.
>> >>> And how (if we want) get comparability for old maven versions.
>> >>>
>> >>>
>> >>> pt., 2 paź 2020 o 10:46 Robert Scholte napisał(a):
>> >>>
>> >>> > In the end a signer is just another file transformer, so we need to
>> >>> > achieve something like this:
>> >>> > local pom >> build/consumer pom (distribute) >> sign (distribute)
>> >>> > The plugin must be able to register a SignFileTransformer, which
>> should
>> >>> > only be called during deploy. For the latter I can imagine we need
>> to
>> >>> > extend the API.
>> >>> >
>> >>> > thanks,
>> >>> > Robert
>> >>> > On 28-9-2020 00:35:45, Slawomir Jaranowski wrote:
>> >>> > In order to remove reflection and possibility to call:
>> >>> >
>> >>> > FileTransformerManager fileTransformerManager =
>> >>> > repositorySystemSession.getFileTransformerManager();
>> >>> >
>> >>> > I must add:
>> >>> >
>> >>> > org.eclipse.aether.transform
>> >>> >
>> >>> > in:
>> >>> >
>> >>> >
>> >>>
>> https://github.com/apache/maven/blob/0e3c7a433fc4f700cc2ae6d2c11ae39ec93cbadb/maven-core/src/main/resources/META-INF/maven/extension.xml#L58
>> >>> >
>> >>> > Without it I have:
>> >>> > java.lang.ClassNotFoundException:
>> >>> > org.eclipse.aether.transform.FileTransformerManager
>> >>> >
>> >>> > this change will be possible in the latest maven version, call above
>> >>> method
>> >>> > on older maven version will cause ClassNotFoundException
>> >>> >
>> >>> > adding direct dependency to maven-resolver-api (even in newer
>> version)
>> >>> in

AW: [Idea] Coding Guidelines for Maven Contribution Newbies

[Markus KARG]

Sandra,

welcome in the Maven dev community! :-)

I think a good starting point would be to simply write up your personal 
lessions lerned, so others can then add PRs ontop with their additions.

Regards
-Markus

P.S.: Like to join us at JavaLand 2021's community workshop on becoming a Maven 
contributor? I think it would be very beneficial for the attendees, so we would 
not just have the appreciated voices of Karl-Heinz and Robert, but also your 
view as a first-time plugin contributor! 

-Ursprüngliche Nachricht-
Von: Sandra Parsick [mailto:spars...@web.de] 
Gesendet: Dienstag, 22. Dezember 2020 14:34
An: dev@maven.apache.org
Betreff: [Idea] Coding Guidelines for Maven Contribution Newbies

Hello dev-list,

some weeks ago, I have started creating some Pull Requests for the Maven JLink 
Plugin [1]. There were many hints about coding rules or decision which version 
/ libs etc should be used and more. So I need some iterations till a trivial 
(IMHO) PR was accepted or in one case to find out the PR was completely 
unnecessary. That was a little bit frustating.
I think it would be easier for new contributor to have a guideline or checklist 
of things to consider. I would love to help create such a checklist or 
guideline to lower the barrier to entry for contributing. I already discuss the 
idea with Ben and he has agreed to help. So what do you think about this idea? 
If this idea finds approval, where is the best place to place it?

Best regards,

Sandra

[1]
https://github.com/apache/maven-jlink-plugin/pulls?q=is%3Apr+is%3Aclosed+author%3Asparsick



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

AW: First issue

[Markus KARG]

Just pick anything you do have fun with working on. :-)
-Markus


-Ursprüngliche Nachricht-
Von: Andrey Fadeev [mailto:aaa...@yandex.ru] 
Gesendet: Dienstag, 22. Dezember 2020 12:53
An: dev@maven.apache.org
Betreff: First issue

Hello everyone!


I'd like to contribute in order to learn Maven and gain experience,

but don't know what issue to choose. Is there any suggestions?

In other case I'm ready to tackle MNG-6806 if it's still relevant.


P.S. My skills & knowledge include java 8 programming and standard data 
structures.


-
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

AW: Help Wanted

[Markus KARG]

ROR]
/Maven-plugin/maven-dependency-plugin/maven-dependency-plugin-markus/src/tes
t/java/org/apache/maven/plugins/dependency/fromDependencies/TestCopyDependen
ciesMojo.java:[441,65] incompatible types: java.lang.Object cannot be
converted to org.apache.maven.artifact.Artifact

[INFO] 23 errors 

No NullPointerException but then again i had to reconfig pom.xml

FWIK: casting errors as far as I can tell

will report back to you when I can compile and test

gruss
martin

 

  _  

From: Markus Karg 
Sent: Thursday, December 3, 2020 12:23 PM
To: dev@maven.apache.org 
Subject: Help Wanted 

 

I would be super happy if somebody of the Maven Heros could help me with my
PR as I am totally stuck!

https://github.com/apache/maven-dependency-plugin/pull/109

Anybody having an idea how I can solve this?

Thanks!
-Markus

AW: [DISCUSS] Allow attributes shorthand in pom.xml

[Markus KARG]

Okay, seems you got me wrong. The idea is not to force YOU to write JSON, but 
to allows OTHERS to do that. There are people that like JSON and YAML over XML, 
so we if would have a separating layer between the information needed by Maven 
itself, and the data format providing that information, we would have the 
freedom for people to add ANY config format they like. I cannot see any good 
reason against THAT. Stay with XML as long as YOU want, but let OTHERS use 
OTHER formats.
-Markus


-Ursprüngliche Nachricht-
Von: Michael Osipov [mailto:micha...@apache.org] 
Gesendet: Samstag, 12. Dezember 2020 12:46
An: dev@maven.apache.org
Betreff: Re: [DISCUSS] Allow attributes shorthand in pom.xml

Am 2020-12-12 um 11:04 schrieb Markus KARG:
> Wouldn't it be a more modern and even more effective approach to add JSON 
> support for POMs? We could keep POM.xml for legacy reasons but add support 
> for POM.json files.

NOO, please! JSON is horribly to write by hand and does not have 
comments. It is a decent serialization format, but a horrible one for 
humans. I would rather prefer YAML for this.

> -Ursprüngliche Nachricht-
> Von: Will Iverson [mailto:wiver...@gmail.com]
> Gesendet: Freitag, 11. Dezember 2020 23:40
> An: dev@maven.apache.org
> Betreff: [DISCUSS] Allow attributes shorthand in pom.xml
> 
> One of the biggest complaints about Maven has long been the verbosity of
> the XML format. The verbosity is due in large part to the exclusive
> reliance on XML elements in Maven.
> 
> Proposal: Allow Maven pom.xml to treat attributes as a short-hand for
> declaring configuration elements.
> 
> Example: One of the most verbose sections of the pom for most projects is
> dependencies. A typical example:
> 
> 
> commons-io
> commons-io
> 2.8.0
> 
> 
> Here is the same declaration expressed with attribute shortcuts:
> 
> 
> That's an 80% reduction in LoC, and would make Maven comparable with other
> popular build tools (e.g. compare and contrast with other build tools at
> https://mvnrepository.com/artifact/commons-io/commons-io/2.8.0)
> 
> REQUEST: Feedback on if this is something to pursue. I've done some
> research, happy to submit patches, but don't want to pursue if there is
> either a) technical reason[s] not to proceed I'm not aware of or b) a lack
> of enthusiasm for the entire idea from the community.
> 
> Basically, I'm looking for some feedback along the lines of a) love it -
> please submit patches so we can check it out, b) huh, maybe, willing to
> look at it, or c) this is a terrible idea, because X. Effectively, a
> totally non-binding vote on if this is worth exploring.
> 
> I've discussed this with others online and done some research, so are a few
> answers to objections/Qs as I currently understand. I may be
> wrong/uninformed about certain aspects, which would be very helpful
> feedback.
> 
> Q: Won't this require a new Maven XSD to be generated?
> A: No. The current Maven XSD declares many elements, but is not actually
> involved in validation. While the current XSD is valuable for tools and
> documentation, it does not actually perform validation.
> 
> Q: Wait, so what actually does the validation?
> A: It's all done in Java code generated by Modello. The maven-model project
> (https://github.com/apache/maven/tree/maven-3.6.3/maven-model) relies on
> the Modello Maven Plugin (
> http://codehaus-plexus.github.io/modello/modello-maven-plugin/) which in
> turn relies on Modello core (http://codehaus-plexus.github.io/modello/) to
> generate the Java code that processes the pom.xml
> 
> The proposal is to submit a patch for Modello that would allow the
> generated source to accept an attribute as an alias for input. If it's a
> valid element per the Maven maven.mdo file (
> https://github.com/apache/maven/blob/maven-3.6.3/maven-model/src/main/mdo/maven.mdo)
> it will now accept an attribute as a shortcut.
> 
> Q: Wouldn't this break, like, everything?
> A: It would only affect pom.xml files that are read at runtime. All emitted
> pom.xml files would remain exactly the same.
> 
> Q: Does this involve changing or rewriting the user's pom.xml? Isn't that
> the thing that's making it hard to support alternative formats for pom.xml
> like polyglot poms, etc?
> A: Nope, the pom.xml on disk is still the pom.xml. A
> X.X.X would be the only flag
> recommended to declare that a pom.xml uses attributes for shorthand.
> 
> Q: How much work is this to actually implement?
> A: It starts with a few lines added to the Modello code generation to allow
> for attribute aliasing with a feature flag. Testing those changes through
> the rest of the dependency chain. Adding test cases throughout.
> Documentation. although as "now you can use a

AW: AW: [DISCUSS] Allow attributes shorthand in pom.xml

[Markus KARG]

Well, don't get me wrong, I think the original question was not whether YOU 
invest time in that, but more whether it makes sense that OTHERS invest in 
that. In the end, this is a democratic and open project. Not every idea asked 
is intended as your personal task. ;-)
-Markus


-Ursprüngliche Nachricht-
Von: Robert Scholte [mailto:rfscho...@apache.org] 
Gesendet: Samstag, 12. Dezember 2020 12:53
An: dev@maven.apache.org
Betreff: Re: AW: [DISCUSS] Allow attributes shorthand in pom.xml

Here's my unpopular response: I'm not going to invest in attribute support for 
Maven.
If the verbosity of the pom.xml is the first thing people complain about, well, 
then Maven is doing a pretty good job (if the build itself had issues, one 
would complain about that first, right?).
By having elements only it is much easier to maintain Maven. 
It'll remove discussion as to: what would be an attribute and what should be an 
element? Can it be based on required versus optional? Allowing both for the 
same "fields" is probably a recipe for disaster.

I'll leave it up to tools like polyglot to do some the transformation from your 
favorite language to the XML as expected by Maven.
This is a clear separation, and it will give the Maven team the opportunity to 
focus on the real issues.

So please join your forces and spend your energy on improving polyglot!

thanks,
Robert
On 12-12-2020 11:04:33, Markus KARG  wrote:
Wouldn't it be a more modern and even more effective approach to add JSON 
support for POMs? We could keep POM.xml for legacy reasons but add support for 
POM.json files.
-Markus

-Ursprüngliche Nachricht-
Von: Will Iverson [mailto:wiver...@gmail.com]
Gesendet: Freitag, 11. Dezember 2020 23:40
An: dev@maven.apache.org
Betreff: [DISCUSS] Allow attributes shorthand in pom.xml

One of the biggest complaints about Maven has long been the verbosity of
the XML format. The verbosity is due in large part to the exclusive
reliance on XML elements in Maven.

Proposal: Allow Maven pom.xml to treat attributes as a short-hand for
declaring configuration elements.

Example: One of the most verbose sections of the pom for most projects is
dependencies. A typical example:


commons-io
commons-io
2.8.0


Here is the same declaration expressed with attribute shortcuts:


That's an 80% reduction in LoC, and would make Maven comparable with other
popular build tools (e.g. compare and contrast with other build tools at
https://mvnrepository.com/artifact/commons-io/commons-io/2.8.0)

REQUEST: Feedback on if this is something to pursue. I've done some
research, happy to submit patches, but don't want to pursue if there is
either a) technical reason[s] not to proceed I'm not aware of or b) a lack
of enthusiasm for the entire idea from the community.

Basically, I'm looking for some feedback along the lines of a) love it -
please submit patches so we can check it out, b) huh, maybe, willing to
look at it, or c) this is a terrible idea, because X. Effectively, a
totally non-binding vote on if this is worth exploring.

I've discussed this with others online and done some research, so are a few
answers to objections/Qs as I currently understand. I may be
wrong/uninformed about certain aspects, which would be very helpful
feedback.

Q: Won't this require a new Maven XSD to be generated?
A: No. The current Maven XSD declares many elements, but is not actually
involved in validation. While the current XSD is valuable for tools and
documentation, it does not actually perform validation.

Q: Wait, so what actually does the validation?
A: It's all done in Java code generated by Modello. The maven-model project
(https://github.com/apache/maven/tree/maven-3.6.3/maven-model) relies on
the Modello Maven Plugin (
http://codehaus-plexus.github.io/modello/modello-maven-plugin/) which in
turn relies on Modello core (http://codehaus-plexus.github.io/modello/) to
generate the Java code that processes the pom.xml

The proposal is to submit a patch for Modello that would allow the
generated source to accept an attribute as an alias for input. If it's a
valid element per the Maven maven.mdo file (
https://github.com/apache/maven/blob/maven-3.6.3/maven-model/src/main/mdo/maven.mdo)
it will now accept an attribute as a shortcut.

Q: Wouldn't this break, like, everything?
A: It would only affect pom.xml files that are read at runtime. All emitted
pom.xml files would remain exactly the same.

Q: Does this involve changing or rewriting the user's pom.xml? Isn't that
the thing that's making it hard to support alternative formats for pom.xml
like polyglot poms, etc?
A: Nope, the pom.xml on disk is still the pom.xml. A
X.X.X would be the only flag
recommended to declare that a pom.xml uses attributes for shorthand.

Q: How much work is this to actually implement?
A: It starts with a few lines added to the Modello code generation to allow
for attribute aliasing with a feature flag. Testing those changes through
the rest of the dependency cha

AW: [DISCUSS] Allow attributes shorthand in pom.xml

[Markus KARG]

Wouldn't it be a more modern and even more effective approach to add JSON 
support for POMs? We could keep POM.xml for legacy reasons but add support for 
POM.json files.
-Markus

-Ursprüngliche Nachricht-
Von: Will Iverson [mailto:wiver...@gmail.com] 
Gesendet: Freitag, 11. Dezember 2020 23:40
An: dev@maven.apache.org
Betreff: [DISCUSS] Allow attributes shorthand in pom.xml

One of the biggest complaints about Maven has long been the verbosity of
the XML format. The verbosity is due in large part to the exclusive
reliance on XML elements in Maven.

Proposal: Allow Maven pom.xml to treat attributes as a short-hand for
declaring configuration elements.

Example: One of the most verbose sections of the pom for most projects is
dependencies. A typical example:


commons-io
commons-io
2.8.0


Here is the same declaration expressed with attribute shortcuts:


That's an 80% reduction in LoC, and would make Maven comparable with other
popular build tools (e.g. compare and contrast with other build tools at
https://mvnrepository.com/artifact/commons-io/commons-io/2.8.0)

REQUEST: Feedback on if this is something to pursue. I've done some
research, happy to submit patches, but don't want to pursue if there is
either a) technical reason[s] not to proceed I'm not aware of or b) a lack
of enthusiasm for the entire idea from the community.

Basically, I'm looking for some feedback along the lines of a) love it -
please submit patches so we can check it out, b) huh, maybe, willing to
look at it, or c) this is a terrible idea, because X. Effectively, a
totally non-binding vote on if this is worth exploring.

I've discussed this with others online and done some research, so are a few
answers to objections/Qs as I currently understand. I may be
wrong/uninformed about certain aspects, which would be very helpful
feedback.

Q: Won't this require a new Maven XSD to be generated?
A: No. The current Maven XSD declares many elements, but is not actually
involved in validation. While the current XSD is valuable for tools and
documentation, it does not actually perform validation.

Q: Wait, so what actually does the validation?
A: It's all done in Java code generated by Modello. The maven-model project
(https://github.com/apache/maven/tree/maven-3.6.3/maven-model) relies on
the Modello Maven Plugin (
http://codehaus-plexus.github.io/modello/modello-maven-plugin/) which in
turn relies on Modello core (http://codehaus-plexus.github.io/modello/) to
generate the Java code that processes the pom.xml

The proposal is to submit a patch for Modello that would allow the
generated source to accept an attribute as an alias for input. If it's a
valid element per the Maven maven.mdo file (
https://github.com/apache/maven/blob/maven-3.6.3/maven-model/src/main/mdo/maven.mdo)
it will now accept an attribute as a shortcut.

Q: Wouldn't this break, like, everything?
A: It would only affect pom.xml files that are read at runtime. All emitted
pom.xml files would remain exactly the same.

Q: Does this involve changing or rewriting the user's pom.xml? Isn't that
the thing that's making it hard to support alternative formats for pom.xml
like polyglot poms, etc?
A: Nope, the pom.xml on disk is still the pom.xml. A
X.X.X would be the only flag
recommended to declare that a pom.xml uses attributes for shorthand.

Q: How much work is this to actually implement?
A: It starts with a few lines added to the Modello code generation to allow
for attribute aliasing with a feature flag. Testing those changes through
the rest of the dependency chain. Adding test cases throughout.
Documentation. although as "now you can use attributes" is conceptually
simple it's not too bad. Tools in the Maven ecosystem would be able to
indicate they have been updated to support this by referring to the simple
term, "attribute shortcuts". Because nothing else changes, the only real
documentation change would be "things that were elements can also be
declared as attributes." The trickiest part is probably sorting out how to
manage the feature flag across the various components. I'm sure there's
more with a huge ecosystem like this, but the actual changes to the Modello
code gen appear to be surprisingly minor.

Q: What about tooling, like IDEs, publishing to Maven Central & Maven
repositories, etc?
A: Many IDEs appear to have implemented validation logic on top of Maven
that currently will flag attributes as errors in a pom.xml. Those IDEs and
other tools would require updates to this validation logic. Because the
rendered pom.xml output remains the same publishing tool chains and Maven
repositories should be completely unaffected.

Q: Any big issues you've identified?
A: Many sub-elements are not actually processed by Modello or Maven Model,
but are instead passed along to the plugin. For example, 
elements. It would be up to each of these projects to eventually allow for
attribute aliasing (or not). Maven projects that rely on Modello would have
the choice to adopt the new 

Help Wanted

[Markus Karg]

I would be super happy if somebody of the Maven Heros could help me with my PR 
as I am totally stuck!

https://github.com/apache/maven-dependency-plugin/pull/109

Anybody having an idea how I can solve this?

Thanks!
-Markus

AW: Talk: Bootstrapping the Java Ecosystem

[Markus KARG]

In fact, as along term user of Maven and Linux, I actually even dislike that 
binary JARs are rebuilt from scratch, as this is not what WORA was invented 
for. It adds no benefits, it just adds new bugs happening on one distro but no 
on another. If you ask me, immediately stop doing that and simply use the one 
and original built from Apache. This is not C++, this is Java.

And if you want to build Maven from scratch, then build it using Maven. That is 
the intended way.

-Markus


-Ursprüngliche Nachricht-
Von: Tamás Cservenák [mailto:ta...@cservenak.net] 
Gesendet: Donnerstag, 19. November 2020 09:51
An: Maven Developers List
Betreff: Re: Talk: Bootstrapping the Java Ecosystem

Hi Bjorn and Emmanuel,

Without starting any flame wars, am really curious: why are you
repackaging Maven?

I'd understand for OS/distro native packages, but
why do you rebuild JVM bytecode as well?

Again, am not to start any flame war, am just curious!

Am Linux user since 98 (first worked on S.u.S.E at university
around '96), but was since using "dirty" distros like
openSUSE then Ubuntu and today Mint.

While watching the video, several questions arose in my head:

1) Instead of rebuilding something (let's say LOC of 1x), you
did that several, if not ten times (so LOC of 10x). So, you
had to review the codebase 10x I guess? Otherwise you are not
sure what you built - as I guess you build it from source
to be sure and able to see (among others) what are you
building. How long was the review process?

2) Similarly, in a process like this, how do you track
vulnerabilities or any other outstanding bugs? Or the
"intermediate" bootstrapped dependencies simply "does not
matter"? Just the final "output" is what matters
(let's say Maven)?

3) What are you really building? As in video, it is said
several times that you "mutilate" some package to build
it, then use it to "bootstrap" some other package, and finally
you rebuild the target package. Given in the process there
was once a "mutilated" tool, how are you certain, that output
of the build is correct (I have no doubts about
reproducibility)? How do you prove that output is what
it is thought/assumed to be?

3) (Joker) What is the overall CO2 footprint of distros like
these? I believe you did not use Apple M1 for this work... :)


Thanks in advance,
T

On Thu, Nov 19, 2020 at 9:15 AM Emmanuel Bourg  wrote:

> Hi Björn,
>
> Nice presentation, the packaging of Maven in Debian followed a similar
> path but we never documented the process. Did you go as far as recording
> the exact steps and build order required to build from scratch?
>
> Spoiler for the next part of your quest toward packaging the Android
> SDK: Maven was the easy part, Gradle and Kotlin are many leagues above
> in term of circular dependencies and headache. We have been trying to
> bootstrap Kotlin for 2 years in Debian and haven't found the right path
> yet.
>
> Emmanuel Bourg
>
>
> On 18/11/2020 21:29, Björn Höfling wrote:
> > Dear Maven Developers,
> >
> > more than 4 years ago I naively asked you on how to build Maven from
> > sources without using Maven.
> >
> > If you are interested in a declarative, bootstrappable, reproducible
> > and effectively executable answer to this question, Julien Lepiller
> > recorded a video on how he bootstrapped Maven and a maven-build-system
> > for GNU Guix with only using the ant-build-system. He shows how to
> > bootstrap Maven only from sources, which difficulties he had and how he
> > mastered the dependency cycles and other problems.
> >
> > You can find a link to the video recordings in this announcement:
> >
> > https://guix.gnu.org/en/blog/2020/online-guix-day-announce-2/
> >
> > If you have any questions, you can join the discussions on Guix day,
> > the discussions for this talk will be on Sunday 2020-11-22, 16:00–16:25
> > UTC.
> >
> > Happy Hacking,
> >
> > Björn
> >
>
> -
> 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

RFC on MDEP-726 and MDEP-437

[Markus Karg]

Dear Maven Developers,

I’d like to kindly request your feedback on my PRs:

https://github.com/apache/maven-dependency-plugin/pull/109

https://github.com/apache/maven-dependency-plugin/pull/87

Thanks a lot! 
-Markus

AW: AW: Hacktoberfest

[Markus KARG]

You are right that, but this is a tricky situation:

* We need more committers to accept more PRs.
* We need to accept more PRs to encourage contributors to contribute more often.
* Contributions need to contribute accepted PRs more often to become committer.

So the sole possible solutions are:

* Contributors become committers without frequently accepted PRs (rather bad 
idea)
* Committers accept PRs more frequenlty (the sole left over solution)

Maybe I missed something, but I do not see any other solution the get at speed.

-Markus


-Ursprüngliche Nachricht-
Von: Robert Scholte [mailto:rfscho...@apache.org] 
Gesendet: Sonntag, 4. Oktober 2020 16:11
An: dev@maven.apache.org
Betreff: Re: AW: Hacktoberfest

As you know, the truth right now it is impossible to keep up. The amount of 
mails and PRs waiting for responses exceeds our capacity.
So it is a matter of prioritizing, and yes, that could mean that PRs will stay 
unanswered.
IF we would also join hacktober, we must change those priorities for a month 
and focus on that, maybe even using the time to respond the open PRs.

thanks,
Robert

On 4-10-2020 13:36:52, Markus KARG  wrote:
Robert,

in fact I think it would be an even better signal to new contributors is at 
least 5 committers would agree to pick up PRs for a whole year.

-Markus


-Ursprüngliche Nachricht-
Von: Robert Scholte [mailto:rfscho...@apache.org]
Gesendet: Sonntag, 4. Oktober 2020 10:55
An: Maarten Mulders; dev@maven.apache.org
Betreff: Re: Hacktoberfest

I think the hacktober is a good initiative.
Just be aware that we need to respond to these PRs ASAP, otherwise it might 
work against us.
We already have a huge amount of PRs that still need to be reviewed, so it is 
not like we don't have enough PRs.

I think we need at least 5 committers that explicitly say the will pick up 
these PR with the highest priority for 1 month.
Otherwise I'd say no.

Robert


On 3-10-2020 20:41:04, Maarten Mulders wrote:
Hi all,

Today, I came across this update [1] from DigitalOcean, one of the
companies behind Hacktoberfest. TL;DR: to prevent "spam pull requests",
only accepted/merged/approved pull requests against GitHub repositories
labelled "hacktoberfest" qualify for the free t-shirt or planting a
tree. This is other than previous years, where _every_ pull request
would qualify, even if the repository owner did not explicitly
participate in Hacktoberfest.

I would argue it makes sense to opt-in Maven repositories for
Hacktoberfest. If it could encourage people to start contributing to
Maven, I think that would be useful. It might also bring Maven to the
attention of people who are looking for (Java) projects to contribute to.

Any thoughts?

Thanks,

Maarten



[1] https://hacktoberfest.digitalocean.com/hacktoberfest-update

-
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

AW: Hacktoberfest

[Markus KARG]

Robert,

in fact I think it would be an even better signal to new contributors is at 
least 5 committers would agree to pick up PRs for a whole year.

-Markus


-Ursprüngliche Nachricht-
Von: Robert Scholte [mailto:rfscho...@apache.org] 
Gesendet: Sonntag, 4. Oktober 2020 10:55
An: Maarten Mulders; dev@maven.apache.org
Betreff: Re: Hacktoberfest

I think the hacktober is a good initiative.
Just be aware that we need to respond to these PRs ASAP, otherwise it might 
work against us.
We already have a huge amount of PRs that still need to be reviewed, so it is 
not like we don't have enough PRs.

I think we need at least 5 committers that explicitly say the will pick up 
these PR with the highest priority for 1 month.
Otherwise I'd say no.

Robert


On 3-10-2020 20:41:04, Maarten Mulders  wrote:
Hi all,

Today, I came across this update [1] from DigitalOcean, one of the
companies behind Hacktoberfest. TL;DR: to prevent "spam pull requests",
only accepted/merged/approved pull requests against GitHub repositories
labelled "hacktoberfest" qualify for the free t-shirt or planting a
tree. This is other than previous years, where _every_ pull request
would qualify, even if the repository owner did not explicitly
participate in Hacktoberfest.

I would argue it makes sense to opt-in Maven repositories for
Hacktoberfest. If it could encourage people to start contributing to
Maven, I think that would be useful. It might also bring Maven to the
attention of people who are looking for (Java) projects to contribute to.

Any thoughts?

Thanks,

Maarten



[1] https://hacktoberfest.digitalocean.com/hacktoberfest-update

-
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

AW: Why is old IO API used in maven resolver?

[Markus KARG]

I used Files.copy a lot in the real world with different sizes, and it was 
always superior to old-school solutions, but I did not benchmark it with 
multi-GiB files.
-Markus

-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] 
Gesendet: Mittwoch, 19. August 2020 15:08
An: Maven Developers List
Betreff: Re: Why is old IO API used in maven resolver?

Did you test the newer Files.copy?

It seems to use a plain char[] forwarding impl too ([1]) vs the sendfile64
of the channel impl ([2]).
Also did you try with some Gigs files? IIRC sendfile had a limitation of a
few gigas - and we sadly have artifacts of > 4G even if rare.
That said if the size is available it can be tested and the optimization
used quite easily I guess.

[1]
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/unix/native/libnio/fs/UnixCopyFile.c#L53
[2]
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/unix/native/libnio/ch/FileChannelImpl.c#L135

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 19 août 2020 à 14:35, Markus KARG  a écrit :

> I do not support your judgement. That bug you mention was fixed nine years
> ago, so even the most exotic platforms should have adopted the fix
> meanwhile. This IS reliable and not more nor less buggy than any other part
> of the JRE. What we should do is give intensive tensting of Stefan's PR,
> but not overhastily abstain from it due to FUD. As a long time user of NIO
> API on Windows and Linux (speaking of years here) I strongly believe that
> the performance benefits will definitively outweigh the potential risks.
> -Markus
>
> -Ursprüngliche Nachricht-
> Von: Jochen Wiedmann [mailto:jochen.wiedm...@gmail.com]
> Gesendet: Mittwoch, 19. August 2020 13:05
> An: Maven Developers List
> Betreff: Re: Why is old IO API used in maven resolver?
>
> On Wed, Aug 19, 2020 at 11:49 AM Michael Osipov 
> wrote:
> >
> > Am 2020-08-19 um 11:27 schrieb Jochen Wiedmann:
> > > Looking at
> > >
> > >  https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6822107
> > >
> > > I would very much like us to abstain from every attempt to go into the
> > > direction, that Stefan suggests. The consequence could be, that we
> > > need to bother with exotic corner cases. Let's stay simple, but
> > > reliable.
> >
> >
> > You proposal is not to change the code at all?
>
> If it's working fine: Yes.
>
> --
>
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
>
> -- (Terry Pratchett, Thief of Time)
>
> -
> 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

AW: Why is old IO API used in maven resolver?

[Markus KARG]

I do not support your judgement. That bug you mention was fixed nine years ago, 
so even the most exotic platforms should have adopted the fix meanwhile. This 
IS reliable and not more nor less buggy than any other part of the JRE. What we 
should do is give intensive tensting of Stefan's PR, but not overhastily 
abstain from it due to FUD. As a long time user of NIO API on Windows and Linux 
(speaking of years here) I strongly believe that the performance benefits will 
definitively outweigh the potential risks.
-Markus

-Ursprüngliche Nachricht-
Von: Jochen Wiedmann [mailto:jochen.wiedm...@gmail.com] 
Gesendet: Mittwoch, 19. August 2020 13:05
An: Maven Developers List
Betreff: Re: Why is old IO API used in maven resolver?

On Wed, Aug 19, 2020 at 11:49 AM Michael Osipov  wrote:
>
> Am 2020-08-19 um 11:27 schrieb Jochen Wiedmann:
> > Looking at
> >
> >  https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6822107
> >
> > I would very much like us to abstain from every attempt to go into the
> > direction, that Stefan suggests. The consequence could be, that we
> > need to bother with exotic corner cases. Let's stay simple, but
> > reliable.
>
>
> You proposal is not to change the code at all?

If it's working fine: Yes.

-- 

Look, that's why there's rules, understand? So that you think before
you break 'em.

-- (Terry Pratchett, Thief of Time)

-
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

AW: Assumption fail treated as unexcepted exception?!

[Markus KARG]

Martin,

sorry was busy otherwise, had no time to check with JUnit 4. Will try ASAP and 
report here.

In fact I do not understand what you want me to ask the JUnit authors. I do not 
want to use JUnit 3 at all (I did not actively decide for any version), so if 
there is something to ask them, please tell me *what*?

thanks
-Markus


-Ursprüngliche Nachricht-
Von: Martin Gainty [mailto:mgai...@hotmail.com] 
Gesendet: Dienstag, 18. August 2020 11:28
An: Maven Developers List
Betreff: Re: Assumption fail treated as unexcepted exception?!

have you tried with junit4?

if you need to stick with older junit then you can implement your 
AssumptionViolatedException to extend BuildFailureException

any feedback from junit author on this behaviour?

gruss
~martin~



From: Markus KARG 
Sent: Monday, August 17, 2020 1:53 PM
To: 'Maven Developers List' 
Subject: AW: Assumption fail treated as unexcepted exception?!

That doesn't make it any better, and it is no excuse that we do not simply 
catch that particular exception inside the Surefire plugin.
So did we simply forget to implement this is the Surefire plugin (so I can add 
it), did we not implement it deliberately (so I shall not add it), or is it 
broken (so I shall fix it)?
-Markus

-Ursprüngliche Nachricht-
Von: Tibor Digana [mailto:tibordig...@apache.org]
Gesendet: Montag, 17. August 2020 18:37
An: Maven Developers List
Betreff: Re: Assumption fail treated as unexcepted exception?!

This is the outcome in IDEA:

"Tests failed: 1, passed: 0"

So the behavior is the same with Maven.

On Mon, Aug 17, 2020 at 6:35 PM Tibor Digana  wrote:

> Hi Markus,
>
> It is a specific problem related to the JUnit library because the test
> fails in IntelliJ IDEA and in Maven as well.
>
> The JUnit4 assumptions fail with yellow markers in IDEA but here the
> JUnit3' TestCase fails in red as a typical error or failure.
> And Maven fails this test as follows but i think this behavior starts in
> the junit library itself.
>
> [INFO] Running test.TestAssumptions
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 0.028 s <<< FAILURE! - in test.TestAssumptions
> [ERROR] test.TestAssumptions.testABC  Time elapsed: 0.01 s  <<< ERROR!
> org.junit.AssumptionViolatedException: got: , expected: is 
> at test/test.TestAssumptions.testABC(TestAssumptions.java:9)
>
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Errors:
> [ERROR]   TestAssumptions.testABC:9 » AssumptionViolated got: ,
> expected: is  [INFO]
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO]
> [INFO]
> --------
> [INFO] BUILD FAILURE
>
> On Mon, Aug 17, 2020 at 3:07 PM Markus KARG 
> wrote:
>
>> Martin,
>>
>> I don't understand your question.
>>
>> You posted the Javadocs, and they tell it clearly: "A test for which an
>> assumption fails should NOT generate a test case failure.".
>>
>> Also Assume's Javadocs
>> (https://junit.org/junit4/javadoc/4.12/org/junit/Assume.html) are pretty
>> clear about it: "... A failed assumption does NOT mean the code is broken,
>> but that the test provides no useful information. Assume basically means
>> "don't RUN this test if these conditions don't apply". The default JUnit
>> runner SKIPS tests with failing assumptions..."
>>
>> So do you really want me to ask the JUnit people whether they really MEAN
>> what they clearly wrote...?
>>
>> -Markus
>>
>> -Ursprüngliche Nachricht-
>> Von: Martin Gainty [mailto:mgai...@hotmail.com]
>> Gesendet: Montag, 17. August 2020 12:27
>> An: Maven Developers List
>> Betreff: Re: Assumption fail treated as unexcepted exception?!
>>
>>
>>/**
>>  * Call to assume that actual satisfies the condition
>> specified by matcher.
>>  * If not, the test halts and is ignored.
>>  * Example:
>>  * :
>>  *   assumeThat(1, is(1)); // passes
>>  *   foo(); // will execute
>>  *   assumeThat(0, is(1)); // assumption failure! test halts
>>  *   int x = 1 / 0; // will never execute
>>  * 
>>  *
>>  * @param  the static type accepted by the matcher (this can flag
>> obvious compile-time problems such as {@code assumeThat(1, is("a"))}
>>  * @param actual the computed value being compared
>>  * @param matcher an expression, built of {@link Matcher}s, specifying
>> allowed values
>>  * @see org.hamcrest.CoreMatchers
>>  * @see org.junit.matchers.JUnitMatchers
>>  */
>> public static  void assumeThat(T actu

AW: Assumption fail treated as unexcepted exception?!

[Markus KARG]

That doesn't make it any better, and it is no excuse that we do not simply 
catch that particular exception inside the Surefire plugin.
So did we simply forget to implement this is the Surefire plugin (so I can add 
it), did we not implement it deliberately (so I shall not add it), or is it 
broken (so I shall fix it)?
-Markus

-Ursprüngliche Nachricht-
Von: Tibor Digana [mailto:tibordig...@apache.org] 
Gesendet: Montag, 17. August 2020 18:37
An: Maven Developers List
Betreff: Re: Assumption fail treated as unexcepted exception?!

This is the outcome in IDEA:

"Tests failed: 1, passed: 0"

So the behavior is the same with Maven.

On Mon, Aug 17, 2020 at 6:35 PM Tibor Digana  wrote:

> Hi Markus,
>
> It is a specific problem related to the JUnit library because the test
> fails in IntelliJ IDEA and in Maven as well.
>
> The JUnit4 assumptions fail with yellow markers in IDEA but here the
> JUnit3' TestCase fails in red as a typical error or failure.
> And Maven fails this test as follows but i think this behavior starts in
> the junit library itself.
>
> [INFO] Running test.TestAssumptions
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 0.028 s <<< FAILURE! - in test.TestAssumptions
> [ERROR] test.TestAssumptions.testABC  Time elapsed: 0.01 s  <<< ERROR!
> org.junit.AssumptionViolatedException: got: , expected: is 
> at test/test.TestAssumptions.testABC(TestAssumptions.java:9)
>
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Errors:
> [ERROR]   TestAssumptions.testABC:9 » AssumptionViolated got: ,
> expected: is  [INFO]
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO]
> [INFO]
> --------
> [INFO] BUILD FAILURE
>
> On Mon, Aug 17, 2020 at 3:07 PM Markus KARG 
> wrote:
>
>> Martin,
>>
>> I don't understand your question.
>>
>> You posted the Javadocs, and they tell it clearly: "A test for which an
>> assumption fails should NOT generate a test case failure.".
>>
>> Also Assume's Javadocs
>> (https://junit.org/junit4/javadoc/4.12/org/junit/Assume.html) are pretty
>> clear about it: "... A failed assumption does NOT mean the code is broken,
>> but that the test provides no useful information. Assume basically means
>> "don't RUN this test if these conditions don't apply". The default JUnit
>> runner SKIPS tests with failing assumptions..."
>>
>> So do you really want me to ask the JUnit people whether they really MEAN
>> what they clearly wrote...?
>>
>> -Markus
>>
>> -Ursprüngliche Nachricht-
>> Von: Martin Gainty [mailto:mgai...@hotmail.com]
>> Gesendet: Montag, 17. August 2020 12:27
>> An: Maven Developers List
>> Betreff: Re: Assumption fail treated as unexcepted exception?!
>>
>>
>>/**
>>  * Call to assume that actual satisfies the condition
>> specified by matcher.
>>  * If not, the test halts and is ignored.
>>  * Example:
>>  * :
>>  *   assumeThat(1, is(1)); // passes
>>  *   foo(); // will execute
>>  *   assumeThat(0, is(1)); // assumption failure! test halts
>>  *   int x = 1 / 0; // will never execute
>>  * 
>>  *
>>  * @param  the static type accepted by the matcher (this can flag
>> obvious compile-time problems such as {@code assumeThat(1, is("a"))}
>>  * @param actual the computed value being compared
>>  * @param matcher an expression, built of {@link Matcher}s, specifying
>> allowed values
>>  * @see org.hamcrest.CoreMatchers
>>  * @see org.junit.matchers.JUnitMatchers
>>  */
>> public static  void assumeThat(T actual, Matcher matcher) {
>> if (!matcher.matches(actual)) {
>> throw new AssumptionViolatedException(actual, matcher);
>> }
>> }
>>
>> //does AssumptionViolatedException ever produce test case failure?
>>
>> /**
>>  * An exception class used to implement assumptions (state in
>> which a
>> given test
>>  * is meaningful and should or should not be executed). A test for which
>> an
>> assumption
>>  * fails should not generate a test case failure.
>>  *
>>  * @see org.junit.Assume
>>  * @since 4.12
>>  */
>> @SuppressWarnings("deprecation")
>> public class AssumptionViolatedException extends
>> org.junit.internal.AssumptionViolatedException {
>> private static final long serialVersionUID = 1L;
>>
>> /**
>>  * An assumption exception wi

AW: Assumption fail treated as unexcepted exception?!

[Markus KARG]

cher}.
 *
 * @deprecated Please use {@link org.junit.AssumptionViolatedException}
instead.
 */
@Deprecated
public AssumptionViolatedException(String assumption, Object value,
Matcher matcher) {
this(assumption, true, value, matcher);
}

/**
 * An assumption exception with the given message only.
 *
 * @deprecated Please use {@link org.junit.AssumptionViolatedException}
instead.
 */
@Deprecated
public AssumptionViolatedException(String assumption) {
this(assumption, false, null, null);
}

/**
 * An assumption exception with the given message and a cause.
 *
 * @deprecated Please use {@link org.junit.AssumptionViolatedException}
instead.
 */
@Deprecated
public AssumptionViolatedException(String assumption, Throwable e) {
this(assumption, false, null, null);
initCause(e);
}

@Override
public String getMessage() {
return StringDescription.asString(this);
}

public void describeTo(Description description) {
if (fAssumption != null) {
description.appendText(fAssumption);
}

if (fValueMatcher) {
// a value was passed in when this instance was constructed;
print it
if (fAssumption != null) {
description.appendText(": ");
}

description.appendText("got: ");
description.appendValue(fValue);

if (fMatcher != null) {
description.appendText(", expected: ");
description.appendDescriptionOf(fMatcher);
}
}
}
}

//at least with junit 4.12 if AssumptionViolatedException will not FAIL the
test-case
//AssumptionViolatedException falls between the exception-handlers to
produce ERROR

can you verify with junit author(s) AssumptionViolatedException  does not
FAIL test-case is intended behaviour?
martin







From: Markus KARG 
Sent: Sunday, August 16, 2020 1:39 PM
To: 'Maven Developers List' 
Subject: AW: Assumption fail treated as unexcepted exception?!

The debug output is quite huge, so I won't put it here. What in particular
shall I lookup inside of that? The environment is:

Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T21:00:29+02:00)
Maven home: C:\Program Files\apache-maven-3.6.1
Java version: 1.8.0_212, vendor: Azul Systems, Inc., runtime: C:\Program
Files\zulu8.38.0.13-ca-jdk8.0.212-win_x64\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
...
[DEBUG] Goal:
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test)
[DEBUG] Style: Regular
[DEBUG] Configuration: 


${maven.test.additionalClasspath}
  -Xmx384m
  
  ${childDelegation}
  

${maven.test.dependency.excludes}
  ${maven.surefire.debug}
  ${dependenciesToScan}
  ${disableXmlReport}
  ${enableAssertions}
  ${surefire.encoding}
  
true
  
  ${excludedGroups}
  ${surefire.excludesFile}

${surefire.failIfNoSpecifiedTests}
  ${failIfNoTests}
  ${forkCount}
  ${forkMode}
  ${surefire.exitTimeout}

${surefire.timeout}
  ${groups}
  ${surefire.includesFile}
  ${junitArtifactName}
  ${junitPlatformArti
factName}
  ${jvm}
  
  ${objectFactory}
  ${parallel}
  
  ${parallelOptimized}

${surefire.parallel.forcedTimeout}

${surefire.parallel.timeout}
  ${perCoreThreadCount}
  ${plugin.artifactMap}
  
  ${surefire.printSummary}
  ${project.artifactMap}
  
  ${maven.test.redirectTestOutputToFile}
  
  ${surefire.reportFormat}
  ${surefire.reportNameSuffix}
  
  ${surefire.rerunFailingTestsCount}
  ${reuseForks}
  ${surefire.runOrder}
  ${surefire.shutdown}
  ${maven.test.skip}
  ${surefire.skipAfterFailureCount}
  ${maven.test.skip.exec}
  ${skipTests}
  ${surefire.suiteXmlFiles}
  
C:\Program Files\apache-maven-3.6.1
  
  ${tempDir}
  ${test}
  
  ${maven.test.failure.ignore}
  ${testNGArtifactName}
  
  ${threadCount}
  ${threadCountClasses}
  ${threadCountMethods}
  ${threadCountSuites}
  ${trimStackTrace}
  ${surefire.useFile}
  ${surefire.useManifestOnlyJar}
  ${surefire.useSystemClassLoader}
  ${useUnlimitedThreads}
  ${basedir}
  
  

...
[ERROR]
testProofClaim(org.apache.maven.plugins.dependency.fromConfiguration.TestCop
yMojo)  Time elapsed: 0.146 s  <<< ERROR!
org.junit.AssumptionViolatedException: always skip
at
org.apache.maven.plugins.dependency.fromConfiguration.TestCopyMojo.testProof
Claim(TestCopyMojo.java:76)
...

IIUC, Maven debug doesn't contain any really specific information besides
what I aready assumed: Surefire treats org.junit.AssumptionViolatedException
as an error but not as a request to skip the test.

This can be reproduced with this really simple test case:
https://github.com/mkarg/maven-dependency-plugin/commit/af257d7987fc41ac4377
4d2dca60b201979d11a2 - as you can see, I just ask JUni

AW: Assumption fail treated as unexcepted exception?!

[Markus KARG]

So the bug is that Maven Dependency Plugin's test suite uses the JUnit 4 
library for test-compile, but actually executes the tests using JUnit 3, right?

-Markus


-Ursprüngliche Nachricht-
Von: Tibor Digana [mailto:tibordig...@apache.org] 
Gesendet: Montag, 17. August 2020 14:09
An: Maven Developers List
Betreff: Re: Assumption fail treated as unexcepted exception?!

Yes Piotr, this is another example why Markus has these unpleasant
experiences with JUnit3.
The code with JUnit4 annotation should be fine.

On Mon, Aug 17, 2020 at 1:34 PM Piotr Żygieło 
wrote:

> Please note, that TestCopyMojo is considered as JUnit3 TestCase
> (
> https://github.com/junit-team/junit4/blob/3a5c6b4d08f408c8ca6a8e0bae71a9bc5a8f97e8/src/main/java/org/junit/internal/builders/JUnit3Builder.java#L17
> ).
> So perhaps JUnit4+ features are not to be expected in such a case?
>
> -
> 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

AW: Assumption fail treated as unexcepted exception?!

[Markus KARG]

Just to make clear: *I* did not add *anything* to make it go wrong -- I just 
execute the existing Maven Dependency Plugin's test suite into which I added an 
assumption. Neither did I write that plugin nor its tests nor its POM. Just to 
clarify that.

-Markus


-Ursprüngliche Nachricht-
Von: Tibor Digana [mailto:tibordig...@apache.org] 
Gesendet: Montag, 17. August 2020 13:27
An: Maven Developers List
Betreff: Re: Assumption fail treated as unexcepted exception?!

yes it should be marked Skipped.
Many factors may turn this. As for instance I have these experiences with
Powermock which always fails the test in IntelliJ IDEA even if the
assumption fails.
Check it out with almost empty POM and a trivial test and compare the
outcome with the one you have attached. And then you will maybe see more.

@Test
public void test() {
 assumeTrue(false);
}

This code should work with JUnit 4.12 and whatever plugin version.
Turn this code to your specifics one by one and you will see what you have
added necessarily has changed the behavior.

T





On Sun, Aug 16, 2020 at 1:40 PM Markus KARG  wrote:

> Guys,
>
>
>
> I'm stuck with working on a new feature due to this, so I hope you can help
> me quickly:
>
>
>
> JUnit knows assumptions, assertions and exceptions. Failing assertions will
> FAIL tests (hence will fail maven builds). Failing assumptions will SKIP
> tests (hence will pass maven builds). Exceptions will ERROR tests (hence
> will break maven builds). Unfortunately today I noticed that assumptions
> actually ERROR test (hence fail builds) in Maven!
>
>
>
> (I simply added another test to maven dependency plugin which contains an
> always-failing assumption to proof the claim)
>
>
>
> [INFO] Results:
>
> [INFO]
>
> [ERROR] Errors:
>
> [ERROR]   TestCopyMojo.proofClaim:274 ┐ AssumptionViolated always skip
>
> [INFO]
>
> [ERROR] Tests run: 257, Failures: 0, Errors: 1, Skipped: 0
>
>
>
> It seems maven treats JUnit assumptions just like JUnit exceptions! :-(
>
>
>
> Can someone tell my why that happens? Do I have to set some option tell
> Maven it shall SKIP instead of ERROR on failing assumptions?!
>
>
>
> Thanks in advance!
>
> -Markus Karg
>
>
>
>


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

AW: Assumption fail treated as unexcepted exception?!

[Markus KARG]

Please see my answer to Martin Gainty, it proofs there is no NPE but 
AssumptionViolatedException. It is a wrong assumption that all thrown 
exceptions lead to test fail. It is JUnit's normal behavior that 
Assume.assumeTrue(false) will throw AssumptionViolatedException, so that one 
explicitly needs special treatment to skip the test, as this is the intention 
of that JUnit API.
-Markus


-Ursprüngliche Nachricht-
Von: John Patrick [mailto:nhoj.patr...@gmail.com] 
Gesendet: Sonntag, 16. August 2020 14:47
An: Maven Developers List
Betreff: Re: Assumption fail treated as unexcepted exception?!

If the code working out the assumption fails and causes a throwable,
either Runtime or Checked, I would expect the test to fail.
If you have a line something like below, and that causes a test error,
then that feels wrong as it's a valid assumption.
Assumptions.assumeFalse("ABC".equals("ABC"), "message");

But if you had below, which would throw an NPE, then that should error
as it's a badly coded assumption logic.
String IS_NULL = null;
Assumptions.assumeFalse(IS_NULL.equals("ABC"), "message");

So without seeing the test involved it's hard to tell if it's correct or not.

John

On Sun, 16 Aug 2020 at 13:31, Martin Gainty  wrote:
>
> MG>below
>
> 
> From: Markus KARG 
> Sent: Sunday, August 16, 2020 7:40 AM
> To: dev@maven.apache.org 
> Subject: Assumption fail treated as unexcepted exception?!
>
> Guys,
>
>
>
> I'm stuck with working on a new feature due to this, so I hope you can help
> me quickly:
>
>
>
> JUnit knows assumptions, assertions and exceptions. Failing assertions will
> FAIL tests (hence will fail maven builds). Failing assumptions will SKIP
> tests (hence will pass maven builds). Exceptions will ERROR tests (hence
> will break maven builds). Unfortunately today I noticed that assumptions
> actually ERROR test (hence fail builds) in Maven!
>
>
>
> (I simply added another test to maven dependency plugin which contains an
> always-failing assumption to proof the claim)
>
>
>
> [INFO] Results:
>
> [INFO]
>
> [ERROR] Errors:
>
> [ERROR]   TestCopyMojo.proofClaim:274 ┐ AssumptionViolated always skip
>
> MG>get maven environment and debug information
> MG>mvn -e -X
> MG>also I know Junit 5.4.2 needs Hamcrest to be on classpath
> MG>can you tell us which version of Junit you are using?
>
> -Markus Karg
> ~gruss~
> ~martin~
>
>
>
>
>

-
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

AW: Assumption fail treated as unexcepted exception?!

[Markus KARG]

The debug output is quite huge, so I won't put it here. What in particular
shall I lookup inside of that? The environment is:

Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T21:00:29+02:00)
Maven home: C:\Program Files\apache-maven-3.6.1
Java version: 1.8.0_212, vendor: Azul Systems, Inc., runtime: C:\Program
Files\zulu8.38.0.13-ca-jdk8.0.212-win_x64\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
...
[DEBUG] Goal:
org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test)
[DEBUG] Style: Regular
[DEBUG] Configuration: 

 
${maven.test.additionalClasspath}
  -Xmx384m
  
  ${childDelegation}
  
 
${maven.test.dependency.excludes}
  ${maven.surefire.debug}
  ${dependenciesToScan}
  ${disableXmlReport}
  ${enableAssertions}
  ${surefire.encoding}
  
true
  
  ${excludedGroups}
  ${surefire.excludesFile}
 
${surefire.failIfNoSpecifiedTests}
  ${failIfNoTests}
  ${forkCount}
  ${forkMode}
  ${surefire.exitTimeout}
 
${surefire.timeout}
  ${groups}
  ${surefire.includesFile}
  ${junitArtifactName}
  ${junitPlatformArti
factName}
  ${jvm}
  
  ${objectFactory}
  ${parallel}
  
  ${parallelOptimized}
 
${surefire.parallel.forcedTimeout}
 
${surefire.parallel.timeout}
  ${perCoreThreadCount}
  ${plugin.artifactMap}
  
  ${surefire.printSummary}
  ${project.artifactMap}
  
  ${maven.test.redirectTestOutputToFile}
  
  ${surefire.reportFormat}
  ${surefire.reportNameSuffix}
  
  ${surefire.rerunFailingTestsCount}
  ${reuseForks}
  ${surefire.runOrder}
  ${surefire.shutdown}
  ${maven.test.skip}
  ${surefire.skipAfterFailureCount}
  ${maven.test.skip.exec}
  ${skipTests}
  ${surefire.suiteXmlFiles}
  
C:\Program Files\apache-maven-3.6.1
  
  ${tempDir}
  ${test}
  
  ${maven.test.failure.ignore}
  ${testNGArtifactName}
  
  ${threadCount}
  ${threadCountClasses}
  ${threadCountMethods}
  ${threadCountSuites}
  ${trimStackTrace}
  ${surefire.useFile}
  ${surefire.useManifestOnlyJar}
  ${surefire.useSystemClassLoader}
  ${useUnlimitedThreads}
  ${basedir}
  
  

...
[ERROR]
testProofClaim(org.apache.maven.plugins.dependency.fromConfiguration.TestCop
yMojo)  Time elapsed: 0.146 s  <<< ERROR!
org.junit.AssumptionViolatedException: always skip
at
org.apache.maven.plugins.dependency.fromConfiguration.TestCopyMojo.testProof
Claim(TestCopyMojo.java:76)
...

IIUC, Maven debug doesn't contain any really specific information besides
what I aready assumed: Surefire treats org.junit.AssumptionViolatedException
as an error but not as a request to skip the test.

This can be reproduced with this really simple test case:
https://github.com/mkarg/maven-dependency-plugin/commit/af257d7987fc41ac4377
4d2dca60b201979d11a2 - as you can see, I just ask JUnit 4.13 to fail the
assumptions, and JUnit CORRECTLY throws AssumptionViolatedException - but
Maven seems to not specifically deal with it.

-Markus
 

-Ursprüngliche Nachricht-
Von: Martin Gainty [mailto:mgai...@hotmail.com] 
Gesendet: Sonntag, 16. August 2020 14:24
An: Maven Developers List
Betreff: Re: Assumption fail treated as unexcepted exception?!

MG>below


From: Markus KARG 
Sent: Sunday, August 16, 2020 7:40 AM
To: dev@maven.apache.org 
Subject: Assumption fail treated as unexcepted exception?!

Guys,



I'm stuck with working on a new feature due to this, so I hope you can help
me quickly:



JUnit knows assumptions, assertions and exceptions. Failing assertions will
FAIL tests (hence will fail maven builds). Failing assumptions will SKIP
tests (hence will pass maven builds). Exceptions will ERROR tests (hence
will break maven builds). Unfortunately today I noticed that assumptions
actually ERROR test (hence fail builds) in Maven!



(I simply added another test to maven dependency plugin which contains an
always-failing assumption to proof the claim)



[INFO] Results:

[INFO]

[ERROR] Errors:

[ERROR]   TestCopyMojo.proofClaim:274 ┐ AssumptionViolated always skip

MG>get maven environment and debug information
MG>mvn -e -X
MG>also I know Junit 5.4.2 needs Hamcrest to be on classpath
MG>can you tell us which version of Junit you are using?

-Markus Karg
~gruss~
~martin~







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

AW: Assumption fail treated as unexcepted exception?!

[Markus KARG]

Happens with surefire 2.22.0 (but also with 3.0.0-M5, just tried it).

Just added the assumption, did not otherwise touch any config properties, but 
maybe maven dependency plugin's existing build does that (haven't read the 
complete source). Any clue which property to search for which could produce 
that?

Thanks
-Markus

-Ursprüngliche Nachricht-
Von: Falko Modler [mailto:f.mod...@gmx.net] 
Gesendet: Sonntag, 16. August 2020 13:53
An: dev@maven.apache.org
Betreff: Assumption fail treated as unexcepted exception?!

Which surefire plugin version? Have you set any config properties?

Cheers,

Falko


-
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

Assumption fail treated as unexcepted exception?!

[Markus KARG]

Guys,

 

I'm stuck with working on a new feature due to this, so I hope you can help
me quickly:

 

JUnit knows assumptions, assertions and exceptions. Failing assertions will
FAIL tests (hence will fail maven builds). Failing assumptions will SKIP
tests (hence will pass maven builds). Exceptions will ERROR tests (hence
will break maven builds). Unfortunately today I noticed that assumptions
actually ERROR test (hence fail builds) in Maven!

 

(I simply added another test to maven dependency plugin which contains an
always-failing assumption to proof the claim)

 

[INFO] Results:

[INFO]

[ERROR] Errors:

[ERROR]   TestCopyMojo.proofClaim:274 ┐ AssumptionViolated always skip

[INFO]

[ERROR] Tests run: 257, Failures: 0, Errors: 1, Skipped: 0

 

It seems maven treats JUnit assumptions just like JUnit exceptions! :-(

 

Can someone tell my why that happens? Do I have to set some option tell
Maven it shall SKIP instead of ERROR on failing assumptions?!

 

Thanks in advance!

-Markus Karg

 

AW: AW: Maven intern projects

[Markus KARG]

Yes, it might be hard work, and yes, it implies discussions, and yes, currently 
only few people benefit from it.

But we need to understand to look on Maven from the side of Java 14 coders (and 
from day to day they will become more people):
* Maven has default support for totally outdated Java version.
* Maven has no native support for some Java 9 features (like this one).
* Java 9 is around for many years.
* The current LTS is Java 11, which is around for years, too.
* To sum up: From the point of *modern* users, with every day of not supporting 
these features, Maven becomes more and more NOT the best choice for them.

We should not further focus on making old things run better, but start 
investing in becoming the best build tool for Java 14 again.

-Markus


-Ursprüngliche Nachricht-
Von: Robert Scholte [mailto:rfscho...@apache.org] 
Gesendet: Montag, 13. April 2020 21:39
An: dev@maven.apache.org
Betreff: Re: AW: Maven intern projects

the problem is that with every folder you'll need a separate execution-block of 
the maven-compiler-plugin. 
I've tried to solve within a single execution block, but that made it worse and 
impossible to manage.
In the end having 1 execution block for every javac call makes sense.

Multirelease jars are only interesting for libraries, I would not advice to do 
this for applications.
So you might expect from library maintainer that they are experienced Java / 
Maven users, so I don't mind that they need to specify multiple execution 
blocks.

https://github.com/metlos/multi-release-jar-maven-plugin was an attempt to do 
what you want: 1 execution block.

However, he confirmed he did not solve the testing part.

IF you want to solve this, you need to make clear separations of what should be 
solved by Maven and what by the maven-compiler-plugin:
- Maven should make it possible to register multiple execution blocks by 
plugins *dynamically* (only the maven-compiler-plugin should be aware of all 
the source folders and the requirements per folder).

It is really not that easy and the number of users will be low.
I would invest in other issues.

Robert
On 13-4-2020 19:43:44, Markus KARG  wrote:
What users finally expect is to have multirelease JAR building being a Maven 
native functionality. This means, it should be as-easy-as putting code in these 
folders:

src/main/java/9/
src/main/java/
src/main/java/11/

then perform

mvn clean package

to get a multi-release jar -- without *any* special switches, config, or 
POM.xml tweaking, and *all* maven-*-plugins will perform the necessary steps on 
their own (e. g. compiler runs multiple times as the compiler plugins knows 
this is needed when it sees /java/number/ folders).

-Markus

-Ursprüngliche Nachricht-
Von: Elliotte Rusty Harold [mailto:elh...@ibiblio.org]
Gesendet: Montag, 13. April 2020 19:02
An: Maven Developers List
Betreff: Re: Maven intern projects

On Mon, Apr 13, 2020 at 11:50 AM Robert Scholte wrote:
>
> Just to be clear: Multirelease jars is a JDK 9+ feature. With Maven it is 
> possible to make them, to test them and to run them. But they are pretty hard 
> to maintain.
> So I would prefer NOT to try make Multirelease Jars of our libraries, unless 
> there's a very good reason.

Yes, that's what I was thinking. Have we documented anywhere how to
make multirelease jars with Maven? My impression from googling was
that this doesn't work yet, but I guess that's not true?

What improvements could we make to improve the workflow for multimodule builds?

> If there is one thing that should be solved, but requires a lot of time, it 
> is support of ServicesLoaders
> https://issues.apache.org/jira/browse/MNG-6275
>

Thanks. I'll look at that.

I did a review pass through the issue tracker. So far these are the
ones I've found that look like they might make parts of plausible
intern level projects:

https://issues.apache.org/jira/browse/MDEP-644?jql=labels%20%3D%20intern

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



-
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

AW: Maven intern projects

[Markus KARG]

What users finally expect is to have multirelease JAR building being a Maven 
native functionality. This means, it should be as-easy-as putting code in these 
folders:

src/main/java/9/
src/main/java/
src/main/java/11/

then perform

mvn clean package

to get a multi-release jar -- without *any* special switches, config, or 
POM.xml tweaking, and *all* maven-*-plugins will perform the necessary steps on 
their own (e. g. compiler runs multiple times as the compiler plugins knows 
this is needed when it sees /java/number/ folders).

-Markus

-Ursprüngliche Nachricht-
Von: Elliotte Rusty Harold [mailto:elh...@ibiblio.org] 
Gesendet: Montag, 13. April 2020 19:02
An: Maven Developers List
Betreff: Re: Maven intern projects

On Mon, Apr 13, 2020 at 11:50 AM Robert Scholte  wrote:
>
> Just to be clear: Multirelease jars is a JDK 9+ feature. With Maven it is 
> possible to make them, to test them and to run them. But they are pretty hard 
> to maintain.
> So I would prefer NOT to try make Multirelease Jars of our libraries, unless 
> there's a very good reason.

Yes, that's what I was thinking. Have we documented anywhere how to
make multirelease jars with Maven? My impression from googling was
that this doesn't work yet, but I guess that's not true?

What improvements could we make to improve the workflow for multimodule builds?

> If there is one thing that should be solved, but requires a lot of time, it 
> is support of ServicesLoaders
> https://issues.apache.org/jira/browse/MNG-6275
>

Thanks. I'll look at that.

I did a review pass through the issue tracker. So far these are the
ones I've found that look like they might make parts of plausible
intern level projects:

https://issues.apache.org/jira/browse/MDEP-644?jql=labels%20%3D%20intern

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



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

AW: Maven intern projects

[Markus KARG]

Great to hear!

Here is my personal wish list. ;-)  

IMHO generally a good idea is to provide public releases of all maven plugins 
and mojohouse plugins which had not been release within 12 months, so we all 
can get rid of depending on -SNAPSHOTs and private forks. :-)

When asking for features particularly speeding up everything which has to do 
with file processing would be useful. I think we are not the only ones having 
build times in the area of minutes, where seconds would be cool. The main 
reason is (a) that Maven its underlying libraries (not yet) makes use of 
multi-version-JARs hence cannot make use of modern Java APIs like NIO where 
possible in an easy way but relies on API level 7 and older, and (b) that Maven 
copies files around a bit too much where linking and / or copy-on-write would 
be sufficient.

Having said this, it would be a really great feature to get an easy-to-use 
solution for creating multi-version-JARs.

-Markus

-Ursprüngliche Nachricht-
Von: Elliotte Rusty Harold [mailto:elh...@ibiblio.org] 
Gesendet: Freitag, 10. April 2020 16:13
An: Maven Developers List
Betreff: Maven intern projects

Due to external developments, I am suddenly able to recruit, fund, and
manage as many as five interns, probably undergraduates, to work on
open source projects such as Maven and its plugins for 12 weeks this
summer.

My management chain has a particular interest in reproducible builds,
so if there's work to be done on that, it would be a really easy sell.
However I can probably get approval for any useful project that can
plausibly be accomplished by a junior/senior CS major in 12 weeks. We
do like these to be feature projects, not simply refactoring or
maintenance.

If anyone has a good idea, or would simply like to point me to
particular issues in Jira that sound like good projects, let me know
and I can start the bureaucratic wheels turning on my end. As long as
the feature being proposed already has general agreement that it's a
good idea, I'll be able to do pretty much all the legwork for managing
the project(s). It shouldn't require any noticeable time from other
maintainers.

Let me know if you have any ideas.

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



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

AW: [RESULT] [VOTE] Release Apache Maven Dependency Plugin version 3.1.2

[Markus KARG]

Thanks! :-)
-Markus Karg

-Ursprüngliche Nachricht-
Von: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] 
Gesendet: Mittwoch, 11. März 2020 19:08
An: Maven Developers List
Cc: Maven Project Management Committee List
Betreff: [RESULT] [VOTE] Release Apache Maven Dependency Plugin version 3.1.2

Hi,

The vote has passed with the following result:

+1 : Hervé Boutemy, Tibor Digana, Olivier Lamy, Romain Manni-Bucau, Karl
Heinz Marbaise

PMC quorum: reached.

I will promote the artifacts to the central repo.

Kind regards
Karl Heinz Marbaise

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



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

AW: AW: [ANN] Apache Maven Shade Plugin 3.2.2 Released

[Markus KARG]

Hervé,

you won't believe how happy I actually am. Since more than one year I needed
to tell the audience of my conference talks to rebuild their custom plugin
just to get the few bug fixes I contributed long time ago (which are
essential in the Jakarta EE environment). Now finally I can simply tell
everybody: Use 3.2.2. A small step for the committers, but a bug step for
mankind!

We really need to go back to the Release Early Release Often mantra to
prevent situations like this in future! ;-)

-Markus


-Ursprüngliche Nachricht-
Von: Hervé BOUTEMY [mailto:herve.bout...@free.fr] 
Gesendet: Freitag, 14. Februar 2020 21:25
An: Maven Developers List
Betreff: Re: AW: [ANN] Apache Maven Shade Plugin 3.2.2 Released

thanks for the positive feedback :)

Le vendredi 14 février 2020, 17:02:36 CET Markus KARG a écrit :
> Yippi! :-)
> 
> -Ursprüngliche Nachricht-
> Von: Hervé Boutemy [mailto:hbout...@apache.org]
> Gesendet: Donnerstag, 13. Februar 2020 22:03
> An: annou...@maven.apache.org; us...@maven.apache.org;
dev@maven.apache.org
> Betreff: [ANN] Apache Maven Shade Plugin 3.2.2 Released
> 
> The Apache Maven team is pleased to announce the release of the Apache
Maven
> Shade Plugin, version 3.2.2
> 
> This plugin provides the capability to package the artifact in an
uber-jar,
> including its dependencies and to shade - i.e. rename - the packages of
some
> of the dependencies.
> 
> https://maven.apache.org/plugins/maven-shade-plugin/
> 
> You should specify the version in your project's plugin configuration:
> 
> 
>   org.apache.maven.plugins
>   maven-shade-plugin
>   3.2.2
> 
> 
> You can download the appropriate sources etc. from the download page:
> 
> https://maven.apache.org/plugins/maven-shade-plugin/download.cgi
> 
> 
> Release Notes - Maven Shade Plugin - Version 3.2.2
> 
> ** Bug
> * [MSHADE-223] - Endless processing when
> promoteTransitiveDependencies=true
> * [MSHADE-284] - Shaded test JARs are always empty
> * [MSHADE-291] - shadedPattern applied multiples times when relocating
> the contents of META-INF/services files
> * [MSHADE-298] - Groovy extension module transformer looking in
> incorrect META-INF directory
> * [MSHADE-309] - issue tracker link on the web site of shade plugin
does
> not work.
> * [MSHADE-311] - Bad exclusions in dependency-reduced-pom.xml
> * [MSHADE-315] - Broken link on Maven Shade Plugin
> * [MSHADE-318] - Specifically included class's dependencies are
missing
> * [MSHADE-331] - Issue Tracker link is not working - Page Not Found
> * [MSHADE-337] - Relocation cannot process class file version 58 JARs
> * [MSHADE-339] - Shaded test jar has wrong type "jar"
> * [MSHADE-340] - Shaded test jar artifact is not attached
> 
> ** New Feature
> * [MSHADE-306] - Log all duplicates, not only classes
> * [MSHADE-347] - Reproducible Builds: make entries in output jar files
> reproducible
> 
> ** Improvement
> * [MSHADE-285] - It should be possible to shade test sources as a JAR
> * [MSHADE-313] - Minimize jar should respect implementations under
> /META-INF/services/
> * [MSHADE-316] - Minijar: true
> * [MSHADE-319] - Group output into included and excluded artifacts to
> easily identify them
> * [MSHADE-348] - Make build Reproducible
> 
> ** Test
> * [MSHADE-327] - improved integration test coverage for relocation and
> minification
> 
> ** Task
> * [MSHADE-322] - Provide a transformer for properties files
> * [MSHADE-330] - Java 12 and 13 support
> * [MSHADE-346] - Introduce mock repository manager for testing
> * [MSHADE-350] - Enable ManifestResourceTransformer to rewrite the
> manifest with relocations
> 
> ** Dependency upgrade
> * [MSHADE-320] - Upgrade maven-artifact-transfer to 0.11.0
> * [MSHADE-338] - Upgrade maven-artifact-transfer 0.12.0
> * [MSHADE-341] - Upgrade plexus-utils 3.3.0
> * [MSHADE-349] - Upgrade to org.ow2.asm:asm:7.3.1
> 
> 
> Enjoy,
> 
> -The Apache Maven team
> 
> 
> 
> -
> 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



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

AW: [ANN] Apache Maven Shade Plugin 3.2.2 Released

[Markus KARG]

Yippi! :-)

-Ursprüngliche Nachricht-
Von: Hervé Boutemy [mailto:hbout...@apache.org] 
Gesendet: Donnerstag, 13. Februar 2020 22:03
An: annou...@maven.apache.org; us...@maven.apache.org; dev@maven.apache.org
Betreff: [ANN] Apache Maven Shade Plugin 3.2.2 Released

The Apache Maven team is pleased to announce the release of the Apache Maven
Shade Plugin, version 3.2.2
 
This plugin provides the capability to package the artifact in an uber-jar,
including its dependencies and to shade - i.e. rename - the packages of some
of the dependencies.
 
https://maven.apache.org/plugins/maven-shade-plugin/
 
You should specify the version in your project's plugin configuration:
 

  org.apache.maven.plugins
  maven-shade-plugin
  3.2.2

 
You can download the appropriate sources etc. from the download page:
 
https://maven.apache.org/plugins/maven-shade-plugin/download.cgi
 

Release Notes - Maven Shade Plugin - Version 3.2.2

** Bug
* [MSHADE-223] - Endless processing when
promoteTransitiveDependencies=true
* [MSHADE-284] - Shaded test JARs are always empty
* [MSHADE-291] - shadedPattern applied multiples times when relocating
the contents of META-INF/services files
* [MSHADE-298] - Groovy extension module transformer looking in
incorrect META-INF directory
* [MSHADE-309] - issue tracker link on the web site of shade plugin does
not work.
* [MSHADE-311] - Bad exclusions in dependency-reduced-pom.xml
* [MSHADE-315] - Broken link on Maven Shade Plugin
* [MSHADE-318] - Specifically included class's dependencies are missing
* [MSHADE-331] - Issue Tracker link is not working - Page Not Found
* [MSHADE-337] - Relocation cannot process class file version 58 JARs
* [MSHADE-339] - Shaded test jar has wrong type "jar"
* [MSHADE-340] - Shaded test jar artifact is not attached

** New Feature
* [MSHADE-306] - Log all duplicates, not only classes
* [MSHADE-347] - Reproducible Builds: make entries in output jar files
reproducible

** Improvement
* [MSHADE-285] - It should be possible to shade test sources as a JAR
* [MSHADE-313] - Minimize jar should respect implementations under
/META-INF/services/
* [MSHADE-316] - Minijar: true
* [MSHADE-319] - Group output into included and excluded artifacts to
easily identify them
* [MSHADE-348] - Make build Reproducible

** Test
* [MSHADE-327] - improved integration test coverage for relocation and
minification

** Task
* [MSHADE-322] - Provide a transformer for properties files
* [MSHADE-330] - Java 12 and 13 support
* [MSHADE-346] - Introduce mock repository manager for testing
* [MSHADE-350] - Enable ManifestResourceTransformer to rewrite the
manifest with relocations

** Dependency upgrade
* [MSHADE-320] - Upgrade maven-artifact-transfer to 0.11.0
* [MSHADE-338] - Upgrade maven-artifact-transfer 0.12.0
* [MSHADE-341] - Upgrade plexus-utils 3.3.0
* [MSHADE-349] - Upgrade to org.ow2.asm:asm:7.3.1

 
Enjoy,
 
-The Apache Maven team



-
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

AW: Releasing Maven Shade Plugin

[Markus KARG]

+1 :-)

-Ursprüngliche Nachricht-
Von: Hervé BOUTEMY [mailto:herve.bout...@free.fr] 
Gesendet: Samstag, 8. Februar 2020 21:53
An: Maven Developers List
Betreff: Re: Releasing Maven Shade Plugin

perfect plan: everything seems ready for the immediate release, the rest
will 
come in a few months

I'll start the release process

Regards,

Hervé

Le samedi 8 février 2020, 10:44:15 CET Robert Scholte a écrit :
> I wanted to wait for the next release for ASM, which will be released at
the
> same time as Java 14. That would give me enough time to wipe out a lot of
> open issues.
> e.g. MSHADE-202 requires a release of dependency-tree, so that one needs
to
> be released too. Still having a discussion about MSHADE-350, not up to me
> to decide if it can wait.
> 
> There are more people waiting, so let's do one now and another in like 2-3
> months.
> 
> Robert
> On 8-2-2020 00:47:19, Hervé BOUTEMY  wrote:
> I'd like to release this plugin: anything to add before the release?
> 
> Regards,
> 
> Hervé
> 
> 
> 
> -
> 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

AW: Releasing Maven Shade Plugin

[Markus KARG]

+1 ! :-)

Nothing to add from my side.

-Markus


-Ursprüngliche Nachricht-
Von: Hervé BOUTEMY [mailto:herve.bout...@free.fr] 
Gesendet: Samstag, 8. Februar 2020 00:47
An: Maven Developers List
Betreff: Releasing Maven Shade Plugin

I'd like to release this plugin: anything to add before the release?

Regards,

Hervé



-
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

Please Release Maven Dependency Plugin 3.1.2

[Markus KARG]

I desperately wait for publication of Maven Dependency Plugin v3.1.2. v3.1.1
was release in 2018 already, which is more than one year ago. There are
several features I desperately need to use in production, so I kindly like
to ask what the plan for releasing 3.1.2 is. Thanks.

-Markus

 

Please consider PR

[Markus KARG]

Dear Committers,

 

I'd kindly like to ask for consideration of my PR:

 

http://github.com/apache/maven-shared/pull/12

 

Regards

-Markus

RE: Please consider my PRs :-)

[Markus KARG]

The plugin that was the origin of my plexus-util changes still uses 
plexus-utils, but thanks for letting me know, I actually did not know that.

-Original Message-
From: Jochen Wiedmann [mailto:jochen.wiedm...@gmail.com] 
Sent: Sonntag, 12. Juni 2016 20:16
To: Maven Developers List
Cc: mar...@headcrashing.eu
Subject: Re: Please consider my PRs :-)

Hello, Markus,

are you aware, that plexus-utils is being replaced by the maven-shared-utils?

Jochen


On Sun, Jun 12, 2016 at 6:03 PM, Markus KARG <mar...@headcrashing.eu> wrote:
> Hello Maven Committers,
>
>
>
> I would like to kindly ask to consider my PRs for merging:
>
>
>
> * Plexus Utils: https://github.com/codehaus-plexus/plexus-utils/pull/12
>
> * Plexus Utils: https://github.com/codehaus-plexus/plexus-utils/pull/13
>
> * Maven Plugins: https://github.com/apache/maven-plugins/pull/86
>
>
>
> Thanks!
>
> -Markus
>



-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg


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

Please consider my PRs :-)

[Markus KARG]

Hello Maven Committers,

 

I would like to kindly ask to consider my PRs for merging:

 

* Plexus Utils: https://github.com/codehaus-plexus/plexus-utils/pull/12

* Plexus Utils: https://github.com/codehaus-plexus/plexus-utils/pull/13

* Maven Plugins: https://github.com/apache/maven-plugins/pull/86

 

Thanks!

-Markus

[MDEP] [trunk] Test fails on Windows 7

[Markus Karg]

We're new to this mailing list and need your organizational advice.

Tried to build MDEP (trunk, no local changes) on Windows 7 (64 Bit) JDK 8u40, 
which fails:

testcase name=testResolveFile 
classname=org.apache.maven.plugin.dependency.utils.filters.TestResolveMarkerFileFilter
 time=0.005
  error message=Unable to create Marker: C:\Users\Markus 
Karg\workspace\maven-dependency-plugin\target\markers\testGroupId-release-jar-1.0.unresolved
 
type=org.apache.maven.plugin.MojoExecutionExceptionorg.apache.maven.plugin.MojoExecutionException:
 Unable to create Marker: C:\Users\Markus 
Karg\workspace\maven-dependency-plugin\target\markers\testGroupId-release-jar-1.0.unresolved
   at java.io.WinNTFileSystem.createFileExclusively(Native Method)
   at java.io.File.createNewFile(File.java:1012)
   at 
org.apache.maven.plugin.dependency.utils.markers.SourcesFileMarkerHandler.setMarker(SourcesFileMarkerHandler.java:146)
   at 
org.apache.maven.plugin.dependency.utils.filters.TestResolveMarkerFileFilter.testResolveFile(TestResolveMarkerFileFilter.java:86)
  /error
/testcase

What to do now? Open a JIRA ticket for it as it is an unknown bug, or waiting 
for some of the core developers to chime in and tell us our user fault?

Thanks a lot!
-Markus

AW: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

[Markus Karg]

As a Maven user I think that everybody who is working on a project should 
behave the same. Hence, I would say, PMC members should rather certainly 
demonstrate how to live the community rules.

-Ursprüngliche Nachricht-
Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Gesendet: Donnerstag, 25. Juli 2013 15:16
An: Maven Users List; Maven Developers List
Betreff: [DISCUSS] Should the Maven PMC be an example of how we want the Maven 
Community to behave (was Re: svn commit: r1506778 - 
/maven/site/trunk/content/markdown/project-roles.md)

There are two schools of thought amongst the current members of this projects 
PMC.

Without wanting to deliberately tip my hand and reveal where my opinion is, we 
would like to solicit the opinions if the community that we serve.

Please give us your thoughts.

The topic is essentially:

Do you want the members of the Maven PMC to be social leaders of the Maven 
community, who's actions demonstrate the best community behaviour?

The alternative is that members of the Maven PMC are here purely to complete 
the legal requirements that an Apache TLP has delegated to PMCs

This is not black and white... The answer can be grey... And everyone is human 
so can make mistakes...

So community, what are you expecting?

- Stephen Connolly

On Thursday, 25 July 2013, wrote:

 Author: jdcasey
 Date: Wed Jul 24 23:21:58 2013
 New Revision: 1506778

 URL: http://svn.apache.org/r1506778
 Log:
 Adding section on PMC standards of community commitment

 Modified:
 maven/site/trunk/content/markdown/project-roles.md

 Modified: maven/site/trunk/content/markdown/project-roles.md
 URL:
 http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project
 -roles.md?rev=1506778r1=1506777r2=1506778view=diff

 ==
 
 --- maven/site/trunk/content/markdown/project-roles.md (original)
 +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24
 23:21:58 2013
 @@ -176,6 +176,29 @@ The Project Management Committee has the
  * Voting on release artifacts.
  * !-- TODO: get the rest of these --

 + Standards for Community Commitment
 +
 +In the spirit of supporting the health of our community, Project 
 +Management Committee members refrain from actions that subvert the 
 +functioning of the committee itself.
 +
 +First, Project Management Committee members should not maintain
 long-running
 +forks of Maven code outside of the project itself. Making significant 
 +changes to Maven code outside of the project displays a lack of 
 +investment in the community. Additionally, attempting to re-integrate 
 +a large number of code changes in bulk overwhelms the ability of 
 +volunteers in the community to review (and potentially veto) the 
 +changes. This effectively thwarts the policing function of the PMC.
 +
 +Second, Project Management Committee members should not divert work 
 +on redesigning, reimplementing, or improving Maven code to 
 +alternative projects outside of this community for the purposes of 
 +reintroducing them as replacement for existing Maven code. While 
 +there is a danger here of falling into a Not Invented Here mentality, 
 +new
 projects
 +created by Maven PMC members strictly to replace Maven code should 
 +not be allowed.
 +
  ### [Project Management Chair](
 http://www.apache.org/foundation/how-it-works.html#pmc-chair)

  For various legal reasons, there are certain things that the Apache




--
Sent from my phone

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

RE: Issue-wise Crowdfunding platform for Maven

[Markus KARG]

Just found it... It's a bit small and hidden due to the black colour.

 -Original Message-
 From: Markus KARG [mailto:mar...@headcrashing.eu]
 Sent: Sonntag, 15. Juli 2012 09:17
 To: 'Maven Users List'; dev@maven.apache.org
 Subject: RE: Issue-wise Crowdfunding platform for Maven
 
 Would be good if each funding item would contain a link to the
 particular item in the project's tracker, so it is easier to learn
 about the issue's details.
 
  -Original Message-
  From: tony Tony [mailto:t...@freedomsponsors.com]
  Sent: Freitag, 13. Juli 2012 22:38
  To: us...@maven.apache.org; dev@maven.apache.org
  Subject: Issue-wise Crowdfunding platform for Maven
 
  Hi all,
 
  I have set up a website where people can place small money bounties
  for open issues on Maven JIRA http://jira.codehaus.org/browse/MNG
  (or Jenkins, or Hibernate, or whatever).
 
  So far it's only got two real offers - and one of them I placed
 myself
  (JENKINS-9216:
  Make OpenID work with Google Apps
  accountshttp://www.freedomsponsors.com/core/issue/11/make-openid-
 work
  -
  with-google-apps-accounts
  ),
  but I really think that as it gets more popular, such a tool can have
  a big positive impact on a lot of open source projects, especially
  popular ones like Maven.
  If you think so too, I welcome you to use it --
  www.freedomsponsors.com :-)
 
  Cheers
  Tony Lâmpada
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



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

RE: Issue-wise Crowdfunding platform for Maven

[Markus KARG]

Would be good if each funding item would contain a link to the particular
item in the project's tracker, so it is easier to learn about the issue's
details.

 -Original Message-
 From: tony Tony [mailto:t...@freedomsponsors.com]
 Sent: Freitag, 13. Juli 2012 22:38
 To: us...@maven.apache.org; dev@maven.apache.org
 Subject: Issue-wise Crowdfunding platform for Maven
 
 Hi all,
 
 I have set up a website where people can place small money bounties for
 open issues on Maven JIRA http://jira.codehaus.org/browse/MNG (or
 Jenkins, or Hibernate, or whatever).
 
 So far it's only got two real offers - and one of them I placed myself
 (JENKINS-9216:
 Make OpenID work with Google Apps
 accountshttp://www.freedomsponsors.com/core/issue/11/make-openid-work-
 with-google-apps-accounts
 ),
 but I really think that as it gets more popular, such a tool can have a
 big positive impact on a lot of open source projects, especially
 popular ones like Maven.
 If you think so too, I welcome you to use it --
 www.freedomsponsors.com :-)
 
 Cheers
 Tony Lâmpada


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