Or if you are checking them in manually, at least use a different version which includes your company name, e.g.
<groupId>commons-logging</groupId> <artifactId>commins-logging</artifactId> <version>1.0-mycompany-1</version> That way maven will at least detect that these are different versions of the same artifact and the version ranges and preferences should* let you pick your one! -Stephen * Yes I know some people have issues with version ranges, etc. but there are ways of making them work, or at least using a dependencyManagement section On Jan 31, 2008 4:07 PM, Wayne Fay <[EMAIL PROTECTED]> wrote: > 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] > >
