[jira] [Updated] (MSHADE-460) Cannot find default constructor of record

[Markus Karg (Jira)]

 [ 
https://issues.apache.org/jira/browse/MSHADE-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Karg updated MSHADE-460:
---
Description: 
I have setup up a small demo project which uses JSONB to deserialize JSON into 
a Java record. The created JAR works fine when using java -cp with the full 
class-path as shown by mvn dependency:build-classpath. As soon as I am building 
an uberjar using the Maven Shade Plugin, at runtime I end up with an exception 
like "Cannot create instance of a class: class 
eu.headcrashing.jaxrsdoneright.sebootstrap.HelloWorld$TimeInfo, No default 
constructor found". I already replaced the contained record class file, but the 
result is the same. As it seems, besides merging services descriptors, there 
seems to be some more resource type to get merge – but which?! Possibly there 
is just something missing in the plugin's docs, possible we actually need to 
invent a new type of transformer.

(BTW, minimizeJar is false, and it works once using a class instead of a record)

  was:
I have setup up a small demo project which uses JSONB to deserialize JSON into 
a Java record. The created JAR works fine when using java -cp with the full 
class-path as shown by mvn dependency:build-classpath. As soon as I am building 
an uberjar using the Maven Shade Plugin, at runtime I end up with an exception 
like "Cannot create instance of a class: class 
eu.headcrashing.jaxrsdoneright.sebootstrap.HelloWorld$TimeInfo, No default 
constructor found". I already replaced the contained record class file, but the 
result is the same. As it seems, besides merging services descriptors, there 
seems to be some more resource type to get merge – but which?! Possibly there 
is just something missing in the plugin's docs, possible we actually need to 
invent a new type of transformer.

(BTW, minimizeJar is false)


> Cannot find default constructor of record
> -
>
> Key: MSHADE-460
> URL: https://issues.apache.org/jira/browse/MSHADE-460
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.5.1
>Reporter: Markus Karg
>Priority: Major
>
> I have setup up a small demo project which uses JSONB to deserialize JSON 
> into a Java record. The created JAR works fine when using java -cp with the 
> full class-path as shown by mvn dependency:build-classpath. As soon as I am 
> building an uberjar using the Maven Shade Plugin, at runtime I end up with an 
> exception like "Cannot create instance of a class: class 
> eu.headcrashing.jaxrsdoneright.sebootstrap.HelloWorld$TimeInfo, No default 
> constructor found". I already replaced the contained record class file, but 
> the result is the same. As it seems, besides merging services descriptors, 
> there seems to be some more resource type to get merge – but which?! Possibly 
> there is just something missing in the plugin's docs, possible we actually 
> need to invent a new type of transformer.
> (BTW, minimizeJar is false, and it works once using a class instead of a 
> record)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (MSHADE-460) Cannot find default constructor of record

[Markus Karg (Jira)]

 [ 
https://issues.apache.org/jira/browse/MSHADE-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Karg updated MSHADE-460:
---
Description: 
I have setup up a small demo project which uses JSONB to deserialize JSON into 
a Java record. The created JAR works fine when using java -cp with the full 
class-path as shown by mvn dependency:build-classpath. As soon as I am building 
an uberjar using the Maven Shade Plugin, at runtime I end up with an exception 
like "Cannot create instance of a class: class 
eu.headcrashing.jaxrsdoneright.sebootstrap.HelloWorld$TimeInfo, No default 
constructor found". I already replaced the contained record class file, but the 
result is the same. As it seems, besides merging services descriptors, there 
seems to be some more resource type to get merge – but which?! Possibly there 
is just something missing in the plugin's docs, possible we actually need to 
invent a new type of transformer.

(BTW, minimizeJar is false)

  was:I have setup up a small demo project which uses JSONB to deserialize JSON 
into a Java record. The created JAR works fine when using java -cp with the 
full class-path as shown by mvn dependency:build-classpath. As soon as I am 
building an uberjar using the Maven Shade Plugin, at runtime I end up with an 
exception like "Cannot create instance of a class: class 
eu.headcrashing.jaxrsdoneright.sebootstrap.HelloWorld$TimeInfo, No default 
constructor found". I already replaced the contained record class file, but the 
result is the same. As it seems, besides merging services descriptors, there 
seems to be some more resource type to get merge – but which?! Possibly there 
is just something missing in the plugin's docs, possible we actually need to 
invent a new type of transformer.


> Cannot find default constructor of record
> -
>
> Key: MSHADE-460
> URL: https://issues.apache.org/jira/browse/MSHADE-460
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.5.1
>Reporter: Markus Karg
>Priority: Major
>
> I have setup up a small demo project which uses JSONB to deserialize JSON 
> into a Java record. The created JAR works fine when using java -cp with the 
> full class-path as shown by mvn dependency:build-classpath. As soon as I am 
> building an uberjar using the Maven Shade Plugin, at runtime I end up with an 
> exception like "Cannot create instance of a class: class 
> eu.headcrashing.jaxrsdoneright.sebootstrap.HelloWorld$TimeInfo, No default 
> constructor found". I already replaced the contained record class file, but 
> the result is the same. As it seems, besides merging services descriptors, 
> there seems to be some more resource type to get merge – but which?! Possibly 
> there is just something missing in the plugin's docs, possible we actually 
> need to invent a new type of transformer.
> (BTW, minimizeJar is false)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MSHADE-460) Cannot find default constructor of record

[Markus Karg (Jira)]

Markus Karg created MSHADE-460:
--

 Summary: Cannot find default constructor of record
 Key: MSHADE-460
 URL: https://issues.apache.org/jira/browse/MSHADE-460
 Project: Maven Shade Plugin
  Issue Type: Bug
Affects Versions: 3.5.1
Reporter: Markus Karg


I have setup up a small demo project which uses JSONB to deserialize JSON into 
a Java record. The created JAR works fine when using java -cp with the full 
class-path as shown by mvn dependency:build-classpath. As soon as I am building 
an uberjar using the Maven Shade Plugin, at runtime I end up with an exception 
like "Cannot create instance of a class: class 
eu.headcrashing.jaxrsdoneright.sebootstrap.HelloWorld$TimeInfo, No default 
constructor found". I already replaced the contained record class file, but the 
result is the same. As it seems, besides merging services descriptors, there 
seems to be some more resource type to get merge – but which?! Possibly there 
is just something missing in the plugin's docs, possible we actually need to 
invent a new type of transformer.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MANTRUN-237) Forwarding dependency classpath to ANT

[Markus Karg (Jira)]

Markus Karg created MANTRUN-237:
---

 Summary: Forwarding dependency classpath to ANT
 Key: MANTRUN-237
 URL: https://issues.apache.org/jira/browse/MANTRUN-237
 Project: Maven Antrun Plugin
  Issue Type: New Feature
Reporter: Markus Karg


When adding a dependency to the maven-antrun-plugin, the classpath containing 
that dependency should be available to the  ant task within ANT. That 
would allow the  task to invoke classes found in that dependencies. As 
this is currently not the case, one has to use the dependency-plugin to write 
the dependency classpath into a property and explicitly use that property with 
 inside of build.xml. While that certainly is 
more flexible, it is rather tedious.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (MNG-6142) Support for additional coordinate to identify branches, editions, private builds, etc.

[Markus Karg (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17345993#comment-17345993
 ] 

Markus Karg commented on MNG-6142:
--

What are you actually missing to be "fleshed out"? Just today I had this exact 
problem: There are two variants of "johnzon-jsonb" actually, one is using the 
Jakarta namespace, one is using the Javax namespace. The implementation 
otherwise is the same. Currently we are publishing the Jakarta variant using a 
classifier "-jakarta" and the Javax variant without a classifier. While this 
technically does work, it implies a problem: What if some day the Jakarta 
variant actually has a different source code or JavaDoc? Then the classifier 
suddenly covers a n:m matrix of "variant:classifier" (like 
"jakarta:javadoc")... The only real solution for real variants is to either add 
 to the POM or define a n:m syntax for classifiers.

So is that what you are missing, or did you simply want to propose that we 
discuss HOW we implement variants in a future major version of Maven?

> Support for additional  coordinate to identify branches, editions, 
> private builds, etc.
> 
>
> Key: MNG-6142
> URL: https://issues.apache.org/jira/browse/MNG-6142
> Project: Maven
>  Issue Type: Wish
>  Components: core
>Reporter: Markus Karg
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> Often development teams work on parallel variants (a.k.a branches) ontop of 
> the same base version. Maven currently has no support for such scenarios, 
> which is problematic, as the following example describes:
> A team of three developers just released version "1.0.0" of a library, which 
> is used by a larger application. The version was now set to 1.1.0-SNAPSHOT 
> for the master branch, and 1.0.1-SNAPSHOT for the Long-Term-Support branch. 
> Now in that team, programmer A started to work on feature A. In the same 
> team, programmer B started to work on feature B, which is concurrent (!) to 
> feature A. The team lead, programmer C, will later decide which (!) of both 
> features (A _or_ B) he wants to get in the final release 1.0.0. To try out 
> each of the features, he sets 1.1.0-SNAPSHOT as the dependency version in his 
> test application, to pull in the latest version of the library. The problem 
> is: How (by means of POM coordinates) to decide which proposed feature to 
> pull, A or B?
> Similar scenarios often happen whilst the development of large systems. There 
> is no real solution here, as group, artifact, and version are the same for 
> all variants of the next development iteration, but only the _variant_ (a.k.a 
> "branch") of the artifact is different.
> Why not simply reusing the existing coordinatest?
> - groupdId: A variant is a different timeline within an artifact, so changing 
> the group is irrational.
> - artifactId: Variants are, just like versions, changes _of_ artifacts, not 
> _different_ artifacts. Certainly, this is the most rational workaround.
> - version: Existing tools depend on the major.minor.build-qualifier schema, 
> and rely upon semantic interpretation that qualifiers are _sorted_, so 
> feature A would become "older" than feature "B", which is completely weird, 
> as both have the same age.
> - classifier: Classifiers are needed in addition to variants, for example 
> both A and B shall publish javadoc and sources, so this would break existing 
> features.
> To sum up, using the existing coordinates implies major drawbacks or even 
> breaks existing features. Also, it is counterintuitive, as a variant implies 
> a separate timeline, neither a new group or artifact, nor a sequence on one 
> shared same timeline.
> Hence, to improve actual current workflow scenarios, I'd like to propose the 
> addition of an optional  coordinate. The interpretation should be 
> like this:
> *  is optional.
> * , if existing, is added to the default file name between 
>  and  (e. g. mylib-featureB-1.0.0-SNAPSHOT-javadoc.jar).
> * , if given, implies that a dependency with variant V of artifact 
> A, will can only be satisfied with exact that coordinates, neither with 
> artifact "A-V", nor with A having no version. On the other hand, just as with 
> versions, a dependency not having a variant, is happy with _any_ variant of 
> the same artifact, unless the variant is marked as "exactly this" using 
> brackets [V].
> Adding support using these rules would allow tool / plugin vendors to greatly 
> support dealing with branches, e. g. in git and subversion, by better 
> understand dependencies on features, differences between branches, etc.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MSHADE-382) Add an option to skip execution

[Markus Karg (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331197#comment-17331197
 ] 

Markus Karg edited comment on MSHADE-382 at 4/24/21, 10:38 AM:
---

There are other use cases for skip: Often while programming I do `mvn verify`. 
In fact, what I _actual_y want is just to run some integration tests, while I 
do not care for the shading *so far* at that time. Certainly, in a _later_ 
step, I do want to turn it back on *then* (when I am _done_ with searching for 
problems). It is _very_ useful that I just can skip the shading *temporarily* 
without modifying the POM, so I can learn if some detected problem *comes* 
_from shading_ *or not*! As a contributor to Maven Shade Plugin I *very often* 
do that while hacking on new MSHADE features!

So for me _as a frequent contributor to this plugin_, being able to do 
`Dshade.skip` is a very big plus one, actually, and thumbs up to Andres for 
providing the PR! :


was (Author: mkarg):
There are other use cases for skip: Often while programming I do `mvn verify`. 
In fact, what I _actual_y want is just to run some integration tests, while I 
do not care for the shading *so far* at that time. Certainly, in a _later_ 
step, I do want to turn it back on *then* (when I am _done_ with searching for 
problems). It is _very_ useful that I just can skip the shading *temporarily* 
without modifying the POM, so I can learn if some detected problem *comes* 
_from shading_ *or not*! As a contributor to Maven Shade Plugin I *very often* 
do that while hacking on new MSHADE features!

So for me _as a frequent contributor to this plugin_, being able to do 
`-Dshade.skip` is a *very big plus one*, actually, and thumbs up to Andres for 
providing the PR! :-

> Add an option to skip execution
> ---
>
> Key: MSHADE-382
> URL: https://issues.apache.org/jira/browse/MSHADE-382
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.4
>Reporter: Andres Almiray
>Priority: Major
>
> It'd be great to have a property for skipping execution, such as 
> `maven.shade.skip`. Useful when a parent has setup shading but a child would 
> like to skip it for example.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-382) Add an option to skip execution

[Markus Karg (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331197#comment-17331197
 ] 

Markus Karg commented on MSHADE-382:


There are other use cases for skip: Often while programming I do `mvn verify`. 
In fact, what I _actual_y want is just to run some integration tests, while I 
do not care for the shading *so far* at that time. Certainly, in a _later_ 
step, I do want to turn it back on *then* (when I am _done_ with searching for 
problems). It is _very_ useful that I just can skip the shading *temporarily* 
without modifying the POM, so I can learn if some detected problem *comes* 
_from shading_ *or not*! As a contributor to Maven Shade Plugin I *very often* 
do that while hacking on new MSHADE features!

So for me _as a frequent contributor to this plugin_, being able to do 
`-Dshade.skip` is a *very big plus one*, actually, and thumbs up to Andres for 
providing the PR! :-

> Add an option to skip execution
> ---
>
> Key: MSHADE-382
> URL: https://issues.apache.org/jira/browse/MSHADE-382
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.4
>Reporter: Andres Almiray
>Priority: Major
>
> It'd be great to have a property for skipping execution, such as 
> `maven.shade.skip`. Useful when a parent has setup shading but a child would 
> like to skip it for example.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-385) Support for Multi-Release-JARs

[Markus Karg (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313926#comment-17313926
 ] 

Markus Karg commented on MSHADE-385:


I confirm that this ticket can be closed. Unfortunately I do not have the 
rights to perform this ticket action.

> Support for Multi-Release-JARs
> --
>
> Key: MSHADE-385
> URL: https://issues.apache.org/jira/browse/MSHADE-385
> Project: Maven Shade Plugin
>  Issue Type: New Feature
>Affects Versions: 3.3.0
>Reporter: Markus Karg
>Priority: Major
>
> Maven Shade Plugin currently is unable to deal with multi-release JARs, hence 
> it always (and only) picks the lowest commen nominator (fallback) class.
>  
> Actually the plugin should instead produce a multi-release JAR, hence pick 
> all class versions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-385) Support for Multi-Release-JARs

[Markus Karg (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313924#comment-17313924
 ] 

Markus Karg commented on MSHADE-385:


Romain, sorry for the confusion. I double-checked MSHADE and in fact it is 
working pretty-well with MJARs. My fault simply was that I forgot to 
_explicitly_ provide `true` in MSHADE's manifest 
transformer config, as I assumed that MSHADE would do that _automatically_ once 
it detects a `version` folder in one of the shaded dependencies. Silly me. ;)

> Support for Multi-Release-JARs
> --
>
> Key: MSHADE-385
> URL: https://issues.apache.org/jira/browse/MSHADE-385
> Project: Maven Shade Plugin
>  Issue Type: New Feature
>Affects Versions: 3.3.0
>Reporter: Markus Karg
>Priority: Major
>
> Maven Shade Plugin currently is unable to deal with multi-release JARs, hence 
> it always (and only) picks the lowest commen nominator (fallback) class.
>  
> Actually the plugin should instead produce a multi-release JAR, hence pick 
> all class versions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MSHADE-385) Support for Multi-Release-JARs

[Markus Karg (Jira)]

Markus Karg created MSHADE-385:
--

 Summary: Support for Multi-Release-JARs
 Key: MSHADE-385
 URL: https://issues.apache.org/jira/browse/MSHADE-385
 Project: Maven Shade Plugin
  Issue Type: New Feature
Affects Versions: 3.3.0
Reporter: Markus Karg


Maven Shade Plugin currently is unable to deal with multi-release JARs, hence 
it always (and only) picks the lowest commen nominator (fallback) class.

 

Actually the plugin should instead produce a multi-release JAR, hence pick all 
class versions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MINVOKER-273) Environment variable with empty value

[Markus Karg (Jira)]

[ 
https://issues.apache.org/jira/browse/MINVOKER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256005#comment-17256005
 ] 

Markus Karg commented on MINVOKER-273:
--

At least on Windows it is impossible to store null in env vars. According to 
Windows API description doing so will remove the variable from the environment. 
Can other OS experts confirm that this is the same on Linux, MacOS, etc? If so, 
I would be +1 for fixing this issue.

