[jira] [Commented] (ARCHETYPE-573) Version 3.1.1 generates redundant newlines in POM files
[
https://issues.apache.org/jira/browse/ARCHETYPE-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999511#comment-16999511
]
Sylwester Lachiewicz commented on ARCHETYPE-573:
[~oburgosm] could you paste command that would produce incorrect results?
> Version 3.1.1 generates redundant newlines in POM files
> ---
>
> Key: ARCHETYPE-573
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-573
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 3.1.1
> Environment: $ mvn -version
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T23:00:29+04:00)
> Maven home: /usr/local/Cellar/maven/3.6.1/libexec
> Java version: 12.0.1, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/openjdk-12.0.1.jdk/Contents/Home
> Default locale: en_AE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
>Reporter: Christian Schlichtherle
>Priority: Minor
>
> Since version 3.1.1, the {{generate}} goal inserts redundant newlines in the
> POM file. Here's a step to reproduce:
> {code:java}
> $ mvn org.apache.maven.plugins:maven-archetype-plugin:3.1.1:generate -B \
> -DarchetypeGroupId=global.namespace.truelicense-maven-archetype \
> -DarchetypeArtifactId=truelicense-maven-archetype \
> -DarchetypeVersion=4.0.0-RC1 \
> -DartifactId='basic' \
> -Dcompany='Company Inc.' \
> -DgroupId='com.company.product' \
> -Dpassword='test1234' \
> -Dsubject='Product 1' \
> -Dversion='1.0-SNAPSHOT'
> $ head basic/pom.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
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> {code}
> It's working fine with version 3.1.0, though:
> {code:java}
> $ mvn org.apache.maven.plugins:maven-archetype-plugin:3.1.0:generate -B \
> -DarchetypeGroupId=global.namespace.truelicense-maven-archetype \
> -DarchetypeArtifactId=truelicense-maven-archetype \
> -DarchetypeVersion=4.0.0-RC1 \
> -DartifactId='basic' \
> -Dcompany='Company Inc.' \
> -DgroupId='com.company.product' \
> -Dpassword='test1234' \
> -Dsubject='Product 1' \
> -Dversion='1.0-SNAPSHOT'
> $ head basic/pom.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
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> com.company.product
> basic
> 1.0-SNAPSHOT
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARCHETYPE-583) Skip parent non-archetype project when updating local catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999483#comment-16999483
]
Lukasz Lenart commented on ARCHETYPE-583:
-
Thanks a lot for looking into that!
> Skip parent non-archetype project when updating local catalog
> -
>
> Key: ARCHETYPE-583
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-583
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 3.1.2
>Reporter: Lukasz Lenart
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.1.3
>
>
> I'm working on a set of [Struts
> archetypes|https://github.com/apache/struts-archetypes/pull/3] and discovered
> that the parent non-archetype project is also added to the local catalog when
> using {{archetype:update-local-catalog}} goal.
> All the submodules are using {{maven-archetype}}
> [packaging|https://maven.apache.org/archetype/archetype-packaging/] and the
> main project is using {{pom}} packaging.
> I have prepared a PR to skip those non-archetype projects
> https://github.com/apache/maven-archetype/pull/33
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARCHETYPE-583) Skip parent non-archetype project when updating local catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated ARCHETYPE-583:
-
Fix Version/s: (was: 3.1.2)
3.1.3
> Skip parent non-archetype project when updating local catalog
> -
>
> Key: ARCHETYPE-583
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-583
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 3.1.2
>Reporter: Lukasz Lenart
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.1.3
>
>
> I'm working on a set of [Struts
> archetypes|https://github.com/apache/struts-archetypes/pull/3] and discovered
> that the parent non-archetype project is also added to the local catalog when
> using {{archetype:update-local-catalog}} goal.
> All the submodules are using {{maven-archetype}}
> [packaging|https://maven.apache.org/archetype/archetype-packaging/] and the
> main project is using {{pom}} packaging.
> I have prepared a PR to skip those non-archetype projects
> https://github.com/apache/maven-archetype/pull/33
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (ARCHETYPE-583) Skip parent non-archetype project when updating local catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed ARCHETYPE-583.
Fix Version/s: 3.1.2
Resolution: Fixed
Fixed in
[9f593b46f4519f68e16a8704a578e8cab33884db|https://gitbox.apache.org/repos/asf?p=maven-archetype.git;a=commit;h=9f593b46f4519f68e16a8704a578e8cab33884db]
Thanks for the patch!
> Skip parent non-archetype project when updating local catalog
> -
>
> Key: ARCHETYPE-583
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-583
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 3.1.2
>Reporter: Lukasz Lenart
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.1.2
>
>
> I'm working on a set of [Struts
> archetypes|https://github.com/apache/struts-archetypes/pull/3] and discovered
> that the parent non-archetype project is also added to the local catalog when
> using {{archetype:update-local-catalog}} goal.
> All the submodules are using {{maven-archetype}}
> [packaging|https://maven.apache.org/archetype/archetype-packaging/] and the
> main project is using {{pom}} packaging.
> I have prepared a PR to skip those non-archetype projects
> https://github.com/apache/maven-archetype/pull/33
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-359) plexus-java 0.9.10 causes a NullPointer in compiler-plugin 3.8.0
[
https://issues.apache.org/jira/browse/MCOMPILER-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999429#comment-16999429
]
Hudson commented on MCOMPILER-359:
--
Build succeeded in Jenkins: Maven TLP » maven-compiler-plugin » master #131
See
https://builds.apache.org/job/maven-box/job/maven-compiler-plugin/job/master/131/
> plexus-java 0.9.10 causes a NullPointer in compiler-plugin 3.8.0
>
>
> Key: MCOMPILER-359
> URL: https://issues.apache.org/jira/browse/MCOMPILER-359
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.0
> Environment: Windows 7
> JDK 10.0.2
> Maven 3.5.4
>Reporter: Marvin
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.9.0
>
> Attachments: plugintest.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If {{}} contains a {{pom}} or {{war}}
> this call:
> {{moduleDescriptor = binaryParser.getModuleDescriptor( path );}}
> throws an {{IOException}}:
> {{zip END header not found}}
> because the file is being treated as a jar file.
> When the call returns to {{CompilerMojo.preparePaths()}} this call returns
> {{null}}:
> {{Throwable cause = pathException.getValue().getCause();}}
> and the next line throws a {{NullPointerException}}:
> {{while ( cause.getCause() != null )}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MCOMPILER-377) Upgrade plexus-java to 1.0.3
[ https://issues.apache.org/jira/browse/MCOMPILER-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MCOMPILER-377. Fix Version/s: (was: 3.9.0) Resolution: Done > Upgrade plexus-java to 1.0.3 > > > Key: MCOMPILER-377 > URL: https://issues.apache.org/jira/browse/MCOMPILER-377 > Project: Maven Compiler Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.8.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MCOMPILER-359) plexus-java 0.9.10 causes a NullPointer in compiler-plugin 3.8.0
[
https://issues.apache.org/jira/browse/MCOMPILER-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-359.
Fix Version/s: 3.9.0
Assignee: Robert Scholte
Resolution: Fixed
Fixed in
[116b98153ef5ce7b13c0275324baa28bca8bc887|https://gitbox.apache.org/repos/asf?p=maven-compiler-plugin.git;a=commit;h=116b98153ef5ce7b13c0275324baa28bca8bc887]
Thanks for the patch!
> plexus-java 0.9.10 causes a NullPointer in compiler-plugin 3.8.0
>
>
> Key: MCOMPILER-359
> URL: https://issues.apache.org/jira/browse/MCOMPILER-359
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.0
> Environment: Windows 7
> JDK 10.0.2
> Maven 3.5.4
>Reporter: Marvin
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.9.0
>
> Attachments: plugintest.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If {{}} contains a {{pom}} or {{war}}
> this call:
> {{moduleDescriptor = binaryParser.getModuleDescriptor( path );}}
> throws an {{IOException}}:
> {{zip END header not found}}
> because the file is being treated as a jar file.
> When the call returns to {{CompilerMojo.preparePaths()}} this call returns
> {{null}}:
> {{Throwable cause = pathException.getValue().getCause();}}
> and the next line throws a {{NullPointerException}}:
> {{while ( cause.getCause() != null )}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999376#comment-16999376
]
Robert Scholte commented on MPLUGIN-302:
This is something that should be scheduled for Maven 5. I'm still convinced
that all dependency-resolution should be done by Maven, and not inside
configuration. However, the current architecture doesn't alow that, so it'll
require a rewrite for some parts of Maven core.
> Dependencies Annotation
> ---
>
> Key: MPLUGIN-302
> URL: https://issues.apache.org/jira/browse/MPLUGIN-302
> Project: Maven Plugin Tools
> Issue Type: New Feature
> Components: API
>Reporter: Robert Scholte
>Priority: Major
> Attachments: dependencies-annotation.patch
>
>
> The goal of this Annotation is to remove all dependencies from the plugin
> configuration and to have custom scopes so they become part of the dependency
> resolution when Maven is creating a buildplan.
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {code}
> Going further: there can be project dependencies which are not part of the
> classpath. One concrete example is the multirelease jar, where the newer
> implementation classes can be added to base jar. Current solution is to have
> a separate (distribution) Maven module which assembles the final jar, but
> with the solution above it is possible to embed them already when creating
> the base jar.
> This project would have the following dependencies:
> {code:xml}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map releaseArtifacts;
> // somewhere in the code
> foreach( Map.Entry releaseEntry : releaseArtifacts.entrySet() )
> {
> // copy content of release.value() to META-INF/versions/release.key()
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MSHARED-826) Require Java 7
[
https://issues.apache.org/jira/browse/MSHARED-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MSHARED-826.
--
Fix Version/s: maven-shared-utils-3.3.0
Resolution: Fixed
Fixed in
[ba671665b40bd088f27d7824776255d9a2f01b4e|https://gitbox.apache.org/repos/asf?p=maven-shared-utils.git;a=commit;h=ba671665b40bd088f27d7824776255d9a2f01b4e]
Thanks for the patch!
> Require Java 7
> --
>
> Key: MSHARED-826
> URL: https://issues.apache.org/jira/browse/MSHARED-826
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-shared-utils
>Reporter: Maarten Mulders
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: maven-shared-utils-3.3.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While working on
> [MSHARED-822|https://issues.apache.org/jira/browse/MSHARED-822] I noticed
> that this project still has {{maven.compiler.source}} and
> {{maven.compiler.target}} on 1.6.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MCHANGELOG-148) Warn on missing namespace
Elliotte Rusty Harold created MCHANGELOG-148: Summary: Warn on missing namespace Key: MCHANGELOG-148 URL: https://issues.apache.org/jira/browse/MCHANGELOG-148 Project: Maven Changelog Plugin Issue Type: Improvement Reporter: Elliotte Rusty Harold We allow pom.xml files with no namespace and reject pom.xml files that use prefixed local names that are correctly namespaced. As step 1 to getting to a release where we can fix this, emit a warning when we encounter a non-namespaced pom.xml such as this: 4.0.0 war 0.1.0-SNAPSHOT c.g mvn25 2.2.0 UTF-8 UTF-8 1.8 1.8 true -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-231) Multiple shade artifacts + reduced pom from the same artifact
[ https://issues.apache.org/jira/browse/MSHADE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999185#comment-16999185 ] Romain Manni-Bucau commented on MSHADE-231: --- [~elharo] MavenProjectHelper.attach ;), or "added to installed/deployed artifacts" > Multiple shade artifacts + reduced pom from the same artifact > - > > Key: MSHADE-231 > URL: https://issues.apache.org/jira/browse/MSHADE-231 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Priority: Major > > Hi guys, > in tomee we create several flavors of tomee-embedded from tomee-embedded > module. > We basically deploy: > - tomee-embedded normal jar > - tomee-embedded "uber" shade > - tomee-embedded "jaxws" shade > - tomee-embedded "jaxrs" shade > We would add few more flavors if we can solve this issue: we can't get > reduced pom and attach it to let our users depend on the reduced pom. > Best would be to: > 1- have the reduced pom created in target/ > 2- attach it to deploy it with another artifact (to avoid pom conflicts) > is that something mvn-shade could do? > Here is the pom: > https://github.com/apache/tomee/blob/master/tomee/tomee-embedded/pom.xml#L55 > Side note: the obvious fix it to define 1 pom by shade but it would make the > maintenance harder for us and create inconsistencies long term. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCHANGELOG-142) UTF-8 Encoding doubled
[
https://issues.apache.org/jira/browse/MCHANGELOG-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999159#comment-16999159
]
Elliotte Rusty Harold commented on MCHANGELOG-142:
--
should be investigated
> UTF-8 Encoding doubled
> --
>
> Key: MCHANGELOG-142
> URL: https://issues.apache.org/jira/browse/MCHANGELOG-142
> Project: Maven Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Jukka Harkki
>Priority: Major
> Labels: sample-project-missing
>
> Creating changelog.xml file doubles UTF-8 encoding if the git comment
> information is already UTF-8 format. For example: if property outputEncoding
> is set to ISO-8859-1 the output is (shown as od dump):
> {code}
> 0004060 7375 7420 696f 696d 616d 6e61 6d20 c379
> u s t o i m i m a a n m y ├
> 0004100 73b6 6c20 7369 a4c3 6b79 6573 7373 a4c3
> Â s l i s ├ ñ y k s e s s ├ ñ
> {code}
> And when set to UTF-8 the output is:
> {code}
> 0004060 6d69 6d69 6161 206e 796d 83c3 b6c2 2073
> i m i m a a n m y ├ â ┬ Â s
> {code}
> The result of UTF-8 encoding is that scandinavian umlauts are garbled. Code
> C3 B6 is the right for the "ö"-letter.
> The ISO-8859-1 format would do for the site documentation but since the file
> changelog.xml header says ISO-8859-1 encoding, rest of the process fails to
> process umlauts.
> I modified class ChangeLogReport method writeChangelogXml() by commenting out
> issue MCHANGELOG-86 writer change:
> {code}
> PrintWriter pw = new PrintWriter(new BufferedOutputStream(new
> FileOutputStream(outputXML)));
> pw.write(changelogXml.toString());
> pw.flush();
> pw.close();
> // MCHANGELOG-86
> //Writer writer = WriterFactory.newWriter( new BufferedOutputStream(
> new FileOutputStream( outputXML ) ),
> // getOutputEncoding() );
> //writer.write(changelogXml.toString());
> //writer.flush();
> //writer.close();
> {code}
> It might be there is double escaping in Writer since couple of lines above
> the change set is created with encoding information:
> {code}
> String changeset = changelogSet.toXML(getOutputEncoding());
> {code}
> However, this is just a wild guess since I did not check out implementation
> of changelogSet.toXML() or writer.write(). It could be also something
> different in version control access since MCHANGELOG-86 was a SVN issue and
> here we got with GIT.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MCHANGELOG-141) Failure to generate changelog.xml with mercurial - need to upgrade to 1.9.4 version of Maven SCM
[ https://issues.apache.org/jira/browse/MCHANGELOG-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MCHANGELOG-141. > Failure to generate changelog.xml with mercurial - need to upgrade to 1.9.4 > version of Maven SCM > > > Key: MCHANGELOG-141 > URL: https://issues.apache.org/jira/browse/MCHANGELOG-141 > Project: Maven Changelog Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: RHEL 6.5, mercurial >Reporter: James MacNider >Priority: Major > Fix For: 2.4.0 > > > I've found that the maven-changelog-plugin will fail to generate a tag-based > changelog.xml file when the SCM is mercurial. This is actually a bug in the > 1.8 version of the maven-scm-plugin. > My testing with a custom (built by me) version of maven-changelog-plugin that > depends on version 1.9.4 of maven-scm-plugin worked fine. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MCHANGELOG-141) Failure to generate changelog.xml with mercurial - need to upgrade to 1.9.4 version of Maven SCM
[ https://issues.apache.org/jira/browse/MCHANGELOG-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MCHANGELOG-141. -- Resolution: Fixed sounds like this one is now fixed > Failure to generate changelog.xml with mercurial - need to upgrade to 1.9.4 > version of Maven SCM > > > Key: MCHANGELOG-141 > URL: https://issues.apache.org/jira/browse/MCHANGELOG-141 > Project: Maven Changelog Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: RHEL 6.5, mercurial >Reporter: James MacNider >Priority: Major > Fix For: 2.4.0 > > > I've found that the maven-changelog-plugin will fail to generate a tag-based > changelog.xml file when the SCM is mercurial. This is actually a bug in the > 1.8 version of the maven-scm-plugin. > My testing with a custom (built by me) version of maven-changelog-plugin that > depends on version 1.9.4 of maven-scm-plugin worked fine. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MGPG-57) passphraseServerId is ignored if a server with id gpg.passphrase exists
[
https://issues.apache.org/jira/browse/MGPG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999155#comment-16999155
]
Elliotte Rusty Harold commented on MGPG-57:
---
Possible user error?
> passphraseServerId is ignored if a server with id gpg.passphrase exists
> ---
>
> Key: MGPG-57
> URL: https://issues.apache.org/jira/browse/MGPG-57
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 1.6
> Environment: Linux, maven 3.2.5
>Reporter: Angelo D.
>Priority: Minor
>
> I have multiple GPG keys in my keyring and I'd like to select a specific one
> for signing. Each key has a different passphrase, stored encrypted in my
> local settings.xml file.
> {code:xml}
>
> gpg.passphrase
> ...
>
>
> my.signing.key
> ...
>
> {code}
> My gpg configuration in the project's pom.xml file hase
> {code:xml}
> ...
>
> my.signing.key
> my.signing.key
>
> ...
> {code}
> If I try to sign my artifacts with this configuration I get an error
> {noformat}
> [INFO] --- maven-gpg-plugin:1.6:sign (default-cli) @ client ---
> gpg: skipped "my.key": bad passphrase
> gpg: signing failed: bad passphrase
> {noformat}
> If I remove the {{gpg.passphrase}} server from the settings everything works
> fine.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MGPG-45) ascDirectory has no effect unless artifacts are not in target
[
https://issues.apache.org/jira/browse/MGPG-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999149#comment-16999149
]
Elliotte Rusty Harold commented on MGPG-45:
---
seems worth investigating
> ascDirectory has no effect unless artifacts are not in target
> -
>
> Key: MGPG-45
> URL: https://issues.apache.org/jira/browse/MGPG-45
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Sebb
>Priority: Major
>
> Not sure if this is a documentation or code bug or both.
> The doc for gpg:sign / ascDirectory says:
> {code}
> The directory where to store signature files.
> Default: ${project.build.directory}/gpg
> {code}
> However changing this has no effect unless the artifacts are moved elsewhere
> than target (by changing assembly:outputDirectory).
> If outputDirectory is set to target/tarballs then the sig files are actually
> stored in target/gpg/target/tarballs for the default setting, rather than in
> the expected directory of target/gpg
> If ascDirectory is set to ASC then the sigs are stored in
> ASC/target/tarballs/ rather than ASC.
> If ascDirectory is set to "." then the sigs are stored in
> target/tarballs/ rather than the home directory.
> There does not seem to be any use-case for this behaviour, and if there is,
> it's not documented correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MGPG-43) Allow signing of arbitrary artifacts
[ https://issues.apache.org/jira/browse/MGPG-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MGPG-43. - > Allow signing of arbitrary artifacts > > > Key: MGPG-43 > URL: https://issues.apache.org/jira/browse/MGPG-43 > Project: Maven GPG Plugin > Issue Type: New Feature >Reporter: Sebb >Priority: Major > Attachments: MGPG-43.patch, MGPG43-2.patch, MGPG43-3.patch, > MGPG43.patch > > > At present, the plugin relies on being run after the "package" phase, > presumably so it knows which files to sign. > This is fine if all the artifacts are intended for distribution via Maven > repos, but there are other distribution mechanisms where signed artifacts are > needed. For example, ASF releases to their mirror system. > It would be useful if there was a separate goal for signing files using > standard includes/excludes. > Ideally this would also be integrated with the assembly plugin somehow so it > could obtain the list of files from the plugin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MGPG-43) Allow signing of arbitrary artifacts
[ https://issues.apache.org/jira/browse/MGPG-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MGPG-43. --- Resolution: Won't Fix Since there's no activity here and this issue is scheduled for autoclosure anyway, I'm going to make an opinionated call that this is out of scope for the GPG plugin. Signing arbitrary files should be done with gpg itself, not a Maven plugin. If anyone wants to pick it up again, feel free to reopen. > Allow signing of arbitrary artifacts > > > Key: MGPG-43 > URL: https://issues.apache.org/jira/browse/MGPG-43 > Project: Maven GPG Plugin > Issue Type: New Feature >Reporter: Sebb >Priority: Major > Attachments: MGPG-43.patch, MGPG43-2.patch, MGPG43-3.patch, > MGPG43.patch > > > At present, the plugin relies on being run after the "package" phase, > presumably so it knows which files to sign. > This is fine if all the artifacts are intended for distribution via Maven > repos, but there are other distribution mechanisms where signed artifacts are > needed. For example, ASF releases to their mirror system. > It would be useful if there was a separate goal for signing files using > standard includes/excludes. > Ideally this would also be integrated with the assembly plugin somehow so it > could obtain the list of files from the plugin. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999143#comment-16999143
]
Elliotte Rusty Harold commented on MPLUGIN-302:
---
scheduled for autoclose. Does anyone want to work on this, or should we resolve
that we're not going to do this?
> Dependencies Annotation
> ---
>
> Key: MPLUGIN-302
> URL: https://issues.apache.org/jira/browse/MPLUGIN-302
> Project: Maven Plugin Tools
> Issue Type: New Feature
> Components: API
>Reporter: Robert Scholte
>Priority: Major
> Attachments: dependencies-annotation.patch
>
>
> The goal of this Annotation is to remove all dependencies from the plugin
> configuration and to have custom scopes so they become part of the dependency
> resolution when Maven is creating a buildplan.
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {code}
> Going further: there can be project dependencies which are not part of the
> classpath. One concrete example is the multirelease jar, where the newer
> implementation classes can be added to base jar. Current solution is to have
> a separate (distribution) Maven module which assembles the final jar, but
> with the solution above it is possible to embed them already when creating
> the base jar.
> This project would have the following dependencies:
> {code:xml}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map releaseArtifacts;
> // somewhere in the code
> foreach( Map.Entry releaseEntry : releaseArtifacts.entrySet() )
> {
> // copy content of release.value() to META-INF/versions/release.key()
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-206) Multi-module builds don't pick up dependency-reduced-pom.xml
[ https://issues.apache.org/jira/browse/MSHADE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999141#comment-16999141 ] Francois MAROT commented on MSHADE-206: --- Hello [~elharo] , as a simple Maven user but following closely what happens in Maven world and using the shade plugin, I can tell you this is still an issue and not resolved. If you use the shade plugin, the module using the shade plugin has to be the LAST one in your Maven execution. Meaning that no module in your multi-module should depend on the shade jar or otherwise you will not get what you expect to get regarding dependencies. You have to split your build in two phase where the first installs (or deploys) the shaded jar. > Multi-module builds don't pick up dependency-reduced-pom.xml > > > Key: MSHADE-206 > URL: https://issues.apache.org/jira/browse/MSHADE-206 > Project: Maven Shade Plugin > Issue Type: Bug >Reporter: Robert Joseph Evans >Priority: Major > > I'm not sure if there is a good solution for this or not. As part of the > Apache Storm project we are trying to shade a lot of dependencies for the > core platform (storm-core), but we also have other modules in the same build > that depend on storm-core, but use the shade plugin to create an uber jar for > deployment. The problem is that if we build all of the modules at once and > let maven handle resolving dependencies the uber jar projects don't see > storm-core's dependency-reduced-pom.xml. They see the original pom.xml and > end up not packaging dependencies that they need. > Our "fix" for this https://github.com/apache/storm/pull/736 is to split the > build up into two phases. One that just builds storm-core and another that > builds the rest. This is going to be a real pain for developers. Are we > doing something wrong? Is this working as expected? > I am happy to submit a fix for this, but I am far from an expert on maven so > if someone in this project sees a direction that I can go in to fix this I > would appreciate any guidance you might have. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MENFORCER-252) DependencyConvergence rule doesn't account dependencyManagement section correctly
[
https://issues.apache.org/jira/browse/MENFORCER-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999140#comment-16999140
]
Elliotte Rusty Harold commented on MENFORCER-252:
-
sounds like a bug, and if it's still happening--is it?--it should be fixed
unconditionally. There shouldn't be a configuration option for this.
> DependencyConvergence rule doesn't account dependencyManagement section
> correctly
> -
>
> Key: MENFORCER-252
> URL: https://issues.apache.org/jira/browse/MENFORCER-252
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.4.1
>Reporter: Dmitry Spikhalskiy
>Priority: Major
> Labels: dependency-tree
>
> DependencyConvergence doesn't catch dependencyManagement section of
> dependency correctly.
> Specific example:
> We have module that depends on async-http-client:
> {code:xml}
>
> org.asynchttpclient
> async-http-client
> 2.0.3
>
> {code}
> From dependencyConvergence rule we get
> {noformat}
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence
> failed with message:
> Failed while enforcing releasability the error(s) are [
> Dependency convergence error for io.netty:netty-handler:4.0.36.Final paths to
> dependency are:
> +-our_artifact
> +-org.asynchttpclient:async-http-client:2.0.3
> +-io.netty:netty-codec-http:4.0.36.Final
> +-io.netty:netty-handler:4.0.36.Final
> and
> +-our_artifact
> +-org.asynchttpclient:async-http-client:2.0.3
> +-com.typesafe.netty:netty-reactive-streams:1.0.4
> +-io.netty:netty-handler:4.0.34.Final
> {noformat}
> While, actually, dependencyManagement section of async-http-client specifies
> and enforce netty-handler:4.0.36.Final and it's dependency tree doesn't
> contain netty-handler:4.0.34.Final
> So... if it's not a bug, it should be a way to ignore such cases of
> explicitly resolved conflicts in external artifact maybe.
> Current fix for this is
> {code:xml}
>
> org.asynchttpclient
> async-http-client
>
>
> io.netty
> netty-handler
>
>
>
>
> io.netty
> netty-handler
> 4.0.36.Final
>
> {code}
> But it's stupid, because netty-handler already contains only
> netty-handler:4.0.36.Final
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MGPG-54) Add check for use of weak private keys before signing
[
https://issues.apache.org/jira/browse/MGPG-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MGPG-54.
---
Resolution: Won't Fix
Since there's no activity here and this issue is scheduled for autoclosure
anyway, I'm going to make an opinionated call that we shouldn't fix this. The
GPG plugin should support what GPG supports, no more, no less.
If anyone disagrees, feel free to reopen.
> Add check for use of weak private keys before signing
> -
>
> Key: MGPG-54
> URL: https://issues.apache.org/jira/browse/MGPG-54
> Project: Maven GPG Plugin
> Issue Type: New Feature
>Reporter: Christopher Tubbs
>Priority: Minor
>
> I just filed MPOM-118, and was thinking that signatures on releases are also
> weakened by the use of weaker private keys.
> It may be possible for the plugin to validate the key to be used prior to
> signing, and to fail if the key is weaker than 4096-bit RSA (the current
> recommended minimum).
> You can see a similar check in this bash scriptlet:
> {code}
> # get default key, if it exists
> KEY=$(gpgconf --list-options gpg | awk -F: '$1 == "default-key" {print $10}'
> | cut -c2-)
> # get first secret key if default isn't set
> [[ -n $KEY ]] || KEY=$(gpg --with-colons --list-secret-key | grep ^sec | head
> -1 | cut -f5 -d:)
> # get bits from first RSA signing (sub)key
> BITS=$(gpg --with-colons --list-secret-key $KEY | grep
> -E'^(sec|ssb)(:[^:]*){2}:1(:[^:]*){7}:[^:]*s' | head -1 | cut -f3 -d:)
> # verify bits are at least 4096
> (( $BITS >= 4096 )) || exit 1
> {code}
> {{--with-colons}} provides backwards-compatible machine-parseable output
> predictably. Specifying the $KEY is optional. Unfortunately, the "usage"
> codes (field 12) to find the signing key/subkey (code "s") aren't displayed
> if you don't specify $KEY on the command line. So, we need to figure out the
> one the gpg command will select, and ask about it explicitly.
> GPG's selection method is to use the default key specified in the gpg
> configuration first. If that isn't set, it just uses the first secret key it
> finds. There's no better way to figure out which key this is other than to
> parse the config file. {{gpgconf}} command can help with that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-826) Require Java 7
[
https://issues.apache.org/jira/browse/MSHARED-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999110#comment-16999110
]
Maarten Mulders commented on MSHARED-826:
-
I think this one can be closed. Maven Shared Utils is on Java 7 now.
> Require Java 7
> --
>
> Key: MSHARED-826
> URL: https://issues.apache.org/jira/browse/MSHARED-826
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-shared-utils
>Reporter: Maarten Mulders
>Assignee: Robert Scholte
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While working on
> [MSHARED-822|https://issues.apache.org/jira/browse/MSHARED-822] I noticed
> that this project still has {{maven.compiler.source}} and
> {{maven.compiler.target}} on 1.6.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MWAR-220) dependencyManagement && overlay + transitive dependency = multiple versions of same dependency in WEB-INF/lib
[ https://issues.apache.org/jira/browse/MWAR-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999108#comment-16999108 ] Elliotte Rusty Harold commented on MWAR-220: probably still an issue > dependencyManagement && overlay + transitive dependency = multiple versions > of same dependency in WEB-INF/lib > - > > Key: MWAR-220 > URL: https://issues.apache.org/jira/browse/MWAR-220 > Project: Maven WAR Plugin > Issue Type: Bug > Components: overlay > Environment: Reproduced this on: 2.0.11, 2.1.0, 2.2.1, 3.0-alpha-7 >Reporter: jieryn >Priority: Major > Attachments: pom.xml > > > With dependencyManagement section defined I get multiple versions of spring > libraries in target/cas-*/WEB-INF/lib after mvn package. If I remove the > dependencyManagement section then only one version of the spring libraries > are found. > There seems to be a problem with m-war-p and overlays and > dependencyManagement not using the maven GAV resolver in a proper way.. I > attached a simple pom which exhibits the problem, just run mvn package to > verify. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MWAR-260) Patch to provide new war-overlay type
[ https://issues.apache.org/jira/browse/MWAR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MWAR-260: --- Description: There are a number of bugs raised around support for WAR overlays: MWAR-73 - war overlay mechanism does not work for classes MWAR-253 - Inherit dependencies from a WAR type dependency when it is overlayed. MWAR-194 - Warn when inconsistent jar versions are detected during overlay MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple versions of same dependency in WEB-INF/lib MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as dependencies MWAR-360 Most of these relate to the fact that overlays are not treated as normal maven dependencies. The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay introduces a new packaging type of "war-overlay", that works in the following way: - The primary artifact is a jar containing the classes from the overlay - Another artifact is attached containing the web content - A dependency on a war-overlay will automatically pull both artifacts into the packaged war To use the new type all you need to do is declare true on the maven-war-plugin. There is an integration test example here: https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. If someone could review the code I could create a patch and update the site documentation. was: There are a number of bugs raised around support for WAR overlays: MWAR-73 - war overlay mechanism does not work for classes MWAR-253 - Inherit dependencies from a WAR type dependency when it is overlayed. MWAR-194 - Warn when inconsistent jar versions are detected during overlay MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple versions of same dependency in WEB-INF/lib MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as dependencies Most of these relate to the fact that overlays are not treated as normal maven dependencies. The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay introduces a new packaging type of "war-overlay", that works in the following way: - The primary artifact is a jar containing the classes from the overlay - Another artifact is attached containing the web content - A dependency on a war-overlay will automatically pull both artifacts into the packaged war To use the new type all you need to do is declare true on the maven-war-plugin. There is an integration test example here: https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. If someone could review the code I could create a patch and update the site documentation. > Patch to provide new war-overlay type > - > > Key: MWAR-260 > URL: https://issues.apache.org/jira/browse/MWAR-260 > Project: Maven WAR Plugin > Issue Type: Improvement > Components: overlay >Affects Versions: 2.1.1 >Reporter: Alex Clarke >Priority: Major > Attachments: MWAR-260-example.zip > > > There are a number of bugs raised around support for WAR overlays: > MWAR-73 - war overlay mechanism does not work for classes > MWAR-253 - Inherit dependencies from a WAR type dependency when it is > overlayed. > MWAR-194 - Warn when inconsistent jar versions are detected during overlay > MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple > versions of same dependency in WEB-INF/lib > MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as > dependencies > MWAR-360 > Most of these relate to the fact that overlays are not treated as normal > maven dependencies. > The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay > introduces a new packaging type of "war-overlay", that works in the following > way: > - The primary artifact is a jar containing the classes from the overlay > - Another artifact is attached containing the web content > - A dependency on a war-overlay will automatically pull both artifacts > into the packaged war > To use the new type all you need to do is declare > true on the maven-war-plugin. There is an > integration test example here: > https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. > > If someone could review the code I could create a patch and update the site > documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MWAR-260) Patch to provide new war-overlay type
[ https://issues.apache.org/jira/browse/MWAR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MWAR-260: --- Description: There are a number of bugs raised around support for WAR overlays: MWAR-73 - war overlay mechanism does not work for classes MWAR-253 - Inherit dependencies from a WAR type dependency when it is overlayed. MWAR-194 - Warn when inconsistent jar versions are detected during overlay MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple versions of same dependency in WEB-INF/lib MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as dependencies MWAR-360 - Overlay: ignore WAR which is transitively dependent over JAR Most of these relate to the fact that overlays are not treated as normal maven dependencies. The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay introduces a new packaging type of "war-overlay", that works in the following way: - The primary artifact is a jar containing the classes from the overlay - Another artifact is attached containing the web content - A dependency on a war-overlay will automatically pull both artifacts into the packaged war To use the new type all you need to do is declare true on the maven-war-plugin. There is an integration test example here: https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. If someone could review the code I could create a patch and update the site documentation. was: There are a number of bugs raised around support for WAR overlays: MWAR-73 - war overlay mechanism does not work for classes MWAR-253 - Inherit dependencies from a WAR type dependency when it is overlayed. MWAR-194 - Warn when inconsistent jar versions are detected during overlay MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple versions of same dependency in WEB-INF/lib MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as dependencies MWAR-360 Most of these relate to the fact that overlays are not treated as normal maven dependencies. The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay introduces a new packaging type of "war-overlay", that works in the following way: - The primary artifact is a jar containing the classes from the overlay - Another artifact is attached containing the web content - A dependency on a war-overlay will automatically pull both artifacts into the packaged war To use the new type all you need to do is declare true on the maven-war-plugin. There is an integration test example here: https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. If someone could review the code I could create a patch and update the site documentation. > Patch to provide new war-overlay type > - > > Key: MWAR-260 > URL: https://issues.apache.org/jira/browse/MWAR-260 > Project: Maven WAR Plugin > Issue Type: Improvement > Components: overlay >Affects Versions: 2.1.1 >Reporter: Alex Clarke >Priority: Major > Attachments: MWAR-260-example.zip > > > There are a number of bugs raised around support for WAR overlays: > MWAR-73 - war overlay mechanism does not work for classes > MWAR-253 - Inherit dependencies from a WAR type dependency when it is > overlayed. > MWAR-194 - Warn when inconsistent jar versions are detected during overlay > MWAR-220 - dependencyManagement && overlay + transitive dependency = multiple > versions of same dependency in WEB-INF/lib > MWAR-33 - jars with differents versions can be in WEB-INF/lib with war as > dependencies > MWAR-360 - Overlay: ignore WAR which is transitively dependent over JAR > Most of these relate to the fact that overlays are not treated as normal > maven dependencies. > The code in https://github.com/SciSysUK/maven-plugins/tree/waroverlay > introduces a new packaging type of "war-overlay", that works in the following > way: > - The primary artifact is a jar containing the classes from the overlay > - Another artifact is attached containing the web content > - A dependency on a war-overlay will automatically pull both artifacts > into the packaged war > To use the new type all you need to do is declare > true on the maven-war-plugin. There is an > integration test example here: > https://github.com/SciSysUK/maven-plugins/tree/waroverlay/maven-war-plugin/src/it/war-overlay. > > If someone could review the code I could create a patch and update the site > documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MWAR-360) Overlay: ignore WAR which is transitively dependent over JAR
[
https://issues.apache.org/jira/browse/MWAR-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999105#comment-16999105
]
Elliotte Rusty Harold commented on MWAR-360:
If this makes sense, it should be unconditionally, not as a configuration
option.
> Overlay: ignore WAR which is transitively dependent over JAR
>
>
> Key: MWAR-360
> URL: https://issues.apache.org/jira/browse/MWAR-360
> Project: Maven WAR Plugin
> Issue Type: Improvement
>Reporter: Michal Domagala
>Priority: Minor
>
> Example:
> I have WAR project 'Base' with class A.
> I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B
> extends A.
> Then 'Base' must have true
> Finally, I have WAR project 'Level2' with class C extends B. For the same
> reason 'Level1' must have true
> Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because
> Level1 contains Base
> Actual: Level1 and Base are overlayed together. That wastes time.
> {noformat}
> [INFO] Copying webapp resources [mwar/Level2/src/main/webapp]
> [INFO] Processing overlay [ id mwar:Level1]
> [INFO] Processing overlay [ id Base:Base]
> [INFO] Webapp assembled in [26 msecs]
> {noformat}
> Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is
> "fake"
> {noformat}
> [INFO] mwar:Level2:war:0.0.1-SNAPSHOT
> [INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile
> [INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile
> [INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile
> [INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile
> {noformat}
> Proposed solution: There should be option 'notOverlayTransitiveWar' which
> allow exclude WARs like 'Base' from overlaying, because the transitive WAR
> may be reached only over JAR and I think there is no reason any JAR really
> depends on WAR.
> Workaround is manually define ovelays in plugin configuration, but Maven
> spirit is Convention over Configuration
> h2. example
> # git clone https://github.com/michaldo/mwar360.git
> # cd mwar360
> # mvn package
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MWAR-358) Check if we need more support for web.xml entries
[ https://issues.apache.org/jira/browse/MWAR-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MWAR-358. -- > Check if we need more support for web.xml entries > - > > Key: MWAR-358 > URL: https://issues.apache.org/jira/browse/MWAR-358 > Project: Maven WAR Plugin > Issue Type: Improvement >Reporter: Karl Heinz Marbaise >Priority: Minor > > https://docs.oracle.com/cd/E13222_01/wls/docs92/webapp/configureservlet.html ? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MWAR-358) Check if we need more support for web.xml entries
[ https://issues.apache.org/jira/browse/MWAR-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MWAR-358. Resolution: Not A Problem I don't think we do. > Check if we need more support for web.xml entries > - > > Key: MWAR-358 > URL: https://issues.apache.org/jira/browse/MWAR-358 > Project: Maven WAR Plugin > Issue Type: Improvement >Reporter: Karl Heinz Marbaise >Priority: Minor > > https://docs.oracle.com/cd/E13222_01/wls/docs92/webapp/configureservlet.html ? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-231) Multiple shade artifacts + reduced pom from the same artifact
[ https://issues.apache.org/jira/browse/MSHADE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999103#comment-16999103 ] Elliotte Rusty Harold commented on MSHADE-231: -- What do you mean by "attach" in this context? > Multiple shade artifacts + reduced pom from the same artifact > - > > Key: MSHADE-231 > URL: https://issues.apache.org/jira/browse/MSHADE-231 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Priority: Major > > Hi guys, > in tomee we create several flavors of tomee-embedded from tomee-embedded > module. > We basically deploy: > - tomee-embedded normal jar > - tomee-embedded "uber" shade > - tomee-embedded "jaxws" shade > - tomee-embedded "jaxrs" shade > We would add few more flavors if we can solve this issue: we can't get > reduced pom and attach it to let our users depend on the reduced pom. > Best would be to: > 1- have the reduced pom created in target/ > 2- attach it to deploy it with another artifact (to avoid pom conflicts) > is that something mvn-shade could do? > Here is the pom: > https://github.com/apache/tomee/blob/master/tomee/tomee-embedded/pom.xml#L55 > Side note: the obvious fix it to define 1 pom by shade but it would make the > maintenance harder for us and create inconsistencies long term. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHADE-230) Cannot specify custom manifest file in a shaded jar.
[ https://issues.apache.org/jira/browse/MSHADE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSHADE-230: - Priority: Minor (was: Major) > Cannot specify custom manifest file in a shaded jar. > > > Key: MSHADE-230 > URL: https://issues.apache.org/jira/browse/MSHADE-230 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 2.4.3 >Reporter: BlakeTNC >Priority: Minor > > When a project uses the maven-jar-plugin, it's easy to include a custom (hand > written) manifest file in the jar, but I can't find a way to do the same > thing with maven shade. How can I use my own manifest file while using the > "maven-shade-plugin"? > Basic details: > My custom manifest file is located in > "src/main/resources/META-INF/MANIFEST.MF". Shade is not including my file, > instead it is being replaced in the final jar with a default manifest file. > The reason I need a custom manifest file is to specify some JavaBeans classes > in my manifest, for a swing component library. Multiple JavaBeans classes > should be specified in the manifest file in the following format, as > described here: > http://www.ewebprogrammer.com/java-beans/module3/javabeans-manifest-file.jsp > (Note that the order of these lines is important, as well as the empty lines > between them. The ManifestResourceTransformer could add the lines, but they > get added out of order and without the empty lines.) > Name: SomeBean1.class > Java-Bean: True > Name: SomeBean2.class > Java-Bean: True > Name: SomeBean3.class > Java-Bean: True > The POM file for this project is long, so I won't paste the whole thing here. > However, the current full POM for this project can be seen on github at this > link: > https://github.com/LGoodDatePicker/LGoodDatePicker/blob/master/Project/pom.xml > See the list of (unsuccessful) solutions I have tried (and additional > details), which are located here. > http://stackoverflow.com/questions/38243222/how-can-i-specify-a-custom-manifest-mf-file-while-using-the-maven-shade-plugin > Thank you. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHADE-230) Cannot specify custom manifest file in a shaded jar.
[ https://issues.apache.org/jira/browse/MSHADE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSHADE-230: - Issue Type: New Feature (was: Bug) > Cannot specify custom manifest file in a shaded jar. > > > Key: MSHADE-230 > URL: https://issues.apache.org/jira/browse/MSHADE-230 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 2.4.3 >Reporter: BlakeTNC >Priority: Major > > When a project uses the maven-jar-plugin, it's easy to include a custom (hand > written) manifest file in the jar, but I can't find a way to do the same > thing with maven shade. How can I use my own manifest file while using the > "maven-shade-plugin"? > Basic details: > My custom manifest file is located in > "src/main/resources/META-INF/MANIFEST.MF". Shade is not including my file, > instead it is being replaced in the final jar with a default manifest file. > The reason I need a custom manifest file is to specify some JavaBeans classes > in my manifest, for a swing component library. Multiple JavaBeans classes > should be specified in the manifest file in the following format, as > described here: > http://www.ewebprogrammer.com/java-beans/module3/javabeans-manifest-file.jsp > (Note that the order of these lines is important, as well as the empty lines > between them. The ManifestResourceTransformer could add the lines, but they > get added out of order and without the empty lines.) > Name: SomeBean1.class > Java-Bean: True > Name: SomeBean2.class > Java-Bean: True > Name: SomeBean3.class > Java-Bean: True > The POM file for this project is long, so I won't paste the whole thing here. > However, the current full POM for this project can be seen on github at this > link: > https://github.com/LGoodDatePicker/LGoodDatePicker/blob/master/Project/pom.xml > See the list of (unsuccessful) solutions I have tried (and additional > details), which are located here. > http://stackoverflow.com/questions/38243222/how-can-i-specify-a-custom-manifest-mf-file-while-using-the-maven-shade-plugin > Thank you. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHADE-220) Shade test-scoped dependencies of test jars
[ https://issues.apache.org/jira/browse/MSHADE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHADE-220. > Shade test-scoped dependencies of test jars > --- > > Key: MSHADE-220 > URL: https://issues.apache.org/jira/browse/MSHADE-220 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.3 >Reporter: Joel Friedly >Priority: Major > > I have a trivial smoketest project that creates a shaded executable jar so > that I can just copy my smoketest jar to any host and run it. My smoketest > project doesn't actually contain the test cases though, it just depends on > the test jar produced by our main integration testing submodule. Shade will > shade in the compile-scoped dependencies of this test jar, but not the > test-scoped dependencies of this test jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MSHADE-220) Shade test-scoped dependencies of test jars
[ https://issues.apache.org/jira/browse/MSHADE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHADE-220. -- Resolution: Won't Fix Per last comment, this is WAI > Shade test-scoped dependencies of test jars > --- > > Key: MSHADE-220 > URL: https://issues.apache.org/jira/browse/MSHADE-220 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.3 >Reporter: Joel Friedly >Priority: Major > > I have a trivial smoketest project that creates a shaded executable jar so > that I can just copy my smoketest jar to any host and run it. My smoketest > project doesn't actually contain the test cases though, it just depends on > the test jar produced by our main integration testing submodule. Shade will > shade in the compile-scoped dependencies of this test jar, but not the > test-scoped dependencies of this test jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-206) Multi-module builds don't pick up dependency-reduced-pom.xml
[ https://issues.apache.org/jira/browse/MSHADE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999099#comment-16999099 ] Elliotte Rusty Harold commented on MSHADE-206: -- still an issue? > Multi-module builds don't pick up dependency-reduced-pom.xml > > > Key: MSHADE-206 > URL: https://issues.apache.org/jira/browse/MSHADE-206 > Project: Maven Shade Plugin > Issue Type: Bug >Reporter: Robert Joseph Evans >Priority: Major > > I'm not sure if there is a good solution for this or not. As part of the > Apache Storm project we are trying to shade a lot of dependencies for the > core platform (storm-core), but we also have other modules in the same build > that depend on storm-core, but use the shade plugin to create an uber jar for > deployment. The problem is that if we build all of the modules at once and > let maven handle resolving dependencies the uber jar projects don't see > storm-core's dependency-reduced-pom.xml. They see the original pom.xml and > end up not packaging dependencies that they need. > Our "fix" for this https://github.com/apache/storm/pull/736 is to split the > build up into two phases. One that just builds storm-core and another that > builds the rest. This is going to be a real pain for developers. Are we > doing something wrong? Is this working as expected? > I am happy to submit a fix for this, but I am far from an expert on maven so > if someone in this project sees a direction that I can go in to fix this I > would appreciate any guidance you might have. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-203) "shadeTestJar" option not working?
[ https://issues.apache.org/jira/browse/MSHADE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999097#comment-16999097 ] Elliotte Rusty Harold edited comment on MSHADE-203 at 12/18/19 12:05 PM: - I think this might be WAI, but I'm not sure. Can anyone say so confidently? was (Author: elharo): Can anyone say of this is WAI? > "shadeTestJar" option not working? > -- > > Key: MSHADE-203 > URL: https://issues.apache.org/jira/browse/MSHADE-203 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.1 >Reporter: Aaron Curley >Priority: Minor > > So, I'm pretty new to using the maven-shade-plugin and I'm not really that > familiar with the maven-shade-plugin's design/code; however, it appears that > the option in the maven-shade-plugin configuration does not > work correctly. > __Symtoms__ > While running "mvn package" in my project (which has set to > true), maven-shade-plugin appears to perform the "test jar shading" step > (after performing the regular jar's shade), but the "shaded" test JAR doesn't > actually include any shaded dependency files (it just includes the "original" > test jar's contents, which is essentially a "no-op"). > __Possible Diagnosis__ > I took a quick look at the release code base for v2.4.1, in particularly, the > mojo/ShadeMojo.java file. In the execute() method, at line 437, there is > method call: > processArtifactSelectors( artifacts, artifactIds, sourceArtifacts, > artifactSelector ); > This method call appears to populate the "artifacts" and "sourceArtifacts" > sets created earlier in execute() but the code noticeably does not populate > the similar "testArtifacts" set. My guess is that this is causing the > "shade" operation to skip processing any artifacts for the test jar shade > operation (since only the project-level artifact is populated in the > "testArtifacts" set at line 432). > __Possible Solution__ > (Obviously) Add an additional parameter to processArtifactSelectors() that > accepts the additional "testArtifacts" set. Then, processArtifactSelectors > could populate that set (much like it does for the "sourceArtifacts" set at > line 623). A more extensible design might be to populate a list of Set's and > supply that to processArtifactSelectors(), but there are some other > difficulties with that (under the current design). > Best wishes. Like I said, I'm pretty new to this plugin, so the above may be > incorrect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-203) "shadeTestJar" option not working?
[ https://issues.apache.org/jira/browse/MSHADE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999097#comment-16999097 ] Elliotte Rusty Harold commented on MSHADE-203: -- Can anyone say of this is WAI? > "shadeTestJar" option not working? > -- > > Key: MSHADE-203 > URL: https://issues.apache.org/jira/browse/MSHADE-203 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.1 >Reporter: Aaron Curley >Priority: Minor > > So, I'm pretty new to using the maven-shade-plugin and I'm not really that > familiar with the maven-shade-plugin's design/code; however, it appears that > the option in the maven-shade-plugin configuration does not > work correctly. > __Symtoms__ > While running "mvn package" in my project (which has set to > true), maven-shade-plugin appears to perform the "test jar shading" step > (after performing the regular jar's shade), but the "shaded" test JAR doesn't > actually include any shaded dependency files (it just includes the "original" > test jar's contents, which is essentially a "no-op"). > __Possible Diagnosis__ > I took a quick look at the release code base for v2.4.1, in particularly, the > mojo/ShadeMojo.java file. In the execute() method, at line 437, there is > method call: > processArtifactSelectors( artifacts, artifactIds, sourceArtifacts, > artifactSelector ); > This method call appears to populate the "artifacts" and "sourceArtifacts" > sets created earlier in execute() but the code noticeably does not populate > the similar "testArtifacts" set. My guess is that this is causing the > "shade" operation to skip processing any artifacts for the test jar shade > operation (since only the project-level artifact is populated in the > "testArtifacts" set at line 432). > __Possible Solution__ > (Obviously) Add an additional parameter to processArtifactSelectors() that > accepts the additional "testArtifacts" set. Then, processArtifactSelectors > could populate that set (much like it does for the "sourceArtifacts" set at > line 623). A more extensible design might be to populate a list of Set's and > supply that to processArtifactSelectors(), but there are some other > difficulties with that (under the current design). > Best wishes. Like I said, I'm pretty new to this plugin, so the above may be > incorrect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-233) IncludeResourceTransformer should (be configurable to) error if file doesn't exist.
[ https://issues.apache.org/jira/browse/MSHADE-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999095#comment-16999095 ] Elliotte Rusty Harold commented on MSHADE-233: -- Worth logging an error message unconditionally here. I don't see why this option should be configurable. > IncludeResourceTransformer should (be configurable to) error if file doesn't > exist. > --- > > Key: MSHADE-233 > URL: https://issues.apache.org/jira/browse/MSHADE-233 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.3 >Reporter: James Howe >Priority: Major > > Just spent a long time debugging why the shaded jar was missing a resource, > and it turns out I just typoed the file. > It would be much better if this wasn't a silent failure. > At least a warning should be logged, if not a full error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHADE-233) IncludeResourceTransformer should (be configurable to) error if file doesn't exist.
[ https://issues.apache.org/jira/browse/MSHADE-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MSHADE-233: - Description: Just spent a long time debugging why the shaded jar was missing a resource, and it turns out I just typoed the file. It would be much better if this wasn't a silent failure. At least a warning should be logged, if not a full error. was: Just spent a long time debugging why the shaded jar mas missing a resource, and it turns out I just typoed the file. It would be much better if this wasn't a silent failure. At least a warning should be logged, if not a full error. > IncludeResourceTransformer should (be configurable to) error if file doesn't > exist. > --- > > Key: MSHADE-233 > URL: https://issues.apache.org/jira/browse/MSHADE-233 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.4.3 >Reporter: James Howe >Priority: Major > > Just spent a long time debugging why the shaded jar was missing a resource, > and it turns out I just typoed the file. > It would be much better if this wasn't a silent failure. > At least a warning should be logged, if not a full error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHADE-95) test-scoped artifact excluded, even if it is also a transitive dep
[
https://issues.apache.org/jira/browse/MSHADE-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MSHADE-95.
---
> test-scoped artifact excluded, even if it is also a transitive dep
> --
>
> Key: MSHADE-95
> URL: https://issues.apache.org/jira/browse/MSHADE-95
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.3.2, 1.4
> Environment: (cygwin)
> Apache Maven 3.0.1 (r1038046; 2010-11-23 05:58:32-0500)
> Java version: 1.6.0_23
> Java home: C:\Program Files\Java\jdk1.6.0_23\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: Alan D. Salewski
>Priority: Major
> Labels: moreinfo
> Attachments: MSHADE-95-IT.patch
>
>
> A test-scoped artifact is excluded from the final jar, even if that artifact
> is also a transitive dependency of some other (non-test-scoped) dep.
> {noformat}
> MY_POM
> |
> |
> +-- dep A (scope: test)
> |
> |
> +-- dep B (scope: compile)
> |
> |
> +-- dep A (scope: compile)
> {noformat}
> In the above scenario, I would expect '{{dep A}}' to be included in the final
> jar, even though it's in the '{{test}}' scope in my POM. The rationale is
> that it is required for '{{dep B}}' to run; its absence will result in a
> {{java.lang.ClassNotFoundException}} at runtime.
> Behavior observed with maven-shade-plugin versions 1.3.2 and 1.4; other
> versions not tested.
> I'll put together a test case later tonight when I have more time and attach
> it here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MSHADE-95) test-scoped artifact excluded, even if it is also a transitive dep
[
https://issues.apache.org/jira/browse/MSHADE-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MSHADE-95.
-
Resolution: Won't Fix
Since this issue is scheduled for autoclosing due to inactivity anyway, I'm
going to be opinionated and say Maven should not support non-test scoped
dependencies on test scoped dependencies. The correct solution here is to fix
the scopes in the POM.
Bundling test scoped dependencies would cause far more problems for correctly
scoped products than it would cure for incorrectly scoped projects.
> test-scoped artifact excluded, even if it is also a transitive dep
> --
>
> Key: MSHADE-95
> URL: https://issues.apache.org/jira/browse/MSHADE-95
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.3.2, 1.4
> Environment: (cygwin)
> Apache Maven 3.0.1 (r1038046; 2010-11-23 05:58:32-0500)
> Java version: 1.6.0_23
> Java home: C:\Program Files\Java\jdk1.6.0_23\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "amd64" Family: "windows"
>Reporter: Alan D. Salewski
>Priority: Major
> Labels: moreinfo
> Attachments: MSHADE-95-IT.patch
>
>
> A test-scoped artifact is excluded from the final jar, even if that artifact
> is also a transitive dependency of some other (non-test-scoped) dep.
> {noformat}
> MY_POM
> |
> |
> +-- dep A (scope: test)
> |
> |
> +-- dep B (scope: compile)
> |
> |
> +-- dep A (scope: compile)
> {noformat}
> In the above scenario, I would expect '{{dep A}}' to be included in the final
> jar, even though it's in the '{{test}}' scope in my POM. The rationale is
> that it is required for '{{dep B}}' to run; its absence will result in a
> {{java.lang.ClassNotFoundException}} at runtime.
> Behavior observed with maven-shade-plugin versions 1.3.2 and 1.4; other
> versions not tested.
> I'll put together a test case later tonight when I have more time and attach
> it here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MJAR-62) Build-Jdk in Manifest.mf does not reflect which compiler version actually compiled the classes in the jar
[
https://issues.apache.org/jira/browse/MJAR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999091#comment-16999091
]
Michael Osipov commented on MJAR-62:
Partially, but we still have:
https://github.com/apache/maven-archiver/blob/master/src/main/java/org/apache/maven/archiver/MavenArchiver.java#L694-L702
> Build-Jdk in Manifest.mf does not reflect which compiler version actually
> compiled the classes in the jar
> -
>
> Key: MJAR-62
> URL: https://issues.apache.org/jira/browse/MJAR-62
> Project: Maven JAR Plugin
> Issue Type: Bug
>Reporter: Stefan Magnus Landrø
>Priority: Major
> Attachments: example-app.zip
>
>
> Manifest.mf does not reflect the version of the compiler that built the jar,
> but defaults to the version that maven runs under: Build-Jdk:
> ${java.version}.
> I believe this makes users uncertain of which compiler was actually used to
> build the classes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-196) Must not attempt to unzip unfamiliar dependency type
[ https://issues.apache.org/jira/browse/MSHADE-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999086#comment-16999086 ] Elliotte Rusty Harold commented on MSHADE-196: -- seems right > Must not attempt to unzip unfamiliar dependency type > > > Key: MSHADE-196 > URL: https://issues.apache.org/jira/browse/MSHADE-196 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Markus Karg >Priority: Major > Labels: dll > > When adding dependencies to rather unconventional package types, like "dll" > or "pdf", we noticed that the share plugin by default tries to unzip them. > This is weird, as obviously this attempt will fail in almost any case. A user > is forced to add explicit exceptions, which is tedious, error prone, and > breaks CoC. > The solution is rather obvious: The shade plugin must only unzip those > package types which it is familiar with. This namely is e. g. JAR, ZIP, BZIP, > GZIP etc. but certainly not anything unknown. > The result of this change will be a simplification of the pom.xml, and shade > plugin's behaviour will be more like a user expects it to work: Don't touch > unkown stuff! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-149) XmlAppendingTransformer not adequate for aop-ajc.xml files
[ https://issues.apache.org/jira/browse/MSHADE-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999087#comment-16999087 ] Elliotte Rusty Harold commented on MSHADE-149: -- I don;t know anything about AOP. Does this make sense? > XmlAppendingTransformer not adequate for aop-ajc.xml files > -- > > Key: MSHADE-149 > URL: https://issues.apache.org/jira/browse/MSHADE-149 > Project: Maven Shade Plugin > Issue Type: Improvement >Reporter: Pascal Pochet >Priority: Trivial > Attachments: AopAjcXmlResourceTransformer.java > > > When merging aop-ajc.xml files (== merging several AspectJ jars...), > XmlAppendingTransformer generates: > > > ...aspects of jar 1 > > > ...aspects of jar 2 > >... > > ...aspects of jar N > > > instead of > > > ...aspects of jar 1 > ...aspects of jar 2 > ...aspects of jar N > > > Solution: > add the attached transformer to the list of existing ones. > and in pom.xml: > implementation="org.apache.maven.plugins.shade.resource.AopAjcXmlResourceTransformer"> > META-INF/aop-ajc.xml > > NB > A more general solution would be to add a parameter to > XmlAppendingTransformer to specify the XML level to merge... (maybe as a > XPath expression ?) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-202) When promoteTransitiveDependencies=true, some are stripped from the dependency-reduced-pom
[
https://issues.apache.org/jira/browse/MSHADE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999084#comment-16999084
]
Elliotte Rusty Harold commented on MSHADE-202:
--
Is this still an issue?
> When promoteTransitiveDependencies=true, some are stripped from
> the dependency-reduced-pom
> ---
>
> Key: MSHADE-202
> URL: https://issues.apache.org/jira/browse/MSHADE-202
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.4.1
> Environment: Windows 7
> java 1.8
>Reporter: Andrey Stepaonv
>Priority: Major
>
> I have 2 modules. First module uses this dependencies:
>
> ch.imvs
> sdes4j
> 1.1.3
>
>
> commons-codec
> commons-codec
>
>
>
>
> commons-codec
> commons-codec
> 1.10
>
> and second module uses first module and maven-shade plugin with execution:
>
> shade-for-obfuscate
> package
>
> shade
>
>
>
>
> ${project.groupId}:firstModule
>
>
> true
>
> ${basedir}/target/dependency-reduced-pom.xml
>
>
> As a result i have reduced pom with dependencies:
>
> ch.imvs
> sdes4j
> 1.1.3
> compile
>
>
> commons-codec
> commons-codec
> 1.10
> compile
>
> But i had to get dependency with
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5966) Add bash completion to delivery
[ https://issues.apache.org/jira/browse/MNG-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999083#comment-16999083 ] Elliotte Rusty Harold commented on MNG-5966: seems useful > Add bash completion to delivery > --- > > Key: MNG-5966 > URL: https://issues.apache.org/jira/browse/MNG-5966 > Project: Maven > Issue Type: Improvement > Components: Command Line >Affects Versions: needing-scrub-3.4.0-fallout >Reporter: Karl Heinz Marbaise >Priority: Minor > > I would like to suggest to add a bash completion to our maven delivery. > I would like to suggest to use the following one: > https://github.com/juven/maven-bash-completion (which is already under Apache > License)... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MJAR-62) Build-Jdk in Manifest.mf does not reflect which compiler version actually compiled the classes in the jar
[
https://issues.apache.org/jira/browse/MJAR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999081#comment-16999081
]
Elliotte Rusty Harold commented on MJAR-62:
---
Has the work on reproducible builds mooted this one?
> Build-Jdk in Manifest.mf does not reflect which compiler version actually
> compiled the classes in the jar
> -
>
> Key: MJAR-62
> URL: https://issues.apache.org/jira/browse/MJAR-62
> Project: Maven JAR Plugin
> Issue Type: Bug
>Reporter: Stefan Magnus Landrø
>Priority: Major
> Attachments: example-app.zip
>
>
> Manifest.mf does not reflect the version of the compiler that built the jar,
> but defaults to the version that maven runs under: Build-Jdk:
> ${java.version}.
> I believe this makes users uncertain of which compiler was actually used to
> build the classes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-177) supersedes/obsoletes
[ https://issues.apache.org/jira/browse/MNG-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MNG-177. - > supersedes/obsoletes > > > Key: MNG-177 > URL: https://issues.apache.org/jira/browse/MNG-177 > Project: Maven > Issue Type: Improvement > Components: FDPFC, POM >Reporter: Brett Porter >Priority: Major > Fix For: Issues to be reviewed for 4.x > > > Ability to map superseded ids. > eg plexus-container-default supersedes plexus-container-api -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MNG-177) supersedes/obsoletes
[ https://issues.apache.org/jira/browse/MNG-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MNG-177. --- Resolution: Fixed There's no proposal here so closing favor the more complete proposal in https://issues.apache.org/jira/browse/MNG-5652 > supersedes/obsoletes > > > Key: MNG-177 > URL: https://issues.apache.org/jira/browse/MNG-177 > Project: Maven > Issue Type: Improvement > Components: FDPFC, POM >Reporter: Brett Porter >Priority: Major > Fix For: Issues to be reviewed for 4.x > > > Ability to map superseded ids. > eg plexus-container-default supersedes plexus-container-api -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5586) Deploy effective pom
[ https://issues.apache.org/jira/browse/MNG-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999073#comment-16999073 ] Elliotte Rusty Harold commented on MNG-5586: Perhaps related to flattened POMs? > Deploy effective pom > > > Key: MNG-5586 > URL: https://issues.apache.org/jira/browse/MNG-5586 > Project: Maven > Issue Type: Improvement > Components: Deployment >Reporter: nicolas de loof >Priority: Major > > When deploying pom for an artifact, maven deploys the actual file used to > build. As this one can define profiles, and build can rely on command line > properties that change actual project model, the deployed pom.xml may not > reflect the one used by maven to build the project. Also, this prevent > changes to happen in pom.xml format (wildcard exclusion for sample) without > breaking compatibility. > Maven should deploy effective pom when artifact doesn't define pom packaging -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5652) "supplies"/"provides"/"proffers" concept proposal
[
https://issues.apache.org/jira/browse/MNG-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999071#comment-16999071
]
Stephen Connolly commented on MNG-5652:
---
It is in no way obsolete.
1. Java modules are orthogonal in some ways, plus we still have lots of
duplicate artifacts
2. Maven shouldn’t be *just* JVM, and non-JVM needs will require this also
3. I have already integrated this into the PDT proposal
> "supplies"/"provides"/"proffers" concept proposal
> -
>
> Key: MNG-5652
> URL: https://issues.apache.org/jira/browse/MNG-5652
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC
>Reporter: Stephen Connolly
>Priority: Major
>
> The exact name is still undecided. Some candidate names are: "supplies",
> "provides", and "proffers"
> h2. "supplies" concept proposal
> ===
> h3. Introduction
>
> The following is a proposal for Maven in a post-modelVersion-4.0.0 era. The
> aim of this proposal is to simplify the management of dependency trees in the
> decentralised era of artifact production that we find ourselves in.
> The core issue is that different organisations can produce artifacts that may
> overlap. The easiest example is the servlet-api. If we restrict ourselves to
> version 2.5 of the servlet specification there are quite a few artifacts that
> all deliver the exact same content:
> * {{jetty:servlet-api:2.5-6.0.2}}
> * {{org.daisy.libs:servlet-api:2.5.0}}
> * {{org.mortbay.jetty:servlet-api-2.5:6.1.14}}
> * {{org.jboss.spec.javax.servlet:jboss-servlet-api_2.5_spec:1.0.1.Final}}
> * etc
> **Note:** this is a generic problem that is not restricted to the
> servlet-api, the servlet-api just provides the example that will be most
> familiar to everyone.
> So where these multiple artifacts supplying the equivalent content becomes a
> problem is when the dependency tree is being calculated. If you have two
> dependencies each declaring transitive dependencies on different artifacts
> that supply equivalent content, then you end up with two copies of the same
> JAR file in your classpath.
> In the case of the servlet-api, the hack most people use is to declare the
> servlet-api with scope `provided` thus preventing it from being transitive.
> This is, however, a hack. In a more ideal world it would be better to let the
> servlet-api be transitive and only when we get to the WAR module would we
> declare that a specific servlet-api is to be provided in the containers that
> the WAR is targets for deployment into.
> We can take a second example that does not have the luxury of a *de facto*
> hack.
> * {{javax.faces:jsf-api:2.1}}
> * {{org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec:2.1.28.Final}}
> * {{org.apache.myfaces.core:myfaces-api:2.1.13}}
> Now in the case of the JSF API, you are supposed to bundle the JSF API in
> your WAR file. So if I use three JSF component libraries, I could very well
> end up with three different but equivalent JSF API jars in my WAR file.
> Ideally what we want is some way of telling Maven that these artifacts are
> equivalent.
> Proposal
>
> Introduce the concept of "supplies" to the project model. The concept needs
> three changes to the project model:
> 1. An explicit top level construct for a project to explicitly declare
> up-front artifacts that it knows - at the time the project is being authored
> - to contain equivalent content to at least a subset of the project's
> content. Declarations could include a claim from: `subset`, `superset`,
> `disjoint` and `equivalent` with the default being `disjoint`.
> 2. An explicit sub-element of the `dependency` construct to allow consumers
> to *post-facto* declare a specific dependency as supplying equivalent content
> for other dependencies
> 3. An extension to the `dependency/excludes/exclude` construct to allow
> consumers to remove claims a dependency makes with respect to supplying
> equivalent content
> By way of illustration, here are some examples of these constructs mapped to
> a Model Version 4.0.0 like XML schema. As the post-modelVersion-4.0.0 schema
> is not yet known, this represents the best way to illustrate how the concept
> will work, but note that this proposal does not suggest a schema for this
> concept.
> h3. Example 1
> This illustrates how we would want, say, the `myfaces-api` project model to
> look.
> {code:xml}
>
> org.apache.myfaces.core
> myfaces-api
> 2.1.3
> ...
>
>
> javax.faces
> jsf-api
> [2.1,2.2)
> superset
>
>
> org.jboss.spec.javax.faces
> jboss-jsf-api_2.1_spec
> equivalent
>
>
> ...
>
> {code}
> This indicates that the {{myfaces-api}} artifact is intended to be useable as
> a drop-in replacement for either
[jira] [Resolved] (MSHADE-165) Allow collection of additional manifest sections in the shaded jar manifest
[ https://issues.apache.org/jira/browse/MSHADE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved MSHADE-165. -- Resolution: Fixed Referenced change seems to have been merged > Allow collection of additional manifest sections in the shaded jar manifest > --- > > Key: MSHADE-165 > URL: https://issues.apache.org/jira/browse/MSHADE-165 > Project: Maven Shade Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Henning Schmiedehausen >Priority: Major > > https://github.com/apache/maven-plugins/pull/18 > This change adds a flag to the ManifestResourceTransformer that will > make it collect all additional manifest sections (non-main) and add > them to the manifest of the shaded jar. > This is useful if per-jar information is stored in Manifests > (e.g. build information) and should still be present in the resulting > shaded jar. > If a section is present in one or more source jars, they are merged > into a single section (TODO: add code to choose between "replace", > "merge" or "fail"). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSHADE-165) Allow collection of additional manifest sections in the shaded jar manifest
[ https://issues.apache.org/jira/browse/MSHADE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold closed MSHADE-165. > Allow collection of additional manifest sections in the shaded jar manifest > --- > > Key: MSHADE-165 > URL: https://issues.apache.org/jira/browse/MSHADE-165 > Project: Maven Shade Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Henning Schmiedehausen >Priority: Major > > https://github.com/apache/maven-plugins/pull/18 > This change adds a flag to the ManifestResourceTransformer that will > make it collect all additional manifest sections (non-main) and add > them to the manifest of the shaded jar. > This is useful if per-jar information is stored in Manifests > (e.g. build information) and should still be present in the resulting > shaded jar. > If a section is present in one or more source jars, they are merged > into a single section (TODO: add code to choose between "replace", > "merge" or "fail"). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHADE-170) Outstanding questions about MSHADE-124
[
https://issues.apache.org/jira/browse/MSHADE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MSHADE-170:
-
Priority: Minor (was: Major)
> Outstanding questions about MSHADE-124
> --
>
> Key: MSHADE-170
> URL: https://issues.apache.org/jira/browse/MSHADE-170
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Gili
>Priority: Minor
> Fix For: backlog
>
>
> MSHADE-124 is marked as fixed but as Anthony Whitford points out:
> # If this is fixed, why does the documentation still warn about this?
> http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependencyReducedPomLocation
> # Shouldn't the default location be under project.build.directory instead of
> basedir? Then {{mvn clean}} would be more effective, and the {{Maven
> Release}} plugin wouldn't give an error saying, "Cannot prepare the release
> because you have local modifications."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-170) Outstanding questions about MSHADE-124
[
https://issues.apache.org/jira/browse/MSHADE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999068#comment-16999068
]
Elliotte Rusty Harold commented on MSHADE-170:
--
at the very least the docs are still an open issue.
> Outstanding questions about MSHADE-124
> --
>
> Key: MSHADE-170
> URL: https://issues.apache.org/jira/browse/MSHADE-170
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Gili
>Priority: Major
> Fix For: backlog
>
>
> MSHADE-124 is marked as fixed but as Anthony Whitford points out:
> # If this is fixed, why does the documentation still warn about this?
> http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependencyReducedPomLocation
> # Shouldn't the default location be under project.build.directory instead of
> basedir? Then {{mvn clean}} would be more effective, and the {{Maven
> Release}} plugin wouldn't give an error saying, "Cannot prepare the release
> because you have local modifications."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5652) "supplies"/"provides"/"proffers" concept proposal
[
https://issues.apache.org/jira/browse/MNG-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999020#comment-16999020
]
elharo commented on MNG-5652:
-
This proposal is interesting but it feels obsolete in a Java 9+ world. Would it
be OK to close it? If someone wants to work on it in the future, they'll likely
need to write a new proposal that starts with the Java Platform Module System
and other Java 9+ features.
> "supplies"/"provides"/"proffers" concept proposal
> -
>
> Key: MNG-5652
> URL: https://issues.apache.org/jira/browse/MNG-5652
> Project: Maven
> Issue Type: New Feature
> Components: FDPFC
>Reporter: Stephen Connolly
>Priority: Major
>
> The exact name is still undecided. Some candidate names are: "supplies",
> "provides", and "proffers"
> h2. "supplies" concept proposal
> ===
> h3. Introduction
>
> The following is a proposal for Maven in a post-modelVersion-4.0.0 era. The
> aim of this proposal is to simplify the management of dependency trees in the
> decentralised era of artifact production that we find ourselves in.
> The core issue is that different organisations can produce artifacts that may
> overlap. The easiest example is the servlet-api. If we restrict ourselves to
> version 2.5 of the servlet specification there are quite a few artifacts that
> all deliver the exact same content:
> * {{jetty:servlet-api:2.5-6.0.2}}
> * {{org.daisy.libs:servlet-api:2.5.0}}
> * {{org.mortbay.jetty:servlet-api-2.5:6.1.14}}
> * {{org.jboss.spec.javax.servlet:jboss-servlet-api_2.5_spec:1.0.1.Final}}
> * etc
> **Note:** this is a generic problem that is not restricted to the
> servlet-api, the servlet-api just provides the example that will be most
> familiar to everyone.
> So where these multiple artifacts supplying the equivalent content becomes a
> problem is when the dependency tree is being calculated. If you have two
> dependencies each declaring transitive dependencies on different artifacts
> that supply equivalent content, then you end up with two copies of the same
> JAR file in your classpath.
> In the case of the servlet-api, the hack most people use is to declare the
> servlet-api with scope `provided` thus preventing it from being transitive.
> This is, however, a hack. In a more ideal world it would be better to let the
> servlet-api be transitive and only when we get to the WAR module would we
> declare that a specific servlet-api is to be provided in the containers that
> the WAR is targets for deployment into.
> We can take a second example that does not have the luxury of a *de facto*
> hack.
> * {{javax.faces:jsf-api:2.1}}
> * {{org.jboss.spec.javax.faces:jboss-jsf-api_2.1_spec:2.1.28.Final}}
> * {{org.apache.myfaces.core:myfaces-api:2.1.13}}
> Now in the case of the JSF API, you are supposed to bundle the JSF API in
> your WAR file. So if I use three JSF component libraries, I could very well
> end up with three different but equivalent JSF API jars in my WAR file.
> Ideally what we want is some way of telling Maven that these artifacts are
> equivalent.
> Proposal
>
> Introduce the concept of "supplies" to the project model. The concept needs
> three changes to the project model:
> 1. An explicit top level construct for a project to explicitly declare
> up-front artifacts that it knows - at the time the project is being authored
> - to contain equivalent content to at least a subset of the project's
> content. Declarations could include a claim from: `subset`, `superset`,
> `disjoint` and `equivalent` with the default being `disjoint`.
> 2. An explicit sub-element of the `dependency` construct to allow consumers
> to *post-facto* declare a specific dependency as supplying equivalent content
> for other dependencies
> 3. An extension to the `dependency/excludes/exclude` construct to allow
> consumers to remove claims a dependency makes with respect to supplying
> equivalent content
> By way of illustration, here are some examples of these constructs mapped to
> a Model Version 4.0.0 like XML schema. As the post-modelVersion-4.0.0 schema
> is not yet known, this represents the best way to illustrate how the concept
> will work, but note that this proposal does not suggest a schema for this
> concept.
> h3. Example 1
> This illustrates how we would want, say, the `myfaces-api` project model to
> look.
> {code:xml}
>
> org.apache.myfaces.core
> myfaces-api
> 2.1.3
> ...
>
>
> javax.faces
> jsf-api
> [2.1,2.2)
> superset
>
>
> org.jboss.spec.javax.faces
> jboss-jsf-api_2.1_spec
> equivalent
>
>
> ...
>
> {code}
> This indicates that the {{myfaces-api}} artifact is intended to be useable as
> a drop-in replacement for either
[jira] [Commented] (MNG-6357) Dependency order should be nearest first
[ https://issues.apache.org/jira/browse/MNG-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999016#comment-16999016 ] elharo commented on MNG-6357: - There might be other edge cases where this matters. For instance, imagine there's a corrupt jar file somewhere in the middle of the classpath. The order could determine whether the class loader hits it and throws an exception before it resolves the class it's looking for in a different jar file. > Dependency order should be nearest first > - > > Key: MNG-6357 > URL: https://issues.apache.org/jira/browse/MNG-6357 > Project: Maven > Issue Type: Improvement >Reporter: Robert Scholte >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > In case of version conflicts, the nearest wins. However, the dependency order > is simply based on tree walking. In the rare that a transitive dependency of > the first direct dependency contains the same class as a latter direct > dependency, the code is compiled against the first one, which is odd. > It would make more sense if direct dependencies are the first ones on the > classpath, followed by the first level transitive dependencies, etc. This > will make the explanation equal to version conflict resolution: nearest wins. > I don't expect real issues due to this change, otherwise we would have had > this issue much earlier. This should become the new default order, however > there should be a system property to get the original order, just in case > somebody needs it. > > Current workaround: make the critical dependency the first direct dependency. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MJAVADOC-632) agggregate using jpms and non jar module is failing
[ https://issues.apache.org/jira/browse/MJAVADOC-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16998947#comment-16998947 ] Olivier Lamy commented on MJAVADOC-632: --- output directory must be used for war and not the final war file > agggregate using jpms and non jar module is failing > --- > > Key: MJAVADOC-632 > URL: https://issues.apache.org/jira/browse/MJAVADOC-632 > Project: Maven Javadoc Plugin > Issue Type: Improvement > Components: javadoc >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MJAVADOC-632) agggregate using jpms and non jar module is failing
Olivier Lamy created MJAVADOC-632: - Summary: agggregate using jpms and non jar module is failing Key: MJAVADOC-632 URL: https://issues.apache.org/jira/browse/MJAVADOC-632 Project: Maven Javadoc Plugin Issue Type: Improvement Components: javadoc Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 3.2.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MJAVADOC-612) UnsupportedOperationException for javadoc:aggregate with multi modules with jpms
[ https://issues.apache.org/jira/browse/MJAVADOC-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MJAVADOC-612. - Resolution: Fixed > UnsupportedOperationException for javadoc:aggregate with multi modules with > jpms > > > Key: MJAVADOC-612 > URL: https://issues.apache.org/jira/browse/MJAVADOC-612 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 3.2.0 > > > Currently using the locationManager from plexus-java is done with a request > without jdkHome so per default a UOE is throw. > we need to get the jdkHome from the javadocExecutable -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MJAVADOC-612) UnsupportedOperationException for javadoc:aggregate with multi modules with jpms
[ https://issues.apache.org/jira/browse/MJAVADOC-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16998945#comment-16998945 ] Olivier Lamy commented on MJAVADOC-612: --- I might closed that one as fixed and open another one for aggregated and non .jar module > UnsupportedOperationException for javadoc:aggregate with multi modules with > jpms > > > Key: MJAVADOC-612 > URL: https://issues.apache.org/jira/browse/MJAVADOC-612 > Project: Maven Javadoc Plugin > Issue Type: Bug >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 3.2.0 > > > Currently using the locationManager from plexus-java is done with a request > without jdkHome so per default a UOE is throw. > we need to get the jdkHome from the javadocExecutable -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-372) Unable to compile modularized test code depending on test-jar
[
https://issues.apache.org/jira/browse/MCOMPILER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16998941#comment-16998941
]
François Loison commented on MCOMPILER-372:
---
I agree. I tested on a project structure of mine and patch broke test
compilation for reasons equivallent to what you said.
I'll work on this again.
> Unable to compile modularized test code depending on test-jar
> -
>
> Key: MCOMPILER-372
> URL: https://issues.apache.org/jira/browse/MCOMPILER-372
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.0
> Environment: Manjaro Linux 64 bit, Open JDK 11, Apache-Maven-3.6.0
>Reporter: Jeronimo Backes
>Assignee: Robert Scholte
>Priority: Blocker
> Attachments: maven-compiler-plugin.MCOMPILER-372.patch,
> univocity-all.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm refactoring
> [univocity-parsers|https://github.com/uniVocity/univocity-parsers] into
> multiple projects with modules (attached a zip with everything I got)
> However I'm unable to reliably build the attached project with its unit
> tests. Unpack then cd into "univocity-all-parent", then run "mvn clean
> install".
>
> All projects generate test-jars, but for some reason class
> *com.univocity.parsers.core.routine.ResultSetWritingRoutine* inside
> "univocity-parsers-core/src/test/java/" is not found when compiling the tests
> of projects "univocity-csv", "univocity-tsv" and "univocity-fixedwidth".
>
> Interestingly, the issue doesn't seem to be consistent as I got
> "univocity-csv" and "univocity-tsv" building without errors a few times.
> "univocity-fixedwidth" however failed consistently every single time.
> Some of the errors I get are:
> {{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.0:testCompile
> (default-testCompile) on project univocity-csv: Compilation failure:
> Compilation failure: }}
> {{[ERROR]
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[27,49]
> cannot find symbol}}
> {{[ERROR] symbol: class ResultSetWritingRoutine}}
> {{[ERROR] location: package com.univocity.parsers.core.routine}}
> {{[ERROR]
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[681,17]
> cannot find symbol}}
> {{[ERROR] symbol: class ResultSetWritingRoutine}}
> {{[ERROR] location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR]
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[681,52]
> cannot find symbol}}
> {{[ERROR] symbol: class ResultSetWritingRoutine}}
> {{[ERROR] location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR]
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[691,17]
> cannot find symbol}}
> {{[ERROR] symbol: class ResultSetTest}}
> {{[ERROR] location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR]
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/CsvWriterTest.java:[691,45]
> cannot find symbol}}
> {{[ERROR] symbol: class ResultSetTest}}
> {{[ERROR] location: class com.univocity.csv.CsvWriterTest}}
> {{[ERROR]
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[123,17]
> cannot find symbol}}
> {{[ERROR] symbol: class ResultSetWritingRoutine}}
> {{[ERROR] location: class com.univocity.csv.routine.CsvRoutinesTest}}
> {{[ERROR]
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[123,52]
> cannot find symbol}}
> {{[ERROR] symbol: class ResultSetWritingRoutine}}
> {{[ERROR] location: class com.univocity.csv.routine.CsvRoutinesTest}}
> {{[ERROR]
> /home/jbax/dev/repository/univocity-all/univocity-oss/univocity-csv/src/test/java/com/univocity/csv/routine/CsvRoutinesTest.java:[124,68]
> package ResultSetWritingRoutine does not exist}}
>
> I was also getting errors saying that the "Example" class was not found, or
> that the "printAndValidate" method was not found (that one comes from the
> univocity-output-tester dependency)..
>
> There's something very weird going on and it's not consistently reproducible.
> If you for example change the code in the failing tests use "*import static
> com.univocity.parsers.core.routine.ResultSetWritingRoutine.** " you may get a
> different set of errors. It's pretty intractable.
> I hope this provides enough information, let me know if you need anything
> else.
--
This message was sent by
[jira] [Created] (MRESOLVER-96) Dependency Injection fails after upgrading to Maven 3.6.2
Marek Neumann created MRESOLVER-96:
--
Summary: Dependency Injection fails after upgrading to Maven 3.6.2
Key: MRESOLVER-96
URL: https://issues.apache.org/jira/browse/MRESOLVER-96
Project: Maven Resolver
Issue Type: Bug
Components: resolver
Affects Versions: 1.4.1
Reporter: Marek Neumann
When using Maven Resolver 1.4.1 in combination with Maven 3.6.2 (also 3.6.3) we
face the following errors when we bootstrap our application:
{code:java}
Exception in thread "main" com.google.inject.CreationException: Unable to
create injector, see the following errors:1) No implementation for
org.apache.maven.model.composition.DependencyManagementImporter was bound.
while locating org.apache.maven.model.composition.DependencyManagementImporter
for field at
org.apache.maven.model.building.DefaultModelBuilder.dependencyManagementImporter(DefaultModelBuilder.java:207)
at
org.apache.maven.repository.internal.MavenResolverModule.configure(MavenResolverModule.java:58)
(via modules: build.development.boot.Bootstrap$ResolverModule ->
org.apache.maven.repository.internal.MavenResolverModule)2) No implementation
for org.apache.maven.model.management.DependencyManagementInjector was bound.
while locating org.apache.maven.model.management.DependencyManagementInjector
for field at
org.apache.maven.model.building.DefaultModelBuilder.dependencyManagementInjector(DefaultModelBuilder.java:213)
at
org.apache.maven.repository.internal.MavenResolverModule.configure(MavenResolverModule.java:58)
(via modules: build.development.boot.Bootstrap$ResolverModule ->
org.apache.maven.repository.internal.MavenResolverModule)
...
17 errors
at
com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:470)
at
com.google.inject.internal.InternalInjectorCreator.initializeStatically(InternalInjectorCreator.java:155)
at
com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:107)
at com.google.inject.Guice.createInjector(Guice.java:99)
at com.google.inject.Guice.createInjector(Guice.java:73)
at com.google.inject.Guice.createInjector(Guice.java:62){code}
The relevant code part is:
{code:java}
Guice.createInjector(new ResolverModule()).getInstance(RepositorySystem.class);
static class ResolverModule extends AbstractModule {
@Override
protected void configure() {
install(new MavenResolverModule());
bind(RepositoryConnectorFactory.class).annotatedWith(Names.named("basic")).to(BasicRepositoryConnectorFactory.class);
bind(TransporterFactory.class).annotatedWith(Names.named("file")).to(FileTransporterFactory.class);
bind(TransporterFactory.class).annotatedWith(Names.named("http")).to(HttpTransporterFactory.class);
}
@Provides
@Singleton
Set
provideRepositoryConnectorFactories(@Named("basic") RepositoryConnectorFactory
basic) {
Set factories = new HashSet<>();
factories.add(basic);
return Collections.unmodifiableSet(factories);
}
@Provides
@Singleton
Set provideTransporterFactories(@Named("file")
TransporterFactory file, @Named("http") TransporterFactory http) {
Set factories = new HashSet<>();
factories.add(file);
factories.add(http);
return Collections.unmodifiableSet(factories);
}
} {code}
This works with either maven-resolver-provider 3.6.0 or downgrading all
org.apache.maven.resolver artifacts to 1.3.1.
It seems as if a similar problem occurred in Idea when setting used Maven
version to 3.6.2:
[https://youtrack.jetbrains.com/issue/IDEA-221882]
Is this a regression introduced in one of the recent maven-resolver versions?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
