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]
