On 25/08/2010 9:46 AM, Anders Hammar wrote:
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>
:-)
It does have a bit of that air about it from the programmers side but
1) Central control over library use does reduce the proliferation of
versions of the same package
2) Once you declare your dependence on
com.artifact_software.lms:lms-pom-spring-hibernate-mysql-tomcat:1.9.1
you don't have to guess if your module has the right core setup. Got
tired of finding spring 2.0.5 jars in webapps that were part of an
application that was supposed to be running 2.5.6
3) Pom files are much simpler to standardize.
4) Much easier to on-board a new person. If you want to know what Apache
packages are in use and can be used without raising a team discussion,
just look at the lms-pom-shared.
5) When we went from Tomcat 5 to 6, I did not have to look through 40
webapps to be sure that no one had a Tomcat 5 jar stuck somewhere.
On the downside it does make "where used" a bit tougher for the less
ubiquitous libraries like Apache POI which is only used in 3 or 4
webapps. it is in "shared" so all projects "might" be using it as far as
Maven is concerned.
Ron
/Anders
On Wed, Aug 25, 2010 at 15:30, Ron Wheeler
<rwhee...@artifact-software.com>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
<rwhee...@artifact-software.com>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
<rwhee...@artifact-software.com>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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
