RE: Why do we need POMs in repo for non-Maven projects?
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]
RE: Why do we need POMs in repo for non-Maven projects?
> -Original Message- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: Monday, June 14, 2004 6:30 AM > To: 'Maven Developers List' > Subject: RE: Why do we need POMs in repo for non-Maven projects? > > > 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. > No. Dependency Report may show project's own dependencies, inherited ones and those resolved by transitive dependencies collector. We might even show a graph of dependencies (nice looking gif image or svg ) > 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. > We have discussed this a bit but nothing is yet decided. I guess that there might be couple of different strategies and some "version clashes" might be resolved automatically. E.g. when one of the projects stated dependency on log4j-1.2.7.jar and other one on log4j-1.2.8.jar we might be able to determine that those versions are compatible and 1.2.8 is the newer one. First we have to see how this really works and to have some real use cases - so we need more POMs. The problem might be that at the beginning we will be getting "fat" POMs with all dependencies in them so the full picture will be falsify. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why do we need POMs in repo for non-Maven projects?
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]
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]
Re: Why do we need POMs in repo for non-Maven projects?
Sure, but dependencies don't necessarily mean build-time stuff. My project might depend on NonMavenProject-A, which also depends on NonMavenProject-B. So, I build my project against their NonMavenProject-A.jar file, and then to *use* my project at runtime, I have to include NonMavenProject-B.jar in my CLASSPATH. That's where I see transitive dependencies for non-maven projects to be nice. Though, I can understand creating POMs might be a hassle. Perchance we should also allow for some simplified runtime-dependencies.txt or something, that simply enumerates the non-maven project's runtime dependencies? -bob On Sun, 13 Jun 2004, Vincent Massol wrote: > Hi, > > A stupid question: Why do we need POMs in repo for non-Maven projects? > > It seems to me, this is for supporting transitive dependencies. 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? > > I'm asking because it's a pain to get POMs for non-Maven projects and > I'm not sure about the benefit. > > Shouldn't non-Maven projects artifacts considered as already *built*? > > Thanks > -Vincent > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Bob McWhirter[EMAIL PROTECTED] The Werken Company http://werken.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
