[jira] [Commented] (MSHADE-284) Shaded test JARs are always empty
[
https://issues.apache.org/jira/browse/MSHADE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434412#comment-16434412
]
Sean Busbey commented on MSHADE-284:
Hi [~peterdm]! I'm not a committer on the project, but in my experience you'll
need to add a test that can show the impact of your fix (i.e. that fails
without it and succeeds with it). AFAICT that's almost always a jira-specific
it added in {{src/it/}}
> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
> Attachments: shadeTestJar.patch
>
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an
> empty test JAR. This has been noticed by others, see for example Steve K's
> answer [on
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
> but people have reverted to other hacks and workarounds to overcome this
> (e.g. use a different plugin).
> Scenario:
> # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole
> purpose to make an uber JAR for the combination of the first two modules.
> {{uber}} itself has no sources.
> # Both modules have both {{jar}} and {{test-jar}} artifacts.
> # Configure the {{maven-shade-plugin}} in the {{uber}} module with the
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
> # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and
> {{impl.jar}}.
> # Content of {{uber-tests.jar}} is the aggregate content of
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
> # Content of {{uber.jar}} is as expected.
> # {{uber-tests.jar}} is empty.
> Root cause:
> * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is
> buggy and incomplete.
> * The call to {{processArtifactSelectors}} on line 425 doesn't pass the
> {{testArtifacts}}, so they are never correctly filled in.
> * The implementation of {{processArtifactSelectors}} doesn't deal with test
> JARs at all and has to be extended to support them.
> * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste
> job, and in 5 years nobody took the time to report or fix it. Amazing.
> Anyway, you can find my proposed fix in attachment: [^shadeTestJar.patch]. I
> have tested it manually on my project and it works.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-444) Add an 'aggregated-no-fork' goal
[
https://issues.apache.org/jira/browse/MJAVADOC-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387264#comment-16387264
]
Sean Busbey commented on MJAVADOC-444:
--
PR has now been updated with docs and an it, modeled after the work for
MJAVADOC-369 which added the no-fork versions of the javadoc and javadoc-test
goals.
> Add an 'aggregated-no-fork' goal
>
>
> Key: MJAVADOC-444
> URL: https://issues.apache.org/jira/browse/MJAVADOC-444
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.10.3
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently you can call maven-javadoc-plugin via {{mvn clean package
> javadoc:aggregate}} which results in deleting all previously created
> artifacts in {{target}} folder. So it would be helpful having a separate goal
> without forking the life cycle.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-444) Add an 'aggregated-no-fork' goal
[
https://issues.apache.org/jira/browse/MJAVADOC-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16382588#comment-16382588
]
Sean Busbey commented on MJAVADOC-444:
--
linking a PR I put together that implements this.
> Add an 'aggregated-no-fork' goal
>
>
> Key: MJAVADOC-444
> URL: https://issues.apache.org/jira/browse/MJAVADOC-444
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.10.3
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently you can call maven-javadoc-plugin via {{mvn clean package
> javadoc:aggregate}} which results in deleting all previously created
> artifacts in {{target}} folder. So it would be helpful having a separate goal
> without forking the life cycle.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-490) Aggregate goal fails if artifacts not installed
[
https://issues.apache.org/jira/browse/MJAVADOC-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16382320#comment-16382320
]
Sean Busbey commented on MJAVADOC-490:
--
using maven-site-plugin version 3.4, I still have this problem but only for
test-jar intra-project dependencies. specifically, those dependencies are test
scope but the forked compile build for the main aggregate for some reason still
tries to find them.
> Aggregate goal fails if artifacts not installed
> ---
>
> Key: MJAVADOC-490
> URL: https://issues.apache.org/jira/browse/MJAVADOC-490
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Shannon Carey
>Priority: Major
>
> Using the javadoc aggregate report causes release:perform to fail if the
> modules were not already installed into the local repository.
> During release:perform's execution of "deploy site-deploy", when
> report:aggregate runs it appears to fork executions on all of the reactor
> modules ("Forking mymodule 0.0.1"). When it gets to a module which has a
> dependency on another module, it cannot find it locally (since that module
> has not yet been installed), tries to download it from Nexus, and ultimately
> fails with "... Could not resolve dependencies for project ... The following
> artifacts could not be resolved ..."
> The only way I can think of to fix this is to add "install" to the
> "preparationGoals" of release:prepare so that the modules are already
> installed before release:perform is run. However, this violates the
> self-containment of release:perform's deploy build, and is generally
> confusing and difficult to diagnose.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-444) Add an 'aggregated-no-fork' goal
[
https://issues.apache.org/jira/browse/MJAVADOC-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16382308#comment-16382308
]
Sean Busbey commented on MJAVADOC-444:
--
this would help immensely for our builds over in Apache HBase. we build 4
aggregate docs (user and internal facing for main and test) and right now that
means 4 additional times forking a build that we don't need.
> Add an 'aggregated-no-fork' goal
>
>
> Key: MJAVADOC-444
> URL: https://issues.apache.org/jira/browse/MJAVADOC-444
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
>Affects Versions: 2.10.3
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently you can call maven-javadoc-plugin via {{mvn clean package
> javadoc:aggregate}} which results in deleting all previously created
> artifacts in {{target}} folder. So it would be helpful having a separate goal
> without forking the life cycle.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASFRES-5) Support additional boilerplate in NOTICE file
[ https://issues.apache.org/jira/browse/MASFRES-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14698582#comment-14698582 ] Sean Busbey commented on MASFRES-5: --- you can already do this by placing a NOTICE file in the src/main/appended-resources directory. specifically, in src/main/appended-resources/META-INF/NOTICE. If you make it NOTICE.vm then it will also be a velocity template. in either case it will be appended to the contents of the NOTICE from the resource bundle. Support additional boilerplate in NOTICE file - Key: MASFRES-5 URL: https://issues.apache.org/jira/browse/MASFRES-5 Project: Apache Maven Resource Bundles Issue Type: Improvement Components: apache-jar-resource-bundle, apache-jar-txt-resource-bundle Affects Versions: apache-jar-resource-bundle-1.4 Reporter: Olivier Lamy (*$^¨%`£) The pom includes using the maven-remote-resources-plugin to get the resourceBundle org.apache:apache-jar-resource-bundle:1.4 which has the Standard LICENSE, NOTICE, and DEPENDENCIES .vm files. The DEPENDENCIES.vm file has already the function at the end to add user-defined boilerplate: #if($postDepListText) $postDepListText #end It would be very useful to us to have similar code at the end of the NOTICE.vm file: #if($project.properties.postNoticeText) $project.properties.postNoticeText #end The use case is we have many files which have the same copyright notice moved to the NOTICES file, and would like to automatically have this included. By doing this, we can define a common parent-pom for these files, which defines the postNoticeText property, and have it included. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-382) Review IT failure on Windows
[
https://issues.apache.org/jira/browse/MASSEMBLY-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14650134#comment-14650134
]
Sean Busbey commented on MASSEMBLY-382:
---
I ran into what I believe is this issue while attempting to use the assembly
plugin to build proper NOTICE files for Apache HBase. Can I get sufficient
karma to edit the issue to clarify?
Review IT failure on Windows
Key: MASSEMBLY-382
URL: https://issues.apache.org/jira/browse/MASSEMBLY-382
Project: Maven Assembly Plugin
Issue Type: Task
Affects Versions: 2.2-beta-3
Reporter: Benjamin Bentmann
Priority: Minor
Attachments: build.log
I observe the following IT failure on my WinXP box as well as on [Hudson's
Vista
box|https://grid.sonatype.org/ci/job/plugins-IT-with-maven-2.0.x/jdk=1.5,label=windows/53/console]:
{noformat}
[INFO] Building:
container-descriptors\custom-containerDescriptorHandler\pom.xml
[INFO] ...FAILED. The post-build script returned false.
{noformat}
Attached is the {{build.log}} of this IT.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MPOM-66) The ASF global pom should upgrade SUREFIRE@2.18.1
[
https://issues.apache.org/jira/browse/MPOM-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated MPOM-66:
Attachment: MPOM-66.1.patch.txt
patch for trunk. tested locally with {{mvn install}} and updating downstream
accumulo project from 16 to 17-SNAPSHOT (it relies on the asf pom to set the
version).
The ASF global pom should upgrade SUREFIRE@2.18.1
-
Key: MPOM-66
URL: https://issues.apache.org/jira/browse/MPOM-66
Project: Maven POMs
Issue Type: Bug
Components: asf
Affects Versions: ASF-16
Reporter: Tibor Digana
Fix For: ASF-17
Attachments: MPOM-66.1.patch.txt
The ASF global pom should upgrade SUREFIRE@2.18.1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
