PR verification
Hi folks, has anyone of you already noticed this plugin? https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin This might automate the test for a PR as Jason wants. Any thoughts? Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request: [MNG-4565] Multiple profile activation conditi...
Github user ChristianSchulte commented on the pull request: https://github.com/apache/maven/pull/20#issuecomment-46546268 Another option would be to provide support for activations based on some language like: activation expressionOS IS 'Linux' AND ( PROPERTY 'Some Name' IS 'true' OR JDK IS '1.6 )/expression /activation Maybe some scripting language provided by the platform ScriptEngine. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Apache Maven EAR Plugin 2.9.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven EAR Plugin, version 2.9.1 This plugin (insert short description of the plugin's purpose). http://maven.apache.org/plugins/maven-ear-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId version2.9.1/version /plugin Release Notes - Maven EAR Plugin Plugin - Version 2.9.1 Bug * [MEAR-189] - fileNameMapping set to no-version breaks skinnyWars feature Task * [MEAR-185] - Deprecated reference to 'defaultJavaBundleDir' in plugin documentation Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request: [MNG-4565] Multiple profile activation conditi...
Github user ChristianSchulte commented on the pull request: https://github.com/apache/maven/pull/20#issuecomment-46547866 Could be as simple as: ``` activation script engine-name= || extension= || mime-type=simple script evaluating to a boolean/script /activation ``` 'engine-name' translates to javax.script.ScriptEngine.getEngineByName() 'extension' translates to javax.script.ScriptEngine.getEngineByExtension() 'mime-type' translates to javax.script.ScriptEngine.getEngineByMimeType() All you need to do is populating the corresponding script engine scope with some pre-defined values. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Apache Maven JAR Plugin version 2.5
Hi, We solved 10 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11137version=18297 There are still 38 issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D%20MJAR%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1026 http://repository.apache.org/content/repositories/maven-1026/org/apache/maven/plugins/maven-jar-plugin/2.5/maven-jar-plugin-2.5-source-release.zip Source release checksum(s): maven-jar-plugin-2.5-source-release.zip sha1: 2038a00885ce34e560e2b3f3968a5fadaa2ca785 Staging site: http://maven.apache.org/plugins-archives/maven-jar-plugin-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Apache Maven EAR Plugin 2.9.1 Released
Hi, is someone of the maven-pmc members so kind to publish the plugin to the dist area and add it to the board report. Many thanks in advance. Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MNG Roadmap in JIRA
Hi, project too. Right now it's Maven 2 3. It can either be Maven 3 or simply Maven. Thoughts? Good point, clean up the JIRA frontpage of MNG. Do you have the permission to do so? If yes, please proceed for Maven. +1 the Jira project description can be administered like other items So changed the Name of the project to Maven simply... Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request: [MNG-4565] Multiple profile activation conditi...
Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/20#issuecomment-46555048 I think Christian's idea is better as the logic is contained to the specific activator. I'm not keen at all to add conditional logic to the POM model anywhere, or any type of expression language being required for the POM 4.0.0 model or general XML model. Maybe an activator using MVEL would work well. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Evolving the POM format
We had the hangout yesterday. I pushed the initial bit of information about evolving the POM format here in a blog post here: http://localhost:4000/2014/06/19/hangout-pom-format.html And created a page in the Wiki to start capturing the information: https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare
Re: Evolving the POM format
Jason, I am sure accessing your localhost is blocked :-) Cheers, Paul On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl ja...@takari.io wrote: We had the hangout yesterday. I pushed the initial bit of information about evolving the POM format here in a blog post here: http://localhost:4000/2014/06/19/hangout-pom-format.html And created a page in the Wiki to start capturing the information: https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare
Re: Evolving the POM format
The links are broken due to use of localhost. Gary On Thu, Jun 19, 2014 at 9:40 AM, Jason van Zyl ja...@takari.io wrote: We had the hangout yesterday. I pushed the initial bit of information about evolving the POM format here in a blog post here: http://localhost:4000/2014/06/19/hangout-pom-format.html And created a page in the Wiki to start capturing the information: https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: Evolving the POM format
I could not make it for hangout, and got a message by google that hangout was canceled? Where is a link of the recording, if any? Thanks, ~t~ On Thu, Jun 19, 2014 at 3:40 PM, Jason van Zyl ja...@takari.io wrote: We had the hangout yesterday. I pushed the initial bit of information about evolving the POM format here in a blog post here: http://localhost:4000/2014/06/19/hangout-pom-format.html And created a page in the Wiki to start capturing the information: https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare
Re: Evolving the POM format
Ah, both localhost and recording problem solved. The proper link is http://takari.io/2014/06/19/hangout-pom-format.html On Thu, Jun 19, 2014 at 3:45 PM, Tamás Cservenák ta...@cservenak.net wrote: I could not make it for hangout, and got a message by google that hangout was canceled? Where is a link of the recording, if any? Thanks, ~t~ On Thu, Jun 19, 2014 at 3:40 PM, Jason van Zyl ja...@takari.io wrote: We had the hangout yesterday. I pushed the initial bit of information about evolving the POM format here in a blog post here: http://localhost:4000/2014/06/19/hangout-pom-format.html And created a page in the Wiki to start capturing the information: https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare
Re: Evolving the POM format
Sorry I use Jekyll locally, the actual link is: http://takari.io/2014/06/19/hangout-pom-format.html On Jun 19, 2014, at 9:43 AM, Paul Benedict pbened...@apache.org wrote: Jason, I am sure accessing your localhost is blocked :-) Cheers, Paul On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl ja...@takari.io wrote: We had the hangout yesterday. I pushed the initial bit of information about evolving the POM format here in a blog post here: http://localhost:4000/2014/06/19/hangout-pom-format.html And created a page in the Wiki to start capturing the information: https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare
Re: Evolving the POM format
Thanks Jason, it was fun, we have been thinking about organizing something like this for Jetty for a while now, maybe get Greg to go through the new http/2 implementation and talk about the latest draft...things like that. anyway, good fun! jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Jun 19, 2014 at 8:46 AM, Jason van Zyl ja...@takari.io wrote: Sorry I use Jekyll locally, the actual link is: http://takari.io/2014/06/19/hangout-pom-format.html On Jun 19, 2014, at 9:43 AM, Paul Benedict pbened...@apache.org wrote: Jason, I am sure accessing your localhost is blocked :-) Cheers, Paul On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl ja...@takari.io wrote: We had the hangout yesterday. I pushed the initial bit of information about evolving the POM format here in a blog post here: http://localhost:4000/2014/06/19/hangout-pom-format.html And created a page in the Wiki to start capturing the information: https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request: [MNG-4565] Multiple profile activation conditi...
Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/20#issuecomment-46562788 @mikebrock Do you think MVEL would be suitable for a one expression evaluator for a Maven profile activator? Imagine putting a MavenProject/pom.xml in the MVEL context and doing some boolean evaluation. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MNG Roadmap in JIRA
I am thinking the older versions in JIRA should also be archived (i.e., taken off the road map). That's still on the todo list, right? Cheers, Paul On Thu, Jun 19, 2014 at 7:40 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, project too. Right now it's Maven 2 3. It can either be Maven 3 or simply Maven. Thoughts? Good point, clean up the JIRA frontpage of MNG. Do you have the permission to do so? If yes, please proceed for Maven. +1 the Jira project description can be administered like other items So changed the Name of the project to Maven simply... Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Evolving the POM format
While the time of day is perfect for me, the day of week being Wed is exactly wrong for me... I have a weekly meeting at that exact time. Some thoughts on evolving the pom. - We need to deploy the 4.0.0 compatible pom no matter what we do. Full stop. - Igor is *mostly* right in that we should not deploy the pom that is used to build to the repository... - Where Igor is wrong is that for packagingpom/packaging we should actually deploy the build time pom to the repository... probably with the classifier `build`... this is safe as `pom` does cannot have a classifier in model version 4.0.0. - You couple that with a simple and obvious restriction... your parent must be the same or earlier version of Maven. You cannot have as a parent a newer version of Maven than the child is built with. - So that leaves the 4.0.0 compatible pom only detailing dependencies... there are some concepts that we need to introduce that cannot be handled in 4.0.0 model: * provides concept, i.e. this artifact is equivalent to another artifact... so that you can remove artifacts from the dependency tree *of consumers* sensibly without needing to add excludes everywhere. So for example org.mortbay.jetty:servlet-api:3.0.20100224 could say it provides javax.servlet:servlet-api:3.0 and thus if I have a direct dependency on org.mortbay.jetty:servlet-api:3.0.20100224 then Maven will know that any of my other dependencies that have a transitive dependency on javax.servlet:servlet-api:3.0 can have that dependency purged from the tree. The provides concept can be transitive depending on the scope of the dependency... probably need a new scope to reflect a dependency being included in an überjar style. So a provided dependency would not add a provides entry... but a bundled dependency would. * runtimes concept, in some ways this can be handled by using dependencies... in other words we can create a pseudo dependency at java.lang:specification with versions 1.1, 1.2, 1.3, 1.4, 5.0, 6.0, 7.0, 8.0, etc and use that dependency to indicate the byte code version that you require. Similarly a pseudo dependency could handle the java.lang:runtime to cover the runtime library requirements... here provides is a great help as those features that are included in different versions of the JRE but available via standalone dependencies can be covered with provides in those pseudo poms. The actual jars can be empty. This should work for android too as the android runtime can be considered as a snapshot of the java one for a specific version. The downside with the dependency approach is that we loose out on enforcement policies... OTOH perhaps we can use the pseudo dependencies as a way of mapping the information back. On 19 June 2014 14:50, Jesse McConnell jesse.mcconn...@gmail.com wrote: Thanks Jason, it was fun, we have been thinking about organizing something like this for Jetty for a while now, maybe get Greg to go through the new http/2 implementation and talk about the latest draft...things like that. anyway, good fun! jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Thu, Jun 19, 2014 at 8:46 AM, Jason van Zyl ja...@takari.io wrote: Sorry I use Jekyll locally, the actual link is: http://takari.io/2014/06/19/hangout-pom-format.html On Jun 19, 2014, at 9:43 AM, Paul Benedict pbened...@apache.org wrote: Jason, I am sure accessing your localhost is blocked :-) Cheers, Paul On Thu, Jun 19, 2014 at 8:40 AM, Jason van Zyl ja...@takari.io wrote: We had the hangout yesterday. I pushed the initial bit of information about evolving the POM format here in a blog post here: http://localhost:4000/2014/06/19/hangout-pom-format.html And created a page in the Wiki to start capturing the information: https://cwiki.apache.org/confluence/display/MAVEN/Evolving+the+POM+Format Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Evolving the POM format
On 2014-06-19, 10:30, Stephen Connolly wrote: - Igor is*mostly* right in that we should not deploy the pom that is used to build to the repository... - Where Igor is wrong is that for packagingpom/packaging we should actually deploy the build time pom to the repository... probably with the classifier `build`... this is safe as `pom` does cannot have a classifier in model version 4.0.0. - You couple that with a simple and obvious restriction... your parent must be the same or earlier version of Maven. You cannot have as a parent a newer version of Maven than the child is built with. I think there is more to this. At very least we need to decide what to do with parent in 4.0.0 compatible poms. Maybe we should always deploy effective pom with build-related elements removed. I am also not sure if it is enough to deploy build parent poms as is. Your suggested parent must be the same or earlier version of Maven implies new versions of Maven can read older pom formats, which I think will significantly limit our flexibility to evolve pom format. I wonder if we can have different solution for force parent poms, like org.apache:apache, which are used by multiple projects and different versions of maven and project-specific parent poms, where it is much easier to require specific version of maven. -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Evolving the POM format
On 19 June 2014 15:48, Igor Fedorenko i...@ifedorenko.com wrote: On 2014-06-19, 10:30, Stephen Connolly wrote: - Igor is*mostly* right in that we should not deploy the pom that is used to build to the repository... - Where Igor is wrong is that for packagingpom/packaging we should actually deploy the build time pom to the repository... probably with the classifier `build`... this is safe as `pom` does cannot have a classifier in model version 4.0.0. - You couple that with a simple and obvious restriction... your parent must be the same or earlier version of Maven. You cannot have as a parent a newer version of Maven than the child is built with. I think there is more to this. At very least we need to decide what to do with parent in 4.0.0 compatible poms. Maybe we should always deploy effective pom with build-related elements removed. Well I think the simple thing is that the 4.0.0 pom is fully resolved when you have a builder pom I am also not sure if it is enough to deploy build parent poms as is. Your suggested parent must be the same or earlier version of Maven implies new versions of Maven can read older pom formats, which I think will significantly limit our flexibility to evolve pom format. They need to be able to parse it into the model. Perhaps they do the parsing by downloading a parser. But I think it is reasonable to expect that we can convert older build pom formats into newer ones and just let Maven take care of it... if we cannot do that then we are really creating a brand new build tool rather than evolving Maven I wonder if we can have different solution for force parent poms, like org.apache:apache, which are used by multiple projects and different versions of maven and project-specific parent poms, where it is much easier to require specific version of maven. Well the simple way is we have deployed the 4.0.0 parent pom as org.apache:apache:14:pom if you want to upgrade your parent to org.apache:apache:15 then you will need to require Maven 4.0+ to build. If you don't want to upgrade your build time requirements, then don't upgrade the parent... and if we need to fix things in the parent for 4.0.0 consumers, we can always deploy org.apache:apache:14.1 as a newer 4.0.0 model pom -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Evolving the POM format
I am curious why you interoperability as a requirement? Perhaps questioning that may seem outrageous, but I see no problem with saying that you need to upgrade to Maven X.Y to read newer POM formats. If a vendor wants to backport their project into older POM formats, that should be the vendor's shoulders and not be a concern of Maven core. If Maven does publish older formats of POMs, you then have to decide how many older formats do you want to publish? One day there will be a 4.1 or 5.0, and it's going to complicate the world if Maven takes on the burden of interoperability. Cheers, Paul On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 19 June 2014 15:48, Igor Fedorenko i...@ifedorenko.com wrote: On 2014-06-19, 10:30, Stephen Connolly wrote: - Igor is*mostly* right in that we should not deploy the pom that is used to build to the repository... - Where Igor is wrong is that for packagingpom/packaging we should actually deploy the build time pom to the repository... probably with the classifier `build`... this is safe as `pom` does cannot have a classifier in model version 4.0.0. - You couple that with a simple and obvious restriction... your parent must be the same or earlier version of Maven. You cannot have as a parent a newer version of Maven than the child is built with. I think there is more to this. At very least we need to decide what to do with parent in 4.0.0 compatible poms. Maybe we should always deploy effective pom with build-related elements removed. Well I think the simple thing is that the 4.0.0 pom is fully resolved when you have a builder pom I am also not sure if it is enough to deploy build parent poms as is. Your suggested parent must be the same or earlier version of Maven implies new versions of Maven can read older pom formats, which I think will significantly limit our flexibility to evolve pom format. They need to be able to parse it into the model. Perhaps they do the parsing by downloading a parser. But I think it is reasonable to expect that we can convert older build pom formats into newer ones and just let Maven take care of it... if we cannot do that then we are really creating a brand new build tool rather than evolving Maven I wonder if we can have different solution for force parent poms, like org.apache:apache, which are used by multiple projects and different versions of maven and project-specific parent poms, where it is much easier to require specific version of maven. Well the simple way is we have deployed the 4.0.0 parent pom as org.apache:apache:14:pom if you want to upgrade your parent to org.apache:apache:15 then you will need to require Maven 4.0+ to build. If you don't want to upgrade your build time requirements, then don't upgrade the parent... and if we need to fix things in the parent for 4.0.0 consumers, we can always deploy org.apache:apache:14.1 as a newer 4.0.0 model pom -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Evolving the POM format
On Jun 19, 2014, at 11:24 AM, Paul Benedict pbened...@apache.org wrote: I am curious why you interoperability as a requirement? Perhaps questioning that may seem outrageous, but I see no problem with saying that you need to upgrade to Maven X.Y to read newer POM formats. To build a project that is certainly fine. If a project starts using a Ruby-based POM you will need a newer version of Maven to build the project. The issue of interoperability arises when projects that want to use what was built by the project using the Ruby-based POM. Say the Guice project starts using a Ruby-based POM: you do not want to force everyone who uses Guice to use a version of Maven that has the capability to read a Ruby-based POM. I think it would be an enormously limiting move to require that. Build with whatever you want but let's make it easy to consume for everyone which means making those dependencies usable by all the existing versions of Maven. The build-time information is mostly, if not completely, irrelevant at consumption time. If a vendor wants to backport their project into older POM formats, that should be the vendor's shoulders and not be a concern of Maven core. If Maven does publish older formats of POMs, you then have to decide how many older formats do you want to publish? One day there will be a 4.1 or 5.0, and it's going to complicate the world if Maven takes on the burden of interoperability. Cheers, Paul On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 19 June 2014 15:48, Igor Fedorenko i...@ifedorenko.com wrote: On 2014-06-19, 10:30, Stephen Connolly wrote: - Igor is*mostly* right in that we should not deploy the pom that is used to build to the repository... - Where Igor is wrong is that for packagingpom/packaging we should actually deploy the build time pom to the repository... probably with the classifier `build`... this is safe as `pom` does cannot have a classifier in model version 4.0.0. - You couple that with a simple and obvious restriction... your parent must be the same or earlier version of Maven. You cannot have as a parent a newer version of Maven than the child is built with. I think there is more to this. At very least we need to decide what to do with parent in 4.0.0 compatible poms. Maybe we should always deploy effective pom with build-related elements removed. Well I think the simple thing is that the 4.0.0 pom is fully resolved when you have a builder pom I am also not sure if it is enough to deploy build parent poms as is. Your suggested parent must be the same or earlier version of Maven implies new versions of Maven can read older pom formats, which I think will significantly limit our flexibility to evolve pom format. They need to be able to parse it into the model. Perhaps they do the parsing by downloading a parser. But I think it is reasonable to expect that we can convert older build pom formats into newer ones and just let Maven take care of it... if we cannot do that then we are really creating a brand new build tool rather than evolving Maven I wonder if we can have different solution for force parent poms, like org.apache:apache, which are used by multiple projects and different versions of maven and project-specific parent poms, where it is much easier to require specific version of maven. Well the simple way is we have deployed the 4.0.0 parent pom as org.apache:apache:14:pom if you want to upgrade your parent to org.apache:apache:15 then you will need to require Maven 4.0+ to build. If you don't want to upgrade your build time requirements, then don't upgrade the parent... and if we need to fix things in the parent for 4.0.0 consumers, we can always deploy org.apache:apache:14.1 as a newer 4.0.0 model pom -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa
Re: Evolving the POM format
I definitely agree that there should be two kinds of POMs: building and consuming. Those are two separate concerns and there's no reason to pollute dependency consumption with build information (or site information!). I am on board with separating the two out. When it comes to evolving the building POM, that's clear cut: upgrade to the Maven X.Y that can read that kind of POM. However, you're still stuck (for a lack of better word) with evolving the POM that everyone consumes, as I said, due to (i) how far back in time you want to support and (ii) publishing all the formats that could exist. Here is my armchair idea to give for consideration: 1) The POM reading code is refactored out of core and becomes a plugin that runs in a new phase at the very beginning (before validate). Either the plugin supports all POM versions, there exists a plugin per specific POM version, or it's configurable which versions you want to read. 2) At publish to repo time, for whatever plugin actually generate the consuming POM, the builder configures how many POM versions he wants to publish: 3.x, 4.0, 4.1, etc. My idea is not to force either party into saying I must read or write umpteen formats. Leave it all to the builder and consumer to decide which are important to each respective use cases. Paul Cheers, Paul On Thu, Jun 19, 2014 at 10:32 AM, Jason van Zyl ja...@takari.io wrote: On Jun 19, 2014, at 11:24 AM, Paul Benedict pbened...@apache.org wrote: I am curious why you interoperability as a requirement? Perhaps questioning that may seem outrageous, but I see no problem with saying that you need to upgrade to Maven X.Y to read newer POM formats. To build a project that is certainly fine. If a project starts using a Ruby-based POM you will need a newer version of Maven to build the project. The issue of interoperability arises when projects that want to use what was built by the project using the Ruby-based POM. Say the Guice project starts using a Ruby-based POM: you do not want to force everyone who uses Guice to use a version of Maven that has the capability to read a Ruby-based POM. I think it would be an enormously limiting move to require that. Build with whatever you want but let's make it easy to consume for everyone which means making those dependencies usable by all the existing versions of Maven. The build-time information is mostly, if not completely, irrelevant at consumption time. If a vendor wants to backport their project into older POM formats, that should be the vendor's shoulders and not be a concern of Maven core. If Maven does publish older formats of POMs, you then have to decide how many older formats do you want to publish? One day there will be a 4.1 or 5.0, and it's going to complicate the world if Maven takes on the burden of interoperability. Cheers, Paul On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 19 June 2014 15:48, Igor Fedorenko i...@ifedorenko.com wrote: On 2014-06-19, 10:30, Stephen Connolly wrote: - Igor is*mostly* right in that we should not deploy the pom that is used to build to the repository... - Where Igor is wrong is that for packagingpom/packaging we should actually deploy the build time pom to the repository... probably with the classifier `build`... this is safe as `pom` does cannot have a classifier in model version 4.0.0. - You couple that with a simple and obvious restriction... your parent must be the same or earlier version of Maven. You cannot have as a parent a newer version of Maven than the child is built with. I think there is more to this. At very least we need to decide what to do with parent in 4.0.0 compatible poms. Maybe we should always deploy effective pom with build-related elements removed. Well I think the simple thing is that the 4.0.0 pom is fully resolved when you have a builder pom I am also not sure if it is enough to deploy build parent poms as is. Your suggested parent must be the same or earlier version of Maven implies new versions of Maven can read older pom formats, which I think will significantly limit our flexibility to evolve pom format. They need to be able to parse it into the model. Perhaps they do the parsing by downloading a parser. But I think it is reasonable to expect that we can convert older build pom formats into newer ones and just let Maven take care of it... if we cannot do that then we are really creating a brand new build tool rather than evolving Maven I wonder if we can have different solution for force parent poms, like org.apache:apache, which are used by multiple projects and different versions of maven and project-specific parent poms, where it is much easier to require specific version of maven. Well the simple way is we have deployed the 4.0.0 parent pom as org.apache:apache:14:pom if you want to
Re: Evolving the POM format
If backwards compatible interoperability is not a requirement then:
If I upgrade one module in my multi-module build to Maven 5.1 then I am
forced right then and there to either:
* upgrade all of them to Maven 5.1; or
* remove the module from my multi-module build
Neither of these are a good user experience in my mind. Maven 5.1 should be
able to build a Maven [2.0,5.1] project without modifying the pom... it can
do that by loading shim layers on demand if necessary, but to my thinking
anything less is going to cause issues for users.
So to my thinking we just accept that Maven needs to evolve such that for
every version X.Y of Maven you know that you can build a Maven project from
the range [2.0,X.Y].
If you have a project that has a parent, then the parent must be in a pom
format that buildable by Maven [2.0,${project.prerequisites.maven}], so a
child pom requiring Maven 5.1 to build can have a parent pom that requires
Maven 5.0 to build but not a parent pom requiring Maven 5.2... there may
even be turtles all the way down to an ancestor pom that requires Maven
[2.0,3.0.3] to build (IIRC after 3.0.3 you get things like wildcards in
excludes due to aether injecting bonus functionality... that should have
been a modelVersion bump in the strictest sense... but well it wasn't)
I also think people overestimate how difficult it is to maintain backwards
compatibility.
I have a Jenkins plugin that was written against Hudson 1.96 and I can take
that .hpi file and drop it into Jenkins 1.568 and it still works
unmodified. Similarly I can upgrade a Jenkins installation jumping quite a
large number of versions without issue.
It is possible to evolve and maintain the ability to read older data... is
it easy? well it's not trivial, but it is a disservice to our users if we
don't try
On 19 June 2014 16:24, Paul Benedict pbened...@apache.org wrote:
I am curious why you interoperability as a requirement? Perhaps questioning
that may seem outrageous, but I see no problem with saying that you need to
upgrade to Maven X.Y to read newer POM formats. If a vendor wants to
backport their project into older POM formats, that should be the vendor's
shoulders and not be a concern of Maven core. If Maven does publish older
formats of POMs, you then have to decide how many older formats do you want
to publish? One day there will be a 4.1 or 5.0, and it's going to
complicate the world if Maven takes on the burden of interoperability.
Cheers,
Paul
On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 19 June 2014 15:48, Igor Fedorenko i...@ifedorenko.com wrote:
On 2014-06-19, 10:30, Stephen Connolly wrote:
- Igor is*mostly* right in that we should not deploy the pom that is
used
to build to the repository...
- Where Igor is wrong is that for packagingpom/packaging we should
actually deploy the build time pom to the repository... probably with
the
classifier `build`... this is safe as `pom` does cannot have a
classifier
in model version 4.0.0.
- You couple that with a simple and obvious restriction... your parent
must
be the same or earlier version of Maven. You cannot have as a parent a
newer version of Maven than the child is built with.
I think there is more to this.
At very least we need to decide what to do with parent in 4.0.0
compatible poms. Maybe we should always deploy effective pom with
build-related elements removed.
Well I think the simple thing is that the 4.0.0 pom is fully resolved
when
you have a builder pom
I am also not sure if it is enough to deploy build parent poms as is.
Your suggested parent must be the same or earlier version of Maven
implies new versions of Maven can read older pom formats, which I think
will significantly limit our flexibility to evolve pom format.
They need to be able to parse it into the model. Perhaps they do the
parsing by downloading a parser. But I think it is reasonable to expect
that we can convert older build pom formats into newer ones and just let
Maven take care of it... if we cannot do that then we are really
creating a
brand new build tool rather than evolving Maven
I wonder
if we can have different solution for force parent poms, like
org.apache:apache, which are used by multiple projects and different
versions of maven and project-specific parent poms, where it is much
easier to require specific version of maven.
Well the simple way is we have deployed the 4.0.0 parent pom as
org.apache:apache:14:pom if you want to upgrade your parent to
org.apache:apache:15 then you will need to require Maven 4.0+ to build.
If
you don't want to upgrade your build time requirements, then don't
upgrade
the parent... and if we need to fix things in the parent for 4.0.0
consumers, we can always deploy org.apache:apache:14.1 as a newer 4.0.0
model pom
--
Topics for Maven Development Hangout
I did not make it for the first one, but watched the recording. One topic I'd like to propose is about thing mentioned at very last minutes of the recording: repository tags in POM, smarter protocol between Maven and MRM, etc Should we have some wiki with topic proposals maybe? Thanks, ~t~
Re: Evolving the POM format
Yeah I thought about that... and I don't like it. First off pom reading is not a pure java world. The ship has sailed. There are people parsing the pom using Ruby, people parsing the pom using other languages that don't even run on the JVM. Thus the only common denominator is to provide an XSLT transformation to map the newer XML format down to the older XML format. Publishing all formats is just ridiculous. My proposal, and I have not seen a better one, is to limit ourselves to at most three poms: 1. The 4.0.0 flattened consumer pom 2. The post 4.0.0 flattened consumer pom 3. The build pom So for 1 we know what that will look like. We just change the rules so that it is always flattened, it never has a parent, we strip out some things, we're explicit on dependency exclusions, etc. In other words it makes it as simple as possible for any pom 4.0.0 parser to construct the transitive dependency tree that we believe it should have. All other use is unnecessary. We don't publish a 4.0.0 consumer pom with packagingpom/packaging because * they are unnecessary for other 4.0.0 consumer poms as none of them will reference a parent * it removes the problem of people wanting to use the 4.0.0 consumer poms as a parent, and we are setting the post-modelVersion-4.0.0 rule as your parent must be of a modelVersion = the child's modelVersion For 3, we have no fucking clue what that will look like. I think we need to agree that the first line of it needs some hint as to the model version... but if we stick to the rule that you need a Maven version that is = the model version of the pom you are building to build... well we can always just try all the parsers we have until one of them works... and if it don't work... well we can safely bomb out as you are trying to build with a version of Maven that is too old. Now we have the hard problem, what does 2 look like? Well 2 is produced and consumed by machines only. So I think it will be either json or xml. Both are problematic formats for people to write correctly, but are simple for machines to create and parse. YAML is out in my view as it becomes too tempting for people to try and hand craft... also have you seen the YAML spec? If we go for XML, we need to use namespaces and define up front what to do with unknown namespaces. If we go for JSON, we need to define the extension mechanism and how to handle unknown extensions. Perhaps the simplest thing to do is to have extensions include a flag that says understanding them is mandatory or not. In any case this post 4.0.0 flattened consumer pom only has to worry about expressing dependencies and dependency like constructs (such as platforms/runtimes and provides information). Which poms we deploy depends on the packaging: packaging == pom: deploy build pom only packaging != pom : deploy 4.0.0 consumer pom and post 4.0.0 consumer poms only That is my vision... the bit that I feel worried about is ensuring that we get the post-4.0.0 consumer pom flexible enough that it can handle future stuff that we have not anticipated... as if we get that wrong then 2-3 years down the road we end up with a 4.0.0 consumer pom, a 5.0.0 consumer pom and a post-5.0.0 consumer pom. I would hate to see us deploying 15 different consumer poms just to publish a 1k utility jar On 19 June 2014 16:49, Paul Benedict pbened...@apache.org wrote: I definitely agree that there should be two kinds of POMs: building and consuming. Those are two separate concerns and there's no reason to pollute dependency consumption with build information (or site information!). I am on board with separating the two out. When it comes to evolving the building POM, that's clear cut: upgrade to the Maven X.Y that can read that kind of POM. However, you're still stuck (for a lack of better word) with evolving the POM that everyone consumes, as I said, due to (i) how far back in time you want to support and (ii) publishing all the formats that could exist. Here is my armchair idea to give for consideration: 1) The POM reading code is refactored out of core and becomes a plugin that runs in a new phase at the very beginning (before validate). Either the plugin supports all POM versions, there exists a plugin per specific POM version, or it's configurable which versions you want to read. 2) At publish to repo time, for whatever plugin actually generate the consuming POM, the builder configures how many POM versions he wants to publish: 3.x, 4.0, 4.1, etc. My idea is not to force either party into saying I must read or write umpteen formats. Leave it all to the builder and consumer to decide which are important to each respective use cases. Paul Cheers, Paul On Thu, Jun 19, 2014 at 10:32 AM, Jason van Zyl ja...@takari.io wrote: On Jun 19, 2014, at 11:24 AM, Paul Benedict pbened...@apache.org wrote: I am curious why you interoperability as a requirement? Perhaps questioning that may seem outrageous, but I see no
Re: Topics for Maven Development Hangout
Can we move it to a day of the week other than Wed? as I'd really like to join On 19 June 2014 16:51, Tamás Cservenák ta...@cservenak.net wrote: I did not make it for the first one, but watched the recording. One topic I'd like to propose is about thing mentioned at very last minutes of the recording: repository tags in POM, smarter protocol between Maven and MRM, etc Should we have some wiki with topic proposals maybe? Thanks, ~t~
Re: Topics for Maven Development Hangout
Sure, how about Thursday? We were also thinking of trying to make it earlier in the day for Europeans. It was a scheduling error on my part making it late at night in Europe. On Jun 19, 2014, at 12:08 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Can we move it to a day of the week other than Wed? as I'd really like to join On 19 June 2014 16:51, Tamás Cservenák ta...@cservenak.net wrote: I did not make it for the first one, but watched the recording. One topic I'd like to propose is about thing mentioned at very last minutes of the recording: repository tags in POM, smarter protocol between Maven and MRM, etc Should we have some wiki with topic proposals maybe? Thanks, ~t~ Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks
Re: [ANN] Apache Maven EAR Plugin 2.9.1 Released
done Regards, Hervé Le jeudi 19 juin 2014 14:32:45 Karl Heinz Marbaise a écrit : Hi, is someone of the maven-pmc members so kind to publish the plugin to the dist area and add it to the board report. Many thanks in advance. Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Evolving the POM format
On Jun 19, 2014, at 11:49 AM, Paul Benedict pbened...@apache.org wrote: I definitely agree that there should be two kinds of POMs: building and consuming. Those are two separate concerns and there's no reason to pollute dependency consumption with build information (or site information!). I am on board with separating the two out. When it comes to evolving the building POM, that's clear cut: upgrade to the Maven X.Y that can read that kind of POM. However, you're still stuck (for a lack of better word) with evolving the POM that everyone consumes, as I said, due to (i) how far back in time you want to support and (ii) publishing all the formats that could exist. Here is my armchair idea to give for consideration: 1) The POM reading code is refactored out of core and becomes a plugin that runs in a new phase at the very beginning (before validate). Either the plugin supports all POM versions, there exists a plugin per specific POM version, or it's configurable which versions you want to read. This is effectively how it works already apart from the fact that the specific reader required is not automatically downloaded. The polyglot form of Maven figures out what is needed to read the POM and loads the appropriate extension. Actually being able to have a consumer POM is one of the major blockers for having DSL-based POMs. 2) At publish to repo time, for whatever plugin actually generate the consuming POM, the builder configures how many POM versions he wants to publish: 3.x, 4.0, 4.1, etc. Without enumerating all the the features requested thus far I'm not sure what's actually necessary. I'm collating them all now to see what we have. Without looking through JIRA I can't remember everything that's been requested. I'm going to start from the concretely requested features. My idea is not to force either party into saying I must read or write umpteen formats. Leave it all to the builder and consumer to decide which are important to each respective use cases. Paul Cheers, Paul On Thu, Jun 19, 2014 at 10:32 AM, Jason van Zyl ja...@takari.io wrote: On Jun 19, 2014, at 11:24 AM, Paul Benedict pbened...@apache.org wrote: I am curious why you interoperability as a requirement? Perhaps questioning that may seem outrageous, but I see no problem with saying that you need to upgrade to Maven X.Y to read newer POM formats. To build a project that is certainly fine. If a project starts using a Ruby-based POM you will need a newer version of Maven to build the project. The issue of interoperability arises when projects that want to use what was built by the project using the Ruby-based POM. Say the Guice project starts using a Ruby-based POM: you do not want to force everyone who uses Guice to use a version of Maven that has the capability to read a Ruby-based POM. I think it would be an enormously limiting move to require that. Build with whatever you want but let's make it easy to consume for everyone which means making those dependencies usable by all the existing versions of Maven. The build-time information is mostly, if not completely, irrelevant at consumption time. If a vendor wants to backport their project into older POM formats, that should be the vendor's shoulders and not be a concern of Maven core. If Maven does publish older formats of POMs, you then have to decide how many older formats do you want to publish? One day there will be a 4.1 or 5.0, and it's going to complicate the world if Maven takes on the burden of interoperability. Cheers, Paul On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 19 June 2014 15:48, Igor Fedorenko i...@ifedorenko.com wrote: On 2014-06-19, 10:30, Stephen Connolly wrote: - Igor is*mostly* right in that we should not deploy the pom that is used to build to the repository... - Where Igor is wrong is that for packagingpom/packaging we should actually deploy the build time pom to the repository... probably with the classifier `build`... this is safe as `pom` does cannot have a classifier in model version 4.0.0. - You couple that with a simple and obvious restriction... your parent must be the same or earlier version of Maven. You cannot have as a parent a newer version of Maven than the child is built with. I think there is more to this. At very least we need to decide what to do with parent in 4.0.0 compatible poms. Maybe we should always deploy effective pom with build-related elements removed. Well I think the simple thing is that the 4.0.0 pom is fully resolved when you have a builder pom I am also not sure if it is enough to deploy build parent poms as is. Your suggested parent must be the same or earlier version of Maven implies new versions of Maven can read older pom formats, which I think will significantly limit our flexibility to evolve pom format. They need to be able
Re: Topics for Maven Development Hangout
wednesday is not ideal for me either: for the first meeting, I did what was necessary to be here, but it would be better for me on another day (time is fine) Regards, Hervé Le jeudi 19 juin 2014 17:08:21 Stephen Connolly a écrit : Can we move it to a day of the week other than Wed? as I'd really like to join On 19 June 2014 16:51, Tamás Cservenák ta...@cservenak.net wrote: I did not make it for the first one, but watched the recording. One topic I'd like to propose is about thing mentioned at very last minutes of the recording: repository tags in POM, smarter protocol between Maven and MRM, etc Should we have some wiki with topic proposals maybe? Thanks, ~t~ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Topics for Maven Development Hangout
22:00-23:00 CEST was fine for me. And Thursday shouldn't be a problem for me. Robert Op Thu, 19 Jun 2014 18:41:18 +0200 schreef Jason van Zyl ja...@takari.io: Sure, how about Thursday? We were also thinking of trying to make it earlier in the day for Europeans. It was a scheduling error on my part making it late at night in Europe. On Jun 19, 2014, at 12:08 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Can we move it to a day of the week other than Wed? as I'd really like to join On 19 June 2014 16:51, Tamás Cservenák ta...@cservenak.net wrote: I did not make it for the first one, but watched the recording. One topic I'd like to propose is about thing mentioned at very last minutes of the recording: repository tags in POM, smarter protocol between Maven and MRM, etc Should we have some wiki with topic proposals maybe? Thanks, ~t~ Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Topics for Maven Development Hangout
Ok, we'll try next week on Thursday at the same time. On Jun 19, 2014, at 1:00 PM, Robert Scholte rfscho...@apache.org wrote: 22:00-23:00 CEST was fine for me. And Thursday shouldn't be a problem for me. Robert Op Thu, 19 Jun 2014 18:41:18 +0200 schreef Jason van Zyl ja...@takari.io: Sure, how about Thursday? We were also thinking of trying to make it earlier in the day for Europeans. It was a scheduling error on my part making it late at night in Europe. On Jun 19, 2014, at 12:08 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Can we move it to a day of the week other than Wed? as I'd really like to join On 19 June 2014 16:51, Tamás Cservenák ta...@cservenak.net wrote: I did not make it for the first one, but watched the recording. One topic I'd like to propose is about thing mentioned at very last minutes of the recording: repository tags in POM, smarter protocol between Maven and MRM, etc Should we have some wiki with topic proposals maybe? Thanks, ~t~ Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson Don Roberts, Patterns for Evolving Frameworks - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
Re: [ANN] Apache Maven EAR Plugin 2.9.1 Released
Hi Hervé, done Regards, Many thanks. Kind regards Karl-Heinz Marbaise Hervé Le jeudi 19 juin 2014 14:32:45 Karl Heinz Marbaise a écrit : Hi, is someone of the maven-pmc members so kind to publish the plugin to the dist area and add it to the board report. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Evolving the POM format
Op Thu, 19 Jun 2014 18:07:33 +0200 schreef Stephen Connolly stephen.alan.conno...@gmail.com: Yeah I thought about that... and I don't like it. First off pom reading is not a pure java world. The ship has sailed. There are people parsing the pom using Ruby, people parsing the pom using other languages that don't even run on the JVM. Thus the only common denominator is to provide an XSLT transformation to map the newer XML format down to the older XML format. Publishing all formats is just ridiculous. My proposal, and I have not seen a better one, is to limit ourselves to at most three poms: 1. The 4.0.0 flattened consumer pom 2. The post 4.0.0 flattened consumer pom 3. The build pom The flatten-maven-plugin is a very nice experiment which taught me that some repository managers require extra information inside the pom.xml beside the consuming parts. So apart from the dependencies it expects developers, scm and a few other elements. We have to be sure that this consumer pom is accepted by all repo managers one way or another. For 2 it is only useful if frameworks like Aether want it and will use it. I think they should be in the lead for the format so it is optimized for them. You might even wonder if it is Maven Core who should create it. I can imagine that either the repo managers extract that information from the artifact and generates the consumer pom OR that the maven-deploy-plugin adds it, so you're not bound to the Maven version to generate such files. Robert So for 1 we know what that will look like. We just change the rules so that it is always flattened, it never has a parent, we strip out some things, we're explicit on dependency exclusions, etc. In other words it makes it as simple as possible for any pom 4.0.0 parser to construct the transitive dependency tree that we believe it should have. All other use is unnecessary. We don't publish a 4.0.0 consumer pom with packagingpom/packaging because * they are unnecessary for other 4.0.0 consumer poms as none of them will reference a parent * it removes the problem of people wanting to use the 4.0.0 consumer poms as a parent, and we are setting the post-modelVersion-4.0.0 rule as your parent must be of a modelVersion = the child's modelVersion For 3, we have no fucking clue what that will look like. I think we need to agree that the first line of it needs some hint as to the model version... but if we stick to the rule that you need a Maven version that is = the model version of the pom you are building to build... well we can always just try all the parsers we have until one of them works... and if it don't work... well we can safely bomb out as you are trying to build with a version of Maven that is too old. Now we have the hard problem, what does 2 look like? Well 2 is produced and consumed by machines only. So I think it will be either json or xml. Both are problematic formats for people to write correctly, but are simple for machines to create and parse. YAML is out in my view as it becomes too tempting for people to try and hand craft... also have you seen the YAML spec? If we go for XML, we need to use namespaces and define up front what to do with unknown namespaces. If we go for JSON, we need to define the extension mechanism and how to handle unknown extensions. Perhaps the simplest thing to do is to have extensions include a flag that says understanding them is mandatory or not. In any case this post 4.0.0 flattened consumer pom only has to worry about expressing dependencies and dependency like constructs (such as platforms/runtimes and provides information). Which poms we deploy depends on the packaging: packaging == pom: deploy build pom only packaging != pom : deploy 4.0.0 consumer pom and post 4.0.0 consumer poms only That is my vision... the bit that I feel worried about is ensuring that we get the post-4.0.0 consumer pom flexible enough that it can handle future stuff that we have not anticipated... as if we get that wrong then 2-3 years down the road we end up with a 4.0.0 consumer pom, a 5.0.0 consumer pom and a post-5.0.0 consumer pom. I would hate to see us deploying 15 different consumer poms just to publish a 1k utility jar On 19 June 2014 16:49, Paul Benedict pbened...@apache.org wrote: I definitely agree that there should be two kinds of POMs: building and consuming. Those are two separate concerns and there's no reason to pollute dependency consumption with build information (or site information!). I am on board with separating the two out. When it comes to evolving the building POM, that's clear cut: upgrade to the Maven X.Y that can read that kind of POM. However, you're still stuck (for a lack of better word) with evolving the POM that everyone consumes, as I said, due to (i) how far back in time you want to support and (ii) publishing all the formats that could exist. Here is my armchair idea to give for
Re: Topics for Maven Development Hangout
Hi, 22:00-23:00 CEST was fine for me. And Thursday shouldn't be a problem for me. vote for that too...here in europe... Kind regards Karl-Heinz Robert Op Thu, 19 Jun 2014 18:41:18 +0200 schreef Jason van Zyl ja...@takari.io: Sure, how about Thursday? We were also thinking of trying to make it earlier in the day for Europeans. It was a scheduling error on my part making it late at night in Europe. On Jun 19, 2014, at 12:08 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Can we move it to a day of the week other than Wed? as I'd really like to join On 19 June 2014 16:51, Tamás Cservenák ta...@cservenak.net wrote: I did not make it for the first one, but watched the recording. One topic I'd like to propose is about thing mentioned at very last minutes of the recording: repository tags in POM, smarter protocol between Maven and MRM, etc Should we have some wiki with topic proposals maybe? Thanks, ~t~ Thanks, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Resolving the dependencies for an Artifact
Hi William, most of the time it's not necessary to find a specific file like this, so I'm wondering what the usecase is. If you're hitting an issue, think of a plugin which might have the same issue and have a look at its code. In this case I'm thinking of the maven-dependency-plugin, especially the code for dependency:tree. Or use the org.apache.maven.project.ProjectBuilder thanks, Robert Op Thu, 19 Jun 2014 00:01:52 +0200 schreef William Ferguson william.fergu...@xandar.com.au: I asked on maven-users but didn't get any viable responses. So I'm hoping someone here can help. -- I have a Mojo that needs to work with Maven 3.0.* and 3.1+ In the Mojo I have an Artifact and I need to resolve it's dependencies. How can/should I do it? If I can resolve the Artifact to a MavenProject then I can use DependencyGraphBuilder (from maven-dependency-tree) to construct a graph of the deps. But I'm struggling to make the Artifact to MavenProject conversion happen. I thought that If I could get a URL to the Artifact's POM file then I could use DefaultMavenRuntime (maven-runtime) to resolve the URL into a MavenProject. But 1. I can't work out how to get a URL to the artifact's POM file (it needs to handle both reactor artifacts and repo artifacts) 2. Even with a URL to the POM file, MavenRuntime#getProject) is returning null. Can someone please point me in the right direction? Am I even on the right path or is there a much more straight forward way of getting the dependencies for the Artifact? -- William - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Resolving the dependencies for an Artifact
For Aries, I ended up doing:
@Component
private org.apache.maven.repository.RepositorySystem repository;
private File resolve(String artifactDescriptor) {
String[] s = artifactDescriptor.split(:);
String type = (s.length = 4 ? s[3] : jar);
Artifact artifact = repository.createArtifact(s[0], s[1], s[2], type);
ArtifactResolutionRequest request = new ArtifactResolutionRequest();
request.setArtifact(artifact);
request.setResolveRoot(true).setResolveTransitively(false);
request.setServers( session.getRequest().getServers() );
request.setMirrors( session.getRequest().getMirrors() );
request.setProxies( session.getRequest().getProxies() );
request.setLocalRepository(session.getLocalRepository());
request.setRemoteRepositories(session.getRequest().getRemoteRepositories());
repository.resolve(request);
return artifact.getFile();
}
If you set “setResolveTransitively(true)” then the ArtifactResolutionResponse
would have all the deps available in it.
That seems to work for both Maven 3.0 and 3.1/3.2.
Dan
Op Thu, 19 Jun 2014 00:01:52 +0200 schreef William Ferguson
william.fergu...@xandar.com.au:
I asked on maven-users but didn't get any viable responses. So I'm hoping
someone here can help.
--
I have a Mojo that needs to work with Maven 3.0.* and 3.1+
In the Mojo I have an Artifact and I need to resolve it's dependencies. How
can/should I do it?
If I can resolve the Artifact to a MavenProject then I can use
DependencyGraphBuilder (from maven-dependency-tree) to construct a graph of
the deps. But I'm struggling to make the Artifact to MavenProject
conversion happen.
I thought that If I could get a URL to the Artifact's POM file then I could
use DefaultMavenRuntime (maven-runtime) to resolve the URL into a
MavenProject. But
1. I can't work out how to get a URL to the artifact's POM file (it
needs to handle both reactor artifacts and repo artifacts)
2. Even with a URL to the POM file, MavenRuntime#getProject) is
returning null.
Can someone please point me in the right direction?
Am I even on the right path or is there a much more straight forward way of
getting the dependencies for the Artifact?
--
William
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Evolving the POM format
On Thursday, 19 June 2014, Robert Scholte rfscho...@apache.org wrote: Op Thu, 19 Jun 2014 18:07:33 +0200 schreef Stephen Connolly stephen.alan.conno...@gmail.com: Yeah I thought about that... and I don't like it. First off pom reading is not a pure java world. The ship has sailed. There are people parsing the pom using Ruby, people parsing the pom using other languages that don't even run on the JVM. Thus the only common denominator is to provide an XSLT transformation to map the newer XML format down to the older XML format. Publishing all formats is just ridiculous. My proposal, and I have not seen a better one, is to limit ourselves to at most three poms: 1. The 4.0.0 flattened consumer pom 2. The post 4.0.0 flattened consumer pom 3. The build pom The flatten-maven-plugin is a very nice experiment which taught me that some repository managers require extra information inside the pom.xml beside the consuming parts. Right now they do because of policy decisions. I think we still have the influence to change such policy if we have a good reason to So apart from the dependencies it expects developers, scm and a few other elements. We have to be sure that this consumer pom is accepted by all repo managers one way or another. For 2 it is only useful if frameworks like Aether want it and will use it. IIUC aether doesn't parse the pom but instead uses an abstraction and is more of a dependency graph solver coupled to a transport and storage layer I think they should be in the lead for the format so it is optimized for them. You might even wonder if it is Maven Core who should create it. I can imagine that either the repo managers extract that information from the artifact and generates the consumer pom OR that the maven-deploy-plugin adds it, so you're not bound to the Maven version to generate such files. Robert So for 1 we know what that will look like. We just change the rules so that it is always flattened, it never has a parent, we strip out some things, we're explicit on dependency exclusions, etc. In other words it makes it as simple as possible for any pom 4.0.0 parser to construct the transitive dependency tree that we believe it should have. All other use is unnecessary. We don't publish a 4.0.0 consumer pom with packagingpom/packaging because * they are unnecessary for other 4.0.0 consumer poms as none of them will reference a parent * it removes the problem of people wanting to use the 4.0.0 consumer poms as a parent, and we are setting the post-modelVersion-4.0.0 rule as your parent must be of a modelVersion = the child's modelVersion For 3, we have no fucking clue what that will look like. I think we need to agree that the first line of it needs some hint as to the model version... but if we stick to the rule that you need a Maven version that is = the model version of the pom you are building to build... well we can always just try all the parsers we have until one of them works... and if it don't work... well we can safely bomb out as you are trying to build with a version of Maven that is too old. Now we have the hard problem, what does 2 look like? Well 2 is produced and consumed by machines only. So I think it will be either json or xml. Both are problematic formats for people to write correctly, but are simple for machines to create and parse. YAML is out in my view as it becomes too tempting for people to try and hand craft... also have you seen the YAML spec? If we go for XML, we need to use namespaces and define up front what to do with unknown namespaces. If we go for JSON, we need to define the extension mechanism and how to handle unknown extensions. Perhaps the simplest thing to do is to have extensions include a flag that says understanding them is mandatory or not. In any case this post 4.0.0 flattened consumer pom only has to worry about expressing dependencies and dependency like constructs (such as platforms/runtimes and provides information). Which poms we deploy depends on the packaging: packaging == pom: deploy build pom only packaging != pom : deploy 4.0.0 consumer pom and post 4.0.0 consumer poms only That is my vision... the bit that I feel worried about is ensuring that we get the post-4.0.0 consumer pom flexible enough that it can handle future stuff that we have not anticipated... as if we get that wrong then 2-3 years down the road we end up with a 4.0.0 consumer pom, a 5.0.0 consumer pom and a post-5.0.0 consumer pom. I would hate to see us deploying 15 different consumer poms just to publish a 1k utility jar On 19 June 2014 16:49, Paul Benedict pbened...@apache.org wrote: I definitely agree that there should be two kinds of POMs: building and consuming. Those are two separate concerns and there's no reason to pollute dependency consumption with build information (or site information!). I am on board with separating the two out. When it comes to
Re: Topics for Maven Development Hangout
Am 06/19/14 17:51, schrieb Tamás Cservenák:
I did not make it for the first one, but watched the recording.
One topic I'd like to propose is about thing mentioned at very last minutes
of the recording: repository tags in POM, smarter protocol between Maven
and MRM, etc
Should we have some wiki with topic proposals maybe?
Here is an idea one may want to consider regarding repository management
and maybe add to that wiki. Here it goes:
dependency
groupIdorg.apache.project.subproject/groupId
/dependency
When Maven resolves that dependency, it could perform a DNS query
against 'subproject.project.apache.org' searching for TXT records
containing repository specifications (the same data as a 'repository'
element in the POM). Not finding TXT records there, continueing up the
hierarchy ('project.apache.org', 'apache.org', 'org'). Finding those TXT
records, Maven could provide those repositories to the resolution
process as the repositories authoritative for artifacts with that group
id. It should not use those repositories to search for anything not
related to that group id, of course. Repository management would become
a matter of nameserver administration. This could help prevent artifact
clashes - that is - same group id, artifact id, version in different
repositories with different content as it would establish authority
management. Maven would resolve artifacts of group id
'org.apache.project.subproject' solely from the repositories setup in
DNS. You get the idea.
Regards,
--
Christian
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
RE: Topics for Maven Development Hangout
I wondered why Hangout was setup for 1400pm Brasil time instead of CEST? I like the idea of flattened poms but I'm hesitant to advocate their usage without knowing the pros/cons for FP. I would also like to see more on full software development lifecycle..Occassionaly i see plugins that dont have positive testcases reason being is that they most probably would'nt work..one that actually stopped my most recent deployment in its tracks.. I would love to see how other languages populate Template Types that guice implements..e.g. populate this using Ruby T ? I think Stephen, Kristian and Benson have a lot of good ideas and i would welcome their participation if they have the time. Thanks, Martin Date: Thu, 19 Jun 2014 20:05:10 +0200 From: khmarba...@gmx.de To: dev@maven.apache.org Subject: Re: Topics for Maven Development Hangout Hi, 22:00-23:00 CEST was fine for me. And Thursday shouldn't be a problem for me. vote for that too...here in europe... Kind regards Karl-Heinz Robert Op Thu, 19 Jun 2014 18:41:18 +0200 schreef Jason van Zyl ja...@takari.io: Sure, how about Thursday? We were also thinking of trying to make it earlier in the day for Europeans. It was a scheduling error on my part making it late at night in Europe. On Jun 19, 2014, at 12:08 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Can we move it to a day of the week other than Wed? as I'd really like to join On 19 June 2014 16:51, Tamás Cservenák ta...@cservenak.net wrote: I did not make it for the first one, but watched the recording. One topic I'd like to propose is about thing mentioned at very last minutes of the recording: repository tags in POM, smarter protocol between Maven and MRM, etc Should we have some wiki with topic proposals maybe? Thanks, ~t~ Thanks, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Resolving the dependencies for an Artifact
Hi Robert, Use case is within the android-maven-plugin we need to generate artefacts for AAR (Android archive) dependencies when building a project. When doing so we need to provide the dependencies of the AAR (not the project) into the generation tool. We can readily retrieve the deps for the AAR by looking through the dependency graph of the project until we find the AAR that then collect deps from there on. This works fine for project (A) that has a dependency on B and C. But if A has dep on B C and B also has a dep on C then it breaks because Maven's dependency resolution (for A, ie the project) will ignore the B-C dep because A-C is more direct. So when we look for the deps of B we never see C. NB maven-dependency-plugin uses maven-dependency-tree for its resolution, which is where I've taken most of my lead so far. It gets down to the context in which the resolution is being done. I need the context to be B instead of A and in order to do that I need to get the MavenProject for B. And this is where I am stuck. William On Fri, Jun 20, 2014 at 4:44 AM, Robert Scholte rfscho...@apache.org wrote: Hi William, most of the time it's not necessary to find a specific file like this, so I'm wondering what the usecase is. If you're hitting an issue, think of a plugin which might have the same issue and have a look at its code. In this case I'm thinking of the maven-dependency-plugin, especially the code for dependency:tree. Or use the org.apache.maven.project.ProjectBuilder thanks, Robert Op Thu, 19 Jun 2014 00:01:52 +0200 schreef William Ferguson william.fergu...@xandar.com.au: I asked on maven-users but didn't get any viable responses. So I'm hoping someone here can help. -- I have a Mojo that needs to work with Maven 3.0.* and 3.1+ In the Mojo I have an Artifact and I need to resolve it's dependencies. How can/should I do it? If I can resolve the Artifact to a MavenProject then I can use DependencyGraphBuilder (from maven-dependency-tree) to construct a graph of the deps. But I'm struggling to make the Artifact to MavenProject conversion happen. I thought that If I could get a URL to the Artifact's POM file then I could use DefaultMavenRuntime (maven-runtime) to resolve the URL into a MavenProject. But 1. I can't work out how to get a URL to the artifact's POM file (it needs to handle both reactor artifacts and repo artifacts) 2. Even with a URL to the POM file, MavenRuntime#getProject) is returning null. Can someone please point me in the right direction? Am I even on the right path or is there a much more straight forward way of getting the dependencies for the Artifact? -- William - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Resolving the dependencies for an Artifact
Hi Dan,
if the ArtifactResolutionResult contains the deps for the Artifact in the
request then that's exactly what I want. However I can't see that it does.
What am I missing?
NB the resolution also needs to be able to resolve Artifacts in the
reactor. I'm pretty certain that
@Component
private org.apache.maven.repository.RepositorySystem repository;
is only going to resolve from the local repo, not the reactor, right?
William
On Fri, Jun 20, 2014 at 4:58 AM, Daniel Kulp dk...@apache.org wrote:
For Aries, I ended up doing:
@Component
private org.apache.maven.repository.RepositorySystem repository;
private File resolve(String artifactDescriptor) {
String[] s = artifactDescriptor.split(:);
String type = (s.length = 4 ? s[3] : jar);
Artifact artifact = repository.createArtifact(s[0], s[1], s[2],
type);
ArtifactResolutionRequest request = new
ArtifactResolutionRequest();
request.setArtifact(artifact);
request.setResolveRoot(true).setResolveTransitively(false);
request.setServers( session.getRequest().getServers() );
request.setMirrors( session.getRequest().getMirrors() );
request.setProxies( session.getRequest().getProxies() );
request.setLocalRepository(session.getLocalRepository());
request.setRemoteRepositories(session.getRequest().getRemoteRepositories());
repository.resolve(request);
return artifact.getFile();
}
If you set “setResolveTransitively(true)” then the
ArtifactResolutionResponse would have all the deps available in it.
That seems to work for both Maven 3.0 and 3.1/3.2.
Dan
Op Thu, 19 Jun 2014 00:01:52 +0200 schreef William Ferguson
william.fergu...@xandar.com.au:
I asked on maven-users but didn't get any viable responses. So I'm hoping
someone here can help.
--
I have a Mojo that needs to work with Maven 3.0.* and 3.1+
In the Mojo I have an Artifact and I need to resolve it's dependencies.
How
can/should I do it?
If I can resolve the Artifact to a MavenProject then I can use
DependencyGraphBuilder (from maven-dependency-tree) to construct a graph
of
the deps. But I'm struggling to make the Artifact to MavenProject
conversion happen.
I thought that If I could get a URL to the Artifact's POM file then I
could
use DefaultMavenRuntime (maven-runtime) to resolve the URL into a
MavenProject. But
1. I can't work out how to get a URL to the artifact's POM file (it
needs to handle both reactor artifacts and repo artifacts)
2. Even with a URL to the POM file, MavenRuntime#getProject) is
returning null.
Can someone please point me in the right direction?
Am I even on the right path or is there a much more straight forward way
of
getting the dependencies for the Artifact?
--
William
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Evolving the POM format
I am not sure I follow.
Do you want to allow multi-module projects where different modules
require different versions of maven?
If required version of maven is the same, why not require the same pom
format version for the entire build too? Are you concerned about changes
to pom.xml files when moving from one format version to the next or
something else?
--
Regards,
Igor
On 2014-06-19, 11:50, Stephen Connolly wrote:
If backwards compatible interoperability is not a requirement then:
If I upgrade one module in my multi-module build to Maven 5.1 then I am
forced right then and there to either:
* upgrade all of them to Maven 5.1; or
* remove the module from my multi-module build
Neither of these are a good user experience in my mind. Maven 5.1 should be
able to build a Maven [2.0,5.1] project without modifying the pom... it can
do that by loading shim layers on demand if necessary, but to my thinking
anything less is going to cause issues for users.
So to my thinking we just accept that Maven needs to evolve such that for
every version X.Y of Maven you know that you can build a Maven project from
the range [2.0,X.Y].
If you have a project that has a parent, then the parent must be in a pom
format that buildable by Maven [2.0,${project.prerequisites.maven}], so a
child pom requiring Maven 5.1 to build can have a parent pom that requires
Maven 5.0 to build but not a parent pom requiring Maven 5.2... there may
even be turtles all the way down to an ancestor pom that requires Maven
[2.0,3.0.3] to build (IIRC after 3.0.3 you get things like wildcards in
excludes due to aether injecting bonus functionality... that should have
been a modelVersion bump in the strictest sense... but well it wasn't)
I also think people overestimate how difficult it is to maintain backwards
compatibility.
I have a Jenkins plugin that was written against Hudson 1.96 and I can take
that .hpi file and drop it into Jenkins 1.568 and it still works
unmodified. Similarly I can upgrade a Jenkins installation jumping quite a
large number of versions without issue.
It is possible to evolve and maintain the ability to read older data... is
it easy? well it's not trivial, but it is a disservice to our users if we
don't try
On 19 June 2014 16:24, Paul Benedict pbened...@apache.org wrote:
I am curious why you interoperability as a requirement? Perhaps questioning
that may seem outrageous, but I see no problem with saying that you need to
upgrade to Maven X.Y to read newer POM formats. If a vendor wants to
backport their project into older POM formats, that should be the vendor's
shoulders and not be a concern of Maven core. If Maven does publish older
formats of POMs, you then have to decide how many older formats do you want
to publish? One day there will be a 4.1 or 5.0, and it's going to
complicate the world if Maven takes on the burden of interoperability.
Cheers,
Paul
On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 19 June 2014 15:48, Igor Fedorenko i...@ifedorenko.com wrote:
On 2014-06-19, 10:30, Stephen Connolly wrote:
- Igor is*mostly* right in that we should not deploy the pom that is
used
to build to the repository...
- Where Igor is wrong is that for packagingpom/packaging we should
actually deploy the build time pom to the repository... probably with
the
classifier `build`... this is safe as `pom` does cannot have a
classifier
in model version 4.0.0.
- You couple that with a simple and obvious restriction... your parent
must
be the same or earlier version of Maven. You cannot have as a parent a
newer version of Maven than the child is built with.
I think there is more to this.
At very least we need to decide what to do with parent in 4.0.0
compatible poms. Maybe we should always deploy effective pom with
build-related elements removed.
Well I think the simple thing is that the 4.0.0 pom is fully resolved
when
you have a builder pom
I am also not sure if it is enough to deploy build parent poms as is.
Your suggested parent must be the same or earlier version of Maven
implies new versions of Maven can read older pom formats, which I think
will significantly limit our flexibility to evolve pom format.
They need to be able to parse it into the model. Perhaps they do the
parsing by downloading a parser. But I think it is reasonable to expect
that we can convert older build pom formats into newer ones and just let
Maven take care of it... if we cannot do that then we are really
creating a
brand new build tool rather than evolving Maven
I wonder
if we can have different solution for force parent poms, like
org.apache:apache, which are used by multiple projects and different
versions of maven and project-specific parent poms, where it is much
easier to require specific version of maven.
Well the simple way is we have deployed the 4.0.0 parent pom as
org.apache:apache:14:pom if you want to upgrade your parent to
Re: Evolving the POM format
Stephen, I'm a little confused by the 3 POMs you have outlined. 1. The 4.0.0 flattened consumer pom 2. The post 4.0.0 flattened consumer pom 3. The build pom Maybe it's just a naming issue, I also see 3 POMs but they are these: A) Consumer POM for non POM projects. Essentially an effective POM sans build section, ie it never has a parent and never has any POM dependencies (mix-ins). B) Consumer POM for POM projects. Same as (A) but it includes the build section. C) Build POM which is where we want to introduce all manner of flexibility. A and B would seem to be easy to provide and create no forward or backward compatibility issues. C is what then is up for discussion. Orthogonal to this is whether there is other meta data that should be published as part of a deployment. But it could be published as a separate artefact to avoid any problem with backward compat. William On Fri, Jun 20, 2014 at 2:07 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Yeah I thought about that... and I don't like it. First off pom reading is not a pure java world. The ship has sailed. There are people parsing the pom using Ruby, people parsing the pom using other languages that don't even run on the JVM. Thus the only common denominator is to provide an XSLT transformation to map the newer XML format down to the older XML format. Publishing all formats is just ridiculous. My proposal, and I have not seen a better one, is to limit ourselves to at most three poms: 1. The 4.0.0 flattened consumer pom 2. The post 4.0.0 flattened consumer pom 3. The build pom So for 1 we know what that will look like. We just change the rules so that it is always flattened, it never has a parent, we strip out some things, we're explicit on dependency exclusions, etc. In other words it makes it as simple as possible for any pom 4.0.0 parser to construct the transitive dependency tree that we believe it should have. All other use is unnecessary. We don't publish a 4.0.0 consumer pom with packagingpom/packaging because * they are unnecessary for other 4.0.0 consumer poms as none of them will reference a parent * it removes the problem of people wanting to use the 4.0.0 consumer poms as a parent, and we are setting the post-modelVersion-4.0.0 rule as your parent must be of a modelVersion = the child's modelVersion For 3, we have no fucking clue what that will look like. I think we need to agree that the first line of it needs some hint as to the model version... but if we stick to the rule that you need a Maven version that is = the model version of the pom you are building to build... well we can always just try all the parsers we have until one of them works... and if it don't work... well we can safely bomb out as you are trying to build with a version of Maven that is too old. Now we have the hard problem, what does 2 look like? Well 2 is produced and consumed by machines only. So I think it will be either json or xml. Both are problematic formats for people to write correctly, but are simple for machines to create and parse. YAML is out in my view as it becomes too tempting for people to try and hand craft... also have you seen the YAML spec? If we go for XML, we need to use namespaces and define up front what to do with unknown namespaces. If we go for JSON, we need to define the extension mechanism and how to handle unknown extensions. Perhaps the simplest thing to do is to have extensions include a flag that says understanding them is mandatory or not. In any case this post 4.0.0 flattened consumer pom only has to worry about expressing dependencies and dependency like constructs (such as platforms/runtimes and provides information). Which poms we deploy depends on the packaging: packaging == pom: deploy build pom only packaging != pom : deploy 4.0.0 consumer pom and post 4.0.0 consumer poms only That is my vision... the bit that I feel worried about is ensuring that we get the post-4.0.0 consumer pom flexible enough that it can handle future stuff that we have not anticipated... as if we get that wrong then 2-3 years down the road we end up with a 4.0.0 consumer pom, a 5.0.0 consumer pom and a post-5.0.0 consumer pom. I would hate to see us deploying 15 different consumer poms just to publish a 1k utility jar On 19 June 2014 16:49, Paul Benedict pbened...@apache.org wrote: I definitely agree that there should be two kinds of POMs: building and consuming. Those are two separate concerns and there's no reason to pollute dependency consumption with build information (or site information!). I am on board with separating the two out. When it comes to evolving the building POM, that's clear cut: upgrade to the Maven X.Y that can read that kind of POM. However, you're still stuck (for a lack of better word) with evolving the POM that everyone consumes, as I said, due to (i) how far back in time you want to support and (ii)
Re: Evolving the POM format
On Friday, 20 June 2014, Igor Fedorenko i...@ifedorenko.com wrote:
I am not sure I follow.
Do you want to allow multi-module projects where different modules
require different versions of maven?
No I want to allow multi-module projects where the maximum modelVersion
defines the minimum required version of maven to build.
If required version of maven is the same, why not require the same pom
format version for the entire build too?
Because I may be working on several things that I am throwing together in
a local aggregator pom... Because I am working on a module that I cannot
change the build process for and another module at the same time that needs
the newer features
Are you concerned about changes
to pom.xml files when moving from one format version to the next or
something else?
I want to be able to migrate modules to newer build poms when they are
ready to do so. That may mean that I have a project with one child that can
be built by Maven 2.0 another that needs maven 3.2.2 and a 3rd that needs
maven 4.1. To build that reactor I need to use maven 4.1 or newer... Or I
can not use a reactor and push things to the local repo and build the first
module with maven 2.0, change my PATH, build the second module with maven
3.2.2, change my PATH again and build the last module with Maven 4.1... All
pushing to the local repo... Hoping that we haven't changed the local repo
format... Hoping that I've remembered to do that all correctly, and all for
the same feature branch... Oh I got distracted and had to switch to a
different branch and back again... Sorry start at the beginning again just
to be sure.
Ok, so we can use something like RVM so that as we cd into each module we
pick up an .mvnenv file that causes our PATH to auto switch... But really?
And for this to work we have two choices... Never evolve the local repo OR
run a local remote repo to act as a maven version neutral exchange... Great
now I've gone from `mvn clean verify` to `cd foo mvn clean deploy
-DaltDeploymentUrl=... cd ../bar mvn clean deploy
-DaltDeploymentUrl=... cd ../manchu ...` that's just great that is!
I argue that unless we keep the contract that newer maven can build all
older maven projects, then there is no point even calling new maven
maven...
Does it have to build them perfectly? Perhaps not, I can live with needing
to tweak things to iron out an inconsistency as long as after the tweak
both new and old build that module the same... So, for example, if the old
pom references ${pom.artifactId} and new maven cannot build that unless you
change it to ${project.artifactId} that is OK in my book as both forms are
legal in old maven so switching to the new one will not break old maven...
(Obviously better if we don't fail in that case... Just trying to give a
concrete example)
The reason is that there is a pressure keeping me from advancing that
module to Maven 4.1. Don't force me to jump through hoops just because some
a-hole is keeping that module shackled to build with Maven 2.0.6 levels of
compatibility... Because if Maven forces me to jump through those hoops...
Congratulations, Maven is now an a-hole too.
--
Regards,
Igor
On 2014-06-19, 11:50, Stephen Connolly wrote:
If backwards compatible interoperability is not a requirement then:
If I upgrade one module in my multi-module build to Maven 5.1 then I am
forced right then and there to either:
* upgrade all of them to Maven 5.1; or
* remove the module from my multi-module build
Neither of these are a good user experience in my mind. Maven 5.1 should
be
able to build a Maven [2.0,5.1] project without modifying the pom... it
can
do that by loading shim layers on demand if necessary, but to my thinking
anything less is going to cause issues for users.
So to my thinking we just accept that Maven needs to evolve such that for
every version X.Y of Maven you know that you can build a Maven project
from
the range [2.0,X.Y].
If you have a project that has a parent, then the parent must be in a pom
format that buildable by Maven [2.0,${project.prerequisites.maven}], so a
child pom requiring Maven 5.1 to build can have a parent pom that requires
Maven 5.0 to build but not a parent pom requiring Maven 5.2... there may
even be turtles all the way down to an ancestor pom that requires Maven
[2.0,3.0.3] to build (IIRC after 3.0.3 you get things like wildcards in
excludes due to aether injecting bonus functionality... that should have
been a modelVersion bump in the strictest sense... but well it wasn't)
I also think people overestimate how difficult it is to maintain backwards
compatibility.
I have a Jenkins plugin that was written against Hudson 1.96 and I can
take
that .hpi file and drop it into Jenkins 1.568 and it still works
unmodified. Similarly I can upgrade a Jenkins installation jumping quite a
large number of versions without issue.
It is possible to evolve and maintain the ability to read older data...
Re: Evolving the POM format
On Friday, 20 June 2014, William Ferguson william.fergu...@xandar.com.au wrote: Stephen, I'm a little confused by the 3 POMs you have outlined. 1. The 4.0.0 flattened consumer pom This is the pom for any consumers who only understand modelVersion 4.0.0 ie Maven [2.0,4.0) and Gradle and Ivy and Buildr and ... 2. The post 4.0.0 flattened consumer pom This is the pom for any consumers that understand modelVersion 4.0.0 3. The build pom This is the pom for building The trick here is in realising that different artifact types need different use cases. Q: When do you need to pull the build pom from the repository? A: When it is the parent of the project you are building. Q: When do you need a consumer pom? A: When you are consuming an artifact. So the only time we need consumer poms is when packaging != pom The only time we need build poms is when packaging == pom (we may need to introduce a new packaging type for those fake pom packaging projects where we produce assemblies, xsd schemas, etc) The consumer poms are all about expressing the dependency tree (they may include limited metadata, such as SCM URL, etc) but ultimately they are about describing how to use the artifact as a dependency... What it brings with it and what it needs brought for it to work. The build pom is all about inheritance (perhaps also Mixins) Maybe it's just a naming issue, I also see 3 POMs but they are these: A) Consumer POM for non POM projects. Essentially an effective POM sans build section, ie it never has a parent and never has any POM dependencies (mix-ins). B) Consumer POM for POM projects. Same as (A) but it includes the build section. Why do you think this needs a build section? C) Build POM which is where we want to introduce all manner of flexibility. A and B would seem to be easy to provide and create no forward or backward compatibility issues. Well B is where we want to add new dependency tree features... This is a smaller set of changes than would affect build an reporting sections, but let us not be so arrogant as to assume we know everything that should go in here... Hence this is the format we need great care with. C is what then is up for discussion. But C doesn't need to be backwards compatible... maven needs to be able to read older formats of C In short, format A is fixed... So we don't have to worry about backwards compat with format A as it is fixed. Format C is build time only, we can legitimately say you need to use a certain minimum version of maven to build a specific builder model version. Format B is the one that risks fragmentation if we get it wrong. Deploying A B is bad enough but acceptable... Deploying A, B, B', B'', B''', ... Well that is inexcusable Orthogonal to this is whether there is other meta data that should be published as part of a deployment. But it could be published as a separate artefact to avoid any problem with backward compat. William On Fri, Jun 20, 2014 at 2:07 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: Yeah I thought about that... and I don't like it. First off pom reading is not a pure java world. The ship has sailed. There are people parsing the pom using Ruby, people parsing the pom using other languages that don't even run on the JVM. Thus the only common denominator is to provide an XSLT transformation to map the newer XML format down to the older XML format. Publishing all formats is just ridiculous. My proposal, and I have not seen a better one, is to limit ourselves to at most three poms: 1. The 4.0.0 flattened consumer pom 2. The post 4.0.0 flattened consumer pom 3. The build pom So for 1 we know what that will look like. We just change the rules so that it is always flattened, it never has a parent, we strip out some things, we're explicit on dependency exclusions, etc. In other words it makes it as simple as possible for any pom 4.0.0 parser to construct the transitive dependency tree that we believe it should have. All other use is unnecessary. We don't publish a 4.0.0 consumer pom with packagingpom/packaging because * they are unnecessary for other 4.0.0 consumer poms as none of them will reference a parent * it removes the problem of people wanting to use the 4.0.0 consumer poms as a parent, and we are setting the post-modelVersion-4.0.0 rule as your parent must be of a modelVersion = the child's modelVersion For 3, we have no fucking clue what that will look like. I think we need to agree that the first line of it needs some hint as to the model version... but if we stick to the rule that you need a Maven version that is = the model version of the pom you are building to build... well we can always just try all the parsers we have until one of them works... and if it don't work... well we can safely bomb out as you are trying to build with a version of Maven that is too old.
RE: Resolving the dependencies for an Artifact
Date: Fri, 20 Jun 2014 08:29:10 +1000 Subject: Re: Resolving the dependencies for an Artifact From: william.fergu...@xandar.com.au To: dev@maven.apache.org Hi Robert, Use case is within the android-maven-plugin we need to generate artefacts for AAR (Android archive) dependencies when building a project. When doing so we need to provide the dependencies of the AAR (not the project) into the generation tool. We can readily retrieve the deps for the AAR by looking through the dependency graph of the project until we find the AAR that then collect deps from there on. This works fine for project (A) that has a dependency on B and C. But if A has dep on B C and B also has a dep on C then it breaks because Maven's dependency resolution (for A, ie the project) will ignore the B-C dep because A-C is more direct. So when we look for the deps of B we never see C. NB maven-dependency-plugin uses maven-dependency-tree for its resolution, which is where I've taken most of my lead so far. It gets down to the context in which the resolution is being done. I need the context to be B instead of A and in order to do that I need to get the MavenProject for B. And this is where I am stuck. MGIf I understand a prioritised dependency shortcut of A-B then B-C (instead of A-C)? MGput this on the Jason's wishlist for Maven 4.x! MGdoes anyone know if Maven has ability to reorder the dependency graph? William On Fri, Jun 20, 2014 at 4:44 AM, Robert Scholte rfscho...@apache.org wrote: Hi William, most of the time it's not necessary to find a specific file like this, so I'm wondering what the usecase is. If you're hitting an issue, think of a plugin which might have the same issue and have a look at its code. In this case I'm thinking of the maven-dependency-plugin, especially the code for dependency:tree. Or use the org.apache.maven.project.ProjectBuilder thanks, Robert Op Thu, 19 Jun 2014 00:01:52 +0200 schreef William Ferguson william.fergu...@xandar.com.au: I asked on maven-users but didn't get any viable responses. So I'm hoping someone here can help. -- I have a Mojo that needs to work with Maven 3.0.* and 3.1+ In the Mojo I have an Artifact and I need to resolve it's dependencies. How can/should I do it? If I can resolve the Artifact to a MavenProject then I can use DependencyGraphBuilder (from maven-dependency-tree) to construct a graph of the deps. But I'm struggling to make the Artifact to MavenProject conversion happen. I thought that If I could get a URL to the Artifact's POM file then I could use DefaultMavenRuntime (maven-runtime) to resolve the URL into a MavenProject. But 1. I can't work out how to get a URL to the artifact's POM file (it needs to handle both reactor artifacts and repo artifacts) 2. Even with a URL to the POM file, MavenRuntime#getProject) is returning null. Can someone please point me in the right direction? Am I even on the right path or is there a much more straight forward way of getting the dependencies for the Artifact? -- William - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Evolving the POM format
OK, when you have been referring to the build pom I thought you just meant the pom in the project source. You actually mean that source pom (perhaps flattened) deployed to the repository. I don't see any need for the build pom to be deployed except where the project has type=pom. Ie we intend for the pom itself to be consumed by another pom. This is what I was referring to as the (B) option. And why I believe it needs the build section. When/why would you want the build pom to be deployed for another type of artifact? William On Fri, Jun 20, 2014 at 10:39 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Friday, 20 June 2014, William Ferguson william.fergu...@xandar.com.au wrote: Stephen, I'm a little confused by the 3 POMs you have outlined. 1. The 4.0.0 flattened consumer pom This is the pom for any consumers who only understand modelVersion 4.0.0 ie Maven [2.0,4.0) and Gradle and Ivy and Buildr and ... 2. The post 4.0.0 flattened consumer pom This is the pom for any consumers that understand modelVersion 4.0.0 3. The build pom This is the pom for building The trick here is in realising that different artifact types need different use cases. Q: When do you need to pull the build pom from the repository? A: When it is the parent of the project you are building. Q: When do you need a consumer pom? A: When you are consuming an artifact. So the only time we need consumer poms is when packaging != pom The only time we need build poms is when packaging == pom (we may need to introduce a new packaging type for those fake pom packaging projects where we produce assemblies, xsd schemas, etc) The consumer poms are all about expressing the dependency tree (they may include limited metadata, such as SCM URL, etc) but ultimately they are about describing how to use the artifact as a dependency... What it brings with it and what it needs brought for it to work. The build pom is all about inheritance (perhaps also Mixins) Maybe it's just a naming issue, I also see 3 POMs but they are these: A) Consumer POM for non POM projects. Essentially an effective POM sans build section, ie it never has a parent and never has any POM dependencies (mix-ins). B) Consumer POM for POM projects. Same as (A) but it includes the build section. Why do you think this needs a build section? C) Build POM which is where we want to introduce all manner of flexibility. A and B would seem to be easy to provide and create no forward or backward compatibility issues. Well B is where we want to add new dependency tree features... This is a smaller set of changes than would affect build an reporting sections, but let us not be so arrogant as to assume we know everything that should go in here... Hence this is the format we need great care with. C is what then is up for discussion. But C doesn't need to be backwards compatible... maven needs to be able to read older formats of C In short, format A is fixed... So we don't have to worry about backwards compat with format A as it is fixed. Format C is build time only, we can legitimately say you need to use a certain minimum version of maven to build a specific builder model version. Format B is the one that risks fragmentation if we get it wrong. Deploying A B is bad enough but acceptable... Deploying A, B, B', B'', B''', ... Well that is inexcusable Orthogonal to this is whether there is other meta data that should be published as part of a deployment. But it could be published as a separate artefact to avoid any problem with backward compat. William On Fri, Jun 20, 2014 at 2:07 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: Yeah I thought about that... and I don't like it. First off pom reading is not a pure java world. The ship has sailed. There are people parsing the pom using Ruby, people parsing the pom using other languages that don't even run on the JVM. Thus the only common denominator is to provide an XSLT transformation to map the newer XML format down to the older XML format. Publishing all formats is just ridiculous. My proposal, and I have not seen a better one, is to limit ourselves to at most three poms: 1. The 4.0.0 flattened consumer pom 2. The post 4.0.0 flattened consumer pom 3. The build pom So for 1 we know what that will look like. We just change the rules so that it is always flattened, it never has a parent, we strip out some things, we're explicit on dependency exclusions, etc. In other words it makes it as simple as possible for any pom 4.0.0 parser to construct the transitive dependency tree that we believe it should have. All other use is unnecessary. We don't publish a 4.0.0 consumer pom with packagingpom/packaging because * they are unnecessary for other 4.0.0 consumer poms as none of them will
Re: Resolving the dependencies for an Artifact
On Jun 19, 2014, at 6:36 PM, William Ferguson william.fergu...@xandar.com.au
wrote:
Hi Dan,
if the ArtifactResolutionResult contains the deps for the Artifact in the
request then that's exactly what I want. However I can't see that it does.
What am I missing?
ArtifactResolutionResult.getArtifacts() is a list of all the artifacts that it
resolved.
NB the resolution also needs to be able to resolve Artifacts in the
reactor. I'm pretty certain that
@Component
private org.apache.maven.repository.RepositorySystem repository;
is only going to resolve from the local repo, not the reactor, right?
This I don’t know. I haven’t tried to have it resolve anything in the reactor.
Dan
William
On Fri, Jun 20, 2014 at 4:58 AM, Daniel Kulp dk...@apache.org wrote:
For Aries, I ended up doing:
@Component
private org.apache.maven.repository.RepositorySystem repository;
private File resolve(String artifactDescriptor) {
String[] s = artifactDescriptor.split(:);
String type = (s.length = 4 ? s[3] : jar);
Artifact artifact = repository.createArtifact(s[0], s[1], s[2],
type);
ArtifactResolutionRequest request = new
ArtifactResolutionRequest();
request.setArtifact(artifact);
request.setResolveRoot(true).setResolveTransitively(false);
request.setServers( session.getRequest().getServers() );
request.setMirrors( session.getRequest().getMirrors() );
request.setProxies( session.getRequest().getProxies() );
request.setLocalRepository(session.getLocalRepository());
request.setRemoteRepositories(session.getRequest().getRemoteRepositories());
repository.resolve(request);
return artifact.getFile();
}
If you set “setResolveTransitively(true)” then the
ArtifactResolutionResponse would have all the deps available in it.
That seems to work for both Maven 3.0 and 3.1/3.2.
Dan
Op Thu, 19 Jun 2014 00:01:52 +0200 schreef William Ferguson
william.fergu...@xandar.com.au:
I asked on maven-users but didn't get any viable responses. So I'm hoping
someone here can help.
--
I have a Mojo that needs to work with Maven 3.0.* and 3.1+
In the Mojo I have an Artifact and I need to resolve it's dependencies.
How
can/should I do it?
If I can resolve the Artifact to a MavenProject then I can use
DependencyGraphBuilder (from maven-dependency-tree) to construct a graph
of
the deps. But I'm struggling to make the Artifact to MavenProject
conversion happen.
I thought that If I could get a URL to the Artifact's POM file then I
could
use DefaultMavenRuntime (maven-runtime) to resolve the URL into a
MavenProject. But
1. I can't work out how to get a URL to the artifact's POM file (it
needs to handle both reactor artifacts and repo artifacts)
2. Even with a URL to the POM file, MavenRuntime#getProject) is
returning null.
Can someone please point me in the right direction?
Am I even on the right path or is there a much more straight forward way
of
getting the dependencies for the Artifact?
--
William
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Resolving the dependencies for an Artifact
ArtifactResolutionResult.getArtifacts() is a list of all the artifacts
that it resolved.
Yes, but aren't those the artifacts that matched the
ArtifactResolutionRequest?
They're not the dependencies of the target of an ArtifactResolutionRequest.
William
NB the resolution also needs to be able to resolve Artifacts in the
reactor. I'm pretty certain that
@Component
private org.apache.maven.repository.RepositorySystem repository;
is only going to resolve from the local repo, not the reactor, right?
This I don’t know. I haven’t tried to have it resolve anything in the
reactor.
Dan
William
On Fri, Jun 20, 2014 at 4:58 AM, Daniel Kulp dk...@apache.org wrote:
For Aries, I ended up doing:
@Component
private org.apache.maven.repository.RepositorySystem repository;
private File resolve(String artifactDescriptor) {
String[] s = artifactDescriptor.split(:);
String type = (s.length = 4 ? s[3] : jar);
Artifact artifact = repository.createArtifact(s[0], s[1], s[2],
type);
ArtifactResolutionRequest request = new
ArtifactResolutionRequest();
request.setArtifact(artifact);
request.setResolveRoot(true).setResolveTransitively(false);
request.setServers( session.getRequest().getServers() );
request.setMirrors( session.getRequest().getMirrors() );
request.setProxies( session.getRequest().getProxies() );
request.setLocalRepository(session.getLocalRepository());
request.setRemoteRepositories(session.getRequest().getRemoteRepositories());
repository.resolve(request);
return artifact.getFile();
}
If you set “setResolveTransitively(true)” then the
ArtifactResolutionResponse would have all the deps available in it.
That seems to work for both Maven 3.0 and 3.1/3.2.
Dan
Op Thu, 19 Jun 2014 00:01:52 +0200 schreef William Ferguson
william.fergu...@xandar.com.au:
I asked on maven-users but didn't get any viable responses. So I'm
hoping
someone here can help.
--
I have a Mojo that needs to work with Maven 3.0.* and 3.1+
In the Mojo I have an Artifact and I need to resolve it's dependencies.
How
can/should I do it?
If I can resolve the Artifact to a MavenProject then I can use
DependencyGraphBuilder (from maven-dependency-tree) to construct a
graph
of
the deps. But I'm struggling to make the Artifact to MavenProject
conversion happen.
I thought that If I could get a URL to the Artifact's POM file then I
could
use DefaultMavenRuntime (maven-runtime) to resolve the URL into a
MavenProject. But
1. I can't work out how to get a URL to the artifact's POM file (it
needs to handle both reactor artifacts and repo artifacts)
2. Even with a URL to the POM file, MavenRuntime#getProject) is
returning null.
Can someone please point me in the right direction?
Am I even on the right path or is there a much more straight forward
way
of
getting the dependencies for the Artifact?
--
William
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Resolving the dependencies for an Artifact
MGIf I understand a prioritised dependency shortcut of A-B then B-C (instead of A-C)? MGput this on the Jason's wishlist for Maven 4.x! MGdoes anyone know if Maven has ability to reorder the dependency graph? I hadn't thought about that. I could look into maven-dep-tree and see if I can determine what is doing the optimisation (ie removing B-C) and provide another method that allows the optimisation to be switched off. But it's adding another method to the mdt DependencyResolver interface - I've already added one in the last month :-). It's likely to be the only consumer of the new method. And it feels a little clunky as I am still resolving deps for A and then walking the graph until I find B to get B's deps. I would much rather just resolve deps for Artifact B. But to do that I need to be able to convert Artifact B into MavenProject B. Surely there has to be a way of doing that. Someone? William William On Fri, Jun 20, 2014 at 4:44 AM, Robert Scholte rfscho...@apache.org wrote: Hi William, most of the time it's not necessary to find a specific file like this, so I'm wondering what the usecase is. If you're hitting an issue, think of a plugin which might have the same issue and have a look at its code. In this case I'm thinking of the maven-dependency-plugin, especially the code for dependency:tree. Or use the org.apache.maven.project.ProjectBuilder thanks, Robert Op Thu, 19 Jun 2014 00:01:52 +0200 schreef William Ferguson william.fergu...@xandar.com.au: I asked on maven-users but didn't get any viable responses. So I'm hoping someone here can help. -- I have a Mojo that needs to work with Maven 3.0.* and 3.1+ In the Mojo I have an Artifact and I need to resolve it's dependencies. How can/should I do it? If I can resolve the Artifact to a MavenProject then I can use DependencyGraphBuilder (from maven-dependency-tree) to construct a graph of the deps. But I'm struggling to make the Artifact to MavenProject conversion happen. I thought that If I could get a URL to the Artifact's POM file then I could use DefaultMavenRuntime (maven-runtime) to resolve the URL into a MavenProject. But 1. I can't work out how to get a URL to the artifact's POM file (it needs to handle both reactor artifacts and repo artifacts) 2. Even with a URL to the POM file, MavenRuntime#getProject) is returning null. Can someone please point me in the right direction? Am I even on the right path or is there a much more straight forward way of getting the dependencies for the Artifact? -- William - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