> Environment variable with empty value
> -
>
> Key: MINVOKER-273
> URL: https://issues.apache.org/jira/browse/MINVOKER-273
> Project: Maven Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> When we configure invoker with empty environment value, like:
> {code}
>  
> org.apache.maven.plugins
> maven-invoker-plugin
> 
> 
> 
> 
> 
> {code}
> Testing code will receive variable {{EMPTY_ENV}} with value {{"null"}} as 
> string.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHARED-969) Environment variable with null value

[Markus Karg (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHARED-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256004#comment-17256004
 ] 

Markus Karg commented on MSHARED-969:
-

At least on Windows it is impossible to store null in env vars. According to 
Windows API description doing so will remove the variable from the environment. 
Can other OS experts confirm that this is the same on Linux, MacOS, etc? If so, 
I would be +1 for fixing this issue.

> Environment variable with null value
> 
>
> Key: MSHARED-969
> URL: https://issues.apache.org/jira/browse/MSHARED-969
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-shared-utils
>Affects Versions: maven-shared-utils-3.3.3
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> When we add environment variable with {{null}} value then to executed process 
> is pass variable with {{"null"}} as string.
> Variable with {{null}} value should not be set, when executed process will 
> try to get this variable will receive {{null}} as we expect.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MWRAPPER-8) Status note on web page

[Markus Karg (Jira)]

[ 
https://issues.apache.org/jira/browse/MWRAPPER-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221213#comment-17221213
 ] 

Markus Karg commented on MWRAPPER-8:


[~rfscholte] [~hboutemy] What do you think?

> Status note on web page
> ---
>
> Key: MWRAPPER-8
> URL: https://issues.apache.org/jira/browse/MWRAPPER-8
> Project: Maven Wrapper
>  Issue Type: Task
>Affects Versions: 3.0.1
>Reporter: Markus Karg
>Priority: Trivial
>  Labels: documentation
>
> 3.0.1 was just released for development purposes, but not for public use. In 
> fact, this plugin does not work for the broad public, as it doesn't find its 
> needed downloads from Maven Central. Unfortunately there is no note on the 
> public web page of this plugin telling people so, hence more and more people 
> run into the problem that they try out the plugin and fail.
>  
> *I offer to put a clear warning there, that nobody needs to try out this 
> plugin, as it will definitively fail unless Maven 3.7.0 is published.*
>  
> On the other hand this only makes sense, if Maven 3.7.0 is several weeks away.
>  
> *So please tell me if it is worth sending a PR, or if you think 3.7.0 will be 
> here in the next few weeks.*



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MWRAPPER-8) Status note on web page

[Markus Karg (Jira)]

Markus Karg created MWRAPPER-8:
--

 Summary: Status note on web page
 Key: MWRAPPER-8
 URL: https://issues.apache.org/jira/browse/MWRAPPER-8
 Project: Maven Wrapper
  Issue Type: Task
Affects Versions: 3.0.1
Reporter: Markus Karg


3.0.1 was just released for development purposes, but not for public use. In 
fact, this plugin does not work for the broad public, as it doesn't find its 
needed downloads from Maven Central. Unfortunately there is no note on the 
public web page of this plugin telling people so, hence more and more people 
run into the problem that they try out the plugin and fail.

 

*I offer to put a clear warning there, that nobody needs to try out this 
plugin, as it will definitively fail unless Maven 3.7.0 is published.*

 

On the other hand this only makes sense, if Maven 3.7.0 is several weeks away.

 

*So please tell me if it is worth sending a PR, or if you think 3.7.0 will be 
here in the next few weeks.*



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MDEP-726) dependency:copy finds missing versions in TRANSITIVE dependencies

[Markus Karg (Jira)]

Markus Karg created MDEP-726:


 Summary: dependency:copy finds missing versions in TRANSITIVE 
dependencies
 Key: MDEP-726
 URL: https://issues.apache.org/jira/browse/MDEP-726
 Project: Maven Dependency Plugin
  Issue Type: New Feature
  Components: copy
Affects Versions: next-release
Reporter: Markus Karg


In case someone wants to dependency:copy a transitive dependency, currently he 
needs to explicitly provide that artifact's version. This is a bit annoying, 
because each time a transitive dependency gets updated, the POM containing the 
copy-execution needs to get adjusted. It would be great, if version could get 
omitted, just like it already works with direct dependencies and managed 
dependencies.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MDEP-437) Create symbolic links instead of physical copies

[Markus Karg (Jira)]

[ 
https://issues.apache.org/jira/browse/MDEP-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160622#comment-17160622
 ] 

Markus Karg commented on MDEP-437:
--

I am planning to provide a PR which adds a new "link" mojo to this plugin. That 
mojo would work like "copy", but it does not really copy the files from the 
local repository to the target location (which needs lots of time with many 
dependencies / huge files), but it only will create a symbolic link in the 
target location pointing into the local repository (which looks the same to 
many plugins and applications, but works considerably faster. POM authors can 
then decide whether they actually like to copy or link, and OS-activated 
profiles could event provide a fallback in cases a link is wanted but the OS 
does not support linking in some cases (like Windows).

> Create symbolic links instead of physical copies
> 
>
> Key: MDEP-437
> URL: https://issues.apache.org/jira/browse/MDEP-437
> Project: Maven Dependency Plugin
>  Issue Type: New Feature
>  Components: copy
>Affects Versions: 3.1.2
> Environment: JDK 7u51, Win 7 Pro SP1 (64 Bit)
>Reporter: Markus Karg
>Priority: Major
>
> When copying lots of resources, especially huge ones (e. g. we are dealing 
> with two gigabytes (!) split up into several 100 MB large binaries) it is 
> tedious to wait until the copy task has performed real physical copies...
> Since JRE 7 Java (which is public for years meanwhile) can deal with symbolic 
> links, it would be really cool if one could add a true 
> configuration option, so the plugin could simply go the fast lane and use 
> symbolic links instead of physical copies.
> For backwards compatibility unfortunately the default has to be "false". :-(



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MDEP-437) Create symbolic links instead of physical copies

[Markus Karg (Jira)]

 [ 
https://issues.apache.org/jira/browse/MDEP-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Karg updated MDEP-437:
-
Affects Version/s: (was: 2.8)
   3.1.2

I'd like to reopen this issue as I like to provide a PR implementing a solution 
by providing a new goal "link" instead of "copy".

> Create symbolic links instead of physical copies
> 
>
> Key: MDEP-437
> URL: https://issues.apache.org/jira/browse/MDEP-437
> Project: Maven Dependency Plugin
>  Issue Type: New Feature
>  Components: copy
>Affects Versions: 3.1.2
> Environment: JDK 7u51, Win 7 Pro SP1 (64 Bit)
>Reporter: Markus Karg
>Priority: Major
>
> When copying lots of resources, especially huge ones (e. g. we are dealing 
> with two gigabytes (!) split up into several 100 MB large binaries) it is 
> tedious to wait until the copy task has performed real physical copies...
> Since JRE 7 Java (which is public for years meanwhile) can deal with symbolic 
> links, it would be really cool if one could add a true 
> configuration option, so the plugin could simply go the fast lane and use 
> symbolic links instead of physical copies.
> For backwards compatibility unfortunately the default has to be "false". :-(



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MGPG-73) Sorry, no terminal at all requested - can't get input

[Markus Karg (Jira)]

Markus Karg created MGPG-73:
---

 Summary: Sorry, no terminal at all requested - can't get input
 Key: MGPG-73
 URL: https://issues.apache.org/jira/browse/MGPG-73
 Project: Maven GPG Plugin
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Markus Karg


Running "mvn sign" (MGPG 1.7-SNAPSHOT) on public Gitlab.com CI/CD service with 
GnuPG 2.2.12 fails with:

{{21329 [INFO] --- maven-gpg-plugin:1.7-SNAPSHOT:sign (sign-artifacts) @ cli 
---}}
{{*gpg: Sorry, no terminal at all requested - can't get input*}}
maven-gpg-plugin   
1.7-SNAPSHOT  
sign-artifacts verify   
 sign   




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MNG-6708) Command line option to exclude NESTED modules

[Markus Karg (JIRA)]

Markus Karg created MNG-6708:


 Summary: Command line option to exclude NESTED modules
 Key: MNG-6708
 URL: https://issues.apache.org/jira/browse/MNG-6708
 Project: Maven
  Issue Type: Improvement
  Components: Command Line
Affects Versions: 3.6.1
Reporter: Markus Karg


[MNG-5230|https://issues.apache.org/jira/browse/MNG-5230] added the -pl !g:a 
switch to exclude explicitly mentioned module g:a, but keep all other modules 
in the reactor build, including the submodules of g:a.

In some projects there are deeply nested hierarchies of modules just for 
structuring purposes. In such purely structural needs for hiearchies, it makes 
sense to exclude the submodules of g:a. Currently the caller must explicitly 
KNOW and PROVIDE all off them by hand. This is tedious and error-prone.

Hence it would be great if there would be a command line option to turn the 
"-pl !g:a" switch into a recursive variant that also skips the children and 
grandchildren of g:a. The optimal solution would be to not add another global 
switch (like -amb) but to have a flag for each excluded module, like "-pl 
!+g:a" a plus symbol explicitly enabling recursion ONLY for g:a but not for 
other modules.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (MNG-6676) Resume reactor build after skipped project using -pl !X -rf X combination

[Markus Karg (JIRA)]

Markus Karg created MNG-6676:


 Summary: Resume reactor build after skipped project using -pl !X 
-rf X combination
 Key: MNG-6676
 URL: https://issues.apache.org/jira/browse/MNG-6676
 Project: Maven
  Issue Type: Improvement
  Components: core
Affects Versions: 3.6.1
Reporter: Markus Karg


With huge multi-module builds sometimes it would come handy if Maven would have 
a "skip-this-and-resume" option. For example, you have hundreds of sub modules 
built fine, but one of them is heavily broken; due to your current task you 
want to ignore that one project just for now, and repeat the reactor build 
*after* the broken one. Due to the heavily long multi-hours time your already 
spent, you do not want to start from the beginning.

A nice syntax for this would be the combination "-pl !X -rf X" which means: 
"Resume *after* X".

At the moment this is not working, as "-pl X" removes X from the project list, 
so "-rf X" says it cannot find X. The fix should be that "-pl X" *keeps* X on 
the project list but marks it explicitly as *SKIPPED*, so "-rf X" *finds* X, 
but detects that it is to be SKIPPED, so it resumes with the next-in-list.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MSHADE-316) Minijar: true

[Markus Karg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHADE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Karg updated MSHADE-316:
---
Summary: Minijar: true  (was: Explicit 
minijar includes)

> Minijar: true
> 
>
> Key: MSHADE-316
> URL: https://issues.apache.org/jira/browse/MSHADE-316
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Reporter: Markus Karg
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.2.2
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Minijar currently respects includes, but these have a drawback: Once you 
> defined an include, the _default includes_ are gone! But what you actually 
> want to have when combining minijar with includes is just an "exception" to 
> minijar's filtering, not a complete replacement of the default includes!
> So what we need to make this work intuitively is either "explicit minijar 
> exceptions", or a "useDefaultIncludes=true" option that turns the notion from 
> "replace default includes by the single given include" to "add the single 
> given include ontop of the default includes".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-318) Specifically included class's dependencies are missing

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16831835#comment-16831835
 ] 

Markus Karg commented on MSHADE-318:


I have turned the without draft PR into a normal PR which is ready to merge. 
Please review. :)

> Specifically included class's dependencies are missing
> --
>
> Key: MSHADE-318
> URL: https://issues.apache.org/jira/browse/MSHADE-318
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Using `` one can specifically defined classes to exempt from 
> minijar's filtering. This is useful when a class is referenced by `String` 
> name instead of `Class` object reference, like e. g. reflection.
> Unfortunately *just* the explicitly included class is exempted from removal, 
> while all its transitive references (i. e. all the classes it uses it turn) 
> are still removed when shading. This effectively breaks the result's 
> functionality. This is hard to work around, as *all* such dependencies have 
> to be explicitly given in the pom to prevent it. That is really nasty.
> As a solution, a specific include shall always automatically include all 
> *transitive dependencies* of the explicitly exempted class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-316) Explicit minijar includes

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817556#comment-16817556
 ] 

Markus Karg commented on MSHADE-316:


[~rfscholte] All requested changes are implemented. Please continue review 
[https://github.com/apache/maven-shade-plugin/pull/19]. :)

> Explicit minijar includes
> -
>
> Key: MSHADE-316
> URL: https://issues.apache.org/jira/browse/MSHADE-316
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Minijar currently respects includes, but these have a drawback: Once you 
> defined an include, the _default includes_ are gone! But what you actually 
> want to have when combining minijar with includes is just an "exception" to 
> minijar's filtering, not a complete replacement of the default includes!
> So what we need to make this work intuitively is either "explicit minijar 
> exceptions", or a "useDefaultIncludes=true" option that turns the notion from 
> "replace default includes by the single given include" to "add the single 
> given include ontop of the default includes".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-318) Specifically included class's dependencies are missing

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817275#comment-16817275
 ] 

Markus Karg commented on MSHADE-318:


I withhold a fix in the draft state 
([https://github.com/apache/maven-shade-plugin/pull/20]) until 
[https://github.com/apache/maven-shade-plugin/pull/19] is merged, as my 
solution builds ontop of that.

> Specifically included class's dependencies are missing
> --
>
> Key: MSHADE-318
> URL: https://issues.apache.org/jira/browse/MSHADE-318
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Using `` one can specifically defined classes to exempt from 
> minijar's filtering. This is useful when a class is referenced by `String` 
> name instead of `Class` object reference, like e. g. reflection.
> Unfortunately *just* the explicitly included class is exempted from removal, 
> while all its transitive references (i. e. all the classes it uses it turn) 
> are still removed when shading. This effectively breaks the result's 
> functionality. This is hard to work around, as *all* such dependencies have 
> to be explicitly given in the pom to prevent it. That is really nasty.
> As a solution, a specific include shall always automatically include all 
> *transitive dependencies* of the explicitly exempted class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MSHADE-318) Specifically included class's dependencies are missing

[Markus Karg (JIRA)]

Markus Karg created MSHADE-318:
--

 Summary: Specifically included class's dependencies are missing
 Key: MSHADE-318
 URL: https://issues.apache.org/jira/browse/MSHADE-318
 Project: Maven Shade Plugin
  Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Markus Karg


Using `` one can specifically defined classes to exempt from minijar's 
filtering. This is useful when a class is referenced by `String` name instead 
of `Class` object reference, like e. g. reflection.

Unfortunately *just* the explicitly included class is exempted from removal, 
while all its transitive references (i. e. all the classes it uses it turn) are 
still removed when shading. This effectively breaks the result's functionality. 
This is hard to work around, as *all* such dependencies have to be explicitly 
given in the pom to prevent it. That is really nasty.

As a solution, a specific include shall always automatically include all 
*transitive dependencies* of the explicitly exempted class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-316) Explicit minijar includes

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816997#comment-16816997
 ] 

Markus Karg commented on MSHADE-316:


[~rfscholte] Provided PR that implements excludeDefaults=true as you requested. 
Please review [https://github.com/apache/maven-shade-plugin/pull/19]. :)

> Explicit minijar includes
> -
>
> Key: MSHADE-316
> URL: https://issues.apache.org/jira/browse/MSHADE-316
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Minijar currently respects includes, but these have a drawback: Once you 
> defined an include, the _default includes_ are gone! But what you actually 
> want to have when combining minijar with includes is just an "exception" to 
> minijar's filtering, not a complete replacement of the default includes!
> So what we need to make this work intuitively is either "explicit minijar 
> exceptions", or a "useDefaultIncludes=true" option that turns the notion from 
> "replace default includes by the single given include" to "add the single 
> given include ontop of the default includes".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-316) Explicit minijar includes

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816917#comment-16816917
 ] 

Markus Karg commented on MSHADE-316:


[~rfscholte] Fully agree with all you say. But see, it is the same for me, too. 
So I think you understand that it is not funny to squander one day of volunteer 
time with the wrong solution.

> Explicit minijar includes
> -
>
> Key: MSHADE-316
> URL: https://issues.apache.org/jira/browse/MSHADE-316
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Minijar currently respects includes, but these have a drawback: Once you 
> defined an include, the _default includes_ are gone! But what you actually 
> want to have when combining minijar with includes is just an "exception" to 
> minijar's filtering, not a complete replacement of the default includes!
> So what we need to make this work intuitively is either "explicit minijar 
> exceptions", or a "useDefaultIncludes=true" option that turns the notion from 
> "replace default includes by the single given include" to "add the single 
> given include ontop of the default includes".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-316) Explicit minijar includes

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816890#comment-16816890
 ] 

Markus Karg commented on MSHADE-316:


[~rfscholte] Ok I will create another PR implementing that alternative 
solution. :-) Just too bad that you didn't tell me earlier as a reaction upon 
my comment of April 4 where I let you choose your preference and proposed 
exactly what you now want in your recent comment... ;-(

> Explicit minijar includes
> -
>
> Key: MSHADE-316
> URL: https://issues.apache.org/jira/browse/MSHADE-316
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Minijar currently respects includes, but these have a drawback: Once you 
> defined an include, the _default includes_ are gone! But what you actually 
> want to have when combining minijar with includes is just an "exception" to 
> minijar's filtering, not a complete replacement of the default includes!
> So what we need to make this work intuitively is either "explicit minijar 
> exceptions", or a "useDefaultIncludes=true" option that turns the notion from 
> "replace default includes by the single given include" to "add the single 
> given include ontop of the default includes".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-316) Explicit minijar includes

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816652#comment-16816652
 ] 

