We've had more than one person show up on this list complaining about strange difficulties with Maven. After a bit of prodding, they tell us that they manually created their repo and the pom files, if they exist at all, are just GAV with no transitive deps. And then they're usually complaining about how Maven isn't working like they expected.
I just want to make sure this happens to as few people as possible. If you know what you're doing and want to check-in some files, please do it, especially for things like Websphere and Weblogic that will never appear in the Central repo. But doing this for things like commons-* is a bad practice. Even if you know what you're doing, you probably should not be checking in files like these manually. Wayne On 1/31/08, Simon Kitching <[EMAIL PROTECTED]> wrote: > I've certainly done something similar in the past. To reduce network traffic, > and to better control what libs are used, it is nice to have a repository on > a local server hosting the jars you need. > > It is very tempting to just take the set of jars you have always been using > (in an existing ant-based build process or similar) and just upload them to > that new repository. It is certainly easier than finding a maven repository > proxy application, and setting that up. > > I don't see a lot wrong with doing that - except that you do need to get the > group ids right! > > Of course long-term, having a proper repository manager installed locally > appears to be the right solution. Some day I have to get that organised for > my workplace... > > Interesting to see that the war plugin does detect filename clashes; as > discussed in another thread recently it appears that the dependency plugin > does not... > > Regards, > Simon > > ---- Wayne Fay <[EMAIL PROTECTED]> schrieb: > > If you're using "mvn install" or "mvn deploy" to install/deploy common > > artifacts like commons-logging etc, then you're probably using Maven > > wrong. > > > > What you've described is exactly what the problem was. You had added > > c-l as a particular G/A/V and then c-l was coming in as a transitive > > dep under a different G/A/V. Since the plugin detected a name > > collision, it expanded the name to include the group as well, to make > > it unique. > > > > Why did you install/deploy commons-logging instead of simply adding a > > <dependency>? You're not the first person to report doing this, so I > > want to understand if there is a failure in the documentation > > somewhere or if new users are simply making poor assumptions about > > what Maven does. > > > > Wayne > > > > On 1/31/08, amit kumar <[EMAIL PROTECTED]> wrote: > > > I have overcome the problem. And guess know the reason for that, > > > actually at the time of creating the LAN maven repository, I have > > > installed common components under org.apache.commons groupId ( > > > assuming the convention of groupId as package name ). So now when I > > > was including commons-logging as dependency in my pom.xml, > > > what I added to pom looked like > > > > > > <groupId>org.apache.commons</groupId> > > > <artifactId>commons-logging</artifactId> > > > <version>1.1</version> > > > > > > But there was another dependency in my pom.xml which as > > > commons-logging as transitive dependency with same version, so what > > > was happening(probably) was that maven instead of overriding the jar > > > file was renaming it, may be because the jars were differently > > > identified as groupId+artifactId+version. > > > Still a little confused about my own explanation of the happenings :) > > > > > > Amit > > > > > > On Jan 30, 2008 9:51 PM, Olivier Lamy <[EMAIL PROTECTED]> wrote: > > > > Looks weird. > > > > Do you use a released version ? or the current snapshot ? > > > > > > > > Could you load an issue in jira with a simple project which reproduce > > > > this ? > > > > > > > > -- > > > > Olivier > > > > > > > > 2008/1/30, amit kumar <[EMAIL PROTECTED]>: > > > > > > > > > Hi,. > > > > > When I am packaging a WAR project, I am seeing the following thing > > > > > happening... > > > > > > > > > > [DEBUG] Processing: commons-logging-1.1.jar > > > > > [DEBUG] Duplicate found: commons-logging-1.1.jar > > > > > [DEBUG] Renamed to: commons-logging-commons-logging-1.1.jar > > > > > > > > > > Any idea why this happens and how to avoid this? > > > > > I am mentioning commons-logging-1.1 as my dependency in the pom.xml, > > > > > and have suppressed the other versions of commons logging which were > > > > > getting packaged as transitive dependencies of project dependencies > > > > > using <exclusion> tag in dependency taf. Same is happening with > > > > > commons-digester and other dependencies. > > > > > > > > > > > > > > > Regards, > > > > > Amit > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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] > > > > > --------------------------------------------------------------------- > 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]
