ok. Cool. Thanks for the information. I understand better now. How do we deal with different versions of the same artifact in the dependency list?
It seems to me that once we get transitive dependencies, we'll have lots of "clashes" between different versions of the same artifacts. How will Maven resolve this? The user will also not know this beforehand as dependencies will be hidden from him. One solution could be that Maven refuse to run when there are conflicting dependencies and users will have to explicitely state which dependency to user in their project.xml (it will have preference over the transitive dependency versions)? I understand you probably have discussed this at length. If you have a pointer feel free to give me a link. Thanks -Vincent > -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: 14 June 2004 01:00 > To: Maven Developers List > Subject: Re: Why do we need POMs in repo for non-Maven projects? > > On Sun, 2004-06-13 at 14:11, Vincent Massol wrote: > > Hi, > > > > A stupid question: Why do we need POMs in repo for non-Maven projects? > > Those non-maven projects have dependencies and projects who state a > dependency on that non-maven project can take advantage of transitive > dependencies and any other dependency tools that might exist. Hibernate, > for example, may not be mavenized but it has a lot of deps that users > would prefer not to have to worry about entering into their POMs. > > > It seems to me, this is for supporting transitive dependencies. > > For that alone it is worth it, but who knows what other sorts of > analysis tools might be developed. > > But the most important pieces of information are the groupId, > artifactId. Those pieces of information are required otherwise we don't > know where to put them in the repository. Once the tools are automated > the POM is where the information will be extracted from in order to > place the artifact in the correct location in the central repository. > Right now we only require a copy of the license but the license > information will also soon be mandatory in order to perform some > analysis wrt licensing. > > > However > > Maven will not try to build non-Maven projects, right? Is there a use > > case where it's still useful to have POM information for non-Maven > > projects? > > A POM is needed, period. If there is no POM the artifact is not going to > Ibiblio and it's as simple as that. Once the process is more fully > automated projects without POMs will just get rejected. > > > I'm asking because it's a pain to get POMs for non-Maven projects and > > I'm not sure about the benefit. > > It is simply required for proper placement, and transitive dependencies > alone make the POM requirement worthwhile. In addition a POM with > groupId, artifactId and dependencies the project can be built by Maven > and dragged into any maven-based CI mechanism which also has benefits. > > > Shouldn't non-Maven projects artifacts considered as already *built*? > > That's really irrelevant to requirement of needing the POM for an > upload. We are close to not requiring any direct access to ibiblio and > meeper will take care of most things. This will be safer, there will be > better auditing and there won't be a many glitches due to people placing > stuff in the repo manually. Every one of us with direct access to > ibiblio has fubar'd something at one point or another and it just can't > happen now that Maven is rapidly approaching critical mass. > > > Thanks > > -Vincent > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://maven.apache.org > > happiness is like a butterfly: the more you chase it, the more it will > elude you, but if you turn your attention to other things, it will come > and sit softly on your shoulder ... > > -- Thoreau > > > --------------------------------------------------------------------- > 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]
