Once you know the answer, the matrix is accurate but it is too
convoluted to be read by someone who does not know the answer already.
Each of the scopes (except for import) affects transitive dependencies
in different ways, as is demonstrated in the table below. If a
dependency is set to the scope in the left column, transitive
dependencies of that dependency with the scope across the top row will
result in a dependency in the main project with the scope listed at the
intersection. If no scope is listed, it means the dependency will be
omitted.
might be written as follows:
"Each of the scopes affects transitive dependencies in different ways.
The table below describes the rules. If a dependency in the higher level
pom is set to the scope in the left column and the transitive
dependencies of the lower level pom are set to the scopes named at the
top of other column, this will result in a dependency with the derived
scope listed in the cell at the intersection. If no scope is listed, it
means the dependency will be omitted.
For example, if the project pom declares a dependency on a group pom
with a scope of "provided" and the group pom includes a jar with scope
"compile", the resulting scope for that jar will be "provided".
Of course, "import" scope does not participate in transitive dependencies."
If it is possible to colour the table or apply fonts so that header
columns and rows are more clearly marked, that would also help.
Thanks for all the help. My test project compiles and produces a 27K war
file instead of a 21Mb war.
Once I get the other 20+ projects fixed up and tested, I will have a
much quicker portal startup and some relief from the Java equivalent of
dll-hell.
It also should make starting a new project much easier since the
dependencies are now grouped much more sensibly.
I just hope it runs after it is deployed.
Ron
Anders Hammar wrote:
Nope, you define scope as 'provided' for the lms-pom-shared pom. All those
transient dependencies will then become 'provided' as well. (However, they
should be declared as 'compile' in the actual pom.)
This matrix explains it all:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
/Anders
On Tue, Jan 12, 2010 at 16:32, Ron Wheeler
<[email protected]>wrote:
Anders Hammar wrote:
It should work if you specify scope of 'provided' on the grouping pom
dependency.
/Anders
To clarify your point, I understand that I should do the following:
In the project pom.xml that creates the war file, I should reference the
shared pom as
<dependency>
<groupId>com.artifact_software.lms</groupId>
<artifactId>lms-pom-shared</artifactId>
<version>1.7.2-SNAPSHOT</version>
<type>pom</type>
</dependency>
which will give it compile scope
In the lms-pom-shared pom.xml, I should reference the dependencies as
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>${commons-logging.version}</version>
<scope>provided</scope>
</dependency>
which I think says that the commons-logging is to be available for
compiling but is not to added to the war file.
If I do this, I get the [ERROR]
\Users\rwheeler\Documents\workspace-sts-2.2.0.RELEASE\lms-sso-ws\src\main\com\artifact_software\portal\ssows\pojo\SSOSiteConfigProfile.java:[6,33]
package org.apache.commons.logging does not exist
If I change the scope of commons-logging to "compile", the compile works
but commons-logging is put in the war file(along with every other shared
jar).
I am using the Springsource version of Eclipse and have overridden the
embedded Maven to use 2.2.1
What am I doing wrong?
Ron
On Tue, Jan 12, 2010 at 14:00, Ron Wheeler
<[email protected]>wrote:
The grouping of dependencies partially works.
I have not found the magic key to getting the dependencies in the
dependency group to be "provided".
Since the jars in the dependency group are shared between all of the war
files and will be provided in in a shared Tomcat directory, I do not want
them in the war file. I just want them for the compile only.
I can not find any way to make them available at compile time without
getting them packed into the wars which makes the war much bigger since
each
war has all of the sharable jars.
Is there any way to exclude provided jars from dependent poms while
creating the war files.
Ron
Ron Wheeler wrote:
file:///C:/Users/rwheeler/Documents/0developmenttools/maven/Maven%20The%20Definitive%20Guide/pom-relationships.html
Section "Dependency Groupers"
Ron
Anders Hammar wrote:
Could you please state where in the Def Guide you read about pom
dependencies? Is it possible that you're talking about the import scope
and
referencing a pom as also described in this blog post:
http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/
/Anders
On Sun, Dec 27, 2009 at 19:01, Ron Wheeler
<[email protected]>wrote:
We are developing a portal project (in production for 2 years now)
that has dozens of webapps that share a lot of the same jar files.
We have started out on the road to chaos with each project having its
own
POM file that is completely independent of its friends.
Having not quite reach the State of Chaos, we are starting to look
more
closely at how Maven can help us.
By reading the Definitive Guide, I found that there is the potential
of
a
"parent POM" and POM dependencies.
I also read the section about grouping libraries together into logical
groups described by a POM file that can be shared.
This looks great.
I looked though the jars that we need and share; looked at the
dependencies for these jars and started to develop a strategy to just
get 1
copy of 1 version of the basic set of jars into the Tomcat shared or
common
directories.
This means in my case that I have a "Jetspeed" POM, a JSF POM, a
"Spring,
Hibernate, MySQL, Tomcat" POM and a utilities (mostly commons-xxx)
POM.
In each of these POM files, I have excluded shared sub-dependencies
and
marked all of the jars as "provided".
In each project POM, I refer to the shared POMs as dependencies.
The problem is that the jars listed in the shared POMs are not visible
during the build unless I mark them as "compile" scope in their family
POMs
even though they will be provided.
I gather that this will cause them to be included in the war being
constructed and I will still get dozens of copies of the same jars in
the
various webapp war files instead of just one copy of the shared jars
and
only webapp-specific jars in each webapp's war file.
Am I doing something wrong or is this just the way it is supposed to
work?
Is there a "right" way to get what I want. 1 copy of shared jars in
Tomcat's shared folder and small war files only containing the jars
not
in
shared.
Thanks
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