Markus Karg commented on MSHADE-316:


[~rfscholte] It is definitively *not* possible with the existing plugin, as a 
single include _automatically excludes all other classes_. The fact that 
de-facto the existing plugin does that bad behavior, is the cause why I spend a 
day to implement it. You _cannot_ specify a single class exemption for the 
minijar filter without my PR (been there).

> Explicit minijar includes
> -
>
> Key: MSHADE-316
> URL: https://issues.apache.org/jira/browse/MSHADE-316
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Minijar currently respects includes, but these have a drawback: Once you 
> defined an include, the _default includes_ are gone! But what you actually 
> want to have when combining minijar with includes is just an "exception" to 
> minijar's filtering, not a complete replacement of the default includes!
> So what we need to make this work intuitively is either "explicit minijar 
> exceptions", or a "useDefaultIncludes=true" option that turns the notion from 
> "replace default includes by the single given include" to "add the single 
> given include ontop of the default includes".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-316) Explicit minijar includes

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816509#comment-16816509
 ] 

Markus Karg commented on MSHADE-316:


[~rfscholte] No, this is a misunderstanding. The idea is *not* to have full 
control over the classes being added. The idea is (see also my PR) is to 
*prevent minjar's removal of explicitly marked classes*. Use case: A dependency 
shall get included into a shaded jar, but that dependency is loaded by 
*Reflection*, so the original artifact does not directly reference the *Class* 
to load, but only holds a *String* with the class name. The Minijar filter will 
remove that class, so the shaded JAR will be broken. With my PR, you can add an 
_explicit minijar exemption_ on that single class name (or pattern), so minijar 
will keep that file even *without a technically detectable* need. This cannot 
be done with the existing include filters, because once _at least one_ include 
is explictly defined, the default (include _all_) is switched off so _all_ 
other classes would be _excluded_. The solution is my PR which simply provides 
an *exemption* for Minijar. There is a rather popular real-life scenario: 
Minijar breaks _Eclipse Jersey_ because one of Jersey's dependency is loaded by 
Reflection.

> Explicit minijar includes
> -
>
> Key: MSHADE-316
> URL: https://issues.apache.org/jira/browse/MSHADE-316
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Minijar currently respects includes, but these have a drawback: Once you 
> defined an include, the _default includes_ are gone! But what you actually 
> want to have when combining minijar with includes is just an "exception" to 
> minijar's filtering, not a complete replacement of the default includes!
> So what we need to make this work intuitively is either "explicit minijar 
> exceptions", or a "useDefaultIncludes=true" option that turns the notion from 
> "replace default includes by the single given include" to "add the single 
> given include ontop of the default includes".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-316) Explicit minijar includes

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815665#comment-16815665
 ] 

Markus Karg commented on MSHADE-316:


[~rfscholte] Please review PR 
https://github.com/apache/maven-shade-plugin/pull/18. :-)

> Explicit minijar includes
> -
>
> Key: MSHADE-316
> URL: https://issues.apache.org/jira/browse/MSHADE-316
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Minijar currently respects includes, but these have a drawback: Once you 
> defined an include, the _default includes_ are gone! But what you actually 
> want to have when combining minijar with includes is just an "exception" to 
> minijar's filtering, not a complete replacement of the default includes!
> So what we need to make this work intuitively is either "explicit minijar 
> exceptions", or a "useDefaultIncludes=true" option that turns the notion from 
> "replace default includes by the single given include" to "add the single 
> given include ontop of the default includes".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-313) Less agressive

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812643#comment-16812643
 ] 

Markus Karg commented on MSHADE-313:


[~rfscholte] Done. Sorry for the delay. :-)

> Less agressive 
> 
>
> Key: MSHADE-313
> URL: https://issues.apache.org/jira/browse/MSHADE-313
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The maven shade plugin already does a great job in minimizing JAR size. For 
> the majority of applications this is exactly what is needed.
> On the other hand there are some application areas where the algorithm is too 
> agressive. One particular and rather frequently found case is the services 
> API: ServiceLoader will ceise to work for minimized JARs since it is the 
> prototype of the biggest "minimize-JAR-antipattern": String-to-class 
> conversion.
> To make  usable in such scenarios, there should be a set of 
> options to enable the usual suspetcs (like ServiceLoader) to be detected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-313) Less agressive

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811510#comment-16811510
 ] 

Markus Karg commented on MSHADE-313:


[~rfscholte] I'm already working on the requested change (only keeping the 
actually indirectly-referenced services). Stay tuned... :-)

> Less agressive 
> 
>
> Key: MSHADE-313
> URL: https://issues.apache.org/jira/browse/MSHADE-313
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The maven shade plugin already does a great job in minimizing JAR size. For 
> the majority of applications this is exactly what is needed.
> On the other hand there are some application areas where the algorithm is too 
> agressive. One particular and rather frequently found case is the services 
> API: ServiceLoader will ceise to work for minimized JARs since it is the 
> prototype of the biggest "minimize-JAR-antipattern": String-to-class 
> conversion.
> To make  usable in such scenarios, there should be a set of 
> options to enable the usual suspetcs (like ServiceLoader) to be detected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MSHADE-313) Less agressive

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1684#comment-1684
 ] 

Markus Karg edited comment on MSHADE-313 at 4/5/19 6:03 PM:


I see your point but as I think we should not decide things for the application 
programmer I had in mind the "keepServices" option you wanted me to remove...!

In fact, the real-world scenario is that "Main" actually WOULD reference the 
service indirectly. So if you like I can add that to the "Main" class to 
express this intent.

But what actually to do with your personal dislike then in case an application 
programmer actually does want the case I artifically drafted to answer your 
questions? Tell them that robert dislilkes his style of coding, re-adding 
"keepServices", or adding the explicit excludes I proposed in the other PR?

EDIT - Proposal: I add a check to the minijar filter that only those services 
are kept that actually are referenced by "Main". Good?

EDIT - Sorry, not by "Main" but by anthing that is to be kept, because a 
service could need a service in turn.


was (Author: mkarg):
I see your point but as I think we should not decide things for the application 
programmer I had in mind the "keepServices" option you wanted me to remove...!

In fact, the real-world scenario is that "Main" actually WOULD reference the 
service indirectly. So if you like I can add that to the "Main" class to 
express this intent.

But what actually to do with your personal dislike then in case an application 
programmer actually does want the case I artifically drafted to answer your 
questions? Tell them that robert dislilkes his style of coding, re-adding 
"keepServices", or adding the explicit excludes I proposed in the other PR?

Proposal: I add a check to the minijar filter that only those services are kept 
that actually are referenced by "Main". Good?

> Less agressive 
> 
>
> Key: MSHADE-313
> URL: https://issues.apache.org/jira/browse/MSHADE-313
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The maven shade plugin already does a great job in minimizing JAR size. For 
> the majority of applications this is exactly what is needed.
> On the other hand there are some application areas where the algorithm is too 
> agressive. One particular and rather frequently found case is the services 
> API: ServiceLoader will ceise to work for minimized JARs since it is the 
> prototype of the biggest "minimize-JAR-antipattern": String-to-class 
> conversion.
> To make  usable in such scenarios, there should be a set of 
> options to enable the usual suspetcs (like ServiceLoader) to be detected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MSHADE-313) Less agressive

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1684#comment-1684
 ] 

Markus Karg edited comment on MSHADE-313 at 4/5/19 6:01 PM:


I see your point but as I think we should not decide things for the application 
programmer I had in mind the "keepServices" option you wanted me to remove...!

In fact, the real-world scenario is that "Main" actually WOULD reference the 
service indirectly. So if you like I can add that to the "Main" class to 
express this intent.

But what actually to do with your personal dislike then in case an application 
programmer actually does want the case I artifically drafted to answer your 
questions? Tell them that robert dislilkes his style of coding, re-adding 
"keepServices", or adding the explicit excludes I proposed in the other PR?

Proposal: I add a check to the minijar filter that only those services are kept 
that actually are referenced by "Main". Good?


was (Author: mkarg):
I see your point but as I think we should not decide things for the application 
programmer I had in mind the "keepServices" option you wanted me to remove...!

In fact, the real-world scenario is that "Main" actually WOULD reference the 
service indirectly. So if you like I can add that to the "Main" class to 
express this intent.

But what actually to do with your personal dislike then in case an application 
programmer actually does want the case I artifically drafted to answer your 
questions? Tell them that robert dislilkes his style of coding, re-adding 
"keepServices", or adding the explicit excludes I proposed in the other PR?

> Less agressive 
> 
>
> Key: MSHADE-313
> URL: https://issues.apache.org/jira/browse/MSHADE-313
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The maven shade plugin already does a great job in minimizing JAR size. For 
> the majority of applications this is exactly what is needed.
> On the other hand there are some application areas where the algorithm is too 
> agressive. One particular and rather frequently found case is the services 
> API: ServiceLoader will ceise to work for minimized JARs since it is the 
> prototype of the biggest "minimize-JAR-antipattern": String-to-class 
> conversion.
> To make  usable in such scenarios, there should be a set of 
> options to enable the usual suspetcs (like ServiceLoader) to be detected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-313) Less agressive

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1684#comment-1684
 ] 

Markus Karg commented on MSHADE-313:


I see your point but as I think we should not decide things for the application 
programmer I had in mind the "keepServices" option you wanted me to remove...!

In fact, the real-world scenario is that "Main" actually WOULD reference the 
service indirectly. So if you like I can add that to the "Main" class to 
express this intent.

But what actually to do with your personal dislike then in case an application 
programmer actually does want the case I artifically drafted to answer your 
questions? Tell them that robert dislilkes his style of coding, re-adding 
"keepServices", or adding the explicit excludes I proposed in the other PR?

> Less agressive 
> 
>
> Key: MSHADE-313
> URL: https://issues.apache.org/jira/browse/MSHADE-313
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The maven shade plugin already does a great job in minimizing JAR size. For 
> the majority of applications this is exactly what is needed.
> On the other hand there are some application areas where the algorithm is too 
> agressive. One particular and rather frequently found case is the services 
> API: ServiceLoader will ceise to work for minimized JARs since it is the 
> prototype of the biggest "minimize-JAR-antipattern": String-to-class 
> conversion.
> To make  usable in such scenarios, there should be a set of 
> options to enable the usual suspetcs (like ServiceLoader) to be detected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-316) Explicit minijar includes

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811090#comment-16811090
 ] 

Markus Karg commented on MSHADE-316:


