Re: [DISCUSS] SCM child-project URL composition
Le vendredi 29 juillet 2011, Mark Struberg a écrit : Is it as simple as that for all SCMs? Yes it is. Remember the old days: this is only a fix for a 'fix'. Originally the SCM URLs haven't been changed for child modules. This 'feature' only got introduce later to make life easier for SVN and CVS users (the vast majority of projects back then). What we now do is to disable this 'feature' (which now got a known and expected default behaviour) in some certain cases. Not more not less. a property? like we did for project.build.encoding? this would be project.scm.autoModule? I honestly fear of doing some magic with the SCM Urls because those are NOT native urls but get interpreted by the SCM providers. Thus the 'url adaptors' would need to 100% match the specific scm providers. So you either ship it in the same build or you are soon doomed I fear. But as you need to ship that classes as part of a maven release, there is just no upgrade scenario and you would need to support sins for a long time... if this gets into maven-scm, this needs to be a dedicated module, cross-scms, and independendant from wagon-provider-api And the upgrade scenario exists: you can override a library shipped with Maven The 2nd nice benefit: I'm currently digging into the attribute stuff in Modello. If this works out, we can use this approach for other long awaited features (like the mixins) in a pom-4.0.0 compatible way! if you didn't see, there is a strictXmlAttribute configuration added in Modello 1.2 [1] to deal with attributes checks or not I don't know how the maven.mdo has been configured in every Maven release. Regards, Hervé [1] http://modello.codehaus.org/modello.html#class_default LieGrue, strub --- On Fri, 7/29/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 12:47 AM On Jul 28, 2011, at 8:31 PM, Mark Struberg wrote: Of course, not having to touch the POMs is a good thing. But I don't get the 'historic behaviour' part. Even if you would have components in the scm-providers (which all need to be changed), this solution would not work with older maven version because they will simply not get injected somewhere. Dealing with what people use today versus native expressions in the future. The components are simple, they could be external and use in Maven 2.x and 3.x. Plus, you would need to split that code from the scm-providers, as explained before. But maintaining them separately, I wonder how this should scale. It must be part of maven-core, because it must clearly be available _before_ dependencies and even extensions are available. We're going to end up with a few lines of code for each SCM. For the short term I doubt this is going to be a problem because there are probably less than 10 to deal with and changes could be made quickly and then they are unlikely to change. It's not a lot of code to deal with, it can be in Maven as it is more for POM construction than anything to do with any particular SCM. So basically it comes down to 1.) having a list of SCMs which must not get the module-name appended. It imo doesn't make much difference if you do this via a regexp or via a Java class. I think the regexp in toolchains.mdo even would have the benefit that a user would be able to overwrite/extend the default config if he needs to. Is it as simple as that for all SCMs? 2.) marking the url tag somehow. Either inside the URL string with a prefix like 'absolute:' or via an xml attribute. The explicit marking of URLs allows this solution to get applied for site stuff too. The regexp/Java stuff would not work for the site URL problematic, because there is no information about the intention of the user in the pom atm. It would be useful to see the forms SCM URL construction for: CVS SVN Git Hg Perforce Clearcase And anything else that people might want. I think if it's going to be something that must work for all cases, and cases we cannot foresee then a simple implementation in a component where the default implementation is component that uses regexes that's fine, but if we're thinking of making this pluggable then I think allowing someone to plug in whatever logic they want would be useful. LieGrue, strub --- On Fri, 7/29/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 12:08 AM I would also propose C) A small bit of Java code in the form of a component for each SCM type and inject those into the inheritance
Re: Apache Maven distribution with fixes
+1 Regards, Hervé Le jeudi 28 juillet 2011, Brett Porter a écrit : On 28/07/2011, at 10:32 PM, Jason van Zyl wrote: On Jul 28, 2011, at 8:25 AM, Mark Struberg wrote: mom jason. Before we ship 3.0.4 I'd like to fix the SCM URL postfix problem which exists in lots of DSCMs. Will do this in the next week. You probably have 6-7 weeks before an official 3.0.4 release would be made so you have plenty of time. If you are going to wait for Aether and Sisu to be provisioned at Eclipse then the total time for both of those to pass into that state is about 7 weeks. The build I proposed could not be an official release until such a time because there are fixes which rely on Sisu and Aether which are important for users. Would you consider dual licensing them again so we can just keep moving forward as we had been? It makes no changes to your plans and reduces the amount of uncertainty everyone has. It's changed license 3 times in the last year, one more won't hurt. There'd be no hold up if the current release had kept the license that it had when it was incorporated a year ago, and the 3.0.4 release process could start straight away. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - 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: [VOTE] Release Maven Release plugin version 2.2.1
+1 -Lukas On 07/28/2011 04:56 PM, Stephen Connolly wrote: Hi, This is a patch release to fix a particularly nasty regression: http://jira.codehaus.org/browse/MRELEASE-697 We solved 3 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11144styleName=Htmlversion=17502 Staging repo: https://repository.apache.org/content/repositories/maven-009/ Source distribution: https://repository.apache.org/content/repositories/maven-009/org/apache/maven/release/maven-release/2.2.1/maven-release-2.2.1-source-release.zip SCM tag: http://svn.apache.org/repos/asf/maven/release/tags/maven-release-2.2.1 Staging site: http://maven.apache.org/plugins/maven-release-plugin-2.2.1/ http://maven.apache.org/maven-release/staging/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Guide to previewing site content ahead of the sync: http://www.apache.org/dev/project-site.html (and search on the page for HTTP proxy) Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, -Stephen - 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: Upgrading maven-checkstyle-plugin checkstyle version support
You could just try with checkstyle 5.3. there is the ability to override the dependencies of a plugin project build plugins plugin artifactIdmaven-checkstyle-plugin/artifactId dependencies ... insert the newer version of checkstyle (not the plugin) here /dependencies /plugin /plugins /build /project If the only change is a version bumb, then you can achieve that by overriding with a bumped version in your pom... No new release needed unless the newer version has changed its API -Stephen On 28 July 2011 15:57, Chris Whelan chrismichaelwhe...@gmail.com wrote: Hi all, I'm looking to use the maven-checkstyle-plugin with checkstyle 5.3, but it only supports 5.0 as of the 2.6 release of the plugin. Looking at trunk it seems to already have been upgraded to 5.3 but there haven't been commits for a couple of months. I'm using a few rules which are not available on 5.0 so can't currently make use of this plug-in. I have a few queries: 1. What are the plans for releasing v2.7 of the plugin? Is there any more work outstanding for checkstyle 5.3/5.4 support? I'd be happy to help with any remaining tasks to get this pushed out the door as it would be a useful upgrade for me. 2. I've done a quick diff of the 1.6 tag against trunk and looking at the changes, the only change related to the checkstyle 5.3 upgrade seems to be bumping the version number of the dependency in the plugin's pom file. Is this all that's needed to make the new plugins from checkstyle 5.3 executable via the plugin? 3. Given that new checkstyle releases pop up every now and again and are likely to include new plug-ins but not necessarily break the API used by maven-checkstyle-plugin, is there another mechanism that could be used to make the upgrade easier? I'm thinking something like a plugin configuration setting checkstyle.version which could be used to specify the checkstyle dependency used by the plug-in. That way it would be possible to use the plugin with future minor releases of checkstyle without having to do a new release of the plug-in itself? I might be oversimplifying things, I'm not sure if additional configuration or glue code is needed to make the new checkstyle rules available through the plug-in when upgrading to 5.3 and beyond. Obviously this would break if checkstyle changed their API but the benefits could well be worth it and the value could easily be defaulted. I'd be happy to work on this and submit a patch if someone can give me an initial pointer to let me know if they think it would be possible. Cheers, Chris - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Hi Hervé! Txs for the input! this would be project.scm.autoModule? dont think that properties would work in this case. They are also only fully evaluated after the model is already built, isn't? Thats a tad to late I fear. But I'm happy to be proven wrong if you find time to test the behaviour. And the upgrade scenario exists: you can override a library shipped with Maven Hmm not really. Because older projects rely on older SCM providers which they define in their pom. Another project might use the latest and greatest new SCM provider. Thus this new 'scm-url-mangler' must be compatible to years of maven-scm history, without even knowing which version will be taken. Not even at runtime, because it will get used at a point in time where the maven-scm version is not yet determined. LieGrue, strub --- On Fri, 7/29/11, Hervé BOUTEMY herve.bout...@free.fr wrote: From: Hervé BOUTEMY herve.bout...@free.fr Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 6:31 AM Le vendredi 29 juillet 2011, Mark Struberg a écrit : Is it as simple as that for all SCMs? Yes it is. Remember the old days: this is only a fix for a 'fix'. Originally the SCM URLs haven't been changed for child modules. This 'feature' only got introduce later to make life easier for SVN and CVS users (the vast majority of projects back then). What we now do is to disable this 'feature' (which now got a known and expected default behaviour) in some certain cases. Not more not less. a property? like we did for project.build.encoding? this would be project.scm.autoModule? I honestly fear of doing some magic with the SCM Urls because those are NOT native urls but get interpreted by the SCM providers. Thus the 'url adaptors' would need to 100% match the specific scm providers. So you either ship it in the same build or you are soon doomed I fear. But as you need to ship that classes as part of a maven release, there is just no upgrade scenario and you would need to support sins for a long time... if this gets into maven-scm, this needs to be a dedicated module, cross-scms, and independendant from wagon-provider-api And the upgrade scenario exists: you can override a library shipped with Maven The 2nd nice benefit: I'm currently digging into the attribute stuff in Modello. If this works out, we can use this approach for other long awaited features (like the mixins) in a pom-4.0.0 compatible way! if you didn't see, there is a strictXmlAttribute configuration added in Modello 1.2 [1] to deal with attributes checks or not I don't know how the maven.mdo has been configured in every Maven release. Regards, Hervé [1] http://modello.codehaus.org/modello.html#class_default LieGrue, strub --- On Fri, 7/29/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 12:47 AM On Jul 28, 2011, at 8:31 PM, Mark Struberg wrote: Of course, not having to touch the POMs is a good thing. But I don't get the 'historic behaviour' part. Even if you would have components in the scm-providers (which all need to be changed), this solution would not work with older maven version because they will simply not get injected somewhere. Dealing with what people use today versus native expressions in the future. The components are simple, they could be external and use in Maven 2.x and 3.x. Plus, you would need to split that code from the scm-providers, as explained before. But maintaining them separately, I wonder how this should scale. It must be part of maven-core, because it must clearly be available _before_ dependencies and even extensions are available. We're going to end up with a few lines of code for each SCM. For the short term I doubt this is going to be a problem because there are probably less than 10 to deal with and changes could be made quickly and then they are unlikely to change. It's not a lot of code to deal with, it can be in Maven as it is more for POM construction than anything to do with any particular SCM. So basically it comes down to 1.) having a list of SCMs which must not get the module-name appended. It imo doesn't make much difference if you do this via a regexp or via a Java class. I think the regexp in toolchains.mdo even would have the benefit that a user would be able to overwrite/extend the default config if he needs to. Is it as simple as that for all SCMs? 2.) marking the url tag somehow. Either inside the URL string with a prefix like 'absolute:' or via an xml attribute. The explicit
Re: [DISCUSS] SCM child-project URL composition
Hi,
here's a use case/convention which neither the current append child's
artifactId strategy nor the static: prefix can handle.
The parent project uses something like
/scm-root/
and the modules/children use
/scm-root/modules/${project.artifactId}
IMHO, the only fully flexible solution is to have an *absolute* URI
which is used for the current project and an extra attribute which
specifies the *relative* URI to be appended by child projects.
This extra attribute would simply default to ./${project.artifactId},
thereby making the append child's artifactId strategy explicit. The
static use case could then be handled by a value of
../${project.artifactId}.
Of course, this relies on SCM providers properly handling path
components like . and ... Also, when property expansion happens
needs to be hashed out. (I think, the parent's relative path attribute
should be expanded in the child's context.)
But while the above convention is maybe not a common case in SCM URIs,
the relations between parent and child *site* URIs (which currently
also use the append child's artifactId strategy) are more diverse,
which I think warrants thinking about a flexible solution.
Just my $0.02.
Andreas
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
gnah sorry :( I explicitly tested the schema validation, but obviously using a new tool (I'm new to macs...) at 3 o clock in the morning isn't producing reliable results :/ But your idea with the XSD-4.0.1 sound really great. Almost too good to believe! That would probably allow us to implement most of the new features like mixins and stuff _without_ getting incompatible. Maybe we could not implement all the new stuff, but it's worth thinking about it. Otoh I'm not sure if such a change should be done in a bugfix release. Or better said: I'm pretty sure that we should _not_ do such a change in a bugfix release ;) LieGrue, strub --- On Fri, 7/29/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 2:01 AM I have some perhaps minor bad news about attributes. Attributes on the url/ element won't validate against the current schema. I had hoped to discover otherwise, but no such luck. The combine.children trick passes because it is inside of the 'any' inside the plugin configuration. I claim that the following is tolerable from a compatibility standpoint: 1) create a 4.0.1 XSD file that adds the necessary xs:anyAttribute (or specific attributes, if you prefer) to the url/ element. 2) Change default archetypes and the release plugin and friends to add this schema instead of the 4.0.0 schema. In other words, Mark's experiments show that, in *practical* terms, adding the attributes works. That leave the question of programs that actually pay attention to the schema itself. The only bad case would be some program out there which for some reason always validates against the 4.0.0 schema even if the schema declared at the top is 4.0.1. I don't believe in this. - 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: [DISCUSS] SCM child-project URL composition
How about coming at this from a different track... scmscm:parent:/path/in/parent/scm that is an SCM that is the same as parent with a path in the parent. the parent scm provider would look up the parent's scm and could use some rules to derive the effective path, acting like a delegate and giving us the correct path. It does mean that unless prerequmaven3.1/maven/prerequ users would have to specify the scm in all initial child modules. On 29 July 2011 08:39, Mark Struberg strub...@yahoo.de wrote: gnah sorry :( I explicitly tested the schema validation, but obviously using a new tool (I'm new to macs...) at 3 o clock in the morning isn't producing reliable results :/ But your idea with the XSD-4.0.1 sound really great. Almost too good to believe! That would probably allow us to implement most of the new features like mixins and stuff _without_ getting incompatible. Maybe we could not implement all the new stuff, but it's worth thinking about it. Otoh I'm not sure if such a change should be done in a bugfix release. Or better said: I'm pretty sure that we should _not_ do such a change in a bugfix release ;) LieGrue, strub --- On Fri, 7/29/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 2:01 AM I have some perhaps minor bad news about attributes. Attributes on the url/ element won't validate against the current schema. I had hoped to discover otherwise, but no such luck. The combine.children trick passes because it is inside of the 'any' inside the plugin configuration. I claim that the following is tolerable from a compatibility standpoint: 1) create a 4.0.1 XSD file that adds the necessary xs:anyAttribute (or specific attributes, if you prefer) to the url/ element. 2) Change default archetypes and the release plugin and friends to add this schema instead of the 4.0.0 schema. In other words, Mark's experiments show that, in *practical* terms, adding the attributes works. That leave the question of programs that actually pay attention to the schema itself. The only bad case would be some program out there which for some reason always validates against the 4.0.0 schema even if the schema declared at the top is 4.0.1. I don't believe in this. - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
I'm in favor of the policy (since I suggested it), that maven 3.0.X can deliver pom XSD 4.0.Y, where the changes the the XSD are proven to be harmless to popular old versions and common sense characterizes them as unlikely to blow anything up. I submit that adding some inheritance control attributes would come under that rubric. Do we need to vote this, or otherwise clarify consensus or the lack thereof? Does anyone hate it? On Fri, Jul 29, 2011 at 4:26 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: How about coming at this from a different track... scmscm:parent:/path/in/parent/scm that is an SCM that is the same as parent with a path in the parent. the parent scm provider would look up the parent's scm and could use some rules to derive the effective path, acting like a delegate and giving us the correct path. It does mean that unless prerequmaven3.1/maven/prerequ users would have to specify the scm in all initial child modules. On 29 July 2011 08:39, Mark Struberg strub...@yahoo.de wrote: gnah sorry :( I explicitly tested the schema validation, but obviously using a new tool (I'm new to macs...) at 3 o clock in the morning isn't producing reliable results :/ But your idea with the XSD-4.0.1 sound really great. Almost too good to believe! That would probably allow us to implement most of the new features like mixins and stuff _without_ getting incompatible. Maybe we could not implement all the new stuff, but it's worth thinking about it. Otoh I'm not sure if such a change should be done in a bugfix release. Or better said: I'm pretty sure that we should _not_ do such a change in a bugfix release ;) LieGrue, strub --- On Fri, 7/29/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 2:01 AM I have some perhaps minor bad news about attributes. Attributes on the url/ element won't validate against the current schema. I had hoped to discover otherwise, but no such luck. The combine.children trick passes because it is inside of the 'any' inside the plugin configuration. I claim that the following is tolerable from a compatibility standpoint: 1) create a 4.0.1 XSD file that adds the necessary xs:anyAttribute (or specific attributes, if you prefer) to the url/ element. 2) Change default archetypes and the release plugin and friends to add this schema instead of the 4.0.0 schema. In other words, Mark's experiments show that, in *practical* terms, adding the attributes works. That leave the question of programs that actually pay attention to the schema itself. The only bad case would be some program out there which for some reason always validates against the 4.0.0 schema even if the schema declared at the top is 4.0.1. I don't believe in this. - 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 - 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: [DISCUSS] SCM child-project URL composition
On 29/07/2011, at 9:35 PM, Benson Margulies wrote: I'm in favor of the policy (since I suggested it), that maven 3.0.X can deliver pom XSD 4.0.Y, where the changes the the XSD are proven to be harmless to popular old versions and common sense characterizes them as unlikely to blow anything up. I submit that adding some inheritance control attributes would come under that rubric. Do we need to vote this, or otherwise clarify consensus or the lack thereof? Does anyone hate it? I'm just a bit behind on mail, but need a clarification - in Maven the XSD is an end result of the model that is generated, but you seem to describe it here as an input. Am I misreading? If you're suggesting a change to the model that is backwards compat API-wise with 4.0.0, and has identical behaviour (or graceful degradation) when read from the repository by = 3.0.3, then I don't see any problem with a particular change. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
On 29 July 2011 12:35, Benson Margulies bimargul...@gmail.com wrote: I'm in favor of the policy (since I suggested it), that maven 3.0.X I think that requires at least a minor bump I would not be happy with classing those as a patch bump can deliver pom XSD 4.0.Y, where the changes the the XSD are proven to be harmless to popular old versions and common sense characterizes them as unlikely to blow anything up. I submit that adding some inheritance control attributes would come under that rubric. Do we need to vote this, or otherwise clarify consensus or the lack thereof? Does anyone hate it? On Fri, Jul 29, 2011 at 4:26 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: How about coming at this from a different track... scmscm:parent:/path/in/parent/scm that is an SCM that is the same as parent with a path in the parent. the parent scm provider would look up the parent's scm and could use some rules to derive the effective path, acting like a delegate and giving us the correct path. It does mean that unless prerequmaven3.1/maven/prerequ users would have to specify the scm in all initial child modules. On 29 July 2011 08:39, Mark Struberg strub...@yahoo.de wrote: gnah sorry :( I explicitly tested the schema validation, but obviously using a new tool (I'm new to macs...) at 3 o clock in the morning isn't producing reliable results :/ But your idea with the XSD-4.0.1 sound really great. Almost too good to believe! That would probably allow us to implement most of the new features like mixins and stuff _without_ getting incompatible. Maybe we could not implement all the new stuff, but it's worth thinking about it. Otoh I'm not sure if such a change should be done in a bugfix release. Or better said: I'm pretty sure that we should _not_ do such a change in a bugfix release ;) LieGrue, strub --- On Fri, 7/29/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 2:01 AM I have some perhaps minor bad news about attributes. Attributes on the url/ element won't validate against the current schema. I had hoped to discover otherwise, but no such luck. The combine.children trick passes because it is inside of the 'any' inside the plugin configuration. I claim that the following is tolerable from a compatibility standpoint: 1) create a 4.0.1 XSD file that adds the necessary xs:anyAttribute (or specific attributes, if you prefer) to the url/ element. 2) Change default archetypes and the release plugin and friends to add this schema instead of the 4.0.0 schema. In other words, Mark's experiments show that, in *practical* terms, adding the attributes works. That leave the question of programs that actually pay attention to the schema itself. The only bad case would be some program out there which for some reason always validates against the 4.0.0 schema even if the schema declared at the top is 4.0.1. I don't believe in this. - 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
We of course also should think one step further and also make a check how we proceed from XSD-4.0.1 to 4.0.2 LieGrue, strub --- On Fri, 7/29/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 11:35 AM I'm in favor of the policy (since I suggested it), that maven 3.0.X can deliver pom XSD 4.0.Y, where the changes the the XSD are proven to be harmless to popular old versions and common sense characterizes them as unlikely to blow anything up. I submit that adding some inheritance control attributes would come under that rubric. Do we need to vote this, or otherwise clarify consensus or the lack thereof? Does anyone hate it? On Fri, Jul 29, 2011 at 4:26 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: How about coming at this from a different track... scmscm:parent:/path/in/parent/scm that is an SCM that is the same as parent with a path in the parent. the parent scm provider would look up the parent's scm and could use some rules to derive the effective path, acting like a delegate and giving us the correct path. It does mean that unless prerequmaven3.1/maven/prerequ users would have to specify the scm in all initial child modules. On 29 July 2011 08:39, Mark Struberg strub...@yahoo.de wrote: gnah sorry :( I explicitly tested the schema validation, but obviously using a new tool (I'm new to macs...) at 3 o clock in the morning isn't producing reliable results :/ But your idea with the XSD-4.0.1 sound really great. Almost too good to believe! That would probably allow us to implement most of the new features like mixins and stuff _without_ getting incompatible. Maybe we could not implement all the new stuff, but it's worth thinking about it. Otoh I'm not sure if such a change should be done in a bugfix release. Or better said: I'm pretty sure that we should _not_ do such a change in a bugfix release ;) LieGrue, strub --- On Fri, 7/29/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 2:01 AM I have some perhaps minor bad news about attributes. Attributes on the url/ element won't validate against the current schema. I had hoped to discover otherwise, but no such luck. The combine.children trick passes because it is inside of the 'any' inside the plugin configuration. I claim that the following is tolerable from a compatibility standpoint: 1) create a 4.0.1 XSD file that adds the necessary xs:anyAttribute (or specific attributes, if you prefer) to the url/ element. 2) Change default archetypes and the release plugin and friends to add this schema instead of the 4.0.0 schema. In other words, Mark's experiments show that, in *practical* terms, adding the attributes works. That leave the question of programs that actually pay attention to the schema itself. The only bad case would be some program out there which for some reason always validates against the 4.0.0 schema even if the schema declared at the top is 4.0.1. I don't believe in this. - 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
A few more 'schematic' notes. 1) AFAIKT, the schema isn't really part of the maven core. Nothing in maven core ever looks at it. The ancient pull parser in plexus wouldn't know a schema if one fell on it from a height. 2) We could publish a 4.0.1 schema tomorrow on the web site (does it need a release vote? :-)) and disturb nothing, since nothing will look at it until someone bothers to edit a POM to point to it. 3) At least the release plugin has a feature for adding schema declarations. We could hold off on changing it, and document: if you want to use these new features, it's up to you to put the new schema URL into your POM if you want to validate. On Fri, Jul 29, 2011 at 7:35 AM, Benson Margulies bimargul...@gmail.com wrote: I'm in favor of the policy (since I suggested it), that maven 3.0.X can deliver pom XSD 4.0.Y, where the changes the the XSD are proven to be harmless to popular old versions and common sense characterizes them as unlikely to blow anything up. I submit that adding some inheritance control attributes would come under that rubric. Do we need to vote this, or otherwise clarify consensus or the lack thereof? Does anyone hate it? On Fri, Jul 29, 2011 at 4:26 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: How about coming at this from a different track... scmscm:parent:/path/in/parent/scm that is an SCM that is the same as parent with a path in the parent. the parent scm provider would look up the parent's scm and could use some rules to derive the effective path, acting like a delegate and giving us the correct path. It does mean that unless prerequmaven3.1/maven/prerequ users would have to specify the scm in all initial child modules. On 29 July 2011 08:39, Mark Struberg strub...@yahoo.de wrote: gnah sorry :( I explicitly tested the schema validation, but obviously using a new tool (I'm new to macs...) at 3 o clock in the morning isn't producing reliable results :/ But your idea with the XSD-4.0.1 sound really great. Almost too good to believe! That would probably allow us to implement most of the new features like mixins and stuff _without_ getting incompatible. Maybe we could not implement all the new stuff, but it's worth thinking about it. Otoh I'm not sure if such a change should be done in a bugfix release. Or better said: I'm pretty sure that we should _not_ do such a change in a bugfix release ;) LieGrue, strub --- On Fri, 7/29/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 2:01 AM I have some perhaps minor bad news about attributes. Attributes on the url/ element won't validate against the current schema. I had hoped to discover otherwise, but no such luck. The combine.children trick passes because it is inside of the 'any' inside the plugin configuration. I claim that the following is tolerable from a compatibility standpoint: 1) create a 4.0.1 XSD file that adds the necessary xs:anyAttribute (or specific attributes, if you prefer) to the url/ element. 2) Change default archetypes and the release plugin and friends to add this schema instead of the 4.0.0 schema. In other words, Mark's experiments show that, in *practical* terms, adding the attributes works. That leave the question of programs that actually pay attention to the schema itself. The only bad case would be some program out there which for some reason always validates against the 4.0.0 schema even if the schema declared at the top is 4.0.1. I don't believe in this. - 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 - 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: [DISCUSS] SCM child-project URL composition
thereof? Does anyone hate it? I'm just a bit behind on mail, but need a clarification - in Maven the XSD is an end result of the model that is generated, but you seem to describe it here as an input. Am I misreading? I've been assuming that the XSD file is a manual production, but I didn't actually check. I guess that modello might be in the business of excreting XSD files, too. So my more recent email is a bit wrong. If you're suggesting a change to the model that is backwards compat API-wise with 4.0.0, and has identical behaviour (or graceful degradation) when read from the repository by = 3.0.3, then I don't see any problem with a particular change. Yes, that's precisely the idea. Some new accessors appear in the model, and if you don't bother them, they won't bother you. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - 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
broken test in maven-javadoc-plugin
Hi! This is a sum-up of my last 5 hours of debugging. Currently there is a failing test in the maven-javadoc-plugin: JavadocReportTest#testProxy() This test fails since the last commit but I actually think it only ever worked by accident. It did rely on a commons-logging-1.0.4.pom which got resolved by a test which did run previously. But after updating to commons-logging.1.1.1 there is no pre-resolved artifact available in target/local-repo anymore, thus the javadoc link info cannot get built and the test fails in line 829: assertTrue( optionsContent.contains( -link 'http://commons.apache.org/logging/apidocs' ) ); I'll for now just disable this line of code, because the test as far as I can see _never_ did go upstream. The remoteRepository list used is always empty!. If anyone has an idea how to get this fixed properly, then please speak up ;) LieGrue, strug - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
On 7/29/11 7:45 AM, Benson Margulies wrote: thereof? Does anyone hate it? I'm just a bit behind on mail, but need a clarification - in Maven the XSD is an end result of the model that is generated, but you seem to describe it here as an input. Am I misreading? I've been assuming that the XSD file is a manual production, but I didn't actually check. I guess that modello might be in the business of excreting XSD files, too. So my more recent email is a bit wrong. Yes, Modello is used to generate the XSD. So the next question that comes up is: can we generate an XSD like you describe using Modello? If we can, I think this is a pretty decent plan, actually...the best of limited options, IMO. If we get the alternative format work done later, then we escape the need to live with the format forever too. So, the danger that we're adding to our ball of tape and chewing gum is limited by that. If you're suggesting a change to the model that is backwards compat API-wise with 4.0.0, and has identical behaviour (or graceful degradation) when read from the repository by= 3.0.3, then I don't see any problem with a particular change. Yes, that's precisely the idea. Some new accessors appear in the model, and if you don't bother them, they won't bother you. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - 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 -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
I think Herve said so. On Jul 29, 2011, at 10:50 AM, John Casey jdca...@commonjava.org wrote: On 7/29/11 7:45 AM, Benson Margulies wrote: thereof? Does anyone hate it? I'm just a bit behind on mail, but need a clarification - in Maven the XSD is an end result of the model that is generated, but you seem to describe it here as an input. Am I misreading? I've been assuming that the XSD file is a manual production, but I didn't actually check. I guess that modello might be in the business of excreting XSD files, too. So my more recent email is a bit wrong. Yes, Modello is used to generate the XSD. So the next question that comes up is: can we generate an XSD like you describe using Modello? If we can, I think this is a pretty decent plan, actually...the best of limited options, IMO. If we get the alternative format work done later, then we escape the need to live with the format forever too. So, the danger that we're adding to our ball of tape and chewing gum is limited by that. If you're suggesting a change to the model that is backwards compat API-wise with 4.0.0, and has identical behaviour (or graceful degradation) when read from the repository by= 3.0.3, then I don't see any problem with a particular change. Yes, that's precisely the idea. Some new accessors appear in the model, and if you don't bother them, they won't bother you. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - 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 -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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: broken test in maven-javadoc-plugin
I discovered the same issue. The problem didn't show itself with a dirty target-folder, but after a mvn clean test it was easy to reproduce.I noticed the test had to do with the proxy, couldn't figure out how this test should work. Now I know: it doesn't. -Robert Date: Fri, 29 Jul 2011 15:22:46 +0100 From: strub...@yahoo.de Subject: broken test in maven-javadoc-plugin To: dev@maven.apache.org Hi! This is a sum-up of my last 5 hours of debugging. Currently there is a failing test in the maven-javadoc-plugin: JavadocReportTest#testProxy() This test fails since the last commit but I actually think it only ever worked by accident. It did rely on a commons-logging-1.0.4.pom which got resolved by a test which did run previously. But after updating to commons-logging.1.1.1 there is no pre-resolved artifact available in target/local-repo anymore, thus the javadoc link info cannot get built and the test fails in line 829: assertTrue( optionsContent.contains( -link 'http://commons.apache.org/logging/apidocs' ) ); I'll for now just disable this line of code, because the test as far as I can see _never_ did go upstream. The remoteRepository list used is always empty!. If anyone has an idea how to get this fixed properly, then please speak up ;) LieGrue, strug - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
-0 I don't like it, but I'm not the one doing the work. I'd accept it if there's no better way to get the problems fixed for whoever is working to fix them. I don't think it's good to get stuck on an old version no one is maintaining. I'm happy to discuss ideas for alternatives. However, I would strongly prefer it to remain dual licensed: - it gives us more options if we need to incorporate source code changes that aren't accepted upstream, particularly if goals change over time - consumers know what they are getting from Maven - it can all be used under the terms of the AL 2.0. - it had the terms of the AL 2.0 when we agreed to incorporate it I continue to hope that will be reconsidered. FWIW, I don't have any argument with regard to the EPL as a license, I just believe AL 2.0 is appropriate here given its history, the early state of community development, and with Maven as its primary consumer. - Brett On 28/07/2011, at 4:45 AM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: broken test in maven-javadoc-plugin
Heh Robert, thanks for sharing ;) I actually was not 100% sure, so it took me a bit time to really understand what this thing might be supposed to do. And that it was actually only working by accident so far. LieGrue, strub --- On Fri, 7/29/11, Robert Scholte rfscho...@codehaus.org wrote: From: Robert Scholte rfscho...@codehaus.org Subject: RE: broken test in maven-javadoc-plugin To: dev@maven.apache.org Date: Friday, July 29, 2011, 4:57 PM I discovered the same issue. The problem didn't show itself with a dirty target-folder, but after a mvn clean test it was easy to reproduce.I noticed the test had to do with the proxy, couldn't figure out how this test should work. Now I know: it doesn't. -Robert Date: Fri, 29 Jul 2011 15:22:46 +0100 From: strub...@yahoo.de Subject: broken test in maven-javadoc-plugin To: dev@maven.apache.org Hi! This is a sum-up of my last 5 hours of debugging. Currently there is a failing test in the maven-javadoc-plugin: JavadocReportTest#testProxy() This test fails since the last commit but I actually think it only ever worked by accident. It did rely on a commons-logging-1.0.4.pom which got resolved by a test which did run previously. But after updating to commons-logging.1.1.1 there is no pre-resolved artifact available in target/local-repo anymore, thus the javadoc link info cannot get built and the test fails in line 829: assertTrue( optionsContent.contains( -link 'http://commons.apache.org/logging/apidocs' ) ); I'll for now just disable this line of code, because the test as far as I can see _never_ did go upstream. The remoteRepository list used is always empty!. If anyone has an idea how to get this fixed properly, then please speak up ;) LieGrue, strug - 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: [VOTE] Incorporate EPL Ether in Maven Releases
I know I stepped away from maven quite some time ago, jetty and other things just don't allow the time...but I have followed this discussion and I'll toss in my two cents. I would be +1 on this and would come to the defense of jason and sonatype on this because no matter what you want to argue about what has and hasn't been done, they have done a ton of the work moving maven forward over the last few years. maven-artifact and a lot of its plumbing has been a bane and annoyance for users and developers with maven alike for years. Aether does the job of handling a chunk of the heavy lifting and if its at all better then what is there then its a no brainer imo. I have known Jason for years and I like to think of him as a friend and I have always thought that he acted with the end users of Maven in mind, what he thinks is best for them. I think that is one thing you can count on, if he is involved with it then the motives, corporate or otherwise, are to support the end users better. Now should that differ from what the maven developer community at large feels at some point in the future then any license currently being discussed has options available to the maven developers. Trying to penalize Jason directly or Sonatype as some of these comments/discussions have done (not necessarily on this thread) does not benefit the end user. I don't really see the point of delaying the vote until the eclipse process has completed either, better would be to cc wayne beaton in on this and ask for early acceptance to get the ball rolling. No reason to be antagonistic about all this. jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Jul 29, 2011 at 12:16, Brett Porter br...@apache.org wrote: -0 I don't like it, but I'm not the one doing the work. I'd accept it if there's no better way to get the problems fixed for whoever is working to fix them. I don't think it's good to get stuck on an old version no one is maintaining. I'm happy to discuss ideas for alternatives. However, I would strongly prefer it to remain dual licensed: - it gives us more options if we need to incorporate source code changes that aren't accepted upstream, particularly if goals change over time - consumers know what they are getting from Maven - it can all be used under the terms of the AL 2.0. - it had the terms of the AL 2.0 when we agreed to incorporate it I continue to hope that will be reconsidered. FWIW, I don't have any argument with regard to the EPL as a license, I just believe AL 2.0 is appropriate here given its history, the early state of community development, and with Maven as its primary consumer. - Brett On 28/07/2011, at 4:45 AM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - 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: [VOTE] Incorporate EPL Ether in Maven Releases
Jesse, there is no private problem involved. The problem is solely that the Maven project just cannot decide itself what it is going to fix and how it will implement features that way. LieGrue, strub --- On Fri, 7/29/11, Jesse McConnell jesse.mcconn...@gmail.com wrote: From: Jesse McConnell jesse.mcconn...@gmail.com Subject: Re: [VOTE] Incorporate EPL Ether in Maven Releases To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 6:26 PM I know I stepped away from maven quite some time ago, jetty and other things just don't allow the time...but I have followed this discussion and I'll toss in my two cents. I would be +1 on this and would come to the defense of jason and sonatype on this because no matter what you want to argue about what has and hasn't been done, they have done a ton of the work moving maven forward over the last few years. maven-artifact and a lot of its plumbing has been a bane and annoyance for users and developers with maven alike for years. Aether does the job of handling a chunk of the heavy lifting and if its at all better then what is there then its a no brainer imo. I have known Jason for years and I like to think of him as a friend and I have always thought that he acted with the end users of Maven in mind, what he thinks is best for them. I think that is one thing you can count on, if he is involved with it then the motives, corporate or otherwise, are to support the end users better. Now should that differ from what the maven developer community at large feels at some point in the future then any license currently being discussed has options available to the maven developers. Trying to penalize Jason directly or Sonatype as some of these comments/discussions have done (not necessarily on this thread) does not benefit the end user. I don't really see the point of delaying the vote until the eclipse process has completed either, better would be to cc wayne beaton in on this and ask for early acceptance to get the ball rolling. No reason to be antagonistic about all this. jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Fri, Jul 29, 2011 at 12:16, Brett Porter br...@apache.org wrote: -0 I don't like it, but I'm not the one doing the work. I'd accept it if there's no better way to get the problems fixed for whoever is working to fix them. I don't think it's good to get stuck on an old version no one is maintaining. I'm happy to discuss ideas for alternatives. However, I would strongly prefer it to remain dual licensed: - it gives us more options if we need to incorporate source code changes that aren't accepted upstream, particularly if goals change over time - consumers know what they are getting from Maven - it can all be used under the terms of the AL 2.0. - it had the terms of the AL 2.0 when we agreed to incorporate it I continue to hope that will be reconsidered. FWIW, I don't have any argument with regard to the EPL as a license, I just believe AL 2.0 is appropriate here given its history, the early state of community development, and with Maven as its primary consumer. - Brett On 28/07/2011, at 4:45 AM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
+0 I think the license issue is a false problem as it is mixed with an IP issue and in any case we'll don't get back this code inside Maven land as its authors don't want. The issue to control this part of code is legitimate but the only solution is to rewrite it from scratch (again) cheers Arnaud On Fri, Jul 29, 2011 at 7:16 PM, Brett Porter br...@apache.org wrote: -0 I don't like it, but I'm not the one doing the work. I'd accept it if there's no better way to get the problems fixed for whoever is working to fix them. I don't think it's good to get stuck on an old version no one is maintaining. I'm happy to discuss ideas for alternatives. However, I would strongly prefer it to remain dual licensed: - it gives us more options if we need to incorporate source code changes that aren't accepted upstream, particularly if goals change over time - consumers know what they are getting from Maven - it can all be used under the terms of the AL 2.0. - it had the terms of the AL 2.0 when we agreed to incorporate it I continue to hope that will be reconsidered. FWIW, I don't have any argument with regard to the EPL as a license, I just believe AL 2.0 is appropriate here given its history, the early state of community development, and with Maven as its primary consumer. - Brett On 28/07/2011, at 4:45 AM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: broken test in maven-javadoc-plugin
Hi Mark I spent a couple of hours debugging this earlier this week. Unfortunately I wasn't able to crack it. But I find your conclusion very plausible. On 2011-07-29 16:22, Mark Struberg wrote: Hi! This is a sum-up of my last 5 hours of debugging. Currently there is a failing test in the maven-javadoc-plugin: JavadocReportTest#testProxy() This test fails since the last commit but I actually think it only ever worked by accident. It did rely on a commons-logging-1.0.4.pom which got resolved by a test which did run previously. But after updating to commons-logging.1.1.1 there is no pre-resolved artifact available in target/local-repo anymore, thus the javadoc link info cannot get built and the test fails in line 829: assertTrue( optionsContent.contains( -link 'http://commons.apache.org/logging/apidocs' ) ); I'll for now just disable this line of code, because the test as far as I can see _never_ did go upstream. The remoteRepository list used is always empty!. If anyone has an idea how to get this fixed properly, then please speak up ;) LieGrue, strug - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: broken test in maven-javadoc-plugin
Hi Dennis! I think we could test this if we start a local jetty serving as a repo http server which only provides one dummy artifact. Then we need to startup a proxy and point maven to this proxy. Sounds like a bit more work, and I'd rather do that in an integration test and not via a unit test. LieGrue, strub --- On Fri, 7/29/11, Dennis Lundberg denn...@apache.org wrote: From: Dennis Lundberg denn...@apache.org Subject: Re: broken test in maven-javadoc-plugin To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 9:59 PM Hi Mark I spent a couple of hours debugging this earlier this week. Unfortunately I wasn't able to crack it. But I find your conclusion very plausible. On 2011-07-29 16:22, Mark Struberg wrote: Hi! This is a sum-up of my last 5 hours of debugging. Currently there is a failing test in the maven-javadoc-plugin: JavadocReportTest#testProxy() This test fails since the last commit but I actually think it only ever worked by accident. It did rely on a commons-logging-1.0.4.pom which got resolved by a test which did run previously. But after updating to commons-logging.1.1.1 there is no pre-resolved artifact available in target/local-repo anymore, thus the javadoc link info cannot get built and the test fails in line 829: assertTrue( optionsContent.contains( -link 'http://commons.apache.org/logging/apidocs' ) ); I'll for now just disable this line of code, because the test as far as I can see _never_ did go upstream. The remoteRepository list used is always empty!. If anyone has an idea how to get this fixed properly, then please speak up ;) LieGrue, strug - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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: broken test in maven-javadoc-plugin
On 2011-07-30 00:13, Mark Struberg wrote: Hi Dennis! I think we could test this if we start a local jetty serving as a repo http server which only provides one dummy artifact. Then we need to startup a proxy and point maven to this proxy. Sounds like a bit more work, and I'd rather do that in an integration test and not via a unit test. Yup, that's the way to go. I found the tests overly complicated for being just unit tests. LieGrue, strub --- On Fri, 7/29/11, Dennis Lundberg denn...@apache.org wrote: From: Dennis Lundberg denn...@apache.org Subject: Re: broken test in maven-javadoc-plugin To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 9:59 PM Hi Mark I spent a couple of hours debugging this earlier this week. Unfortunately I wasn't able to crack it. But I find your conclusion very plausible. On 2011-07-29 16:22, Mark Struberg wrote: Hi! This is a sum-up of my last 5 hours of debugging. Currently there is a failing test in the maven-javadoc-plugin: JavadocReportTest#testProxy() This test fails since the last commit but I actually think it only ever worked by accident. It did rely on a commons-logging-1.0.4.pom which got resolved by a test which did run previously. But after updating to commons-logging.1.1.1 there is no pre-resolved artifact available in target/local-repo anymore, thus the javadoc link info cannot get built and the test fails in line 829: assertTrue( optionsContent.contains( -link 'http://commons.apache.org/logging/apidocs' ) ); I'll for now just disable this line of code, because the test as far as I can see _never_ did go upstream. The remoteRepository list used is always empty!. If anyone has an idea how to get this fixed properly, then please speak up ;) LieGrue, strug - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
non-reproducible issues on CI
Hi! Our CI is broken since a while and most of the errors are of the following kind: [ERROR] Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced - [Help 1] org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:129) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:142) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:261) at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:185) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:235) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:106) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:86) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:98) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.sonatype.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:282) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:316) at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:115) ... 20 more Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:541) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:220) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:197) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:267) ... 23 more Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until
RE: non-reproducible issues on CI
Mark- ..do you have snapshots enabled false for your repository..e.g repositories repository snapshots enabledfalse/enabled /snapshots /repository /repositories Liebe GruBe Martin __ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Date: Sat, 30 Jul 2011 00:22:12 +0100 From: strub...@yahoo.de Subject: non-reproducible issues on CI To: dev@maven.apache.org Hi! Our CI is broken since a while and most of the errors are of the following kind: [ERROR] Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced - [Help 1] org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:129) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:142) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:261) at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:185) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:235) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:106) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:86) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:98) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.sonatype.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:282) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:316) at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:115) ... 20 more Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until the update interval of local.central has
Re: non-reproducible issues on CI
I think I've seen a similar error come up on a few boxes of my own. I think it has something to do with the lastUpdated terminator in your repository. I've had some success removing this off of POMs that wouldn't download. Alternatively, nuking the repository might help. My two cents. Andrew On Jul 29, 2011, at 6:22 PM, Mark Struberg wrote: Hi! Our CI is broken since a while and most of the errors are of the following kind: [ERROR] Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced - [Help 1] org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:129) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:142) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:261) at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:185) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:235) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:106) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:86) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:98) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.sonatype.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:282) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:316) at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:115) ... 20 more Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:541) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:220) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:197) at
