I'll give you a concrete example of why I want those POM's. I have a plugin goal that I wrote for my plugin that compares my plugins version against all the repo's that it can find, looking for a newer (only numeric, no rc/beta/etc) version of the project. If it finds it, it prints out to the user "There is a newer version available at http://blahblah that you should download". This is to keep users updating their custom plugins.
I am taking the same approach and trying to apply it to ALL my project dependencies.. Commons-logging-1.0.4 was just released. The goal spits back a report that says "Commons-logging-1.0.3 appears to have been updated to 1.0.4 on http://blahblah";. If I have non maven project POM's, I can check those as well as the maven ones. Eventually I hope the report will tell me where I don't have the latest dependencies, as well as which components I have use differeing versions of dependencies. Eric Pugh > -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Sunday, June 13, 2004 9:30 PM > 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]