Default includes are defined by JavaDocs as "By default, all files are included 
and no files are excluded.", hence: "**/*"

PR will follow.

> Explicit minijar includes
> -
>
> Key: MSHADE-316
> URL: https://issues.apache.org/jira/browse/MSHADE-316
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Reporter: Markus Karg
>Priority: Major
>
> Minijar currently respects includes, but these have a drawback: Once you 
> defined an include, the _default includes_ are gone! But what you actually 
> want to have when combining minijar with includes is just an "exception" to 
> minijar's filtering, not a complete replacement of the default includes!
> So what we need to make this work intuitively is either "explicit minijar 
> exceptions", or a "useDefaultIncludes=true" option that turns the notion from 
> "replace default includes by the single given include" to "add the single 
> given include ontop of the default includes".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MSHADE-313) Less agressive

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811082#comment-16811082
 ] 

Markus Karg edited comment on MSHADE-313 at 4/5/19 5:43 PM:


Yes, indeed you missed the most important part of my PR: Whether or not "Main" 
uses the service or not plays not role, that's a very essential point that the 
code expresses! The outcome of the shade plugin is a service in turn that is 
not limited to what "Main" does, but will be used by any third-party consumer. 
As *that* is out of reach of any technical check, the service MUST be kept 
always, independent of whatever "Main" does nor does not. And yes, "Main" MUST 
stay part of the project, because it still is a public class that a consumer of 
the outcome of the shade plugin might want to load that class!


was (Author: mkarg):
Yes, indeed you missed the most important part of my PR: Whether or not "Main" 
uses the service or not plays not role, that's a very essential point that the 
code expresses! The outcome of the shade plugin is a service in turn that is 
not limited to what "Main" does, but will be used by any third-party consumer. 
As *that* is out of reach of any technical check, the service MUST be kept 
always, independent of whatever "Main" does nor does not. :-)

> Less agressive 
> 
>
> Key: MSHADE-313
> URL: https://issues.apache.org/jira/browse/MSHADE-313
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The maven shade plugin already does a great job in minimizing JAR size. For 
> the majority of applications this is exactly what is needed.
> On the other hand there are some application areas where the algorithm is too 
> agressive. One particular and rather frequently found case is the services 
> API: ServiceLoader will ceise to work for minimized JARs since it is the 
> prototype of the biggest "minimize-JAR-antipattern": String-to-class 
> conversion.
> To make  usable in such scenarios, there should be a set of 
> options to enable the usual suspetcs (like ServiceLoader) to be detected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-313) Less agressive

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811082#comment-16811082
 ] 

Markus Karg commented on MSHADE-313:


Yes, indeed you missed the most important part of my PR: Whether or not "Main" 
uses the service or not plays not role, that's a very essential point that the 
code expresses! The outcome of the shade plugin is a service in turn that is 
not limited to what "Main" does, but will be used by any third-party consumer. 
As *that* is out of reach of any technical check, the service MUST be kept 
always, independent of whatever "Main" does nor does not. :-)

> Less agressive 
> 
>
> Key: MSHADE-313
> URL: https://issues.apache.org/jira/browse/MSHADE-313
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The maven shade plugin already does a great job in minimizing JAR size. For 
> the majority of applications this is exactly what is needed.
> On the other hand there are some application areas where the algorithm is too 
> agressive. One particular and rather frequently found case is the services 
> API: ServiceLoader will ceise to work for minimized JARs since it is the 
> prototype of the biggest "minimize-JAR-antipattern": String-to-class 
> conversion.
> To make  usable in such scenarios, there should be a set of 
> options to enable the usual suspetcs (like ServiceLoader) to be detected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-316) Explicit minijar includes

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810254#comment-16810254
 ] 

Markus Karg commented on MSHADE-316:


[~rfscholte] Shall I provide a PR for that? For which solution, "explicit 
minijar exceptions" or "useDefaultIncludes=true"? Both solve the same problem, 
but have different side aspects (positive and negative).

> Explicit minijar includes
> -
>
> Key: MSHADE-316
> URL: https://issues.apache.org/jira/browse/MSHADE-316
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Reporter: Markus Karg
>Priority: Major
>
> Minijar currently respects includes, but these have a drawback: Once you 
> defined an include, the _default includes_ are gone! But what you actually 
> want to have when combining minijar with includes is just an "exception" to 
> minijar's filtering, not a complete replacement of the default includes!
> So what we need to make this work intuitively is either "explicit minijar 
> exceptions", or a "useDefaultIncludes=true" option that turns the notion from 
> "replace default includes by the single given include" to "add the single 
> given include ontop of the default includes".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MSHADE-316) Explicit minijar includes

[Markus Karg (JIRA)]

Markus Karg created MSHADE-316:
--

 Summary: Explicit minijar includes
 Key: MSHADE-316
 URL: https://issues.apache.org/jira/browse/MSHADE-316
 Project: Maven Shade Plugin
  Issue Type: Improvement
Reporter: Markus Karg


Minijar currently respects includes, but these have a drawback: Once you 
defined an include, the _default includes_ are gone! But what you actually want 
to have when combining minijar with includes is just an "exception" to 
minijar's filtering, not a complete replacement of the default includes!

So what we need to make this work intuitively is either "explicit minijar 
exceptions", or a "useDefaultIncludes=true" option that turns the notion from 
"replace default includes by the single given include" to "add the single given 
include ontop of the default includes".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Issue Comment Deleted] (MSHADE-308) Support SPI pluggability for ResourceTranformers and Filters

[Markus Karg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHADE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Karg updated MSHADE-308:
---
Comment: was deleted

(was: Maybe it would be a good idea to actually *not* provide a new goal, but 
instead have a different *Shader* strategy. This sounds most intuitive: What 
you actually want to reach is *not* that another goal is reached -- you still 
want to *shade* stuff. But you want to use a different *strategy* when shading: 
A JPMS strategy. So my advice would be: Keep the goal, but change the shader.)

> Support SPI pluggability for ResourceTranformers and Filters
> 
>
> Key: MSHADE-308
> URL: https://issues.apache.org/jira/browse/MSHADE-308
> Project: Maven Shade Plugin
>  Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-308) Support SPI pluggability for ResourceTranformers and Filters

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810240#comment-16810240
 ] 

Markus Karg commented on MSHADE-308:


[~romain.manni-bucau] Yes, wrong ticket, thanks for the pointer.

> Support SPI pluggability for ResourceTranformers and Filters
> 
>
> Key: MSHADE-308
> URL: https://issues.apache.org/jira/browse/MSHADE-308
> Project: Maven Shade Plugin
>  Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-262) Add jpms goal

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810237#comment-16810237
 ] 

Markus Karg commented on MSHADE-262:


Maybe it would be a good idea to actually *not* provide a new goal, but instead 
have a different *Shader* strategy. This sounds most intuitive: What you 
actually want to reach is *not* that another goal is reached – you still want 
to *shade* stuff. But you want to use a different *strategy* when shading: A 
JPMS strategy. So my advice would be: Keep the goal, but change the shader.

> Add jpms goal
> -
>
> Key: MSHADE-262
> URL: https://issues.apache.org/jira/browse/MSHADE-262
> Project: Maven Shade Plugin
>  Issue Type: New Feature
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>
> With Java 9 we get module descriptors for strong encapsulation and reliable 
> configuration.
> When shading we should not merge or ignore these descriptors.
> In case of an application we should think of the way spring boot works, i.e. 
> bundle the jars in a jar and provide a new classloader. This is the only way 
> to preserve the strong encapsulation right now.
> After a talk with [~pwebb] and [~dblevins] we came to the conclusion that it 
> should NOT be combined with the current shade goal. First idea was to make a 
> new plugin, but after some rethinking I'd prefer to just make a separate goal 
> for it in this shade-plugin.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-308) Support SPI pluggability for ResourceTranformers and Filters

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16810141#comment-16810141
 ] 

Markus Karg commented on MSHADE-308:


Maybe it would be a good idea to actually *not* provide a new goal, but instead 
have a different *Shader* strategy. This sounds most intuitive: What you 
actually want to reach is *not* that another goal is reached -- you still want 
to *shade* stuff. But you want to use a different *strategy* when shading: A 
JPMS strategy. So my advice would be: Keep the goal, but change the shader.

> Support SPI pluggability for ResourceTranformers and Filters
> 
>
> Key: MSHADE-308
> URL: https://issues.apache.org/jira/browse/MSHADE-308
> Project: Maven Shade Plugin
>  Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-314) Should warn (and fix) breaking signed JARs

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809925#comment-16809925
 ] 

Markus Karg commented on MSHADE-314:


[~rfscholte] Shall I provide a PR for this?

> Should warn (and fix) breaking signed JARs
> --
>
> Key: MSHADE-314
> URL: https://issues.apache.org/jira/browse/MSHADE-314
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>
> Pulling content from signed JARs into uber-jar results in non-executable 
> outcome, as the signing information included is invalid within the new JAR.
> The solution must be to strip the signing information, and prompt a clear 
> warning about breaking the signing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MSHADE-314) Should warn (and fix) breaking signed JARs

[Markus Karg (JIRA)]

Markus Karg created MSHADE-314:
--

 Summary: Should warn (and fix) breaking signed JARs
 Key: MSHADE-314
 URL: https://issues.apache.org/jira/browse/MSHADE-314
 Project: Maven Shade Plugin
  Issue Type: Improvement
Affects Versions: 3.2.1
Reporter: Markus Karg


Pulling content from signed JARs into uber-jar results in non-executable 
outcome, as the signing information included is invalid within the new JAR.

The solution must be to strip the signing information, and prompt a clear 
warning about breaking the signing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-313) Less agressive

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16805814#comment-16805814
 ] 

Markus Karg commented on MSHADE-313:


Tests implemented. Please review 
https://github.com/apache/maven-shade-plugin/pull/17. :-)

> Less agressive 
> 
>
> Key: MSHADE-313
> URL: https://issues.apache.org/jira/browse/MSHADE-313
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The maven shade plugin already does a great job in minimizing JAR size. For 
> the majority of applications this is exactly what is needed.
> On the other hand there are some application areas where the algorithm is too 
> agressive. One particular and rather frequently found case is the services 
> API: ServiceLoader will ceise to work for minimized JARs since it is the 
> prototype of the biggest "minimize-JAR-antipattern": String-to-class 
> conversion.
> To make  usable in such scenarios, there should be a set of 
> options to enable the usual suspetcs (like ServiceLoader) to be detected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-313) Less agressive

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804393#comment-16804393
 ] 

Markus Karg commented on MSHADE-313:


Tests still in progress, but initial draft of the PR is already online as WIP 
at [https://github.com/apache/maven-shade-plugin/pull/17]. Stay tuned. :)

> Less agressive 
> 
>
> Key: MSHADE-313
> URL: https://issues.apache.org/jira/browse/MSHADE-313
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The maven shade plugin already does a great job in minimizing JAR size. For 
> the majority of applications this is exactly what is needed.
> On the other hand there are some application areas where the algorithm is too 
> agressive. One particular and rather frequently found case is the services 
> API: ServiceLoader will ceise to work for minimized JARs since it is the 
> prototype of the biggest "minimize-JAR-antipattern": String-to-class 
> conversion.
> To make  usable in such scenarios, there should be a set of 
> options to enable the usual suspetcs (like ServiceLoader) to be detected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-313) Less agressive

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799401#comment-16799401
 ] 

Markus Karg commented on MSHADE-313:


[~khmarbaise] I will send the PR ASAP. :)

[~michael-o] What's broken is that the ServiceLoader won't be able to actually 
instantiate the service in the dependency anymore, as its implementing classes 
are optimized away due to missing hard class links in the original artifact.

> Less agressive 
> 
>
> Key: MSHADE-313
> URL: https://issues.apache.org/jira/browse/MSHADE-313
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>
> The maven shade plugin already does a great job in minimizing JAR size. For 
> the majority of applications this is exactly what is needed.
> On the other hand there are some application areas where the algorithm is too 
> agressive. One particular and rather frequently found case is the services 
> API: ServiceLoader will ceise to work for minimized JARs since it is the 
> prototype of the biggest "minimize-JAR-antipattern": String-to-class 
> conversion.
> To make  usable in such scenarios, there should be a set of 
> options to enable the usual suspetcs (like ServiceLoader) to be detected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MSHADE-313) Less agressive

[Markus Karg (JIRA)]

Markus Karg created MSHADE-313:
--

 Summary: Less agressive 
 Key: MSHADE-313
 URL: https://issues.apache.org/jira/browse/MSHADE-313
 Project: Maven Shade Plugin
  Issue Type: Improvement
Affects Versions: 3.2.1
Reporter: Markus Karg


The maven shade plugin already does a great job in minimizing JAR size. For the 
majority of applications this is exactly what is needed.

On the other hand there are some application areas where the algorithm is too 
agressive. One particular and rather frequently found case is the services API: 
ServiceLoader will ceise to work for minimized JARs since it is the prototype 
of the biggest "minimize-JAR-antipattern": String-to-class conversion.

To make  usable in such scenarios, there should be a set of 
options to enable the usual suspetcs (like ServiceLoader) to be detected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-313) Less agressive

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16797948#comment-16797948
 ] 

Markus Karg commented on MSHADE-313:


[~rfscholte] I hope you remember our short discussion about that topic on 
JavaLand 2019. Would be a pleasure to contribute my solution, so on the next 
conference I can show POMs using the _original_ Maven Shade Plugin instead of 
my _forked_ one. ;)

> Less agressive 
> 
>
> Key: MSHADE-313
> URL: https://issues.apache.org/jira/browse/MSHADE-313
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>
> The maven shade plugin already does a great job in minimizing JAR size. For 
> the majority of applications this is exactly what is needed.
> On the other hand there are some application areas where the algorithm is too 
> agressive. One particular and rather frequently found case is the services 
> API: ServiceLoader will ceise to work for minimized JARs since it is the 
> prototype of the biggest "minimize-JAR-antipattern": String-to-class 
> conversion.
> To make  usable in such scenarios, there should be a set of 
> options to enable the usual suspetcs (like ServiceLoader) to be detected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-313) Less agressive

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16797945#comment-16797945
 ] 

Markus Karg commented on MSHADE-313:


I have already developed and successfully tested a prototype for protecting _in 
particular services_ (in the sense of JRE's ServiceLoader class) from getting 
broken  (simply using the METAINF/services content as a source for must-keep). 
If nobody objects the core idea of having an new 
true option (default for backwards compatibility: 
false), then I would turn it into production quality (i. e. cover it with a 
repeatable test) and send a Github Pull Request in the next weeks.

> Less agressive 
> 
>
> Key: MSHADE-313
> URL: https://issues.apache.org/jira/browse/MSHADE-313
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.2.1
>Reporter: Markus Karg
>Priority: Major
>
> The maven shade plugin already does a great job in minimizing JAR size. For 
> the majority of applications this is exactly what is needed.
> On the other hand there are some application areas where the algorithm is too 
> agressive. One particular and rather frequently found case is the services 
> API: ServiceLoader will ceise to work for minimized JARs since it is the 
> prototype of the biggest "minimize-JAR-antipattern": String-to-class 
> conversion.
> To make  usable in such scenarios, there should be a set of 
> options to enable the usual suspetcs (like ServiceLoader) to be detected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJAVADOC-575) 8 fails when module-info.java exists

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762402#comment-16762402
 ] 

Markus Karg commented on MJAVADOC-575:
--

I assume this is caused by Maven Javadoc Plugin adding --module-path as soon as 
it finds a module-info.java file in the src folder. This should be modified in 
a way that the existence of that file is to be ignored by the plugin as soon as 
the provided  is 8 or older, because the aim of such a feature / files 
combination simply is to have JavaDocs created "as if" the used JDK "would be" 
8 - and JDK 8's JavaDoc tool simply ignores that file.

> 8 fails when module-info.java exists
> -
>
> Key: MJAVADOC-575
> URL: https://issues.apache.org/jira/browse/MJAVADOC-575
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Markus Karg
>Priority: Major
>
> Some projects are written for Java 8 but include a module-info.java class 
> cross-compiled using JDK 9. On JDK 11.0.2 the Maven Javadoc Plugin does fail 
> with the following message:
>  error: option --module-path not allowed with target 1.8
> In fact, it is wrong that the Javadoc plugin uses the "--module-path" option 
> once 8 is provided.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MJAVADOC-575) 8 fails when module-info.java exists

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAVADOC-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762190#comment-16762190
 ] 

Markus Karg commented on MJAVADOC-575:
--

Also fails in 3.1.0-SNAPSHOT.

> 8 fails when module-info.java exists
> -
>
> Key: MJAVADOC-575
> URL: https://issues.apache.org/jira/browse/MJAVADOC-575
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Markus Karg
>Priority: Major
>
> Some projects are written for Java 8 but include a module-info.java class 
> cross-compiled using JDK 9. On JDK 11.0.2 the Maven Javadoc Plugin does fail 
> with the following message:
>  error: option --module-path not allowed with target 1.8
> In fact, it is wrong that the Javadoc plugin uses the "--module-path" option 
> once 8 is provided.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MJAVADOC-575) 8 fails when module-info.java exists

[Markus Karg (JIRA)]

Markus Karg created MJAVADOC-575:


 Summary: 8 fails when module-info.java exists
 Key: MJAVADOC-575
 URL: https://issues.apache.org/jira/browse/MJAVADOC-575
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 3.0.1
Reporter: Markus Karg


Some projects are written for Java 8 but include a module-info.java class 
cross-compiled using JDK 9. On JDK 11.0.2 the Maven Javadoc Plugin does fail 
with the following message:

 error: option --module-path not allowed with target 1.8

In fact, it is wrong that the Javadoc plugin uses the "--module-path" option 
once 8 is provided.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-5830) maven.multiModuleProjectDirectory system propery is not set

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735508#comment-16735508
 ] 

Markus Karg commented on MNG-5830:
--

The Eclipse Foundation has this problem (maven.multiModuleProjectDirectory not 
getting resolved) with Maven 3.5.4! [~khmarbaise] can you please help us fixing 
this on our public EF build infrastructure? This is a showstopper for Jakarta 
EE 8. Would be great, thanks! :)

> maven.multiModuleProjectDirectory system propery is not set
> ---
>
> Key: MNG-5830
> URL: https://issues.apache.org/jira/browse/MNG-5830
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap  Build, Command Line
>Affects Versions: 3.3.1, 3.3.3
>Reporter: Krzysztof Sobkowiak
>Assignee: Christian Schulte
>Priority: Major
>  Labels: Linux
>
> I have downloaded the newest Maven 3.3.3 and point the M2_HOME to the 
> directory with unpacked Maven.  {{mvn -v}} produces following error (whereas 
> the versions prior to 3.1.1 worked correctly)
> {code}
> kso@lenovo:/tmp$ export 
> M2_HOME=/home/kso/work/pde/dev/maven/apache-maven-3.3.3/
> kso@lenovo:/tmp$ mvn -v
> -Dmaven.multiModuleProjectDirectory system propery is not set. Check $M2_HOME 
> environment variable and mvn script match.kso@lenovo:/tmp$ 
> {code}
> The same problem when I want to build any maven project.
> Below the same output with Maven 3.2.5 to give you informations about my 
> environment
> {code}
> kso@lenovo:/tmp$ export 
> M2_HOME=/home/kso/work/pde/dev/maven/apache-maven-3.2.5/
> kso@lenovo:/tmp$ mvn -v
> Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 
> 2014-12-14T18:29:23+01:00)
> Maven home: /home/kso/work/pde/dev/maven/apache-maven-3.2.5
> Java version: 1.7.0_71, vendor: Oracle Corporation
> Java home: /home/kso/work/pde/run/jvm/jdk1.7.0_71/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.16.0-38-generic", arch: "amd64", family: "unix"
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MDEP-628) Unpacking File Mappers

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733047#comment-16733047
 ] 

Markus Karg commented on MDEP-628:
--

Is there a public nightly build of 3.1.2-SNAPSHOT available that I can use to 
try out this feature, or do I have to stick with my homebrewn binary until 
3.1.2 is finally released (and when will that be the case)?

> Unpacking File Mappers
> --
>
> Key: MDEP-628
> URL: https://issues.apache.org/jira/browse/MDEP-628
> Project: Maven Dependency Plugin
>  Issue Type: New Feature
>  Components: unpack, unpack-dependencies
>Affects Versions: 3.1.1
>Reporter: Markus Karg
>Assignee: Robert Scholte
>Priority: Major
>  Labels: FileMapper, Mapping, Path
> Fix For: 3.1.2
>
>
> The new parameter {{fileMappers}} (default: {{null}}) can be set to an 
> implementation of the 
> {{org.codehaus.plexus.components.io.filemappers.FileMapper}} interface to 
> rewrite the target path of each unpacked file.
> This is useful in case prefixes of target files names within the target 
> directory shall be added (using {{PrefixFileMapper}}), changed or omitted 
> (using {{RegExpFileMapper}}).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MDEP-628) Unpacking File Mappers

[Markus Karg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MDEP-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Karg updated MDEP-628:
-
Summary: Unpacking File Mappers  (was: Unpacking File Mapper)

> Unpacking File Mappers
> --
>
> Key: MDEP-628
> URL: https://issues.apache.org/jira/browse/MDEP-628
> Project: Maven Dependency Plugin
>  Issue Type: New Feature
>  Components: unpack, unpack-dependencies
>Affects Versions: 3.1.1
>Reporter: Markus Karg
>Priority: Major
>  Labels: FileMapper, Mapping, Path
>
> The new parameter {{fileMappers}} (default: {{null}}) can be set to an 
> implementation of the 
> {{org.codehaus.plexus.components.io.filemappers.FileMapper}} interface to 
> rewrite the target path of each unpacked file.
> This is useful in case prefixes of target files names within the target 
> directory shall be added (using {{PrefixFileMapper}}), changed or omitted 
> (using {{RegExpFileMapper}}).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MDEP-628) Unpacking File Mapper

[Markus Karg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MDEP-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Karg updated MDEP-628:
-
Description: 
The new parameter {{fileMappers}} (default: {{null}}) can be set to an 
implementation of the 
{{org.codehaus.plexus.components.io.filemappers.FileMapper}} interface to 
rewrite the target path of each unpacked file.

This is useful in case prefixes of target files names within the target 
directory shall be added (using {{PrefixFileMapper}}), changed or omitted 
(using {{RegExpFileMapper}}).

  was:
The new parameter {{fileMapper}} (default: {{null}}) can be set to an 
implementation of the 
{{org.codehaus.plexus.components.io.filemappers.FileMapper}} interface to 
rewrite the target path of each unpacked file.

This is useful in case prefixes of target files names within the target 
directory shall be added (using {{PrefixFileMapper}}), changed or omitted 
(using {{RegExpFileMapper}}).


> Unpacking File Mapper
> -
>
> Key: MDEP-628
> URL: https://issues.apache.org/jira/browse/MDEP-628
> Project: Maven Dependency Plugin
>  Issue Type: New Feature
>  Components: unpack, unpack-dependencies
>Affects Versions: 3.1.1
>Reporter: Markus Karg
>Priority: Major
>  Labels: FileMapper, Mapping, Path
>
> The new parameter {{fileMappers}} (default: {{null}}) can be set to an 
> implementation of the 
> {{org.codehaus.plexus.components.io.filemappers.FileMapper}} interface to 
> rewrite the target path of each unpacked file.
> This is useful in case prefixes of target files names within the target 
> directory shall be added (using {{PrefixFileMapper}}), changed or omitted 
> (using {{RegExpFileMapper}}).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MDEP-628) Unpacking File Mapper

[Markus Karg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MDEP-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Karg updated MDEP-628:
-
Attachment: (was: image-2018-09-22-11-58-40-679.png)

> Unpacking File Mapper
> -
>
> Key: MDEP-628
> URL: https://issues.apache.org/jira/browse/MDEP-628
> Project: Maven Dependency Plugin
>  Issue Type: New Feature
>  Components: unpack, unpack-dependencies
>Affects Versions: 3.1.1
>Reporter: Markus Karg
>Priority: Major
>  Labels: FileMapper, Mapping, Path
>
> The new parameter {{fileMapper}} (default: {{null}}) can be set to an 
> implementation of the 
> {{org.codehaus.plexus.components.io.filemappers.FileMapper}} interface to 
> rewrite the target path of each unpacked file.
> This is useful in case prefixes of target files names within the target 
> directory shall be added (using {{PrefixFileMapper}}), changed or omitted 
> (using {{RegExpFileMapper}}).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MDEP-628) Unpacking File Mapper

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16624573#comment-16624573
 ] 

Markus Karg commented on MDEP-628:
--

I have developed an implementation of this functionality, see the following 
Github Pull Requests:

* [https://github.com/codehaus-plexus/plexus-archiver/pull/100] - Adds this 
functionality to Plexus Archiver 3.7.0-SNAPSHOT.

* [https://github.com/apache/maven-dependency-plugin/pull/5] - Adds this 
functionality to of 3.2.1-SNAPSHOT by using Plexus Archiver 3.7.0-SNAPSHOT.

> Unpacking File Mapper
> -
>
> Key: MDEP-628
> URL: https://issues.apache.org/jira/browse/MDEP-628
> Project: Maven Dependency Plugin
>  Issue Type: New Feature
>  Components: unpack, unpack-dependencies
>Affects Versions: 3.1.1
>Reporter: Markus Karg
>Priority: Major
>  Labels: FileMapper, Mapping, Path
> Attachments: image-2018-09-22-11-58-40-679.png
>
>
> The new parameter {{fileMapper}} (default: {{null}}) can be set to an 
> implementation of the 
> {{org.codehaus.plexus.components.io.filemappers.FileMapper}} interface to 
> rewrite the target path of each unpacked file.
> This is useful in case prefixes of target files names within the target 
> directory shall be added (using {{PrefixFileMapper}}), changed or omitted 
> (using {{RegExpFileMapper}}).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MDEP-628) Unpacking File Mapper

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16624573#comment-16624573
 ] 

Markus Karg edited comment on MDEP-628 at 9/22/18 10:01 AM:


I have developed an implementation of this functionality, see the following 
Github Pull Requests:
 * [https://github.com/codehaus-plexus/plexus-archiver/pull/100] - Adds this 
functionality to Plexus Archiver 3.7.0-SNAPSHOT.

 * [https://github.com/apache/maven-dependency-plugin/pull/5] - Adds this 
functionality to 3.2.1-SNAPSHOT by using Plexus Archiver 3.7.0-SNAPSHOT.


was (Author: mkarg):
I have developed an implementation of this functionality, see the following 
Github Pull Requests:

* [https://github.com/codehaus-plexus/plexus-archiver/pull/100] - Adds this 
functionality to Plexus Archiver 3.7.0-SNAPSHOT.

* [https://github.com/apache/maven-dependency-plugin/pull/5] - Adds this 
functionality to of 3.2.1-SNAPSHOT by using Plexus Archiver 3.7.0-SNAPSHOT.

> Unpacking File Mapper
> -
>
> Key: MDEP-628
> URL: https://issues.apache.org/jira/browse/MDEP-628
> Project: Maven Dependency Plugin
>  Issue Type: New Feature
>  Components: unpack, unpack-dependencies
>Affects Versions: 3.1.1
>Reporter: Markus Karg
>Priority: Major
>  Labels: FileMapper, Mapping, Path
> Attachments: image-2018-09-22-11-58-40-679.png
>
>
> The new parameter {{fileMapper}} (default: {{null}}) can be set to an 
> implementation of the 
> {{org.codehaus.plexus.components.io.filemappers.FileMapper}} interface to 
> rewrite the target path of each unpacked file.
> This is useful in case prefixes of target files names within the target 
> directory shall be added (using {{PrefixFileMapper}}), changed or omitted 
> (using {{RegExpFileMapper}}).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MDEP-628) Unpacking File Mapper

[Markus Karg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MDEP-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus Karg updated MDEP-628:
-
Attachment: image-2018-09-22-11-58-40-679.png

> Unpacking File Mapper
> -
>
> Key: MDEP-628
> URL: https://issues.apache.org/jira/browse/MDEP-628
> Project: Maven Dependency Plugin
>  Issue Type: New Feature
>  Components: unpack, unpack-dependencies
>Affects Versions: 3.1.1
>Reporter: Markus Karg
>Priority: Major
>  Labels: FileMapper, Mapping, Path
> Attachments: image-2018-09-22-11-58-40-679.png
>
>
> The new parameter {{fileMapper}} (default: {{null}}) can be set to an 
> implementation of the 
> {{org.codehaus.plexus.components.io.filemappers.FileMapper}} interface to 
> rewrite the target path of each unpacked file.
> This is useful in case prefixes of target files names within the target 
> directory shall be added (using {{PrefixFileMapper}}), changed or omitted 
> (using {{RegExpFileMapper}}).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MDEP-628) Unpacking File Mapper

[Markus Karg (JIRA)]

Markus Karg created MDEP-628:


 Summary: Unpacking File Mapper
 Key: MDEP-628
 URL: https://issues.apache.org/jira/browse/MDEP-628
 Project: Maven Dependency Plugin
  Issue Type: New Feature
  Components: unpack, unpack-dependencies
Affects Versions: 3.1.1
Reporter: Markus Karg


The new parameter {{fileMapper}} (default: {{null}}) can be set to an 
implementation of the 
{{org.codehaus.plexus.components.io.filemappers.FileMapper}} interface to 
rewrite the target path of each unpacked file.

This is useful in case prefixes of target files names within the target 
directory shall be added (using {{PrefixFileMapper}}), changed or omitted 
(using {{RegExpFileMapper}}).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MRELEASE-956) Release Strategy Interface

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16325582#comment-16325582
 ] 

Markus Karg commented on MRELEASE-956:
--

Yes, certainly they need to have a decent understanding of programming, but 
this does not imply (and it _should not_ automatically imply) any understanding 
about _Maven programming_. Anyways, it is great to have strategies now, even 
such specialized ones. We will check whether it is enough for us or whether we 
still need to fork our own release plugin. In the latter case, we will post a 
PR in May.

> Release Strategy Interface
> --
>
> Key: MRELEASE-956
> URL: https://issues.apache.org/jira/browse/MRELEASE-956
> Project: Maven Release Plugin
>  Issue Type: New Feature
>  Components: perform
>Reporter: Markus Karg
>Assignee: Robert Scholte
>  Labels: strategy
> Fix For: 3.0.0
>
>
> The release plugin has built-in strategies for preparation and performing of 
> a release. For example, the strategy for preparation contains increasing 
> versions numbers, comitting to SCM, tagging in SCM, and so.
> Not all users share the same strategies in real life. For example, some 
> companies might want to have a tag AND and a branch created in SCM when 
> preparing a release. Or other companies might want to have tag created for 
> "prepared-release-1.0.0" at preparation, and replace it by "release-1.0.0" as 
> part of release:perform.
> To provide better flexibility of such company-wide strategies, it might be a 
> solution to introduce an interface "ReleaseStrategy" which acts as a worker 
> for the prepare and perform goals (and possibly others). The current built-in 
> strategy could be refactored to be a default-included 
> "DefaultReleaseStrategy" for backwards compatibility, while users could 
> configure a new property "releaseStrategy" to point to an Extension which 
> provides a differently working strategy.
> To make this work, certainly the Strategy implementation needs to get passed 
> a context which allows to fire actions like "tag version", "create branch", 
> "change pom version" and so on, just as the current built-in strategy has.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MRELEASE-956) Release Strategy Interface

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16325205#comment-16325205
 ] 

Markus Karg commented on MRELEASE-956:
--

Understood. But still I have concerns:

* Your strategy enforces the paradigm that a release is always flollowing a 
flat list of phases. In the real world, there might be organizations having 
rather complex organizational processes which are neither flat nor linear, 
including branches and loops. For example, there even could be parallel tasks 
that have be successful before the next step, or a step must be repeated, etc. 
This seems to be impossible with your model (or at least I it is so complex 
that I did not understand it by the first look), while it is simple with mine.

* * Due to your enforced lilst-of-phases-plus-hints design implementing a 
custom release strategy becomes a rather complex task: One has to be rather 
experienced with Maven / Plugin internals and data structures. Implementing my 
strategy instead is possible even for programming beginners one has to 
implement "onRelease" and can do what he want; only if he wants to call Maven 
he has to learn about Maven APIs.

> Release Strategy Interface
> --
>
> Key: MRELEASE-956
> URL: https://issues.apache.org/jira/browse/MRELEASE-956
> Project: Maven Release Plugin
>  Issue Type: New Feature
>  Components: perform
>Reporter: Markus Karg
>Assignee: Robert Scholte
>  Labels: strategy
> Fix For: 3.0.0
>
>
> The release plugin has built-in strategies for preparation and performing of 
> a release. For example, the strategy for preparation contains increasing 
> versions numbers, comitting to SCM, tagging in SCM, and so.
> Not all users share the same strategies in real life. For example, some 
> companies might want to have a tag AND and a branch created in SCM when 
> preparing a release. Or other companies might want to have tag created for 
> "prepared-release-1.0.0" at preparation, and replace it by "release-1.0.0" as 
> part of release:perform.
> To provide better flexibility of such company-wide strategies, it might be a 
> solution to introduce an interface "ReleaseStrategy" which acts as a worker 
> for the prepare and perform goals (and possibly others). The current built-in 
> strategy could be refactored to be a default-included 
> "DefaultReleaseStrategy" for backwards compatibility, while users could 
> configure a new property "releaseStrategy" to point to an Extension which 
> provides a differently working strategy.
> To make this work, certainly the Strategy implementation needs to get passed 
> a context which allows to fire actions like "tag version", "create branch", 
> "change pom version" and so on, just as the current built-in strategy has.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MRELEASE-956) Release Strategy Interface

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16325179#comment-16325179
 ] 

Markus Karg commented on MRELEASE-956:
--

Looking at you code I do not see much similarity with what I proposed. Your 
strategy interface simply allows to customize the phases to perform for each 
release action. What I proposed was an interface which allows complete freedom, 
e. g. even running a custom Groovy script which changes issue tracker entries 
etc. So I think your solution is too narrow. The idea of my ReleaseStrategy was 
that it is triggered to execute at a given point, and an implementation will in 
turn ask the Release Plugin to perform some actions in turn. Like 
"Strategy.onPrepare -> API.bumpVersion(Major + 1) then SQL: INSERT INTO ISSUE 
DATABASE"... etc.

> Release Strategy Interface
> --
>
> Key: MRELEASE-956
> URL: https://issues.apache.org/jira/browse/MRELEASE-956
> Project: Maven Release Plugin
>  Issue Type: New Feature
>  Components: perform
>Reporter: Markus Karg
>Assignee: Robert Scholte
>  Labels: strategy
> Fix For: 3.0.0
>
>
> The release plugin has built-in strategies for preparation and performing of 
> a release. For example, the strategy for preparation contains increasing 
> versions numbers, comitting to SCM, tagging in SCM, and so.
> Not all users share the same strategies in real life. For example, some 
> companies might want to have a tag AND and a branch created in SCM when 
> preparing a release. Or other companies might want to have tag created for 
> "prepared-release-1.0.0" at preparation, and replace it by "release-1.0.0" as 
> part of release:perform.
> To provide better flexibility of such company-wide strategies, it might be a 
> solution to introduce an interface "ReleaseStrategy" which acts as a worker 
> for the prepare and perform goals (and possibly others). The current built-in 
> strategy could be refactored to be a default-included 
> "DefaultReleaseStrategy" for backwards compatibility, while users could 
> configure a new property "releaseStrategy" to point to an Extension which 
> provides a differently working strategy.
> To make this work, certainly the Strategy implementation needs to get passed 
> a context which allows to fire actions like "tag version", "create branch", 
> "change pom version" and so on, just as the current built-in strategy has.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MRELEASE-956) Release Strategy Interface

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16325167#comment-16325167
 ] 

Markus Karg commented on MRELEASE-956:
--

Update: Did not find the time for the PR, apparently. If nobody else finds time 
earlier, I will look into that in May.

> Release Strategy Interface
> --
>
> Key: MRELEASE-956
> URL: https://issues.apache.org/jira/browse/MRELEASE-956
> Project: Maven Release Plugin
>  Issue Type: New Feature
>  Components: perform
>Reporter: Markus Karg
>Assignee: Robert Scholte
>  Labels: strategy
>
> The release plugin has built-in strategies for preparation and performing of 
> a release. For example, the strategy for preparation contains increasing 
> versions numbers, comitting to SCM, tagging in SCM, and so.
> Not all users share the same strategies in real life. For example, some 
> companies might want to have a tag AND and a branch created in SCM when 
> preparing a release. Or other companies might want to have tag created for 
> "prepared-release-1.0.0" at preparation, and replace it by "release-1.0.0" as 
> part of release:perform.
> To provide better flexibility of such company-wide strategies, it might be a 
> solution to introduce an interface "ReleaseStrategy" which acts as a worker 
> for the prepare and perform goals (and possibly others). The current built-in 
> strategy could be refactored to be a default-included 
> "DefaultReleaseStrategy" for backwards compatibility, while users could 
> configure a new property "releaseStrategy" to point to an Extension which 
> provides a differently working strategy.
> To make this work, certainly the Strategy implementation needs to get passed 
> a context which allows to fire actions like "tag version", "create branch", 
> "change pom version" and so on, just as the current built-in strategy has.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6254) Clarificatin on sorting in Repository Metadata

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16082801#comment-16082801
 ] 

Markus Karg commented on MNG-6254:
--

Just as I said, all I propose is to clarify and document, not to rework 
anything.

> Clarificatin on  sorting in Repository Metadata
> -
>
> Key: MNG-6254
> URL: https://issues.apache.org/jira/browse/MNG-6254
> Project: Maven
>  Issue Type: Improvement
>  Components: Artifacts and Repositories
>Affects Versions: 3.5.0
>Reporter: Markus Karg
>
> The document 
> http://maven.apache.org/ref/3.3.9/maven-repository-metadata/repository-metadata.html
>  explains that  does contain a _List_, hence is _sorted_.
> When pulling _real _metadata from Maven Central, e. g. 
> http://repo.maven.apache.org/maven2/javax/ws/rs/jsr311-api/maven-metadata.xml,
>  it is apparent that the content of  is _not_ sorted (in this 
> example, 1.1-ea is listed _after_ 1.1, which is a violation of the sorting, 
> because -ea must be listed _before_ 1.1). So effectively Maven Central 
> devliers _unsorted_ versions.
> Also, the effectively listed XSD 
> http://maven.apache.org/xsd/metadata-1.1.0.xsd is nonexistent, so cannot be 
> looked but whether Maven Central is wrong, or whether actually the 
> specification should say it must be Set instead of List.
> To sum up, there should be a clarification whether  must be sorted 
> according to the Maven Version Numbering Schema, whether it must be Set vs 
> List, and whether the missing XSD should be uploaded.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6254) Clarificatin on sorting in Repository Metadata

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16082613#comment-16082613
 ] 

Markus Karg commented on MNG-6254:
--

Actually the aim of this bug report is that make clear what the specification 
wants, neither what you "AFAIK" nor what I want. It is to be clarified and 
clearly documented once.

> Clarificatin on  sorting in Repository Metadata
> -
>
> Key: MNG-6254
> URL: https://issues.apache.org/jira/browse/MNG-6254
> Project: Maven
>  Issue Type: Improvement
>  Components: Artifacts and Repositories
>Affects Versions: 3.5.0
>Reporter: Markus Karg
>
> The document 
> http://maven.apache.org/ref/3.3.9/maven-repository-metadata/repository-metadata.html
>  explains that  does contain a _List_, hence is _sorted_.
> When pulling _real _metadata from Maven Central, e. g. 
> http://repo.maven.apache.org/maven2/javax/ws/rs/jsr311-api/maven-metadata.xml,
>  it is apparent that the content of  is _not_ sorted (in this 
> example, 1.1-ea is listed _after_ 1.1, which is a violation of the sorting, 
> because -ea must be listed _before_ 1.1). So effectively Maven Central 
> devliers _unsorted_ versions.
> Also, the effectively listed XSD 
> http://maven.apache.org/xsd/metadata-1.1.0.xsd is nonexistent, so cannot be 
> looked but whether Maven Central is wrong, or whether actually the 
> specification should say it must be Set instead of List.
> To sum up, there should be a clarification whether  must be sorted 
> according to the Maven Version Numbering Schema, whether it must be Set vs 
> List, and whether the missing XSD should be uploaded.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MNG-6254) Clarificatin on sorting in Repository Metadata

[Markus Karg (JIRA)]

Markus Karg created MNG-6254:


 Summary: Clarificatin on  sorting in Repository Metadata
 Key: MNG-6254
 URL: https://issues.apache.org/jira/browse/MNG-6254
 Project: Maven
  Issue Type: Improvement
  Components: Artifacts and Repositories
Affects Versions: 3.5.0
Reporter: Markus Karg


The document 
http://maven.apache.org/ref/3.3.9/maven-repository-metadata/repository-metadata.html
 explains that  does contain a _List_, hence is _sorted_.

When pulling _real _metadata from Maven Central, e. g. 
http://repo.maven.apache.org/maven2/javax/ws/rs/jsr311-api/maven-metadata.xml, 
it is apparent that the content of  is _not_ sorted (in this example, 
1.1-ea is listed _after_ 1.1, which is a violation of the sorting, because -ea 
must be listed _before_ 1.1). So effectively Maven Central devliers _unsorted_ 
versions.

Also, the effectively listed XSD http://maven.apache.org/xsd/metadata-1.1.0.xsd 
is nonexistent, so cannot be looked but whether Maven Central is wrong, or 
whether actually the specification should say it must be Set instead 
of List.

To sum up, there should be a clarification whether  must be sorted 
according to the Maven Version Numbering Schema, whether it must be Set vs 
List, and whether the missing XSD should be uploaded.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6250) MVN 3.5.0 cannot resolve range [1.1.1, 1.2)

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16078249#comment-16078249
 ] 

Markus Karg commented on MNG-6250:
--

Today I learned the reason of this problem, and I think the bug report is 
invalid. The problem is NOT a general problem with [1.1.1, 1.2), but actually 
the meta information is wrong in Maven Central for one particular artifact. I 
filed an issue against MCENTRAL to fix it.


javax.ws.rs
jsr311-api
1.1.1


Search Maven Central says the latest version is 1.1.1, but the meta information 
delivered by Maven Central says there is only one version, and it is 1.1-ea. 
Hence, the range resolution fails.

This is not an MNG issue, it is an MCENTRAL issue.

> MVN 3.5.0 cannot resolve range [1.1.1, 1.2)
> ---
>
> Key: MNG-6250
> URL: https://issues.apache.org/jira/browse/MNG-6250
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.0
> Environment: Win 7, 64 Bit, JDK 8u92, MVN 3.5.0
>Reporter: Markus Karg
>
> I have a project which has a dependency which in turn has a depency on a 
> range [1.1.1, 1.2). mvn dependency:tree fails to resolve this range. It stops 
> complaining that there is no version found for [1.1.1, 1.2). The strange 
> thing is, there is a 1.1.1 in the local repo, and once I either replace the 
> range by exactly 1.1.1, or once I use dependencyManagement to exactly use 
> 1.1.1, the dependency tree is correctly shown. So it seems, range resolution 
> is broken. This happens with both, MVN 3.0.4 and MVN 3.5.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MNG-6250) MVN 3.5.0 cannot resolve range [1.1.1, 1.2)

[Markus Karg (JIRA)]

Markus Karg created MNG-6250:


 Summary: MVN 3.5.0 cannot resolve range [1.1.1, 1.2)
 Key: MNG-6250
 URL: https://issues.apache.org/jira/browse/MNG-6250
 Project: Maven
  Issue Type: Bug
Affects Versions: 3.5.0
 Environment: Win 7, 64 Bit, JDK 8u92, MVN 3.5.0
Reporter: Markus Karg


I have a project which has a dependency which in turn has a depency on a range 
[1.1.1, 1.2). mvn dependency:tree fails to resolve this range. It stops 
complaining that there is no version found for [1.1.1, 1.2). The strange thing 
is, there is a 1.1.1 in the local repo, and once I either replace the range by 
exactly 1.1.1, or once I use dependencyManagement to exactly use 1.1.1, the 
dependency tree is correctly shown. So it seems, range resolution is broken. 
This happens with both, MVN 3.0.4 and MVN 3.5.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MDEP-574) include not matching for custom types

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16071626#comment-16071626
 ] 

Markus Karg commented on MDEP-574:
--

Actually I tried it out but providing g:a:e does not work with include.

 

From: Guillaume Boué (JIRA) [mailto:j...@apache.org] 
Sent: Sonntag, 2. Juli 2017 13:54
To: mar...@headcrashing.eu
Subject: [jira] [Kommentiert] (MDEP-574) include not matching for custom types

 





  Guillaume 
Boué hat   BugMDEP-574 
kommentiert 



  



  Betreff: include not matching 
for custom types 



Currently, include should support extensions, but not types (as it internally 
uses a  

 PatternInclusionsFilter to filter artifacts), so g:a:e:v would work.

The gavToPath method is only used in the case of manualInclude, which works 
without considering project dependencies.




  Kommentar 
hinzufügen

  Kommentar 
hinzufügen 


  



Diese Nachricht wurde von Atlassian JIRA übermittelt 
(v6.4.14#64029-sha1:ae256fe) 


Atlassian logo

 



> include not matching for custom types
> -
>
> Key: MDEP-574
> URL: https://issues.apache.org/jira/browse/MDEP-574
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: purge-local-repository
>Affects Versions: 3.0.1
> Environment: Win 7, 64 Bit, JDK 8u92, MVN 3.5.0, MDEP 3.0.1
>Reporter: Markus Karg
>
> Apparently MDEP's purge-local-repository cannot explicitly include 
> dependencies with custom types, like "de.quipsy:qsstatoleobject-pbd:pbd", 
> because (according to the javadocs of private String gavToPath( String gav )) 
> the goal's private coordiante parser expects g:a:v, while the actual 
> coordinates of this include are g:a:t:v.
> Effectively this render  not mathing anything.
> Workaround: Do not use includes, but simply purge ALL dependencies (in this 
> case, the artifact is correctly found, and in debug mode also is correctly 
> reported as "Puring artifact: g:a:t:v".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MDEP-574) include not matching for custom types

[Markus Karg (JIRA)]

Markus Karg created MDEP-574:


 Summary: include not matching for custom types
 Key: MDEP-574
 URL: https://issues.apache.org/jira/browse/MDEP-574
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: purge-local-repository
Affects Versions: 3.0.1
 Environment: Win 7, 64 Bit, JDK 8u92, MVN 3.5.0, MDEP 3.0.1
Reporter: Markus Karg


Apparently MDEP's purge-local-repository cannot explicitly include dependencies 
with custom types, like "de.quipsy:qsstatoleobject-pbd:pbd", because (according 
to the javadocs of private String gavToPath( String gav )) the goal's private 
coordiante parser expects g:a:v, while the actual coordinates of this include 
are g:a:t:v.

Effectively this render  not mathing anything.

Workaround: Do not use includes, but simply purge ALL dependencies (in this 
case, the artifact is correctly found, and in debug mode also is correctly 
reported as "Puring artifact: g:a:t:v".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MDEP-573) "purge-local-repository -Dinclude" does not work as described

[Markus Karg (JIRA)]

Markus Karg created MDEP-573:


 Summary: "purge-local-repository -Dinclude" does not work as 
described
 Key: MDEP-573
 URL: https://issues.apache.org/jira/browse/MDEP-573
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: purge-local-repository
Affects Versions: 3.0.1
 Environment: Win 7, 64 Bit, JDK 8u92, MVN 3.5.0, MDEP 3.0.1
Reporter: Markus Karg


When I run _mvn generate-sources_ on a POM which binds the goal 
_purge-local-repository_ to that phase, then MDEP correctly purges and 
re-resolves the all dependencies of all submodules.

When I instead run _mvn dependency:purge-local-repository_ then the reactor 
*skips* all submodules.

This in rather annoying and surprising, because nowhere in the public 
description of MDEP is told that invoking _dependency:purge-local-repository_ 
at the command line as the sole goal will effectively *skip submodules* of the 
POM.

If this is not intended, this bug should get fixed.

If this is intended, then the documentation of this goal should clearly tell 
that.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MNG-6142) Support for additional coordinate to identify branches, editions, private builds, etc.

[Markus Karg (JIRA)]

Markus Karg created MNG-6142:


 Summary: Support for additional  coordinate to identify 
branches, editions, private builds, etc.
 Key: MNG-6142
 URL: https://issues.apache.org/jira/browse/MNG-6142
 Project: Maven
  Issue Type: Wish
  Components: core
Reporter: Markus Karg


Often development teams work on parallel variants (a.k.a branches) ontop of the 
same base version. Maven currently has no support for such scenarios, which is 
problematic, as the following example describes:

A team of three developers just released version "1.0.0" of a library, which is 
used by a larger application. The version was now set to 1.1.0-SNAPSHOT for the 
master branch, and 1.0.1-SNAPSHOT for the Long-Term-Support branch. Now in that 
team, programmer A started to work on feature A. In the same team, programmer B 
started to work on feature B, which is concurrent (!) to feature A. The team 
lead, programmer C, will later decide which (!) of both features (A _or_ B) he 
wants to get in the final release 1.0.0. To try out each of the features, he 
sets 1.1.0-SNAPSHOT as the dependency version in his test application, to pull 
in the latest version of the library. The problem is: How (by means of POM 
coordinates) to decide which proposed feature to pull, A or B?

Similar scenarios often happen whilst the development of large systems. There 
is no real solution here, as group, artifact, and version are the same for all 
variants of the next development iteration, but only the _variant_ (a.k.a 
"branch") of the artifact is different.

Why not simply reusing the existing coordinatest?
- groupdId: A variant is a different timeline within an artifact, so changing 
the group is irrational.
- artifactId: Variants are, just like versions, changes _of_ artifacts, not 
_different_ artifacts. Certainly, this is the most rational workaround.
- version: Existing tools depend on the major.minor.build-qualifier schema, and 
rely upon semantic interpretation that qualifiers are _sorted_, so feature A 
would become "older" than feature "B", which is completely weird, as both have 
the same age.
- classifier: Classifiers are needed in addition to variants, for example both 
A and B shall publish javadoc and sources, so this would break existing 
features.

To sum up, using the existing coordinates implies major drawbacks or even 
breaks existing features. Also, it is counterintuitive, as a variant implies a 
separate timeline, neither a new group or artifact, nor a sequence on one 
shared same timeline.

Hence, to improve actual current workflow scenarios, I'd like to propose the 
addition of an optional  coordinate. The interpretation should be like 
this:
*  is optional.
* , if existing, is added to the default file name between 
 and  (e. g. mylib-featureB-1.0.0-SNAPSHOT-javadoc.jar).
* , if given, implies that a dependency with variant V of artifact A, 
will can only be satisfied with exact that coordinates, neither with artifact 
"A-V", nor with A having no version. On the other hand, just as with versions, 
a dependency not having a variant, is happy with _any_ variant of the same 
artifact, unless the variant is marked as "exactly this" using brackets [V].

Adding support using these rules would allow tool / plugin vendors to greatly 
support dealing with branches, e. g. in git and subversion, by better 
understand dependencies on features, differences between branches, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-6048) Maven-Shared: Java7Support silently fails overwriting symlinks

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15338816#comment-15338816
 ] 

Markus Karg commented on MNG-6048:
--

Fix available at https://github.com/apache/maven-shared/pull/12

> Maven-Shared: Java7Support silently fails overwriting symlinks
> --
>
> Key: MNG-6048
> URL: https://issues.apache.org/jira/browse/MNG-6048
> Project: Maven
>  Issue Type: Bug
>  Components: Errors
>Reporter: Markus Karg
>Priority: Critical
>
> When A is an existing symlink to B, then createSymbolicLink(A,C) does
> neither overwrite A->B by A->C (as expected in analogy to the behavior
> of copy(A,C)) nor does it throw an exception nor does it return A->B to
> indicate the failure, but it actually "silently fails", i. e. it returns
> A->C!
> This certainly is heavily problematic, unsymmetric to what
> copy(File,File) and Files.createSymbolicLink(Path,Path) do, and
> certainly unwanted and buggy behavior.
> The solution is to delete any existing target before creating the
> symlic, hence copying the behavior of copy(File,File).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MNG-6048) Maven-Shared: Java7Support silently fails overwriting symlinks

[Markus Karg (JIRA)]

Markus Karg created MNG-6048:


 Summary: Maven-Shared: Java7Support silently fails overwriting 
symlinks
 Key: MNG-6048
 URL: https://issues.apache.org/jira/browse/MNG-6048
 Project: Maven
  Issue Type: Bug
  Components: Errors
Reporter: Markus Karg
Priority: Critical


When A is an existing symlink to B, then createSymbolicLink(A,C) does
neither overwrite A->B by A->C (as expected in analogy to the behavior
of copy(A,C)) nor does it throw an exception nor does it return A->B to
indicate the failure, but it actually "silently fails", i. e. it returns
A->C!

This certainly is heavily problematic, unsymmetric to what
copy(File,File) and Files.createSymbolicLink(Path,Path) do, and
certainly unwanted and buggy behavior.

The solution is to delete any existing target before creating the
symlic, hence copying the behavior of copy(File,File).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MRELEASE-956) Release Strategy Interface

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336851#comment-15336851
 ] 

Markus Karg commented on MRELEASE-956:
--

Sounds good. I will set up a PR and report here. Stay tuned. :-)

> Release Strategy Interface
> --
>
> Key: MRELEASE-956
> URL: https://issues.apache.org/jira/browse/MRELEASE-956
> Project: Maven Release Plugin
>  Issue Type: New Feature
>  Components: perform
>Reporter: Markus Karg
>  Labels: strategy
>
> The release plugin has built-in strategies for preparation and performing of 
> a release. For example, the strategy for preparation contains increasing 
> versions numbers, comitting to SCM, tagging in SCM, and so.
> Not all users share the same strategies in real life. For example, some 
> companies might want to have a tag AND and a branch created in SCM when 
> preparing a release. Or other companies might want to have tag created for 
> "prepared-release-1.0.0" at preparation, and replace it by "release-1.0.0" as 
> part of release:perform.
> To provide better flexibility of such company-wide strategies, it might be a 
> solution to introduce an interface "ReleaseStrategy" which acts as a worker 
> for the prepare and perform goals (and possibly others). The current built-in 
> strategy could be refactored to be a default-included 
> "DefaultReleaseStrategy" for backwards compatibility, while users could 
> configure a new property "releaseStrategy" to point to an Extension which 
> provides a differently working strategy.
> To make this work, certainly the Strategy implementation needs to get passed 
> a context which allows to fire actions like "tag version", "create branch", 
> "change pom version" and so on, just as the current built-in strategy has.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MRELEASE-956) Release Strategy Interface

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336580#comment-15336580
 ] 

Markus Karg commented on MRELEASE-956:
--

If you like I could provide a PR on GitHub as an early draft.

> Release Strategy Interface
> --
>
> Key: MRELEASE-956
> URL: https://issues.apache.org/jira/browse/MRELEASE-956
> Project: Maven Release Plugin
>  Issue Type: New Feature
>  Components: perform
>Reporter: Markus Karg
>  Labels: strategy
>
> The release plugin has built-in strategies for preparation and performing of 
> a release. For example, the strategy for preparation contains increasing 
> versions numbers, comitting to SCM, tagging in SCM, and so.
> Not all users share the same strategies in real life. For example, some 
> companies might want to have a tag AND and a branch created in SCM when 
> preparing a release. Or other companies might want to have tag created for 
> "prepared-release-1.0.0" at preparation, and replace it by "release-1.0.0" as 
> part of release:perform.
> To provide better flexibility of such company-wide strategies, it might be a 
> solution to introduce an interface "ReleaseStrategy" which acts as a worker 
> for the prepare and perform goals (and possibly others). The current built-in 
> strategy could be refactored to be a default-included 
> "DefaultReleaseStrategy" for backwards compatibility, while users could 
> configure a new property "releaseStrategy" to point to an Extension which 
> provides a differently working strategy.
> To make this work, certainly the Strategy implementation needs to get passed 
> a context which allows to fire actions like "tag version", "create branch", 
> "change pom version" and so on, just as the current built-in strategy has.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MRELEASE-956) Release Strategy Interface

[Markus Karg (JIRA)]

Markus Karg created MRELEASE-956:


 Summary: Release Strategy Interface
 Key: MRELEASE-956
 URL: https://issues.apache.org/jira/browse/MRELEASE-956
 Project: Maven Release Plugin
  Issue Type: New Feature
  Components: perform
Reporter: Markus Karg


The release plugin has built-in strategies for preparation and performing of a 
release. For example, the strategy for preparation contains increasing versions 
numbers, comitting to SCM, tagging in SCM, and so.

Not all users share the same strategies in real life. For example, some 
companies might want to have a tag AND and a branch created in SCM when 
preparing a release. Or other companies might want to have tag created for 
"prepared-release-1.0.0" at preparation, and replace it by "release-1.0.0" as 
part of release:perform.

To provide better flexibility of such company-wide strategies, it might be a 
solution to introduce an interface "ReleaseStrategy" which acts as a worker for 
the prepare and perform goals (and possibly others). The current built-in 
strategy could be refactored to be a default-included "DefaultReleaseStrategy" 
for backwards compatibility, while users could configure a new property 
"releaseStrategy" to point to an Extension which provides a differently working 
strategy.

To make this work, certainly the Strategy implementation needs to get passed a 
context which allows to fire actions like "tag version", "create branch", 
"change pom version" and so on, just as the current built-in strategy has.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MRELEASE-954) maven-release-plugin should push less often to git server

[Markus Karg (JIRA)]

Markus Karg created MRELEASE-954:


 Summary: maven-release-plugin should push less often to git server
 Key: MRELEASE-954
 URL: https://issues.apache.org/jira/browse/MRELEASE-954
 Project: Maven Release Plugin
  Issue Type: Improvement
  Components: Git
Affects Versions: 2.5.3
Reporter: Markus Karg
Priority: Minor


mvn release:prepare runs three times git push which is bad:

A single push at the end is enough to bring all commits and tags to the server 
finally
It consumes more time than essentially necessary
It is risky, because in case the first POM change A-SNAPSHOT -> A is pushed to 
the server but an error happens (bug in plugin, crash of client, whatever) then 
a "half prepared" state is on the server (the second POM change A -> B-SNAPSHOT 
is missing) and you cannot auto-recover from that without manual action (as mvn 
release:clean does not undo the tag). If there is only one single push at the 
end, then EVERYTHING, two commits and a tag, is pushed as a single transaction 
to the server, which is much better!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MDEP-436) German umlauts in outputDirectory and destFileName getting garbled

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15188953#comment-15188953
 ] 

Markus Karg commented on MDEP-436:
--

I did not find the time to add _configurability_ of encoding to 
maven-dependency-plugin, but worked around using some _static_ encoding 
meanwhile, which works fine. Maybe some other users have the same need, so here 
is what I did in short:

* Download source code of maven-dependency-plugin 2.10

* Patch the source file AbstractDependencyMojo in the following way:

...
UnArchiver unArchiver;

try
{
unArchiver = archiverManager.getUnArchiver( artifact.getType() 
);
getLog().debug( "Found unArchiver by type: " + unArchiver );
}
catch ( NoSuchArchiverException e )
{
unArchiver = archiverManager.getUnArchiver( file );
getLog().debug( "Found unArchiver by extension: " + unArchiver 
);
}

// BEGIN OF PATCH
if ( unArchiver instanceof AbstractZipUnArchiver )
{
( ( AbstractZipUnArchiver ) unArchiver ).setEncoding( "CP850" );
getLog().warn( "Custom dependency plugin: Always uses encoding 
'CP850' for unpacking." );
}
// END OF PATCH

unArchiver.setUseJvmChmod( useJvmChmod );
...

* In the POM set version to "2.10_CP850_PATCH".
* mvn install
* In your projects explicitly request version "2.10_CP850_PATCH"

Works for me, and relaxes the time until there is configurability. :-)

HTH
-Markus

> German umlauts in outputDirectory and destFileName getting garbled
> --
>
> Key: MDEP-436
> URL: https://issues.apache.org/jira/browse/MDEP-436
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy
>Affects Versions: 2.8
> Environment: Win7 Pro SP1 64 Bit, JRE 7, MVN 3.0.4
>Reporter: Markus Karg
>Assignee: Kristian Rosenvold
>Priority: Critical
> Fix For: 2.10
>
>
> I am using German umlauts like Ä, Ö and Ü in my POM when configuring the 
> outputDirectory and destFileName properties of the copy goal.
> When the plugin does the actual copy, the directory and file do not contain 
> that umlauts, but instead a strange symbol (encoding garbage).
> It seems the plugin is unable to deal with German umlauts. While Java 
> definitively IS able to correctly handle it, and while the POM is encoded in 
> UTF-8, it is definitively a bug of a Maven component. As I do not know which 
> component fails here, I am reporting it at the failing plugin, as it is the 
> entry-point for me.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5847) Maven controls java.library.path

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14608629#comment-14608629
 ] 

Markus Karg commented on MNG-5847:
--

The is simply is not true. The Maven framework is able to handle any kind of 
dependencies and artifacts type, be it JAR, ZIP, EXE, DLL, MSI or whatever you 
like. And no, I explicitly like to discuss my proposal and nothing else as this 
is the Maven tracker and not a public discussion forum for anything dealing 
with modules.

 Maven controls java.library.path
 

 Key: MNG-5847
 URL: https://issues.apache.org/jira/browse/MNG-5847
 Project: Maven
  Issue Type: Wish
Reporter: Markus Karg
  Labels: dill, jni, lib, native, so

 We have many Java projects that are dependent of other Java projects which 
 make use of JNI. Hence, when we do mvn test in our project, we fail 
 frequently as the native part of the dependency is missing, even if we 
 declare the native part as an explicit dependency. There are several ideas 
 how to solve that, but non of them is complete or sufficient.
 The solution users expect would look like this:
 * MyProject has one dependency to OtherProject of type*/type (asterisk 
 means: Maven selects best fit).
 * OtherProject offers many different packages, e. g. win-x86-dll, 
 win-x64-dll, linux-so-64, etc.
 * When doing mvn test on MyProject, Maven checks ALL exiting packages for the 
 dependency's coordinates, and select that package that is the best fit for 
 the current execution enviroment. For example, it select win-x86-dll when 
 run on Windows (32 Bit), or selects linux-so-64 when run on Linux (64 Bit) 
 etc. This mechanism should be extensible by future extension plugin, so a 
 third party vendor can simply provide addtional mappings via Maven Central.
 * Just as Maven does a configuration of the ClassPath from all JAR 
 dependencies, it now will now do a configuration of all native dependencies. 
 That means, it copies the selected native dependencies to target/dependencies 
 and builds a synthetic java.library.path system property.
 * As a result, adding a native dependency will work on any platform without 
 any complex pom.xml tweaks.
 * The solution shall not be a Java-only solution, but it shall work with any 
 kind of toolset. So a toolset plugin shall be able to utilize the core 
 mechanism and adapt it to its own needs, which includes for example the fact 
 that setting java.library.path is job of the Java Toolset Plugin, while 
 providing a similar lookup mechanism is job a hypothetical different Toolset 
 Plugin.
 We would really beg the Maven team to provide such a solution, as JNI is an 
 integral part of Java for really long time, and we have this problem every 
 other day.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5847) Maven controls java.library.path

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14606331#comment-14606331
 ] 

