It should work if you specify scope of 'provided' on the grouping pom dependency.
/Anders 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] > >
