maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Eggers <its_toas...@yahoo.com.INVALID>
Subject Re: Using shaded JAR as a dependency in a WAR module
Date Mon, 08 Dec 2014 17:08:09 GMT
-----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:
> 
> <promoteTransitiveDependencies>true</promoteTransitiveDependencies>
>
>  This of course makes perfect sense.
> 
> 2. Issue number 2
> 
> I needed to set the following:
> 
> <keepDependenciesWithProvidedScope>true</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> <groupId>org.mdeggers</groupId> 
> <artifactId>Calhost</artifactId> 
> <version>${calhost.version}</version> </dependency> <dependency>

> <groupId>org.mdeggers</groupId> 
> <artifactId>IHomeResources</artifactId> 
> <version>${ihomeresources.version}</version> <type>pom</type>

> </dependency> </dependencies>
> 
> <build> <plugins> <plugin> 
> <groupId>org.apache.maven.plugins</groupId> 
> <artifactId>maven-shade-plugin</artifactId> <version>2.3</version>

> <executions> <execution> <id>combine</id> <phase>package</phase>

> <goals> <goal>shade</goal> </goals> <configuration>
> 
> <keepDependenciesWithProvidedScope>true</keepDependenciesWithProvidedScope>
>
> 
> 
> <promoteTransitiveDependencies>true</promoteTransitiveDependencies>
>
> 
<artifactSet>
> <includes> <include>org.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> <groupId>org.mdeggers</groupId>

>>>> <artifactId>CoreServer</artifactId> 
>>>> <version>${coreserver.version}</version> </dependency>

>>>> <dependency> <groupId>org.mdeggers</groupId> 
>>>> <artifactId>CoreClient</artifactId> 
>>>> <version>${coreclient.version}</version> <type>war</type>

>>>> </dependency> <dependency> <groupId>javax.servlet</groupId>

>>>> <artifactId>servlet-api</artifactId> <version>2.5</version>

>>>> <scope>provided</scope> </dependency> <dependency>

>>>> <groupId>javax.servlet.jsp</groupId> 
>>>> <artifactId>jsp-api</artifactId> <version>2.1</version>

>>>> <scope>provided</scope> </dependency> <dependency>

>>>> <groupId>org.mdeggers</groupId> 
>>>> <artifactId>GlobalCalcWeb</artifactId> 
>>>> <version>${globalweb.version}</version> <type>war</type>

>>>> </dependency> <dependency> <groupId>org.mdeggers</groupId>

>>>> <artifactId>IHomeWeb</artifactId> 
>>>> <version>${ihome.version}</version> <type>pom</type>
>>>> </dependency> <dependency> <groupId>org.mdeggers</groupId>

>>>> <artifactId>IFCResources</artifactId> 
>>>> <version>1.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>
>>>>>>> <groupId>org.mdeggers</groupId> 
>>>>>>> <artifactId>IFCResources</artifactId> 
>>>>>>> <version>1.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.version>1.0-SNAPSHOT</calhost.version> 
>>>>>>> <ihomeresources.version>1.0-SNAPSHOT</ihomeresources.version>
>>>>>>>
>>>>>>>
>
>>>>>>> 
</properties>
>>>>>>> <dependencies> <dependency>
>>>>>>> <groupId>org.mdeggers</groupId> 
>>>>>>> <artifactId>Calhost</artifactId> 
>>>>>>> <version>${calhost.version}</version> </dependency>

>>>>>>> <dependency> <groupId>org.mdeggers</groupId>

>>>>>>> <artifactId>IHomeResources</artifactId> 
>>>>>>> <version>${ihomeresources.version}</version> 
>>>>>>> <type>pom</type> </dependency> </dependencies>
>>>>>>> 
>>>>>>> <plugin> <groupId>org.apache.maven.plugins</groupId>

>>>>>>> <artifactId>maven-shade-plugin</artifactId> 
>>>>>>> <version>2.3</version> <executions> <execution>

>>>>>>> <id>combine</id> <phase>package</phase>
<goals> 
>>>>>>> <goal>shade</goal> </goals> <configuration>
>>>>>>> <artifactSet> <includes>
>>>>>>> <include>org.mdeggers:*</include> </includes>

>>>>>>> </artifactSet> </configuration> </execution>
>>>>>>> </executions> </plugin>
>>>>>>> 
>>>>>>> Partial dependencies for 
>>>>>>> org.mdeggers:iforeclosure:1.0-SNAPSHOT:war
>>>>>>> 
>>>>>>> <dependencies> <dependency>
>>>>>>> <groupId>org.mdeggers</groupId> 
>>>>>>> <artifactId>IFCResources</artifactId> 
>>>>>>> <version>1.0-SNAPSHOT</version> </dependency>

>>>>>>> </dependencies>
>>>>>>> 
>>>>>>> Parent pom modules section:
>>>>>>> 
>>>>>>> <modules> <module>IFCResources</module> 
>>>>>>> <module>iforeclosure</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

iQEcBAEBAgAGBQJUhdr5AAoJEEFGbsYNeTwtg/MH/1zzSZ7Xqv54ngx60TrfC8bk
97yMh6OuMh/HrR+M5MP3qFLOMRBGf32Qz8ai6E8CSIzUSW02Zp8DCWuJxQTZM3U7
DoZx0ny61qNBCzgH9iK6IgmaVplhFbBDkw3ilNT+eoHAAAtN44YGJxt65vdcDT4I
cIudpeD0GIz9Sv3Xjxn2EYmTiB3QPwhA/l9djReDvnFvz3YcvSVjLyTXXVyJgtmJ
hCuDN4JSXoF2c6oF2ofg7g4tMZ5M3E1lJTqe1u+N4XTYuyeg4Ytt+TudfDu5M6WR
aITKNWUQ6MxKghRO1G2wOo26XCOcLzuwd4zmyMZNaxcxzuH8zg3qM3Ppk9e2s/E=
=7CTf
-----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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message