Markus Karg commented on MNG-5847:
--

You seem to completely misunderstood my proposal, as it solely is about 
improving CoC. Profiles and classifiers enforce a real lot of explicit, manual, 
error-prone configuration, and do not solve the original problem, as there is 
simply no offical Maven way to tell in a pom the general idea of put those 
native stuff on the native classpath, not on the Java classpath. If you think 
you can solve that in less than 50 lines of explicit and totally bad-to-read 
XML configuration clutter, I'd be glad to see your solution. My proposal is 
about exactly that. :-)

 Maven controls java.library.path
 

 Key: MNG-5847
 URL: https://issues.apache.org/jira/browse/MNG-5847
 Project: Maven
  Issue Type: Wish
Reporter: Markus Karg
  Labels: dill, jni, lib, native, so

 We have many Java projects that are dependent of other Java projects which 
 make use of JNI. Hence, when we do mvn test in our project, we fail 
 frequently as the native part of the dependency is missing, even if we 
 declare the native part as an explicit dependency. There are several ideas 
 how to solve that, but non of them is complete or sufficient.
 The solution users expect would look like this:
 * MyProject has one dependency to OtherProject of type*/type (asterisk 
 means: Maven selects best fit).
 * OtherProject offers many different packages, e. g. win-x86-dll, 
 win-x64-dll, linux-so-64, etc.
 * When doing mvn test on MyProject, Maven checks ALL exiting packages for the 
 dependency's coordinates, and select that package that is the best fit for 
 the current execution enviroment. For example, it select win-x86-dll when 
 run on Windows (32 Bit), or selects linux-so-64 when run on Linux (64 Bit) 
 etc. This mechanism should be extensible by future extension plugin, so a 
 third party vendor can simply provide addtional mappings via Maven Central.
 * Just as Maven does a configuration of the ClassPath from all JAR 
 dependencies, it now will now do a configuration of all native dependencies. 
 That means, it copies the selected native dependencies to target/dependencies 
 and builds a synthetic java.library.path system property.
 * As a result, adding a native dependency will work on any platform without 
 any complex pom.xml tweaks.
 * The solution shall not be a Java-only solution, but it shall work with any 
 kind of toolset. So a toolset plugin shall be able to utilize the core 
 mechanism and adapt it to its own needs, which includes for example the fact 
 that setting java.library.path is job of the Java Toolset Plugin, while 
 providing a similar lookup mechanism is job a hypothetical different Toolset 
 Plugin.
 We would really beg the Maven team to provide such a solution, as JNI is an 
 integral part of Java for really long time, and we have this problem every 
 other day.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5847) Maven controls java.library.path

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604717#comment-14604717
 ] 

