Re: Figuring out the proper Maven dependency setting
Am Donnerstag 11 November 2010, 02:04:09 schrieb Ron Wheeler: > On 10/11/2010 4:37 PM, Brian Topping wrote: > > On Nov 10, 2010, at 4:20 PM, Ron Wheeler wrote: > >> It is mostly exclusions to stop old versions of libraries from being > >> dragged in by mistake. It took a bit of doing to get these the first > >> time but it is nice now that we do not have a screen full of > >> conflicting version notes. > > > > So I guess you are then having to manually import the dependencies that > > you are excluding? That is seriously painful. > > We only did that once about a year ago. It was painful but now life is > grand. > commons-logging is specified once for 60 projects and I know exactly > what version is used everywhere. Why not simply use instead? hth, - martin signature.asc Description: This is a digitally signed message part.
Re: Figuring out the proper Maven dependency setting
Am Mittwoch 10 November 2010, 22:25:13 schrieb Brian Topping: > On Nov 10, 2010, at 4:06 PM, Yanko, Curtis wrote: > > I have used the technique described here but I have also had too to > > forensic type package level comparisons to try an find matches. > > Eventually slugging our way through namespace collisions and knocking > > down issues one Classpath Not Found at a time. > > The directory entries in a Zip archive are not compressed. This makes > class names searchable with 'grep -R' on the local repository. If you > download and compile a lot of OSS projects that use Maven, chances are > your repository has most of the dependencies you would normally want to > use already in it. > > Alternately, to speed inquiries on jar contents, I use > http://mvnrepository.com. Once one drills down to the page for a specific > version of a dependency, the package structure of the contents is > displayed. There is also http://www.mvnbrowser.com/ and http://www.jarvana.com/jarvana/ which I find both to be very usefull. The latter even lets you search for classes! hth, - martin signature.asc Description: This is a digitally signed message part.
RE: Figuring out the proper Maven dependency setting
+1, That's the spirit! It's like I said, many teams for a long time have under-valued the build process and deem the whole activity to be not worth their time. And yet, so few teams I meet can provided me with a bill-of-materials or even a basic architectural drawing showing the relationship of their components. I very often find several JARs being packaged that aren't needed. Large circular dependencies and my favorite, 2 or 3 major versions within a family of libraries. > -Original Message- > From: Michael McCallum [mailto:mich...@redengine.co.nz] > Sent: Wednesday, November 10, 2010 4:44 PM > To: Maven Users List > Subject: Re: Figuring out the proper Maven dependency setting > > On Thursday 11 November 2010 09:48:34 Brian Topping wrote: > > > > These problems existed before Maven though. Maven just > gives you a bigger, more efficient gun to shoot yourself in > the foot with. > > > I'm more likely to say that now we _know_ what a mess we > have, where as before we were ignorant. In which case maven > is the tool that actually lets us take control and get it > right, even if its only in our own limited spheres of influence. > > Its not just a maven/java problem all the linux distributions > have done through the same pain. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Figuring out the proper Maven dependency setting
I'm not talking about libraries, I'm talking about an app that has been built for years either with Ant or without a build script. So we get a known good EAR and de-construct it often finding JARs that don't exist in the wild or are unidentifiable. So re-creating that EAR Maven can become a real challenge. > -Original Message- > From: Brian Topping [mailto:topp...@codehaus.org] > Sent: Wednesday, November 10, 2010 4:25 PM > To: Maven Users List > Subject: Re: Figuring out the proper Maven dependency setting > > > On Nov 10, 2010, at 4:06 PM, Yanko, Curtis wrote: > > > I have used the technique described here but I have also had too to > > forensic type package level comparisons to try an find matches. > > Eventually slugging our way through namespace collisions > and knocking > > down issues one Classpath Not Found at a time. > > The directory entries in a Zip archive are not compressed. > This makes class names searchable with 'grep -R' on the local > repository. If you download and compile a lot of OSS > projects that use Maven, chances are your repository has most > of the dependencies you would normally want to use already in it. > > Alternately, to speed inquiries on jar contents, I use > http://mvnrepository.com. Once one drills down to the page > for a specific version of a dependency, the package structure > of the contents is displayed. It's a lot easier than > constantly doing 'jar tvf ' to see what's in there, > and there's a bunch of additional information about the > dependency on that page too. It only works for jars in the > central repo though, and sadly, there are a few things that > could be made a lot nicer, but the authors have a full email > box and apparently do not want to be bothered. > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Figuring out the proper Maven dependency setting
On 10/11/2010 4:37 PM, Brian Topping wrote: On Nov 10, 2010, at 4:20 PM, Ron Wheeler wrote: It is mostly exclusions to stop old versions of libraries from being dragged in by mistake. It took a bit of doing to get these the first time but it is nice now that we do not have a screen full of conflicting version notes. So I guess you are then having to manually import the dependencies that you are excluding? That is seriously painful. We only did that once about a year ago. It was painful but now life is grand. commons-logging is specified once for 60 projects and I know exactly what version is used everywhere. It seems to follow that you would also want to set exclusions on all the excluded dependencies that you manually import, right? I mean, there's no telling that you might get a version of a transitive dependency somewhere that has two versions! :-) No need that I can see for this. At that point, I don't know why you would bother with Maven at all. Maven manages all this for us, builds all the right libraries. Tiny little POM files that are easy to maintain. Few dependencies and no exclusions. Easy to make a new one. Just copy and old one and change a few fields on the first screen of the POM editor. The effort required to disable all the dependency functionality (one dependency at a time) is so much more painful than using it well. Not painful at all. No overhead once we set up our dependency POMs. I'm not trying to be mean here, just trying to illustrate how the situation degenerates. Have you tried not using exclusions at all, then using dependency:tree to debug conflicts? Classpath conflicts where there are two versions of the same jar are usually pretty easy to spot, and when they happen, they make such a big mess of everything that it's hard to miss. But dependency:tree will show you one or two root causes of the problem, then you can put in a single exclusion on the precise jar that is causing the problem. Problem solved, and you still get updates to transitives like God intended. Sure. That is how we started. Pain was constant. Drove us crazy. Conflicts all over the place. Multiple versions of third party libraries on the classpath. Never knew which combination was going to go in at run-time. Once you get 70 portlets, servlets and web services to watch, you want to know what version of third party libraries you are building with. If we decide to go to the latest Apache-POI, we just change it one place. We do it carefully after a discussion about impact and risk. We verify what other dependencies will be affected. But we only do it once and we do it under control. No conflicts. Only things that break, are stuff that we wrote. Another small note. We put all our shared libraries at the Tomcat level. Our war files are small and generally consist exclusively of our own code. We only load 1 copy of commons-logging onto the server. The scores of libraries are all aggregated into 10 library jar files that go on /lib. Ron - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Figuring out the proper Maven dependency setting
On Nov 10, 2010, at 4:20 PM, Ron Wheeler wrote: > It is mostly exclusions to stop old versions of libraries from being dragged > in by mistake. > It took a bit of doing to get these the first time but it is nice now that we > do not have a screen full of conflicting version notes. So I guess you are then having to manually import the dependencies that you are excluding? That is seriously painful. It seems to follow that you would also want to set exclusions on all the excluded dependencies that you manually import, right? I mean, there's no telling that you might get a version of a transitive dependency somewhere that has two versions! :-) At that point, I don't know why you would bother with Maven at all. The effort required to disable all the dependency functionality (one dependency at a time) is so much more painful than using it well. I'm not trying to be mean here, just trying to illustrate how the situation degenerates. Have you tried not using exclusions at all, then using dependency:tree to debug conflicts? Classpath conflicts where there are two versions of the same jar are usually pretty easy to spot, and when they happen, they make such a big mess of everything that it's hard to miss. But dependency:tree will show you one or two root causes of the problem, then you can put in a single exclusion on the precise jar that is causing the problem. Problem solved, and you still get updates to transitives like God intended. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Figuring out the proper Maven dependency setting
On Nov 10, 2010, at 4:06 PM, Yanko, Curtis wrote: > I have used the technique described here but I have also had too to > forensic type package level comparisons to try an find matches. > Eventually slugging our way through namespace collisions and knocking > down issues one Classpath Not Found at a time. The directory entries in a Zip archive are not compressed. This makes class names searchable with 'grep -R' on the local repository. If you download and compile a lot of OSS projects that use Maven, chances are your repository has most of the dependencies you would normally want to use already in it. Alternately, to speed inquiries on jar contents, I use http://mvnrepository.com. Once one drills down to the page for a specific version of a dependency, the package structure of the contents is displayed. It's a lot easier than constantly doing 'jar tvf ' to see what's in there, and there's a bunch of additional information about the dependency on that page too. It only works for jars in the central repo though, and sadly, there are a few things that could be made a lot nicer, but the authors have a full email box and apparently do not want to be bothered. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Figuring out the proper Maven dependency setting
On 10/11/2010 3:40 PM, marshall wrote:
Hi;
This is probably a beginner question, but I thought it was worth posing
because it is frequently very frustrating when working with Maven.
Is there a clear way to know which particular dependencies Maven requires,
when working with a set of jars/libraries?
For example, I have been trying to get JPA and Hibernate configured properly
in the pom.xml. I have tried so many different variations of dependencies
(hibernate, hibernate-core, javax.persistence, JPA, MySQL, etc.) that I finally
just threw up my hands in frustration.
I can get a Hibernate/JPA/MySQL application working just fine without Maven,
but when I try to integrate Maven I'm lost as to which dependencies it needs.
They seem to be different than the jars/libraries I specify in the classpath
for a non-Maven build.
Thanks;
Mar
We use Hibernate and Mysql all the time in Maven and have no problem
specifying the versions
As you can see below, we only need 3 dependencies to get enough to make
it all run and one of them is a connector for MS-SQL which we use
against a remote database at another company.
This POM controls the dependencies of Hibernate and Mysql. It is mostly
exclusions to stop old versions of libraries from being dragged in by
mistake.
It took a bit of doing to get these the first time but it is nice now
that we do not have a screen full of conflicting version notes.
This is used as a dependency of other similar POMs until we get a POM
that contains the major framwork dependencies
"lms-pom-spring-hibernate-mysql-tomcat" which actual applications depend on.
When we want to change the MySQL connector, we only change it here and
rebuild the other POMs to get everyone in synch.
The developer who is building a web service, servlet or portlet has no
concern about the actual versions of the lower level stuff.
He is building with 1.9.1 of our base and gets whatever is supposed to
be there.
We do the same thing for the Apache commons, CXF, Jasper dependencies,
etc. We have about 10 in total.
Most projects only need 5 or fewer dependencies to get everything and
everything is a lot!
lms - Learning Management System - is the application umbrella.
We can usually release these very early in the project since these do
not change very often but we do build a set of SNAPSHOTs to start.
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
lms-pom-master
com.company.lms
1.9.1
com.company.lms
lms-pom-hibernate-mysql
pom
Hibernate-MySQL
1.9.1
Hibernate and MySQL
3.2.6.ga
5.1.10
1.2.2
org.hibernate
hibernate
${hibernate.version}
commons-logging
commons-logging
commons-collections
commons-collections
asm
asm
cglib
cglib
antlr
antlr
jta
javax.transaction
dom4j
dom4j
mysql
mysql-connector-java
${mysql-connector-java.version}
net.sourceforge.jtds
jtds
${jtds.version}
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Figuring out the proper Maven dependency setting
I would be curious if you could unpack you app and just replace the JARs with ones from Maven repo's and have it still work. I can't tell you how projects I've encountered where I cannot figure what version a JAR is or where it came from. I am sure I have seen hand modified JAR lumping packages together or JARs from IDE libraries that aren't intended for distribution. I have used the technique described here but I have also had too to forensic type package level comparisons to try an find matches. Eventually slugging our way through namespace collisions and knocking down issues one Classpath Not Found at a time. > -Original Message- > From: Brian Topping [mailto:topp...@codehaus.org] > Sent: Wednesday, November 10, 2010 3:49 PM > To: Maven Users List > Subject: Re: Figuring out the proper Maven dependency setting > > > On Nov 10, 2010, at 3:40 PM, marshall wrote: > > > Hi; > > This is probably a beginner question, but I thought it was > worth posing because it is frequently very frustrating when > working with Maven. > > Is there a clear way to know which particular dependencies > Maven requires, when working with a set of jars/libraries? > > This isn't as much a Maven question as it is a question on > the organizations that package the dependencies, but here's > some info. Dependencies typically depend on other > dependencies, and one eventually gets a transitive closure of > dependencies. You can see this in your build by running 'mvn > dependency:tree'. This will show you a tree of who is pulling > in what, and help make decisions on what to pull in at the > top level and what you can ignore. > > For instance, if you used to pull in asm for use with > Hibernate, you can stop doing that, because the Hibernate > dependency you choose will know better what exact version it > was compiled at. If you need a specific version of asm for > your own needs, this is where things get more complicated. > > These problems existed before Maven though. Maven just gives > you a bigger, more efficient gun to shoot yourself in the foot with. > > Hope that helps... > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Figuring out the proper Maven dependency setting
+1 > -Original Message- > From: Brian Topping [mailto:topp...@codehaus.org] > Sent: Wednesday, November 10, 2010 3:49 PM > To: Maven Users List > Subject: Re: Figuring out the proper Maven dependency setting > > > On Nov 10, 2010, at 3:40 PM, marshall wrote: > > > Hi; > > This is probably a beginner question, but I thought it was > worth posing because it is frequently very frustrating when > working with Maven. > > Is there a clear way to know which particular dependencies > Maven requires, when working with a set of jars/libraries? > > This isn't as much a Maven question as it is a question on > the organizations that package the dependencies, but here's > some info. Dependencies typically depend on other > dependencies, and one eventually gets a transitive closure of > dependencies. You can see this in your build by running 'mvn > dependency:tree'. This will show you a tree of who is pulling > in what, and help make decisions on what to pull in at the > top level and what you can ignore. > > For instance, if you used to pull in asm for use with > Hibernate, you can stop doing that, because the Hibernate > dependency you choose will know better what exact version it > was compiled at. If you need a specific version of asm for > your own needs, this is where things get more complicated. > > These problems existed before Maven though. Maven just gives > you a bigger, more efficient gun to shoot yourself in the foot with. > > Hope that helps... > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Figuring out the proper Maven dependency setting
On Nov 10, 2010, at 3:40 PM, marshall wrote: > Hi; > This is probably a beginner question, but I thought it was worth posing > because it is frequently very frustrating when working with Maven. > Is there a clear way to know which particular dependencies Maven requires, > when working with a set of jars/libraries? This isn't as much a Maven question as it is a question on the organizations that package the dependencies, but here's some info. Dependencies typically depend on other dependencies, and one eventually gets a transitive closure of dependencies. You can see this in your build by running 'mvn dependency:tree'. This will show you a tree of who is pulling in what, and help make decisions on what to pull in at the top level and what you can ignore. For instance, if you used to pull in asm for use with Hibernate, you can stop doing that, because the Hibernate dependency you choose will know better what exact version it was compiled at. If you need a specific version of asm for your own needs, this is where things get more complicated. These problems existed before Maven though. Maven just gives you a bigger, more efficient gun to shoot yourself in the foot with. Hope that helps... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
