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>
         <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/
--- This email is free from viruses and malware because avast!
Antivirus protection is active. http://www.avast.com


---------------------------------------------------------------------



To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJUgeWDAAoJEEFGbsYNeTwtoTkH+wecGgNHc2VNaHxR8kp8PTXB
xHFRfI7VeD2wrQgwqyZSCnL1pJSbSLUvhHopIQslTiHO1Rbr84/L0o4DZe8z+m49
4Oty9Jz7soEP+b0PnhomErNMD7aPsjtPjsAT59rYS4zlbT5FkphauYzFxfdnmCfC
OCykAIN/dUgNRL0RlUfAX207RHLAx1Kvz3gHhxsMPgLr9HqFaBBHipGh2ZIv+jog
reGqqmK0px2UoH1oniXREJ9fpMCB09dbQEX5UwtAHKgCeAvEblMLosxFuWH3fL/U
VyjiaQNUZwt8pwhDeV1vCjQceOluooFgnYhn95pMxvnrDNHiHP4e+OxKiiczzqU=
=2b8i
-----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: [email protected]
For additional commands, e-mail: [email protected]




--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to