[jira] [Commented] (MPOM-468) Remove or provide option to disable checksum-maven-plugin

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MPOM-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818080#comment-17818080
 ] 

Christopher Tubbs commented on MPOM-468:


[~michael-o], I'm using the 3.9.6, but I don't know what version was used by 
the release manager who prepared our last release candidate, where I noticed 
the issue. It was my understanding that Nexus created the .md5 and .sha1 files, 
though, not Maven. Perhaps I'm wrong? I really don't know what part creates 
that, because they don't seem to be created when I do `mvn verify` or even `mvn 
install`, so I can't really reproduce except by doing another `deploy`.

Re your general question: it's my understanding that it was added because some 
people had a desire to have Maven generate their SHA512 that was required for 
the SVN/dist area. For projects I'm on, we have no audience for this file 
whatsoever, at least not the one the Mavem build is producing.

I agree with you about how it should be presented in the dist area.

Regarding "Why does it need to be on Central at all?". That's kind of a red 
herring, because even if you intend to delete the source-release artifact, and 
not put it in Maven Central, the generation of these extra checksum files is 
still an added inconvenience. For the purposes of this issue, I think it's fine 
to just accept that there may be some use cases to have source-release 
artifacts in Maven Central, and other use cases where it doesn't make sense. 
It's not really important for this issue, though.

I think [~cstamas] has a really good point. Using this plugin isn't needed at 
all, since Maven 3.9 has the ability to produce sha512 files built-in. So, 
that's another reason to remove it... perhaps even more important than any of 
the reasons I listed.

> Remove or provide option to disable checksum-maven-plugin
> -
>
> Key: MPOM-468
> URL: https://issues.apache.org/jira/browse/MPOM-468
> Project: Maven POMs
>  Issue Type: Bug
>  Components: asf
>Affects Versions: ASF-31
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Currently, the net.nicoulaj.maven.plugins:checksum-maven-plugin is used to 
> generate .sha512 files for the source-release classifier artifact in the 
> apache-release profile.
> There are many problems with this plugin that justify removing it or making 
> it easier to disable:
> 1. Not everybody wants this. It is intended to help construct SHA512 files in 
> the Nexus staging repository, so people can easily have something to copy 
> over into their DIST area in SVN. But, it's expected that people delete these 
> from the staging repository before releasing the staging repo to Maven 
> central after a successful release vote. Well, not everybody uses this 
> pattern. Some people, like those pushing for MPOM-282, generate sha512 files 
> differently (with the filename, so it can be easily verified with standard 
> tooling). It is inconvenient for this plugin to create extra files in the 
> staging repo that we must deal with, leading to more room for user error 
> during the release process.
> 2. In the case where users actually don't want to modify the staging repo, 
> but actually release the repo with the source-release artifact (there are 
> many use cases for that), this creates more work, because those people only 
> have to remove stuff from the staging repo *because* of this plugin. It 
> doesn't make it more convenient... it makes it less convenient... to do a 
> release.
> 3. It doesn't just generate .sha512 files. It also results in .sha512.md1 and 
> .sha512.sha1 files, which are just excessive to deal with.
> 4. The plugin has not been maintained in 2 years.
> 5. The plugin's website with all of its generated plugin documentation is no 
> longer functional.
> 6. The plugin doesn't appear to have a standard "-DmyPluginPrefix.skip" 
> method of disabling the plugin to bypass it. So, one must specifically 
> override the plugin by duplicating the apache-release profile, and creating 
> an execution with the same ID, but with different config to force it to be 
> overridden.
> 7. None (or very few) of the configuration properties seem to have user 
> properties to set them as a system property or in the POM's properties 
> section. So, that makes it cumbersome to modify the configuration.
> 8. Because of number 7, this ASF parent POM, must set everything in the XML, 
> and since it hasn't created proxy properties to set things indirectly, the 
> only way to override it is to create a local apache-release profile 
> containing the same plugin, with the same execution id, but with different 
> configuration.
> For all of these reasons, and probably more, I think this plugin should be 
> removed from the ASF parent POM. If not that, then it should at least be 
> moved to a 

[jira] [Created] (MPOM-468) Remove or provide option to disable checksum-maven-plugin

[Christopher Tubbs (Jira)]

Christopher Tubbs created MPOM-468:
--

 Summary: Remove or provide option to disable checksum-maven-plugin
 Key: MPOM-468
 URL: https://issues.apache.org/jira/browse/MPOM-468
 Project: Maven POMs
  Issue Type: Bug
  Components: asf
Affects Versions: ASF-31
Reporter: Christopher Tubbs


Currently, the net.nicoulaj.maven.plugins:checksum-maven-plugin is used to 
generate .sha512 files for the source-release classifier artifact in the 
apache-release profile.

There are many problems with this plugin that justify removing it or making it 
easier to disable:

1. Not everybody wants this. It is intended to help construct SHA512 files in 
the Nexus staging repository, so people can easily have something to copy over 
into their DIST area in SVN. But, it's expected that people delete these from 
the staging repository before releasing the staging repo to Maven central after 
a successful release vote. Well, not everybody uses this pattern. Some people, 
like those pushing for MPOM-282, generate sha512 files differently (with the 
filename, so it can be easily verified with standard tooling). It is 
inconvenient for this plugin to create extra files in the staging repo that we 
must deal with, leading to more room for user error during the release process.
2. In the case where users actually don't want to modify the staging repo, but 
actually release the repo with the source-release artifact (there are many use 
cases for that), this creates more work, because those people only have to 
remove stuff from the staging repo *because* of this plugin. It doesn't make it 
more convenient... it makes it less convenient... to do a release.
3. It doesn't just generate .sha512 files. It also results in .sha512.md1 and 
.sha512.sha1 files, which are just excessive to deal with.
4. The plugin has not been maintained in 2 years.
5. The plugin's website with all of its generated plugin documentation is no 
longer functional.
6. The plugin doesn't appear to have a standard "-DmyPluginPrefix.skip" method 
of disabling the plugin to bypass it. So, one must specifically override the 
plugin by duplicating the apache-release profile, and creating an execution 
with the same ID, but with different config to force it to be overridden.
7. None (or very few) of the configuration properties seem to have user 
properties to set them as a system property or in the POM's properties section. 
So, that makes it cumbersome to modify the configuration.
8. Because of number 7, this ASF parent POM, must set everything in the XML, 
and since it hasn't created proxy properties to set things indirectly, the only 
way to override it is to create a local apache-release profile containing the 
same plugin, with the same execution id, but with different configuration.

For all of these reasons, and probably more, I think this plugin should be 
removed from the ASF parent POM. If not that, then it should at least be moved 
to a different profile and disabled by default. If not that, then it should at 
least be moved to a different profile so it can be easily disabled by choice. 
If not that, then at the very least, create a proxy property to set the 
includeClassifiers (and other important options) as properties, so we don't 
have to jump through hoops to try to override and disable this plugin when a 
project doesn't want to use it.

For reference: https://github.com/nicoulaj/checksum-maven-plugin




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

[jira] [Commented] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MJAVADOC-707:


Tried with 3.6.0 and legacyMode seems to work fine.

> Plugin won't work if Automatic-Module-Name is used
> --
>
> Key: MJAVADOC-707
> URL: https://issues.apache.org/jira/browse/MJAVADOC-707
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.2, 3.4.0
>Reporter: Christopher Tubbs
>Priority: Critical
>  Labels: jpms
>
> Using Automatic-Module-Name in a manifest (an intermediate step to help 
> transition to using modules) prevents this plugin from adding the necessary 
> dependencies to the class path, so it can build javadocs.
> maven-compiler-plugin seems to work fine, as does surefire and all the others 
> when Automatic-Module-Name entries appear in a project's jar manifests. 
> However, this plugin, as of 3.3.1, still does not work correctly with these.
> Instead of using the traditional class path, this plugin seems to force 
> treating the project as a module, even though it does not have any 
> module-info.java files, and most of its dependencies have not transitioned to 
> using modules.
> Here's a pull request that demonstrates adding the Automatic-Module-Name to 
> the manifest for a multi-module (Maven module) project, that fails on the 
> javadoc plugin:
> https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and 
> javadoc:jar are known to fail. I did not test with any other mojos.
> Not supporting this feature holds all projects back from being able to 
> transition to modules over time.
> http://branchandbound.net/blog/java/2017/12/automatic-module-name/
> https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules



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

[jira] [Commented] (MNG-5987) Document the algorithm calculating the order of plugin executions inside a phase.

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MNG-5987:


Having a public "priority" field would be wonderful, but if two plugin 
executions are defined for the same phase and priority, documenting the order 
would still be needed, even if it's documented as "not defined" or "arbitrary 
order" (forcing users to set a priority if they care). Another reason having 
that public would be that it would help plugins like sortpom-maven-plugin, to 
organize plugins in the POM without worrying about messing up the execution 
order. Alternatively, it'd be great if "lifecycle phase" was a first-class 
citizen in the POM, with plugins attached to it as children of the phase 
element, rather than this constructed only internally, and obfuscated to users 
by an obscure (and optional) {{}} element inside the execution config. 
This obfuscation is probably the biggest confusion I have to explain to new 
Maven users... they simply don't understand intuitively that Maven is based on 
a lifecycle with attached plugins. Having the lifecycle/phase be a first-class 
citizen in the POM makes this much more intuitive.

> Document the algorithm calculating the order of plugin executions inside a 
> phase.
> -
>
> Key: MNG-5987
> URL: https://issues.apache.org/jira/browse/MNG-5987
> Project: Maven
>  Issue Type: Improvement
>  Components: Documentation:  General
>Reporter: Christian Schulte
>Priority: Critical
>
> Users continuously report issues regarding the order of plugin executions: 
> repeating that *"this order is not expected to be guaranteed inside a phase"* 
> is not convincing for them. (notice that perhaps telling that it *cannot* be 
> guaranteed nor really controlled may be more convincing...)
> The algorithm used to calculate the order of executions performed by Maven 
> needs to be documented:
>  - declaration order in the POM
>  - inheritance merging from parent POM,
>  - merging of profiles and other plugin containers,
>  - the order of executions of multiple executions in the same lifecycle phase,
>  - the sorting by plugin that happens when multiple goals are defined for the 
> same plugin,
>  etc.
> based on Model Building 
> [https://maven.apache.org/ref/current/maven-model-builder/] ...



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

[jira] [Commented] (MASFRES-30) Exclude all CI configuration files

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASFRES-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716517#comment-17716517
 ] 

Christopher Tubbs commented on MASFRES-30:
--

[~michael-o] I'm sure there are plugins that process .git/config as well. I'm 
not sure that makes much of a difference. For me, the question about whether it 
makes sense to exclude them is basically: do I want these in an ASF 
source-release tarball? And the answer is: no, because they only matter in the 
git repo, not the source-release tarball. If they aren't excluded by default... 
how do I exclude them from the source-release tarball assembly, then?

> Exclude all CI configuration files
> --
>
> Key: MASFRES-30
> URL: https://issues.apache.org/jira/browse/MASFRES-30
> Project: Apache Maven Resource Bundles
>  Issue Type: Improvement
>  Components: apache-source-release-assembly-descriptor
>Affects Versions: apache-source-release-assembly-descriptor-1.0.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: apache-resources 1.5
>
>
> Exclude:
> * {{.github}}
> * {{Jenkinsfile}}
> * {{.asf.yaml}}
> * {{.travis.yml}}
> * {{deploySite.sh}}



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

[jira] [Commented] (MASFRES-30) Exclude all CI configuration files

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASFRES-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17712224#comment-17712224
 ] 

Christopher Tubbs commented on MASFRES-30:
--

[~michael-o]  I think I would argue that the .gitignore and .gitattributes 
files are also meta files for git, and also the .git file when in a git 
worktree. All those only have meaning/utility inside a git repository. Inside a 
source artifact with the .git directory removed and the git aspect removed, 
they have no value, similar to the IDE files.

> Exclude all CI configuration files
> --
>
> Key: MASFRES-30
> URL: https://issues.apache.org/jira/browse/MASFRES-30
> Project: Apache Maven Resource Bundles
>  Issue Type: Improvement
>  Components: apache-source-release-assembly-descriptor
>Affects Versions: apache-source-release-assembly-descriptor-1.0.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: apache-resources 1.5
>
>
> Exclude:
> * {{.github}}
> * {{Jenkinsfile}}
> * {{.asf.yaml}}
> * {{.travis.yml}}
> * {{deploySite.sh}}



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

[jira] [Commented] (MASFRES-30) Exclude all CI configuration files

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASFRES-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17712117#comment-17712117
 ] 

Christopher Tubbs commented on MASFRES-30:
--

A related issue: I noticed that SCM files like .gitignore are being included, 
but the main .git directory is not. Is this resource bundle supposed to be 
excluding those, or is maven-assembly-plugin itself supposed to ignore those by 
default? I'm asking because I noticed that these .gitignore files seem to be 
included lately, but I think it wasn't too long ago that these were excluded. 
I'm not sure if this component should exclude them or if that's a MASSEMBLY 
issue.

> Exclude all CI configuration files
> --
>
> Key: MASFRES-30
> URL: https://issues.apache.org/jira/browse/MASFRES-30
> Project: Apache Maven Resource Bundles
>  Issue Type: Improvement
>  Components: apache-source-release-assembly-descriptor
>Affects Versions: apache-source-release-assembly-descriptor-1.0.6
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: apache-resources 1.5
>
>
> Exclude:
> * {{.github}}
> * {{Jenkinsfile}}
> * {{.asf.yaml}}
> * {{.travis.yml}}
> * {{deploySite.sh}}



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

[jira] [Commented] (MASSEMBLY-845) MASSEMBLY-817 makes some usecases very inconvenient

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696225#comment-17696225
 ] 

Christopher Tubbs commented on MASSEMBLY-845:
-

This issue seems to be a duplicate of MASSEMBLY-843. It even has identical 
descriptions, but only slightly different subject lines. One should be closed 
(typically for duplicates, the earliest one should be kept, but both have a 
fair number of comments in this case).

> MASSEMBLY-817 makes some usecases very inconvenient
> ---
>
> Key: MASSEMBLY-845
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-845
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ulf Dreyer
>Priority: Major
>
> The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient:
> We need to create an archive with one stable name (independent of e.g. 
> version) so we don't have to propagate these information to a bunch of 
> scripts.
> The general solution (i.e. Stack-overflow) refers exactly to the finalName:
> [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin]
> *Please change finalName back to a settable property.*
> It being settable does not hurt anyone satisfied with the default naming 
> convention but makes some usecases vastly simpler (otherwise you have to 
> rename the artifact using yet another plugin or propagate version info 
> possibly through a chain of scripts)



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

[jira] [Comment Edited] (MASSEMBLY-843) finalName as readonly parameter makes common usecases very complicated

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696156#comment-17696156
 ] 

Christopher Tubbs edited comment on MASSEMBLY-843 at 3/3/23 1:44 PM:
-

Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using 
{{finalName}} is generating a warning: "Parameter 'finalName' is read-only, 
must not be used in configuration". However, using {{finalName}} appears to be 
the only way you can change the name of the base directory inside the assembly 
tarball, as per this StackOverflow answer: 
[https://stackoverflow.com/a/12182912]

This needs to be settable, preferably without a warning, so we can override the 
base directory name inside the assembly. I looked for other options that might 
be able to do that, and I could not find any.

To be clear, {{}} ($\{project.build.finalName\}) 
does appear to be read-only, but I'm talking about {{}} in the assembly, which is generating the warning, even 
though setting it still works, so it appears to now be a hidden undocumented 
feature, that generates the warning.

The use case here is not to override the name of the artifact, whose name still 
follows conventions... the use case is to override the directory name inside 
the artifact.


was (Author: ctubbsii):
Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using 
{{finalName}} is generating a warning: "Parameter 'finalName' is read-only, 
must not be used in configuration". However, using {{finalName}} appears to be 
the only way you can change the name of the base directory inside the assembly 
tarball, as per this StackOverflow answer: 
[https://stackoverflow.com/a/12182912]

This needs to be settable, preferably without a warning, so we can override the 
base directory name inside the assembly. I looked for other options that might 
be able to do that, and I could not find any.

To be clear, {{}} ($\{project.build.finalName\}) 
does appear to be read-only, but I'm talking about {{}} in the assembly, which is generating the warning, even 
though setting it still works, so it appears to now be a hidden undocumented 
feature, that generates the warning.

> finalName as readonly parameter makes common usecases very complicated
> --
>
> Key: MASSEMBLY-843
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-843
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ulf Dreyer
>Priority: Major
>
> The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient:
> We need to create an archive with one stable name (independent of e.g. 
> version) so we don't have to propagate these information to a bunch of 
> scripts.
> The general solution (i.e. Stack-overflow) refers exactly to the finalName:
> [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin]
> *Please change finalName back to a settable property.*
> It being settable does not hurt anyone satisfied with the default naming 
> convention but makes some usecases vastly simpler (otherwise you have to 
> rename the artifact using yet another plugin or propagate version info 
> possibly through a chain of scripts)



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

[jira] [Comment Edited] (MASSEMBLY-843) finalName as readonly parameter makes common usecases very complicated

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696156#comment-17696156
 ] 

Christopher Tubbs edited comment on MASSEMBLY-843 at 3/3/23 1:42 PM:
-

Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using 
{{finalName}} is generating a warning: "Parameter 'finalName' is read-only, 
must not be used in configuration". However, using {{finalName}} appears to be 
the only way you can change the name of the base directory inside the assembly 
tarball, as per this StackOverflow answer: 
[https://stackoverflow.com/a/12182912]

This needs to be settable, preferably without a warning, so we can override the 
base directory name inside the assembly. I looked for other options that might 
be able to do that, and I could not find any.

To be clear, {{}} ($\{project.build.finalName\}) 
does appear to be read-only, but I'm talking about {{}} in the assembly, which is generating the warning, even 
though setting it still works, so it appears to now be a hidden undocumented 
feature, that generates the warning.


was (Author: ctubbsii):
Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using 
{{finalName}} is generating a warning: "Parameter 'finalName' is read-only, 
must not be used in configuration". However, using {{finalName}} appears to be 
the only way you can change the name of the base directory inside the assembly 
tarball, as per this StackOverflow answer: 
[https://stackoverflow.com/a/12182912]

This needs to be settable, preferably without a warning, so we can override the 
base directory name inside the assembly. I looked for other options that might 
be able to do that, and I could not find any.

To be clear, {{}} ({{ $\{project.build.finalName\} 
}}) does appear to be read-only, but I'm talking about 
{{}} in the assembly, which is 
generating the warning, even though setting it still works, so it appears to 
now be a hidden undocumented feature, that generates the warning.

> finalName as readonly parameter makes common usecases very complicated
> --
>
> Key: MASSEMBLY-843
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-843
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ulf Dreyer
>Priority: Major
>
> The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient:
> We need to create an archive with one stable name (independent of e.g. 
> version) so we don't have to propagate these information to a bunch of 
> scripts.
> The general solution (i.e. Stack-overflow) refers exactly to the finalName:
> [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin]
> *Please change finalName back to a settable property.*
> It being settable does not hurt anyone satisfied with the default naming 
> convention but makes some usecases vastly simpler (otherwise you have to 
> rename the artifact using yet another plugin or propagate version info 
> possibly through a chain of scripts)



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

[jira] [Comment Edited] (MASSEMBLY-843) finalName as readonly parameter makes common usecases very complicated

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696156#comment-17696156
 ] 

Christopher Tubbs edited comment on MASSEMBLY-843 at 3/3/23 1:42 PM:
-

Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using 
{{finalName}} is generating a warning: "Parameter 'finalName' is read-only, 
must not be used in configuration". However, using {{finalName}} appears to be 
the only way you can change the name of the base directory inside the assembly 
tarball, as per this StackOverflow answer: 
[https://stackoverflow.com/a/12182912]

This needs to be settable, preferably without a warning, so we can override the 
base directory name inside the assembly. I looked for other options that might 
be able to do that, and I could not find any.

To be clear, {{}} ({{ $\{project.build.finalName\} 
}}) does appear to be read-only, but I'm talking about 
{{}} in the assembly, which is 
generating the warning, even though setting it still works, so it appears to 
now be a hidden undocumented feature, that generates the warning.


was (Author: ctubbsii):
Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using 
{{finalName}} is generating a warning: "Parameter 'finalName' is read-only, 
must not be used in configuration". However, using {{finalName}} appears to be 
the only way you can change the name of the base directory inside the assembly 
tarball, as per this StackOverflow answer: 
[https://stackoverflow.com/a/12182912]

This needs to be settable, preferably without a warning, so we can override the 
base directory name inside the assembly. I looked for other options that might 
be able to do that, and I could not find any.

To be clear, {{}} ({{ ${project.build.finalName} 
}}) does appear to be read-only, but I'm talking about 
{{}} in the assembly, which is 
generating the warning, even though setting it still works, so it appears to 
now be a hidden undocumented feature, that generates the warning.

> finalName as readonly parameter makes common usecases very complicated
> --
>
> Key: MASSEMBLY-843
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-843
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ulf Dreyer
>Priority: Major
>
> The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient:
> We need to create an archive with one stable name (independent of e.g. 
> version) so we don't have to propagate these information to a bunch of 
> scripts.
> The general solution (i.e. Stack-overflow) refers exactly to the finalName:
> [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin]
> *Please change finalName back to a settable property.*
> It being settable does not hurt anyone satisfied with the default naming 
> convention but makes some usecases vastly simpler (otherwise you have to 
> rename the artifact using yet another plugin or propagate version info 
> possibly through a chain of scripts)



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

[jira] [Comment Edited] (MASSEMBLY-843) finalName as readonly parameter makes common usecases very complicated

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696156#comment-17696156
 ] 

Christopher Tubbs edited comment on MASSEMBLY-843 at 3/3/23 1:42 PM:
-

Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using 
{{finalName}} is generating a warning: "Parameter 'finalName' is read-only, 
must not be used in configuration". However, using {{finalName}} appears to be 
the only way you can change the name of the base directory inside the assembly 
tarball, as per this StackOverflow answer: 
[https://stackoverflow.com/a/12182912]

This needs to be settable, preferably without a warning, so we can override the 
base directory name inside the assembly. I looked for other options that might 
be able to do that, and I could not find any.

To be clear, {{}} ({{ ${project.build.finalName} 
}}) does appear to be read-only, but I'm talking about 
{{}} in the assembly, which is 
generating the warning, even though setting it still works, so it appears to 
now be a hidden undocumented feature, that generates the warning.


was (Author: ctubbsii):
Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using 
{{finalName}} is generating a warning: "Parameter 'finalName' is read-only, 
must not be used in configuration". However, using {{finalName}} appears to be 
the only way you can change the name of the base directory inside the assembly 
tarball, as per this StackOverflow answer: 
[https://stackoverflow.com/a/12182912]

This needs to be settable, preferably without a warning, so we can override the 
base directory name inside the assembly. I looked for other options that might 
be able to do that, and I could not find any.

To be clear, \{{}} (\{{ ${project.build.finalName} 
}}) does appear to be read-only, but I'm talking about 
{{}} in the assembly, which is 
generating the warning, even though setting it still works, so it appears to 
now be a hidden undocumented feature, that generates the warning.

> finalName as readonly parameter makes common usecases very complicated
> --
>
> Key: MASSEMBLY-843
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-843
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ulf Dreyer
>Priority: Major
>
> The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient:
> We need to create an archive with one stable name (independent of e.g. 
> version) so we don't have to propagate these information to a bunch of 
> scripts.
> The general solution (i.e. Stack-overflow) refers exactly to the finalName:
> [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin]
> *Please change finalName back to a settable property.*
> It being settable does not hurt anyone satisfied with the default naming 
> convention but makes some usecases vastly simpler (otherwise you have to 
> rename the artifact using yet another plugin or propagate version info 
> possibly through a chain of scripts)



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

[jira] [Commented] (MASSEMBLY-843) finalName as readonly parameter makes common usecases very complicated

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696156#comment-17696156
 ] 

Christopher Tubbs commented on MASSEMBLY-843:
-

Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using 
{{finalName}} is generating a warning: "Parameter 'finalName' is read-only, 
must not be used in configuration". However, using {{finalName}} appears to be 
the only way you can change the name of the base directory inside the assembly 
tarball, as per this StackOverflow answer: 
[https://stackoverflow.com/a/12182912]

This needs to be settable, preferably without a warning, so we can override the 
base directory name inside the assembly. I looked for other options that might 
be able to do that, and I could not find any.

To be clear, \{{}} (\{{ ${project.build.finalName} 
}}) does appear to be read-only, but I'm talking about 
{{}} in the assembly, which is 
generating the warning, even though setting it still works, so it appears to 
now be a hidden undocumented feature, that generates the warning.

> finalName as readonly parameter makes common usecases very complicated
> --
>
> Key: MASSEMBLY-843
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-843
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Ulf Dreyer
>Priority: Major
>
> The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient:
> We need to create an archive with one stable name (independent of e.g. 
> version) so we don't have to propagate these information to a bunch of 
> scripts.
> The general solution (i.e. Stack-overflow) refers exactly to the finalName:
> [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin]
> *Please change finalName back to a settable property.*
> It being settable does not hurt anyone satisfied with the default naming 
> convention but makes some usecases vastly simpler (otherwise you have to 
> rename the artifact using yet another plugin or propagate version info 
> possibly through a chain of scripts)



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

[jira] [Comment Edited] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684482#comment-17684482
 ] 

Christopher Tubbs edited comment on MASSEMBLY-941 at 2/6/23 7:43 AM:
-

One git-specific solution might be to detect that the plugin is running on 
files contained within a git repository, and instead of using the 
filesystem-detected permissions, just ignore those and use the git-metadata for 
the file, {{git ls-files -s path/to/file | cut -c 3-6}}. Or still detect the 
executable flag from the filesystem, but instead of preserving it precisely, 
simplify it to either 644 or 755, knowing that's all the granularity that git 
could have preserved.


was (Author: ctubbsii):
One git-specific solution might be to detect that the plugin is running on 
files contained within a git repository, and instead of using the 
filesystem-detected permissions, just ignore those and use the git-metadata for 
the file, {{git ls-files -s path/to/file | cut -c 3-6}}. Or still detect the 
executable flag from the filesystem, but preserving it precisely, simplify it 
to either 644 or 755, knowing that's all the granularity that git could have 
preserved.

> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Assignee: Herve Boutemy
>Priority: Critical
> Fix For: next-release
>
>
> Since MASSEMBLY-921 in 3.2.0, existing file permissions seem to be ignored 
> when creating a tarball assembly, and files stored in the assembly do not 
> have their original file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly, should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



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

[jira] [Commented] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684482#comment-17684482
 ] 

Christopher Tubbs commented on MASSEMBLY-941:
-

One git-specific solution might be to detect that the plugin is running on 
files contained within a git repository, and instead of using the 
filesystem-detected permissions, just ignore those and use the git-metadata for 
the file, {{git ls-files -s path/to/file | cut -c 3-6}}. Or still detect the 
executable flag from the filesystem, but preserving it precisely, simplify it 
to either 644 or 755, knowing that's all the granularity that git could have 
preserved.

> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Assignee: Herve Boutemy
>Priority: Critical
> Fix For: next-release
>
>
> Since MASSEMBLY-921 in 3.2.0, existing file permissions seem to be ignored 
> when creating a tarball assembly, and files stored in the assembly do not 
> have their original file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly, should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



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

[jira] [Commented] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17684479#comment-17684479
 ] 

Christopher Tubbs commented on MASSEMBLY-941:
-

{quote}
FYI, here is an example of different build results: by default, my local env 
has umask 002, but reference build was done with umask 022 => I had to add the 
umask requirement to rebuild with success the affected artifact 
https://github.com/jvm-repo-rebuild/reproducible-central/commit/626485c96d069fea2107a8162e8f388b358ebb67
{quote}

Thanks for the link, and the explanation. I think that helps clarify a lot of 
the questions I had about how users might be impacted by this. In my mind, I 
was thinking it would only matter if unpacking a source tarball (which could be 
set to preserve permissions and ignore umask), but your example shows that 
another use case is checking out a git branch with umask set. Unfortunately, 
git doesn't have an option to ignore umask and use the permissions stored in 
the repository. Besides that, it only stores either 644 or 755 and can't 
express anything else either.

Many users have suggested workarounds for git at 
https://stackoverflow.com/questions/11574271/git-change-default-umask-when-update-file

As for Windows, I don't even know how one deals with filesystems that can't 
understand executable flags... that's just so foreign to me. I don't think 
there's any good solution for Windows. I think you did the best you could for 
that... I think if projects needs to use Windows, they really need to configure 
the assembly descriptor with permissions for each file, explicitly.

{quote}
once this new maven-assembly-plugin will be released, such cases will happen 
more often: I had hoped to avoid this rebuild env prerequisite...
{quote}

Unfortunately, it doesn't seem to be avoidable. But, maybe pointing users to 
some of the suggestions on the StackOverflow link above for git users might 
help. Or just, encouraging more standard use of {{0022}} for everybody. I can't 
imagine too many cases where {{0002}} is preferable.

> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Assignee: Herve Boutemy
>Priority: Critical
> Fix For: next-release
>
>
> Since MASSEMBLY-921 in 3.2.0, existing file permissions seem to be ignored 
> when creating a tarball assembly, and files stored in the assembly do not 
> have their original file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly, should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



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

[jira] [Commented] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634484#comment-17634484
 ] 

Christopher Tubbs commented on MASSEMBLY-941:
-

The referenced jobs that failed in Jenkins have been deleted, thus making it 
hard to review the IT failures. If you can point me to the source code for the 
failing tests, and/or provide instructions on how to run them locally, I can 
try to reproduce.

> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Assignee: Herve Boutemy
>Priority: Critical
> Fix For: next-release
>
>
> Since 3.2.0, existing file permissions seem to be ignored when creating a 
> tarball assembly, and files stored in the assembly do not have their original 
> file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly, should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



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

[jira] [Commented] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17633393#comment-17633393
 ] 

Christopher Tubbs commented on MASSEMBLY-941:
-

I still don't understand how this is a problem.

Your local machine probably shouldn't default to granting write permission to 
other members of your group, but let's assume you have a good reason to do that.
git ignores group permissions entirely when it stores file information. It only 
stores 644 and 755, from what I understand. So if you build a project with 
files that have other group/other permissions, then check those into git, 
whoever checks out the same commit and rebuilds, isn't going to see the same 
result. I think this is a useful behavior to mimic with the assembly plugin. It 
should only set 644 or 755, unless explicitly overridden with a specific mode 
in the descriptor.

But, I'm also having a hard time understanding how to reproduce this problem. 
Where are the permissions modes getting mangled? Is it during the archive? 
Wouldn't it be during the extraction of the archive? If it's during the 
extraction, you can use {{-p, --preserve-permissions, --same-permissions}} to 
preserve the mode in the archive when you use {{tar}} to extract, and then your 
umask settings shouldn't have an impact. If the umask in your local environment 
or in the CI environment, is causing problems with the reproducibility tests, I 
would suggest that the problem is buggy tests that don't take into account the 
umask during extract... it's not a problem with the behavior of the plugin for 
reproducibility.

As for the Windows case... I'm not sure how to address that... it really 
depends on the filesystem. As I understand it, NTFS and FAT don't really 
support POSIX file modes to begin with.

Regarding the suggestion [~hboutemy] made above, I do not think it is a good 
idea to force the group POSIX permissions from the user permissions. That would 
grant the group write permission on the user's files and directories by 
default. That's a bad idea, and there's a reason why most *nix systems have a 
default umask of at least 0022, and not something like 0002 or . If 
anything, the default group could be forced from the "other" permissions, so 
you only get 644 and 755 in the end.

> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Assignee: Herve Boutemy
>Priority: Critical
> Fix For: next-release
>
>
> Since 3.2.0, existing file permissions seem to be ignored when creating a 
> tarball assembly, and files stored in the assembly do not have their original 
> file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly, should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



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

[jira] [Commented] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17618726#comment-17618726
 ] 

Christopher Tubbs commented on MASSEMBLY-941:
-

[~hboutemy] It took me awhile, but I think I understand the example you gave. 
In that case, I think the problem was not the maven-assembly-plugin or mockito, 
but the problem was that jvm-repo-rebuild/reproducible-central had a strange 
environment. The fix in the referenced PR was reasonable, as it allowed the 
mockito team to explicitly declare the file permissions for the archive. That 
was reasonable in their case, because all their files had the same permissions. 
An alternative could have been for them to modify their build.gradle (or maybe 
something in the gradle wrapper properties?) to set the umask before starting 
the build.

However, explicitly setting all the files to the same mode is not desired in 
the general case.

I've been reading up on what git does with file permissions, and it seems like 
when they store files in the git history, they only store 644 or 755, but 
nothing else. I think it's okay to use this simplified model for when the mode 
isn't explicitly set in the assembly descriptor for a given file set. Git also 
has a configuration option to ignore file mode changes, if only the executable 
bit is different. This helps avoid checking in (storing) executable bits when 
the git worktree is checked out on a badly-behaving filesystem (with respect to 
executable bits, like FAT, for example). I'm not sure maven-assembly-plugin 
needs to get that complicated... but it would be nice if it preserved 
executable flags, so instead of archiving everything as 644, it also used 755, 
if the existing file being archived had its executable bit set. I think this 
simplified model would be suitable for most everybody.. . and if they need 
something more fine-grained, they can create a custom assembly descriptor that 
explicitly sets the file modes for the files they want to be different.


> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Since 3.2.0, existing file permissions seem to be ignored when creating a 
> tarball assembly, and files stored in the assembly do not have their original 
> file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly, should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



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

[jira] [Commented] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17618358#comment-17618358
 ] 

Christopher Tubbs commented on MASSEMBLY-941:
-

I'm not sure I understand what the umask issue could be, either. What is stored 
in the archive should be whatever was observed. umask only comes into play when 
files are created when unpacking the tarball. It shouldn't affect the archival 
process. If you re-build / re-archive from an unpacked tarball where you 
unpacked it with {{--no-same-permissions}} applied, either by default 
(non-superusers) or explicitly, then you're starting from a different initial 
state, and I wouldn't expect the build to be reproducible in that case.

> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Since 3.2.0, existing file permissions seem to be ignored when creating a 
> tarball assembly, and files stored in the assembly do not have their original 
> file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly, should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



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

[jira] [Commented] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MJAVADOC-707:


Hmm, 3.0.1 gives another error when trying to compute javadoc url links to 
classes in sibling modules in a multi-module build. It does work around the 
automatic module name issue, though.

> Plugin won't work if Automatic-Module-Name is used
> --
>
> Key: MJAVADOC-707
> URL: https://issues.apache.org/jira/browse/MJAVADOC-707
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.2, 3.4.0
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Using Automatic-Module-Name in a manifest (an intermediate step to help 
> transition to using modules) prevents this plugin from adding the necessary 
> dependencies to the class path, so it can build javadocs.
> maven-compiler-plugin seems to work fine, as does surefire and all the others 
> when Automatic-Module-Name entries appear in a project's jar manifests. 
> However, this plugin, as of 3.3.1, still does not work correctly with these.
> Instead of using the traditional class path, this plugin seems to force 
> treating the project as a module, even though it does not have any 
> module-info.java files, and most of its dependencies have not transitioned to 
> using modules.
> Here's a pull request that demonstrates adding the Automatic-Module-Name to 
> the manifest for a multi-module (Maven module) project, that fails on the 
> javadoc plugin:
> https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and 
> javadoc:jar are known to fail. I did not test with any other mojos.
> Not supporting this feature holds all projects back from being able to 
> transition to modules over time.
> http://branchandbound.net/blog/java/2017/12/automatic-module-name/
> https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules



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

[jira] [Commented] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MJAVADOC-707:


[~laeubi] Thanks for the tip on the workaround. It seems to help make progress, 
in that it avoids the error. However, it seems to prevent any javadoc jars (or 
aggregate javadocs) from being built at all, tried with both 3.4.0 and 3.4.1.

> Plugin won't work if Automatic-Module-Name is used
> --
>
> Key: MJAVADOC-707
> URL: https://issues.apache.org/jira/browse/MJAVADOC-707
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.2, 3.4.0
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Using Automatic-Module-Name in a manifest (an intermediate step to help 
> transition to using modules) prevents this plugin from adding the necessary 
> dependencies to the class path, so it can build javadocs.
> maven-compiler-plugin seems to work fine, as does surefire and all the others 
> when Automatic-Module-Name entries appear in a project's jar manifests. 
> However, this plugin, as of 3.3.1, still does not work correctly with these.
> Instead of using the traditional class path, this plugin seems to force 
> treating the project as a module, even though it does not have any 
> module-info.java files, and most of its dependencies have not transitioned to 
> using modules.
> Here's a pull request that demonstrates adding the Automatic-Module-Name to 
> the manifest for a multi-module (Maven module) project, that fails on the 
> javadoc plugin:
> https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and 
> javadoc:jar are known to fail. I did not test with any other mojos.
> Not supporting this feature holds all projects back from being able to 
> transition to modules over time.
> http://branchandbound.net/blog/java/2017/12/automatic-module-name/
> https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules



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

[jira] [Commented] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17605585#comment-17605585
 ] 

Christopher Tubbs commented on MASSEMBLY-941:
-

I'm just going to ping this one once again, as I'm updating to the latest 
Apache parent POM (27), and maven-assembly-plugin is now upgraded to 3.4.1 with 
that, and this is still broken. So, we're still stuck on 3.1.1, the last 
version where file permissions were preserved correctly by this plugin.

> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Since 3.2.0, existing file permissions seem to be ignored when creating a 
> tarball assembly, and files stored in the assembly do not have their original 
> file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly, should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



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

[jira] [Commented] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MJAVADOC-707:


Confirmed still a bug in the just released 3.4.0

> Plugin won't work if Automatic-Module-Name is used
> --
>
> Key: MJAVADOC-707
> URL: https://issues.apache.org/jira/browse/MJAVADOC-707
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.2, 3.4.0
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Using Automatic-Module-Name in a manifest (an intermediate step to help 
> transition to using modules) prevents this plugin from adding the necessary 
> dependencies to the class path, so it can build javadocs.
> maven-compiler-plugin seems to work fine, as does surefire and all the others 
> when Automatic-Module-Name entries appear in a project's jar manifests. 
> However, this plugin, as of 3.3.1, still does not work correctly with these.
> Instead of using the traditional class path, this plugin seems to force 
> treating the project as a module, even though it does not have any 
> module-info.java files, and most of its dependencies have not transitioned to 
> using modules.
> Here's a pull request that demonstrates adding the Automatic-Module-Name to 
> the manifest for a multi-module (Maven module) project, that fails on the 
> javadoc plugin:
> https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and 
> javadoc:jar are known to fail. I did not test with any other mojos.
> Not supporting this feature holds all projects back from being able to 
> transition to modules over time.
> http://branchandbound.net/blog/java/2017/12/automatic-module-name/
> https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules



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

[jira] [Updated] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used

[Christopher Tubbs (Jira)]

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

Christopher Tubbs updated MJAVADOC-707:
---
Affects Version/s: 3.4.0

> Plugin won't work if Automatic-Module-Name is used
> --
>
> Key: MJAVADOC-707
> URL: https://issues.apache.org/jira/browse/MJAVADOC-707
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.2, 3.4.0
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Using Automatic-Module-Name in a manifest (an intermediate step to help 
> transition to using modules) prevents this plugin from adding the necessary 
> dependencies to the class path, so it can build javadocs.
> maven-compiler-plugin seems to work fine, as does surefire and all the others 
> when Automatic-Module-Name entries appear in a project's jar manifests. 
> However, this plugin, as of 3.3.1, still does not work correctly with these.
> Instead of using the traditional class path, this plugin seems to force 
> treating the project as a module, even though it does not have any 
> module-info.java files, and most of its dependencies have not transitioned to 
> using modules.
> Here's a pull request that demonstrates adding the Automatic-Module-Name to 
> the manifest for a multi-module (Maven module) project, that fails on the 
> javadoc plugin:
> https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and 
> javadoc:jar are known to fail. I did not test with any other mojos.
> Not supporting this feature holds all projects back from being able to 
> transition to modules over time.
> http://branchandbound.net/blog/java/2017/12/automatic-module-name/
> https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules



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

[jira] [Commented] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MJAVADOC-707:


There seem to be two problems:

# when the automatic module name is added to the jar manifest, it complains 
that packages are empty that have only a package-info.java file. It does not 
complain and works as expected when the automatic-module-name is not in the 
manifest, and
# once the a placeholder class is added so it stops complaining about the empty 
package, it fails to find dependency classes on the classpath that it needs to 
generate the javadocs.

> Plugin won't work if Automatic-Module-Name is used
> --
>
> Key: MJAVADOC-707
> URL: https://issues.apache.org/jira/browse/MJAVADOC-707
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.2
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Using Automatic-Module-Name in a manifest (an intermediate step to help 
> transition to using modules) prevents this plugin from adding the necessary 
> dependencies to the class path, so it can build javadocs.
> maven-compiler-plugin seems to work fine, as does surefire and all the others 
> when Automatic-Module-Name entries appear in a project's jar manifests. 
> However, this plugin, as of 3.3.1, still does not work correctly with these.
> Instead of using the traditional class path, this plugin seems to force 
> treating the project as a module, even though it does not have any 
> module-info.java files, and most of its dependencies have not transitioned to 
> using modules.
> Here's a pull request that demonstrates adding the Automatic-Module-Name to 
> the manifest for a multi-module (Maven module) project, that fails on the 
> javadoc plugin:
> https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and 
> javadoc:jar are known to fail. I did not test with any other mojos.
> Not supporting this feature holds all projects back from being able to 
> transition to modules over time.
> http://branchandbound.net/blog/java/2017/12/automatic-module-name/
> https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MJAVADOC-707:


I've confirmed this still doesn't work with 3.3.2 as well. This seems pretty 
important for people to be able to transition to modules. Is there any way this 
can get on the development roadmap?

> Plugin won't work if Automatic-Module-Name is used
> --
>
> Key: MJAVADOC-707
> URL: https://issues.apache.org/jira/browse/MJAVADOC-707
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.2
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Using Automatic-Module-Name in a manifest (an intermediate step to help 
> transition to using modules) prevents this plugin from adding the necessary 
> dependencies to the class path, so it can build javadocs.
> maven-compiler-plugin seems to work fine, as does surefire and all the others 
> when Automatic-Module-Name entries appear in a project's jar manifests. 
> However, this plugin, as of 3.3.1, still does not work correctly with these.
> Instead of using the traditional class path, this plugin seems to force 
> treating the project as a module, even though it does not have any 
> module-info.java files, and most of its dependencies have not transitioned to 
> using modules.
> Here's a pull request that demonstrates adding the Automatic-Module-Name to 
> the manifest for a multi-module (Maven module) project, that fails on the 
> javadoc plugin:
> https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and 
> javadoc:jar are known to fail. I did not test with any other mojos.
> Not supporting this feature holds all projects back from being able to 
> transition to modules over time.
> http://branchandbound.net/blog/java/2017/12/automatic-module-name/
> https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used

[Christopher Tubbs (Jira)]

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

Christopher Tubbs updated MJAVADOC-707:
---
Affects Version/s: 3.3.2

> Plugin won't work if Automatic-Module-Name is used
> --
>
> Key: MJAVADOC-707
> URL: https://issues.apache.org/jira/browse/MJAVADOC-707
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>Affects Versions: 3.3.1, 3.3.2
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Using Automatic-Module-Name in a manifest (an intermediate step to help 
> transition to using modules) prevents this plugin from adding the necessary 
> dependencies to the class path, so it can build javadocs.
> maven-compiler-plugin seems to work fine, as does surefire and all the others 
> when Automatic-Module-Name entries appear in a project's jar manifests. 
> However, this plugin, as of 3.3.1, still does not work correctly with these.
> Instead of using the traditional class path, this plugin seems to force 
> treating the project as a module, even though it does not have any 
> module-info.java files, and most of its dependencies have not transitioned to 
> using modules.
> Here's a pull request that demonstrates adding the Automatic-Module-Name to 
> the manifest for a multi-module (Maven module) project, that fails on the 
> javadoc plugin:
> https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and 
> javadoc:jar are known to fail. I did not test with any other mojos.
> Not supporting this feature holds all projects back from being able to 
> transition to modules over time.
> http://branchandbound.net/blog/java/2017/12/automatic-module-name/
> https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SUREFIRE-2035) Main artifact jar not present on test class path for tests

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516960#comment-17516960
 ] 

Christopher Tubbs commented on SUREFIRE-2035:
-

All project tests pass with M6. I've attached the demo project to this issue, 
so I can delete the no-longer needed GitHub repo.

> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
> Attachments: surefire-2035-example-main.zip
>
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555, 
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that 
> causes the main artifact jar to be missing from the class path in test cases. 
> I was able to verify that by printing out 
> {{System.getProperty("java.class.path")}} before and after switching to M5, 
> and confirmed that the jar was missing after switching.
> For some reason, unit tests still seem to work okay, though I can't figure 
> out why. However, if I try to launch a process using Java's ProcessBuilder 
> using the same class path from {{System.getProperty("java.class.path")}}, 
> that process fails with ClassNotFoundException, failing to find classes that 
> should definitely be present on the class path from the main artifact.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (SUREFIRE-2035) Main artifact jar not present on test class path for tests

[Christopher Tubbs (Jira)]

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

Christopher Tubbs updated SUREFIRE-2035:

Attachment: surefire-2035-example-main.zip

> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
> Attachments: surefire-2035-example-main.zip
>
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555, 
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that 
> causes the main artifact jar to be missing from the class path in test cases. 
> I was able to verify that by printing out 
> {{System.getProperty("java.class.path")}} before and after switching to M5, 
> and confirmed that the jar was missing after switching.
> For some reason, unit tests still seem to work okay, though I can't figure 
> out why. However, if I try to launch a process using Java's ProcessBuilder 
> using the same class path from {{System.getProperty("java.class.path")}}, 
> that process fails with ClassNotFoundException, failing to find classes that 
> should definitely be present on the class path from the main artifact.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SUREFIRE-2035) Main artifact jar not present on test class path for tests

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516946#comment-17516946
 ] 

Christopher Tubbs commented on SUREFIRE-2035:
-

I'm still re-running some of our project tests to be sure there aren't any 
other problems with M6 (so far, there doesn't seem to be). I can verify that 
the few tests that were failing in our project with M5 now also pass with M6. 
So, I think this ticket can be closed.

If anybody knows which patch in M6 fixed this, please link it to the JIRA or 
mention its git commit here. If there's a regression in future and somebody 
finds this issue, that link might help a future developer identify the 
underlying code that should be fixed.

> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555, 
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that 
> causes the main artifact jar to be missing from the class path in test cases. 
> I was able to verify that by printing out 
> {{System.getProperty("java.class.path")}} before and after switching to M5, 
> and confirmed that the jar was missing after switching.
> For some reason, unit tests still seem to work okay, though I can't figure 
> out why. However, if I try to launch a process using Java's ProcessBuilder 
> using the same class path from {{System.getProperty("java.class.path")}}, 
> that process fails with ClassNotFoundException, failing to find classes that 
> should definitely be present on the class path from the main artifact.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SUREFIRE-2035) Main artifact jar not present on test class path for tests

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516865#comment-17516865
 ] 

Christopher Tubbs commented on SUREFIRE-2035:
-

Well then, M6 works fine, at least with my demo project.

> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555, 
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that 
> causes the main artifact jar to be missing from the class path in test cases. 
> I was able to verify that by printing out 
> {{System.getProperty("java.class.path")}} before and after switching to M5, 
> and confirmed that the jar was missing after switching.
> For some reason, unit tests still seem to work okay, though I can't figure 
> out why. However, if I try to launch a process using Java's ProcessBuilder 
> using the same class path from {{System.getProperty("java.class.path")}}, 
> that process fails with ClassNotFoundException, failing to find classes that 
> should definitely be present on the class path from the main artifact.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SUREFIRE-2035) Main artifact jar not present on test class path for tests

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516841#comment-17516841
 ] 

Christopher Tubbs commented on SUREFIRE-2035:
-

I've created a very minimal example that demonstrates this bug: 
https://github.com/ctubbsii/surefire-2035-example

> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555, 
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that 
> causes the main artifact jar to be missing from the class path in test cases. 
> I was able to verify that by printing out 
> {{System.getProperty("java.class.path")}} before and after switching to M5, 
> and confirmed that the jar was missing after switching.
> For some reason, unit tests still seem to work okay, though I can't figure 
> out why. However, if I try to launch a process using Java's ProcessBuilder 
> using the same class path from {{System.getProperty("java.class.path")}}, 
> that process fails with ClassNotFoundException, failing to find classes that 
> should definitely be present on the class path from the main artifact.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (SUREFIRE-2035) Main artifact jar not present on test class path for tests

[Christopher Tubbs (Jira)]

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

Christopher Tubbs updated SUREFIRE-2035:

Description: 
While trying to troubleshoot https://github.com/apache/accumulo/issues/2555, I 
noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that 
causes the main artifact jar to be missing from the class path in test cases. I 
was able to verify that by printing out 
{{System.getProperty("java.class.path")}} before and after switching to M5, and 
confirmed that the jar was missing after switching.

For some reason, unit tests still seem to work okay, though I can't figure out 
why. However, if I try to launch a process using Java's ProcessBuilder using 
the same class path from {{System.getProperty("java.class.path")}}, that 
process fails with ClassNotFoundException, failing to find classes that should 
definitely be present on the class path from the main artifact.


  was:
While trying to troubleshoot https://github.com/apache/accumulo/issues/2555, I 
noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that 
causes the main artifact jar to be missing from the class path in test cases. I 
was able to verify that by printing out 
{{System.getProperty("java.class.path")}} before and after switching to M5, and 
confirmed that the jar was missing after switching.

For some reason, tests still seem to work okay, though I can't figure out why. 
However, if I try to launch a process using Java's ProcessBuilder using the 
same class path from {{System.getProperty("java.class.path")}}, that process 
fails with ClassNotFoundException, failing to find classes that should 
definitely be present on the class path from the main artifact.



> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555, 
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that 
> causes the main artifact jar to be missing from the class path in test cases. 
> I was able to verify that by printing out 
> {{System.getProperty("java.class.path")}} before and after switching to M5, 
> and confirmed that the jar was missing after switching.
> For some reason, unit tests still seem to work okay, though I can't figure 
> out why. However, if I try to launch a process using Java's ProcessBuilder 
> using the same class path from {{System.getProperty("java.class.path")}}, 
> that process fails with ClassNotFoundException, failing to find classes that 
> should definitely be present on the class path from the main artifact.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SUREFIRE-2035) Main artifact jar not present on test class path for tests

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514134#comment-17514134
 ] 

Christopher Tubbs commented on SUREFIRE-2035:
-

[~sjaranowski] I can provide the full output of 
{{System.getProperty("java.class.path")}}, but it is quite large, and not very 
useful to see all the repeated elements. I did a {{diff}} on them (after 
replacing colons with newlines) and the only difference was the lack of the 
main jar artifact in M5 that was present in M4, which led me to my description 
above. Showing the full output from both is only going to show that same 
conclusion in a more verbose way.

So instead, I will work on providing a minimal project to reproduce this issue, 
and provide the output of that, to be less verbose.

> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555, 
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that 
> causes the main artifact jar to be missing from the class path in test cases. 
> I was able to verify that by printing out 
> {{System.getProperty("java.class.path")}} before and after switching to M5, 
> and confirmed that the jar was missing after switching.
> For some reason, tests still seem to work okay, though I can't figure out 
> why. However, if I try to launch a process using Java's ProcessBuilder using 
> the same class path from {{System.getProperty("java.class.path")}}, that 
> process fails with ClassNotFoundException, failing to find classes that 
> should definitely be present on the class path from the main artifact.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510415#comment-17510415
 ] 

Christopher Tubbs commented on MASSEMBLY-941:
-

[~pzygielo] That does appear to be related, if not the direct cause. However, 
it makes no sense to do that, except to ensure that the builds on Unix/Linux 
work exactly produce the exact same content as when built on Windows. But, I 
don't know why anybody would have that as an expectation in the first place. In 
the case of Apache Accumulo, we cannot build on Windows at all because our 
build requires things like "make" and certain bash scripts we've written, so it 
makes no sense to erase POSIX permissions that are set in the git repository 
that we build from, in order to maintain a build that is equivalent to Windows, 
because we don't have a project that builds on Windows at all. All this does 
for us is break our previously working Unix/Linux builds.

> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Since 3.2.0, existing file permissions seem to be ignored when creating a 
> tarball assembly, and files stored in the assembly do not have their original 
> file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly, should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (SUREFIRE-2035) Main artifact jar not present on test class path for tests

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503320#comment-17503320
 ] 

Christopher Tubbs commented on SUREFIRE-2035:
-

I even tried explicitly adding the main jar artifact onto the class path using 
{{additionalClasspathElements}}, but that didn't work. The jar was still 
missing when I printed {{System.getProperty("java.class.path")}}

> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555, 
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that 
> causes the main artifact jar to be missing from the class path in test cases. 
> I was able to verify that by printing out 
> {{System.getProperty("java.class.path")}} before and after switching to M5, 
> and confirmed that the jar was missing after switching.
> For some reason, tests still seem to work okay, though I can't figure out 
> why. However, if I try to launch a process using Java's ProcessBuilder using 
> the same class path from {{System.getProperty("java.class.path")}}, that 
> process fails with ClassNotFoundException, failing to find classes that 
> should definitely be present on the class path from the main artifact.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (SUREFIRE-2035) Main artifact jar not present on test class path for tests

[Christopher Tubbs (Jira)]

Christopher Tubbs created SUREFIRE-2035:
---

 Summary: Main artifact jar not present on test class path for tests
 Key: SUREFIRE-2035
 URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Failsafe Plugin
Affects Versions: 3.0.0-M5
Reporter: Christopher Tubbs


While trying to troubleshoot https://github.com/apache/accumulo/issues/2555, I 
noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that 
causes the main artifact jar to be missing from the class path in test cases. I 
was able to verify that by printing out 
{{System.getProperty("java.class.path")}} before and after switching to M5, and 
confirmed that the jar was missing after switching.

For some reason, tests still seem to work okay, though I can't figure out why. 
However, if I try to launch a process using Java's ProcessBuilder using the 
same class path from {{System.getProperty("java.class.path")}}, that process 
fails with ClassNotFoundException, failing to find classes that should 
definitely be present on the class path from the main artifact.




--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used

[Christopher Tubbs (Jira)]

Christopher Tubbs created MJAVADOC-707:
--

 Summary: Plugin won't work if Automatic-Module-Name is used
 Key: MJAVADOC-707
 URL: https://issues.apache.org/jira/browse/MJAVADOC-707
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 3.3.1
Reporter: Christopher Tubbs


Using Automatic-Module-Name in a manifest (an intermediate step to help 
transition to using modules) prevents this plugin from adding the necessary 
dependencies to the class path, so it can build javadocs.

maven-compiler-plugin seems to work fine, as does surefire and all the others 
when Automatic-Module-Name entries appear in a project's jar manifests. 
However, this plugin, as of 3.3.1, still does not work correctly with these.

Instead of using the traditional class path, this plugin seems to force 
treating the project as a module, even though it does not have any 
module-info.java files, and most of its dependencies have not transitioned to 
using modules.

Here's a pull request that demonstrates adding the Automatic-Module-Name to the 
manifest for a multi-module (Maven module) project, that fails on the javadoc 
plugin:
https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and 
javadoc:jar are known to fail. I did not test with any other mojos.

Not supporting this feature holds all projects back from being able to 
transition to modules over time.

http://branchandbound.net/blog/java/2017/12/automatic-module-name/

https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MNG-6784) Create correct SHA512 content

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MNG-6784:


There's also a related discussion on 
https://github.com/apache/maven-apache-parent/pull/40 for MPOM, but the 
conversation moved because a lot of it was out of scope of MPOM... 

> Create correct SHA512 content
> -
>
> Key: MNG-6784
> URL: https://issues.apache.org/jira/browse/MNG-6784
> Project: Maven
>  Issue Type: Improvement
>  Components: Deployment
>Affects Versions: 3.6.2
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Currently the created SHA512 which is used for the distribution area contains 
> only the checksum but not the filename which results in bad output if the 
> checksums being checked via command line tool:
> {code}
> $ shasum -c apache-maven-3.2.5-bin.tar.gz.sha512
> $ shasum: apache-maven-3.2.5-bin.tar.gz.sha512: no properly formatted SHA 
> checksum lines found
> {code}
> The checksum should be enhanced to support that correctly.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MNG-6784) Create correct SHA512 content

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MNG-6784:


If we're talking about the files generated by the plugin in MPOM, and not the 
resolver stuff, then here's the related upstream ticket I filed awhile back: 
https://github.com/nicoulaj/checksum-maven-plugin/issues/127

> Create correct SHA512 content
> -
>
> Key: MNG-6784
> URL: https://issues.apache.org/jira/browse/MNG-6784
> Project: Maven
>  Issue Type: Improvement
>  Components: Deployment
>Affects Versions: 3.6.2
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Currently the created SHA512 which is used for the distribution area contains 
> only the checksum but not the filename which results in bad output if the 
> checksums being checked via command line tool:
> {code}
> $ shasum -c apache-maven-3.2.5-bin.tar.gz.sha512
> $ shasum: apache-maven-3.2.5-bin.tar.gz.sha512: no properly formatted SHA 
> checksum lines found
> {code}
> The checksum should be enhanced to support that correctly.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MNG-6784) Create correct SHA512 content

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MNG-6784:


I'm not sure if this issue is about the resolver, or about files produced by 
some plugin for the release distribution area. In any case, I do think it would 
make sense if anywhere these files were created, they wrote in a format that 
included the filename, so it can be more easily verified with standard tooling. 
It does no harm to include the filename, and makes it easier for anybody, 
regardless of context to use a checksum file they encounter to verify the file 
it accompanies.

> Create correct SHA512 content
> -
>
> Key: MNG-6784
> URL: https://issues.apache.org/jira/browse/MNG-6784
> Project: Maven
>  Issue Type: Improvement
>  Components: Deployment
>Affects Versions: 3.6.2
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Currently the created SHA512 which is used for the distribution area contains 
> only the checksum but not the filename which results in bad output if the 
> checksums being checked via command line tool:
> {code}
> $ shasum -c apache-maven-3.2.5-bin.tar.gz.sha512
> $ shasum: apache-maven-3.2.5-bin.tar.gz.sha512: no properly formatted SHA 
> checksum lines found
> {code}
> The checksum should be enhanced to support that correctly.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (MRELEASE-938) Need better support for staging release candidates with git and Nexus

[Christopher Tubbs (Jira)]

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

Christopher Tubbs edited comment on MRELEASE-938 at 1/4/22, 12:48 PM:
--

[~hboutemy] re: "too Git tag oriented" - I created this issue specifically 
because this plugin creates an inconvenient git tag. This issue isn't intended 
to be about anything else. So, yes, the focus is on the git tag. To answer your 
questions:
 * The version in the POM for the release candidate is the final version. We 
don't append "-rc1" to it because we don't want that in the final released 
artifacts. We don't change any bits between voting and publishing, not even to 
modify the version number, as that would change the signatures and checksums 
evaluated during the vote.
 * The version doesn't change if it is accepted
 * The convenience binaries don't matter for this discussion, but they sit in 
staging repository at repository.apache.org; any POM information in their 
META-INF directory would match the corresponding POM in the source artifacts 
being voted on

Here's another attempt at trying to summarize the problem using the relevant 
actions taken by this plugin, and an example version {{1.0.0}}:

# {{[release:prepare]}} writes a tag name at 
{{rel/project-1.0.0}} in the pom.xml,
# {{[release:prepare]}} creates a git tag at {{rel/project-1.0.0}},
# {{[release:perform]}} executes maven-assembly-plugin using the source-release 
assembly descriptor defined in the ASF parent POM, which stores the POM from 
step 1 in the source release artifact that is currently being staged

The core of the problem is that step 1 and 2 above are reusing the same tag 
name for different purposes. The {{}} recorded in step 1 is 
effectively permalink information so you can find the git history that 
corresponds to a given release, and could be thought of as a "final tag" for a 
released version. The tag currently created in step 2 and checked out in step 3 
serves a more transient purpose, and could be thought of as a "release 
candidate tag". A release candidate shouldn't create a tag following final tag 
naming conventions until after a successful vote, and a final tag shouldn't 
document a release candidate name in {{}}. This entire issue is 
trying to keep those two separate with limited configuration options made 
available by this plugin. If you append "-rcX" to the tag name, then it 
permanently gets stored in the released POM. But if you don't, then this plugin 
prematurely creates a tag for a release candidate that follows a final tag 
naming convention.

{code:xml}

  
  rel/project-@{project.version}
  true
  true

  
  rc/project-@{project.version}
  false
  false
  true

{code}


was (Author: ctubbsii):
[~hboutemy] re: "too Git tag oriented" - I created this issue specifically 
because this plugin creates an inconvenient git tag. This issue isn't intended 
to be about anything else. So, yes, the focus is on the git tag. To answer your 
questions:
 * The version in the POM for the release candidate is the final version. We 
don't append "-rc1" to it because we don't want that in the final released 
artifacts. We don't change any bits between voting and publishing, not even to 
modify the version number, as that would change the signatures and checksums 
evaluated during the vote.
 * The version doesn't change if it is accepted
 * The convenience binaries don't matter for this discussion, but they sit in 
staging repository at repository.apache.org; any POM information in their 
META-INF directory would match the corresponding POM in the source artifacts 
being voted on

Here's another attempt at trying to summarize the problem using the relevant 
actions taken by this plugin, and an example version {{1.0.0}}:

# {{[release:prepare]}} writes a tag name at 
{{rel/project-1.0.0}} in the pom.xml,
# {{[release:prepare]}} creates a git tag at {{rel/project-1.0.0}},
# {{[release:perform]}} executes maven-assembly-plugin using the source-release 
assembly descriptor defined in the ASF parent POM, which stores the POM from 
step 1 in the source release artifact that is currently being staged

The core of the problem is that step 1 and 2 above are reusing the same tag 
name for different purposes. The {{}} recorded in step 1 is 
effectively permalink information so you can find the git history that 
corresponds to a given release, and could be thought of as a "final tag" for a 
released version. The tag currently created in step 2 and checked out in step 3 
serves a more transient purpose, and could be thought of as a "release 
candidate tag". A release candidate shouldn't create a tag following final tag 
naming conventions until after a successful vote, and a final tag shouldn't 
document a release candidate name in {{}}. This entire issue is 
trying to keep those two separate with limited configuration options 

[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MRELEASE-938:


[~hboutemy] re: "too Git tag oriented" - I created this issue specifically 
because this plugin creates an inconvenient git tag. This issue isn't intended 
to be about anything else. So, yes, the focus is on the git tag. To answer your 
questions:
 * The version in the POM for the release candidate is the final version. We 
don't append "-rc1" to it because we don't want that in the final released 
artifacts. We don't change any bits between voting and publishing, not even to 
modify the version number, as that would change the signatures and checksums 
evaluated during the vote.
 * The version doesn't change if it is accepted
 * The convenience binaries don't matter for this discussion, but they sit in 
staging repository at repository.apache.org; any POM information in their 
META-INF directory would match the corresponding POM in the source artifacts 
being voted on

Here's another attempt at trying to summarize the problem using the relevant 
actions taken by this plugin, and an example version {{1.0.0}}:

# {{[release:prepare]}} writes a tag name at 
{{rel/project-1.0.0}} in the pom.xml,
# {{[release:prepare]}} creates a git tag at {{rel/project-1.0.0}},
# {{[release:perform]}} executes maven-assembly-plugin using the source-release 
assembly descriptor defined in the ASF parent POM, which stores the POM from 
step 1 in the source release artifact that is currently being staged

The core of the problem is that step 1 and 2 above are reusing the same tag 
name for different purposes. The {{}} recorded in step 1 is 
effectively permalink information so you can find the git history that 
corresponds to a given release, and could be thought of as a "final tag" for a 
released version. The tag currently created in step 2 and checked out in step 3 
serves a more transient purpose, and could be thought of as a "release 
candidate tag". A release candidate shouldn't create a tag following final tag 
naming conventions until after a successful vote, and a final tag shouldn't 
document a release candidate name in {{}}. This entire issue is 
trying to keep those two separate with limited configuration options made 
available by this plugin.

{code:xml}

  
  rel/project-@{project.version}
  true
  true

  
  rc/project-@{project.version}
  false
  false
  true

{code}

> Need better support for staging release candidates with git and Nexus
> -
>
> Key: MRELEASE-938
> URL: https://issues.apache.org/jira/browse/MRELEASE-938
> Project: Maven Release Plugin
>  Issue Type: Improvement
>Reporter: Christopher Tubbs
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Use case:
> An ASF project creates git tags which are GPG-signed named "rel/" 
> after a release is voted on. If the release passes, the contents of the 
> pom.xml files should refer to this final tag, and not any intermediate 
> release candidate tag name.
> To avoid pushing the release prior to building a release candidate and 
> publishing it to the staging maven repository, the configuration sets 
> {{false}} and 
> {{true}}, and the tag name is created with 
> {{rel/@\{project.version\}}}.
> There is still a risk of a release manager accidentally pushing the tag 
> created by the maven-release-plugin, which has the final name, but is not GPG 
> signed, and should not be pushed, because it cannot (and should not) change 
> once it is.
> What might be useful here is an alternate, intermediate name, 
> {{@\{project.version\}}} which can be used as the checkout tag for the 
> perform step.
> Alternatively, no tag actually has to be created in this case (a GPG-signed 
> tag is manually created later). Unless {{suppressCommitBeforeTag}} is set, 
> the perform step can check out from {{HEAD~1}}, instead. An option to skip 
> tag creation entirely could work under these circumstances.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MRELEASE-938:


{{release:prepare}} and {{release:perform}} are already kind of multi-stage. It 
would also suffice to just have an option that disables creating the tag. For 
the {{release:perform}} step, instead of checking out the tag from the name in 
{{}}, the {{release:prepare}} step could just record the git commit 
hash that it would have created the tag from, so that {{release:perform}} can 
check that out instead. 

> Need better support for staging release candidates with git and Nexus
> -
>
> Key: MRELEASE-938
> URL: https://issues.apache.org/jira/browse/MRELEASE-938
> Project: Maven Release Plugin
>  Issue Type: Improvement
>Reporter: Christopher Tubbs
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Use case:
> An ASF project creates git tags which are GPG-signed named "rel/" 
> after a release is voted on. If the release passes, the contents of the 
> pom.xml files should refer to this final tag, and not any intermediate 
> release candidate tag name.
> To avoid pushing the release prior to building a release candidate and 
> publishing it to the staging maven repository, the configuration sets 
> {{false}} and 
> {{true}}, and the tag name is created with 
> {{rel/@\{project.version\}}}.
> There is still a risk of a release manager accidentally pushing the tag 
> created by the maven-release-plugin, which has the final name, but is not GPG 
> signed, and should not be pushed, because it cannot (and should not) change 
> once it is.
> What might be useful here is an alternate, intermediate name, 
> {{@\{project.version\}}} which can be used as the checkout tag for the 
> perform step.
> Alternatively, no tag actually has to be created in this case (a GPG-signed 
> tag is manually created later). Unless {{suppressCommitBeforeTag}} is set, 
> the perform step can check out from {{HEAD~1}}, instead. An option to skip 
> tag creation entirely could work under these circumstances.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MRELEASE-938:


[~michael-o], Yes, I'm aware that releases are source artifacts. I don't 
believe I misrepresented that. Some projects use this plugin to stage a release 
candidate, because the Apache parent POM is conveniently configured with a 
release profile that uses the maven-assembly-plugin, configured with the 
apache-source-release-assembly-descriptor, to produce those source artifacts. 
This is very convenient, because with a simple execution of the 
maven-release-plugin, one can create the release candidate source artifacts 
alongside a staged Nexus repository with convenience binaries for evaluation 
and testing of release candidates to inform voting PMC members.

This issue isn't about the release artifacts. It's about making it easier to 
use this plugin in a workflow where it is used to prepare "ASF release" 
candidates. Although the git tag is not the official source release, many 
projects have a desire to create a tag in SCM that is sync'd with the official 
source release in some way (either has identical contents, or was used to 
prepare the source release, or similar). This plugin creates such a tag 
already, but it doesn't play nicely with the "ASF release" candidate workflow, 
because it creates a destination tag prematurely... before the candidate has 
been voted on and approved. In git, once a tag is used, it shouldn't be 
updated. So, the same tag shouldn't be re-used. Release candidates should also 
not follow the INFRA-provided {{rel*}} protected branch/tag naming convention, 
which implies it matches up to a release, for provenance tracking. So, the goal 
here is to have an option to continue using all the power of this plugin, but 
more easily avoid tag creation until after a vote passes.

> Need better support for staging release candidates with git and Nexus
> -
>
> Key: MRELEASE-938
> URL: https://issues.apache.org/jira/browse/MRELEASE-938
> Project: Maven Release Plugin
>  Issue Type: Improvement
>Reporter: Christopher Tubbs
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Use case:
> An ASF project creates git tags which are GPG-signed named "rel/" 
> after a release is voted on. If the release passes, the contents of the 
> pom.xml files should refer to this final tag, and not any intermediate 
> release candidate tag name.
> To avoid pushing the release prior to building a release candidate and 
> publishing it to the staging maven repository, the configuration sets 
> {{false}} and 
> {{true}}, and the tag name is created with 
> {{rel/@\{project.version\}}}.
> There is still a risk of a release manager accidentally pushing the tag 
> created by the maven-release-plugin, which has the final name, but is not GPG 
> signed, and should not be pushed, because it cannot (and should not) change 
> once it is.
> What might be useful here is an alternate, intermediate name, 
> {{@\{project.version\}}} which can be used as the checkout tag for the 
> perform step.
> Alternatively, no tag actually has to be created in this case (a GPG-signed 
> tag is manually created later). Unless {{suppressCommitBeforeTag}} is set, 
> the perform step can check out from {{HEAD~1}}, instead. An option to skip 
> tag creation entirely could work under these circumstances.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MRELEASE-938:


[~rfscholte] I don't understand how to use the MRELEASE-956 changes, if they 
are even documented anywhere. It may be possible to use that feature to 
customize the release strategy to satisfy the use case here, but I just don't 
know how right now. If you can point me to documentation on how to use it, I 
can evaluate it to see if it works for the above use case.

[~michael-o] While the description of the problem is complex, the actual 
solutions don't have to be.

The problem I've described is not about version numbers at all, but of git tag 
management. So, liberally burning through version numbers doesn't solve 
anything. Furthermore, it would be a *really* bad idea to adopt the same naming 
convention for tags of unreleased versions as those of released versions. The 
naming convention that INFRA recommends (requires?) for releases, which is 
{{rel*}}, implies that tags following that naming convention are *releases*. 
Unreleased versions burned through in this manner shouldn't occupy the same 
space. Deleting them and leaving gaps could also be confusing for users, 
because gaps could mean an unreleased burned version number, or a released 
version number that somebody forgot to tag.

The problem is complicated and difficult to explain, as is explaining why 
proposed alternatives like these are insufficient. But, the solutions don't 
have to be that complex. They just have to provide a little more flexibility to 
prepare a release without creating a tag in its final after-vote location.

Without some way to easily prepare a release candidate without creating a 
release tag, you have to set {{pushChanges}} to false and {{localCheckout}} to 
true like in 
https://github.com/apache/accumulo/blob/976af80c1591a177265009aa4ed1eb03b8e21c93/pom.xml#L832-L833
 and then you have to manually push your release candidate branches and delete 
the local tag that this plugin created, or you have to do all that in a script 
outside of this plugin, like in 
https://github.com/apache/accumulo/blob/976af80c1591a177265009aa4ed1eb03b8e21c93/assemble/build.sh
 , which makes this plugin substantially less useful when you still need 
external scripts to prepare a release candidate instead of just running 
{{release:prepare}} and {{release:perform}}.

> Need better support for staging release candidates with git and Nexus
> -
>
> Key: MRELEASE-938
> URL: https://issues.apache.org/jira/browse/MRELEASE-938
> Project: Maven Release Plugin
>  Issue Type: Improvement
>Reporter: Christopher Tubbs
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Use case:
> An ASF project creates git tags which are GPG-signed named "rel/" 
> after a release is voted on. If the release passes, the contents of the 
> pom.xml files should refer to this final tag, and not any intermediate 
> release candidate tag name.
> To avoid pushing the release prior to building a release candidate and 
> publishing it to the staging maven repository, the configuration sets 
> {{false}} and 
> {{true}}, and the tag name is created with 
> {{rel/@\{project.version\}}}.
> There is still a risk of a release manager accidentally pushing the tag 
> created by the maven-release-plugin, which has the final name, but is not GPG 
> signed, and should not be pushed, because it cannot (and should not) change 
> once it is.
> What might be useful here is an alternate, intermediate name, 
> {{@\{project.version\}}} which can be used as the checkout tag for the 
> perform step.
> Alternatively, no tag actually has to be created in this case (a GPG-signed 
> tag is manually created later). Unless {{suppressCommitBeforeTag}} is set, 
> the perform step can check out from {{HEAD~1}}, instead. An option to skip 
> tag creation entirely could work under these circumstances.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (MNG-6784) Create correct SHA512 content

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MNG-6784:


[~kwin] - The page you linked is an informational page, a "HOW TO" guide, not 
policy. Even if it were ASF policy, nothing in that page describes any kind of 
file format requirement, as far as I can tell. If you believe otherwise, please 
cite the specific line.

> Create correct SHA512 content
> -
>
> Key: MNG-6784
> URL: https://issues.apache.org/jira/browse/MNG-6784
> Project: Maven
>  Issue Type: Improvement
>  Components: Deployment
>Affects Versions: 3.6.2
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 4.0.x-candidate, wontfix-candidate
>
>
> Currently the created SHA512 which is used for the distribution area contains 
> only the checksum but not the filename which results in bad output if the 
> checksums being checked via command line tool:
> {code}
> $ shasum -c apache-maven-3.2.5-bin.tar.gz.sha512
> $ shasum: apache-maven-3.2.5-bin.tar.gz.sha512: no properly formatted SHA 
> checksum lines found
> {code}
> The checksum should be enhanced to support that correctly.



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

[jira] [Commented] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424266#comment-17424266
 ] 

Christopher Tubbs commented on SUREFIRE-1584:
-

[~Casper_NL], the last release looks like it was in June 2020. The PR to update 
the docs was merged in November 2020. There was also another change to the docs 
3 months after that, with information regarding 3.0.0-M6, which is not yet 
released. My suspicion is that even though the documentation has been updated, 
it won't be published until the next release, which will be 3.0.0-M6. It's 
possible to update the website before then, but this is minor, so it's probably 
not worth the effort. It should get automatically updated when 3.0.0-M6 is 
released and the website updated for that. So, I don't think it's worth 
re-opening this issue.

> Rerun Failing Tests with JUnit 5
> 
>
> Key: SUREFIRE-1584
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1584
> Project: Maven Surefire
>  Issue Type: New Feature
>  Components: JUnit 5.x support, Maven Surefire Report Plugin
>Affects Versions: 2.22.0
>Reporter: Tic Tac
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
> Attachments: FlakyReruns.png
>
>
> The very useful feature for integration tests ¨[Rerun Failing 
> Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨
>  is currently only supported for the very outdated JUnit 4.
> The documentation says: ¨This feature is supported only for JUnit 4.x.¨
> Can you please support this feature for JUnit 5.3 or later?



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

[jira] [Commented] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343428#comment-17343428
 ] 

Christopher Tubbs commented on MASSEMBLY-941:
-

Hi, just checking back to see if anybody has a fix for this. It seems to be a 
pretty important bug with the assembly plugin.

> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Since 3.2.0, existing file permissions seem to be ignored when creating a 
> tarball assembly, and files stored in the assembly do not have their original 
> file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly, should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



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

[jira] [Commented] (MJAVADOC-614) "No source files for package" in a directory with accent characters

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MJAVADOC-614:


This issue is marked as "Fixed", but it has no associated "fixVersion" in JIRA. 
In which version will this be fixed?

> "No source files for package" in a directory with accent characters
> ---
>
> Key: MJAVADOC-614
> URL: https://issues.apache.org/jira/browse/MJAVADOC-614
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.1.0, 3.1.1, 3.2.0
> Environment: Operating System: Windows 7
> Java: OracleJDK12
> Maven: 3.6.1
>Reporter: Alexis Jehan
>Priority: Critical
> Attachments: options, options(3.0.1), packages, packages(3.0.1)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
>  
> Executing "mvn clean javadoc:javadoc" in the "D:\é\foo" produces the 
> following error:
> {quote}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:3.1.1:javadoc (default-cli) on 
> project foo: An error has occurred in Javadoc report generation:
>  [ERROR] Exit code: 2 - javadoc: error - No source files for package foo.bar
>  [ERROR]
>  [ERROR] Command line was: "C:\Program Files\Java\jdk-12\bin\javadoc.exe" 
> @options @packages
>  [ERROR]
>  [ERROR] Refer to the generated Javadoc files in 
> 'D:\é\foo\target\site\apidocs' dir.
> {quote}
> In a directory named "D:\e\foo", the same command does not produce any error.
> The bug does not affect Apache Maven Javadoc Plugin 3.0.1.



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

[jira] [Commented] (MNG-5689) Checksum policy for mirrors

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MNG-5689:


> This is not correct. The mirror is still necessary to catch repositories from 
> POMs which are not in settings.xml. 

It sounds like you're saying that mirrors are still useful if the only thing 
you want to override from repositories in the POMs are the URLs. And, probably 
the most useful one to override is `*`.

> The mirror inherits the policlies of the repo it mirrors. This makes sense.

I'm not convinced that it makes sense. The POMs should not be the authority on 
how the client behaves when interacting with a repository. The client should 
decide for itself how it wants to treat the checksum failures when interacting 
with that repository (or any of its mirrors).

Even if the default is now strict, a POM could specify a repository that is not 
strict... and the client should be able to override that to force it to be 
strict (or some other setting, although I don't know why anybody would choose 
to use anything other than strict/fail). The client can currently override it 
globally across all repositories, using `-C`, but there's no `settings.xml` 
equivalent to that.

> Checksum policy for mirrors
> ---
>
> Key: MNG-5689
> URL: https://issues.apache.org/jira/browse/MNG-5689
> Project: Maven
>  Issue Type: Improvement
>  Components: Settings
>Affects Versions: 3.2.3
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
> Fix For: Issues to be reviewed for 4.x, wontfix-candidate
>
>
> It does not appear that there is any way to configure a checksum policy for 
> mirrors in the settings.xml file.
> In particular, I'd love to enforce a "strict" checksum policy on maven 
> central. I can configure a mirrorOf central, but I cannot set the checksum 
> policy. This seems like a big oversight.



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

[jira] [Commented] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244408#comment-17244408
 ] 

Christopher Tubbs commented on SUREFIRE-1584:
-

[~borjapenman] Based on the file I edited, my guess would be that the website 
is only updated after a release.

> Rerun Failing Tests with JUnit 5
> 
>
> Key: SUREFIRE-1584
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1584
> Project: Maven Surefire
>  Issue Type: New Feature
>  Components: JUnit 5.x support, Maven Surefire Report Plugin
>Affects Versions: 2.22.0
>Reporter: Tic Tac
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
> Attachments: FlakyReruns.png
>
>
> The very useful feature for integration tests ¨[Rerun Failing 
> Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨
>  is currently only supported for the very outdated JUnit 4.
> The documentation says: ¨This feature is supported only for JUnit 4.x.¨
> Can you please support this feature for JUnit 5.3 or later?



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

[jira] [Commented] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229445#comment-17229445
 ] 

Christopher Tubbs commented on SUREFIRE-1584:
-

[~tibordigana] https://github.com/apache/maven-surefire/pull/323

> Rerun Failing Tests with JUnit 5
> 
>
> Key: SUREFIRE-1584
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1584
> Project: Maven Surefire
>  Issue Type: New Feature
>  Components: JUnit 5.x support, Maven Surefire Report Plugin
>Affects Versions: 2.22.0
>Reporter: Tic Tac
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
> Attachments: FlakyReruns.png
>
>
> The very useful feature for integration tests ¨[Rerun Failing 
> Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨
>  is currently only supported for the very outdated JUnit 4.
> The documentation says: ¨This feature is supported only for JUnit 4.x.¨
> Can you please support this feature for JUnit 5.3 or later?



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

[jira] [Commented] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228329#comment-17228329
 ] 

Christopher Tubbs commented on SUREFIRE-1584:
-

[~tibordigana], my comment contained a conditional: "*If*..."... because I 
don't know what wording would be correct. I was just trying to bring something 
to the attention of somebody who knows what it *should* say (which is not me), 
so they can update it.

> Rerun Failing Tests with JUnit 5
> 
>
> Key: SUREFIRE-1584
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1584
> Project: Maven Surefire
>  Issue Type: New Feature
>  Components: JUnit 5.x support, Maven Surefire Report Plugin
>Affects Versions: 2.22.0
>Reporter: Tic Tac
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
> Attachments: FlakyReruns.png
>
>
> The very useful feature for integration tests ¨[Rerun Failing 
> Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨
>  is currently only supported for the very outdated JUnit 4.
> The documentation says: ¨This feature is supported only for JUnit 4.x.¨
> Can you please support this feature for JUnit 5.3 or later?



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

[jira] [Commented] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224270#comment-17224270
 ] 

Christopher Tubbs commented on SUREFIRE-1584:
-

If {{-Dsurefire.rerunFailingTestsCount}} is available in JUnit5, can somebody 
please update the documentation on 
https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html
 to say so?
It currently says that it only works in JUnit4.x

> Rerun Failing Tests with JUnit 5
> 
>
> Key: SUREFIRE-1584
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1584
> Project: Maven Surefire
>  Issue Type: New Feature
>  Components: JUnit 5.x support, Maven Surefire Report Plugin
>Affects Versions: 2.22.0
>Reporter: Tic Tac
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
> Attachments: FlakyReruns.png
>
>
> The very useful feature for integration tests ¨[Rerun Failing 
> Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨
>  is currently only supported for the very outdated JUnit 4.
> The documentation says: ¨This feature is supported only for JUnit 4.x.¨
> Can you please support this feature for JUnit 5.3 or later?



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

[jira] [Commented] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186635#comment-17186635
 ] 

Christopher Tubbs commented on MASSEMBLY-941:
-

I updated the description and title to make the issue more apparent.

Also, here is a minimal pom.xml to reproduce the issue (do {{ chmod +x pom.xml 
}} to reproduce):

{code:xml}

http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
https://maven.apache.org/xsd/maven-4.0.0.xsd;>
  4.0.0
  com.example
  example
  0.0.1-SNAPSHOT
  pom
  


2020-01-22T15:10:15Z
  
  
clean assembly:single

  
org.apache.maven.plugins
maven-assembly-plugin

3.3.0

  
org.apache.apache.resources
apache-source-release-assembly-descriptor
1.0.6
  


  
source-release-zip-tar
  
  posix

  

  

{code}

This appears to have been broken by the reproducibility features using the {{ 
project.build.outputTimestamp }} property. Removing that property fixes the 
issue. However, that property will be inherited from the Apache parent pom, and 
in any case, it should preserve file permissions even if reproducibility is 
used.

> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Since 3.2.0, existing file permissions seem to be ignored when creating a 
> tarball assembly, and files stored in the assembly do not have their original 
> file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly, should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



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

[jira] [Updated] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

[Christopher Tubbs (Jira)]

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

Christopher Tubbs updated MASSEMBLY-941:

Description: 
Since 3.2.0, existing file permissions seem to be ignored when creating a 
tarball assembly, and files stored in the assembly do not have their original 
file permissions preserved.

Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
existing file permissions are normally preserved. This is now broken in 3.2.0, 
unless the component descriptor explicitly sets the fileModes.

This was discovered trying to prepare a release candidate for Apache Accumulo 
using the apache-23.pom parent POM's predefined `source-release-tar` descriptor 
using the `single` goal. We noticed that the resulting source-release tarball 
had stripped all the executable permissions from our scripts, instead of 
preserving them. This makes the resulting source release more difficult to 
build from source.

A source-release assembly, and any other assembly that does not specify the 
file permissions explicitly should preserve the existing file permissions, just 
as it used to with 3.1.1 and earlier.

  was:
My project (Apache Accumulo) is using the apache-23.pom parent POM with the 
predefined `source-release-tar` descriptor using the `single` goal.

Using version 3.1.1 of this plugin, file permissions are preserved.

However, since 3.2.0, file permissions seem to be ignored, and tarballs created 
with this plugin have executable permission removed from scripts.


> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Since 3.2.0, existing file permissions seem to be ignored when creating a 
> tarball assembly, and files stored in the assembly do not have their original 
> file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



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

[jira] [Updated] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

[Christopher Tubbs (Jira)]

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

Christopher Tubbs updated MASSEMBLY-941:

Description: 
Since 3.2.0, existing file permissions seem to be ignored when creating a 
tarball assembly, and files stored in the assembly do not have their original 
file permissions preserved.

Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
existing file permissions are normally preserved. This is now broken in 3.2.0, 
unless the component descriptor explicitly sets the fileModes.

This was discovered trying to prepare a release candidate for Apache Accumulo 
using the apache-23.pom parent POM's predefined `source-release-tar` descriptor 
using the `single` goal. We noticed that the resulting source-release tarball 
had stripped all the executable permissions from our scripts, instead of 
preserving them. This makes the resulting source release more difficult to 
build from source.

A source-release assembly, and any other assembly that does not specify the 
file permissions explicitly, should preserve the existing file permissions, 
just as it used to with 3.1.1 and earlier.

  was:
Since 3.2.0, existing file permissions seem to be ignored when creating a 
tarball assembly, and files stored in the assembly do not have their original 
file permissions preserved.

Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
existing file permissions are normally preserved. This is now broken in 3.2.0, 
unless the component descriptor explicitly sets the fileModes.

This was discovered trying to prepare a release candidate for Apache Accumulo 
using the apache-23.pom parent POM's predefined `source-release-tar` descriptor 
using the `single` goal. We noticed that the resulting source-release tarball 
had stripped all the executable permissions from our scripts, instead of 
preserving them. This makes the resulting source release more difficult to 
build from source.

A source-release assembly, and any other assembly that does not specify the 
file permissions explicitly should preserve the existing file permissions, just 
as it used to with 3.1.1 and earlier.


> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Priority: Critical
>
> Since 3.2.0, existing file permissions seem to be ignored when creating a 
> tarball assembly, and files stored in the assembly do not have their original 
> file permissions preserved.
> Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, 
> existing file permissions are normally preserved. This is now broken in 
> 3.2.0, unless the component descriptor explicitly sets the fileModes.
> This was discovered trying to prepare a release candidate for Apache Accumulo 
> using the apache-23.pom parent POM's predefined `source-release-tar` 
> descriptor using the `single` goal. We noticed that the resulting 
> source-release tarball had stripped all the executable permissions from our 
> scripts, instead of preserving them. This makes the resulting source release 
> more difficult to build from source.
> A source-release assembly, and any other assembly that does not specify the 
> file permissions explicitly, should preserve the existing file permissions, 
> just as it used to with 3.1.1 and earlier.



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

[jira] [Updated] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0

[Christopher Tubbs (Jira)]

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

Christopher Tubbs updated MASSEMBLY-941:

Summary: file permissions removed during assembly:single since 3.2.0  (was: 
file modes removed for tarball assembly since 3.2.0)

> file permissions removed during assembly:single since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Priority: Critical
>
> My project (Apache Accumulo) is using the apache-23.pom parent POM with the 
> predefined `source-release-tar` descriptor using the `single` goal.
> Using version 3.1.1 of this plugin, file permissions are preserved.
> However, since 3.2.0, file permissions seem to be ignored, and tarballs 
> created with this plugin have executable permission removed from scripts.



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

[jira] [Updated] (MASSEMBLY-941) file modes removed for tarball assembly since 3.2.0

[Christopher Tubbs (Jira)]

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

Christopher Tubbs updated MASSEMBLY-941:

Priority: Critical  (was: Major)

> file modes removed for tarball assembly since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Priority: Critical
>
> My project (Apache Accumulo) is using the apache-23.pom parent POM with the 
> predefined `source-release-tar` descriptor using the `single` goal.
> Using version 3.1.1 of this plugin, file permissions are preserved.
> However, since 3.2.0, file permissions seem to be ignored, and tarballs 
> created with this plugin have executable permission removed from scripts.



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

[jira] [Updated] (MASSEMBLY-941) file modes removed for tarball assembly since 3.2.0

[Christopher Tubbs (Jira)]

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

Christopher Tubbs updated MASSEMBLY-941:

Affects Version/s: 3.2.0
   3.3.0

> file modes removed for tarball assembly since 3.2.0
> ---
>
> Key: MASSEMBLY-941
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: permissions
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Christopher Tubbs
>Priority: Major
>
> My project (Apache Accumulo) is using the apache-23.pom parent POM with the 
> predefined `source-release-tar` descriptor using the `single` goal.
> Using version 3.1.1 of this plugin, file permissions are preserved.
> However, since 3.2.0, file permissions seem to be ignored, and tarballs 
> created with this plugin have executable permission removed from scripts.



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

[jira] [Created] (MASSEMBLY-941) file modes removed for tarball assembly since 3.2.0

[Christopher Tubbs (Jira)]

Christopher Tubbs created MASSEMBLY-941:
---

 Summary: file modes removed for tarball assembly since 3.2.0
 Key: MASSEMBLY-941
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-941
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: permissions
Reporter: Christopher Tubbs


My project (Apache Accumulo) is using the apache-23.pom parent POM with the 
predefined `source-release-tar` descriptor using the `single` goal.

Using version 3.1.1 of this plugin, file permissions are preserved.

However, since 3.2.0, file permissions seem to be ignored, and tarballs created 
with this plugin have executable permission removed from scripts.



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

[jira] [Comment Edited] (MRELEASE-938) Need better support for staging release candidates with git and Nexus

[Christopher Tubbs (Jira)]

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

Christopher Tubbs edited comment on MRELEASE-938 at 12/21/19 4:58 AM:
--

[~elharo]  This can *not* be fixed by Nexus behavior changes, because:

1. Nexus should not have access to the project's git repository to alter the 
tags if moving from staged to release, and it certainly shouldn't have the GPG 
private keys to create signed tags, and
2. Nexus should not be modifying the pom.xml's scm section to update the tag 
name in the pom when moving from staged to release, especially since that would 
break the user's GPG signatures on those pom artifacts.

To be clear, although staging to Nexus is a driving use case, the relevant 
issues have little to nothing to do with Nexus. This is really about the git 
tag management limitations performed this plugin that could be improved.

To attempt to explain it more clearly:

* This plugin creates a git tag during {{prepare}} based on the 
{{}}.
* This plugin modifies the {{}} element in the POM's {{}} section 
according to the tag name format.
* When you are using the plugin to stage release candidates, you do *not* want 
it to create a git tag based on the final release when you don't yet know if 
the release candidate will be the final release (especially in ASF if the final 
release tag name looks like {{rel/project-version}}, because tags starting with 
{{rel}} are locked and can't be deleted without help from INFRA).

Your options are to:

1. skip tag creation and manually create a tag after the release candidate is 
decided to be released, or
2. create a tag name format that includes a release candidate sequence number, 
like {{rel/project-version-rc1}}.

The problem with option 1 is that this plugin doesn't have any such option to 
skip tag creation. You do have the option to skip the git push, but that is 
inconvenient, because it isn't the default and it also skips pushing the new 
commits in the branch that update the versions in the pom.xml files, and in any 
case... even if you skipped pushing, you'd still have a local tag that might 
unintentionally get pushed later.

The problem with option 2 is that the pom.xml file's {{scm}} section that this 
plugin updated will have the wrong tag name if the release candidate is 
approved for release (it will have the tag name ending in "-rc1" rather than 
the final tag name, making it more difficult for people with a copy of the 
release to be able to find the correct corresponding git tag for the release 
associated with a given pom.xml. This is particularly problematic for other 
tools like maven-site-plugin, which make use of the scm information in the pom 
to create links for users on a project's website that goes back to the tag.

This could be fixed by either of the following two solutions:

1. Add an option of this plugin to skip git tag creation, and expect users to 
do that manually later. This will cause problems with the {{perform}} goal's 
ability to check out the commit (because the tag won't exist), but {{HEAD~1}} 
could be used with {{localCheckout}}, so long as {{suppressCommitBeforeTag}} is 
not used. This solution would allow the plugin's modification to the scm 
section of the pom to work only once the user manually created their own tag of 
the same name, but they wouldn't have to worry about any automatically created 
tags made by this plugin that would interfere with that.

Or,

2. This plugin could be modified so that the name of the actual git tag branch 
could be specified separately from the final tag name that gets put into the 
pom's scm section. So, "project-version-rc1", "project-version-rc2", and 
"project-version-rc3" git tags could all be created by this plugin, all 
containing the same pom with the scm section showing a tag name that is simply 
"project-version". Then, a user can simply create a "project-version" tag from 
the same commit as whichever "project-version-rcX" tag was approved for final 
release (without having to recreate the staged artifacts in Nexus with a 
corrected pom.xml).

I know this is a bit obscure of a use case... so if I've explained it poorly, I 
apologize. If both proposed options are rejected, for whatever reason, that's 
fine. It's just a bit more work to do local git tag management in a build 
script outside of maven... I had just hoped that this release plugin could 
handle this (seemingly common) use case so we could encapsulate the entire 
release process within the configuration for this plugin.

Mostly, I just want to make sure the reason for rejecting the suggestion isn't 
based on misunderstanding the nature of the problem being described.


was (Author: ctubbsii):
[~elharo]  This can *not* be fixed by Nexus behavior changes, because:

1. Nexus should not have access to the project's git repository to alter the 
tags 

[jira] [Commented] (MRELEASE-938) Need better support for staging release candidates with git and Nexus

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MRELEASE-938:


[~elharo]  This can *not* be fixed by Nexus behavior changes, because:

1. Nexus should not have access to the project's git repository to alter the 
tags if moving from staged to release, and it certainly shouldn't have the GPG 
private keys to create signed tags, and
2. Nexus should not be modifying the pom.xml's scm section to update the tag 
name in the pom when moving from staged to release, especially since that would 
break the user's GPG signatures on those pom artifacts.

To be clear, although staging to Nexus is a driving use case, the relevant 
issues have little to nothing to do with Nexus. This is really about the git 
tag management limitations performed this plugin that could be improved.

To attempt to explain it more clearly:

* This plugin creates a git tag during {{prepare}} based on the 
{{}}.
* This plugin modifies the {{}} element in the POM's {{}} section 
according to the tag name format.
* When you are using the plugin to stage release candidates, you do *not* want 
it to create a git tag based on the final release when you don't yet know if 
the release candidate will be the final release (especially in ASF if the final 
release tag name looks like {{rel/project-version}}, because tags starting with 
{{rel}} are locked and can't be deleted without help from INFRA).

Your options are to:

1. skip tag creation and manually create a tag after the release candidate is 
decided to be released, or
2. create a tag name format that includes a release candidate sequence number, 
like {{rel/project-version-rc1}}.

The problem with option 1 is that this plugin doesn't have any such option to 
skip tag creation. You do have the option to skip the git push, but that is 
inconvenient, because it isn't the default and it also skips pushing the new 
commits in the branch that update the versions in the pom.xml files, and in any 
case... even if you skipped pushing, you'd still have a local tag that might 
unintentionally get pushed later.

The problem with option 2 is that the pom.xml file's {{scm}} section that this 
plugin updated will have the wrong tag name if the release candidate is 
approved for release (it will have the tag name ending in "-rc1" rather than 
the final tag name, making it more difficult for people with a copy of the 
release to be able to find the correct corresponding git tag for the release 
associated with a given pom.xml. This is particularly problematic for other 
tools like maven-site-plugin, which make use of the scm information in the pom 
to create links for users on a project's website that goes back to the tag.

This could be fixed by either of the following two solutions:

1. Add an option of this plugin to skip git tag creation, and expect users to 
do that manually later. This will cause problems with the {{perform}} goal's 
ability to check out the commit (because the tag won't exist), but {{HEAD~1}} 
could be used with {{localCheckout}}, so long as {{suppressCommitBeforeTag}} is 
not used. This solution would allow the plugin's modification to the scm 
section of the pom to work only once the user manually created their own tag of 
the same name, but they wouldn't have to worry about any automatically created 
tags made by this plugin that would interfere with that.

Or,

2. This plugin could be modified so that the name of the actual git tag branch 
could be specified separately from the final tag name that gets put into the 
pom's scm section. So, "project-version-rc1", "project-version-rc2", and 
"project-version-rc3" git tags could all be created by this plugin, all 
containing the same pom with the scm section showing a tag name that is simply 
"project-version". Then, a user can simply create a "project-version" tag from 
the same commit as whichever "project-version-rcX" tag was approved for final 
release (without having to recreate the staged artifacts in Nexus with a 
corrected pom.xml).

I know this is a bit obscure of a use case... so if I've explained it poorly, I 
apologize. If both proposed options are rejected, for whatever reason, that's 
fine. It's just a bit more work to do local git tag management in a build 
script outside of maven... I had just hoped that this release plugin could 
handle this (seemingly common) use case so we could encapsulate the entire 
release process within the configuration for this plugin.

> Need better support for staging release candidates with git and Nexus
> -
>
> Key: MRELEASE-938
> URL: https://issues.apache.org/jira/browse/MRELEASE-938
> Project: Maven Release Plugin
>  Issue Type: Improvement
>Reporter: Christopher Tubbs
>

[jira] [Commented] (MJAVADOC-609) Include jars for which module name cannot be determined on the classpath

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MJAVADOC-609:


I believe this issue can be closed now. It should be fixed in 3.2.0 with the 
fix for MJAVADOC-620.

> Include jars for which module name cannot be determined on the classpath
> 
>
> Key: MJAVADOC-609
> URL: https://issues.apache.org/jira/browse/MJAVADOC-609
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Phil Clay
>Priority: Major
>
> In maven-javadoc-plugin v3.1.0, dependency jars for which the module name 
> cannot be determined are not included on the classpath when running the 
> javadoc command.  This leads to ClassNotFoundExceptions when running javadoc.
> Here is a concrete example:
> When developing features on feature branches, some developers include jira 
> issue names in the version of artifacts... e.g. {{ABC-1234-SNAPSHOT}}.   This 
> leads to jar file names in the form {{foo-ABC-1234-SNAPSHOT.jar}}.  
> Unfortunately, an automatic module name cannot be determined from the 
> filename of this jar according to the rules of 
> [ModuleFinder|https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...-].
>  When attempting to determine the module name of this jar, the following 
> exception is encountered:
> {code:java}
> java.lang.module.FindException: Unable to derive module descriptor for 
> C:\Users\foo\.m2\repository\com\bar\foo\ABC-1234-SNAPSHOT\foo-ABC-1234-SNAPSHOT.jar
>   at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:647)
>   at 
> java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:330)
>   at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:236)
>   at 
> java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:189)
>   at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:165)
>   at ModuleTest.test(ModuleTest.java:14)
>   ... snip
> Caused by: java.lang.IllegalArgumentException: foo.ABC.1234.SNAPSHOT: Invalid 
> module name: '1234' is not a Java identifier
>   at 
> java.base/jdk.internal.module.Checks.requireModuleName(Checks.java:52)
>   at 
> java.base/java.lang.module.ModuleDescriptor$Builder.(ModuleDescriptor.java:1550)
>   at 
> java.base/java.lang.module.ModuleDescriptor.newAutomaticModule(ModuleDescriptor.java:2438)
>   at 
> java.base/jdk.internal.module.ModulePath.deriveModuleDescriptor(ModulePath.java:507)
>   at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:643)
>   ... 44 more
> {code}
> The maven-javadoc-plugin will swallow this exception (without logging), and 
> won't include the jar on the classpath.
> More specifically:
>  # [{{AbstractJavadocMojo}} calls 
> {{locationManager.resolvePaths(request)}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5144]
>  # The returned {{ResolvePathsResult result}} contains the swallowed 
> exception in {{result.getPathExceptions()}}. The result does not include the 
> file in [{{getModulepathElements()}} or 
> {{getClasspathElements()}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5146-L5148]
>  # The {{AbstractJavadocMojo}} ignores the path exceptions
>  # Therefore, the files that have path exceptions do not get included in the 
> classpath or module path
>  # Later, this results in ClassNotFoundExceptions when running javadoc
> One workaround is to _not_ use the jira issue name in the version. However, 
> this practice is extremely baked into our workflow (there is automation 
> around it), and therefore would be very difficult to change.
> I would like the maven-javadoc-plugin to include jars for which the automatic 
> module name cannot be determined on the classpath.
> Potential solutions:
> This could potentially be solved in 
> [plexus-java|https://github.com/codehaus-plexus/plexus-languages/blob/879376946165679eb3bb980ddaf8db68ab2031d4/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/LocationManager.java#L356],
>  by having {{LocationManager.resolvePaths}} return jars for which the 
> automatic module name cannot be determined as part of 
> {{result.getClasspathElements()}}
> Or, it could be solved it maven-javadoc-plugin by having 
> {{AbstractJavadocMojo}} include any files from {{result.getPathExceptions()}} 
> on the classpath by default.
> Regardless of what is done, {{result.getPathExceptions()}} should not be 

[jira] [Commented] (MJAVADOC-609) Include jars for which module name cannot be determined on the classpath

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MJAVADOC-609:


The pull request to fix MJAVADOC-620 
(https://github.com/apache/maven-javadoc-plugin/pull/35) is basically what I 
would have come up with to fix this issue, if fixing it at the plugin level, so 
it probably is a duplicate of this issue, after all.

> Include jars for which module name cannot be determined on the classpath
> 
>
> Key: MJAVADOC-609
> URL: https://issues.apache.org/jira/browse/MJAVADOC-609
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Phil Clay
>Priority: Major
>
> In maven-javadoc-plugin v3.1.0, dependency jars for which the module name 
> cannot be determined are not included on the classpath when running the 
> javadoc command.  This leads to ClassNotFoundExceptions when running javadoc.
> Here is a concrete example:
> When developing features on feature branches, some developers include jira 
> issue names in the version of artifacts... e.g. {{ABC-1234-SNAPSHOT}}.   This 
> leads to jar file names in the form {{foo-ABC-1234-SNAPSHOT.jar}}.  
> Unfortunately, an automatic module name cannot be determined from the 
> filename of this jar according to the rules of 
> [ModuleFinder|https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...-].
>  When attempting to determine the module name of this jar, the following 
> exception is encountered:
> {code:java}
> java.lang.module.FindException: Unable to derive module descriptor for 
> C:\Users\foo\.m2\repository\com\bar\foo\ABC-1234-SNAPSHOT\foo-ABC-1234-SNAPSHOT.jar
>   at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:647)
>   at 
> java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:330)
>   at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:236)
>   at 
> java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:189)
>   at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:165)
>   at ModuleTest.test(ModuleTest.java:14)
>   ... snip
> Caused by: java.lang.IllegalArgumentException: foo.ABC.1234.SNAPSHOT: Invalid 
> module name: '1234' is not a Java identifier
>   at 
> java.base/jdk.internal.module.Checks.requireModuleName(Checks.java:52)
>   at 
> java.base/java.lang.module.ModuleDescriptor$Builder.(ModuleDescriptor.java:1550)
>   at 
> java.base/java.lang.module.ModuleDescriptor.newAutomaticModule(ModuleDescriptor.java:2438)
>   at 
> java.base/jdk.internal.module.ModulePath.deriveModuleDescriptor(ModulePath.java:507)
>   at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:643)
>   ... 44 more
> {code}
> The maven-javadoc-plugin will swallow this exception (without logging), and 
> won't include the jar on the classpath.
> More specifically:
>  # [{{AbstractJavadocMojo}} calls 
> {{locationManager.resolvePaths(request)}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5144]
>  # The returned {{ResolvePathsResult result}} contains the swallowed 
> exception in {{result.getPathExceptions()}}. The result does not include the 
> file in [{{getModulepathElements()}} or 
> {{getClasspathElements()}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5146-L5148]
>  # The {{AbstractJavadocMojo}} ignores the path exceptions
>  # Therefore, the files that have path exceptions do not get included in the 
> classpath or module path
>  # Later, this results in ClassNotFoundExceptions when running javadoc
> One workaround is to _not_ use the jira issue name in the version. However, 
> this practice is extremely baked into our workflow (there is automation 
> around it), and therefore would be very difficult to change.
> I would like the maven-javadoc-plugin to include jars for which the automatic 
> module name cannot be determined on the classpath.
> Potential solutions:
> This could potentially be solved in 
> [plexus-java|https://github.com/codehaus-plexus/plexus-languages/blob/879376946165679eb3bb980ddaf8db68ab2031d4/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/LocationManager.java#L356],
>  by having {{LocationManager.resolvePaths}} return jars for which the 
> automatic module name cannot be determined as part of 
> {{result.getClasspathElements()}}
> Or, it could be solved it maven-javadoc-plugin by having 
> {{AbstractJavadocMojo}} include any 

[jira] [Commented] (MJAVADOC-620) Maven Javadoc Plugin fails to resolve the dependencies when used with Java 11

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MJAVADOC-620:


At first I wouldn't have thought so, because the description of this issue 
seems more complicated than the one in MJAVADOC-609, but based on the pull 
request that fixes the issue, it appears this is a duplicate of MJAVADOC-609.

Even if it is describing a slightly different issue, the pull request appears 
like it would fix MJAVADOC-609.

> Maven Javadoc Plugin fails to resolve the dependencies when used with Java 11
> -
>
> Key: MJAVADOC-620
> URL: https://issues.apache.org/jira/browse/MJAVADOC-620
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.1.0, 3.1.1
> Environment: Mageia Linux 7, AdoptOpenJDK 11.0.1
>Reporter: Julien Gouesse
>Priority: Major
> Attachments: BuildMeFirst.zip, MavenTest.zip, ThenBuildThisSite.zip
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Maven Javadoc Plugin fails to resolve the dependencies that are inherited by 
> all sub-modules in the parent pom file and the dependencies specific to some 
> sub-modules if and only if it's used with Java 11 whereas it works flawlessly 
> with Java 8. This bug is reproducible with this project:
> [https://jogamp.org/cgit/ardor3d.git/tree/]
> Enter "mvn site" and you'll get the following error message:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-site) on 
> project ardor3d: Error generating maven-javadoc-plugin:3.1.1:aggregate 
> report: [ERROR] Exit code: 1 - 
> Ardor3D/ardor3d-swt/src/test/java/com/ardor3d/input/swt/TestSwtMouseWrapper.java:23:
>  error: package org.eclipse.swt.events does not exist
> Note that "mvn install" works with Java 11, this problem of dependency 
> management only occurs while generating the Java API documentation with Java 
> 11.
>  



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

[jira] [Commented] (MJAVADOC-609) Include jars for which module name cannot be determined on the classpath

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MJAVADOC-609:


[~rfscholte], I think MJAVADOC-620 might be a separate issue, but I'm not sure. 
This one is very narrowly scoped on one specific situation where an exception 
isn't handled properly when looking up the automatic module names using Java's 
built-in ModuleFinder API.

> Include jars for which module name cannot be determined on the classpath
> 
>
> Key: MJAVADOC-609
> URL: https://issues.apache.org/jira/browse/MJAVADOC-609
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Phil Clay
>Priority: Major
>
> In maven-javadoc-plugin v3.1.0, dependency jars for which the module name 
> cannot be determined are not included on the classpath when running the 
> javadoc command.  This leads to ClassNotFoundExceptions when running javadoc.
> Here is a concrete example:
> When developing features on feature branches, some developers include jira 
> issue names in the version of artifacts... e.g. {{ABC-1234-SNAPSHOT}}.   This 
> leads to jar file names in the form {{foo-ABC-1234-SNAPSHOT.jar}}.  
> Unfortunately, an automatic module name cannot be determined from the 
> filename of this jar according to the rules of 
> [ModuleFinder|https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...-].
>  When attempting to determine the module name of this jar, the following 
> exception is encountered:
> {code:java}
> java.lang.module.FindException: Unable to derive module descriptor for 
> C:\Users\foo\.m2\repository\com\bar\foo\ABC-1234-SNAPSHOT\foo-ABC-1234-SNAPSHOT.jar
>   at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:647)
>   at 
> java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:330)
>   at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:236)
>   at 
> java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:189)
>   at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:165)
>   at ModuleTest.test(ModuleTest.java:14)
>   ... snip
> Caused by: java.lang.IllegalArgumentException: foo.ABC.1234.SNAPSHOT: Invalid 
> module name: '1234' is not a Java identifier
>   at 
> java.base/jdk.internal.module.Checks.requireModuleName(Checks.java:52)
>   at 
> java.base/java.lang.module.ModuleDescriptor$Builder.(ModuleDescriptor.java:1550)
>   at 
> java.base/java.lang.module.ModuleDescriptor.newAutomaticModule(ModuleDescriptor.java:2438)
>   at 
> java.base/jdk.internal.module.ModulePath.deriveModuleDescriptor(ModulePath.java:507)
>   at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:643)
>   ... 44 more
> {code}
> The maven-javadoc-plugin will swallow this exception (without logging), and 
> won't include the jar on the classpath.
> More specifically:
>  # [{{AbstractJavadocMojo}} calls 
> {{locationManager.resolvePaths(request)}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5144]
>  # The returned {{ResolvePathsResult result}} contains the swallowed 
> exception in {{result.getPathExceptions()}}. The result does not include the 
> file in [{{getModulepathElements()}} or 
> {{getClasspathElements()}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5146-L5148]
>  # The {{AbstractJavadocMojo}} ignores the path exceptions
>  # Therefore, the files that have path exceptions do not get included in the 
> classpath or module path
>  # Later, this results in ClassNotFoundExceptions when running javadoc
> One workaround is to _not_ use the jira issue name in the version. However, 
> this practice is extremely baked into our workflow (there is automation 
> around it), and therefore would be very difficult to change.
> I would like the maven-javadoc-plugin to include jars for which the automatic 
> module name cannot be determined on the classpath.
> Potential solutions:
> This could potentially be solved in 
> [plexus-java|https://github.com/codehaus-plexus/plexus-languages/blob/879376946165679eb3bb980ddaf8db68ab2031d4/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/LocationManager.java#L356],
>  by having {{LocationManager.resolvePaths}} return jars for which the 
> automatic module name cannot be determined as part of 
> {{result.getClasspathElements()}}
> Or, it could be solved it maven-javadoc-plugin by having 
> 

[jira] [Commented] (MJAVADOC-609) Include jars for which module name cannot be determined on the classpath

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MJAVADOC-609:


I have a pull request on plexus-java that may fix this issue, but would need 
somebody to build maven-javadoc-plugin with the patched version to test it.

> Include jars for which module name cannot be determined on the classpath
> 
>
> Key: MJAVADOC-609
> URL: https://issues.apache.org/jira/browse/MJAVADOC-609
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Phil Clay
>Priority: Major
>
> In maven-javadoc-plugin v3.1.0, dependency jars for which the module name 
> cannot be determined are not included on the classpath when running the 
> javadoc command.  This leads to ClassNotFoundExceptions when running javadoc.
> Here is a concrete example:
> When developing features on feature branches, some developers include jira 
> issue names in the version of artifacts... e.g. {{ABC-1234-SNAPSHOT}}.   This 
> leads to jar file names in the form {{foo-ABC-1234-SNAPSHOT.jar}}.  
> Unfortunately, an automatic module name cannot be determined from the 
> filename of this jar according to the rules of 
> [ModuleFinder|https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...-].
>  When attempting to determine the module name of this jar, the following 
> exception is encountered:
> {code:java}
> java.lang.module.FindException: Unable to derive module descriptor for 
> C:\Users\foo\.m2\repository\com\bar\foo\ABC-1234-SNAPSHOT\foo-ABC-1234-SNAPSHOT.jar
>   at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:647)
>   at 
> java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:330)
>   at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:236)
>   at 
> java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:189)
>   at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:165)
>   at ModuleTest.test(ModuleTest.java:14)
>   ... snip
> Caused by: java.lang.IllegalArgumentException: foo.ABC.1234.SNAPSHOT: Invalid 
> module name: '1234' is not a Java identifier
>   at 
> java.base/jdk.internal.module.Checks.requireModuleName(Checks.java:52)
>   at 
> java.base/java.lang.module.ModuleDescriptor$Builder.(ModuleDescriptor.java:1550)
>   at 
> java.base/java.lang.module.ModuleDescriptor.newAutomaticModule(ModuleDescriptor.java:2438)
>   at 
> java.base/jdk.internal.module.ModulePath.deriveModuleDescriptor(ModulePath.java:507)
>   at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:643)
>   ... 44 more
> {code}
> The maven-javadoc-plugin will swallow this exception (without logging), and 
> won't include the jar on the classpath.
> More specifically:
>  # [{{AbstractJavadocMojo}} calls 
> {{locationManager.resolvePaths(request)}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5144]
>  # The returned {{ResolvePathsResult result}} contains the swallowed 
> exception in {{result.getPathExceptions()}}. The result does not include the 
> file in [{{getModulepathElements()}} or 
> {{getClasspathElements()}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5146-L5148]
>  # The {{AbstractJavadocMojo}} ignores the path exceptions
>  # Therefore, the files that have path exceptions do not get included in the 
> classpath or module path
>  # Later, this results in ClassNotFoundExceptions when running javadoc
> One workaround is to _not_ use the jira issue name in the version. However, 
> this practice is extremely baked into our workflow (there is automation 
> around it), and therefore would be very difficult to change.
> I would like the maven-javadoc-plugin to include jars for which the automatic 
> module name cannot be determined on the classpath.
> Potential solutions:
> This could potentially be solved in 
> [plexus-java|https://github.com/codehaus-plexus/plexus-languages/blob/879376946165679eb3bb980ddaf8db68ab2031d4/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/LocationManager.java#L356],
>  by having {{LocationManager.resolvePaths}} return jars for which the 
> automatic module name cannot be determined as part of 
> {{result.getClasspathElements()}}
> Or, it could be solved it maven-javadoc-plugin by having 
> {{AbstractJavadocMojo}} include any files from {{result.getPathExceptions()}} 
> on the classpath by default.
> Regardless of what 

[jira] [Comment Edited] (MJAVADOC-609) Include jars for which module name cannot be determined on the classpath

[Christopher Tubbs (Jira)]

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

Christopher Tubbs edited comment on MJAVADOC-609 at 11/22/19 9:07 AM:
--

I have a pull request on plexus-java that may fix this issue, but would need 
somebody to build maven-javadoc-plugin with the patched version to test it:

https://github.com/codehaus-plexus/plexus-languages/pull/30


was (Author: ctubbsii):
I have a pull request on plexus-java that may fix this issue, but would need 
somebody to build maven-javadoc-plugin with the patched version to test it.

> Include jars for which module name cannot be determined on the classpath
> 
>
> Key: MJAVADOC-609
> URL: https://issues.apache.org/jira/browse/MJAVADOC-609
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Phil Clay
>Priority: Major
>
> In maven-javadoc-plugin v3.1.0, dependency jars for which the module name 
> cannot be determined are not included on the classpath when running the 
> javadoc command.  This leads to ClassNotFoundExceptions when running javadoc.
> Here is a concrete example:
> When developing features on feature branches, some developers include jira 
> issue names in the version of artifacts... e.g. {{ABC-1234-SNAPSHOT}}.   This 
> leads to jar file names in the form {{foo-ABC-1234-SNAPSHOT.jar}}.  
> Unfortunately, an automatic module name cannot be determined from the 
> filename of this jar according to the rules of 
> [ModuleFinder|https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...-].
>  When attempting to determine the module name of this jar, the following 
> exception is encountered:
> {code:java}
> java.lang.module.FindException: Unable to derive module descriptor for 
> C:\Users\foo\.m2\repository\com\bar\foo\ABC-1234-SNAPSHOT\foo-ABC-1234-SNAPSHOT.jar
>   at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:647)
>   at 
> java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:330)
>   at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:236)
>   at 
> java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:189)
>   at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:165)
>   at ModuleTest.test(ModuleTest.java:14)
>   ... snip
> Caused by: java.lang.IllegalArgumentException: foo.ABC.1234.SNAPSHOT: Invalid 
> module name: '1234' is not a Java identifier
>   at 
> java.base/jdk.internal.module.Checks.requireModuleName(Checks.java:52)
>   at 
> java.base/java.lang.module.ModuleDescriptor$Builder.(ModuleDescriptor.java:1550)
>   at 
> java.base/java.lang.module.ModuleDescriptor.newAutomaticModule(ModuleDescriptor.java:2438)
>   at 
> java.base/jdk.internal.module.ModulePath.deriveModuleDescriptor(ModulePath.java:507)
>   at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:643)
>   ... 44 more
> {code}
> The maven-javadoc-plugin will swallow this exception (without logging), and 
> won't include the jar on the classpath.
> More specifically:
>  # [{{AbstractJavadocMojo}} calls 
> {{locationManager.resolvePaths(request)}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5144]
>  # The returned {{ResolvePathsResult result}} contains the swallowed 
> exception in {{result.getPathExceptions()}}. The result does not include the 
> file in [{{getModulepathElements()}} or 
> {{getClasspathElements()}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5146-L5148]
>  # The {{AbstractJavadocMojo}} ignores the path exceptions
>  # Therefore, the files that have path exceptions do not get included in the 
> classpath or module path
>  # Later, this results in ClassNotFoundExceptions when running javadoc
> One workaround is to _not_ use the jira issue name in the version. However, 
> this practice is extremely baked into our workflow (there is automation 
> around it), and therefore would be very difficult to change.
> I would like the maven-javadoc-plugin to include jars for which the automatic 
> module name cannot be determined on the classpath.
> Potential solutions:
> This could potentially be solved in 
> [plexus-java|https://github.com/codehaus-plexus/plexus-languages/blob/879376946165679eb3bb980ddaf8db68ab2031d4/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/LocationManager.java#L356],
>  by having {{LocationManager.resolvePaths}} return jars for which 

[jira] [Comment Edited] (MJAVADOC-609) Include jars for which module name cannot be determined on the classpath

[Christopher Tubbs (Jira)]

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

Christopher Tubbs edited comment on MJAVADOC-609 at 11/22/19 12:12 AM:
---

(EDIT: originally asked why ticket was closed... but it's not closed... my 
mistake)

It doesn't seem to have been fixed in 3.1.1
In particular, this is problematic for ALL {{-incubating}} patterns, and this 
blocks module adoption by projects which use any dependencies with 
{{-incubating}} (or {{-STABLE}}, {{-LATEST}}, {{-SNAPSHOT}}, etc.)


was (Author: ctubbsii):
Why is this one closed? It doesn't seem to have been fixed in 3.1.1
In particular, this is problematic for ALL {{-incubating}} patterns, and this 
blocks module adoption by projects which use any dependencies with 
{{-incubating}} (or {{-STABLE}}, {{-LATEST}}, {{-SNAPSHOT}}, etc.)

> Include jars for which module name cannot be determined on the classpath
> 
>
> Key: MJAVADOC-609
> URL: https://issues.apache.org/jira/browse/MJAVADOC-609
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Phil Clay
>Priority: Major
>
> In maven-javadoc-plugin v3.1.0, dependency jars for which the module name 
> cannot be determined are not included on the classpath when running the 
> javadoc command.  This leads to ClassNotFoundExceptions when running javadoc.
> Here is a concrete example:
> When developing features on feature branches, some developers include jira 
> issue names in the version of artifacts... e.g. {{ABC-1234-SNAPSHOT}}.   This 
> leads to jar file names in the form {{foo-ABC-1234-SNAPSHOT.jar}}.  
> Unfortunately, an automatic module name cannot be determined from the 
> filename of this jar according to the rules of 
> [ModuleFinder|https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...-].
>  When attempting to determine the module name of this jar, the following 
> exception is encountered:
> {code:java}
> java.lang.module.FindException: Unable to derive module descriptor for 
> C:\Users\foo\.m2\repository\com\bar\foo\ABC-1234-SNAPSHOT\foo-ABC-1234-SNAPSHOT.jar
>   at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:647)
>   at 
> java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:330)
>   at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:236)
>   at 
> java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:189)
>   at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:165)
>   at ModuleTest.test(ModuleTest.java:14)
>   ... snip
> Caused by: java.lang.IllegalArgumentException: foo.ABC.1234.SNAPSHOT: Invalid 
> module name: '1234' is not a Java identifier
>   at 
> java.base/jdk.internal.module.Checks.requireModuleName(Checks.java:52)
>   at 
> java.base/java.lang.module.ModuleDescriptor$Builder.(ModuleDescriptor.java:1550)
>   at 
> java.base/java.lang.module.ModuleDescriptor.newAutomaticModule(ModuleDescriptor.java:2438)
>   at 
> java.base/jdk.internal.module.ModulePath.deriveModuleDescriptor(ModulePath.java:507)
>   at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:643)
>   ... 44 more
> {code}
> The maven-javadoc-plugin will swallow this exception (without logging), and 
> won't include the jar on the classpath.
> More specifically:
>  # [{{AbstractJavadocMojo}} calls 
> {{locationManager.resolvePaths(request)}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5144]
>  # The returned {{ResolvePathsResult result}} contains the swallowed 
> exception in {{result.getPathExceptions()}}. The result does not include the 
> file in [{{getModulepathElements()}} or 
> {{getClasspathElements()}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5146-L5148]
>  # The {{AbstractJavadocMojo}} ignores the path exceptions
>  # Therefore, the files that have path exceptions do not get included in the 
> classpath or module path
>  # Later, this results in ClassNotFoundExceptions when running javadoc
> One workaround is to _not_ use the jira issue name in the version. However, 
> this practice is extremely baked into our workflow (there is automation 
> around it), and therefore would be very difficult to change.
> I would like the maven-javadoc-plugin to include jars for which the automatic 
> module name cannot be determined on the classpath.
> Potential solutions:
> This could potentially be solved in 
> 

[jira] [Commented] (MJAVADOC-609) Include jars for which module name cannot be determined on the classpath

[Christopher Tubbs (Jira)]

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

Christopher Tubbs commented on MJAVADOC-609:


Why is this one closed? It doesn't seem to have been fixed in 3.1.1
In particular, this is problematic for ALL {{-incubating}} patterns, and this 
blocks module adoption by projects which use any dependencies with 
{{-incubating}} (or {{-STABLE}}, {{-LATEST}}, {{-SNAPSHOT}}, etc.)

> Include jars for which module name cannot be determined on the classpath
> 
>
> Key: MJAVADOC-609
> URL: https://issues.apache.org/jira/browse/MJAVADOC-609
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: javadoc
>Affects Versions: 3.1.0
>Reporter: Phil Clay
>Priority: Major
>
> In maven-javadoc-plugin v3.1.0, dependency jars for which the module name 
> cannot be determined are not included on the classpath when running the 
> javadoc command.  This leads to ClassNotFoundExceptions when running javadoc.
> Here is a concrete example:
> When developing features on feature branches, some developers include jira 
> issue names in the version of artifacts... e.g. {{ABC-1234-SNAPSHOT}}.   This 
> leads to jar file names in the form {{foo-ABC-1234-SNAPSHOT.jar}}.  
> Unfortunately, an automatic module name cannot be determined from the 
> filename of this jar according to the rules of 
> [ModuleFinder|https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...-].
>  When attempting to determine the module name of this jar, the following 
> exception is encountered:
> {code:java}
> java.lang.module.FindException: Unable to derive module descriptor for 
> C:\Users\foo\.m2\repository\com\bar\foo\ABC-1234-SNAPSHOT\foo-ABC-1234-SNAPSHOT.jar
>   at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:647)
>   at 
> java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:330)
>   at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:236)
>   at 
> java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:189)
>   at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:165)
>   at ModuleTest.test(ModuleTest.java:14)
>   ... snip
> Caused by: java.lang.IllegalArgumentException: foo.ABC.1234.SNAPSHOT: Invalid 
> module name: '1234' is not a Java identifier
>   at 
> java.base/jdk.internal.module.Checks.requireModuleName(Checks.java:52)
>   at 
> java.base/java.lang.module.ModuleDescriptor$Builder.(ModuleDescriptor.java:1550)
>   at 
> java.base/java.lang.module.ModuleDescriptor.newAutomaticModule(ModuleDescriptor.java:2438)
>   at 
> java.base/jdk.internal.module.ModulePath.deriveModuleDescriptor(ModulePath.java:507)
>   at java.base/jdk.internal.module.ModulePath.readJar(ModulePath.java:643)
>   ... 44 more
> {code}
> The maven-javadoc-plugin will swallow this exception (without logging), and 
> won't include the jar on the classpath.
> More specifically:
>  # [{{AbstractJavadocMojo}} calls 
> {{locationManager.resolvePaths(request)}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5144]
>  # The returned {{ResolvePathsResult result}} contains the swallowed 
> exception in {{result.getPathExceptions()}}. The result does not include the 
> file in [{{getModulepathElements()}} or 
> {{getClasspathElements()}}|https://github.com/apache/maven-javadoc-plugin/blob/58c0c6da6f23df9f48b319734dd87b1ce5106fd1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L5146-L5148]
>  # The {{AbstractJavadocMojo}} ignores the path exceptions
>  # Therefore, the files that have path exceptions do not get included in the 
> classpath or module path
>  # Later, this results in ClassNotFoundExceptions when running javadoc
> One workaround is to _not_ use the jira issue name in the version. However, 
> this practice is extremely baked into our workflow (there is automation 
> around it), and therefore would be very difficult to change.
> I would like the maven-javadoc-plugin to include jars for which the automatic 
> module name cannot be determined on the classpath.
> Potential solutions:
> This could potentially be solved in 
> [plexus-java|https://github.com/codehaus-plexus/plexus-languages/blob/879376946165679eb3bb980ddaf8db68ab2031d4/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/LocationManager.java#L356],
>  by having {{LocationManager.resolvePaths}} return jars for which the 
> automatic module name cannot be determined as part of 
> {{result.getClasspathElements()}}
> Or, it could be solved it maven-javadoc-plugin by having 
> 

[jira] [Commented] (MPOM-218) consider impact of maven-remote-resources-plugin in plugins not pluginManagement

[Christopher Tubbs (JIRA)]

[ 
https://issues.apache.org/jira/browse/MPOM-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900492#comment-16900492
 ] 

Christopher Tubbs commented on MPOM-218:


In Accumulo, we just just provide a basic "DEPENDENCIES" file. The plugin 
doesn't clobber the one that already exists: 
https://github.com/apache/accumulo/blob/rel/2.0.0/DEPENDENCIES

> consider impact of maven-remote-resources-plugin in plugins not 
> pluginManagement 
> -
>
> Key: MPOM-218
> URL: https://issues.apache.org/jira/browse/MPOM-218
> Project: Maven POMs
>  Issue Type: Improvement
>Reporter: Adrian Cole
>Priority: Major
>
> While maven-remote-resources-plugin in plugins, it is difficult to work with 
> vs if it were in pluginManagement. For example, the parent pom can spit out a 
> distracting empty DEPENDENCIES file, which ends up by default in the source 
> distribution.
> I've noticed multiple projects (ex dubbo, edgent) creating separate 
> distribution modules which on one hand works around this issue, but on the 
> other is a source of maintenance.
> I'd ask to consider using pluginManagement instead, or possibly having the 
> ability to not create a DEPENDENCIES file when there are none, which would 
> also solve the problem. Maybe there's also another way to strip this out with 
> an assembly, but I've failed to figure this out.



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

[jira] [Updated] (MSITE-848) sitedescriptor example page fails to describe restrictions on dotted properties

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs updated MSITE-848:

Description: 
I tried injecting a property from {{pom.xml}} into 
{{src/site/markdown/index.md.vm}}.

It did not work when the property was {{accumulo.version}}, but did work when I 
switched the property name to {{accumuloVersion}}.

With the dot present in the property name, nothing was interpolated, and 
instead, I got the literal {{${accumulo.version\}}} in my html output.

EDIT: Title updated to reflect that this is a documentation bug. See the pull 
request for proposed solution.

  was:
I tried injecting a property from {{pom.xml}} into 
{{src/site/markdown/index.md.vm}}.

It did not work when the property was {{accumulo.version}}, but did work when I 
switched the property name to {{accumuloVersion}}.

With the dot present in the property name, nothing was interpolated, and 
instead, I got the literal {{${accumulo.version\}}} in my html output.

Summary: sitedescriptor example page fails to describe restrictions on 
dotted properties  (was: Maven properties with dots do not get injected into 
site templates)

> sitedescriptor example page fails to describe restrictions on dotted 
> properties
> ---
>
> Key: MSITE-848
> URL: https://issues.apache.org/jira/browse/MSITE-848
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: property interpolation
>Affects Versions: 3.8.2
>Reporter: Christopher Tubbs
>Assignee: Robert Scholte
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I tried injecting a property from {{pom.xml}} into 
> {{src/site/markdown/index.md.vm}}.
> It did not work when the property was {{accumulo.version}}, but did work when 
> I switched the property name to {{accumuloVersion}}.
> With the dot present in the property name, nothing was interpolated, and 
> instead, I got the literal {{${accumulo.version\}}} in my html output.
> EDIT: Title updated to reflect that this is a documentation bug. See the pull 
> request for proposed solution.



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

[jira] [Commented] (MSITE-848) Maven properties with dots do not get injected into site templates

[Christopher Tubbs (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSITE-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899156#comment-16899156
 ] 

Christopher Tubbs commented on MSITE-848:
-

[~rfscholte] Thanks for the response. That's useful information. When I 
searched, the following page showed up first in search results: 
https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Custom_Properties
 

If this bug could be re-opened and resolved as a documentation bug, I think 
it'd be great to mention that restriction on the sitedescriptor.html page 
(could link to the creating-content.html page).

> Maven properties with dots do not get injected into site templates
> --
>
> Key: MSITE-848
> URL: https://issues.apache.org/jira/browse/MSITE-848
> Project: Maven Site Plugin
>  Issue Type: Bug
>  Components: property interpolation
>Affects Versions: 3.8.2
>Reporter: Christopher Tubbs
>Assignee: Robert Scholte
>Priority: Major
>
> I tried injecting a property from {{pom.xml}} into 
> {{src/site/markdown/index.md.vm}}.
> It did not work when the property was {{accumulo.version}}, but did work when 
> I switched the property name to {{accumuloVersion}}.
> With the dot present in the property name, nothing was interpolated, and 
> instead, I got the literal {{${accumulo.version\}}} in my html output.



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

[jira] [Created] (MSITE-848) Maven properties with dots do not get injected into site templates

[Christopher Tubbs (JIRA)]

Christopher Tubbs created MSITE-848:
---

 Summary: Maven properties with dots do not get injected into site 
templates
 Key: MSITE-848
 URL: https://issues.apache.org/jira/browse/MSITE-848
 Project: Maven Site Plugin
  Issue Type: Bug
  Components: property interpolation
Affects Versions: 3.8.2
Reporter: Christopher Tubbs


I tried injecting a property from {{pom.xml}} into 
{{src/site/markdown/index.md.vm}}.

It did not work when the property was {{accumulo.version}}, but did work when I 
switched the property name to {{accumuloVersion}}.

With the dot present in the property name, nothing was interpolated, and 
instead, I got the literal {{${accumulo.version\}}} in my html output.



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

[jira] [Commented] (MNG-2496) dependencyManagement not used for dependencies in plugin section.

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MNG-2496:


To be fair, overriding the plugin's dependency versions within the plugin 
declaration itself does work it just downloads some unnecessary metadata to 
resolve version ranges first, before promptly ignoring all that it just 
downloaded and using the override version anyway.

> dependencyManagement not used for dependencies in plugin section.
> -
>
> Key: MNG-2496
> URL: https://issues.apache.org/jira/browse/MNG-2496
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 2.0.4
>Reporter: Brian Fox
>Priority: Major
>
> In my parent, I have a dependencyManagement set with this jar:
> 
> 
> 
> com.stchome.build.maven
> testng-initializer
> 1.0
> test
> 
> I have a plugin specified that had a dependency like this:
> 
> maven-antrun-plugin
> 
> 
> run-testng
> test
> 
> 
>  classname="com.stchome.testng.initializer.PackageInitializer">
>  path="${project.build.testOutputDirectory}"/>
>  path="${project.build.testSourceDirectory}"/>
> 
>  inheritRefs="true" inheritAll="true">
>  value="${project.build.directory}"/>
>  value="${project.build.testOutputDirectory}"/>
>  value="${project.build.testSourceDirectory}"/>
> 
> 
> 
> 
> run
> 
> 
> 
> 
> 
> com.stchome.build.maven
> testng-initializer
> 
> 
> 
> When I build, it doesn't seem to resolve this dependency version from 
> dependencyManagement
> [INFO] An invalid artifact was detected.
> This artifact might be in your project's POM, or it might have been included 
> transitively du
>  information we do have for this artifact:
> o GroupID: com.stchome.build.maven
> o ArtifactID:  testng-initializer
> o Version: <<< MISSING >>>
> o Type:jar
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.artifact.InvalidArtifactRTException: For artifact 
> {com.stchome.build.maven:
> n cannot be empty.
> at 
> org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:1
> at 
> org.apache.maven.artifact.DefaultArtifact.(DefaultArtifact.java:119)
> at 
> org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultAr
> at 
> org.apache.maven.artifact.factory.DefaultArtifactFactory.createDependencyArtifact
> at 
> org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetada
> at 
> org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:
> at 
> org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginM
> at 
> org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.ja
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycle
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(Default
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(De
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleE
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLi
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecu
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> 

[jira] [Commented] (MNG-5583) Better PKCS12 and/or PKCS11 support

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MNG-5583:


It's not a high priority for me right now. Feel free to close it, if nobody 
else is pushing for it. It's still a security issue, but (perhaps) not a 
serious one.

> Better PKCS12 and/or PKCS11 support
> ---
>
> Key: MNG-5583
> URL: https://issues.apache.org/jira/browse/MNG-5583
> Project: Maven
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 3.1.1
> Environment: Any multi-user environment, especially Unix/Linux 
> environments.
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
> Fix For: waiting-for-feedback
>
>
> Maven supports dependency resolution through HTTPS with client-authentication 
> (documented MNG-1560), via JSSE system properties on the java command-line. 
> These can be configured in the environment of the process that launches Maven 
> as 
> [MAVEN_OPTS|https://maven.apache.org/guides/mini/guide-repository-ssl.html], 
> which can be made relatively secure.
> However, eventually, when the mvn bootstrap script starts Maven's java 
> process, these options are placed on the command line for java. This is 
> extremely problematic, because it means that any JSSE properties with 
> sensitive information (javax.net.ssl.keyStorePassword, for example) are 
> visible in the process list to any user of the system. This is explicitly 
> [advised against by 
> Java|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization],
>  but appears to be the only way to pass this information to Maven.
> Maven can do a better job of prompting for, or configuring, passphrases for 
> keyStores and trustStores. It already has the ability to configure server 
> credentials in the settings.xml file, protected with a master passphrase read 
> from a different file 
> ([~/.m2/settings-security.xml|https://maven.apache.org/guides/mini/guide-encryption.html]).
>  This would work for JKS and PKCS12 keystores today, if there were a way to 
> configure the passphrases there instead of in MAVEN_OPTS.
> Another option would be to support PKCS11 keystores, configured via the 
> current JSSE system properties. However, to do this, Maven needs to 
> instantiate the SSL configuration in the http client with an AuthProvider and 
> a callback handler which prompts for the PKCS11 pin/passphrase.



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

[jira] [Commented] (MNG-5583) Better PKCS12 and/or PKCS11 support

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MNG-5583:


I haven't tried this in awhile, but I believe it's still relevant, because the 
JSSE system property for the keystore passphrase is still placed on the process 
command-line, just like all the other MAVEN_OPTS properties in ~/.mavenrc are 
placed on the process command-line. There doesn't appear to be a built-in 
mechanism to retrieve the unlock passphrase any other way.

I believe you are suggesting that Maven could manage the credential storage 
similar to how it manages SSH credentials. I don't think I'd be any help with 
the code implementation, but I might be able to help from a user-experience 
side of things (to test and offer suggestions).

> Better PKCS12 and/or PKCS11 support
> ---
>
> Key: MNG-5583
> URL: https://issues.apache.org/jira/browse/MNG-5583
> Project: Maven
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 3.1.1
> Environment: Any multi-user environment, especially Unix/Linux 
> environments.
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
> Fix For: waiting-for-feedback
>
>
> Maven supports dependency resolution through HTTPS with client-authentication 
> (documented MNG-1560), via JSSE system properties on the java command-line. 
> These can be configured in the environment of the process that launches Maven 
> as 
> [MAVEN_OPTS|https://maven.apache.org/guides/mini/guide-repository-ssl.html], 
> which can be made relatively secure.
> However, eventually, when the mvn bootstrap script starts Maven's java 
> process, these options are placed on the command line for java. This is 
> extremely problematic, because it means that any JSSE properties with 
> sensitive information (javax.net.ssl.keyStorePassword, for example) are 
> visible in the process list to any user of the system. This is explicitly 
> [advised against by 
> Java|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization],
>  but appears to be the only way to pass this information to Maven.
> Maven can do a better job of prompting for, or configuring, passphrases for 
> keyStores and trustStores. It already has the ability to configure server 
> credentials in the settings.xml file, protected with a master passphrase read 
> from a different file 
> ([~/.m2/settings-security.xml|https://maven.apache.org/guides/mini/guide-encryption.html]).
>  This would work for JKS and PKCS12 keystores today, if there were a way to 
> configure the passphrases there instead of in MAVEN_OPTS.
> Another option would be to support PKCS11 keystores, configured via the 
> current JSSE system properties. However, to do this, Maven needs to 
> instantiate the SSL configuration in the http client with an AuthProvider and 
> a callback handler which prompts for the PKCS11 pin/passphrase.



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

[jira] [Updated] (MNG-5583) Better PKCS12 and/or PKCS11 support

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs updated MNG-5583:
---
Description: 
Maven supports dependency resolution through HTTPS with client-authentication 
(documented MNG-1560), via JSSE system properties on the java command-line. 
These can be configured in the environment of the process that launches Maven 
as [MAVEN_OPTS|https://maven.apache.org/guides/mini/guide-repository-ssl.html], 
which can be made relatively secure.

However, eventually, when the mvn bootstrap script starts Maven's java process, 
these options are placed on the command line for java. This is extremely 
problematic, because it means that any JSSE properties with sensitive 
information (javax.net.ssl.keyStorePassword, for example) are visible in the 
process list to any user of the system. This is explicitly [advised against by 
Java|https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization],
 but appears to be the only way to pass this information to Maven.

Maven can do a better job of prompting for, or configuring, passphrases for 
keyStores and trustStores. It already has the ability to configure server 
credentials in the settings.xml file, protected with a master passphrase read 
from a different file 
([~/.m2/settings-security.xml|https://maven.apache.org/guides/mini/guide-encryption.html]).
 This would work for JKS and PKCS12 keystores today, if there were a way to 
configure the passphrases there instead of in MAVEN_OPTS.

Another option would be to support PKCS11 keystores, configured via the current 
JSSE system properties. However, to do this, Maven needs to instantiate the SSL 
configuration in the http client with an AuthProvider and a callback handler 
which prompts for the PKCS11 pin/passphrase.

  was:
Maven supports dependency resolution through HTTPS with client-authentication 
(documented MNG-1560), via JSSE system properties on the java command-line. 
These can be configured in the environment of the process that launches Maven 
as [MAVEN_OPTS|http://maven.apache.org/guides/mini/guide-repository-ssl.html], 
which can be made relatively secure.

However, eventually, when the mvn bootstrap script starts Maven's java process, 
these options are placed on the command line for java. This is extremely 
problematic, because it means that any JSSE properties with sensitive 
information (javax.net.ssl.keyStorePassword, for example) are visible in the 
process list to any user of the system. This is explicitly [advised against by 
Java|http://download.java.net/jdk8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization],
 but appears to be the only way to pass this information to Maven.

Maven can do a better job of prompting for, or configuring, passphrases for 
keyStores and trustStores. It already has the ability to configure server 
credentials in the settings.xml file, protected with a master passphrase read 
from a different file 
([~/.m2/settings-security.xml|http://maven.apache.org/guides/mini/guide-encryption.html]).
 This would work for JKS and PKCS12 keystores today, if there were a way to 
configure the passphrases there instead of in MAVEN_OPTS.

Another option would be to support PKCS11 keystores, configured via the current 
JSSE system properties. However, to do this, Maven needs to instantiate the SSL 
configuration in the http client with an AuthProvider and a callback handler 
which prompts for the PKCS11 pin/passphrase.


> Better PKCS12 and/or PKCS11 support
> ---
>
> Key: MNG-5583
> URL: https://issues.apache.org/jira/browse/MNG-5583
> Project: Maven
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 3.1.1
> Environment: Any multi-user environment, especially Unix/Linux 
> environments.
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
> Fix For: waiting-for-feedback
>
>
> Maven supports dependency resolution through HTTPS with client-authentication 
> (documented MNG-1560), via JSSE system properties on the java command-line. 
> These can be configured in the environment of the process that launches Maven 
> as 
> [MAVEN_OPTS|https://maven.apache.org/guides/mini/guide-repository-ssl.html], 
> which can be made relatively secure.
> However, eventually, when the mvn bootstrap script starts Maven's java 
> process, these options are placed on the command line for java. This is 
> extremely problematic, because it means that any JSSE properties with 
> sensitive information (javax.net.ssl.keyStorePassword, for example) are 
> visible in the process list to any user of the system. This is explicitly 
> [advised against by 
> 

[jira] [Commented] (MINSTALL-143) Move checksum generation from install to deploy plugin

[Christopher Tubbs (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINSTALL-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16756734#comment-16756734
 ] 

Christopher Tubbs commented on MINSTALL-143:


[~beamerblvd], where do you see that recommendation "online"? Personally, I 
wouldn't recommend that. I just use maven-deploy-plugin and it works just fine 
when publishing to Sonatype Nexus repository manager staging repositories, and 
then use the UIs to close and/or release the repositories from there. I do not 
know what advantage nexus-staging-maven-plugin offers over maven-deploy-plugin, 
so perhaps there's some cool feature I'm missing out on... but I suspect not, 
since everything works just fine without it.

> Move checksum generation from install to deploy plugin
> --
>
> Key: MINSTALL-143
> URL: https://issues.apache.org/jira/browse/MINSTALL-143
> Project: Maven Install Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0-M1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 3.0.0-M1
>
>
> We should move the checksum generation from maven-install-plugin to 
> maven-deploy-plugin cause the checksums will only be needed as a preparation 
> for the transfer to a remote repository but not for an installation into a 
> local repository.
> This needed to be done within maven-artifact-transfer component first.



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

[jira] [Commented] (MINVOKER-243) invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MINVOKER-243:


[~rfscholte], yes. In this case, the transitive dependency is a sibling module 
in a multi-module project.

Example:

module A: depends on commons-configuration
module B: depends on A and commons-io
module C: maven plugin configured with invoker for ITs, depends on B

{{invoker:install}} in module C should install the jar from module B, and also 
the jar from module A (because it is a transitive dependency of B), but not 
commons-io or commons-configuration.

Version 3.0.1 works fine, but 3.1.0 fails to install module A, instead only 
installing module B.

> invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)
> --
>
> Key: MINVOKER-243
> URL: https://issues.apache.org/jira/browse/MINVOKER-243
> Project: Maven Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Christopher Tubbs
>Priority: Blocker
>
> Something seems to have broken between 3.0.1 and 3.1.0, as the install goal 
> no longer copies transitive dependencies to the localRepositoryPath as it did 
> in version 3.0.1.
> This is very problematic, because if the artifacts are not in the 
> localRepositoryPath, the invoked project will try to download them from a 
> remote repository, which isn't possible for SNAPSHOT versions (such as those 
> in a sibling module in a multi-module project). This can make it difficult to 
> even build a multi-module project, unless the invoked task is skipped and the 
> sibling module can be published to a remote snapshot repository temporarily, 
> and then the build re-executed normally. (Saw this happen in Apache Accumulo 
> after upgrading to apache-21.pom)



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

[jira] [Commented] (MINVOKER-243) invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MINVOKER-243:


If I had more time, I could try to create a smaller project for reproducing the 
issue, but I'm currently prepping to head to Montreal for ApacheCon. For now, 
hopefully the Accumulo example will suffice.

> invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)
> --
>
> Key: MINVOKER-243
> URL: https://issues.apache.org/jira/browse/MINVOKER-243
> Project: Maven Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Christopher Tubbs
>Priority: Blocker
>
> Something seems to have broken between 3.0.1 and 3.1.0, as the install goal 
> no longer copies transitive dependencies to the localRepositoryPath as it did 
> in version 3.0.1.
> This is very problematic, because if the artifacts are not in the 
> localRepositoryPath, the invoked project will try to download them from a 
> remote repository, which isn't possible for SNAPSHOT versions (such as those 
> in a sibling module in a multi-module project). This can make it difficult to 
> even build a multi-module project, unless the invoked task is skipped and the 
> sibling module can be published to a remote snapshot repository temporarily, 
> and then the build re-executed normally. (Saw this happen in Apache Accumulo 
> after upgrading to apache-21.pom)



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

[jira] [Commented] (MINVOKER-243) invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MINVOKER-243:


[~khmarbaise], sure thing: the current master branch of Accumulo 
(2.0.0-SNAPSHOT) fails in the maven-plugin module. I fixed this in commit 
[https://github.com/apache/accumulo/commit/16795c526f6d39d1cffd5be39168850bd1d6fbbd]
 by reverting to 3.0.1 of the plugin, but if you edit the pom to use 3.1.0 
again (which is the version set in the Apache POM version 21), it fails to copy 
the transitive dependencies during the install goal.

You can see the difference by just looking at the number of jars copied during 
the "install" goal

For example, compare the console output of this broken build (3.1.0):
[https://builds.apache.org/view/A/view/Accumulo/job/Accumulo-Master/2473/org.apache.accumulo$accumulo-maven-plugin/console]

with this working one (3.0.1):
[https://builds.apache.org/view/A/view/Accumulo/job/Accumulo-Master/2475/org.apache.accumulo$accumulo-maven-plugin/console]

If you want to try to reproduce locally, keep in mind Accumulo probably won't 
build on Windows (only Mac and Linux), and also has a native JNI library, so 
you need {{g++}} and {{make}} installed. You can also make the build faster by 
doing {{mvn clean verify -Dtest=blah -Dit.test=blah -Dspotbugs.skip 
-Dcheckstyle.skip -Dwarbucks.skip -Dmodernizer.skip -P\!autoformat}}. Don't do 
{{-DskipTests}} or {{-DskipITs}} because that will activate a profile which 
skips the invoker plugin execution entirely. Also, keep in mind that now that 
we've had a successful build, the build may succeed in spite of this bug, 
because it will pull the previous build's jar from the SNAPSHOT repository 
instead of from the sibling module's current build. But, you'll still be able 
to see the failure if you clobber the ${distMgmtSnapshotsUrl} property from the 
parent POM so it doesn't grab the previous snapshot build. And, in either case, 
you can still see the difference in the log output regarding which dependencies 
are being installed.

> invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)
> --
>
> Key: MINVOKER-243
> URL: https://issues.apache.org/jira/browse/MINVOKER-243
> Project: Maven Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Christopher Tubbs
>Priority: Blocker
>
> Something seems to have broken between 3.0.1 and 3.1.0, as the install goal 
> no longer copies transitive dependencies to the localRepositoryPath as it did 
> in version 3.0.1.
> This is very problematic, because if the artifacts are not in the 
> localRepositoryPath, the invoked project will try to download them from a 
> remote repository, which isn't possible for SNAPSHOT versions (such as those 
> in a sibling module in a multi-module project). This can make it difficult to 
> even build a multi-module project, unless the invoked task is skipped and the 
> sibling module can be published to a remote snapshot repository temporarily, 
> and then the build re-executed normally. (Saw this happen in Apache Accumulo 
> after upgrading to apache-21.pom)



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

[jira] [Comment Edited] (MINVOKER-243) invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs edited comment on MINVOKER-243 at 9/23/18 12:57 AM:
--

[~khmarbaise], sure thing: the current master branch of Accumulo 
(2.0.0-SNAPSHOT) failed in the maven-plugin module before I fixed this in 
commit 
[https://github.com/apache/accumulo/commit/16795c526f6d39d1cffd5be39168850bd1d6fbbd]
 by reverting to 3.0.1 of the plugin, but if you edit the pom to use 3.1.0 
again (which is the version set in the Apache POM version 21), it fails to copy 
the transitive dependencies during the install goal.

You can see the difference by just looking at the number of jars copied during 
the "install" goal

For example, compare the console output of this broken build (3.1.0):
 
[https://builds.apache.org/view/A/view/Accumulo/job/Accumulo-Master/2473/org.apache.accumulo$accumulo-maven-plugin/console]

with this working one (3.0.1):
 
[https://builds.apache.org/view/A/view/Accumulo/job/Accumulo-Master/2475/org.apache.accumulo$accumulo-maven-plugin/console]

If you want to try to reproduce locally, keep in mind Accumulo probably won't 
build on Windows (only Mac and Linux), and also has a native JNI library, so 
you need {{g++}} and {{make}} installed. You can also make the build faster by 
doing {{mvn clean verify -Dtest=blah -Dit.test=blah -Dspotbugs.skip 
-Dcheckstyle.skip -Dwarbucks.skip -Dmodernizer.skip -P!autoformat}}. Don't do 
{{-DskipTests}} or {{-DskipITs}} because that will activate a profile which 
skips the invoker plugin execution entirely. Also, keep in mind that now that 
we've had a successful build, the build may succeed in spite of this bug, 
because it will pull the previous build's jar from the SNAPSHOT repository 
instead of from the sibling module's current build. But, you'll still be able 
to see the failure if you clobber the ${distMgmtSnapshotsUrl} property from the 
parent POM so it doesn't grab the previous snapshot build. And, in either case, 
you can still see the difference in the log output regarding which dependencies 
are being installed.


was (Author: ctubbsii):
[~khmarbaise], sure thing: the current master branch of Accumulo 
(2.0.0-SNAPSHOT) fails in the maven-plugin module. I fixed this in commit 
[https://github.com/apache/accumulo/commit/16795c526f6d39d1cffd5be39168850bd1d6fbbd]
 by reverting to 3.0.1 of the plugin, but if you edit the pom to use 3.1.0 
again (which is the version set in the Apache POM version 21), it fails to copy 
the transitive dependencies during the install goal.

You can see the difference by just looking at the number of jars copied during 
the "install" goal

For example, compare the console output of this broken build (3.1.0):
[https://builds.apache.org/view/A/view/Accumulo/job/Accumulo-Master/2473/org.apache.accumulo$accumulo-maven-plugin/console]

with this working one (3.0.1):
[https://builds.apache.org/view/A/view/Accumulo/job/Accumulo-Master/2475/org.apache.accumulo$accumulo-maven-plugin/console]

If you want to try to reproduce locally, keep in mind Accumulo probably won't 
build on Windows (only Mac and Linux), and also has a native JNI library, so 
you need {{g++}} and {{make}} installed. You can also make the build faster by 
doing {{mvn clean verify -Dtest=blah -Dit.test=blah -Dspotbugs.skip 
-Dcheckstyle.skip -Dwarbucks.skip -Dmodernizer.skip -P\!autoformat}}. Don't do 
{{-DskipTests}} or {{-DskipITs}} because that will activate a profile which 
skips the invoker plugin execution entirely. Also, keep in mind that now that 
we've had a successful build, the build may succeed in spite of this bug, 
because it will pull the previous build's jar from the SNAPSHOT repository 
instead of from the sibling module's current build. But, you'll still be able 
to see the failure if you clobber the ${distMgmtSnapshotsUrl} property from the 
parent POM so it doesn't grab the previous snapshot build. And, in either case, 
you can still see the difference in the log output regarding which dependencies 
are being installed.

> invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)
> --
>
> Key: MINVOKER-243
> URL: https://issues.apache.org/jira/browse/MINVOKER-243
> Project: Maven Invoker Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Christopher Tubbs
>Priority: Blocker
>
> Something seems to have broken between 3.0.1 and 3.1.0, as the install goal 
> no longer copies transitive dependencies to the localRepositoryPath as it did 
> in version 3.0.1.
> This is very problematic, because if the artifacts are not in the 
> localRepositoryPath, the invoked project will try to download them from a 
> remote repository, which isn't possible 

[jira] [Created] (MINVOKER-243) invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)

[Christopher Tubbs (JIRA)]

Christopher Tubbs created MINVOKER-243:
--

 Summary: invoker:install doesn't copy transitive dependencies 
anymore (as of 3.1.0)
 Key: MINVOKER-243
 URL: https://issues.apache.org/jira/browse/MINVOKER-243
 Project: Maven Invoker Plugin
  Issue Type: Bug
Affects Versions: 3.1.0
Reporter: Christopher Tubbs


Something seems to have broken between 3.0.1 and 3.1.0, as the install goal no 
longer copies transitive dependencies to the localRepositoryPath as it did in 
version 3.0.1.

This is very problematic, because if the artifacts are not in the 
localRepositoryPath, the invoked project will try to download them from a 
remote repository, which isn't possible for SNAPSHOT versions (such as those in 
a sibling module in a multi-module project). This can make it difficult to even 
build a multi-module project, unless the invoked task is skipped and the 
sibling module can be published to a remote snapshot repository temporarily, 
and then the build re-executed normally. (Saw this happen in Apache Accumulo 
after upgrading to apache-21.pom)



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

[jira] [Commented] (MNG-5689) Checksum policy for mirrors

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MNG-5689:


MNG-4645 implies that the configuration for central can be overridden by 
creating a new repository configuration with the same id "central", but with 
different configuration, instead of using a mirror. If that is true, then this 
issue can be closed, since the "mirrors" section seems entirely unnecessary, if 
any repository can be overridden in the settings.xml file this way.

Either MNG-5728 or MNG-5506 would also satisfy my use case.

> Checksum policy for mirrors
> ---
>
> Key: MNG-5689
> URL: https://issues.apache.org/jira/browse/MNG-5689
> Project: Maven
>  Issue Type: Improvement
>  Components: Settings
>Affects Versions: 3.2.3
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
>
> It does not appear that there is any way to configure a checksum policy for 
> mirrors in the settings.xml file.
> In particular, I'd love to enforce a "strict" checksum policy on maven 
> central. I can configure a mirrorOf central, but I cannot set the checksum 
> policy. This seems like a big oversight.



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

[jira] [Commented] (MNG-5689) Checksum policy for mirrors

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MNG-5689:


bq. These days, everyone is encouraged to use a repo manager with a proxy 
repository.

As long as Maven ships with a default repository already configured, and POMs 
are able to specify additional repositories, it will remain necessary for users 
to be able to override configuration for those repositories when they configure 
a mirror to use instead of the default one or those specified in POMs. The fact 
that everyone is now encouraged to use a repo manager makes this even more 
important, because that is precisely the situation where configuring a mirror 
matters.

> Checksum policy for mirrors
> ---
>
> Key: MNG-5689
> URL: https://issues.apache.org/jira/browse/MNG-5689
> Project: Maven
>  Issue Type: Improvement
>  Components: Settings
>Affects Versions: 3.2.3
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
>
> It does not appear that there is any way to configure a checksum policy for 
> mirrors in the settings.xml file.
> In particular, I'd love to enforce a "strict" checksum policy on maven 
> central. I can configure a mirrorOf central, but I cannot set the checksum 
> policy. This seems like a big oversight.



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

[jira] [Comment Edited] (MNG-5689) Checksum policy for mirrors

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs edited comment on MNG-5689 at 3/26/18 4:09 PM:
-

Ah, understood. That could work. I haven't tested it. It might work as a 
workaround, if it applies globally, but it's still better to be able to 
configure repositories in the configuration files.

If {{-C}} works, maybe a simpler design would be to add a top-level 
{{}} which corresponds to that command-line option?


was (Author: ctubbsii):
Ah, understood. That could work. I haven't tested it. It might work as a 
workaround, if it applies globally, but it's still better to be able to 
configure repositories in the configuration files.

If {{ -C }} works, maybe a simpler design would be to add a top-level 
{{}} which corresponds to that command-line option?

> Checksum policy for mirrors
> ---
>
> Key: MNG-5689
> URL: https://issues.apache.org/jira/browse/MNG-5689
> Project: Maven
>  Issue Type: Improvement
>  Components: Settings
>Affects Versions: 3.2.3
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
>
> It does not appear that there is any way to configure a checksum policy for 
> mirrors in the settings.xml file.
> In particular, I'd love to enforce a "strict" checksum policy on maven 
> central. I can configure a mirrorOf central, but I cannot set the checksum 
> policy. This seems like a big oversight.



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

[jira] [Commented] (MNG-5689) Checksum policy for mirrors

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MNG-5689:


Ah, understood. That could work. I haven't tested it. It might work as a 
workaround, if it applies globally, but it's still better to be able to 
configure repositories in the configuration files.

If {{ -C }} works, maybe a simpler design would be to add a top-level 
{{}} which corresponds to that command-line option?

> Checksum policy for mirrors
> ---
>
> Key: MNG-5689
> URL: https://issues.apache.org/jira/browse/MNG-5689
> Project: Maven
>  Issue Type: Improvement
>  Components: Settings
>Affects Versions: 3.2.3
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
>
> It does not appear that there is any way to configure a checksum policy for 
> mirrors in the settings.xml file.
> In particular, I'd love to enforce a "strict" checksum policy on maven 
> central. I can configure a mirrorOf central, but I cannot set the checksum 
> policy. This seems like a big oversight.



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

[jira] [Commented] (MNG-5689) Checksum policy for mirrors

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MNG-5689:


An alternative for what? That just prints the version information. How does 
that relate to this issue?

> Checksum policy for mirrors
> ---
>
> Key: MNG-5689
> URL: https://issues.apache.org/jira/browse/MNG-5689
> Project: Maven
>  Issue Type: Improvement
>  Components: Settings
>Affects Versions: 3.2.3
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
>
> It does not appear that there is any way to configure a checksum policy for 
> mirrors in the settings.xml file.
> In particular, I'd love to enforce a "strict" checksum policy on maven 
> central. I can configure a mirrorOf central, but I cannot set the checksum 
> policy. This seems like a big oversight.



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

[jira] [Commented] (MNG-5689) Checksum policy for mirrors

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MNG-5689:


I had a mirror with broken artifacts in it... which is what motivated me to 
create this. Maven was perfectly happy downloading the broken artifacts, 
warning about them (the default behavior), and then putting the broken 
artifacts on the class path when I built my application. It was a pain to 
figure out why my builds were failing. A strict "fail" checksum policy would 
have made it obvious.

> Checksum policy for mirrors
> ---
>
> Key: MNG-5689
> URL: https://issues.apache.org/jira/browse/MNG-5689
> Project: Maven
>  Issue Type: Improvement
>  Components: Settings
>Affects Versions: 3.2.3
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
>
> It does not appear that there is any way to configure a checksum policy for 
> mirrors in the settings.xml file.
> In particular, I'd love to enforce a "strict" checksum policy on maven 
> central. I can configure a mirrorOf central, but I cannot set the checksum 
> policy. This seems like a big oversight.



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

[jira] [Commented] (MNG-5689) Checksum policy for mirrors

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MNG-5689:


Essentially, what I'm trying to do is avoid downloading corrupt artifacts from 
a Maven Central mirror. I can configure the mirror, but I currently have no way 
to set a strict checksum policy.

If there's an existing way to set the checksum policy for artifacts downloaded 
from a mirror, then there's no need for what I'm suggesting.

> Checksum policy for mirrors
> ---
>
> Key: MNG-5689
> URL: https://issues.apache.org/jira/browse/MNG-5689
> Project: Maven
>  Issue Type: Improvement
>  Components: Settings
>Affects Versions: 3.2.3
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
>
> It does not appear that there is any way to configure a checksum policy for 
> mirrors in the settings.xml file.
> In particular, I'd love to enforce a "strict" checksum policy on maven 
> central. I can configure a mirrorOf central, but I cannot set the checksum 
> policy. This seems like a big oversight.



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

[jira] [Commented] (MNG-5689) Checksum policy for mirrors

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MNG-5689:


According to https://maven.apache.org/settings.html repositories can be 
configured (in settings.xml or pom.xml) like:

{code}
  

  codehausSnapshots
  Codehaus Snapshots
  
false
always
warn
  
  
true
never
fail
  
  http://snapshots.maven.codehaus.org/maven2
  default

  
{code}

However, mirrors can only specify (in settings.xml):

{code}
  

  planetmirror.com
  PlanetMirror Australia
  http://downloads.planetmirror.com/pub/maven2
  central

  
{code}

Mirrors should have the additional options missing:
{code}
  
false
always
warn
  
  
true
never
fail
  
  default
{code}

That way, they can not only substitute for the policy for the repository, but 
they can also override it.

Example:

{code}
  

  planetmirror.com
  PlanetMirror Australia
  http://downloads.planetmirror.com/pub/maven2
  central
  
true
fail
  
  
false
  

  
{code}


> Checksum policy for mirrors
> ---
>
> Key: MNG-5689
> URL: https://issues.apache.org/jira/browse/MNG-5689
> Project: Maven
>  Issue Type: Improvement
>  Components: Settings
>Affects Versions: 3.2.3
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
>
> It does not appear that there is any way to configure a checksum policy for 
> mirrors in the settings.xml file.
> In particular, I'd love to enforce a "strict" checksum policy on maven 
> central. I can configure a mirrorOf central, but I cannot set the checksum 
> policy. This seems like a big oversight.



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

[jira] [Commented] (MNG-5689) Checksum policy for mirrors

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MNG-5689:


I would encourage the Maven community to consider addressing this issue. The 
inability to enforce a strict checksum policy means that it is that much harder 
to detect corrupt artifacts. This could be viewed as a security issue, in the 
case where artifacts are intentionally corrupted by a man-in-the-middle attack 
to inject vulerable code when the downloaded library is used, or as a denial of 
service attack, to prevent software from building or running because it cannot 
download working dependent software libraries. I realize, of course, that the 
checksum policy has only a limited ability to prevent such security problems 
(because the checksums are stored "in-band" with the artifacts themselves, and 
anybody able to manipulate the artifacts could also manipulate the checksums), 
but I still think it's better for users to be able to have *some* kind of 
assurances from the server that the artifacts haven't been altered in transit.

> Checksum policy for mirrors
> ---
>
> Key: MNG-5689
> URL: https://issues.apache.org/jira/browse/MNG-5689
> Project: Maven
>  Issue Type: Improvement
>  Components: Settings
>Affects Versions: 3.2.3
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
>
> It does not appear that there is any way to configure a checksum policy for 
> mirrors in the settings.xml file.
> In particular, I'd love to enforce a "strict" checksum policy on maven 
> central. I can configure a mirrorOf central, but I cannot set the checksum 
> policy. This seems like a big oversight.



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

[jira] [Commented] (MNG-5583) Better PKCS12 and/or PKCS11 support

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on MNG-5583:


I would encourage the Maven community to consider addressing this issue... 
because the current implementation can expose JSSE system properties to other 
users, which could expose private credentials. Being able to connect to a 
secure Maven repository server may not be a high priority for users primarily 
using Maven Central, but for any enterprise environment, where an 
authenticating Maven repository server is used to distribute critical software 
artifacts, it would be nice to not expose credentials for PKCS12 and JKS 
keystores via JSSE system properties on the process command-line.

> Better PKCS12 and/or PKCS11 support
> ---
>
> Key: MNG-5583
> URL: https://issues.apache.org/jira/browse/MNG-5583
> Project: Maven
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 3.1.1
> Environment: Any multi-user environment, especially Unix/Linux 
> environments.
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
>
> Maven supports dependency resolution through HTTPS with client-authentication 
> (documented MNG-1560), via JSSE system properties on the java command-line. 
> These can be configured in the environment of the process that launches Maven 
> as 
> [MAVEN_OPTS|http://maven.apache.org/guides/mini/guide-repository-ssl.html], 
> which can be made relatively secure.
> However, eventually, when the mvn bootstrap script starts Maven's java 
> process, these options are placed on the command line for java. This is 
> extremely problematic, because it means that any JSSE properties with 
> sensitive information (javax.net.ssl.keyStorePassword, for example) are 
> visible in the process list to any user of the system. This is explicitly 
> [advised against by 
> Java|http://download.java.net/jdk8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization],
>  but appears to be the only way to pass this information to Maven.
> Maven can do a better job of prompting for, or configuring, passphrases for 
> keyStores and trustStores. It already has the ability to configure server 
> credentials in the settings.xml file, protected with a master passphrase read 
> from a different file 
> ([~/.m2/settings-security.xml|http://maven.apache.org/guides/mini/guide-encryption.html]).
>  This would work for JKS and PKCS12 keystores today, if there were a way to 
> configure the passphrases there instead of in MAVEN_OPTS.
> Another option would be to support PKCS11 keystores, configured via the 
> current JSSE system properties. However, to do this, Maven needs to 
> instantiate the SSL configuration in the http client with an AuthProvider and 
> a callback handler which prompts for the PKCS11 pin/passphrase.



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

[jira] [Updated] (MNG-5689) Checksum policy for mirrors

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs updated MNG-5689:
---
Labels: security-issue  (was: )

> Checksum policy for mirrors
> ---
>
> Key: MNG-5689
> URL: https://issues.apache.org/jira/browse/MNG-5689
> Project: Maven
>  Issue Type: Improvement
>  Components: Settings
>Affects Versions: 3.2.3
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
>
> It does not appear that there is any way to configure a checksum policy for 
> mirrors in the settings.xml file.
> In particular, I'd love to enforce a "strict" checksum policy on maven 
> central. I can configure a mirrorOf central, but I cannot set the checksum 
> policy. This seems like a big oversight.



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

[jira] [Updated] (MNG-5583) Better PKCS12 and/or PKCS11 support

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs updated MNG-5583:
---
Labels: security-issue  (was: )

> Better PKCS12 and/or PKCS11 support
> ---
>
> Key: MNG-5583
> URL: https://issues.apache.org/jira/browse/MNG-5583
> Project: Maven
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 3.1.1
> Environment: Any multi-user environment, especially Unix/Linux 
> environments.
>Reporter: Christopher Tubbs
>Priority: Major
>  Labels: security-issue
>
> Maven supports dependency resolution through HTTPS with client-authentication 
> (documented MNG-1560), via JSSE system properties on the java command-line. 
> These can be configured in the environment of the process that launches Maven 
> as 
> [MAVEN_OPTS|http://maven.apache.org/guides/mini/guide-repository-ssl.html], 
> which can be made relatively secure.
> However, eventually, when the mvn bootstrap script starts Maven's java 
> process, these options are placed on the command line for java. This is 
> extremely problematic, because it means that any JSSE properties with 
> sensitive information (javax.net.ssl.keyStorePassword, for example) are 
> visible in the process list to any user of the system. This is explicitly 
> [advised against by 
> Java|http://download.java.net/jdk8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization],
>  but appears to be the only way to pass this information to Maven.
> Maven can do a better job of prompting for, or configuring, passphrases for 
> keyStores and trustStores. It already has the ability to configure server 
> credentials in the settings.xml file, protected with a master passphrase read 
> from a different file 
> ([~/.m2/settings-security.xml|http://maven.apache.org/guides/mini/guide-encryption.html]).
>  This would work for JKS and PKCS12 keystores today, if there were a way to 
> configure the passphrases there instead of in MAVEN_OPTS.
> Another option would be to support PKCS11 keystores, configured via the 
> current JSSE system properties. However, to do this, Maven needs to 
> instantiate the SSL configuration in the http client with an AuthProvider and 
> a callback handler which prompts for the PKCS11 pin/passphrase.



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

[jira] [Comment Edited] (MNG-3328) Allow multiple profile activation properties.

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs edited comment on MNG-3328 at 2/24/18 5:31 AM:
-

This issue currently has 103 votes and 85 watchers. I wonder if this is the 
most anticipated backlogged feature of Maven for the last 10 years since it was 
initially requested? In any case, MNG-6345 could be a good alternative to the 
boolean operations that folks have suggested here.


was (Author: ctubbsii):
This issue currently has 105 votes and 85 watchers. I wonder if this is the 
most anticipated backlogged feature of Maven for the last 10 years since it was 
initially requested? In any case, MNG-6345 could be a good alternative to the 
boolean operations that folks have suggested here.

> Allow multiple profile activation properties.
> -
>
> Key: MNG-3328
> URL: https://issues.apache.org/jira/browse/MNG-3328
> Project: Maven
>  Issue Type: Improvement
>  Components: Profiles
>Affects Versions: 2.0.8
>Reporter: Paul Gier
>Priority: Major
> Fix For: 3.x / Backlog
>
>
> The pom model should be changed to allow multiple properties to activate a 
> profile.  So the profile activation section could look something like this:
> {code:xml}
> 
>   
> some-value
> another-value
>   
> 
> {code}
> This would provide more flexibility in profile activation.



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