[jira] (MEAR-60) Improve support for skinny war files
[
https://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289261#comment-289261
]
Andreas Thaler commented on MEAR-60:
I configured the outputFileNameMapping for the war-plugin like that:
{code}
org.apache.maven.plugins
maven-war-plugin
2.1.1
@{artifactId}@-@{baseVersion}@.@{extension}@
{code}
> Improve support for skinny war files
>
>
> Key: MEAR-60
> URL: https://jira.codehaus.org/browse/MEAR-60
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.3
> Environment: mvn 2.0.5
>Reporter: Marcel Schutte
>Assignee: Dennis Lundberg
>Priority: Critical
> Fix For: 2.7
>
> Attachments: maven-ear-plugin-addon-1.0-SNAPSHOT.jar,
> maven-ear-plugin-addon-1.0-SNAPSHOT-sources.jar,
> maven-ear-plugin-MEAR-60.patch
>
>
> Provide a boolean configuration option for webModules to include the war's
> transitive dependencies.
> As described on
> http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it
> is very common in a J2EE environment to use so called skinny wars. Here the
> war's WEB-INF/lib will not contain the dependent jars, but instead they are
> packaged inside the EAR. The war references them through its
> META-INF/MANIFEST.MF
> This option could be used to avoid the 'painful part' mentioned in the above
> web page. The war's dependencies wouldn't have to be duplicated alongside the
> ear's.
> I also found an old issue (MEAR-14) which has asked for the current default
> behavior of not including the transitive dependencies. It suggests a property
> to include specific dependencies of the war. As far as I can tell this has
> never been implemented and this is also not what I am asking for. My proposal
> is an all of nothing kind of option for each war module in the ear.
> On a side note, for me this is the part where removal of the old maven 1
> style properties per dependency is missed the most. With them it was possible
> to decide for each single dependency whether to put it in WEB-INF/lib or
> reference it through the manifest classpath. But of course, then we didn't
> have the transitive dependencies
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-60) Improve support for skinny war files
[ https://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287731#comment-287731 ] Andreas Thaler commented on MEAR-60: Hi Dennis, Purpose of my fileNameMapper was not to remove the timestamped version from war, instead it configured the ear to use timestamped versions for the shared libs. Nevertheless I changed my code now by configuring the war plugin to use non-timestamped versions and now it works fine. I always avoided this approach as I have many war projects to configure contra one ear project, but it is ok. thanks for your support, am looking forward to the new release :) > Improve support for skinny war files > > > Key: MEAR-60 > URL: https://jira.codehaus.org/browse/MEAR-60 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: mvn 2.0.5 >Reporter: Marcel Schutte >Assignee: Dennis Lundberg >Priority: Critical > Fix For: 2.7 > > Attachments: maven-ear-plugin-addon-1.0-SNAPSHOT.jar, > maven-ear-plugin-addon-1.0-SNAPSHOT-sources.jar, > maven-ear-plugin-MEAR-60.patch > > > Provide a boolean configuration option for webModules to include the war's > transitive dependencies. > As described on > http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it > is very common in a J2EE environment to use so called skinny wars. Here the > war's WEB-INF/lib will not contain the dependent jars, but instead they are > packaged inside the EAR. The war references them through its > META-INF/MANIFEST.MF > This option could be used to avoid the 'painful part' mentioned in the above > web page. The war's dependencies wouldn't have to be duplicated alongside the > ear's. > I also found an old issue (MEAR-14) which has asked for the current default > behavior of not including the transitive dependencies. It suggests a property > to include specific dependencies of the war. As far as I can tell this has > never been implemented and this is also not what I am asking for. My proposal > is an all of nothing kind of option for each war module in the ear. > On a side note, for me this is the part where removal of the old maven 1 > style properties per dependency is missed the most. With them it was possible > to decide for each single dependency whether to put it in WEB-INF/lib or > reference it through the manifest classpath. But of course, then we didn't > have the transitive dependencies -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-60) Improve support for skinny war files
[ https://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285736#comment-285736 ] Andreas Thaler commented on MEAR-60: Hi Dennis, with my setup it is failing nearly always. It looks like this: Project myJar which contains classes needed by all my webapps and is of type jar. Project myWar1 using myJar and is of type war Project myWar2 using myJar and is of type war Project myEar of type ear using ear plugin for ear creation My workflow looks like this: Call "mvn install" on myJar. As a result the jar will be installed to the local repo. As the project has a snapshot version the timestamp version will be used as stated in docu: http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Available_Variables (Unfortunately I'm not able to reproduce it stable that a jar will be created in repo using timestamp :( ) Afterwards I'm calling mvn install on the war projects, as the result the wars get created having the timestamp based jars in lib folder. When you call mvn install on the ear project the jars will be placed also to the ear but using non-timestamp version and so they will not get removed from war. Key point here to reproduce it is to get a timestamp version of your jar project installed to the local repo. I'm using Maven 3.0.3 and java 1.7.01 on windows 7. War-plugin 2.1.1 I hope you can reproduce it, don't hesitate to ask further. Thanks in advance, Andreas > Improve support for skinny war files > > > Key: MEAR-60 > URL: https://jira.codehaus.org/browse/MEAR-60 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: mvn 2.0.5 >Reporter: Marcel Schutte >Assignee: Dennis Lundberg >Priority: Critical > Fix For: 2.7 > > Attachments: maven-ear-plugin-addon-1.0-SNAPSHOT.jar, > maven-ear-plugin-addon-1.0-SNAPSHOT-sources.jar, > maven-ear-plugin-MEAR-60.patch > > > Provide a boolean configuration option for webModules to include the war's > transitive dependencies. > As described on > http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it > is very common in a J2EE environment to use so called skinny wars. Here the > war's WEB-INF/lib will not contain the dependent jars, but instead they are > packaged inside the EAR. The war references them through its > META-INF/MANIFEST.MF > This option could be used to avoid the 'painful part' mentioned in the above > web page. The war's dependencies wouldn't have to be duplicated alongside the > ear's. > I also found an old issue (MEAR-14) which has asked for the current default > behavior of not including the transitive dependencies. It suggests a property > to include specific dependencies of the war. As far as I can tell this has > never been implemented and this is also not what I am asking for. My proposal > is an all of nothing kind of option for each war module in the ear. > On a side note, for me this is the part where removal of the old maven 1 > style properties per dependency is missed the most. With them it was possible > to decide for each single dependency whether to put it in WEB-INF/lib or > reference it through the manifest classpath. But of course, then we didn't > have the transitive dependencies -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEAR-60) Improve support for skinny war files
[ https://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Thaler updated MEAR-60: --- Attachment: maven-ear-plugin-addon-1.0-SNAPSHOT-sources.jar maven-ear-plugin-addon-1.0-SNAPSHOT.jar Workaround jar for unique timestamp versioning problem > Improve support for skinny war files > > > Key: MEAR-60 > URL: https://jira.codehaus.org/browse/MEAR-60 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: mvn 2.0.5 >Reporter: Marcel Schutte >Assignee: Dennis Lundberg >Priority: Critical > Fix For: 2.7 > > Attachments: maven-ear-plugin-addon-1.0-SNAPSHOT.jar, > maven-ear-plugin-addon-1.0-SNAPSHOT-sources.jar, > maven-ear-plugin-MEAR-60.patch > > > Provide a boolean configuration option for webModules to include the war's > transitive dependencies. > As described on > http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it > is very common in a J2EE environment to use so called skinny wars. Here the > war's WEB-INF/lib will not contain the dependent jars, but instead they are > packaged inside the EAR. The war references them through its > META-INF/MANIFEST.MF > This option could be used to avoid the 'painful part' mentioned in the above > web page. The war's dependencies wouldn't have to be duplicated alongside the > ear's. > I also found an old issue (MEAR-14) which has asked for the current default > behavior of not including the transitive dependencies. It suggests a property > to include specific dependencies of the war. As far as I can tell this has > never been implemented and this is also not what I am asking for. My proposal > is an all of nothing kind of option for each war module in the ear. > On a side note, for me this is the part where removal of the old maven 1 > style properties per dependency is missed the most. With them it was possible > to decide for each single dependency whether to put it in WEB-INF/lib or > reference it through the manifest classpath. But of course, then we didn't > have the transitive dependencies -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-60) Improve support for skinny war files
[
https://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285334#comment-285334
]
Andreas Thaler commented on MEAR-60:
Hi Dennis,
I would prefer to see the problem solved rather than documented as the
workaround involves custom code. Without the workaround the skinnyWar issue is
not solved from my perspective..
However here my solution with which it is working fine for me:
I created a jar containing a single java file implementing the FileNameMapping
interface. The implementation uses Artifact.getVersion() instead of
Artifact.getBaseVersion() used in AbstractFileNameMapping. So the libs placed
to the ear will have the same file name as in the war and duplicates will be
detected. I attached the jar to this issue.
At the plugin configuration the fileNameMapping property must be configured to
the custom file in the new jar. Furthermore the dependency to the jar must be
configured at the plugin.
{code}
org.apache.maven.plugins
maven-ear-plugin
2.7-SNAPSHOT
de.hybris.maven.VersionFileNameMapping
true
lib
de.hybris.maven
maven-ear-plugin-addon
1.0-SNAPSHOT
{code}
Thanks for bringing this whole story to an end,
Andreas
> Improve support for skinny war files
>
>
> Key: MEAR-60
> URL: https://jira.codehaus.org/browse/MEAR-60
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.3
> Environment: mvn 2.0.5
>Reporter: Marcel Schutte
>Assignee: Dennis Lundberg
>Priority: Critical
> Fix For: 2.7
>
> Attachments: maven-ear-plugin-MEAR-60.patch
>
>
> Provide a boolean configuration option for webModules to include the war's
> transitive dependencies.
> As described on
> http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it
> is very common in a J2EE environment to use so called skinny wars. Here the
> war's WEB-INF/lib will not contain the dependent jars, but instead they are
> packaged inside the EAR. The war references them through its
> META-INF/MANIFEST.MF
> This option could be used to avoid the 'painful part' mentioned in the above
> web page. The war's dependencies wouldn't have to be duplicated alongside the
> ear's.
> I also found an old issue (MEAR-14) which has asked for the current default
> behavior of not including the transitive dependencies. It suggests a property
> to include specific dependencies of the war. As far as I can tell this has
> never been implemented and this is also not what I am asking for. My proposal
> is an all of nothing kind of option for each war module in the ear.
> On a side note, for me this is the part where removal of the old maven 1
> style properties per dependency is missed the most. With them it was possible
> to decide for each single dependency whether to put it in WEB-INF/lib or
> reference it through the manifest classpath. But of course, then we didn't
> have the transitive dependencies
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-60) Improve support for skinny war files
[ https://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=285162#comment-285162 ] Andreas Thaler commented on MEAR-60: For me it works really fine in general. I have a problem in case the war contains artifacts having unique timestamp based version numbers. It seems that the war plugin uses the Artifact.getVersion() method for resolving of artifact files while the ear plugin uses the Artifact.getBaseVersion() method. With this the artifacts in my war are not detected as already contained in ear and will be not removed from war. I found a workaround by configuring a custom fileNameMapping for the ear plugin using the getVersion() method for artifact file resolving. With this everything works perfect. > Improve support for skinny war files > > > Key: MEAR-60 > URL: https://jira.codehaus.org/browse/MEAR-60 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: mvn 2.0.5 >Reporter: Marcel Schutte >Assignee: Dennis Lundberg >Priority: Critical > Attachments: maven-ear-plugin-MEAR-60.patch > > > Provide a boolean configuration option for webModules to include the war's > transitive dependencies. > As described on > http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it > is very common in a J2EE environment to use so called skinny wars. Here the > war's WEB-INF/lib will not contain the dependent jars, but instead they are > packaged inside the EAR. The war references them through its > META-INF/MANIFEST.MF > This option could be used to avoid the 'painful part' mentioned in the above > web page. The war's dependencies wouldn't have to be duplicated alongside the > ear's. > I also found an old issue (MEAR-14) which has asked for the current default > behavior of not including the transitive dependencies. It suggests a property > to include specific dependencies of the war. As far as I can tell this has > never been implemented and this is also not what I am asking for. My proposal > is an all of nothing kind of option for each war module in the ear. > On a side note, for me this is the part where removal of the old maven 1 > style properties per dependency is missed the most. With them it was possible > to decide for each single dependency whether to put it in WEB-INF/lib or > reference it through the manifest classpath. But of course, then we didn't > have the transitive dependencies -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