Markus Karg commented on MNG-5847:
--

Intentionally not, as it is the diametrical approach to my proposal.

 Maven controls java.library.path
 

 Key: MNG-5847
 URL: https://issues.apache.org/jira/browse/MNG-5847
 Project: Maven
  Issue Type: Wish
Reporter: Markus Karg
  Labels: dill, jni, lib, native, so

 We have many Java projects that are dependent of other Java projects which 
 make use of JNI. Hence, when we do mvn test in our project, we fail 
 frequently as the native part of the dependency is missing, even if we 
 declare the native part as an explicit dependency. There are several ideas 
 how to solve that, but non of them is complete or sufficient.
 The solution users expect would look like this:
 * MyProject has one dependency to OtherProject of type*/type (asterisk 
 means: Maven selects best fit).
 * OtherProject offers many different packages, e. g. win-x86-dll, 
 win-x64-dll, linux-so-64, etc.
 * When doing mvn test on MyProject, Maven checks ALL exiting packages for the 
 dependency's coordinates, and select that package that is the best fit for 
 the current execution enviroment. For example, it select win-x86-dll when 
 run on Windows (32 Bit), or selects linux-so-64 when run on Linux (64 Bit) 
 etc. This mechanism should be extensible by future extension plugin, so a 
 third party vendor can simply provide addtional mappings via Maven Central.
 * Just as Maven does a configuration of the ClassPath from all JAR 
 dependencies, it now will now do a configuration of all native dependencies. 
 That means, it copies the selected native dependencies to target/dependencies 
 and builds a synthetic java.library.path system property.
 * As a result, adding a native dependency will work on any platform without 
 any complex pom.xml tweaks.
 * The solution shall not be a Java-only solution, but it shall work with any 
 kind of toolset. So a toolset plugin shall be able to utilize the core 
 mechanism and adapt it to its own needs, which includes for example the fact 
 that setting java.library.path is job of the Java Toolset Plugin, while 
 providing a similar lookup mechanism is job a hypothetical different Toolset 
 Plugin.
 We would really beg the Maven team to provide such a solution, as JNI is an 
 integral part of Java for really long time, and we have this problem every 
 other day.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5847) Maven controls java.library.path

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14603105#comment-14603105
 ] 

