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] > >
