Actually all that happened ( installing commons into the LAN repository ) on the second day of i started using maven(2nd week of my first job :) ), there has been a strict deadline for that. But anyways I guess these are just lame excuses for misusing maven(unintentional), but at that time thats' what I thought it is like(which could be wrong). And my experience with groupId's has always been confusing, at places it is the package name while others artifactId and groupId becomes the same. That amplified the motivation to commit the mistake, and there are few commons artifacts being used here at my workplace which are not there in the repo1.maven.org ( i.e. commons-email-1.0-mod.jar).
But I believe everyone learns with time, and learning is best when it comes from the mistakes you commit. Thanks for the help. Regards, Amit On Jan 31, 2008 1:57 PM, Stephen Connolly <[EMAIL PROTECTED]> wrote: > 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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
