[jira] [Created] (MPDF-96) Ability to automatically include in the TOC documents that are located in subfolders
Simona created MPDF-96: -- Summary: Ability to automatically include in the TOC documents that are located in subfolders Key: MPDF-96 URL: https://issues.apache.org/jira/browse/MPDF-96 Project: Maven PDF Plugin Issue Type: New Feature Reporter: Simona Only the documents that are in the root are included in the PDF. If you have documents that are in subfolders these documents are not converted into the PDF and included in the TOC. As a developer I want to be able to declare an item within the pdf.xml that allows me to automatically include all the documents contained in the sub-folders in the TOC without having to declare them by hand -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202439#comment-17202439
]
Marat Abrarov edited comment on MEAR-267 at 9/25/20, 10:04 PM:
---
Hi [~leokom],
Won't workaround in [pull request
#1|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] of
lrozenblyum/MEAR-267-issue-demo project work for you? I understand that it's
not solution, e.g. the same EJB JAR may be included into different EARs each
having different
[outputFileNameMapping|https://maven.apache.org/plugins/maven-ear-plugin/examples/customize-file-name-mapping.html]
and the workaround doesn't work in this case.
It looks like with 3.0 version of Maven EAR Plugin default
outputFileNameMapping was changed to include group ID. I explicitly defined
outputFileNameMapping to look like:
{noformat}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{noformat}
when migrated one of my projects from Maven EAR Plugin 2.10.1 to 3.0.2. May be
the same solution is more applicable to your needs.
Thank you for detecting and describing this bug.
was (Author: abrarovm):
Hi [~leokom],
Won't workaround in [pull request
#1|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] of
lrozenblyum/MEAR-267-issue-demo project work for you? I understand that it's
not solution, e.g. the same EJB JAR may be included into different EARs each
having different
[outputFileNameMapping|https://maven.apache.org/plugins/maven-ear-plugin/examples/customize-file-name-mapping.html]
and the workaround doesn't work in this case.
It looks like with 3.0 version of Maven EAR Plugin default
outputFileNameMapping was changed to include group ID. I explicitly defined
outputFileNameMapping to look like:
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
when migrated one of my projects from Maven EAR Plugin 2.10.1 to 3.0.2. May be
the same solution is more applicable to your needs.
Thank you for detecting and describing this bug.
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml
> reference would be:
> {quote}{{}}
> tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
> assembly.xml contains reference
> {quote}
> com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
>
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this
> scenario in standalone mode without Eclipse - and assembly.xml is consistent
> with the jar files
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202439#comment-17202439
]
Marat Abrarov commented on MEAR-267:
Hi [~leokom],
Won't workaround in [pull request
#1|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] of
lrozenblyum/MEAR-267-issue-demo project work for you? I understand that it's
not solution, e.g. the same EJB JAR may be included into different EARs each
having different
[outputFileNameMapping|https://maven.apache.org/plugins/maven-ear-plugin/examples/customize-file-name-mapping.html]
and the workaround doesn't work in this case.
It looks like with 3.0 version of Maven EAR Plugin default
outputFileNameMapping was changed to include group ID. I explicitly defined
outputFileNameMapping to look like:
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
when migrated one of my projects from Maven EAR Plugin 2.10.1 to 3.0.2. May be
the same solution is more applicable to your needs.
Thank you for detecting and describing this bug.
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml
> reference would be:
> {quote}{{}}
> tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
> assembly.xml contains reference
> {quote}
> com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
>
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this
> scenario in standalone mode without Eclipse - and assembly.xml is consistent
> with the jar files
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202439#comment-17202439
]
Marat Abrarov edited comment on MEAR-267 at 9/25/20, 10:03 PM:
---
Hi [~leokom],
Won't workaround in [pull request
#1|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] of
lrozenblyum/MEAR-267-issue-demo project work for you? I understand that it's
not solution, e.g. the same EJB JAR may be included into different EARs each
having different
[outputFileNameMapping|https://maven.apache.org/plugins/maven-ear-plugin/examples/customize-file-name-mapping.html]
and the workaround doesn't work in this case.
It looks like with 3.0 version of Maven EAR Plugin default
outputFileNameMapping was changed to include group ID. I explicitly defined
outputFileNameMapping to look like:
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
when migrated one of my projects from Maven EAR Plugin 2.10.1 to 3.0.2. May be
the same solution is more applicable to your needs.
Thank you for detecting and describing this bug.
was (Author: abrarovm):
Hi [~leokom],
Won't workaround in [pull request
#1|https://github.com/lrozenblyum/MEAR-267-issue-demo/pull/1] of
lrozenblyum/MEAR-267-issue-demo project work for you? I understand that it's
not solution, e.g. the same EJB JAR may be included into different EARs each
having different
[outputFileNameMapping|https://maven.apache.org/plugins/maven-ear-plugin/examples/customize-file-name-mapping.html]
and the workaround doesn't work in this case.
It looks like with 3.0 version of Maven EAR Plugin default
outputFileNameMapping was changed to include group ID. I explicitly defined
outputFileNameMapping to look like:
{code:xml}
org.apache.maven.plugins
maven-ear-plugin
3.0.2
...
@{artifactId}@-@{baseVersion}@@{dashClassifier?}@.@{extension}@
{code}
when migrated one of my projects from Maven EAR Plugin 2.10.1 to 3.0.2. May be
the same solution is more applicable to your needs.
Thank you for detecting and describing this bug.
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml
> reference would be:
> {quote}{{}}
> tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
> assembly.xml contains reference
> {quote}
> com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
>
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this
> scenario in standalone mode without Eclipse - and assembly.xml is consistent
> with the jar files
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MINDEXER-125) Spring Boot Starter artifact missing
[
https://issues.apache.org/jira/browse/MINDEXER-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MINDEXER-125.
---
Resolution: Cannot Reproduce
JAR is there.
> Spring Boot Starter artifact missing
>
>
> Key: MINDEXER-125
> URL: https://issues.apache.org/jira/browse/MINDEXER-125
> Project: Maven Indexer
> Issue Type: Bug
>Reporter: Marco Rizzi
>Priority: Major
>
> For the artifacts in
> [https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/,]
> in the Maven Index I can only find 3 of them (module, javadoc and source).
> I can not find any entry for the
> "{{spring-boot-starter-web-2.3.2.RELEASE.jar}}".
> Could the cause be related to the fact that the "module" artifact
> ("{{spring-boot-starter-web-2.3.2.RELEASE.module}}") has the
> "{{u:org.springframework.boot|spring-boot-starter-web|2.3.2.RELEASE|NA}}"?
> AFAIK it should have a further suffix "{{module}}" since module is the
> extension (according to "{{u}}" filed definition in [1]).
> Or could it be related to
> [spring-boot-starter-web-2.3.2.RELEASE.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE.jar.sha1]
> and
> [spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1]
> having the same value (i.e. "{{85f79121fdaabcbcac085d0d4aad34af9f8dbba2}}")
> Thanks in advance,
> Marco
> [1]
> [https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/indexer-core/index.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6093) create a slf4j-simple provider extension that supports level color rendering
[ https://issues.apache.org/jira/browse/MNG-6093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202427#comment-17202427 ] Philippe Cloutier commented on MNG-6093: Would someone explain how this was solved? The links are broken so I really can't figure it out. > create a slf4j-simple provider extension that supports level color rendering > > > Key: MNG-6093 > URL: https://issues.apache.org/jira/browse/MNG-6093 > Project: Maven > Issue Type: New Feature > Components: Logging >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.5.0-alpha-1, 3.5.0 > > > With color support, core Maven and plugins do general message colorization > (or more high-level "message styling" through maven-shared-utils) > slf4j provider however has to add color: > - for log level output (DEBUG/INFO/WARNING/ERROR) > - for stacktrace rendering > That's why we use Gossip slf4j provider: it has sufficient little extension > points to add this, with just a little bit of code (see > http://maven.apache.org/ref/3-LATEST/maven-embedder/apidocs/org/apache/maven/cli/logging/impl/gossip/package-summary.html > ) and configuration > The issue with switching to Gossip slf4j provider is that people don't know > it and it does not have the same features as slf4j-simple (missing relative > timestamps and configuration with CLI: see > http://mail-archives.apache.org/mod_mbox/maven-dev/201607.mbox/%3CCAK8jvqxYNK4weM2Frp4Brg3J7EybyjBiCsSRdGuNMQhYAG728Q%40mail.gmail.com%3E > ), the configuration file is not the same (name nor content). > But the extension points are not that big: if slf4j-simple provider just made > a few methods protected instread of private, it would be extensible > What if we just copy slf4j-simple to change the signatures and create small > extension classes? The license permits it, we can try it and eventually see > with slf4j if the modification can go into official release -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] eolivelli commented on pull request #378: [MNG-6991] Restore how the local repository is determined
eolivelli commented on pull request #378: URL: https://github.com/apache/maven/pull/378#issuecomment-699124410 Shall we add a couple of tests that cover the change please? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MINDEXER-125) Spring Boot Starter artifact missing
[
https://issues.apache.org/jira/browse/MINDEXER-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202363#comment-17202363
]
Michael Boyles commented on MINDEXER-125:
-
This is not a maven issue. If you have think something is missing, you should
speak to the people who publish it.
Anyway, I'm looking at the same repo you linked and the jar is there.
> Spring Boot Starter artifact missing
>
>
> Key: MINDEXER-125
> URL: https://issues.apache.org/jira/browse/MINDEXER-125
> Project: Maven Indexer
> Issue Type: Bug
>Reporter: Marco Rizzi
>Priority: Major
>
> For the artifacts in
> [https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/,]
> in the Maven Index I can only find 3 of them (module, javadoc and source).
> I can not find any entry for the
> "{{spring-boot-starter-web-2.3.2.RELEASE.jar}}".
> Could the cause be related to the fact that the "module" artifact
> ("{{spring-boot-starter-web-2.3.2.RELEASE.module}}") has the
> "{{u:org.springframework.boot|spring-boot-starter-web|2.3.2.RELEASE|NA}}"?
> AFAIK it should have a further suffix "{{module}}" since module is the
> extension (according to "{{u}}" filed definition in [1]).
> Or could it be related to
> [spring-boot-starter-web-2.3.2.RELEASE.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE.jar.sha1]
> and
> [spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1]
> having the same value (i.e. "{{85f79121fdaabcbcac085d0d4aad34af9f8dbba2}}")
> Thanks in advance,
> Marco
> [1]
> [https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/indexer-core/index.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MINDEXER-125) Spring Boot Starter artifact missing
Marco Rizzi created MINDEXER-125:
Summary: Spring Boot Starter artifact missing
Key: MINDEXER-125
URL: https://issues.apache.org/jira/browse/MINDEXER-125
Project: Maven Indexer
Issue Type: Bug
Reporter: Marco Rizzi
For the artifacts in
[https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/,]
in the Maven Index I can only find 3 of them (module, javadoc and source).
I can not find any entry for the
"{{spring-boot-starter-web-2.3.2.RELEASE.jar}}".
Could the cause be related to the fact that the "module" artifact
("{{spring-boot-starter-web-2.3.2.RELEASE.module}}") has the
"{{u:org.springframework.boot|spring-boot-starter-web|2.3.2.RELEASE|NA}}"?
AFAIK it should have a further suffix "{{module}}" since module is the
extension (according to "{{u}}" filed definition in [1]).
Or could it be related to
[spring-boot-starter-web-2.3.2.RELEASE.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE.jar.sha1]
and
[spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1|https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-starter-web/2.3.2.RELEASE/spring-boot-starter-web-2.3.2.RELEASE-javadoc.jar.sha1]
having the same value (i.e. "{{85f79121fdaabcbcac085d0d4aad34af9f8dbba2}}")
Thanks in advance,
Marco
[1]
[https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/indexer-core/index.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] mthmulders opened a new pull request #378: [MNG-6991] Restore how the local repository is determined
mthmulders opened a new pull request #378: URL: https://github.com/apache/maven/pull/378 The refactoring of MavenCli.populateRequest introduced a subtle bug. It would select ~/.m2/repository as the local repository instead of something that is configured in ~/.m2/settings.xml. See [MNG-6991](https://issues.apache.org/jira/browse/MNG-6991) and [this Slack discussion](https://the-asf.slack.com/archives/C7Q9JB404/p1601016907001000) for additional details. - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the [Core IT][core-its] successfully. - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6991) settings-defined local repository is not honored
[
https://issues.apache.org/jira/browse/MNG-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202233#comment-17202233
]
Michael Osipov commented on MNG-6991:
-
[~facewindu], really appreciate that you test snapshots!
> settings-defined local repository is not honored
>
>
> Key: MNG-6991
> URL: https://issues.apache.org/jira/browse/MNG-6991
> Project: Maven
> Issue Type: Bug
>Reporter: François Guillot
>Assignee: Maarten Mulders
>Priority: Major
>
> We have functional tests using the latest Maven snapshots and they started
> polluting the global ~/.m2/repository.
> [This
> commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
> introduced a bug in the handling of the local repository definition.
> The local repository is taken from settings
> [here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
> but then, before, Maven was doing (in MavenCli)
> {code}
> String localRepoProperty = request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> if ( localRepoProperty == null )
> {
> localRepoProperty = request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> }
> if ( localRepoProperty != null )
> {
> request.setLocalRepositoryPath( localRepoProperty );
> }
> {code}
> effectively replacing the local repository definition only if
> `maven.repo.local` was defined in user or system properties.
>
> After the commit mentioned above, the code does
> {code}
> request.setLocalRepositoryPath( determineLocalRepositoryPath( request
> ) );
> ...
> private String determineLocalRepositoryPath( final
> MavenExecutionRequest request )
> {
> return request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY,
> request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY ) // null if not found
> );
> }
> {code}
> effectively _always_ replacing the local repository definition, potentially
> nulling it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-ear-plugin] elharo opened a new pull request #15: [MEAR-285] check return value from mkdirs
elharo opened a new pull request #15: URL: https://github.com/apache/maven-ear-plugin/pull/15 @hboutemy This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shared-utils] elharo opened a new pull request #65: fix a few JavaDoc errors
elharo opened a new pull request #65: URL: https://github.com/apache/maven-shared-utils/pull/65 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] elharo merged pull request #13: [MEAR-285] clean up exception handling
elharo merged pull request #13: URL: https://github.com/apache/maven-ear-plugin/pull/13 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] santik commented on a change in pull request #9: [MEAR-194] Use ear archiver instead of jar archiver
santik commented on a change in pull request #9:
URL: https://github.com/apache/maven-ear-plugin/pull/9#discussion_r494092160
##
File path: src/main/java/org/apache/maven/plugins/ear/EarMojo.java
##
@@ -289,12 +296,25 @@ public void execute()
final File earFile;
final MavenArchiver archiver;
final Date reproducibleLastModifiedDate;
+File ddFile = new File( getWorkDirectory(), APPLICATION_XML_URI );
try
{
earFile = getEarFile( outputDirectory, finalName, classifier );
archiver = new EarMavenArchiver( getModules() );
-getLog().debug( "Jar archiver implementation [" +
jarArchiver.getClass().getName() + "]" );
-archiver.setArchiver( jarArchiver );
+JarArchiver theArchiver;
+if ( ddFile.exists() )
+{
+final EarArchiver earArchiver = getEarArchiver();
+earArchiver.setAppxml( ddFile );
+theArchiver = earArchiver;
+}
+else
+{
+theArchiver = getJarArchiver();
Review comment:
file is not required for the jar archiver, but required for ear
##
File path: src/main/java/org/apache/maven/plugins/ear/EarMojo.java
##
@@ -289,12 +296,25 @@ public void execute()
final File earFile;
final MavenArchiver archiver;
final Date reproducibleLastModifiedDate;
+File ddFile = new File( getWorkDirectory(), APPLICATION_XML_URI );
try
{
earFile = getEarFile( outputDirectory, finalName, classifier );
archiver = new EarMavenArchiver( getModules() );
-getLog().debug( "Jar archiver implementation [" +
jarArchiver.getClass().getName() + "]" );
-archiver.setArchiver( jarArchiver );
+JarArchiver theArchiver;
+if ( ddFile.exists() )
+{
+final EarArchiver earArchiver = getEarArchiver();
+earArchiver.setAppxml( ddFile );
+theArchiver = earArchiver;
+}
+else
+{
+theArchiver = getJarArchiver();
Review comment:
ok
I fixed conflicts again
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-ear-plugin] elharo merged pull request #14: [MEAR-285] Prefer Apache commons IO dependencies
elharo merged pull request #14: URL: https://github.com/apache/maven-ear-plugin/pull/14 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] hboutemy commented on a change in pull request #9: [MEAR-194] Use ear archiver instead of jar archiver
hboutemy commented on a change in pull request #9:
URL: https://github.com/apache/maven-ear-plugin/pull/9#discussion_r494063438
##
File path: src/main/java/org/apache/maven/plugins/ear/EarMojo.java
##
@@ -289,12 +296,25 @@ public void execute()
final File earFile;
final MavenArchiver archiver;
final Date reproducibleLastModifiedDate;
+File ddFile = new File( getWorkDirectory(), APPLICATION_XML_URI );
try
{
earFile = getEarFile( outputDirectory, finalName, classifier );
archiver = new EarMavenArchiver( getModules() );
-getLog().debug( "Jar archiver implementation [" +
jarArchiver.getClass().getName() + "]" );
-archiver.setArchiver( jarArchiver );
+JarArchiver theArchiver;
+if ( ddFile.exists() )
+{
+final EarArchiver earArchiver = getEarArchiver();
+earArchiver.setAppxml( ddFile );
+theArchiver = earArchiver;
+}
+else
+{
+theArchiver = getJarArchiver();
Review comment:
given there is a test later that checks and fail if the descriptor does
not exist, it seems this case is not really useful, isn't it?
##
File path: src/main/java/org/apache/maven/plugins/ear/EarMojo.java
##
@@ -289,12 +296,25 @@ public void execute()
final File earFile;
final MavenArchiver archiver;
final Date reproducibleLastModifiedDate;
+File ddFile = new File( getWorkDirectory(), APPLICATION_XML_URI );
try
{
earFile = getEarFile( outputDirectory, finalName, classifier );
archiver = new EarMavenArchiver( getModules() );
-getLog().debug( "Jar archiver implementation [" +
jarArchiver.getClass().getName() + "]" );
-archiver.setArchiver( jarArchiver );
+JarArchiver theArchiver;
+if ( ddFile.exists() )
+{
+final EarArchiver earArchiver = getEarArchiver();
+earArchiver.setAppxml( ddFile );
+theArchiver = earArchiver;
+}
+else
+{
+theArchiver = getJarArchiver();
Review comment:
I tested and found that starting with JavaEE 5, descriptor is not
required: but currently, EarArchiver is implemented in a way that does not
support this condition
ok, now I see how we must either improve EarArchiver, either do the
workaround you did: I'll merge and document the workaround
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-ear-plugin] santik commented on a change in pull request #9: [MEAR-194] Use ear archiver instead of jar archiver
santik commented on a change in pull request #9:
URL: https://github.com/apache/maven-ear-plugin/pull/9#discussion_r494830755
##
File path: src/main/java/org/apache/maven/plugins/ear/EarMojo.java
##
@@ -289,12 +296,25 @@ public void execute()
final File earFile;
final MavenArchiver archiver;
final Date reproducibleLastModifiedDate;
+File ddFile = new File( getWorkDirectory(), APPLICATION_XML_URI );
try
{
earFile = getEarFile( outputDirectory, finalName, classifier );
archiver = new EarMavenArchiver( getModules() );
-getLog().debug( "Jar archiver implementation [" +
jarArchiver.getClass().getName() + "]" );
-archiver.setArchiver( jarArchiver );
+JarArchiver theArchiver;
+if ( ddFile.exists() )
+{
+final EarArchiver earArchiver = getEarArchiver();
+earArchiver.setAppxml( ddFile );
+theArchiver = earArchiver;
+}
+else
+{
+theArchiver = getJarArchiver();
Review comment:
ok
I fixed conflicts again
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Assigned] (MNG-6991) settings-defined local repository is not honored
[
https://issues.apache.org/jira/browse/MNG-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders reassigned MNG-6991:
Assignee: Maarten Mulders
> settings-defined local repository is not honored
>
>
> Key: MNG-6991
> URL: https://issues.apache.org/jira/browse/MNG-6991
> Project: Maven
> Issue Type: Bug
>Reporter: François Guillot
>Assignee: Maarten Mulders
>Priority: Major
>
> We have functional tests using the latest Maven snapshots and they started
> polluting the global ~/.m2/repository.
> [This
> commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
> introduced a bug in the handling of the local repository definition.
> The local repository is taken from settings
> [here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
> but then, before, Maven was doing (in MavenCli)
> {code}
> String localRepoProperty = request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> if ( localRepoProperty == null )
> {
> localRepoProperty = request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> }
> if ( localRepoProperty != null )
> {
> request.setLocalRepositoryPath( localRepoProperty );
> }
> {code}
> effectively replacing the local repository definition only if
> `maven.repo.local` was defined in user or system properties.
>
> After the commit mentioned above, the code does
> {code}
> request.setLocalRepositoryPath( determineLocalRepositoryPath( request
> ) );
> ...
> private String determineLocalRepositoryPath( final
> MavenExecutionRequest request )
> {
> return request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY,
> request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY ) // null if not found
> );
> }
> {code}
> effectively _always_ replacing the local repository definition, potentially
> nulling it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6991) settings-defined local repository is not honored
[
https://issues.apache.org/jira/browse/MNG-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
François Guillot updated MNG-6991:
--
Description:
We have functional tests using the latest Maven snapshots and they started
polluting the global ~/.m2/repository.
[This
commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
introduced a bug in the handling of the local repository definition.
The local repository is taken from settings
[here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
but then, before, Maven was doing (in MavenCli)
{code}
String localRepoProperty = request.getUserProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY );
if ( localRepoProperty == null )
{
localRepoProperty = request.getSystemProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY );
}
if ( localRepoProperty != null )
{
request.setLocalRepositoryPath( localRepoProperty );
}
{code}
effectively replacing the local repository definition only if
`maven.repo.local` was defined in user or system properties.
After the commit mentioned above, the code does
{code}
request.setLocalRepositoryPath( determineLocalRepositoryPath( request )
);
...
private String determineLocalRepositoryPath( final
MavenExecutionRequest request )
{
return request.getUserProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY,
request.getSystemProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY ) // null if not found
);
}
{code}
effectively _always_ replacing the local repository definition, potentially
nulling it.
was:
We have functional tests using the latest Maven snapshots and they started
polluting the global ~/.m2/repository.
[This
commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
introduced a bug in the handling of the local repository definition.
The local repository is taken from settings
[here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
but then, before, Maven was doing (in MavenCli)
String localRepoProperty = request.getUserProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY );
if ( localRepoProperty == null )
{
localRepoProperty = request.getSystemProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY );
}
if ( localRepoProperty != null )
{
request.setLocalRepositoryPath( localRepoProperty );
}
effectively replacing the local repository definition only if
`maven.repo.local` was defined in user or system properties.
After the commit mentioned above, the code does
request.setLocalRepositoryPath( determineLocalRepositoryPath( request )
);
...
private String determineLocalRepositoryPath( final
MavenExecutionRequest request )
{
return request.getUserProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY,
request.getSystemProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY ) // null if not found
);
}
effectively _always_ replacing the local repository definition, potentially
nulling it.
> settings-defined local repository is not honored
>
>
> Key: MNG-6991
> URL: https://issues.apache.org/jira/browse/MNG-6991
> Project: Maven
> Issue Type: Bug
>Reporter: François Guillot
>Priority: Major
>
> We have functional tests using the latest Maven snapshots and they started
> polluting the global ~/.m2/repository.
> [This
> commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
> introduced a bug in the handling of the local repository definition.
> The local repository is taken from settings
> [here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
> but then, before, Maven was doing (in MavenCli)
> {code}
> String localRepoProperty = request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> if ( localRepoProperty == null )
> {
> localRepoProperty = request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> }
> if ( localRepoProperty != null )
> {
> request.setLocalRepositoryPath( localRepoProperty );
> }
> {code}
> effectively replacing the
[jira] [Updated] (MNG-6991) settings-defined local repository is not honored
[
https://issues.apache.org/jira/browse/MNG-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
François Guillot updated MNG-6991:
--
Description:
We have functional tests using the latest Maven snapshots and they started
polluting the global ~/.m2/repository.
[This
commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
introduced a bug in the handling of the local repository definition.
The local repository is taken from settings
[here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
but then, before, Maven was doing (in MavenCli)
String localRepoProperty = request.getUserProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY );
if ( localRepoProperty == null )
{
localRepoProperty = request.getSystemProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY );
}
if ( localRepoProperty != null )
{
request.setLocalRepositoryPath( localRepoProperty );
}
effectively replacing the local repository definition only if
`maven.repo.local` was defined in user or system properties.
After the commit mentioned above, the code does
request.setLocalRepositoryPath( determineLocalRepositoryPath( request )
);
...
private String determineLocalRepositoryPath( final
MavenExecutionRequest request )
{
return request.getUserProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY,
request.getSystemProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY ) // null if not found
);
}
effectively _always_ replacing the local repository definition, potentially
nulling it.
was:
We have functional tests using the latest Maven snapshots and they started
polluting the global ~/.m2/repository.
[This
commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
introduced a bug in the handling of the local repository definition.
The local repository is taken from settings
[here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
but then, before, Maven was doing (in MavenCli)
{quote}String localRepoProperty = request.getUserProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY );
if ( localRepoProperty == null )
{
localRepoProperty = request.getSystemProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY );
}
if ( localRepoProperty != null )
{
request.setLocalRepositoryPath( localRepoProperty );
}
{quote}
effectively replacing the local repository definition only if
`maven.repo.local` was defined in user or system properties.
After the commit mentioned above, the code does
{quote}request.setLocalRepositoryPath( determineLocalRepositoryPath( request )
);
...
private String determineLocalRepositoryPath( final MavenExecutionRequest
request )
{
return request.getUserProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY,
request.getSystemProperties().getProperty( MavenCli.LOCAL_REPO_PROPERTY ) //
null if not found
);
}
{quote}
effectively _always_ replacing the local repository definition, potentially
nulling it.
> settings-defined local repository is not honored
>
>
> Key: MNG-6991
> URL: https://issues.apache.org/jira/browse/MNG-6991
> Project: Maven
> Issue Type: Bug
>Reporter: François Guillot
>Priority: Major
>
> We have functional tests using the latest Maven snapshots and they started
> polluting the global ~/.m2/repository.
> [This
> commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
> introduced a bug in the handling of the local repository definition.
> The local repository is taken from settings
> [here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
> but then, before, Maven was doing (in MavenCli)
> String localRepoProperty = request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> if ( localRepoProperty == null )
> {
> localRepoProperty = request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> }
> if ( localRepoProperty != null )
> {
> request.setLocalRepositoryPath( localRepoProperty );
> }
> effectively replacing the local repository definition only if
> `maven.repo.local` was defined in user or system properties.
>
> After the commit mentioned above, the code does
>
[jira] [Updated] (MNG-6991) settings-defined local repository is not honored
[
https://issues.apache.org/jira/browse/MNG-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
François Guillot updated MNG-6991:
--
Description:
We have functional tests using the latest Maven snapshots and they started
polluting the global ~/.m2/repository.
[This
commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
introduced a bug in the handling of the local repository definition.
The local repository is taken from settings
[here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
but then, before, Maven was doing (in MavenCli)
{quote}String localRepoProperty = request.getUserProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY );
if ( localRepoProperty == null )
{
localRepoProperty = request.getSystemProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY );
}
if ( localRepoProperty != null )
{
request.setLocalRepositoryPath( localRepoProperty );
}
{quote}
effectively replacing the local repository definition only if
`maven.repo.local` was defined in user or system properties.
After the commit mentioned above, the code does
{quote}request.setLocalRepositoryPath( determineLocalRepositoryPath( request )
);
...
private String determineLocalRepositoryPath( final MavenExecutionRequest
request )
{
return request.getUserProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY,
request.getSystemProperties().getProperty( MavenCli.LOCAL_REPO_PROPERTY ) //
null if not found
);
}
{quote}
effectively _always_ replacing the local repository definition, potentially
nulling it.
was:
We have functional tests using the latest Maven snapshots and they started
polluting the global ~/.m2/repository.
[This
commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
introduced a bug in the handling of the local repository definition.
The local repository is taken from settings
[here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
but then, before, Maven was doing (in MavenCli)
{{String localRepoProperty = request.getUserProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY ) {}}
{{ if ( localRepoProperty == null ) {}}
{{ localRepoProperty = request.getSystemProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY )}}
{{ }}}
{{ if ( localRepoProperty != null ) {}}
{{ request.setLocalRepositoryPath( localRepoProperty );}}
{{ }}}
effectively replacing the local repository definition only if
`maven.repo.local` was defined in user or system properties.
After the commit mentioned above, the code does
{{request.setLocalRepositoryPath( determineLocalRepositoryPath( request ) );}}
{{...}}
{{private String determineLocalRepositoryPath( final MavenExecutionRequest
request ) {}}
{{ return request.getUserProperties().getProperty(}}
{{ MavenCli.LOCAL_REPO_PROPERTY,}}
{{ request.getSystemProperties().getProperty( MavenCli.LOCAL_REPO_PROPERTY ) //
null if not found}}
{{ );}}
{{}}}
effectively _always_ replacing the local repository definition, potentially
nulling it.
> settings-defined local repository is not honored
>
>
> Key: MNG-6991
> URL: https://issues.apache.org/jira/browse/MNG-6991
> Project: Maven
> Issue Type: Bug
>Reporter: François Guillot
>Priority: Major
>
> We have functional tests using the latest Maven snapshots and they started
> polluting the global ~/.m2/repository.
> [This
> commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
> introduced a bug in the handling of the local repository definition.
> The local repository is taken from settings
> [here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
> but then, before, Maven was doing (in MavenCli)
> {quote}String localRepoProperty = request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> if ( localRepoProperty == null )
> {
> localRepoProperty = request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> }
> if ( localRepoProperty != null )
> {
> request.setLocalRepositoryPath( localRepoProperty );
> }
> {quote}
> effectively replacing the local repository definition only if
> `maven.repo.local` was defined in user or system properties.
>
> After the commit mentioned above, the code does
> {quote}request.setLocalRepositoryPath( determineLocalRepositoryPath( request
> ) );
> ...
> private String determineLocalRepositoryPath( final MavenExecutionRequest
> request )
> {
> return
[jira] [Updated] (MNG-6991) settings-defined local repository is not honored
[
https://issues.apache.org/jira/browse/MNG-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
François Guillot updated MNG-6991:
--
Description:
We have functional tests using the latest Maven snapshots and they started
polluting the global ~/.m2/repository.
[This
commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
introduced a bug in the handling of the local repository definition.
The local repository is taken from settings
[here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
but then, before, Maven was doing (in MavenCli)
{{String localRepoProperty = request.getUserProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY ) {}}
{{ if ( localRepoProperty == null ) {}}
{{ localRepoProperty = request.getSystemProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY )}}
{{ }}}
{{ if ( localRepoProperty != null ) {}}
{{ request.setLocalRepositoryPath( localRepoProperty );}}
{{ }}}
effectively replacing the local repository definition only if
`maven.repo.local` was defined in user or system properties.
After the commit mentioned above, the code does
{{request.setLocalRepositoryPath( determineLocalRepositoryPath( request ) );}}
{{...}}
{{private String determineLocalRepositoryPath( final MavenExecutionRequest
request ) {}}
{{ return request.getUserProperties().getProperty(}}
{{ MavenCli.LOCAL_REPO_PROPERTY,}}
{{ request.getSystemProperties().getProperty( MavenCli.LOCAL_REPO_PROPERTY ) //
null if not found}}
{{ );}}
{{}}}
effectively _always_ replacing the local repository definition, potentially
nulling it.
was:
We have functional tests using the latest Maven snapshots and they started
polluting the global ~/.m2/repository.
[This
commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
introduced a bug in the handling of the local repository definition.
The local repository is taken from settings
[here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
but then, before, Maven was doing (in MavenCli)
{quote}String localRepoProperty = request.getUserProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY ) {
if ( localRepoProperty == null ) {
localRepoProperty = request.getSystemProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY )
}
if ( localRepoProperty != null ) {
request.setLocalRepositoryPath( localRepoProperty );
}
{quote}
effectively replacing the local repository definition only if
`maven.repo.local` was defined in user or system properties.
After the commit mentioned above, the code does
{quote}{{request.setLocalRepositoryPath(determineLocalRepositoryPath(request)
);}}
{{...}}
{{private String determineLocalRepositoryPath( final MavenExecutionRequest
request ) {}}
{{ return request.getUserProperties().getProperty(}}
{{ MavenCli.LOCAL_REPO_PROPERTY,}}
{{ request.getSystemProperties().getProperty( MavenCli.LOCAL_REPO_PROPERTY ) //
null if not found}}
{{ );}}
{{}}}
{quote}
effectively _always_ replacing the local repository definition, potentially
nulling it.
> settings-defined local repository is not honored
>
>
> Key: MNG-6991
> URL: https://issues.apache.org/jira/browse/MNG-6991
> Project: Maven
> Issue Type: Bug
>Reporter: François Guillot
>Priority: Major
>
> We have functional tests using the latest Maven snapshots and they started
> polluting the global ~/.m2/repository.
> [This
> commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
> introduced a bug in the handling of the local repository definition.
> The local repository is taken from settings
> [here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
> but then, before, Maven was doing (in MavenCli)
> {{String localRepoProperty = request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY ) {}}
> {{ if ( localRepoProperty == null ) {}}
> {{ localRepoProperty = request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY )}}
> {{ }}}
> {{ if ( localRepoProperty != null ) {}}
> {{ request.setLocalRepositoryPath( localRepoProperty );}}
> {{ }}}
> effectively replacing the local repository definition only if
> `maven.repo.local` was defined in user or system properties.
>
> After the commit mentioned above, the code does
> {{request.setLocalRepositoryPath( determineLocalRepositoryPath( request ) );}}
> {{...}}
> {{private String determineLocalRepositoryPath( final MavenExecutionRequest
>
[jira] [Created] (MNG-6991) settings-defined local repository is not honored
François Guillot created MNG-6991:
-
Summary: settings-defined local repository is not honored
Key: MNG-6991
URL: https://issues.apache.org/jira/browse/MNG-6991
Project: Maven
Issue Type: Bug
Reporter: François Guillot
We have functional tests using the latest Maven snapshots and they started
polluting the global ~/.m2/repository.
[This
commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
introduced a bug in the handling of the local repository definition.
The local repository is taken from settings
[here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
but then, before, Maven was doing (in MavenCli)
{quote}String localRepoProperty = request.getUserProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY ) {
if ( localRepoProperty == null ) {
localRepoProperty = request.getSystemProperties().getProperty(
MavenCli.LOCAL_REPO_PROPERTY )
}
if ( localRepoProperty != null ) {
request.setLocalRepositoryPath( localRepoProperty );
}
{quote}
effectively replacing the local repository definition only if
`maven.repo.local` was defined in user or system properties.
After the commit mentioned above, the code does
{quote}{{request.setLocalRepositoryPath(determineLocalRepositoryPath(request)
);}}
{{...}}
{{private String determineLocalRepositoryPath( final MavenExecutionRequest
request ) {}}
{{ return request.getUserProperties().getProperty(}}
{{ MavenCli.LOCAL_REPO_PROPERTY,}}
{{ request.getSystemProperties().getProperty( MavenCli.LOCAL_REPO_PROPERTY ) //
null if not found}}
{{ );}}
{{}}}
{quote}
effectively _always_ replacing the local repository definition, potentially
nulling it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSOURCES-129) The IT for MSOURCES-95 consistently fails on Linux+JDK8
[ https://issues.apache.org/jira/browse/MSOURCES-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kanters updated MSOURCES-129: Description: As can be seen on [Jenkins|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-source-plugin/job/master/], the integration test for MSOURCES-95 fails consistently and has been from the introduction of the IT. I was able to trace this back to a bug in the JDK which the plexus-archiver unfortunately affects. The fix in plexus-archiver has been proposed: [https://github.com/codehaus-plexus/plexus-archiver/pull/149] After the PR has been merged in and a new version has been released, we should upgrade the plexus-archiver dependency in maven-source-plugin to fix it. was: As can be seen on [Jenkins|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-source-plugin/job/master/], the integration test for MSOURCES-95 fails consistently and has been from the introduction of the IT. I was able to trace this back to a bug in the JDK which the plexus-archiver unfortunately affects. The fix in plexus-archiver has been proposed: [https://github.com/codehaus-plexus/plexus-archiver/pull/149]. After the PR has been merged in and a new version has been released, we should upgrade the plexus-archiver dependency in maven-source-plugin to fix it. > The IT for MSOURCES-95 consistently fails on Linux+JDK8 > --- > > Key: MSOURCES-129 > URL: https://issues.apache.org/jira/browse/MSOURCES-129 > Project: Maven Source Plugin > Issue Type: Bug >Reporter: Martin Kanters >Priority: Major > > As can be seen on > [Jenkins|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-source-plugin/job/master/], > the integration test for MSOURCES-95 fails consistently and has been from > the introduction of the IT. > I was able to trace this back to a bug in the JDK which the plexus-archiver > unfortunately affects. > The fix in plexus-archiver has been proposed: > [https://github.com/codehaus-plexus/plexus-archiver/pull/149] > After the PR has been merged in and a new version has been released, we > should upgrade the plexus-archiver dependency in maven-source-plugin to fix > it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSOURCES-129) The IT for MSOURCES-95 consistently fails on Linux+JDK8
[ https://issues.apache.org/jira/browse/MSOURCES-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201938#comment-17201938 ] Martin Kanters commented on MSOURCES-129: - Thanks [~michaelboyles], should be fixed now. > The IT for MSOURCES-95 consistently fails on Linux+JDK8 > --- > > Key: MSOURCES-129 > URL: https://issues.apache.org/jira/browse/MSOURCES-129 > Project: Maven Source Plugin > Issue Type: Bug >Reporter: Martin Kanters >Priority: Major > > As can be seen on > [Jenkins|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-source-plugin/job/master/], > the integration test for MSOURCES-95 fails consistently and has been from > the introduction of the IT. > I was able to trace this back to a bug in the JDK which the plexus-archiver > unfortunately affects. > The fix in plexus-archiver has been proposed: > [https://github.com/codehaus-plexus/plexus-archiver/pull/149] > After the PR has been merged in and a new version has been released, we > should upgrade the plexus-archiver dependency in maven-source-plugin to fix > it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSOURCES-129) The IT for MSOURCES-95 consistently fails on Linux+JDK8
[ https://issues.apache.org/jira/browse/MSOURCES-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders updated MSOURCES-129: - Description: As can be seen on [Jenkins|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-source-plugin/job/master/], the integration test for MSOURCES-95 fails consistently and has been from the introduction of the IT. I was able to trace this back to a bug in the JDK which the plexus-archiver unfortunately affects. The fix in plexus-archiver has been proposed: [https://github.com/codehaus-plexus/plexus-archiver/pull/149]. After the PR has been merged in and a new version has been released, we should upgrade the plexus-archiver dependency in maven-source-plugin to fix it. was: As can be seen on [Jenkins|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-source-plugin/job/master/], the integration test for MSOURCES-95 fails consistently and has been from the introduction of the IT. I was able to trace this back to a bug in the JDK which the plexus-archiver unfortunately affects. The fix in plexus-archiver has been proposed: [https://github.com/codehaus-plexus/plexus-archiver/pull/149.] After the PR has been merged in and a new version has been released, we should upgrade the plexus-archiver dependency in maven-source-plugin to fix it. > The IT for MSOURCES-95 consistently fails on Linux+JDK8 > --- > > Key: MSOURCES-129 > URL: https://issues.apache.org/jira/browse/MSOURCES-129 > Project: Maven Source Plugin > Issue Type: Bug >Reporter: Martin Kanters >Priority: Major > > As can be seen on > [Jenkins|https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-source-plugin/job/master/], > the integration test for MSOURCES-95 fails consistently and has been from > the introduction of the IT. > I was able to trace this back to a bug in the JDK which the plexus-archiver > unfortunately affects. > The fix in plexus-archiver has been proposed: > [https://github.com/codehaus-plexus/plexus-archiver/pull/149]. > After the PR has been merged in and a new version has been released, we > should upgrade the plexus-archiver dependency in maven-source-plugin to fix > it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