Markus Karg commented on MNG-5847:
--

Ok so it should be enough to just provide the consuming part of the example. 
I'll set up a project and publish it here. :-)

 Maven controls java.library.path
 

 Key: MNG-5847
 URL: https://issues.apache.org/jira/browse/MNG-5847
 Project: Maven
  Issue Type: Wish
Reporter: Markus Karg
  Labels: dill, jni, lib, native, so

 We have many Java projects that are dependent of other Java projects which 
 make use of JNI. Hence, when we do mvn test in our project, we fail 
 frequently as the native part of the dependency is missing, even if we 
 declare the native part as an explicit dependency. There are several ideas 
 how to solve that, but non of them is complete or sufficient.
 The solution users expect would look like this:
 * MyProject has one dependency to OtherProject of type*/type (asterisk 
 means: Maven selects best fit).
 * OtherProject offers many different packages, e. g. win-x86-dll, 
 win-x64-dll, linux-so-64, etc.
 * When doing mvn test on MyProject, Maven checks ALL exiting packages for the 
 dependency's coordinates, and select that package that is the best fit for 
 the current execution enviroment. For example, it select win-x86-dll when 
 run on Windows (32 Bit), or selects linux-so-64 when run on Linux (64 Bit) 
 etc. This mechanism should be extensible by future extension plugin, so a 
 third party vendor can simply provide addtional mappings via Maven Central.
 * Just as Maven does a configuration of the ClassPath from all JAR 
 dependencies, it now will now do a configuration of all native dependencies. 
 That means, it copies the selected native dependencies to target/dependencies 
 and builds a synthetic java.library.path system property.
 * As a result, adding a native dependency will work on any platform without 
 any complex pom.xml tweaks.
 * The solution shall not be a Java-only solution, but it shall work with any 
 kind of toolset. So a toolset plugin shall be able to utilize the core 
 mechanism and adapt it to its own needs, which includes for example the fact 
 that setting java.library.path is job of the Java Toolset Plugin, while 
 providing a similar lookup mechanism is job a hypothetical different Toolset 
 Plugin.
 We would really beg the Maven team to provide such a solution, as JNI is an 
 integral part of Java for really long time, and we have this problem every 
 other day.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MNG-5847) Maven controls java.library.path

[Markus Karg (JIRA)]

Markus Karg created MNG-5847:


 Summary: Maven controls java.library.path
 Key: MNG-5847
 URL: https://issues.apache.org/jira/browse/MNG-5847
 Project: Maven
  Issue Type: Wish
Reporter: Markus Karg


We have many Java projects that are dependent of other Java projects which make 
use of JNI. Hence, when we do mvn test in our project, we fail frequently as 
the native part of the dependency is missing, even if we declare the native 
part as an explicit dependency. There are several ideas how to solve that, but 
non of them is complete or sufficient.

The solution users expect would look like this:

* MyProject has one dependency to OtherProject of type*/type (asterisk 
means: Maven selects best fit).
* OtherProject offers many different packages, e. g. win-x86-dll, win-x64-dll, 
linux-so-64, etc.
* When doing mvn test on MyProject, Maven checks ALL exiting packages for the 
dependency's coordinates, and select that package that is the best fit for the 
current execution enviroment. For example, it select win-x86-dll when run on 
Windows (32 Bit), or selects linux-so-64 when run on Linux (64 Bit) etc. This 
mechanism should be extensible by future extension plugin, so a third party 
vendor can simply provide addtional mappings via Maven Central.
* Just as Maven does a configuration of the ClassPath from all JAR 
dependencies, it now will now do a configuration of all native dependencies. 
That means, it copies the selected native dependencies to target/dependencies 
and builds a synthetic java.library.path system property.
* As a result, adding a native dependency will work on any platform without any 
complex pom.xml tweaks.
* The solution shall not be a Java-only solution, but it shall work with any 
kind of toolset. So a toolset plugin shall be able to utilize the core 
mechanism and adapt it to its own needs, which includes for example the fact 
that setting java.library.path is job of the Java Toolset Plugin, while 
providing a similar lookup mechanism is job a hypothetical different Toolset 
Plugin.

We would really beg the Maven team to provide such a solution, as JNI is an 
integral part of Java for really long time, and we have this problem every 
other day.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5847) Maven controls java.library.path

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14601784#comment-14601784
 ] 

Markus Karg commented on MNG-5847:
--

How should this look like? Do you really want me to set up a mixed C / Java 
multi-module project, or would it be enough to provide a hypothetical pom.xml 
declaring an abstract dependency to a DLL?

 Maven controls java.library.path
 

 Key: MNG-5847
 URL: https://issues.apache.org/jira/browse/MNG-5847
 Project: Maven
  Issue Type: Wish
Reporter: Markus Karg
  Labels: dill, jni, lib, native, so

 We have many Java projects that are dependent of other Java projects which 
 make use of JNI. Hence, when we do mvn test in our project, we fail 
 frequently as the native part of the dependency is missing, even if we 
 declare the native part as an explicit dependency. There are several ideas 
 how to solve that, but non of them is complete or sufficient.
 The solution users expect would look like this:
 * MyProject has one dependency to OtherProject of type*/type (asterisk 
 means: Maven selects best fit).
 * OtherProject offers many different packages, e. g. win-x86-dll, 
 win-x64-dll, linux-so-64, etc.
 * When doing mvn test on MyProject, Maven checks ALL exiting packages for the 
 dependency's coordinates, and select that package that is the best fit for 
 the current execution enviroment. For example, it select win-x86-dll when 
 run on Windows (32 Bit), or selects linux-so-64 when run on Linux (64 Bit) 
 etc. This mechanism should be extensible by future extension plugin, so a 
 third party vendor can simply provide addtional mappings via Maven Central.
 * Just as Maven does a configuration of the ClassPath from all JAR 
 dependencies, it now will now do a configuration of all native dependencies. 
 That means, it copies the selected native dependencies to target/dependencies 
 and builds a synthetic java.library.path system property.
 * As a result, adding a native dependency will work on any platform without 
 any complex pom.xml tweaks.
 * The solution shall not be a Java-only solution, but it shall work with any 
 kind of toolset. So a toolset plugin shall be able to utilize the core 
 mechanism and adapt it to its own needs, which includes for example the fact 
 that setting java.library.path is job of the Java Toolset Plugin, while 
 providing a similar lookup mechanism is job a hypothetical different Toolset 
 Plugin.
 We would really beg the Maven team to provide such a solution, as JNI is an 
 integral part of Java for really long time, and we have this problem every 
 other day.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MSHADE-196) Must not attempt to unzip unfamiliar dependency type

