Re: [I] [MWAR-73] war overlay mechanism does not work for classes [maven-war-plugin]

2025-06-12 Thread via GitHub


jira-importer commented on issue #247:
URL: 
https://github.com/apache/maven-war-plugin/issues/247#issuecomment-2967855629

   **[Mark 
Struberg](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=struberg)**
 commented
   
   MWAR-131 implements the part of handling the jared classes as attached 
artifact.
   


-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] [MWAR-73] war overlay mechanism does not work for classes [maven-war-plugin]

2025-06-12 Thread via GitHub


jira-importer commented on issue #247:
URL: 
https://github.com/apache/maven-war-plugin/issues/247#issuecomment-2967855618

   **[Michael 
Horwitz](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=horwitzm)**
 commented
   
   I am attaching a patch for the wr plugin to include the functionality from 
the Warpath plugin developed for the AppFuse project to solve this issue. We 
have been using the warpath plugin on the AppFuse project for a while now, and 
it seems stable. All documentation on the warpath feature is included within 
the patch as .apt files.
   
   To summarise:
   
   1) All classes from WEB-INF/lib are extracted to a jar for inclusion as a 
system scope dependency on the project. As a result the classes are available 
during compile, but are not included in the final war.
   2) A new artifact type, warpath, is defined by the plugin which allows users 
to selectively decide which war dependencies to include on the classpath and 
which not. This prevents changes to the behaviour of the plugin which may 
affect existing projects which depend on war overlay.
   3) Projects are correctly set up for Idea and Eclipse.
   
   Outstanding issues:
   1) This will not work if the war sources have been included as a jar file 
(archiveClasses flag is set). This should be trivial to fix.
   2) It does not solve the war overlay ordering problem.
   
   


-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] [MWAR-73] war overlay mechanism does not work for classes [maven-war-plugin]

2025-06-12 Thread via GitHub


jira-importer commented on issue #247:
URL: 
https://github.com/apache/maven-war-plugin/issues/247#issuecomment-2967855626

   **[Dominique 
Jean-Prost](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=djeanprost)**
 commented
   
   any chance this bug/feature could be officialy fixed ? As it is very 
interesting and that patchs are provided, it should be quite easy to release 
it, shouldn'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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] [MWAR-73] war overlay mechanism does not work for classes [maven-war-plugin]

2025-06-12 Thread via GitHub


jira-importer commented on issue #247:
URL: 
https://github.com/apache/maven-war-plugin/issues/247#issuecomment-2967855637

   **[Michael 
Osipov](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=michael-o)**
 commented
   
   Please refer to 
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
 if you're wondering why this issue was closed out.
   
   Assignee, if you think you can fix this bug anytime soon, please reopen and 
proceed appropriately.
   


-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] [MWAR-73] war overlay mechanism does not work for classes [maven-war-plugin]

2025-06-12 Thread via GitHub


jira-importer commented on issue #247:
URL: 
https://github.com/apache/maven-war-plugin/issues/247#issuecomment-2967855605

   **[Carlos Sanchez 
Gonzalez](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=carlos)** 
commented
   
   You can try archiveClasses option, that may help
   


-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] [MWAR-73] war overlay mechanism does not work for classes [maven-war-plugin]

2025-06-12 Thread via GitHub


jira-importer commented on issue #247:
URL: 
https://github.com/apache/maven-war-plugin/issues/247#issuecomment-2967855615

   **[Mark 
Struberg](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=struberg)**
 commented
   
   It seems that i found a second way to fit my needs:
   
   I patched the archiveClasses feature to create an attached artifact and 
switch this feature on in war1.
   
   > public void createJarArchive( File libDirectory )
   
   ...
   archiver.getArchiver().addDirectory( classesDirectory, getIncludes(), 
getExcludes() );
   archiver.createArchive( project, archive );
   projectHelper.attachArtifact( project, "jar", "webclasses", jarFile );
   
   In the pom of war2, i simply add a manual dependency to this webclasses 
artifact.
   \\
   \msx.test\
   \war1\
   \1.0-SNAPSHOT\
   \war\
   \
   \ \
   \msx.test\
   \war1\
   \1.0-SNAPSHOT\
   \webclasses\
   \jar\
   \provided\
   \
   
   This method has a few pros and also cons
   pro:
   1.) it is faster (compared to war overlaying in preparecp step), because the 
unpacking step isn't needed anymore
   2.) the hack with the resource path led to unintended side effects when 
using the eclipse and idea plugins (The classes got added as source directories 
in the IDE). The dependency resolution now also works with e.g.  m2eclipse
   
   contra:
   1.) the first war needs to have 'archiveClasses=true'
   2.) in the 2nd war, there have to be 2 dependency settings, one for the war 
itself and another one with the webclasses classifier. The version numbers 
always have to be exactly the same.
   
   The 2nd con may be avoided if it is possible to automatically check if there 
is an attached 'webclasses'  artifact, and automatically add this artifact to 
the dependency list. But i didn't succeed to get this work. Anyone have an idea 
how i may manage this?
   


-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] [MWAR-73] war overlay mechanism does not work for classes [maven-war-plugin]

2025-06-12 Thread via GitHub


jira-importer commented on issue #247:
URL: 
https://github.com/apache/maven-war-plugin/issues/247#issuecomment-2967855611

   **[Mark 
Struberg](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=struberg)**
 commented
   
   Hi Carlos!
   
   The problem is, that the classes of the war, on which the actual war depends 
on, are not available at compiletime for the actual war.
   For example: The class Test2 is in war2 and depends on war1 which has the 
Test1 class + class Test2 extends Test1
   So even if i switch the archiveClasses feature on, the compiler may not see 
the dependant classes at compile time.
   
   What i have done so far to resolve this issue (i would rather consider it a 
bug) is to introduce a new WarClasspathMojo which temporary explodes any 
dependant war and adds a resourcePath to the 
target/$explodedWarPath/WEB-INF/classes directory. Since the maven-war-plugin 
is only active if the actual artifact is a war, this has imho no negative 
effects on building e.g. an EAR where this is not intended.
   
   The new WarClasspathMojo is to be activated in the phase generate-resources.
   


-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]