[jira] [Created] (SUREFIRE-2205) Mojo documentation links are broken
Daniel Huss created SUREFIRE-2205: - Summary: Mojo documentation links are broken Key: SUREFIRE-2205 URL: https://issues.apache.org/jira/browse/SUREFIRE-2205 Project: Maven Surefire Issue Type: Bug Components: documentation Affects Versions: 3.2.1 Reporter: Daniel Huss Attachments: image-2023-10-24-16-45-11-220.png To reproduce: # Go to [https://maven.apache.org/surefire/maven-surefire-plugin/] # Click link to "goals" or "surefire:test" Expected: Goals or goal documentation is shown. Actual: !image-2023-10-24-16-45-11-220.png|width=299,height=182! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-707) Plugin won't work if Automatic-Module-Name is used
[ https://issues.apache.org/jira/browse/MJAVADOC-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17543556#comment-17543556 ] Daniel Huss commented on MJAVADOC-707: -- For people who stumble upon this issue: * You might've searched for the following error message, so I'll just paste the keywords: Maven Javadoc Plugin Unable to derive module descriptor * As a temporary workaround, try relocating the maven-javadoc-plugin execution to the "process-classes" phase, while also relocating the execution of whatever-sets-the-manifest-entry (in my case: maven-bundle-plugin) to a later phase such as "prepare-package" :-/ > Plugin won't work if Automatic-Module-Name is used > -- > > Key: MJAVADOC-707 > URL: https://issues.apache.org/jira/browse/MJAVADOC-707 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 3.3.1, 3.3.2, 3.4.0 >Reporter: Christopher Tubbs >Priority: Critical > > Using Automatic-Module-Name in a manifest (an intermediate step to help > transition to using modules) prevents this plugin from adding the necessary > dependencies to the class path, so it can build javadocs. > maven-compiler-plugin seems to work fine, as does surefire and all the others > when Automatic-Module-Name entries appear in a project's jar manifests. > However, this plugin, as of 3.3.1, still does not work correctly with these. > Instead of using the traditional class path, this plugin seems to force > treating the project as a module, even though it does not have any > module-info.java files, and most of its dependencies have not transitioned to > using modules. > Here's a pull request that demonstrates adding the Automatic-Module-Name to > the manifest for a multi-module (Maven module) project, that fails on the > javadoc plugin: > https://github.com/apache/accumulo/pull/2498 ; both javadoc:aggregate and > javadoc:jar are known to fail. I did not test with any other mojos. > Not supporting this feature holds all projects back from being able to > transition to modules over time. > http://branchandbound.net/blog/java/2017/12/automatic-module-name/ > https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#automatic-modules -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[
https://jira.codehaus.org/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=360589#comment-360589
]
Daniel Huss edited comment on MEAR-166 at 1/3/15 1:55 PM:
--
A minimalist's approach
Changes:
* Modified skinny-wars test case
* Modified {{EarMojo::changeManifestClasspath()}}: Now indiscriminately does
its thing for all other modules, not just instances of {{JarModule}}.
** This means that when skinny WARs are enabled, WARs will end up on the
{{Class-Path}} manifest entry of all other modules, including other WARs.
Not what I'd call a good solution. However, as I've recently lost all interest
in the ear plugin, this is where my participation ends. Bye!
*slowly backs out of the room*
Edit: Looks like I've re-discovered my old account
was (Author: dhuss):
A minimalist's approach
Changes:
* Modified skinny-wars test case
* Modified {{EarMojo::changeManifestClasspath()}}: Now indiscriminately does
its thing for all other modules, not just instances of {{JarModule}}.
** This means that when skinny WARs are enabled, WARs will end up on the
{{Class-Path}} manifest entry of all other modules, including other WARs.
Not what I'd call a good solution. However, as I've recently lost all interest
in the ear plugin, this is where my participation ends. Bye!
*slowly backs out of the room*
> 'skinnyWar' doesn't work well with dependencies of type 'ejb'
> -
>
> Key: MEAR-166
> URL: https://jira.codehaus.org/browse/MEAR-166
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.8, 2.9
> Environment: many different environments I've verified this on
>Reporter: Michal Michalski
>Priority: Minor
> Labels: contributers-welcome
> Fix For: more-investigation
>
> Attachments: MEAR-166-patch.diff
>
>
> It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it
> does left 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies
> exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic
> trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's
> dependencies should go to EAR's lib.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[
https://jira.codehaus.org/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Huss updated MEAR-166:
-
Attachment: MEAR-166-patch.diff
A minimalist's approach
Changes:
* Modified skinny-wars test case
* Modified {{EarMojo::changeManifestClasspath()}}: Now indiscriminately does
its thing for all other modules, not just instances of {{JarModule}}.
** This means that when skinny WARs are enabled, WARs will end up on the
{{Class-Path}} manifest entry of all other modules, including other WARs.
Not what I'd call a good solution. However, as I've recently lost all interest
in the ear plugin, this is where my participation ends. Bye!
*slowly backs out of the room*
> 'skinnyWar' doesn't work well with dependencies of type 'ejb'
> -
>
> Key: MEAR-166
> URL: https://jira.codehaus.org/browse/MEAR-166
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.8, 2.9
> Environment: many different environments I've verified this on
>Reporter: Michal Michalski
>Priority: Minor
> Labels: contributers-welcome
> Fix For: more-investigation
>
> Attachments: MEAR-166-patch.diff
>
>
> It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it
> does left 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies
> exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic
> trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's
> dependencies should go to EAR's lib.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-166) 'skinnyWar' doesn't work well with dependencies of type 'ejb'
[
https://jira.codehaus.org/browse/MEAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356090#comment-356090
]
Daniel Huss commented on MEAR-166:
--
Would love to see this fixed :-)
Here is my use case:
=== in web module ===
{code:java}
@Path("/hello")
public class HelloResource
{
@Inject
private HelloService helloService;
...
}
{code}
I think this simple use case is _impossible_ to get right with
ejb-client because the whole ejb-client mechanism is fundamentally
flawed:
* Depending on ejb-client artifacts will still pull all dependencies of the EJB
implementation into the corresponding dependency scope.
* If separating API from EJB implementation is the purpose of the ejb-client
feature, the EJB artifact should depend on the API artifact and all API classes
should be stripped from the EJB artifact. Since both ejb-client and ejb
originate from the same POM, this is not possible (I think).
** So we end up with a ejb artifact plus a ejb-client
artifact, both containing all API classes. In a JEE container such as JBoss AS
7, this will easily lead to the following situation:
**# The EJB implementaiton sees API class "HelloService" loaded by class loader
"A"
**# The API consumer sees API class "HelloService" loaded by class loader "B"
**# A.HelloService is not equal to B.HelloService
**# CDI fails because of unsatisfied dependencies
In my opinion ejb-client should never be used as a maven
dependency for those reasons. If I could, I'd simply avoid using the
maven-ejb-plugin by creating two plain jar projects.
However, this is not an option because the ear plugin requires ejb
for s (and I do like the ear plugin :-) )
> 'skinnyWar' doesn't work well with dependencies of type 'ejb'
> -
>
> Key: MEAR-166
> URL: https://jira.codehaus.org/browse/MEAR-166
> Project: Maven Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.8, 2.9
> Environment: many different environments I've verified this on
>Reporter: Michal Michalski
>Priority: Minor
> Fix For: more-investigation
>
>
> It seems that 'skinnyWar' works OK with dependencies of type 'jar', but it
> does left 'ejb' dependencies in WEB-INF/lib. Finally, these dependencies
> exist both in EAR's lib dir and WEB-INF/lib within WAR, when using classic
> trick with both 'war'-type and 'pom'-type dependency to WAR, so all WAR's
> dependencies should go to EAR's lib.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] Commented: (MASSEMBLY-285) regression: duplicate files added to the assembly
[
http://jira.codehaus.org/browse/MASSEMBLY-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=246776#action_246776
]
Daniel Huss commented on MASSEMBLY-285:
---
Why has this been flagged as fixed? If two filesets contain files with
identical names, I still get those awkward duplicates (2.2 beta5 and final):
{code:xml}
${project.build.directory}/deps/indexer
glassfishv3/glassfish/domains/domain1/autodeploy/jobservice/WEB-INF/lib
${project.build.directory}/deps/jobservice
glassfishv3/glassfish/domains/domain1/autodeploy/jobservice
{code}
!http://img802.imageshack.us/img802/1585/clipboard01iz.jpg!
> regression: duplicate files added to the assembly
> -
>
> Key: MASSEMBLY-285
> URL: http://jira.codehaus.org/browse/MASSEMBLY-285
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Brett Porter
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.2-beta-3
>
>
> I found that it was possible to add a file twice to the assembly through
> different filesets (a zip file) so that when it extracted it prompted for
> overwrite.
> It should error out or collapse the entries (as 2.1 did).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