[Markus Karg (JIRA)]

Markus Karg created MSHADE-196:
--

 Summary: Must not attempt to unzip unfamiliar dependency type
 Key: MSHADE-196
 URL: https://issues.apache.org/jira/browse/MSHADE-196
 Project: Maven Shade Plugin
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Markus Karg


When adding dependencies to rather unconventional package types, like dll or 
pdf, we noticed that the share plugin by default tries to unzip them. This is 
weird, as obviously this attempt will fail in almost any case. A user is forced 
to add explicit exceptions, which is tedious, error prone, and breaks CoC.

The solution is rather obvious: The shade plugin must only unzip those package 
types which it is familiar with. This namely is e. g. JAR, ZIP, BZIP, GZIP etc. 
but certainly not anything unknown.

The result of this change will be a simplification of the pom.xml, and shade 
plugin's behaviour will be more like a user expects it to work: Don't touch 
unkown stuff!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MDEP-442) Failed to access file due to locked access when using more than one Maven worker thread

[Markus Karg (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522924#comment-14522924
 ] 

Markus Karg commented on MDEP-442:
--

Jenkins is configured to run only one instance of the job. The problem was not 
triggered by parallel execution of that job, but by using multiple threads for 
that single job. The modules of the maven project access the same dependency, 
which seems to be not thread safe. It works well with one worker job, but not 
with many. It has nothing to do with Jenkins, and happens sporadically.

 Failed to access file due to locked access when using more than one Maven 
 worker thread
 ---

 Key: MDEP-442
 URL: https://issues.apache.org/jira/browse/MDEP-442
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: copy
Affects Versions: 2.8
 Environment: MVN 3.0.4, JDK 1.7, Win 7 Pro SP1 64 Bit
Reporter: Markus Karg
Priority: Critical
 Fix For: waiting-for-feedback

 Attachments: maven-thread-test-update.zip, maven-thread-test.zip


 My multi-module POM contains of ten modules. Each of that modules does the 
 same: Invoke the 'copy' goal of the dependency plugin. The idea is to have 
 ten copies of the identical source, which then will end up in ten different 
 targets by getting furthere processed.
 As long as I do not use more than one Maven worker thread, everything works 
 well always. But when using -T 5 to have five worker threads, rather often 
 the reactor fails because the source file (!) is locked:
 {noformat}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-dependency-plugin:2.8:copy (copy) on project 
 MYARTIFACT: Unable to resolve artifact. Could not transfer artifact 
 mygroup:myartifact:dll:4.36.1-20140415.143537-37 from/to nexus 
 (http://nexus/nexus/content/groups/public): 
 C:\Users\jenkins.QUIPSY\.m2\repository\mygroup\myartifact\4.36.1-SNAPSHOT\myartifact-4.36.1-20140415.143537-37.dll
  (The process cannot access the file, because it is in use by another process)
 {noformat}
 So it seems that the 'copy' task actually is locking the source file, which 
 is not multi-threading-compatible. Hence, either that is a bug and should get 
 fixed, or it is on purpose, then this goal has to be marked as 
 non-multithreading-able.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] (MDEP-436) German umlauts in outputDirectory and destFileName getting garbled

[Markus KARG (JIRA)]

[ 
https://jira.codehaus.org/browse/MDEP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365132#comment-365132
 ] 

Markus KARG commented on MDEP-436:
--

Yes this issue talks solely about ZIP but definitively not about JAR.

 German umlauts in outputDirectory and destFileName getting garbled
 --

 Key: MDEP-436
 URL: https://jira.codehaus.org/browse/MDEP-436
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: copy
Affects Versions: 2.8
 Environment: Win7 Pro SP1 64 Bit, JRE 7, MVN 3.0.4
Reporter: Markus KARG
Assignee: Kristian Rosenvold
Priority: Critical
 Fix For: 2.10


 I am using German umlauts like Ä, Ö and Ü in my POM when configuring the 
 outputDirectory and destFileName properties of the copy goal.
 When the plugin does the actual copy, the directory and file do not contain 
 that umlauts, but instead a strange symbol (encoding garbage).
 It seems the plugin is unable to deal with German umlauts. While Java 
 definitively IS able to correctly handle it, and while the POM is encoded in 
 UTF-8, it is definitively a bug of a Maven component. As I do not know which 
 component fails here, I am reporting it at the failing plugin, as it is the 
 entry-point for me.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MDEP-436) German umlauts in outputDirectory and destFileName getting garbled

[Markus KARG (JIRA)]

[ 
https://jira.codehaus.org/browse/MDEP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365132#comment-365132
 ] 

Markus KARG edited comment on MDEP-436 at 3/17/15 3:53 AM:
---

Yes this issue talks solely about ZIP but definitively not about JAR. To be 
more specific, the copy target is working well since recent plexus changes, 
but solely the unpack target for ZIPs still faces this issue.

A possible solution could look like this:

configuration
encodingCP850/encoding
/configuration


was (Author: mkarg):
Yes this issue talks solely about ZIP but definitively not about JAR.

 German umlauts in outputDirectory and destFileName getting garbled
 --

 Key: MDEP-436
 URL: https://jira.codehaus.org/browse/MDEP-436
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: copy
Affects Versions: 2.8
 Environment: Win7 Pro SP1 64 Bit, JRE 7, MVN 3.0.4
Reporter: Markus KARG
Assignee: Kristian Rosenvold
Priority: Critical
 Fix For: 2.10


 I am using German umlauts like Ä, Ö and Ü in my POM when configuring the 
 outputDirectory and destFileName properties of the copy goal.
 When the plugin does the actual copy, the directory and file do not contain 
 that umlauts, but instead a strange symbol (encoding garbage).
 It seems the plugin is unable to deal with German umlauts. While Java 
 definitively IS able to correctly handle it, and while the POM is encoded in 
 UTF-8, it is definitively a bug of a Maven component. As I do not know which 
 component fails here, I am reporting it at the failing plugin, as it is the 
 entry-point for me.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MDEP-481) destFileName is getting ignored

[Markus KARG (JIRA)]

Markus KARG created MDEP-481:


 Summary: destFileName is getting ignored
 Key: MDEP-481
 URL: https://jira.codehaus.org/browse/MDEP-481
 Project: Maven Dependency Plugin
  Issue Type: Bug
Affects Versions: 2.10
 Environment: Win 7 Pro SP1, 64 Bit, JDK 8u40
Reporter: Markus KARG


With the following configuration, the entry destFileName is getting ignored, 
but the original name as matched by the includes pattern is used for the 
destination file name:

artifactItem
groupIdg/groupId
artifactIda/artifactId
typet/type
includesprefix*suffix.ext/includes
destFileNamename.ext/destFileName
/artifactItem

This is problematic in case the exact file name is unknown or irrelevant, e. g. 
if a file shall be picked by prefix solely, while the suffix (version, 
classifier, etc.) are irrelevant, as the destFileName would leave out suffix 
anyways.

As it is the POM author's responsibility to not overwrite files, the default 
behaviour should not be to ignore destFileName in case of multiple pattern 
matches, but the files should simply auto-overwrite each other. Typically the 
default use case where a POM author would use patterns and destFileName at the 
same time, anyways is when he knows for sure there is can be only one match.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MDEP-436) German umlauts in outputDirectory and destFileName getting garbled

[Markus KARG (JIRA)]

[ 
https://jira.codehaus.org/browse/MDEP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365082#comment-365082
 ] 

Markus KARG commented on MDEP-436:
--

According to Kristian Rosenvold this issue is NOT fixed and CP850 won't work 
(only UTF-8 will). So I'd like to kindly ask to reopen and fix this issue, 
which is really important to Windows users, as Windows can only display ZIPs 
encoded as CP850. :-)

 German umlauts in outputDirectory and destFileName getting garbled
 --

 Key: MDEP-436
 URL: https://jira.codehaus.org/browse/MDEP-436
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: copy
Affects Versions: 2.8
 Environment: Win7 Pro SP1 64 Bit, JRE 7, MVN 3.0.4
Reporter: Markus KARG
Assignee: Kristian Rosenvold
Priority: Critical
 Fix For: 2.10


 I am using German umlauts like Ä, Ö and Ü in my POM when configuring the 
 outputDirectory and destFileName properties of the copy goal.
 When the plugin does the actual copy, the directory and file do not contain 
 that umlauts, but instead a strange symbol (encoding garbage).
 It seems the plugin is unable to deal with German umlauts. While Java 
 definitively IS able to correctly handle it, and while the POM is encoded in 
 UTF-8, it is definitively a bug of a Maven component. As I do not know which 
 component fails here, I am reporting it at the failing plugin, as it is the 
 entry-point for me.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MDEP-436) German umlauts in outputDirectory and destFileName getting garbled

[Markus KARG (JIRA)]

[ 
https://jira.codehaus.org/browse/MDEP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365064#comment-365064
 ] 

Markus KARG commented on MDEP-436:
--

Can you please append a comment showing how to configure 
maven-dependency-plugin:unpack in a way that will preserve German umlauts of 
file names when the ZIP was created with encodingCP850/encoding? With the 
default configuration  maven-dependency-plugin:unpack actually unpacks garbage! 
.-(

 German umlauts in outputDirectory and destFileName getting garbled
 --

 Key: MDEP-436
 URL: https://jira.codehaus.org/browse/MDEP-436
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: copy
Affects Versions: 2.8
 Environment: Win7 Pro SP1 64 Bit, JRE 7, MVN 3.0.4
Reporter: Markus KARG
Assignee: Kristian Rosenvold
Priority: Critical
 Fix For: 2.10


 I am using German umlauts like Ä, Ö and Ü in my POM when configuring the 
 outputDirectory and destFileName properties of the copy goal.
 When the plugin does the actual copy, the directory and file do not contain 
 that umlauts, but instead a strange symbol (encoding garbage).
 It seems the plugin is unable to deal with German umlauts. While Java 
 definitively IS able to correctly handle it, and while the POM is encoded in 
 UTF-8, it is definitively a bug of a Maven component. As I do not know which 
 component fails here, I am reporting it at the failing plugin, as it is the 
 entry-point for me.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)

[jira] (MNG-5732) Java 9 completely changes JDK directory layout and drops tools.jar

[Markus KARG (JIRA)]

 [ 
https://jira.codehaus.org/browse/MNG-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Markus KARG updated MNG-5732:
-

Description: 
Oracle published plans to drop the existence of tools.jar and totally 
restructure the directory layout of the JDK beginning with JDK 9, including 
changes in the extensions mechanism and location of rt.jar. As a side effect, 
all plugins relying on a particular layout structure and / or the existence of 
tools.jar won't work on JDK 9.

The intention is to move from a histrically grown infrastructure to a layout 
which is clearly documented by JEP 220, hence it can be considered consistent 
on all future JDKs, which is a positive thing, but imposes problems for many 
tool vendors.

As this is a cross-plugin concern, all plugins have to be checked and possibly 
fixed.

For more information see http://openjdk.java.net/jeps/220.

A pre-release of JDK 9 can be downloaded from https://jdk9.java.net/download/.

Oracle is interested to get in touch with projects being currently dependend of 
the existing pre-9 JDK structure. Such projects shall report on the jigsaw-dev 
mailing list.

Some effects in short:

• JRE and JDK images now have identical structures. Previously a JDK 
image embedded the JRE in a jre subdirectory; now a JDK image is simply a 
run-time image that happens to contain the full set of development tools and 
other items historically found in the JDK.

• User-editable configuration files previously located in the lib 
directory are now in the new 'conf' directory. The files that remain in the lib 
directory are private implementation details of the run-time system, and should 
never be opened or modified.

• The endorsed-standards override mechanism has been removed. 
Applications that rely upon this mechanism, either by setting the system 
property java.endorsed.dirs or by placing jar files into the lib/endorsed 
directory of a JRE, will not work. We expect to provide similar functionality 
later in JDK 9 in the form of upgradeable modules.

• The extension mechanism has been removed. Applications that rely upon 
this mechanism, either by setting the system property java.ext.dirs or by 
placing jar files into the lib/ext directory of a JRE, will not work. In most 
cases, jar files that were previously installed as extensions can simply be 
placed at the front of the class path.

• The internal files rt.jar, tools.jar, and dt.jar have been removed. The 
content of these files is now stored in a more efficient format in 
implementation-private files in the lib directory. Class and resource files 
previously in tools.jar and dt.jar are now always visible via the bootstrap or 
application class loaders in a JDK image.

• A new, built-in NIO file-system provider can be used to access the 
class and resource files stored in a run-time image. Tools that previously read 
rt.jar and other internal jar files directly should be updated to use this file 
system.

(Source: December Oracle Java CAP Program Newsletter)

  was:
Oracle published plans to drop the existence of tools.jar and totally 
restructure the directory layout of the JDK beginning with JDK 9, including 
changes in the extensions mechanism and location of rt.jar. As a side effect, 
all plugins relying on a particular layout structure and / or the existence of 
tools.jar won't work on JDK 9.

The intention is to move from a histrically grown infrastructure to a layout 
which is specified by a JSR standard, hence it can be considered consistent on 
all future JDKs even from different vendors, which is a positive thing, but 
imposed problems for many tool vendors.

As this is a cross-plugin concern, all plugins have to be checked and possibly 
fixed.

For more information see http://openjdk.java.net/jeps/220.

A pre-release of JDK 9 can be downloaded from https://jdk9.java.net/download/.

Oracle is interested to get in touch with projects being currently dependend of 
the existing pre-9 JDK structure. Such projects shall report on the jigsaw-dev 
mailing list.

Some effects in short:

• JRE and JDK images now have identical structures. Previously a JDK 
image embedded the JRE in a jre subdirectory; now a JDK image is simply a 
run-time image that happens to contain the full set of development tools and 
other items historically found in the JDK.

• User-editable configuration files previously located in the lib 
directory are now in the new 'conf' directory. The files that remain in the lib 
directory are private implementation details of the run-time system, and should 
never be opened or modified.

• The endorsed-standards override mechanism has been removed. 
Applications that rely upon this mechanism, either by setting the system 
property java.endorsed.dirs or by placing jar files into the lib/endorsed 
directory of a JRE, will not work. We expect to provide similar functionality 
later in 

[jira] (MNG-5732) Java 9 completely changes JDK directory layout and drops tools.jar

[Markus KARG (JIRA)]

Markus KARG created MNG-5732:


 Summary: Java 9 completely changes JDK directory layout and drops 
tools.jar
 Key: MNG-5732
 URL: https://jira.codehaus.org/browse/MNG-5732
 Project: Maven
  Issue Type: Improvement
  Components: General
 Environment: JDK 9
Reporter: Markus KARG
Priority: Blocker


Oracle published plans to drop the existence of tools.jar and totally 
restructure the directory layout of the JDK beginning with JDK 9, including 
changes in the extensions mechanism and location of rt.jar. As a side effect, 
all plugins relying on a particular layout structure and / or the existence of 
tools.jar won't work on JDK 9.

The intention is to move from a histrically grown infrastructure to a layout 
which is specified by a JSR standard, hence it can be considered consistent on 
all future JDKs even from different vendors, which is a positive thing, but 
imposed problems for many tool vendors.

As this is a cross-plugin concern, all plugins have to be checked and possibly 
fixed.

For more information see http://openjdk.java.net/jeps/220.

A pre-release of JDK 9 can be downloaded from https://jdk9.java.net/download/.

Oracle is interested to get in touch with projects being currently dependend of 
the existing pre-9 JDK structure. Such projects shall report on the jigsaw-dev 
mailing list.

Some effects in short:

• JRE and JDK images now have identical structures. Previously a JDK 
image embedded the JRE in a jre subdirectory; now a JDK image is simply a 
run-time image that happens to contain the full set of development tools and 
other items historically found in the JDK.

• User-editable configuration files previously located in the lib 
directory are now in the new 'conf' directory. The files that remain in the lib 
directory are private implementation details of the run-time system, and should 
never be opened or modified.

• The endorsed-standards override mechanism has been removed. 
Applications that rely upon this mechanism, either by setting the system 
property java.endorsed.dirs or by placing jar files into the lib/endorsed 
directory of a JRE, will not work. We expect to provide similar functionality 
later in JDK 9 in the form of upgradeable modules.

• The extension mechanism has been removed. Applications that rely upon 
this mechanism, either by setting the system property java.ext.dirs or by 
placing jar files into the lib/ext directory of a JRE, will not work. In most 
cases, jar files that were previously installed as extensions can simply be 
placed at the front of the class path.

• The internal files rt.jar, tools.jar, and dt.jar have been removed. The 
content of these files is now stored in a more efficient format in 
implementation-private files in the lib directory. Class and resource files 
previously in tools.jar and dt.jar are now always visible via the bootstrap or 
application class loaders in a JDK image.

• A new, built-in NIO file-system provider can be used to access the 
class and resource files stored in a run-time image. Tools that previously read 
rt.jar and other internal jar files directly should be updated to use this file 
system.

(Source: December Oracle Java CAP Program Newsletter)



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)