[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_r494624818
##
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
[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=17201781#comment-17201781 ] Michael Boyles commented on MSOURCES-129: - The link for the PR is broken because the period is included. Real link is [https://github.com/codehaus-plexus/plexus-archiver/pull/149] > 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 ] 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. > 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] [Created] (MSOURCES-129) The IT for MSOURCES-95 consistently fails on Linux+JDK8
Martin Kanters created MSOURCES-129: --- Summary: 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 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-6990) Build order not set corectly
[ https://issues.apache.org/jira/browse/MNG-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kanters closed MNG-6990. --- Assignee: Martin Kanters Resolution: Not A Bug > Build order not set corectly > > > Key: MNG-6990 > URL: https://issues.apache.org/jira/browse/MNG-6990 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.3.9, 3.5.3, 3.6.3 > Environment: OS: > Kubuntu 18.04 LTS > JDK: > openjdk version "1.8.0_265" > OpenJDK Runtime Environment (build 1.8.0_265-8u265-b01-0ubuntu2~18.04-b01) > OpenJDK 64-Bit Server VM (build 25.265-b01, mixed mode) > Projects have been tested with Eclipse Photon, 2020-06, 2020-09 >Reporter: Stefano Cazzola >Assignee: Martin Kanters >Priority: Major > Attachments: test-no-parent.zip, test-with-parent-fixed.zip, > test-with-parent.zip > > > It seems that Maven is not able to decide the correct build order when two > projects extend the same parent but one has a dependency on the other. > More precisely, it seems that whenever projects extend the same parent, they > are built following the alphabetical order: this means that if project A > depends on project B, it is nonetheless built before B, generating > compilation error. > I've created some very simple example I'm attaching to this ticket, one using > a parent (which does not compile), one not (which does compile). > Please note that I tested specifically against the versions I mentioned. I > would not be able to say if in previous versions the build order was detected > corretcly, or if it was resolved in some intermediate version. > Please note also that I am not able to tell if it's a Maven or Eclipse issue. > For this reason I'm filing the same ticket to the Eclipse Team. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6990) Build order not set corectly
[ https://issues.apache.org/jira/browse/MNG-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201744#comment-17201744 ] Martin Kanters commented on MNG-6990: - Thanks for the linking the Eclipse ticket link, it sounds like a very peculiar issue, good luck! I'll close the ticket now. > Build order not set corectly > > > Key: MNG-6990 > URL: https://issues.apache.org/jira/browse/MNG-6990 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.3.9, 3.5.3, 3.6.3 > Environment: OS: > Kubuntu 18.04 LTS > JDK: > openjdk version "1.8.0_265" > OpenJDK Runtime Environment (build 1.8.0_265-8u265-b01-0ubuntu2~18.04-b01) > OpenJDK 64-Bit Server VM (build 25.265-b01, mixed mode) > Projects have been tested with Eclipse Photon, 2020-06, 2020-09 >Reporter: Stefano Cazzola >Priority: Major > Attachments: test-no-parent.zip, test-with-parent-fixed.zip, > test-with-parent.zip > > > It seems that Maven is not able to decide the correct build order when two > projects extend the same parent but one has a dependency on the other. > More precisely, it seems that whenever projects extend the same parent, they > are built following the alphabetical order: this means that if project A > depends on project B, it is nonetheless built before B, generating > compilation error. > I've created some very simple example I'm attaching to this ticket, one using > a parent (which does not compile), one not (which does compile). > Please note that I tested specifically against the versions I mentioned. I > would not be able to say if in previous versions the build order was detected > corretcly, or if it was resolved in some intermediate version. > Please note also that I am not able to tell if it's a Maven or Eclipse issue. > For this reason I'm filing the same ticket to the Eclipse Team. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-428) Documentation regarding useIncrementalCompilation not very useful
[ https://issues.apache.org/jira/browse/MCOMPILER-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201706#comment-17201706 ] Thomas Bracher commented on MCOMPILER-428: -- That would have been an improvement, but unfortunately the current implementation does not have this optimization, maybe the documentation could only mention the safety in reproducibility of the build rather than going into the details. But I could not find a proper way to phrase without this. Maybe if the optimization is implemented, the documentation should be updated. > Documentation regarding useIncrementalCompilation not very useful > - > > Key: MCOMPILER-428 > URL: https://issues.apache.org/jira/browse/MCOMPILER-428 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Thomas Bracher >Priority: Minor > Labels: documentation > > As of today, maven-compiler-plugin documentation for > useIncrementalCompilation says: "to enable/disable incrementation compilation > feature". Since there is no documentation of said feature, users will have to > either: > 1) take a guess at how the feature behaves > 2) painfully read the plugin code to understand what it does > This is less than optimal and lead to misunderstanding, like this comment > https://issues.apache.org/jira/browse/MCOMPILER-205?focusedCommentId=14428972=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14428972 > > So far the most explicit documentation I have found is in answer of a > stackoverflow issue: https://stackoverflow.com/a/49700942 > I think it would benefit a lot of users to understand the implication of both > options of this flag. I am trying to submit a PR providing an example of text. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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] elharo opened a new pull request #14: [MEAR-285] Prefer Apache commons IO dependencies
elharo opened a new 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
[jira] [Commented] (MNG-5984) Maven core extension resolution ignores repositories from activeByDefault profiles in settings.xml
[
https://issues.apache.org/jira/browse/MNG-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201680#comment-17201680
]
Slawomir Jaranowski commented on MNG-5984:
--
I think, cause problem for this is that evaluation for profile activation is
done during project model building.
It happen after settings process and after extensions is loaded.
During settings process only activeProfiles tags is regognized.
So repositories from profile settings is not included.
> Maven core extension resolution ignores repositories from activeByDefault
> profiles in settings.xml
> --
>
> Key: MNG-5984
> URL: https://issues.apache.org/jira/browse/MNG-5984
> Project: Maven
> Issue Type: Bug
> Components: Profiles, Settings
>Affects Versions: 3.3.9
>Reporter: Gabriël Konat
>Priority: Minor
> Fix For: 3.7.x-candidate
>
>
> When building a project with a core extension in {{.mvn/extensions.xml}},
> where the core extension is not installed locally but needs to be retrieved
> from a remote repository, profiles from {{settings.xml}} with repositories
> which are {{true}}, are ignored, failing
> the resolution of the core extension.
> If the profile is activated from within an {{activeProfiles}} section, they
> are not ignored and resolution succeeds.
> Concrete example:
> {code:xml|title=.mvn/extensions.xml}
>
>
>
> org.metaborg
> spoofax-maven-plugin-pomless
> 2.0.0-SNAPSHOT
>
>
> {code}
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
>
>
> add-metaborg-snapshot-repos
>
> true
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> {code}
> Results in failed resolution:
> {code:title=mvn -Dmaven.repo.local=.cleanmvnrepo clean verify}
> [WARNING] The POM for
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT is missing, no
> dependency information available
> [WARNING] Failed to read extensions descriptor
> /Users/gohla/spoofax/master/repo/spoofax-releng/sdf/org.metaborg.meta.lang.sdf/.mvn/extensions.xml:
> Plugin org.metaborg:spoofax-maven-plugin-pomless:2.0.0-SNAPSHOT or one of
> its dependencies could not be resolved: Could not find artifact
> org.metaborg:spoofax-maven-plugin-pomless:jar:2.0.0-SNAPSHOT
> {code}
> Whereas with the following settings file it succeeds to resolve the core
> extension:
> {code:xml|title=~/.m2/settings.xml}
>
>xmlns="http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;
> >
>
>
> add-metaborg-snapshot-repos
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
> metaborg-snapshot-repo
>
> http://artifacts.metaborg.org/content/repositories/snapshots/
>
> false
>
>
> true
>
>
>
>
>
>
> add-metaborg-snapshot-repos
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-stage-plugin] michaelboyles opened a new pull request #2: [MSTAGE-24] - set minimum maven version to 3.1
michaelboyles opened a new pull request #2: URL: https://github.com/apache/maven-stage-plugin/pull/2 https://issues.apache.org/jira/browse/MSTAGE-24 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
[jira] [Comment Edited] (MCOMPILER-425) Compiler argument with newline treated as multiple arguments in fork mode
[
https://issues.apache.org/jira/browse/MCOMPILER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201501#comment-17201501
]
Michael Boyles edited comment on MCOMPILER-425 at 9/24/20, 12:42 PM:
-
Shouldn't you be doing this? They're on different lines, which is what you
wanted.
{code:java}
-XDcompilePolicy=simple
-Xplugin:ErrorProne
-Xep:ObjectToString:ERROR
{code}
You say that it works when not forking, but these parameters are only used
when forking. As per [the
docs|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs]
"Sets the arguments to be passed to the compiler if {{fork}} is set to
{{true"}}
So if you think that these params are being applied to non-forked version, you
are mistaken. (I doubled-checked with latest build to see whether the docs were
accurate, by passing a spurious compiler parameter, and it was indeed not
applied)
was (Author: michaelboyles):
Shouldn't you be doing this? They're on different lines, which is what you
wanted.
-XDcompilePolicy=simple-Xplugin:ErrorProne
-Xep:ObjectToString:ERROR
You say that it works when not forking, but these parameters are only used when
forking. As per [the
docs|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs]
"Sets the arguments to be passed to the compiler if {{fork}} is set to
{{true"}}
So if you think that these params are being applied to non-forked version, you
are mistaken. (I doubled-checked with latest build to see whether the docs were
accurate, by passing a spurious compiler parameter, and it was indeed not
applied)
> Compiler argument with newline treated as multiple arguments in fork mode
> -
>
> Key: MCOMPILER-425
> URL: https://issues.apache.org/jira/browse/MCOMPILER-425
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: David Phillips
>Priority: Major
>
> In the below example, we want to pass the second argument as a single
> argument to the compiler, but we add newlines in the XML for readability.
> This works correctly when not forking, but when forking, the argument is
> treated as multiple arguments.
> {code:xml}
>
> true
>
> -XDcompilePolicy=simple
>
> -Xplugin:ErrorProne
> -Xep:ObjectToString:ERROR
>
>
>
>
> com.google.errorprone
> error_prone_core
> 2.4.0
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-425) Compiler argument with newline treated as multiple arguments in fork mode
[
https://issues.apache.org/jira/browse/MCOMPILER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201501#comment-17201501
]
Michael Boyles commented on MCOMPILER-425:
--
Shouldn't you be doing this? They're on different lines, which is what you
wanted.
-XDcompilePolicy=simple-Xplugin:ErrorProne
-Xep:ObjectToString:ERROR
You say that it works when not forking, but these parameters are only used when
forking. As per [the
docs|https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerArgs]
"Sets the arguments to be passed to the compiler if {{fork}} is set to
{{true"}}
So if you think that these params are being applied to non-forked version, you
are mistaken. (I doubled-checked with latest build to see whether the docs were
accurate, by passing a spurious compiler parameter, and it was indeed not
applied)
> Compiler argument with newline treated as multiple arguments in fork mode
> -
>
> Key: MCOMPILER-425
> URL: https://issues.apache.org/jira/browse/MCOMPILER-425
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: David Phillips
>Priority: Major
>
> In the below example, we want to pass the second argument as a single
> argument to the compiler, but we add newlines in the XML for readability.
> This works correctly when not forking, but when forking, the argument is
> treated as multiple arguments.
> {code:xml}
>
> true
>
> -XDcompilePolicy=simple
>
> -Xplugin:ErrorProne
> -Xep:ObjectToString:ERROR
>
>
>
>
> com.google.errorprone
> error_prone_core
> 2.4.0
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1834) Make warnings for skipped tests configurable
[
https://issues.apache.org/jira/browse/SUREFIRE-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201476#comment-17201476
]
Michael Boyles commented on SUREFIRE-1834:
--
Happy to work on this. A new parameter for the test goal, something like
false
defaulting to the current behaviour: true.
That is, if someone gives the go-ahead that this is indeed a desirable feature.
Seems fair enough to me
> Make warnings for skipped tests configurable
>
>
> Key: SUREFIRE-1834
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1834
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Martin Winandy
>Priority: Major
>
> Currently, Surefire outputs warnings for skipped tests.
> For example:
> {noformat}
> [WARNING] Tests run: 4, Failures: 0, Errors: 0, Skipped: 2, Time elapsed:
> 0.037 s - in org.tinylog.core.runtime.LegacyStackTraceAccessTest
> [WARNING] Tests run: 62, Failures: 0, Errors: 0, Skipped: 2
> {noformat}
> I have some platform depending tests, which are enabled or disabled depending
> on the actual platform. It would be great, if a property could be introduced
> to disable warnings for skipped tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-javadoc-plugin] michaelboyles opened a new pull request #62: [MJAVADOC-660] - No periods without complete sentences in @param fixes
michaelboyles opened a new pull request #62: URL: https://github.com/apache/maven-javadoc-plugin/pull/62 https://issues.apache.org/jira/browse/MJAVADOC-660 Removed periods from @param and @return, as per Oracle guidelines --- Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MJAVADOC) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MJAVADOC-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJAVADOC-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 -Prun-its` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). 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
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] [Updated] (MEAR-285) EarMojo fails to handle assorted IO Errors
[ https://issues.apache.org/jira/browse/MEAR-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MEAR-285: --- Fix Version/s: 3.1.0 > EarMojo fails to handle assorted IO Errors > -- > > Key: MEAR-285 > URL: https://issues.apache.org/jira/browse/MEAR-285 > Project: Maven Ear Plugin > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 3.1.0 > > > including failure to create work directory, I/O errors when writing files, > and closing input streams used to read manifests -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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?
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
