[jira] [Commented] (MPDF-47) docDescriptors of other locales than default are ignored for pdf generation
[
https://issues.apache.org/jira/browse/MPDF-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16216520#comment-16216520
]
Frank Weiler commented on MPDF-47:
--
The patch from Tim resolves the issue. It would be nice if this could be
incorporated for the next release.
> docDescriptors of other locales than default are ignored for pdf generation
> ---
>
> Key: MPDF-47
> URL: https://issues.apache.org/jira/browse/MPDF-47
> Project: Maven PDF Plugin
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: Maven 2.2.1, Windows 7 (and NetBeans 6.9.1)
>Reporter: Fabian Bahle
> Attachments: fix_locale_select.diff, pdf.xml, pdf_de.xml
>
>
> If you have a multi language maven site and you'll try to build a pdf also
> with multiple locales only the default pdf.xml docDescriptor will be used for
> generating the pdfs.
> Try following:
> Create a directory layout like:
> {noformat}
> +- src/
>+- site/
> +- xdoc/
> | +- index.xml (some default language content)
> | +- help.xml (some default language content)
> | +- foo.xml (some default language content)
> |
> +- de/
> | +- xdoc/
> | +- index.xml (some different content than default language)
> | +- help.xml (some different content than default language)
> | +- foo.xml (some different content than default language)
> +- site.xml (Default site descriptor)
> +- site_de.xml (German site descriptor)
> +- pdf.xml (Default pdf descriptor)
> +- pdf_de.xml (German pdf descriptor)
> {noformat}
> Content of pdf.xml:
> see attachment pdf.xml
> Content of pdf_de.xml:
> see attachment pdf_de.xml
> Content of pom.xml:
> {code:xml}
> ...
>
> ...
>
> ...
>
> org.apache.maven.plugins
> maven-site-plugin
> 2.2
>
> en,de
>
>
>
> org.apache.maven.plugins
> maven-pdf-plugin
> 1.1
>
>
> ${project.reporting.outputDirectory}
> false
> true
> en,de
>
>
>
> pdf
> site
>
> pdf
>
>
>
>
>
>
> {code}
> If you now execute
> {noformat}
> mvn site
> {noformat}
> or
> {noformat}
> mvn pdf:pdf
> {noformat}
> and compare the two generated pdfs you'll see that the table of contents is
> the one from the pdf.xml in both pdfs. I guess in this case the file
> pdf_de.xml isn't used at anytime during the build, because the build (mvn
> site or mvn pdf:pdf) is also successful if you have syntax errors in the
> pdf_de.xml file, e.g. leave a item tag open in that file and build again.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible updated MNG-6141:
Attachment: MNG-6141-2.zip
Extended example, where
* parent inherits maven-parent and manages junit,
* module-1 overrides plexus-component-annotations (managed by maven-parent) and
manages plexus-utils with a depMgmt section and
* a new module-3 (without a parent) using module-1.
{code:title=Module 1}
[DEBUG] localhost:module-1:jar:1.0-SNAPSHOT
[DEBUG]org.codehaus.plexus:plexus-component-annotations:jar:1.5.0:compile
[DEBUG] junit:junit:jar:3.8.1:compile (version managed from 3.8.2 by
localhost:parent:1.0-SNAPSHOT)
[DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG] org.apache.maven:maven-model:jar:3.0:compile
[DEBUG] org.codehaus.plexus:plexus-utils:jar:2.0.7:compile (version
managed from 2.0.4 by localhost:module-1:1.0-SNAPSHOT)
[DEBUG] org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG] org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
{code}
Module-3 obviously uses wrong plexus-utils and junit versions, but at least the
correct version of maven-plugin-api:
{code:title=Module 3}
[DEBUG] localhost:module-3:jar:1.0-SNAPSHOT
[DEBUG]localhost:module-1:jar:1.0-SNAPSHOT:compile
[DEBUG] org.codehaus.plexus:plexus-component-annotations:jar:1.5.0:compile
[DEBUG] junit:junit:jar:3.8.2:compile
[DEBUG] org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG] org.apache.maven:maven-model:jar:3.0:compile
[DEBUG] org.codehaus.plexus:plexus-utils:jar:2.0.4:compile
[DEBUG] org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG] org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG]org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
{code}
Generated with Maven 3.3.9.
If I understand you proposal now correctly, you would like to forbid the local
overriding of maven-plugin-api, which is ignored for module-2, but respected
for module-3. OTOH module-3 exposes different problems, since the active
depMgmt sections of a dependency itself are not considered.
One use case, where I use a local overriding also actively, is for testing a
different version of a dependency. Existing unit test may reveal a different
behaviour.
> Dependency management overrides are not transitive and should be considered
> an anti-pattern.
>
>
> Key: MNG-6141
> URL: https://issues.apache.org/jira/browse/MNG-6141
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Attachments: MNG-6141-2.zip, MNG-6141.zip
>
>
> Overriding the dependency management in a module's {{}}
> section, the overridden value will not be preserved transitively. It makes no
> sense to be able to override the dependency management in a module if that is
> only effective in that module and nowhere else. Overriding the dependency
> management from inside a {{}} element should be considered an
> anti-pattern. Maven should provide a warning when it is used. During the
> development of Maven 3.4, there have been quite a few discussions on dev@
> about build issues which were all caused by overriding the dependency
> management that way without noticing this is not supported transitively.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible updated MNG-6141:
Attachment: (was: MNG-6141-2.zip)
> Dependency management overrides are not transitive and should be considered
> an anti-pattern.
>
>
> Key: MNG-6141
> URL: https://issues.apache.org/jira/browse/MNG-6141
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Attachments: MNG-6141-3.zip, MNG-6141.zip
>
>
> Overriding the dependency management in a module's {{}}
> section, the overridden value will not be preserved transitively. It makes no
> sense to be able to override the dependency management in a module if that is
> only effective in that module and nowhere else. Overriding the dependency
> management from inside a {{}} element should be considered an
> anti-pattern. Maven should provide a warning when it is used. During the
> development of Maven 3.4, there have been quite a few discussions on dev@
> about build issues which were all caused by overriding the dependency
> management that way without noticing this is not supported transitively.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible updated MNG-6141:
Attachment: MNG-6141-3.zip
Updated example. Replaces MNG-6141-2.zip
> Dependency management overrides are not transitive and should be considered
> an anti-pattern.
>
>
> Key: MNG-6141
> URL: https://issues.apache.org/jira/browse/MNG-6141
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Attachments: MNG-6141-3.zip, MNG-6141.zip
>
>
> Overriding the dependency management in a module's {{}}
> section, the overridden value will not be preserved transitively. It makes no
> sense to be able to override the dependency management in a module if that is
> only effective in that module and nowhere else. Overriding the dependency
> management from inside a {{}} element should be considered an
> anti-pattern. Maven should provide a warning when it is used. During the
> development of Maven 3.4, there have been quite a few discussions on dev@
> about build issues which were all caused by overriding the dependency
> management that way without noticing this is not supported transitively.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16216635#comment-16216635
]
Joerg Schaible edited comment on MNG-6141 at 10/24/17 10:08 AM:
Extended example, where
* parent inherits maven-parent and manages junit,
* module-1 overrides plexus-component-annotations (managed by maven-parent) and
manages plexus-utils with a depMgmt section and
* a new module-3 (without a parent) using module-1.
{code:title=Module 1}
[DEBUG] localhost:module-1:jar:1.0-SNAPSHOT
[DEBUG]org.codehaus.plexus:plexus-component-annotations:jar:1.5.0:compile
[DEBUG] junit:junit:jar:3.8.1:compile (version managed from 3.8.2 by
localhost:parent:1.0-SNAPSHOT)
[DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG] org.apache.maven:maven-model:jar:3.0:compile
[DEBUG] org.codehaus.plexus:plexus-utils:jar:2.0.7:compile (version
managed from 2.0.4 by localhost:module-1:1.0-SNAPSHOT)
[DEBUG] org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG] org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
{code}
Module-3 obviously uses wrong plexus-utils and junit versions, but at least the
correct version of maven-plugin-api and plexus-component-annotations:
{code:title=Module 3}
[DEBUG] localhost:module-3:jar:1.0-SNAPSHOT
[DEBUG]localhost:module-1:jar:1.0-SNAPSHOT:compile
[DEBUG] org.codehaus.plexus:plexus-component-annotations:jar:1.5.0:compile
[DEBUG] junit:junit:jar:3.8.2:compile
[DEBUG] org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG] org.apache.maven:maven-model:jar:3.0:compile
[DEBUG] org.codehaus.plexus:plexus-utils:jar:2.0.4:compile
[DEBUG] org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG] org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG]org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
{code}
Generated with Maven 3.3.9.
If I understand you proposal now correctly, you would like to forbid the local
overriding of maven-plugin-api, which is ignored for module-2, but respected
for module-3. OTOH module-3 exposes different problems, since the active
depMgmt sections of a dependency itself are not considered.
One use case, where I use a local overriding also actively, is for testing a
different version of a dependency. Existing unit test may reveal a different
behaviour.
was (Author: joehni):
Extended example, where
* parent inherits maven-parent and manages junit,
* module-1 overrides plexus-component-annotations (managed by maven-parent) and
manages plexus-utils with a depMgmt section and
* a new module-3 (without a parent) using module-1.
{code:title=Module 1}
[DEBUG] localhost:module-1:jar:1.0-SNAPSHOT
[DEBUG]org.codehaus.plexus:plexus-component-annotations:jar:1.5.0:compile
[DEBUG] junit:junit:jar:3.8.1:compile (version managed from 3.8.2 by
localhost:parent:1.0-SNAPSHOT)
[DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG] org.apache.maven:maven-model:jar:3.0:compile
[DEBUG] org.codehaus.plexus:plexus-utils:jar:2.0.7:compile (version
managed from 2.0.4 by localhost:module-1:1.0-SNAPSHOT)
[DEBUG] org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG] org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
{code}
Module-3 obviously uses wrong plexus-utils and junit versions, but at least the
correct version of maven-plugin-api:
{code:title=Module 3}
[DEBUG] localhost:module-3:jar:1.0-SNAPSHOT
[DEBUG]localhost:module-1:jar:1.0-SNAPSHOT:compile
[DEBUG] org.codehaus.plexus:plexus-component-annotations:jar:1.5.0:compile
[DEBUG] junit:junit:jar:3.8.2:compile
[DEBUG] org.apache.maven:maven-plugin-api:jar:3.0:compile
[DEBUG] org.apache.maven:maven-model:jar:3.0:compile
[DEBUG] org.codehaus.plexus:plexus-utils:jar:2.0.4:compile
[DEBUG] org.apache.maven:maven-artifact:jar:3.0:compile
[DEBUG] org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
[DEBUG] org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
[DEBUG] org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
[DEBUG]org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
{code}
Generated with Maven 3.3.9.
If I understand y
[jira] [Commented] (SUREFIRE-1383) dependenciesToScan Does Not Leverage Classpath Elements
[ https://issues.apache.org/jira/browse/SUREFIRE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16216980#comment-16216980 ] ASF GitHub Bot commented on SUREFIRE-1383: -- Github user owenfarrell commented on the issue: https://github.com/apache/maven-surefire/pull/164 @Tibor17 - Is this what you were thinking of when you asked to clean up the distinct change sets related to #157? > dependenciesToScan Does Not Leverage Classpath Elements > > > Key: SUREFIRE-1383 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1383 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20 >Reporter: Owen Farrell >Assignee: Tibor Digana > Fix For: 2.21.1 > > Attachments: scanned-dependencies-sample.zip > > Time Spent: 48h > Remaining Estimate: 24h > > The configuration attribute relies solely on installed > artifacts. This is an issue when the targeted dependencies were built as part > of the current session. The net result is that stale artifacts are used (i.e. > if the dependency has changed since it was last installed) or the tests are > not executed at all (if the dependency has not been previously installed. > Attached is a sample project that illustrates this issue: > Given I have a multi-module project >And the first module built includes test classes as part of the project > artifact >And subsequent modules scan the first for unit tests to execute > When I execute the _*test*_ goal (prior to any install) > Then the build should succeed >And tests should be executed with each module -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6141) Dependency management overrides are not transitive and should be considered an anti-pattern.
[
https://issues.apache.org/jira/browse/MNG-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217126#comment-16217126
]
Ralph Goers commented on MNG-6141:
--
Can't this be resolved just by adding the enforcer plugin to the build?
> Dependency management overrides are not transitive and should be considered
> an anti-pattern.
>
>
> Key: MNG-6141
> URL: https://issues.apache.org/jira/browse/MNG-6141
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Attachments: MNG-6141-3.zip, MNG-6141.zip
>
>
> Overriding the dependency management in a module's {{}}
> section, the overridden value will not be preserved transitively. It makes no
> sense to be able to override the dependency management in a module if that is
> only effective in that module and nowhere else. Overriding the dependency
> management from inside a {{}} element should be considered an
> anti-pattern. Maven should provide a warning when it is used. During the
> development of Maven 3.4, there have been quite a few discussions on dev@
> about build issues which were all caused by overriding the dependency
> management that way without noticing this is not supported transitively.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ARCHETYPE-519) archetype:generate with specified remote archetypeCatalog falls back to internal catalog
[
https://issues.apache.org/jira/browse/ARCHETYPE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217296#comment-16217296
]
Petar Tahchiev commented on ARCHETYPE-519:
--
For me it works:
{{settings.xml}}
{code}
nemesis
nemesis-samplestore-archetype
https://repository.nemesis.io/artifactory/libs-snapshot/
nemesis-samplestore-archetype
ptahchiev
XXX
{code}
and then just the regular command line execution of {{archetype:generate}}.
> archetype:generate with specified remote archetypeCatalog falls back to
> internal catalog
>
>
> Key: ARCHETYPE-519
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-519
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 3.0.0
> Environment: Mac OS X 10.11.6, Apache Maven 3.2.3
>Reporter: Philip Mundt
>Assignee: Robert Scholte
> Fix For: 3.0.1
>
>
> We were surprised to find out that our archetype was "suddenly" not working
> anymore. It turns out it was the release of
> {{org.apache.maven.plugins:maven-archetype-plugin:3.0.0}} from 12/Feb/17 that
> was the culprit.
> When running:
> {{mvn org.apache.maven.plugins:maven-archetype-plugin:3.0.0:generate
> -DarchetypeCatalog=}} we end up with the
> plugin falling back to the internal catalog:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building Maven Stub Project (No POM) 1
> [INFO]
>
> [INFO]
> [INFO] >>> maven-archetype-plugin:3.0.0:generate (default-cli) >
> generate-sources @ standalone-pom >>>
> [INFO]
> [INFO] <<< maven-archetype-plugin:3.0.0:generate (default-cli) <
> generate-sources @ standalone-pom <<<
> [INFO]
> [INFO] --- maven-archetype-plugin:3.0.0:generate (default-cli) @
> standalone-pom ---
> [INFO] Generating project in Interactive mode
> [INFO] No catalog defined. Using internal catalog
> [INFO] No archetype defined. Using maven-archetype-quickstart
> (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
> Choose archetype:
> 1: internal -> org.apache.maven.archetypes:maven-archetype-archetype (An
> archetype which contains a sample archetype.)
> 2: internal -> org.apache.maven.archetypes:maven-archetype-j2ee-simple (An
> archetype which contains a simplifed sample J2EE application.)
> 3: internal -> org.apache.maven.archetypes:maven-archetype-plugin (An
> archetype which contains a sample Maven plugin.)
> 4: internal -> org.apache.maven.archetypes:maven-archetype-plugin-site (An
> archetype which contains a sample Maven plugin site.
> This archetype can be layered upon an existing Maven plugin project.)
> 5: internal -> org.apache.maven.archetypes:maven-archetype-portlet (An
> archetype which contains a sample JSR-268 Portlet.)
> 6: internal -> org.apache.maven.archetypes:maven-archetype-profiles ()
> 7: internal -> org.apache.maven.archetypes:maven-archetype-quickstart (An
> archetype which contains a sample Maven project.)
> 8: internal -> org.apache.maven.archetypes:maven-archetype-site (An archetype
> which contains a sample Maven site which demonstrates
> some of the supported document types like APT, XDoc, and FML and
> demonstrates how
> to i18n your site. This archetype can be layered upon an existing Maven
> project.)
> 9: internal -> org.apache.maven.archetypes:maven-archetype-site-simple (An
> archetype which contains a sample Maven site.)
> 10: internal -> org.apache.maven.archetypes:maven-archetype-webapp (An
> archetype which contains a sample Maven Webapp project.)
> Choose a number or apply filter (format: [groupId:]artifactId, case sensitive
> contains):
> {code}
> Version 2.4 works as expected (the archetype catalog exists under given URL
> and can be downloaded).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MNG-6294) Convert MavenPluginValidator into a plexus component
Michael Simacek created MNG-6294: Summary: Convert MavenPluginValidator into a plexus component Key: MNG-6294 URL: https://issues.apache.org/jira/browse/MNG-6294 Project: Maven Issue Type: Improvement Components: core Reporter: Michael Simacek [XMvn|https://github.com/fedora-java/xmvn] is a maven extension that helps with creating RPM packages. In order to comply with packaging requirements, it needs to relax some checks that maven does. One of those is plugin validation done in MavenPluginValidator class. Currently, it overrides that by shadowing the class on the classpath, which is a hack. It would help if MavenPluginValidator was a plexus component and thus the implementation could be selected by configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6294) Convert MavenPluginValidator into a plexus component
[ https://issues.apache.org/jira/browse/MNG-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217492#comment-16217492 ] ASF GitHub Bot commented on MNG-6294: - GitHub user msimacek opened a pull request: https://github.com/apache/maven/pull/134 [MNG-6294] Convert MavenPluginValidator into a plexus component Patch for https://issues.apache.org/jira/browse/MNG-6294 You can merge this pull request into a Git repository by running: $ git pull https://github.com/msimacek/maven master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/134.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #134 > Convert MavenPluginValidator into a plexus component > > > Key: MNG-6294 > URL: https://issues.apache.org/jira/browse/MNG-6294 > Project: Maven > Issue Type: Improvement > Components: core >Reporter: Michael Simacek > > [XMvn|https://github.com/fedora-java/xmvn] is a maven extension that helps > with creating RPM packages. In order to comply with packaging requirements, > it needs to relax some checks that maven does. One of those is plugin > validation done in MavenPluginValidator class. Currently, it overrides that > by shadowing the class on the classpath, which is a hack. It would help if > MavenPluginValidator was a plexus component and thus the implementation could > be selected by configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MCOMPILER-313) Support mrjar dependency with module descriptor only in META-INF/versions/x
Robert Scholte created MCOMPILER-313: Summary: Support mrjar dependency with module descriptor only in META-INF/versions/x Key: MCOMPILER-313 URL: https://issues.apache.org/jira/browse/MCOMPILER-313 Project: Maven Compiler Plugin Issue Type: Improvement Affects Versions: 3.7.0 Reporter: Robert Scholte Assignee: Robert Scholte Fix For: 3.7.1 Requires upgrade of plexus-java to 0.9.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MCOMPILER-313) Support mrjar dependency with module descriptor only in META-INF/versions/x
[ https://issues.apache.org/jira/browse/MCOMPILER-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MCOMPILER-313. Resolution: Fixed Fixed in [r1813229|http://svn.apache.org/viewvc?rev=1813229&view=rev] > Support mrjar dependency with module descriptor only in META-INF/versions/x > > > Key: MCOMPILER-313 > URL: https://issues.apache.org/jira/browse/MCOMPILER-313 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.7.0 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 3.7.1 > > > Requires upgrade of plexus-java to 0.9.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9
[
https://issues.apache.org/jira/browse/SUREFIRE-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217701#comment-16217701
]
Enrico Olivelli commented on SUREFIRE-1424:
---
I think that Alan's answer is complete.
Maybe we could just add this list to the FAQ page about java9. It is not a
surefire issue indeed.
We can drop the -add-modules and fix the it tests just by adding the required
dependencies on the poms in order to demonstrate that this approch is working.
For java.sql package we can add an it test which adds -add-modules=java.sql in
case of build on java9 using a profile.
Does this sound good to you Tibor and Robert?
> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks
> like Maven specific. I've managed to trim down the problem to [a simple class
> that doesn't involve Spring
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<<
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests) Time
> elapsed: 0.006 s <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException:
> javax.transaction.TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has
> also a simple Gradle build that shows it works with Gradle as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (MNG-6255) Maven script cannot parse jvm.config with CRLF
[
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly resolved MNG-6255.
---
Resolution: Fixed
Fix Version/s: 3.5.2
> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
> Fix For: 3.5.2
>
>
> A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will
> not parse it correctly. The script uses the {{tr}} command to change *LF* to
> space, but this leaves *CR* behind. For example, with the {{jvm.config}} file
> containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following
> error message is printed:
> {code}
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial heap size: -Xms512m
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (MNG-6255) Maven script cannot parse jvm.config with CRLF
[
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly reopened MNG-6255:
---
> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will
> not parse it correctly. The script uses the {{tr}} command to change *LF* to
> space, but this leaves *CR* behind. For example, with the {{jvm.config}} file
> containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following
> error message is printed:
> {code}
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial heap size: -Xms512m
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6255) Maven script cannot parse jvm.config with CRLF
[
https://issues.apache.org/jira/browse/MNG-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Connolly updated MNG-6255:
--
Fix Version/s: (was: 3.5.2)
> Maven script cannot parse jvm.config with CRLF
> --
>
> Key: MNG-6255
> URL: https://issues.apache.org/jira/browse/MNG-6255
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
> Environment: Windows 7 with MINGW64 environment via Git for Windows
> 0.1.1 including GNU coreutils and bash 4.4.12
>Reporter: Andrew Kennedy
>
> A project with a {{.mvn/jvm.config}} file that has *CRLF* line endings will
> not parse it correctly. The script uses the {{tr}} command to change *LF* to
> space, but this leaves *CR* behind. For example, with the {{jvm.config}} file
> containing the text {{-Xmx1024m -Xms512m}} followed by *CRLF*, the following
> error message is printed:
> {code}
> $ mvn install
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> Invalid initial heap size: -Xms512m
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9
[
https://issues.apache.org/jira/browse/SUREFIRE-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217715#comment-16217715
]
Robert Scholte commented on SUREFIRE-1424:
--
I would expect users to hit such issue already at compile time when working
with Java 9. I don't remember all the details about the {{java.sql}} package,
but the original fix does more harm than good.
> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks
> like Maven specific. I've managed to trim down the problem to [a simple class
> that doesn't involve Spring
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<<
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests) Time
> elapsed: 0.006 s <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException:
> javax.transaction.TransactionManager
> at
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has
> also a simple Gradle build that shows it works with Gradle as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCOMPILER-313) Support mrjar dependency with module descriptor only in META-INF/versions/x
[ https://issues.apache.org/jira/browse/MCOMPILER-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217747#comment-16217747 ] Hudson commented on MCOMPILER-313: -- SUCCESS: Integrated in Jenkins build maven-plugins #9175 (See [https://builds.apache.org/job/maven-plugins/9175/]) [MCOMPILER-313] Support mrjar dependency with module descriptor only in META-INF/versions/x (rfscholte: [http://svn.apache.org/viewvc/?view=rev&rev=1813229]) * (edit) maven-compiler-plugin/pom.xml * (edit) maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java > Support mrjar dependency with module descriptor only in META-INF/versions/x > > > Key: MCOMPILER-313 > URL: https://issues.apache.org/jira/browse/MCOMPILER-313 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.7.0 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 3.7.1 > > > Requires upgrade of plexus-java to 0.9.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ARCHETYPE-505) archetype:create-from-project,the .gitignore file not copy to archetype-resources
[
https://issues.apache.org/jira/browse/ARCHETYPE-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16218074#comment-16218074
]
justin georgeson commented on ARCHETYPE-505:
While the post-generate groovy script works, I can't use a reference project IT
because the reference project is first copied to the target folder using the
default excludes. Why copy the reference project to the target folder before
comparing?
> archetype:create-from-project,the .gitignore file not copy to
> archetype-resources
> -
>
> Key: ARCHETYPE-505
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-505
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
>Affects Versions: 2.4
> Environment: maven 3.3 ,maven-archetype-plugin 2.4
>Reporter: feilong
> Attachments: webapp-springmvc32.zip
>
>
> I have a very simple maven test project for {{archetype:create-from-project}}
> such as :(you can download from the Attachment)
> {noformat}
> | .gitignore
> | pom.xml
> |
> \---src
> +---main
> | \---java
> | overview.html
> |
> \---test
> {noformat}
> only {{.gitignore}} and {{pom.xml}}, and {{overview.html}} files
> and I excute the command line in the root folder:
> {code:xml}
> mvn -X archetype:create-from-project
> {code}
> I see ,in the
> {{target\generated-sources\archetype\src\main\resources\archetype-resources}}
> folder, only
> {noformat}
> | pom.xml
> |
> \---src
> \---main
> \---java
> overview.html
> {noformat}
> no {{.gitignore}} file
>
> first , I search the same issue in jira, there is #ARCHETYPE-474 , but not as
> my scene
>
> I search some solution in stackoverflow
> http://stackoverflow.com/questions/7981060/maven-archetype-plugin-doesnt-let-resources-in-archetype-resources-through#answer-37322323
> In pom.xml,I have also configed that
> {code:xml}
>
> maven-resources-plugin
> 3.0.1
>
> utf-8
> true
> false
>
>
>
> default-resources
> process-resources
>
> resources
>
>
> true
>
>
>
> default-testResources
> process-test-resources
>
> testResources
>
>
>
>
> {code}
> {{maven-resources-plugin}} set {{addDefaultExcludes}} attribute to {{false}}
> but does't work
>
> so, I look for the maven-archetype source code in github
> https://github.com/apache/maven-archetype
> the
> org.apache.maven.archetype.creator.FilesetArchetypeCreator.*createArchetypeFiles*(Properties,
> List, String, File, File, String) method
> line 796 show that:
> {code:title=FilesetArchetypeCreator.java|borderStyle=solid}
> private void createArchetypeFiles( Properties reverseProperties,
> List fileSets, String packageName,
>File basedir, File
> archetypeFilesDirectory, String defaultEncoding )
> throws IOException
> {
> getLogger().debug( "Creating Archetype/Module files from " + basedir
> + " to " + archetypeFilesDirectory );
> for ( FileSet fileSet : fileSets )
> {
> DirectoryScanner scanner = new DirectoryScanner();
> scanner.setBasedir( basedir );
> scanner.setIncludes( (String[]) concatenateToList(
> fileSet.getIncludes(), fileSet.getDirectory() ).toArray(
> new String[fileSet.getIncludes().size()] ) );
> scanner.setExcludes( (String[]) fileSet.getExcludes().toArray(
> new String[fileSet.getExcludes().size()] ) );
> scanner.addDefaultExcludes();
> getLogger().debug( "Using fileset " + fileSet );
> scanner.scan();
> List fileSetResources = Arrays.asList(
> scanner.getIncludedFiles() );
> getLogger().debug( "Scanned " + fileSetResources.size() + "
> resources" );
>
> .
> {code}
> here is {{scanner.addDefaultExcludes();}}
> So , the result log show that :
> {noformat}
> [DEBUG] Creating Archetype/Module files from
> C:\Users\feilong\feilong\feilong-archetypes\0726-232539 to
> C:\Users\feilong\feilong\feilong-archetypes\0726-232539\
> target\generated-sources\archetype\src\main\resources\archetype-resources
> [DEBUG] Using fileset src/main/java (Copied-Flat) [**/*.html -- ]
> [DEBUG] Scanned 1 resources
> [DEBUG] Package as Directory: Package:com.baozun.store->com\baozun\store
> [DEBUG] InputFileName:src\main\java\overview.html
> [DEBUG] OutputFileName:src\main\java\overview.html
> [DEBUG] Copied src/main/java files
> [DEBUG] Using fileset (Copied-Flat) [.gitignore -- ]
> [D
