Re: Using shaded JAR as a dependency in a WAR module
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ron,
I'm not sure if it's a better or worse solution. It does minimize the
configuration effort. This is always a good thing when moving people
from Ant to Maven.
What it does illustrate (at least to me) is that the code base I'm
working with has more technical debts that need to be addressed.
Also, that the documentation is quite dense - you speed through it at
your peril.
. . . just my two cents
/mde/
On 12/5/2014 7:36 PM, Ron Wheeler wrote:
Great. I hope that the discussion was helpful even if you found a
better solution.
Ron
On 05/12/2014 3:22 PM, Mark Eggers wrote: Ron and Stephen,
Ron, we cannot use libraries installed into Tomcat's
$CATALINA_BASE/lib directory for several reasons. While it's nice
from a developer and deployment point of view, we do end up
running multiple versions of the WAR file (with different versions
of various dependencies) on the same Tomcat. We also release the
WAR file, and it would be difficult to require people to modify
their server environment.
Thanks! I finally figured it out.
1. Issue number 1
I was using a POM artifact to aggregate a set of lower level
libraries. In order to do this, I had to set the following in the
shade plugin:
promoteTransitiveDependenciestrue/promoteTransitiveDependencies
This of course makes perfect sense.
2. Issue number 2
I needed to set the following:
keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope
Both of these are mentioned (albeit not as clearly as it might be)
in the fine documentation here:
http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html
Combining those two creates a JAR with all of the dependency
pom.xml files in it, as well as the classes / resources / etc. An
examination of the target WAR file shows a nice, clean WEB-INF/lib
with managed dependencies all the way down the chain.
For those people interested, the dependencies and shade plugin
configuration are given below.
dependencies dependency groupIdorg.mdeggers/groupId
artifactIdCalhost/artifactId
version${calhost.version}/version /dependency dependency
groupIdorg.mdeggers/groupId
artifactIdIHomeResources/artifactId
version${ihomeresources.version}/version typepom/type
/dependency /dependencies
build plugins plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-shade-plugin/artifactId version2.3/version
executions execution idcombine/id phasepackage/phase
goals goalshade/goal /goals configuration
keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope
promoteTransitiveDependenciestrue/promoteTransitiveDependencies
artifactSet
includes includeorg.mdeggers:*/include /includes
/artifactSet /configuration /execution /executions
/plugin /plugins /build
Sorry for the line length.
Obviously, if you don't have any transitive dependencies, you
won't need the promote line.
It works. Hope this is the correct solution.
. . . just my two cents /mde/
On 12/5/2014 10:57 AM, Ron Wheeler wrote:
Some forums are more concerned about form than content.
Everyone here is pretty focused on solving your problem
rather than telling how to post it.
If you look at the examples in my post, you will see that the
type is pom for dependencies on libraries. We also use
provided scope since we install the libraries once rather
than include them with each upload of a war file since they
generally don't change.
We set the content of our libraries (jars and versions) at
the beginning of a release cycle and don't change them for
the duration of the release unless there is an emergency.
This gives everyone a stable environment and once you have
the libraries loaded into Tomcat, in our case, they do not
change as the application gets worked on. This makes the
testing go quicker since you are only replacing the war file
that you are working on and the war file only contains the
code that we write.
I am not sure if this applies to your libraries.
Ron
On 05/12/2014 12:04 PM, Mark Eggers wrote: Ron,
Thanks for the link. I'm attempting to do this with the
shade plugin. I took a look at the JAR that the shade plugin
generates with my configuration, and it seems to have the
pom.xml files from which it was built, but not the reduced
dependency pom.xml (or any pom.xml from the built / shaded
artifact).
This means that I have not configured the shade plugin
properly to produce an artifact that can be consumed as if it
was built without using the shade plugin.
The entire list of dependencies for the WAR module:
dependencies dependency groupIdorg.mdeggers/groupId
artifactIdCoreServer/artifactId
version${coreserver.version}/version /dependency
dependency groupIdorg.mdeggers/groupId
artifactIdCoreClient/artifactId
version${coreclient.version}/version typewar/type
/dependency dependency groupIdjavax.servlet/groupId
Re: Using shaded JAR as a dependency in a WAR module
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ron,
Thanks for the link. I'm attempting to do this with the shade plugin.
I took a look at the JAR that the shade plugin generates with my
configuration, and it seems to have the pom.xml files from which it
was built, but not the reduced dependency pom.xml (or any pom.xml from
the built / shaded artifact).
This means that I have not configured the shade plugin properly to
produce an artifact that can be consumed as if it was built without
using the shade plugin.
The entire list of dependencies for the WAR module:
dependencies
dependency
groupIdorg.mdeggers/groupId
artifactIdCoreServer/artifactId
version${coreserver.version}/version
/dependency
dependency
groupIdorg.mdeggers/groupId
artifactIdCoreClient/artifactId
version${coreclient.version}/version
typewar/type
/dependency
dependency
groupIdjavax.servlet/groupId
artifactIdservlet-api/artifactId
version2.5/version
scopeprovided/scope
/dependency
dependency
groupIdjavax.servlet.jsp/groupId
artifactIdjsp-api/artifactId
version2.1/version
scopeprovided/scope
/dependency
dependency
groupIdorg.mdeggers/groupId
artifactIdGlobalCalcWeb/artifactId
version${globalweb.version}/version
typewar/type
/dependency
dependency
groupIdorg.mdeggers/groupId
artifactIdIHomeWeb/artifactId
version${ihome.version}/version
typepom/type
/dependency
dependency
groupIdorg.mdeggers/groupId
artifactIdIFCResources/artifactId
version1.0-SNAPSHOT/version
/dependency
/dependencies
There could be as many as 50 components going into the final WAR file,
so it would be nice to manage them in a more organized fashion (as
well as reduce the clutter in WEB-INF/lib).
All of the versions with properties have properties defined. The last
dependency is the shaded JAR, and the one that is not behaving as
expected (but probably as built / configured).
The NetBeans graphical display of the dependencies shows IFCResources,
as well as the three components it was shaded from.
Sorry for the top-post. It seems to be the norm on this list, whereas
the Tomcat mailing list explicitly mentions replying at the bottom. I
didn't see any mention of posting style on the site. If posting at the
bottom is the encouraged form, I'll be happy to do so.
. . . just my two cents
/mde/
On 12/4/2014 8:41 PM, Ron Wheeler wrote:
We do this all the time and it always works.
http://blog.artifact-software.com/tech/?p=121 Aggregation jars make
development simpler and wars smaller
Partial dependencies for
org.mdeggers:iforeclosure:1.0-SNAPSHOT:war
dependencies dependency groupIdorg.mdeggers/groupId
artifactIdIFCResources/artifactId
version1.0-SNAPSHOT/version /dependency /dependencies
What are the dependencies for the war file? Partial list is not
much help.
Ron
On 04/12/2014 6:29 PM, Mark Eggers wrote: Folks,
I admit it, I'm a bit confused (and relatively new to maven).
Goal:
To release a WAR file with a minimal number of JAR files in
WEB-INF/lib.
Thought:
1. Break up the WAR project into a WAR module and a JAR module 2.
Make the WAR module be dependent on the JAR module 3. Use the
Maven shade plugin in the JAR module to create a shaded JAR 4.
Drive the entire project with an agregator pom.xml
The JAR module does shade properly, creating a single JAR with all
of the dependencies bundled into a single JAR. It uses a pom
dependency to gather in most of its requirements. None of the JAR
or pom dependencies have further dependencies, so the resulting
JAR is self-contained.
However, when I build the WAR file and reference the shaded JAR
file as a dependency, I do not get the shaded JAR file in
WEB-INF/lib. Instead, I get all of the dependencies as individual
JAR files in WEB-INF/lib.
I'm using the following environment (can post my complete pom.xml
files if needed).
OS:Fedora Linux 64 bit - latest updates JDK: 1.7.0_72 64 bit
Maven: 3.2.3
maven-shade-plugin: 2.3 maven-war-plugin: 2.4
shade configuration and dependencies for
org.mdeggers:IFCResources:1.0-SNAPSHOT
properties calhost.version1.0-SNAPSHOT/calhost.version
ihomeresources.version1.0-SNAPSHOT/ihomeresources.version
/properties
dependencies dependency groupIdorg.mdeggers/groupId
artifactIdCalhost/artifactId
version${calhost.version}/version /dependency dependency
groupIdorg.mdeggers/groupId
artifactIdIHomeResources/artifactId
version${ihomeresources.version}/version typepom/type
/dependency /dependencies
plugin groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-shade-plugin/artifactId version2.3/version
executions execution idcombine/id phasepackage/phase
goals goalshade/goal /goals configuration artifactSet
includes
Re: Using shaded JAR as a dependency in a WAR module
Some forums are more concerned about form than content.
Everyone here is pretty focused on solving your problem rather than
telling how to post it.
If you look at the examples in my post, you will see that the type is
pom for dependencies on libraries.
We also use provided scope since we install the libraries once rather
than include them with each upload of a war file since they generally
don't change.
We set the content of our libraries (jars and versions) at the beginning
of a release cycle and don't change them for the duration of the release
unless there is an emergency.
This gives everyone a stable environment and once you have the libraries
loaded into Tomcat, in our case, they do not change as the application
gets worked on.
This makes the testing go quicker since you are only replacing the war
file that you are working on and the war file only contains the code
that we write.
I am not sure if this applies to your libraries.
Ron
On 05/12/2014 12:04 PM, Mark Eggers wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ron,
Thanks for the link. I'm attempting to do this with the shade plugin.
I took a look at the JAR that the shade plugin generates with my
configuration, and it seems to have the pom.xml files from which it
was built, but not the reduced dependency pom.xml (or any pom.xml from
the built / shaded artifact).
This means that I have not configured the shade plugin properly to
produce an artifact that can be consumed as if it was built without
using the shade plugin.
The entire list of dependencies for the WAR module:
dependencies
dependency
groupIdorg.mdeggers/groupId
artifactIdCoreServer/artifactId
version${coreserver.version}/version
/dependency
dependency
groupIdorg.mdeggers/groupId
artifactIdCoreClient/artifactId
version${coreclient.version}/version
typewar/type
/dependency
dependency
groupIdjavax.servlet/groupId
artifactIdservlet-api/artifactId
version2.5/version
scopeprovided/scope
/dependency
dependency
groupIdjavax.servlet.jsp/groupId
artifactIdjsp-api/artifactId
version2.1/version
scopeprovided/scope
/dependency
dependency
groupIdorg.mdeggers/groupId
artifactIdGlobalCalcWeb/artifactId
version${globalweb.version}/version
typewar/type
/dependency
dependency
groupIdorg.mdeggers/groupId
artifactIdIHomeWeb/artifactId
version${ihome.version}/version
typepom/type
/dependency
dependency
groupIdorg.mdeggers/groupId
artifactIdIFCResources/artifactId
version1.0-SNAPSHOT/version
/dependency
/dependencies
There could be as many as 50 components going into the final WAR file,
so it would be nice to manage them in a more organized fashion (as
well as reduce the clutter in WEB-INF/lib).
All of the versions with properties have properties defined. The last
dependency is the shaded JAR, and the one that is not behaving as
expected (but probably as built / configured).
The NetBeans graphical display of the dependencies shows IFCResources,
as well as the three components it was shaded from.
Sorry for the top-post. It seems to be the norm on this list, whereas
the Tomcat mailing list explicitly mentions replying at the bottom. I
didn't see any mention of posting style on the site. If posting at the
bottom is the encouraged form, I'll be happy to do so.
. . . just my two cents
/mde/
On 12/4/2014 8:41 PM, Ron Wheeler wrote:
We do this all the time and it always works.
http://blog.artifact-software.com/tech/?p=121 Aggregation jars make
development simpler and wars smaller
Partial dependencies for
org.mdeggers:iforeclosure:1.0-SNAPSHOT:war
dependencies dependency groupIdorg.mdeggers/groupId
artifactIdIFCResources/artifactId
version1.0-SNAPSHOT/version /dependency /dependencies
What are the dependencies for the war file? Partial list is not
much help.
Ron
On 04/12/2014 6:29 PM, Mark Eggers wrote: Folks,
I admit it, I'm a bit confused (and relatively new to maven).
Goal:
To release a WAR file with a minimal number of JAR files in
WEB-INF/lib.
Thought:
1. Break up the WAR project into a WAR module and a JAR module 2.
Make the WAR module be dependent on the JAR module 3. Use the
Maven shade plugin in the JAR module to create a shaded JAR 4.
Drive the entire project with an agregator pom.xml
The JAR module does shade properly, creating a single JAR with all
of the dependencies bundled into a single JAR. It uses a pom
dependency to gather in most of its requirements. None of the JAR
or pom dependencies have further dependencies, so the resulting
JAR is self-contained.
However, when I build the WAR file and reference the shaded JAR
file as a dependency, I do not get the shaded JAR file in
WEB-INF/lib. Instead, I get all of the dependencies as individual
JAR files in
Re: Using shaded JAR as a dependency in a WAR module
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ron and Stephen,
Ron, we cannot use libraries installed into Tomcat's
$CATALINA_BASE/lib directory for several reasons. While it's nice from
a developer and deployment point of view, we do end up running
multiple versions of the WAR file (with different versions of various
dependencies) on the same Tomcat. We also release the WAR file, and it
would be difficult to require people to modify their server environment.
Thanks! I finally figured it out.
1. Issue number 1
I was using a POM artifact to aggregate a set of lower level
libraries. In order to do this, I had to set the following in the
shade plugin:
promoteTransitiveDependenciestrue/promoteTransitiveDependencies
This of course makes perfect sense.
2. Issue number 2
I needed to set the following:
keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope
Both of these are mentioned (albeit not as clearly as it might be) in
the fine documentation here:
http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html
Combining those two creates a JAR with all of the dependency pom.xml
files in it, as well as the classes / resources / etc. An examination
of the target WAR file shows a nice, clean WEB-INF/lib with managed
dependencies all the way down the chain.
For those people interested, the dependencies and shade plugin
configuration are given below.
dependencies
dependency
groupIdorg.mdeggers/groupId
artifactIdCalhost/artifactId
version${calhost.version}/version
/dependency
dependency
groupIdorg.mdeggers/groupId
artifactIdIHomeResources/artifactId
version${ihomeresources.version}/version
typepom/type
/dependency
/dependencies
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-shade-plugin/artifactId
version2.3/version
executions
execution
idcombine/id
phasepackage/phase
goals
goalshade/goal
/goals
configuration
keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope
promoteTransitiveDependenciestrue/promoteTransitiveDependencies
artifactSet
includes
includeorg.mdeggers:*/include
/includes
/artifactSet
/configuration
/execution
/executions
/plugin
/plugins
/build
Sorry for the line length.
Obviously, if you don't have any transitive dependencies, you won't
need the promote line.
It works. Hope this is the correct solution.
. . . just my two cents
/mde/
On 12/5/2014 10:57 AM, Ron Wheeler wrote:
Some forums are more concerned about form than content. Everyone
here is pretty focused on solving your problem rather than telling
how to post it.
If you look at the examples in my post, you will see that the type
is pom for dependencies on libraries. We also use provided
scope since we install the libraries once rather than include them
with each upload of a war file since they generally don't change.
We set the content of our libraries (jars and versions) at the
beginning of a release cycle and don't change them for the duration
of the release unless there is an emergency. This gives everyone a
stable environment and once you have the libraries loaded into
Tomcat, in our case, they do not change as the application gets
worked on. This makes the testing go quicker since you are only
replacing the war file that you are working on and the war file
only contains the code that we write.
I am not sure if this applies to your libraries.
Ron
On 05/12/2014 12:04 PM, Mark Eggers wrote: Ron,
Thanks for the link. I'm attempting to do this with the shade
plugin. I took a look at the JAR that the shade plugin generates
with my configuration, and it seems to have the pom.xml files from
which it was built, but not the reduced dependency pom.xml (or any
pom.xml from the built / shaded artifact).
This means that I have not configured the shade plugin properly to
produce an artifact that can be consumed as if it was built
without using the shade plugin.
The entire list of dependencies for the WAR module:
dependencies dependency groupIdorg.mdeggers/groupId
artifactIdCoreServer/artifactId
version${coreserver.version}/version /dependency
dependency groupIdorg.mdeggers/groupId
artifactIdCoreClient/artifactId
version${coreclient.version}/version typewar/type
/dependency dependency groupIdjavax.servlet/groupId
artifactIdservlet-api/artifactId version2.5/version
scopeprovided/scope /dependency dependency
groupIdjavax.servlet.jsp/groupId
artifactIdjsp-api/artifactId version2.1/version
scopeprovided/scope /dependency dependency
Re: Using shaded JAR as a dependency in a WAR module
Great.
I hope that the discussion was helpful even if you found a better solution.
Ron
On 05/12/2014 3:22 PM, Mark Eggers wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ron and Stephen,
Ron, we cannot use libraries installed into Tomcat's
$CATALINA_BASE/lib directory for several reasons. While it's nice from
a developer and deployment point of view, we do end up running
multiple versions of the WAR file (with different versions of various
dependencies) on the same Tomcat. We also release the WAR file, and it
would be difficult to require people to modify their server environment.
Thanks! I finally figured it out.
1. Issue number 1
I was using a POM artifact to aggregate a set of lower level
libraries. In order to do this, I had to set the following in the
shade plugin:
promoteTransitiveDependenciestrue/promoteTransitiveDependencies
This of course makes perfect sense.
2. Issue number 2
I needed to set the following:
keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope
Both of these are mentioned (albeit not as clearly as it might be) in
the fine documentation here:
http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html
Combining those two creates a JAR with all of the dependency pom.xml
files in it, as well as the classes / resources / etc. An examination
of the target WAR file shows a nice, clean WEB-INF/lib with managed
dependencies all the way down the chain.
For those people interested, the dependencies and shade plugin
configuration are given below.
dependencies
dependency
groupIdorg.mdeggers/groupId
artifactIdCalhost/artifactId
version${calhost.version}/version
/dependency
dependency
groupIdorg.mdeggers/groupId
artifactIdIHomeResources/artifactId
version${ihomeresources.version}/version
typepom/type
/dependency
/dependencies
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-shade-plugin/artifactId
version2.3/version
executions
execution
idcombine/id
phasepackage/phase
goals
goalshade/goal
/goals
configuration
keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope
promoteTransitiveDependenciestrue/promoteTransitiveDependencies
artifactSet
includes
includeorg.mdeggers:*/include
/includes
/artifactSet
/configuration
/execution
/executions
/plugin
/plugins
/build
Sorry for the line length.
Obviously, if you don't have any transitive dependencies, you won't
need the promote line.
It works. Hope this is the correct solution.
. . . just my two cents
/mde/
On 12/5/2014 10:57 AM, Ron Wheeler wrote:
Some forums are more concerned about form than content. Everyone
here is pretty focused on solving your problem rather than telling
how to post it.
If you look at the examples in my post, you will see that the type
is pom for dependencies on libraries. We also use provided
scope since we install the libraries once rather than include them
with each upload of a war file since they generally don't change.
We set the content of our libraries (jars and versions) at the
beginning of a release cycle and don't change them for the duration
of the release unless there is an emergency. This gives everyone a
stable environment and once you have the libraries loaded into
Tomcat, in our case, they do not change as the application gets
worked on. This makes the testing go quicker since you are only
replacing the war file that you are working on and the war file
only contains the code that we write.
I am not sure if this applies to your libraries.
Ron
On 05/12/2014 12:04 PM, Mark Eggers wrote: Ron,
Thanks for the link. I'm attempting to do this with the shade
plugin. I took a look at the JAR that the shade plugin generates
with my configuration, and it seems to have the pom.xml files from
which it was built, but not the reduced dependency pom.xml (or any
pom.xml from the built / shaded artifact).
This means that I have not configured the shade plugin properly to
produce an artifact that can be consumed as if it was built
without using the shade plugin.
The entire list of dependencies for the WAR module:
dependencies dependency groupIdorg.mdeggers/groupId
artifactIdCoreServer/artifactId
version${coreserver.version}/version /dependency
dependency groupIdorg.mdeggers/groupId
artifactIdCoreClient/artifactId
version${coreclient.version}/version typewar/type
/dependency dependency groupIdjavax.servlet/groupId
artifactIdservlet-api/artifactId version2.5/version
scopeprovided/scope /dependency dependency
Re: Using shaded JAR as a dependency in a WAR module
DependencyReducedPom
On Thursday, 4 December 2014, Mark Eggers its_toas...@yahoo.com.invalid
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Folks,
I admit it, I'm a bit confused (and relatively new to maven).
Goal:
To release a WAR file with a minimal number of JAR files in WEB-INF/lib.
Thought:
1. Break up the WAR project into a WAR module and a JAR module
2. Make the WAR module be dependent on the JAR module
3. Use the Maven shade plugin in the JAR module to create a shaded JAR
4. Drive the entire project with an agregator pom.xml
The JAR module does shade properly, creating a single JAR with all of
the dependencies bundled into a single JAR. It uses a pom dependency
to gather in most of its requirements. None of the JAR or pom
dependencies have further dependencies, so the resulting JAR is
self-contained.
However, when I build the WAR file and reference the shaded JAR file
as a dependency, I do not get the shaded JAR file in WEB-INF/lib.
Instead, I get all of the dependencies as individual JAR files in
WEB-INF/lib.
I'm using the following environment (can post my complete pom.xml
files if needed).
OS:Fedora Linux 64 bit - latest updates
JDK: 1.7.0_72 64 bit
Maven: 3.2.3
maven-shade-plugin: 2.3
maven-war-plugin: 2.4
shade configuration and dependencies for
org.mdeggers:IFCResources:1.0-SNAPSHOT
properties
calhost.version1.0-SNAPSHOT/calhost.version
ihomeresources.version1.0-SNAPSHOT/ihomeresources.version
/properties
dependencies
dependency
groupIdorg.mdeggers/groupId
artifactIdCalhost/artifactId
version${calhost.version}/version
/dependency
dependency
groupIdorg.mdeggers/groupId
artifactIdIHomeResources/artifactId
version${ihomeresources.version}/version
typepom/type
/dependency
/dependencies
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-shade-plugin/artifactId
version2.3/version
executions
execution
idcombine/id
phasepackage/phase
goals
goalshade/goal
/goals
configuration
artifactSet
includes
includeorg.mdeggers:*/include
/includes
/artifactSet
/configuration
/execution
/executions
/plugin
Partial dependencies for org.mdeggers:iforeclosure:1.0-SNAPSHOT:war
dependencies
dependency
groupIdorg.mdeggers/groupId
artifactIdIFCResources/artifactId
version1.0-SNAPSHOT/version
/dependency
/dependencies
Parent pom modules section:
modules
moduleIFCResources/module
moduleiforeclosure/module
/modules
I'm obviously missing something here. Thoughts, corrections, pointers
are all appreciated.
I know, using a shaded JAR as a dependency is probably not best
practice. However, the resulting WAR file is an end product and the
shaded JAR only contains internal components from other web overlays
used to build the final war.
. . . just my (confused) 2 cents
/mde/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBAgAGBQJUgO5LAAoJEEFGbsYNeTwt9YgIAKLuOll7rpDRI4Ea3ieshWgY
HugkUrvaja1UZdKkFm0bdo4qQxUUmKHL9byHTQzPiLb6+WKeXaaQaMDvhA0DgbAp
tJQ+4WKEPBzKx5MUvftY2oEiW8eVEnMIkZ6qLA0aPKxrenodlekz3eKlxJ/D8kxF
dqf5UvncIYGNlzbThVlFaOpmp7FgF6dStrBDPuyGdhcLWpb4UkI/sVqo92/copnY
tMR2uX9/Uscn+11pXlcTTg+YfGGwlguZIEkSBRlUBiAYMwiDG0fyDqRaVcv18BtS
/iLB6hlB8xNkRArvIpDV+h7W2sHK6jekjzfCU80ZO72ZSgsiYUKMqWlY04GlPTU=
=jCy7
-END PGP SIGNATURE-
---
This email is free from viruses and malware because avast! Antivirus
protection is active.
http://www.avast.com
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org javascript:;
For additional commands, e-mail: users-h...@maven.apache.org
javascript:;
--
Sent from my phone
Re: Using shaded JAR as a dependency in a WAR module
We do this all the time and it always works.
http://blog.artifact-software.com/tech/?p=121 Aggregation jars make development
simpler and wars smaller
Partial dependencies for org.mdeggers:iforeclosure:1.0-SNAPSHOT:war
dependencies
dependency
groupIdorg.mdeggers/groupId
artifactIdIFCResources/artifactId
version1.0-SNAPSHOT/version
/dependency
/dependencies
What are the dependencies for the war file? Partial list is not much help.
Ron
On 04/12/2014 6:29 PM, Mark Eggers wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Folks,
I admit it, I'm a bit confused (and relatively new to maven).
Goal:
To release a WAR file with a minimal number of JAR files in WEB-INF/lib.
Thought:
1. Break up the WAR project into a WAR module and a JAR module
2. Make the WAR module be dependent on the JAR module
3. Use the Maven shade plugin in the JAR module to create a shaded JAR
4. Drive the entire project with an agregator pom.xml
The JAR module does shade properly, creating a single JAR with all of
the dependencies bundled into a single JAR. It uses a pom dependency
to gather in most of its requirements. None of the JAR or pom
dependencies have further dependencies, so the resulting JAR is
self-contained.
However, when I build the WAR file and reference the shaded JAR file
as a dependency, I do not get the shaded JAR file in WEB-INF/lib.
Instead, I get all of the dependencies as individual JAR files in
WEB-INF/lib.
I'm using the following environment (can post my complete pom.xml
files if needed).
OS:Fedora Linux 64 bit - latest updates
JDK: 1.7.0_72 64 bit
Maven: 3.2.3
maven-shade-plugin: 2.3
maven-war-plugin: 2.4
shade configuration and dependencies for
org.mdeggers:IFCResources:1.0-SNAPSHOT
properties
calhost.version1.0-SNAPSHOT/calhost.version
ihomeresources.version1.0-SNAPSHOT/ihomeresources.version
/properties
dependencies
dependency
groupIdorg.mdeggers/groupId
artifactIdCalhost/artifactId
version${calhost.version}/version
/dependency
dependency
groupIdorg.mdeggers/groupId
artifactIdIHomeResources/artifactId
version${ihomeresources.version}/version
typepom/type
/dependency
/dependencies
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-shade-plugin/artifactId
version2.3/version
executions
execution
idcombine/id
phasepackage/phase
goals
goalshade/goal
/goals
configuration
artifactSet
includes
includeorg.mdeggers:*/include
/includes
/artifactSet
/configuration
/execution
/executions
/plugin
Partial dependencies for org.mdeggers:iforeclosure:1.0-SNAPSHOT:war
dependencies
dependency
groupIdorg.mdeggers/groupId
artifactIdIFCResources/artifactId
version1.0-SNAPSHOT/version
/dependency
/dependencies
Parent pom modules section:
modules
moduleIFCResources/module
moduleiforeclosure/module
/modules
I'm obviously missing something here. Thoughts, corrections, pointers
are all appreciated.
I know, using a shaded JAR as a dependency is probably not best
practice. However, the resulting WAR file is an end product and the
shaded JAR only contains internal components from other web overlays
used to build the final war.
. . . just my (confused) 2 cents
/mde/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBAgAGBQJUgO5LAAoJEEFGbsYNeTwt9YgIAKLuOll7rpDRI4Ea3ieshWgY
HugkUrvaja1UZdKkFm0bdo4qQxUUmKHL9byHTQzPiLb6+WKeXaaQaMDvhA0DgbAp
tJQ+4WKEPBzKx5MUvftY2oEiW8eVEnMIkZ6qLA0aPKxrenodlekz3eKlxJ/D8kxF
dqf5UvncIYGNlzbThVlFaOpmp7FgF6dStrBDPuyGdhcLWpb4UkI/sVqo92/copnY
tMR2uX9/Uscn+11pXlcTTg+YfGGwlguZIEkSBRlUBiAYMwiDG0fyDqRaVcv18BtS
/iLB6hlB8xNkRArvIpDV+h7W2sHK6jekjzfCU80ZO72ZSgsiYUKMqWlY04GlPTU=
=jCy7
-END PGP SIGNATURE-
---
This email is free from viruses and malware because avast! Antivirus protection
is active.
http://www.avast.com
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
