As long as you know about the drawbacks. It makes me remember all those
trouble free days of ant..
<classpath>
<fileset dir="lib">
<include name="**/*.jar"/>
</fileset>
</classpath>
:-)
/Anders
On Wed, Aug 25, 2010 at 15:30, Ron Wheeler
<[email protected]>wrote:
> On 25/08/2010 9:07 AM, Anders Hammar wrote:
>
>> What I was thinking of was that you could get transitive dependencies
>> included which are actually also included in your "super-jar". As the
>> super-jar is of a different GA than the original/correct artifact, Maven
>> will have no chance to handle that but you need to exclude that manually.
>> In
>> my experience, no normal Java developer will have a clue about this.
>>
> The developers generally do not have to add any dependencies to their poms
> other than the libraries that we have agreed on.
> This simplifies their lives since they do not have to worry about third
> party jars.
> If there is a new library added to an individual module, the maven
> dependency hierarchy window identifies conflicts which can then be raised
> with the team to see how it should be resolved.
>
> Ron
>
> As the dependency grouping pom solves this issue I see it as a better
>> Maven
>> solution. However, it will make your deployment to the server involve a
>> little bit more work as you need to copy more than one jar. But I assume
>> you
>> have tools to do this so it shouldn't be an issue, right?
>>
>> /Anders
>>
>> On Wed, Aug 25, 2010 at 13:59, Ron Wheeler
>> <[email protected]>wrote:
>>
>> On 25/08/2010 2:45 AM, Anders Hammar wrote:
>>>
>>> I don't think that I would call Ron's solution a best-practice (I see
>>>> issues
>>>> with transitive dependencies).
>>>>
>>>> Can you elaborate? We have not found any problems yet but perhaps we
>>> have
>>> been lucky.
>>> We do pay attention to version conflicts while building the aggregate
>>> jars.
>>> Are we missing something?
>>>
>>>
>>> If you want something as simple as just
>>>
>>>> adding one dependency, you should create a pom project that groups these
>>>> dependencies. Tim explains this in this blog post:
>>>>
>>>>
>>>> http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/
>>>>
>>>> However, be aware that there are drawbacks with this solution. For one,
>>>> the
>>>> "mvn dependency:analyze" won't work as the dependencies go one the wrong
>>>> level. The import pom solution that Stephen suggests does not have this
>>>> limitation, which is very nice.
>>>>
>>>> /Anders
>>>>
>>>> On Wed, Aug 25, 2010 at 06:26, Ron Wheeler
>>>> <[email protected]>wrote:
>>>>
>>>> This is a common problem in a portal environment or SOA architecture
>>>>
>>>>> where
>>>>> many webapps are generated.
>>>>> We solved this by creating a set of projects that create sets of jars
>>>>> that
>>>>> group together a bunch of jars into one massive jar.
>>>>>
>>>>> For example, we have a spring-mysql-hibernate-tomcat project that
>>>>> creates
>>>>> an aggregated jar with all of the libraries included in this set of
>>>>> projects.
>>>>> The POM that manages this project has all the version numbers so the
>>>>> parent
>>>>> pom of all of the modules only specifies the application version and
>>>>> the
>>>>> module only depends on our set of aggregated POMs.
>>>>>
>>>>> If you want to change the version of a Hibernate library you only have
>>>>> to
>>>>> change it in one place.
>>>>> The POMs that create individual application artifacts do not know
>>>>> anything
>>>>> about the version of Hibernate, they only depend on the current
>>>>> ($project.version) version of the application to get all the right bits
>>>>> and
>>>>> pieces of spring, mysql, hibernate and tomcat.
>>>>>
>>>>> This really simplifies the management of individual portlets or web
>>>>> services.
>>>>> They call on one parent POM that specifies the {$project.version} and
>>>>> use
>>>>> this variable in the dependency for spring-mysql-hibernate-tomcat, jsf,
>>>>> CXF,
>>>>> etc.
>>>>> This means that a module's POM is very stable and only has 4 or 5
>>>>> dependencies.
>>>>> We also deploy the aggregated jars into the Tomcat shared library.
>>>>>
>>>>> This makes the webapps very small and reduces the number of choices
>>>>> that
>>>>> a
>>>>> developer has to make about third party jars.
>>>>>
>>>>> Ron
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 24/08/2010 5:54 PM, Zac Thompson wrote:
>>>>>
>>>>> I've racked my brain to come up with an ideal solution to this,
>>>>>
>>>>>> without success, so I'm throwing myself on the mercy of the group.
>>>>>> Any and all advice is greatly appreciated.
>>>>>>
>>>>>> I have a project with many modules that are all released together;
>>>>>> let's say they're in group ca.zac.A. The parent pom (also the
>>>>>> aggregator) for the group defines dependencyManagement for all the
>>>>>> child poms so that keeping versions consistent within the group and
>>>>>> releasing them together is easy. So far, so good.
>>>>>>
>>>>>> But other projects might depend on a subset of the group, or have
>>>>>> transitive dependencies on them, so I list the whole set of ca.zac.A
>>>>>> modules in the dependencyManagement section of each such project: I
>>>>>> want to be sure of keeping the versions consistent and known, and
>>>>>> sometimes Maven's resolution ends up choosing mixed versions. But
>>>>>> adding the whole set means I end up duplicating a large block of the
>>>>>> POM in multiple projects. And if I add a new module that might get
>>>>>> transitively included, then I have to update multiple places. I am
>>>>>> looking for a way to centralize this information.
>>>>>>
>>>>>> 1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using
>>>>>> properties to affect transitive dependencies is not likely to happen
>>>>>> any time soon, and I wholeheartedly agree that it's a bad idea anyway.
>>>>>>
>>>>>> 2) The idea of inheriting from the ca.zac.A parent pom worked with
>>>>>> maven 2.1.0, but not well for other versions (and it smells bad
>>>>>> anyway).
>>>>>>
>>>>>> 3) I *could* list them all in dependencyManagement in my
>>>>>> "organizational parent" pom, with the version controlled by a single
>>>>>> property, but then I'd have to update it whenever a new module is
>>>>>> added to ca.zac.A. Having such a pom list a sizable set of my
>>>>>> projects is probably workable, but it feels like I'm abusing it.
>>>>>>
>>>>>> 4) Multiple inheritance is not supported nor desired, and I understand
>>>>>> that the planned "mixin" capability won't be around until post-3.0. I
>>>>>> could have an intermediate parent pom, with just the
>>>>>> dependencyManagement entries for my group, but in fact, I have more
>>>>>> than one such set. So I'd have to put all such groups in one pom, and
>>>>>> update it whenever ca.zac.A or .B or .C have a new module. This is
>>>>>> probably my best option, but it still feels less than ideal: I'd
>>>>>> rather be able to update a discrete place for each group. In
>>>>>> practical terms, this isn't much different than putting it in the org
>>>>>> parent, because I'd have to use this as the parent for most projects
>>>>>> anyway.
>>>>>>
>>>>>> Am I stuck for now? Is there some other option I'm just not seeing?
>>>>>>
>>>>>> What I find myself wishing for is something like the following, and
>>>>>> just have it apply to all the artifacts in the group (note that I
>>>>>> would only ever want to do it for a groupId that I controlled):
>>>>>>
>>>>>> <dependencyManagement>
>>>>>> <dependencies>
>>>>>> <dependency>
>>>>>> <groupId>ca.zac.A</groupId>
>>>>>> <versionId>${ca.zac.A.version}</versionId>
>>>>>> <!-- note no artifactId is listed -->
>>>>>> </dependency>...
>>>>>>
>>>>>> Then in the child POMs I could just specify the ca.zac.A.version
>>>>>> property. Is there a reason why something like this is a bad idea and
>>>>>> would never happen? Or should I just go ahead and submit a request
>>>>>> for it? It looks like there used to be a similar one at MNG-3633
>>>>>> (using wildcards), but that JIRA has vanished!
>>>>>>
>>>>>> Should I just grin and bear it until mixins in 3.1? If so, I'll see
>>>>>> if there's some way I can contribute.
>>>>>>
>>>>>> Zac
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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]
>
>
