Re: [DISCUSS] [VOTE] Should we respin CANCELLED releases with the same version number?
Actually clarified that the release plugin is being used but the tag is being forced to a different name and then moved post successful release, e.g. mvn release:prepate release:perform -DreleaseVersion=3.1.0 -Dtag=3.1.0-RC1 Now there is an issue with that in that the pom will contain the wrong tag in the scm section... $ svn log --limit 5 -v https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.5 r1456364 | bodewig | 2013-03-14 08:43:27 + (Thu, 14 Mar 2013) | 1 line Changed paths: A /commons/proper/compress/tags/COMPRESS-1.5 (from /commons/proper/compress/tags/COMPRESS-1.5_RC1:1456363) Vote has passed, 1.5 is released r1455005 | bodewig | 2013-03-11 06:10:51 + (Mon, 11 Mar 2013) | 1 line Changed paths: A /commons/proper/compress/tags/COMPRESS-1.5_RC1 (from /commons/proper/compress/trunk:1455004) M /commons/proper/compress/tags/COMPRESS-1.5_RC1/pom.xml Tagging first RC for Compress 1.5 So they are not using the release plugin then... perhaps a pseudo-tag option is needed for the release plugin then... On 29 May 2013 13:40, Barrie Treloar wrote: > On 29 May 2013 20:53, Stephen Connolly > wrote: > > The issue with that is when using the Maven Release Plugin, you will not > be > ... > > Can't we fix the tooling then? > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
On Thursday, 30 May 2013, Chris Graham wrote: > What do we currently do for plugins? What do we currently do for core? > Is there in difference in the approach taken? No difference. In each case we currently respin failed votes reusing the version number until we get an actual successful vote. > > We call for a vot for vX.Y.Z of (plugins's [recently at > least] do not appear to go throught he beta/RC phases). That is down to not really having new core plugins recently, and the size of changes being such that the release manager felt there was no need for an alpha/beta Because of the switch from sonatype aether to eclipse aether *and* the exposing of the aether API to plugins, for Maven 3.1.0 jumping straight to 3.1.0 was deemed too risky by the release manager, hence 3.1.0-alpha-1. Personally, given the lack of review the 3.1.0-SNAPSHOTs were getting, this was probably a wise plan... However I think quite a few people have put their eyes on the code by now, so *if* I was the release manager, I'd be tempted to head straight for 3.1.0... Thankfully I am not release manager for this release, so not my problem ;-) (Note: the release manager is just whoever stands up and says "I want to cut a release of XYZ"... Can change with every release, or stay mostly the same. Eg Kristian has been release manager for Surefire by consistently stepping up and cutting releases, but if any other committer wanted to run a release they can step up at any time... It's actually something we encourage newer committers to do (usually starting with smaller plugins though) so that they can get a feel for how our release process works (learn by doing)) > > Can someone please spell out a sequence of events (by time) as to what > happens through the entire process? From prep to vote to ending up in > central. > > Slightly simplified, and there are differences for components vs plugins vs core, but essential principle remains close to this 1. Run `mvn release:prepare release:perform` 2. Send the "[vote]" email 3. Wait 72h (or longer if not enough binding votes and the release manager thinks some more binding votes will turn up) 4. On nexus, promote the staging repo 5. Update JIRA versions 6. Update the component's site (and for plugins the table of plugin versions) 7. Copy the artifacts to dist 8. Wait for "the sync" to central 9. Send "[ann]" email And the same sequnce, but for a failed vote, and it's revoting (we've used > the same version no again, here, have we not?) After step 3, we currently delete the tag, go back to step 1. And release again reusing the same version number from the first time. > > -Chris > > > > On Thu, May 30, 2013 at 6:11 AM, Fred Cooke > > > wrote: > > > > > > > -1 for actual releases: it would create more mess imo for end users if > > > there's many bizarre jumps in numbering > > > > > > The thing with this argument is that it's very, very weak. If a missed > > version confuses a user, they're basically brain-dead. Assuming your > users > > are brain dead is _always_ dangerous. Assuming the users or a > _development_ > > tool are brain-dead is that in and of itself IMO. > > > > A random example from central that I gave to Robert earlier: > > > > > > > http://search.maven.org/#search|gav|1|g%3A%22antlr%22%20AND%20a%3A%22antlr%22 > > > > I don't know about the rest of you... but I'm not confused by the absence > > of 2.7.3 in any way shape or form. I'm additionally not confused by the > > absence of 2.7.8, 2.7.9, 2.7.10, etc, nor 2.8.* nor 2.9.* It's > meaningless > > to me that they're absent. I use and test a version (usually latest) and > > verify it functions adequately for my needs, then I depend on it (dep or > > plugin equally) and that's it. If I find a flaw, or need to use a new > > feature, then I can go looking for the best version that is compatible > with > > my setup, that contains it (again, likely latest, API change not > > withstanding). > > > > Being worried about developers being confused by a non-sequential set of > > binaries to choose from is bizarre at best. Developers, even the bad > ones, > > are generally a fairly intelligent bunch. > > > > This is not winamp! :-p (nor VLC) > > > > Fred. > > > -- Sent from my phone
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
On 30 May 2013 10:30, Chris Graham wrote: > Thank you Stephen for taking the time to explain. > > To me, the key critical bits are: > > 1. The full normal tag is created, and deleted if failed. If the release > process fails (as in release:prepare/release:perform) we often have to > delete the tag and manually re-run it anyway. > Well to my mind that is also part of the issue If we accept that failed tags get deleted, then we should respin reusing the same version number until we have a non-failed tag (irrespective of the reason for the failure) If we don't reuse version numbers, it should be ever, in which case if release:prepare produces a tag that *cannot* complete release:perform (as opposed to just a failure for a single run of release:perform) then we would not delete the tag and run release:prepare for the next version number. In that sense I don't see this as a critical bit... rather I see it as part of what should be covered by the vote. > 2. The copying process to get it in the wild is manual and post vote. > Not quite true, the artifacts are in the wild... just in a staging repository from which they can be deleted. The copy to dist is a legal requirement to ensure the legal protections that the ASF provides remain in force (this is also why the PMC have binding votes, and why the PMC has to concern itself with annoying pesky things like ensuring that the NOTICE.txt has correct content and that files have the correct license headers... I may not, in the past, have fully appreciated the reasons for or the needs for these things... but since becoming a member of the ASF [with the legal responsibilities that come with that] I have gained a different perspective). But there is always concern from people that they will end up with their local repository corrupted as a side-effect of testing. For instance, suppose there is a fix related to how some component works behind a proxy. That may well require you to add the staging repository to your corporate proxy repository (because the machines you want to test from, and perhaps even the scenario you want to test, are required to have a * in their settings.xml)... in such a case you will end up with the situation that the test machines have downloaded the artifacts into their local repository cache *and* even with the repository source validation that Maven 3.x brings to the table, you will need to manually purge those artifacts from your local repository cache *because* the * will be forcing the source of those release artifacts to be unchanged. Now one could argue that you shouldn't be adding the staging repo to your proxy in the first place, and instead you should create a special proxy on your repository manager that adds in the staging repo on top of the normal proxy and update the settings.xml to use this new mirrorOf source... but that will force everything to be re-downloaded into the local cache *and* there are test circumstances where one might fear that such a change could affect the validity of your testing. The above, to my mind, is the primary driver for never reusing version numbers... whether it is worthy of the change is for all to decide... My current thinking is though: * if we allow deleting tags because the tag won't complete release:perform, then we should re-use version numbers. * if we don't allow re-using version numbers, then we should not allow deleting tags *just* because the tag won't complete release:perform. And I am considering whether I want to change my vote ;-) > Given that, I have no problem with respinning a release using the same > version, which is, essentially what we have been doing. > > This is very similar to what I do for the day job. But not the same. In the > day job, we through away a release and just create a new one. > > Why the difference? > > Simple, the audience for the day job is limited, and the decision to > release is driven by the tech lead and immediate. > > There is no voting process. > > In this OS world, we are talking about release X.Y.Z (or whatever) and, > personally, I remember X.Y.Z. I would quickly get confused if I had to > constantly remember that X.Y.Z is now X.Y.(Z+N). > > Additionally, the vote remains open for a period of time, and I would get > lost with the constantly changing numbers. Note, this is not the same as > saying anything about skipped public version numbers. > > For the same reason, I would recommend offering different approaches to > core/plugins/whatever: let's not complicate things. > > So, to that end, > > -1 (ie respin) for all > > (non binding) > > -Chris > > > > On Thu, May 30, 2013 at 5:11 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On Thursday, 30 May 2013, Chris Graham wrote: > > > > > What do we currently do
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
As far as the ASF is concerned, from a legal perspective, the tag is not a release. The only release is the src.tar.gz in the dist folder or the archives. Tags and binaries are simply a convenience for users. Whether that is something that is important to the Maven community is a different question though. On 30 May 2013 11:26, Chris Graham wrote: > One more thing to consider: > > It's a huge change; as if you do not delete, you now have broken 'releases' > in a SCM somwhere, and that is radically different to what is currently > there. > > I should be able to check anything out now from a tag, build it and have it > work. > > If we allow broken tags, then we could be frustrating a lot of people. > > It's a huge change of process. > > And for me, I prefer not to introduce it. > > We also have maven's concept of immutability, which is a reason NOT to > allow the reuse of numbers; however, that does not appear to have been too > much of a problem up until now. > > -Chris > > > > > On Thu, May 30, 2013 at 7:55 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On 30 May 2013 10:30, Chris Graham wrote: > > > > > Thank you Stephen for taking the time to explain. > > > > > > To me, the key critical bits are: > > > > > > 1. The full normal tag is created, and deleted if failed. If the > release > > > process fails (as in release:prepare/release:perform) we often have to > > > delete the tag and manually re-run it anyway. > > > > > > > Well to my mind that is also part of the issue > > > > If we accept that failed tags get deleted, then we should respin reusing > > the same version number until we have a non-failed tag (irrespective of > the > > reason for the failure) > > > > If we don't reuse version numbers, it should be ever, in which case if > > release:prepare produces a tag that *cannot* complete release:perform (as > > opposed to just a failure for a single run of release:perform) then we > > would not delete the tag and run release:prepare for the next version > > number. > > > > In that sense I don't see this as a critical bit... rather I see it as > part > > of what should be covered by the vote. > > > > > > > 2. The copying process to get it in the wild is manual and post vote. > > > > > > > Not quite true, the artifacts are in the wild... just in a staging > > repository from which they can be deleted. The copy to dist is a legal > > requirement to ensure the legal protections that the ASF provides remain > in > > force (this is also why the PMC have binding votes, and why the PMC has > to > > concern itself with annoying pesky things like ensuring that the > NOTICE.txt > > has correct content and that files have the correct license headers... I > > may not, in the past, have fully appreciated the reasons for or the needs > > for these things... but since becoming a member of the ASF [with the > legal > > responsibilities that come with that] I have gained a different > > perspective). > > > > But there is always concern from people that they will end up with their > > local repository corrupted as a side-effect of testing. > > > > For instance, suppose there is a fix related to how some component works > > behind a proxy. That may well require you to add the staging repository > to > > your corporate proxy repository (because the machines you want to test > > from, and perhaps even the scenario you want to test, are required to > have > > a * in their settings.xml)... in such a case you > will > > end up with the situation that the test machines have downloaded the > > artifacts into their local repository cache *and* even with the > repository > > source validation that Maven 3.x brings to the table, you will need to > > manually purge those artifacts from your local repository cache *because* > > the * will be forcing the source of those release > > artifacts to be unchanged. > > > > Now one could argue that you shouldn't be adding the staging repo to your > > proxy in the first place, and instead you should create a special proxy > on > > your repository manager that adds in the staging repo on top of the > normal > > proxy and update the settings.xml to use this new mirrorOf source... but > > that will force everything to be re-downloaded into the local cache *and* > > there are test circumstances where one might fear that such a change > could > > affect the validity of your testing. > >
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
On 30 May 2013 11:38, Fred Cooke wrote: > When I first witnessed the deletion of tags > and re-spinning of versions some months ago it was the most disturbing > thing that's happened to me since I found out that Santa Claus wasn't real. > WHAT THE F*CK!!! Are you suggesting to me that he isn't real... I have lost all respect for you... next you'll be telling me that it was my parents who left all those presents under the tree... get out of here you mad man!
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
I will be counting spilt votes like this as the actual release vote... If we want to finesse for alpha and beta after the principle for releases is established, we can have another vote... So to clarify: Robert's vote is currently -1 reuse version numbers when respinning On Thursday, 30 May 2013, Robert Scholte wrote: > Let me rephrase my vote: > > +1 for qualified releases > > -1 for actual releases > > Robert > > Op Wed, 29 May 2013 19:07:59 +0200 schreef Robert Scholte < > rfscho...@apache.org>: > > -1 (binding) on actual releases >> >> Robert >> >> >> Op Wed, 29 May 2013 15:20:17 +0200 schreef Daniel Kulp > >: >> >> +1 for "qualified" releases (alpha, beta, RC, etc…) that are working >>> toward the full blow release but aren't intended to be that. >>> >>> -1 for the actual releases. >>> >>> Dan >>> >>> >>> >>> On May 29, 2013, at 6:01 AM, Stephen Connolly < >>> stephen.alan.conno...@gmail.com> wrote: >>> >>> We have been using a policy of only making releases without skipping >>>> version numbers, e.g. >>>> >>>> 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc >>>> >>>> Whereby if there is something wrong with the artifacts staged for >>>> release, >>>> we drop the staging repo, delete the tag, roll back the version, and run >>>> again. >>>> >>>> This vote is to change the policy to: >>>> >>>> drop the staging repo, document the release as not released, and run >>>> with >>>> the next version. >>>> >>>> Under this new proposal, if the staged artifacts for 3.1.0 fail to meet >>>> the >>>> release criteria, then the artifacts would be dropped from the staging >>>> repository and never see the light of day. The tag would remain in SCM, >>>> and >>>> we would document (somewhere) that the release was cancelled. The >>>> "respin" >>>> would have version number 3.1.1 and there would never be a 3.1.0. >>>> >>>> This change could mean that the first actual release of 3.1.x might end >>>> up >>>> being 3.1.67 (though I personally view that as unlikely, and in the >>>> context >>>> of 3.1.x I think we are very nearly there) >>>> >>>> Please Note: >>>> http://maven.apache.org/**developers/release/maven-** >>>> project-release-procedure.**html#Check_the_vote_**resultsdoes<http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes> >>>> not actually specify what it means by "the process will need to be >>>> restarted" so this vote will effect a change either outcome >>>> >>>> +1: Never respin with the same version number, always increment the >>>> version >>>> for a respin >>>> 0: Don't care >>>> -1: Always respin with the same version number until that version number >>>> gets released >>>> >>>> This vote will be open for 72 hours. A Majority of PMC votes greater >>>> that 3 >>>> will be deemed as decisive in either direction (i.e. if the sum is < -3 >>>> or >>>> >>>>> +3 then there is a documented result) >>>>> >>>> >>>> For any releases in progress at this point in time, it is up to the >>>> release >>>> manager to decide what to do if they need to do a respin. >>>> >>>> -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 > > -- Sent from my phone
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
On Thursday, 30 May 2013, Wayne Fay wrote: > On Thu, May 30, 2013 at 4:55 AM, Stephen Connolly <...> wrote: > > > > And I am considering whether I want to change my vote ;-) Nope I'm sticking with +1 no reusing version numbers After Fred pointed out the immutability thing and given that eg tomcat and other ASF projects use this model... Some other things I are is that with +1 you can push the git tag at the time of the vote (because we will never delete or modify that tag) so we also have the advantage of being able to verify that the source bundle matches the tag at the time of voting... -Stephen > > I am as well. Fred's comments like: > > > but I'm not confused by the absence > > of 2.7.3 in any way shape or form. > and > > The concept of immutability is pretty core to > > Maven (at least in my mind). > > are making me rethink things a little bit. :) > > Wayne > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: [VOTE] Apache 3.1.0-alpha-1
You are the release manager. My vote on respinning specifically stated that any releases in progress, the release manager can decide. If it were me I'd call it 3.1.0-beta-1 as we have had enough eyes by now that its better than alpha... I'd also be happy going straight for the 3.1.0 end game... But if you want to hold 3.1.0 as a sacred number and "fear" the respinning vote going > +3, then -beta-1 would give you breathing room. TL;DR lets get this bad boy out! On Thursday, 30 May 2013, Jason van Zyl wrote: > Ok, we're just waiting now for Stephen to summarize the vote and then when > we figure out what to call it I'll roll out the release. > > On May 30, 2013, at 2:32 PM, Hervé BOUTEMY wrote: > > > https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound > > > > page created > > improvements welcome > > > > Regards, > > > > Hervé > > > > Le jeudi 30 mai 2013 09:10:50 Arnaud Héritier a écrit : > >> Perfect. Thx > >> > >> On Thu, May 30, 2013 at 3:27 AM, Hervé BOUTEMY >wrote: > >>> MNG-5482 fixed: ok for me to go for take 4 > >>> > >>> when a plugin cannot be loaded due to missing Sonatype Aether class, > hint > >>> url > >>> will be > >>> http://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound > >>> > >>> the Wiki article still needs to be written... > >>> > >>> Regards, > >>> > >>> Hervé > >>> > >>> Le mercredi 29 mai 2013 09:34:46 Arnaud Héritier a écrit : > On Wed, May 29, 2013 at 7:39 AM, Hervé BOUTEMY > wrote: > > good idea: can you open a Jira issue? > > Done : https://jira.codehaus.org/browse/MNG-5482 > Another probably more stupid idea : Wasn't it possible to use the > shade > plugin or something like this to provide a version of aether under the > >>> > >>> old > >>> > groupId to not have such requirement in plugins upgrades ? Something > that > we'll have been able to remove in a next major release (4) > > Good news, about Aether I perhaps found an improvement in its > >>> > >>> performances > >>> > : https://gist.github.com/aheritier/5668330 > > It's interesting for me but won't be so impressive for 99,99% of > projects > where the dependency resolution time is really reduced compared to > others > tasks (compilation, tests ..) > > Bad news I also found a bug : > https://jira.codehaus.org/browse/MNG-5483 > > Cheers, > > > notice, at a first pass, improving content of > >>> > >>> > http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerExceptiont > >>> > > o > > explain the special case of Aether is easy. But I'll try to have a > > dedicated > > link tonight: I know that the code will go in DefaultExceptionHandler > > class in > > maven-core, my only hesitation actually is how to code ITs to test > the > > result: > > are there already ITs checking such error messages? > > > > Regards, > > > > Hervé > > > > Le mardi 28 mai 2013 18:31:26 Arnaud Héritier a écrit : > >> For now I had no issue with this release after an upgrade of few > >>> > >>> plugins > >>> > >> In the future (another Alpha ..) couldn't you catch such error and > > > > provide > > > >> a more user friendly message asking to upgrade the plugin : > >>> > >> [INFO] Dependency-reduced POM written at: > >>> > /Users/arnaud/Code/eXo/platform-public-distributions/plf-tomcat-extensions > >>> > > -m> > > > First, the taking in of scattered particulars under one Idea, > so that everyone understands what is being talked about ... Second, > the separation of the Idea into parts, by dividing it at the joints, > as nature directs, not breaking any limb in half as a bad carver might. > > -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) > > > > > > -- Sent from my phone
Re: [VOTE] Apache 3.1.0-alpha-1
Go for it! (Aside: not sure that we'll get that much more eyes for 3.1.0-alpha-x... I think the eyes will only hit it when we get to 3.1.0...) On Thursday, 30 May 2013, Jason van Zyl wrote: > I'm going to stick to alpha-1. No one has looked at it save 10 people > which doesn't, to me, constitute any reasonably sized population. I'll roll > it out in the morning. > > On May 30, 2013, at 4:15 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > You are the release manager. My vote on respinning specifically stated > that > > any releases in progress, the release manager can decide. > > > > If it were me I'd call it 3.1.0-beta-1 as we have had enough eyes by now > > that its better than alpha... I'd also be happy going straight for the > > 3.1.0 end game... But if you want to hold 3.1.0 as a sacred number and > > "fear" the respinning vote going > +3, then -beta-1 would give you > > breathing room. > > > > TL;DR lets get this bad boy out! > > > > On Thursday, 30 May 2013, Jason van Zyl wrote: > > > >> Ok, we're just waiting now for Stephen to summarize the vote and then > when > >> we figure out what to call it I'll roll out the release. > >> > >> On May 30, 2013, at 2:32 PM, Hervé BOUTEMY > wrote: > >> > >>> https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound > >>> > >>> page created > >>> improvements welcome > >>> > >>> Regards, > >>> > >>> Hervé > >>> > >>> Le jeudi 30 mai 2013 09:10:50 Arnaud Héritier a écrit : > >>>> Perfect. Thx > >>>> > >>>> On Thu, May 30, 2013 at 3:27 AM, Hervé BOUTEMY >>> wrote: > >>>>> MNG-5482 fixed: ok for me to go for take 4 > >>>>> > >>>>> when a plugin cannot be loaded due to missing Sonatype Aether class, > >> hint > >>>>> url > >>>>> will be > >>>>> http://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound > >>>>> > >>>>> the Wiki article still needs to be written... > >>>>> > >>>>> Regards, > >>>>> > >>>>> Hervé > >>>>> > >>>>> Le mercredi 29 mai 2013 09:34:46 Arnaud Héritier a écrit : > >>>>>> On Wed, May 29, 2013 at 7:39 AM, Hervé BOUTEMY < > herve.bout...@free.fr > >>>>>> > >>>>>> wrote: > >>>>>>> good idea: can you open a Jira issue? > >>>>>> > >>>>>> Done : https://jira.codehaus.org/browse/MNG-5482 > >>>>>> Another probably more stupid idea : Wasn't it possible to use the > >> shade > >>>>>> plugin or something like this to provide a version of aether under > the > >>>>> > >>>>> old > >>>>> > >>>>>> groupId to not have such requirement in plugins upgrades ? Something > >>>>>> that > >>>>>> we'll have been able to remove in a next major release (4) > >>>>>> > >>>>>> Good news, about Aether I perhaps found an improvement in its > >>>>> > >>>>> performances > >>>>> > >>>>>> : https://gist.github.com/aheritier/5668330 > >>>>>> > >>>>>> It's interesting for me but won't be so impressive for 99,99% of > >>>>>> projects > >>>>>> where the dependency resolution time is really reduced compared to > >>>>>> others > >>>>>> tasks (compilation, tests ..) > >>>>>> > >>>>>> Bad news I also found a bug : > >> https://jira.codehaus.org/browse/MNG-5483 > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>>> notice, at a first pass, improving content of > >>>>> > >>>>> > >> > <http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerExceptiont> > Thanks, > > Jason > > -- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > To do two things at once is to do neither. > > -- Publilius Syrus, Roman slave, first century B.C. > > > > > > -- Sent from my phone
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
On 31 May 2013 10:22, James Nord (jnord) wrote: > > This discussion about respins is really strange to me. I've been cutting > > releases, with Maven, at Apache, for years now. And all of them have > reused > > version numbers for respins. And all of them have carefully used staging > > technology (old: directories, new: Nexus) to ensure that artifacts don't > > escape to the wild until they pass the vote. > > But they have to be in the wild in order to test (especially plugins). > > This adds a barrier to test for external people in a corporate > environment, and can cause mishaps if one library delivered with a plugin > is not cleaned up correctly from a MRM, causing the old failed version to > be served up to clients. > > Basically IMHO reusing version numbers violates maven rule #1 releases > never change. > > Personally I wouldn’t care if 3.3.0 is called 3.3.0-7 or 3.3.0-24 so long > as it is the official "3.3.0". > > After all isn’t this what the buildnumber is for? > > +1 no reusing version numbers (non binding) (but I am against skipping > x.y.z versions - e.g. there should not be a gap from 3.2.12 to 3.3.6 ) > Can you please explain that last bit? If there is an API change (backwards compatible) that necessitates the next version after 3.2.12 have a minor version incremented and then it turns out that it takes another 7 tries to get a viable release out the door then that means that the released versions you would see (with no re-using) would be 3.2.12 and then 3.3.6. If you allow for reusing, you would get 3.2.12 followed by 3.3.0... perhaps you could explain what you are exactly against and how such a situation could arrise? > > /James >
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
On 31 May 2013 10:41, James Nord (jnord) wrote: > > -Original Message- > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > > Sent: 31 May 2013 10:29 > > To: Maven Developers List > > Subject: Re: [VOTE] Should we respin CANCELLED releases with the same > > version number? > > > > On 31 May 2013 10:22, James Nord (jnord) wrote: > > > > > > This discussion about respins is really strange to me. I've been > > > > cutting releases, with Maven, at Apache, for years now. And all of > > > > them have > > > reused > > > > version numbers for respins. And all of them have carefully used > > > > staging technology (old: directories, new: Nexus) to ensure that > > > > artifacts don't escape to the wild until they pass the vote. > > > > > > But they have to be in the wild in order to test (especially plugins). > > > > > > This adds a barrier to test for external people in a corporate > > > environment, and can cause mishaps if one library delivered with a > > > plugin is not cleaned up correctly from a MRM, causing the old failed > > > version to be served up to clients. > > > > > > Basically IMHO reusing version numbers violates maven rule #1 releases > > > never change. > > > > > > Personally I wouldn't care if 3.3.0 is called 3.3.0-7 or 3.3.0-24 so > > > long as it is the official "3.3.0". > > > > > > After all isn't this what the buildnumber is for? > > > > > > +1 no reusing version numbers (non binding) (but I am against > > > +skipping > > > x.y.z versions - e.g. there should not be a gap from 3.2.12 to 3.3.6 ) > > > > > > > Can you please explain that last bit? > > > > If there is an API change (backwards compatible) that necessitates the > next > > version after 3.2.12 have a minor version incremented and then it turns > out > > that it takes another 7 tries to get a viable release out the door then > that > > means that the released versions you would see (with no re-using) would > be > > 3.2.12 and then 3.3.6. If you allow for reusing, you would get > > 3.2.12 followed by 3.3.0... perhaps you could explain what you are > exactly > > against and how such a situation could arrise? > > > So what I am for is the following (example) (which does not re-use version > numbers): > > So we have 3.2.12 (released as you currently do). > New breaking API is encountered > So you up the minor version - and create a "RC" release > That version is 3.3.0-1 (the buildnumber is important) > That fails due to some license not being present, so you release the next > version > 3.3.0-2 > ... > 3.3.0-3 > ... > 3.3.0-7 > This passes the vote and the announce about apache maven 3.3.0 available > for download goes onto the website and links to 3.3.0-7 > After release some bugs are found, > Next version is 3.3.1-nnn > > > What I am against is the following (which **also** does not re-use version > numbers): > So we have 3.2.12 (released as you currently do). > New breaking API is encountered > So you up the minor version - and create a "RC" release > That version is 3.3.0 > That fails due to some license not being present, so you release the next > version > 3.3.1 > ... > 3.3.3 > ... > 3.3.7 > This passes the vote and the announce about apache maven 3.3.7 available > for download goes onto the website (but there is no mention of 3.3.6 or any > other prior 3.3.x) > > So I would not want to see (in "released version") 3.2.12 -> 3.3.7 -> > 3.3.16 -> 3.4.7 > > FYI, Tomcat goes with the skipping, e.g. http://archive.apache.org/dist/tomcat/tomcat-7/ where the first non-beta 7.0.x is 7.0.6 and I don't see a 2.4.0 for HTTPD http://archive.apache.org/dist/httpd/ So some of the 'older' Apache projects are just fine skipping version numbers. I personally don't see what is so offensive about 3.3.7 over 3.3.0-7. I think you are just as likely to have somebody moan about where were 3.3.0-1 through 3.3.0-6 as they would moan about where are 3.3.0 through 3.3.6... and the answer would be the exact same... those were not good enough... so they were not released. The practical reality is that we should never get that far... assuming we have enough eyes looking at releases. Yes 3.1.0-alpha-1 has had/will have at least four respins... primarily because the volunteers have been slow stepping up and testing... Part of the issue from my PoV with stepping up and testing is that version number reuse can lead to worry that
Re: [VOTE] Apache 3.1.0-alpha-1
On 31 May 2013 12:01, jieryn wrote: > Greetings, > > On Fri, May 31, 2013 at 1:34 AM, Hervé BOUTEMY > wrote: > > I don't know what you mean by "send pull requests to Jenkins", if you're > > talking about Apache's Jenkins instance or something more general from > the > > Jenkins project > > There is something called the backend-crawler which locates common > tools that can be auto-installed by the Jenkins service itself. All > Jenkins instances will load a JSON file, similar to the way it knows > which plugins can be auto-installed. I meant we should perhaps send a > pull request here: > > https://github.com/jenkinsci/backend-crawler/blob/master/ant_maven.groovy > > More information here: > > https://wiki.jenkins-ci.org/display/JENKINS/Adding+tool+auto-installer > https://wiki.jenkins-ci.org/display/JENKINS/Tool+Auto-Installation > > > but I'm interested by the "it would be auto-installable" objective at > least on > > Apache's Jenkins instance > > Yep, that or someone with karma can just manually install it and > enable it as the default builder? That way it won't break any builds > which require a specific Apache Maven. But the auto-installable route > would enable more places to just quickly enable it.. I'm not sure if > Jenkins folks would be receptive to having an Apache Maven pre-release > kind of thing showing up in their tool list, but off the top of my > head I can not find a reasonable objection. > > Wearing my Jenkins hat, I would not be happy with pre-release bits showing up unless they had a clear (pre-release) tag, and I don't think there is an easy way to uninstall tools from the build slaves... But I think it would be a good topic to bring up at the next Jenkins Board meeting (not that I ever attend those due to TZ issues) Note: Given KKs view of how bad an idea reusing version numbers is, I suspect that KK would be against the pre-release as long as we allow respinning with the same version number... but there is no harm in asking the question -Stephen > -Jesse > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
I will need to recheck the tally, but I think the result is -3 So looks like we will be reusing version numbers on respins On Wednesday, 29 May 2013, Stephen Connolly wrote: > We have been using a policy of only making releases without skipping > version numbers, e.g. > > 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc > > Whereby if there is something wrong with the artifacts staged for release, > we drop the staging repo, delete the tag, roll back the version, and run > again. > > This vote is to change the policy to: > > drop the staging repo, document the release as not released, and run with > the next version. > > Under this new proposal, if the staged artifacts for 3.1.0 fail to meet > the release criteria, then the artifacts would be dropped from the staging > repository and never see the light of day. The tag would remain in SCM, and > we would document (somewhere) that the release was cancelled. The "respin" > would have version number 3.1.1 and there would never be a 3.1.0. > > This change could mean that the first actual release of 3.1.x might end up > being 3.1.67 (though I personally view that as unlikely, and in the context > of 3.1.x I think we are very nearly there) > > Please Note: > http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes > not actually specify what it means by "the process will need to be > restarted" so this vote will effect a change either outcome > > +1: Never respin with the same version number, always increment the > version for a respin > 0: Don't care > -1: Always respin with the same version number until that version number > gets released > > This vote will be open for 72 hours. A Majority of PMC votes greater that > 3 will be deemed as decisive in either direction (i.e. if the sum is < -3 > or > +3 then there is a documented result) > > For any releases in progress at this point in time, it is up to the > release manager to decide what to do if they need to do a respin. > > -Stephen > -- Sent from my phone
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
I will point out that for this specific vote I listed three options and a criteria. So this vote has no vetoes. Simple sum of all binding votes defines the result. If the sum is < -3 then that says majority dont want to burn version numbers. If the sum > +3 then that says the majority want to keep release version number labels as immutable and therefore burn version numbers with each cancelled vote. After 72h the total, by my count was -3 and has only gone further in that direction. I think the reuse of version numbers has one this vote. If Hervé wants to call a second vote for burning qualified version labels, fine by me but my view is do for all releases the same On Sunday, 2 June 2013, Fred Cooke wrote: > I apologise. I had three tabs open from Apache, and grabbed the wrong one. > > According to the correct, page, though: > > -0.9: 'I *really* don't like this, but *I'm not going to stand in the > way*if everyone else wants to go ahead with it.' > > There's an *implication* there that an extra -0.1 might change that to I > *am > * going to stand in the way. There's also a disclaimer in the intro that > says "might be interpreted" and a "TBS" (To Be Specified?) in the > procedures section. > > I believe I've seen Mojo release votes (not code mod votes) vetoed, and > they (we? ugh) claim to use the same rules. Correct me if I'm wrong > (again). > > So, Apache elders, what IS the procedure voting ruleset, and who's going to > update that page so that it's clear? > > Fred. > > On Sun, Jun 2, 2013 at 9:11 PM, Benson Margulies > > >wrote: > > > Thanks, Baptiste, that's the reference I was looking for. > > > > > > On Sun, Jun 2, 2013 at 3:08 PM, Baptiste MATHUS > > wrote: > > > That link is for HTTPd. > > > For Apache general guidelines, read > > > http://www.apache.org/foundation/voting.html > > > -1 are only vetos for "code modification", not "procedural" issues . > > > > > > Cheers > > > > > > > > > 2013/6/2 Fred Cooke > > > > > >> Benson, read the rules: > > >> > > >> http://httpd.apache.org/dev/voting.html > > >> > > >> "*-1 *No, I *veto* this action." > > >> > > >> +1 + -1 != 0 > > >> > > >> On Sun, Jun 2, 2013 at 8:55 PM, Benson Margulies < > bimargul...@gmail.com > > >> >wrote: > > >> > > >> > On Sun, Jun 2, 2013 at 2:42 PM, Fred Cooke > > wrote: > > >> > >> from my experience, even if this question is not absolutely > > >> > scm-specific, > > >> > >> git > > >> > >> brings us a new problem we didn't have with svn: once a tag is > set > > on > > >> > the > > >> > >> canonical repo and replicated on developers' repos, it is not > > >> > automatically > > >> > >> updated if updated in the canonical > > >> > >> > > >> > > > > >> > > Git brings you no such "problem", it simply exposes your extremely > > poor > > >> > > practices... A tag should, and in any sane place is, permanent and > > >> > > irrevocable. > > >> > > > > >> > > On another note, the veto by -1 vote mechanism is a great idea > for a > > >> > > release, but a terrible idea for a principle like this. For a > > release > > >> it > > >> > > requires a justification, for this it's just "my opinion" > overriding > > >> one > > >> > of > > >> > > Maven's core principals. > > >> > > > >> > > > >> > Fred, > > >> > > > >> > Who says that anyone has a veto? As a principle of Apache, very few > > >> > things are subject to veto, and I can't see how this would be one. > If > > >> > there's a clear majority of opinion in favor of burning versions, > > >> > we'll start burning versions. I voted -1. I'll live with whatever > > >> > outcome, but I'd live more happily with a more elaborated > description > > >> > of the resulting procedure. Like, where and how do we document these > > >> > never-born releases, etc, etc. > > >> > > > >> > --benson > > >> > > > >> > > > >> > > > > >> > > Stagnation wins. > > >> > > > > >> > > Fred. > > >> > > > > >> > > > > >> > >> > > >> > >> but I may miss some git-fu once again... > > >> > >> > > >> > >> Regards, > > >> > >> > > >> > >> Hervé > > >> > >> > > >> > >> Le samedi 1 juin 2013 20:47:36 Chris Graham a écrit : > > >> > >> > >but as I see, there seems to be a consensus around a 2-sided > > rule: > > >> > >> > >- don't reuse version number for pre-releases (RC, etc) > > >> > >> > >- reuse version number for actual releases > > >> > >> > > > >> > >> > Not sure how I feel about that. > > >> > >> > > > >> > >> > alpha/beta/RCx etc, they are all still valid version nos, so I > > think > > >> > that > > >> > >> > the no re-spin rule should still apply in the same manner. > > >> > >> > > > > -- Sent from my phone
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
Now the issue with componentX-1.4 that you wan to test is one that only shows up behind your corporate proxy, and you have a system set up with the failing case and you dare not change anything... So you add the staging repo to your mirror, run the test case, and drop the test artifact from the mirror as fast as you can... (Because creating a separate mirror would require changing the test setup and resulting in re-resolution again) The thing is that the test is a long test... And now you don't know who else has got that invalid componentX-1.4 (because your test is still failing) and when the fixed componentX-1.4 is released you may find a nightmare tracking it down again. Somewhat contrived some might say, but that is the use case where this s more critical On Monday, 3 June 2013, Robert Scholte wrote: > All nice ideas, but let's go back to a real usecase: > > Let's assume we're having an issue with componentX-1.4 > If you weren't one of the testers, then this dependency was pulled from > Maven Central. You can check out the code as specified in the tag, etc. > etc. No issues here. > But if you were one of the testers you must be sure that you're not using > the staged version anymore, but the one from Maven Central. When reusing > version numbers due to unsuccessful staged versions, you can only confirm > it by comparing the *revisions* of both componentX-1.4 > I think somehow (the rootcause of) MNG-5181 is related: if you're using an > artifact originally from a staging repo and that repo has disappeared, the > build must fail. You are forced to clean up these staged artifacts, so they > are pulled from Maven Central. Only this way your local build is the same > as any other developers build. > As said before: - the actual release is the one in the dist-folder > - tags are just an easy way to refer to a certain revision. > - so if you want to be 100% sure you're checking out the correct source, > use revisions and not tags (which means revision must be set during > packaging, e.g in the manifest file). > > Robert > > Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies < > bimargul...@gmail.com>: > > I would consider it delux if the release plugin were enhanced to >> support a more sophisticated mapping between artifact versions and >> tags -- as per Kristian, wouldn't it be cool if it could iterate over >> tags while repeating itself on customer-visible release numbers? I'd >> help to code this is we had a collective understanding of how we >> wanted it to work. >> >> --**--**- >> 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 > > -- Sent from my phone
Re: [VOTE] Should we respin CANCELLED releases with the same version number?
On Monday, 3 June 2013, Kristian Rosenvold wrote: > If you add apache staging to your corp proxy > and expose that to everyone you are mixing test and production. > /me dislikes the concept. > > The way I usually solve this is to have an additional > corp repo-url that exposes the regular internal repo > *and* staging. This url is used to test staging. The *point* is what happens when your test case machine is pointing to the proxy. If you switch that to a different URL _maven.repositories will kick in and re-resolve potentially breaking your test case. The only way I can see out of such is to edit the test machine's hosts file so that the DNs name gets resolved to a different server and that assumes the proxy is referenced by DNS and not eg https:/ 10.0.0.5/nexus/groups/public/ I did say this is likely a rare case, but it is the case that would force burning version numbers, and the exception tests (or proves in old English) the rule (Anyway vote is over, so issue is moot. I don't care enough to call a second vote) > (I have yet to come across a scenaro where multiple > users share this ;) > > Kristian > > > 2013/6/3 Stephen Connolly > >: > > Now the issue with componentX-1.4 that you wan to test is one that only > > shows up behind your corporate proxy, and you have a system set up with > the > > failing case and you dare not change anything... > > > > So you add the staging repo to your mirror, run the test case, and drop > the > > test artifact from the mirror as fast as you can... (Because creating a > > separate mirror would require changing the test setup and resulting in > > re-resolution again) > > > > The thing is that the test is a long test... And now you don't know who > > else has got that invalid componentX-1.4 (because your test is still > > failing) and when the fixed componentX-1.4 is released you may find a > > nightmare tracking it down again. > > > > Somewhat contrived some might say, but that is the use case where this s > > more critical > > > > On Monday, 3 June 2013, Robert Scholte wrote: > > > >> All nice ideas, but let's go back to a real usecase: > >> > >> Let's assume we're having an issue with componentX-1.4 > >> If you weren't one of the testers, then this dependency was pulled from > >> Maven Central. You can check out the code as specified in the tag, etc. > >> etc. No issues here. > >> But if you were one of the testers you must be sure that you're not > using > >> the staged version anymore, but the one from Maven Central. When reusing > >> version numbers due to unsuccessful staged versions, you can only > confirm > >> it by comparing the *revisions* of both componentX-1.4 > >> I think somehow (the rootcause of) MNG-5181 is related: if you're using > an > >> artifact originally from a staging repo and that repo has disappeared, > the > >> build must fail. You are forced to clean up these staged artifacts, so > they > >> are pulled from Maven Central. Only this way your local build is the > same > >> as any other developers build. > >> As said before: - the actual release is the one in the dist-folder > >> - tags are just an easy way to refer to a certain revision. > >> - so if you want to be 100% sure you're checking out the correct source, > >> use revisions and not tags (which means revision must be set during > >> packaging, e.g in the manifest file). > >> > >> Robert > >> > >> Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies < > >> bimargul...@gmail.com >: > >> > >> I would consider it delux if the release plugin were enhanced to > >>> support a more sophisticated mapping between artifact versions and > >>> tags -- as per Kristian, wouldn't it be cool if it could iterate over > >>> tags while repeating itself on customer-visible release numbers? I'd > >>> help to code this is we had a collective understanding of how we > >>> wanted it to work. > >>> > >>> > --**--**- > >>> 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 > >> > >> > > > > -- > > Sent from my phone > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: [VOTE] Apache 3.1.0-alpha-1 (Take 4)
+1 (binding) On 1 June 2013 14:13, Jason van Zyl wrote: > Here are the release bits for 3.1.0-alpha-1: > > Release notes: > > https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967 > > Staging repository: > https://repository.apache.org/content/repositories/maven-046/ > > Staged distribution: > > https://repository.apache.org/content/repositories/maven-046/org/apache/maven/apache-maven/3.1.0-alpha-1/ > > Staged Site: > http://maven.apache.org/ref/3.1.0-alpha-1 > > Thanks, > > Jason > > -- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > First, the taking in of scattered particulars under one Idea, > so that everyone understands what is being talked about ... Second, > the separation of the Idea into parts, by dividing it at the joints, > as nature directs, not breaking any limb in half as a bad carver might. > > -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) > > > > > >
Re: [VOTE] Release Maven Surefire Plugin version 2.15
On Friday, 7 June 2013, Andreas Gudian wrote: > Hi, > > This is my first release, so please check carefully what I may have missed > :). > > We solved 16 issues: > > https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&version=19174 > > This is the first release that does not support JVM versions prior 1.5 to > be forked. I thought the plan was to bump the major version for this change? > > There are still lots of issues left in JIRA: > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&mode=hide&jqlQuery=project+%3D+SUREFIRE+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-075 > > https://repository.apache.org/content/repositories/maven-075/org/apache/maven/plugins/maven-surefire-plugin/2.15/maven-surefire-plugin-2.15-sources.jar > > https://repository.apache.org/content/repositories/maven-075/org/apache/maven/plugins/maven-failsafe-plugin/2.15/maven-failsafe-plugin-2.15-sources.jar > Source: https://git-wip-us.apache.org/repos/asf/maven-surefire.git tag > surefire-2.15 > > Staging site: > > http://maven.apache.org/surefire-archives/maven-surefire-2.15/maven-surefire-plugin/index.html > > http://maven.apache.org/surefire-archives/maven-surefire-2.15/maven-failsafe-plugin/index.html > > http://maven.apache.org/surefire-archives/maven-surefire-2.15/maven-surefire-report-plugin/index.html > > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > -- Sent from my phone
Re: Fwd: Maven plugin trademarks [Re: Downloading a file for shipping in an artifact]
relocation pom will not work for plugins... (we maybe should look into that though) Simplest is just to move to the new ID and tell your users to change... that's what jetty did On 18 June 2013 16:00, Christian Schulte wrote: > >> Perhaps we are at the point where we should start breaking builds rather > >> than just giving a stern warning... certainly the warning has been there > >> for long enough > > MNG-3762 > > Say there is a maven-whatever-plugin available in central which needs to > be renamed to whatever-maven-plugin. Is there a best-practice or guide > describing how to rename a plugin's artifact id ? Deploy a relocation > POM or do not ? > > -- > Christian > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Fwd: Maven plugin trademarks [Re: Downloading a file for shipping in an artifact]
Maven Plugin Plugin already gives a big friendly warning... Once we get the wording on the website right, we will "flip the switch" and break people's builds if they are bold... On 18 June 2013 17:06, Lennart Jörelid wrote: > Well ... documentation is good, but enforcement and a friendly but clearly > phrased error message containing: > > >1. What is wrong with the current naming, >2. What should be done to correct the problems, and >3. A reference to further reading on the topic (for example *why* >something is enforced) > > ... is even better, in that it works. That is the only functional way in a > large organisation, and I believe the maven community can be perceived as > such. > > > > 2013/6/18 Christian Schulte > > > Am 06/18/13 17:32, schrieb Stephen Connolly: > > > relocation pom will not work for plugins... (we maybe should look into > > that > > > though) > > > > > > Simplest is just to move to the new ID and tell your users to change... > > > that's what jetty did > > > > Ok. Thanks for clarifying. > > > > -- > > Christian > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > -- > > -- > +==+ > | Bästa hälsningar, > | [sw. "Best regards"] > | > | Lennart Jörelid > | EAI Architect & Integrator > | > | jGuru Europe AB > | Mölnlycke - Kista > | > | Email: l...@jguru.se > | URL: www.jguru.se > | Phone > | (skype):jgurueurope > | (intl): +46 708 507 603 > | (domestic): 0708 - 507 603 > +==+ >
Re: Download links for source packages - where are they?
On Wednesday, 26 June 2013, Barrie Treloar wrote: > On 26 June 2013 18:44, sebb > wrote: > > Howewer the ASF releases source. > > If you don't provide a download link to the source how are users > > supposed to find it? > > > > I agree that most people are not going to want to download the original > source. > > But that does not mean it should be left unlinked. > > We provide all that for Maven core - the bit the users care about and run. > > Plugins are download by Maven. > Few, if any, user is going to download a source distribution of a > plugin and built it themselves. > If they are going to do that, then they are likely to want to work on > Jira issues or provide a patch and it makes much more sense to work > with source control. > And we have prominent links to the source control repositories, > including the tags. I do not think it would be a major harm to add a reporting plugin to generate the dist download link for source bundles... As it can only add... I agree that there is no *requirement* for us to provide the download link... But there are things we can improve. Until recently, it was not clear to us that the source bundles had to be copied into the dist directory... Someone at infra wrote an audit script and we copied all the missing bundles over for plugins (they were on repository.apache.org so it is not that we hadn't generated them) I think we should turn on rat for all plugins, not just core... I will look into this next week if nobody else has... Most likely I will turn on rat without strong enforcement just yet, and then turn on zero tollerance in a month or so to give people the chance to fix rat issues and get out any emergency releases that might be required (eg if there is a CVE requiring a plugin release, you don't want that blocked while we review the integration test data that may or may not require an ASF license header for the test to be valid, and I'd rather have a valid set of exclusions rather than a "lets just get the build passing to make this release" approach which can get forgotten to unwind after) > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: Release process updates
On Friday, 28 June 2013, Fred Cooke wrote: > For git the unique hash is sufficient, you don't really need the tag at > all, they simply point to the unique hash (or another tag, in a chain). If > Git was the SCM of choice, I'd use RCX tags, and then not retag for final, > but rather point the final tag AT the last, accepted RC tag. > > For example > > artifact-RC1 >> 1234567890ABCDE > artifact-RC2 >> ABCDE1234567890 > artifact-RC3 >> 12345ABCDE67890 > artifact >> artifact-RC3 (yes this is possible! and is correctly resolved > to the hash pointed to by the final chain-link) And how exactly do we bake the hash into the Pom? We need to know what we are baking into the Pom *before* we can commit the Pom So in the GIT world, we need to bake a tag into the Pom as we cannot predict the hash. In the Subversion world, we need to bake a tag without revision into the Pom as we cannot predict the revision we will get when we do commit. I am fine with saying for GIT *votes* the hash of the tag should be included in the vote email, but pushing the tag at the time of the vote I see as a bad plan (unless we decide to change the tag naming convention) Subversion does not let us avoid committing the tag, so in that case I am fine with saying in the vote email tag@1234342 But I don't see (given the way the version numbering vote went) why we need to do anything other than the above 1 small change to the vote emails And keep in mind that given that SCM is just a convenience, even that is not strictly necessary... It is the -src.tar.gz that we are voting on... Everything else is just a convenience > > If I were forced (at gun point) to use SVN again, I'd not create real > SVN-tags, I'd modify my tooling to either add SVN meta data linking name > and revision number and path or do the same in a plain text file(s) > somewhere in the repo. The entire SVN cp thing leaves me feeling ill. SVN > mv makes me want to cry like a girl. From the help info: > > Note: this subcommand is equivalent to a 'copy' and 'delete'. > > > > If only file systems were this good! :-p > > In terms of current SVN usage, the "SVN mv" command is probably a good > choice, as already discussed. You could argue that a "cp" would be better, > but this creates wholesale duplication, which is never good. > > Fred. > > On Fri, Jun 28, 2013 at 12:35 PM, sebb wrote: > > > The re-use of tags is a side-issue to this thread, though I'm glad to > > see some support for using immutable tags, whatever route is chosen > > Please start a new thread to continue that discussion. > > > > The vote e-mail must have the revision and tag name/trunk URL in it > > else it is not complete. > > > > Just as Maven insists on GAV - where V=version - a unique SVN > > coordinate requires the revision and the tree segment selector (e.g. > > tag). > > I don't know what Git needs - I suppose it may depend on whether > > multiple components are part of the same Git instance. > > > > But whatever - as it stands, the current vote e-mail is > > **incomplete**; it does not provide sufficient information for the > > candidate to be properly evaluated. > > The information needs to be present both for current and historical use. > > > > On 28 June 2013 10:09, Arnaud Héritier wrote: > > > +1 to change our tags convention if it solves this issue by avoiding to > > > reuse tag names to give a better visibility from where a release was > done > > > > > > > > > On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold < > > > kristian.rosenv...@gmail.com> wrote: > > > > > >> This suggestion is much like what we came up with the last time > > >> we discussed this - about 3 weeks ago. > > >> > > >> This behaviour is simple to achieve without a single line > > >> of change; the release plugin already asks for a SCM tag name > > >> distinct from the version number. (we *could* add some kind > > >> of support for an explicit convention, we could even add a scm-lookup > > >> to auto-roll forward on subsequent takes). > > >> > > >> Now I've been trying to think if there's a sensible convention > > >> that could be established that would allow us to > > >> simply *keep* the tag name of the accepted version > > >> without re-pushing another tag after release (and, since the tag > > >> name can be etched into the pom of the released artifact, there > > >> should be no real reason for confusion). > > >> > > >> I've been thinking about a *tagging* convention along the lines > > >> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2, > > >> maven-xx-plugin-2.3.2#3..." > > >> > > >> Effectively we would delete #1 and #2 and keep the #3 tag, since this > > >> vote passed on take 3. > > >> > > >> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the > > >> released 2.3.2 version. > > >> > > >> This is mostly a policy change on tag naming, we could implement this > > >> without a line > > >> of code change. Since both svn and git essentially have flawed tag > > >> handling it makes sense to do
Re: [VOTE] Release Maven Enforcer version 1.3 (take 2)
On Sunday, 30 June 2013, sebb wrote: > On 29 June 2013 11:47, Robert Scholte > > wrote: > > Hi Sebb, > > > > none of these files will end up in Maven Central, they are all used for > > tests. > > However, they do end up in the source release which is published via > the ASF mirrors. > It's vital that all released source files have the appropriate header. Not true, for example where a source file is in a format that does not support comments or where the source file is data for a test case and the presence of a comment breaks the test case... Thus there is no requirement for *all* files to contain the license, and hence the LICENSE file is required to be sufficient as the effective license for all files unless the file indicates otherwise... Now it is best practice that we put the license on as many files as possible, but the straw-man example proves that the license is not *required* on all files, just *recommended* on as many as possible. Where some of the code comes under different licenses in the one code base, then is is required that we provide some indication as to which files are covered by which licenses. That is easiest to achieve by having license headers, but it is not required to be such. -Stephen > > For me that's not enough reason to cancel the vote. > > > > thanks, > > > > Robert > > > > Op Thu, 27 Jun 2013 12:26:03 +0200 schreef sebb : > > > > > >> On 25 June 2013 21:23, Robert Scholte wrote: > >>> > >>> Hi, > >>> > >>> We solved 15 issues: > >>> > >>> > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=19011 > >>> > >>> There are still a couple of issues left in JIRA: > >>> > >>> > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11530&status=1 > >>> > >>> Staging repo: > >>> https://repository.apache.org/content/repositories/maven-070/ > >>> > >>> > https://repository.apache.org/content/repositories/maven-070/org/apache/maven/enforcer/enforcer/1.3/enforcer-1.3-source-release.zip > >>> > >>> Staging site: > >>> http://maven.apache.org/enforcer-archives/enforcer-LATEST/ > >>> > >>> Guide to testing staged releases: > >>> http://maven.apache.org/guides/development/guide-testing-releases.html > >>> > >>> Vote open for 72 hours. > >>> > >>> [ ] +1 > >>> [ ] +0 > >>> [X] -1 > >> > >> > >> There are lots of files in the source archive that don't have AL > headers: > >> > >> enforcer-1.3/DEPENDENCIES > >> enforcer-1.3/enforcer-api/src/custom-rule-sample/pom.xml > >> > >> > enforcer-1.3/enforcer-api/src/custom-rule-sample/src/main/java/org/apache/maven/enforcer/rule/MyCustomRule.java > >> enforcer-1.3/enforcer-api/src/custom-rule-sample/src/usage-pom.xml > >> enforcer-1.3/enforcer-api/src/custom-rule-sample/usage-pom.xml > >> enforcer-1.3/enforcer-api/src/main/assembly/custom-rule-sample.xml > >> > >> > enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/no-repositories/child/pom.xml > >> > >> > enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/no-repositories/pom.xml > >> > >> > enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-plugin-repositories/child/pom.xml > >> > >> > enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-plugin-repositories/pom.xml > >> > >> > enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-repositories/child/pom.xml > >> > >> > enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-repositories/pom.xml > >> > >> > enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-plugin-repositories/child/pom.xml > >> > >> > enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-plugin-repositories/pom.xml > >> > >> > enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-repositories/child/pom.xml > >> > >> > enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-repositories/pom.xml > >> > >> > enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/checkPluginPropertyVersion/pom.xml > >> > >> > enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/checkPluginVersionProfile/pom.xml > >> > >> enforcer-1.3/enforcer-rules/src/test/resourc -- Sent from my phone
Re: Unique Git coordinates (was: Release process updates (try 2))
On Sunday, 30 June 2013, sebb wrote: > On 30 June 2013 21:56, Fred Cooke > > wrote: > >> > >> OK, so what is the Git command to download a copy of the sources that > >> > > are part of the hash? > >> > > > > git checkout > > Does not work for me. Until I hear otherwise, the reviewers for whom this is critical (ie the PMC) have enough context to figure out which repo the vote refers to. (Or they just look it up from the Pom in the source bundle) Now I am not saying that it is ideal, and given how easy it is to provide the details, I don't think it shoud be avoided, but when reviewing policy and procedure it is necessary to get to the root requirements so that the changed procedure (if it gets changed) is not doing things fr the sake of doing them... The fable of the fve chimpanzees and the ladder and the bunch of bananas is always relevant when reviewing procedures (every time a chip tries to climb the ladder, power-hose them all until it stops... Eventually no chimp will try to climb... Then start swapping out chimps one at a time Then stop hosing and end up with a room full of chimps who will beat the crap out f any chimp that tries to climb the ladder but they don't know *why*) > I get the following error message: > > fatal: Not a git repository (or any of the parent directories): .git > > This suggests that Git does not know where to download the hash from. > > > Then observe the tree. You can also export an archive, though I don't > > recall the exact command off the top of my hand. > > > > > >> Don't I need to know something about the Git repo it comes from? > >> > > > > Yes, the URL which would be pre-agreed. Providing it would be a nice > > convenience, but nothing more. > > Again I disagree; the reviewer should have the specific information > they need without having to look elsewhere. > And likewise it should be in the e-mail thread for historical purposes. > > > > >> Or are Git hashes guaranteed to be universally unique? > >> > > > > Nothing is, however within the realms of SHA1 collisions, sure. The > chances > > of finding a second repo for *any* other piece of software that contains > > the identical hash is pretty low. The chances of finding the same hash > in a > > single Git repo is impractically low. I can't see how that is handled, > but > > the obvious way would be to just respin the commit so the date meta data > > changed and the hash changed. In any case, if that's a flaw, it's a flaw > of > > Git, and can't be avoided. In practice, it's not a flaw at all. > > > >> It's just sloppy not to do this; if a quality release process is > required, > >> > so is the SVN rev number. If "good enough" is OK, then it can be > omitted > >> > because you can, most of the time, just guess. Guessing = mistakes, > >> though. > >> > >> Sorry, I have to disagree there; the source reference cannot be > >> omitted under any circumstances because it's not possible to review > >> the source release without a reference to the files in SCM. There's no > >> way to determine provenance otherwise. > >> > > > > I was trying to be nice with "sloppy" or perhaps sarcastic. It's totally > > unacceptable to me, however it seems like some people here think it's > OK. I > > can see their point of view, however it's too easy to do it right to > > justify not doing it right. I agree with you, completely. > > > > Fred. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: Release process updates (try 2)
On Monday, 1 July 2013, Baptiste MATHUS wrote: > Guys, even if not convinced this is really useful, > I suppose voting template could just be adjusted so that the sha1 > or svn revision be added in the VOTE thread, and then get back to code as > usual? +1 > > As it is just a 5 seconds additional operation to be done by the RM, I > think this is acceptable if this helps close this thread isn't it? > > My 2 cents. > > Cheers > > > 2013/7/1 Fred Cooke > > > > Deleting and recreating a Git tag once published is an *extremely* stupid > > thing to do, at least an order of magnitude more so than the same action > in > > SVN. I sincerely hope that developers in this community would not engage > > in such activities. > > > > Nevertheless, this thread isn't about that, it's about providing a > specific > > and reliable way to know what we're supposed to be looking at. It's > about a > > line or two in an email, nothing more. If that is too much to ask, then > > something is seriously wrong here. > > > > On Mon, Jul 1, 2013 at 3:46 PM, Daniel Kulp > > wrote: > > > > > > > > +1 - I agree with Chris. > > > > > > Besides, if something DOES change in the svn/git tag, we get an email > > > notification so we can immediately figure out what's going on. In > > > addition, if you compare what you are voting on to whatever is the > latest > > > version of the the tag, if there is any difference whatsoever in the > > code, > > > the reviewer should immediately figure out why.I really don't care > > > about the exact revision number at all. Whatever is the latest "tag" > > > (head/whatever) is what's important as that's what will be held there > > > forever once the vote passes. > > > > > > Dan > > > > > > > > > On Jul 1, 2013, at 2:18 AM, Chris Graham > > > > > wrote: > > > > On Mon, Jul 1, 2013 at 4:20 AM, sebb > > wrote: > > > > Reminder: all this thread is just about is adding the following lines > > > >> to vote e-mails: > > > >> > > > >> SVN Tag: > > > >> > > > >> > > > > > > https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/ > > > >> (r1496317< > > > > > > https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/(r1496317 > > > > > > > >> ) > > > >> > > > >> > > > > I still find this redundant. Given that the tag will not change for > the > > > > time window of the vote, and that the tag has it's own revision no, > and > > > you > > > > can derive the revision from the tag, so I see no need to quote the > > > > revision no. > > > > > > > > In the event of a failed vote, the version/tag will be reused and it > > will > > > > have a new revision, which also will be derivable. > > > > > > > > In the event of a successful vote, the tag will remain permanently. > > > > > > > > Should anyone ever wish to trawl through the (svn) history, then you > > will > > > > still be able to see the intermediate/failed votes and history. And > > you'd > > > > also need the archives of this list to address why the vote failed > etc. > > > > > > > > or whatever the equivalent is for Git (or any other SCM that may be > in > > > >> use at the time). > > > >> > > > >> Yes, others wil have their own requirements. > > > > > > -- > > > 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 > > > > > > > > > > > > -- > Baptiste MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! > -- Sent from my phone
Re: svn commit: r1498969 - /maven/site/trunk/content/markdown/project-roles.md
Anyone who has suggestions for improvements or additional content, please shout out or commit your changes... The aim is to let people understand the different roles and responsibilities in the Maven community On 2 July 2013 16:13, wrote: > Author: stephenc > Date: Tue Jul 2 15:13:59 2013 > New Revision: 1498969 > > URL: http://svn.apache.org/r1498969 > Log: > This is only a draft... and there is still a lot of review needed > > Added: > maven/site/trunk/content/markdown/project-roles.md > > Added: maven/site/trunk/content/markdown/project-roles.md > URL: > http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1498969&view=auto > > == > --- maven/site/trunk/content/markdown/project-roles.md (added) > +++ maven/site/trunk/content/markdown/project-roles.md Tue Jul 2 > 15:13:59 2013 > @@ -0,0 +1,194 @@ > + > +# Apache Maven Project Roles > + > +The Apache Maven project is not just the software it produces. > +The Apache Foundation has a phrase: “Community over code†which > +is about how it is the community that grows around a project > +that is the most important thing. > + > +Everyone reading this is part of the Apache Maven community, > +and even if you are an invisible part of the Apache Maven > +community you are still part of the community. > + > +There are many ways we can sort the people in our > +community, we present the following as one such way. > +Please do not take offence if you disagree with this > +categorisation. It is important to remember that we are > +a *community* not a *clique* so you are entitled to disagree > +with others in the community. (Note that the right to disagree > +comes with a responsibility not to deliberately cause offence > +or discord.) > + > +## Informal roles > + > +### Lurkers > + > +People who do not use Maven at all, but have an interest in > +the project. This can include people who are developing > +competing software tools to Apache Maven. > + > +It would be great if the lurkers would come out of the shadows > +and make themselves visible, but every community needs its > +lurkers, so if you are a lurker sulking about on the fringes > +of the Apache Maven project, know that you are a valued member > +of our community. If you ever feel the need to change your role > +we will welcome you with open arms… (and if we don't welcome you > +with open arms, please advise the [Project management committee][3] > +who are responsible for ensuring that the community is a healthy > +one) > + > +### Consumers > + > +People who use Maven, but do not actively join the community. > +This does not include people who are: subscribed to one of the > +Maven mailing lists; active in a Maven user community (e.g. > +something like [stackoverflow][1]; submitting bug reports; etc. > + > +Maybe Apache Maven is the perfect product for you and does > +exactly what you need and want, and you never have a need > +to ask questions about how to use Maven as it is immediately > +obvious to you how one is supposed to use Maven… if that is the > +case could you please consider taking a more active role in > +our community as Maven is none of the above to our minds > +and you might have a point of view that we have missed. > + > +If you do have issues with Maven (we all have issues with it > +so there is nothing wrong in having issues with Maven) please > +let us know: > + > +* Submitting bug reports is the best way to let us know about bugs > +* Asking questions on the [Users Mailing List][2] is the best way > +get answers to questions. > + > +As a last resort, other Maven user communities are another route > +to getting more involved in the Maven community, but keep in > +mind that Apache Foundation projects are supposed to encourage > +the community at the ASF, so you will get more eyes and a > +quicker response if you engage directly with the ASF hosted > +community. > + > +### Users > + > +People who use Maven and have joined the community. This includes people > who have: > +* Submitted a bug report > +* Asked a question on the [Maven user list][2] > +* Joined one of the other Maven user communities. > + > +We hope your bug report has received some attention, if it > +hasn't why don't you see if you can fix the issue yourself > +and submit a patch? > + > +We hope your question was answered, if it hasn't think of > +all the other users who's questions sit unanswered, how many > +of them do you know an answer for (even if only a partial > +answer)? Why don't you respond to their questions with the > +answers you know? If everybody did that, your question would > +have an answer. Pay it forward! > + > +We hope your experience in one of the other Maven user > +communities is a positive one, so why not join the canonical > +Maven user community and subscribe to the [Maven user list][2]? > + > +### Contributors > + > +People who use Maven, have joined the Maven community and c
Re: svn commit: r1498969 - /maven/site/trunk/content/markdown/project-roles.md
It is important, but it interrupts the flow of the sentence. It is good english to put interruptions in a subordinate clause so that the reader knows to skip them in making sense of the sentence. If you want another way would be to put it in a different interuption style - such as within a minus block - assuming they make sense for the current sentence structure. On 3 July 2013 10:17, Olivier Lamy wrote: > 2013/7/3 Stephen Connolly : > > Anyone who has suggestions for improvements or additional content, please > > shout out or commit your changes... > > > > The aim is to let people understand the different roles and > > responsibilities in the Maven community > > > > > > On 2 July 2013 16:13, wrote: > > > >> Author: stephenc > >> Date: Tue Jul 2 15:13:59 2013 > >> New Revision: 1498969 > >> > >> URL: http://svn.apache.org/r1498969 > >> Log: > >> This is only a draft... and there is still a lot of review needed > >> > >> Added: > >> maven/site/trunk/content/markdown/project-roles.md > >> > >> Added: maven/site/trunk/content/markdown/project-roles.md > >> URL: > >> > http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1498969&view=auto > >> > >> > == > >> --- maven/site/trunk/content/markdown/project-roles.md (added) > >> +++ maven/site/trunk/content/markdown/project-roles.md Tue Jul 2 > >> 15:13:59 2013 > >> @@ -0,0 +1,194 @@ > >> + > >> +# Apache Maven Project Roles > >> + > >> +The Apache Maven project is not just the software it produces. > >> +The Apache Foundation has a phrase: “Community over code†which > >> +is about how it is the community that grows around a project > >> +that is the most important thing. > >> + > >> +Everyone reading this is part of the Apache Maven community, > >> +and even if you are an invisible part of the Apache Maven > >> +community you are still part of the community. > >> + > >> +There are many ways we can sort the people in our > >> +community, we present the following as one such way. > >> +Please do not take offence if you disagree with this > >> +categorisation. It is important to remember that we are > >> +a *community* not a *clique* so you are entitled to disagree > >> +with others in the community. (Note that the right to disagree > >> +comes with a responsibility not to deliberately cause offence > >> +or discord.) > > Why parentheses here? That give me the impression it's not important. > Perso I believe it's important :-) > > >> + > >> +## Informal roles > >> + > >> +### Lurkers > >> + > >> +People who do not use Maven at all, but have an interest in > >> +the project. This can include people who are developing > >> +competing software tools to Apache Maven. > >> + > >> +It would be great if the lurkers would come out of the shadows > >> +and make themselves visible, but every community needs its > >> +lurkers, so if you are a lurker sulking about on the fringes > >> +of the Apache Maven project, know that you are a valued member > >> +of our community. If you ever feel the need to change your role > >> +we will welcome you with open arms… (and if we don't welcome you > >> +with open arms, please advise the [Project management committee][3] > >> +who are responsible for ensuring that the community is a healthy > >> +one) > >> + > >> +### Consumers > >> + > >> +People who use Maven, but do not actively join the community. > >> +This does not include people who are: subscribed to one of the > >> +Maven mailing lists; active in a Maven user community (e.g. > >> +something like [stackoverflow][1]; submitting bug reports; etc. > >> + > >> +Maybe Apache Maven is the perfect product for you and does > >> +exactly what you need and want, and you never have a need > >> +to ask questions about how to use Maven as it is immediately > >> +obvious to you how one is supposed to use Maven… if that is the > >> +case could you please consider taking a more active role in > >> +our community as Maven is none of the above to our minds > >> +and you might have a point of view that we have missed. > >> + > >> +If you do have issues with Maven (we all have issues with it > >> +so t
Re: svn commit: r1498969 - /maven/site/trunk/content/markdown/project-roles.md
On 3 July 2013 11:39, Olivier Lamy wrote: > 2013/7/3 Stephen Connolly : > > It is important, but it interrupts the flow of the sentence. It is good > > english to put interruptions in a subordinate clause so that the reader > > knows to skip them in making sense of the sentence. If you want another > way > > would be to put it in a different interuption style - such as within a > > minus block - assuming they make sense for the current sentence > structure. > > > > thanks for the english lesson! > As that could be different in French it looks we reach a cultural > language difference :-) > Yes well your franglish can often be difficult to decipher... and then there is my hiberno-english (the only true form of the language by the way) which can have increased ironic nuances... e.g. the joke: An english professor is giving a lecture on negatives and positives, how you can have a double negative being the same as a positive but there is never a double positive being the same as a negative... at which point, in a strong Dublin accent is heard from the back of the audience: "Yeah, right!!!" Being in AU, I suggest you pick up a stone and throw it... chances are it will hit an Irish person who will then be able to give the correct intonation on that last bit and perhaps then you might discover the correct way of pronouncing a double positive which means a negative! ;-) > > /me not a native english writer/speaker but learning aussie language :-) > > > > > On 3 July 2013 10:17, Olivier Lamy wrote: > > > >> 2013/7/3 Stephen Connolly : > >> > Anyone who has suggestions for improvements or additional content, > please > >> > shout out or commit your changes... > >> > > >> > The aim is to let people understand the different roles and > >> > responsibilities in the Maven community > >> > > >> > > >> > On 2 July 2013 16:13, wrote: > >> > > >> >> Author: stephenc > >> >> Date: Tue Jul 2 15:13:59 2013 > >> >> New Revision: 1498969 > >> >> > >> >> URL: http://svn.apache.org/r1498969 > >> >> Log: > >> >> This is only a draft... and there is still a lot of review needed > >> >> > >> >> Added: > >> >> maven/site/trunk/content/markdown/project-roles.md > >> >> > >> >> Added: maven/site/trunk/content/markdown/project-roles.md > >> >> URL: > >> >> > >> > http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1498969&view=auto > >> >> > >> >> > >> > == > >> >> --- maven/site/trunk/content/markdown/project-roles.md (added) > >> >> +++ maven/site/trunk/content/markdown/project-roles.md Tue Jul 2 > >> >> 15:13:59 2013 > >> >> @@ -0,0 +1,194 @@ > >> >> + > >> >> +# Apache Maven Project Roles > >> >> + > >> >> +The Apache Maven project is not just the software it produces. > >> >> +The Apache Foundation has a phrase: “Community over code†which > >> >> +is about how it is the community that grows around a project > >> >> +that is the most important thing. > >> >> + > >> >> +Everyone reading this is part of the Apache Maven community, > >> >> +and even if you are an invisible part of the Apache Maven > >> >> +community you are still part of the community. > >> >> + > >> >> +There are many ways we can sort the people in our > >> >> +community, we present the following as one such way. > >> >> +Please do not take offence if you disagree with this > >> >> +categorisation. It is important to remember that we are > >> >> +a *community* not a *clique* so you are entitled to disagree > >> >> +with others in the community. (Note that the right to disagree > >> >> +comes with a responsibility not to deliberately cause offence > >> >> +or discord.) > >> > >> Why parentheses here? That give me the impression it's not important. > >> Perso I believe it's important :-) > >> > >> >> + > >> >> +## Informal roles > >> >> + > >> >> +### Lurkers > >> >> + > >> >> +People who do not use Maven at all, but have an interest in > >> >> +the project.
Re: svn commit: r1498969 - /maven/site/trunk/content/markdown/project-roles.md
Chris, Please provide a diff to what you would like to see Committers, Please feel free to commit the changes you would like. TL;DR It took me a few hours to get that together and I don't have the time right now to make more revisions, so please just hack away On 3 July 2013 12:27, Chris Graham wrote: > What is in (parenthesis) is a full sentence in it's own right. > > Given the personal abuse that I have received recently, and I am aware of > others as well who also have. > > I certainly would like the responsibilities highlighted. > > Because as they say, with great power comes great responsibility. :-) > > -Chris > > Sent from my iPhone > > On 03/07/2013, at 8:12 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > It is important, but it interrupts the flow of the sentence. It is good > > english to put interruptions in a subordinate clause so that the reader > > knows to skip them in making sense of the sentence. If you want another > way > > would be to put it in a different interuption style - such as within a > > minus block - assuming they make sense for the current sentence > structure. > > > > > > On 3 July 2013 10:17, Olivier Lamy wrote: > > > >> 2013/7/3 Stephen Connolly : > >>> Anyone who has suggestions for improvements or additional content, > please > >>> shout out or commit your changes... > >>> > >>> The aim is to let people understand the different roles and > >>> responsibilities in the Maven community > >>> > >>> > >>> On 2 July 2013 16:13, wrote: > >>> > >>>> Author: stephenc > >>>> Date: Tue Jul 2 15:13:59 2013 > >>>> New Revision: 1498969 > >>>> > >>>> URL: http://svn.apache.org/r1498969 > >>>> Log: > >>>> This is only a draft... and there is still a lot of review needed > >>>> > >>>> Added: > >>>>maven/site/trunk/content/markdown/project-roles.md > >>>> > >>>> Added: maven/site/trunk/content/markdown/project-roles.md > >>>> URL: > >>>> > >> > http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1498969&view=auto > >>>> > >>>> > >> > == > >>>> --- maven/site/trunk/content/markdown/project-roles.md (added) > >>>> +++ maven/site/trunk/content/markdown/project-roles.md Tue Jul 2 > >>>> 15:13:59 2013 > >>>> @@ -0,0 +1,194 @@ > >>>> + > >>>> +# Apache Maven Project Roles > >>>> + > >>>> +The Apache Maven project is not just the software it produces. > >>>> +The Apache Foundation has a phrase: “Community over code†which > >>>> +is about how it is the community that grows around a project > >>>> +that is the most important thing. > >>>> + > >>>> +Everyone reading this is part of the Apache Maven community, > >>>> +and even if you are an invisible part of the Apache Maven > >>>> +community you are still part of the community. > >>>> + > >>>> +There are many ways we can sort the people in our > >>>> +community, we present the following as one such way. > >>>> +Please do not take offence if you disagree with this > >>>> +categorisation. It is important to remember that we are > >>>> +a *community* not a *clique* so you are entitled to disagree > >>>> +with others in the community. (Note that the right to disagree > >>>> +comes with a responsibility not to deliberately cause offence > >>>> +or discord.) > >> > >> Why parentheses here? That give me the impression it's not important. > >> Perso I believe it's important :-) > >> > >>>> + > >>>> +## Informal roles > >>>> + > >>>> +### Lurkers > >>>> + > >>>> +People who do not use Maven at all, but have an interest in > >>>> +the project. This can include people who are developing > >>>> +competing software tools to Apache Maven. > >>>> + > >>>> +It would be great if the lurkers would come out of the shadows > >>>> +and make themselves visible, but every community needs its > >>>> +lurkers, so if you are a lurker sulking a
Re: [VOTE] Apache 3.1.0
I have asked the legal-discuss list for an opinion on test data sets and license headers. From my reading of the current ASF position: http://www.apache.org/legal/src-headers.html#faq-exceptions we do not currently have an exception for test data sets. Pending the outcome of that discussion I will have to be -1 If the outcome is that we do not need to do anything for test data sets, then I would be happy to switch to +1. If the outcome is that we need to add some additional text to the NOTICE files to cover the test data sets, then we will need to respin as nobody on the PMC can vote +1 if we are aware that the release is in violation of the ASF policies and we would be neglecting our governance role. If the outcome is that we need to add the license headers to all the test data files, then I think the PMC will have to review what we want to do as adding license headers to every file in the test data set runs the risk of invalidating the test data and that is an unnecessary risk that would cripple the project and as such I would be looking for the ASF to change such a decision and provide us with a means of using the NOTICE file to cover the test data. I hate being petty, but unfortunately that is part of the governance role that the PMC is tasked with... :-( - Stephen On 1 July 2013 03:56, Barrie Treloar wrote: > On 1 July 2013 06:52, sebb wrote: > > Another problem: the NOTICE file contains the following spurious text: > > > > > = > >== NOTICE file corresponding to the section 4 d of > == > >== the Apache License, Version 2.0, > == > >== in this case for the Apache Maven distribution. > == > > > = > > > > This must not be present in NOTICE files, which are required to be as > > short as possible (but no shorter). > > > > ASF NOTICE files must start as per the following example: > > > > > > Apache Maven > > Copyright 2001-2013 The Apache Software Foundation > > > > This product includes software developed at > > The Apache Software Foundation (http://www.apache.org/). > > == > > > > Note also that the phrase should be "developed at" not "developed by" > > - the distinction is important. > > > > Furthermore, the NOTICE file refers to additonal 3rd party software, > > but there don't appear to be any LICENSE files for the software. > > The licenses should either be in LICENSE.txt or linked therefrom. > > From what I can tell we have been failing this since August 2010. > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=apache-maven/NOTICE.txt;hb=bfaf11090a212f8445f2ad929af8acce5a984bf0 > > I can't find change history for > http://www.apache.org/legal/src-headers.html so I don't know if we > have been failing all the time, or since it was changed. > > And I can see you've raised http://jira.codehaus.org/browse/MNG-5487 > to track this. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Apache 3.1.0
On 4 July 2013 12:32, sebb wrote: > On 4 July 2013 11:05, Stephen Connolly > wrote: > > I have asked the legal-discuss list for an opinion on test data sets and > > license headers. From my reading of the current ASF position: > > http://www.apache.org/legal/src-headers.html#faq-exceptions we do not > > currently have an exception for test data sets. > > I undertstand that some test data files cannot have AL headers. > > However, surely any exception which might be agreed does not cover > unit test cases in Java files? > Nor the poms needed to run the tests. > There are several such in the source archive. > Are these in src/test/resources/ or in src/it/ because if so they are test data not software we distribute and build. Without inspecting each and every test data file and the corresponding test case (which invokes the test case using e.g. maven verifier or maven invoker... i.e. files in src/test/java which clearly must have a license header) we cannot be certain that adding a license header will not affect the results of the test... yes the vast majority of them can probably have the header added successfully... but I do not see anyone standing up willing to undertake that mammoth analysis task. I would much rather get an exception that lets us release and then turn the screw and tighten which files need the exception to remain and which can have the headers added as we progress through multiple releases. That is the approach which will help the community as us taking what could be *years* to get the test cases with headers in *every* place where they can safely be put quite frankly would kill this project. > > Pending the outcome of that discussion I will have to be > > > > -1 > > > > If the outcome is that we do not need to do anything for test data sets, > > then I would be happy to switch to +1. > > > > If the outcome is that we need to add some additional text to the NOTICE > > files to cover the test data sets, then we will need to respin as nobody > on > > the PMC can vote +1 if we are aware that the release is in violation of > the > > ASF policies and we would be neglecting our governance role. > > > > If the outcome is that we need to add the license headers to all the test > > data files, then I think the PMC will have to review what we want to do > as > > adding license headers to every file in the test data set runs the risk > of > > invalidating the test data and that is an unnecessary risk that would > > cripple the project and as such I would be looking for the ASF to change > > such a decision and provide us with a means of using the NOTICE file to > > cover the test data. > > > > I hate being petty, but unfortunately that is part of the governance role > > that the PMC is tasked with... :-( > > I would not classify it as unfortunate. > > ASF committership and PMC membership are both privileges, not rights, > and come with certain responsibilities. > In particular to ensure that releases are available under the Apache > License, and don't contain any suprises for the end users. > I started the drive to get the licensing tidied up before you started putting your attentions here: https://github.com/apache/maven/commit/bfcf03d42c37bce5bf16a1ab689073109d191bf7 I understand why the PMC has to do this... Quite frankly it was only when I groked what it means to be a member of the ASF that I got the fuller understanding of the role of the PMC that I have now. I think there are a lot of people in the community that do not understand why the ASF does things the way it does. Such people are prone to see the PMC being pernicious as "meddling" and "getting in the way"... and may even see my -1 vote as "unfortunate". I was just framing my actions so that they are not confused. Aside: If a committer does not like that we (the PMC) have to be this way, and does not think they could uphold the responsibility to conduct their reviews diligently taking care of the legal responsibilities that the ASF tasks the PMC with then I would recommend that such a committer reject a nomination to the PMC if we were to offer it... in some ways being on the PMC is a thankless job... but it is one that I agreed to do... so until I get fed up, so be it! -Stephen > > - Stephen > > > > > > On 1 July 2013 03:56, Barrie Treloar wrote: > > > >> On 1 July 2013 06:52, sebb wrote: > >> > Another problem: the NOTICE file contains the following spurious text: > >> > > >> > > >> > = > >> >== NOTICE file corresponding to the section 4 d of > >> == > >> >== t
Re: [VOTE] Apache 3.1.0
On 4 July 2013 13:14, sebb wrote: > On 4 July 2013 12:52, Stephen Connolly > wrote: > > On 4 July 2013 12:32, sebb wrote: > > > >> On 4 July 2013 11:05, Stephen Connolly > > >> wrote: > >> > I have asked the legal-discuss list for an opinion on test data sets > and > >> > license headers. From my reading of the current ASF position: > >> > http://www.apache.org/legal/src-headers.html#faq-exceptions we do not > >> > currently have an exception for test data sets. > >> > >> I undertstand that some test data files cannot have AL headers. > >> > >> However, surely any exception which might be agreed does not cover > >> unit test cases in Java files? > >> Nor the poms needed to run the tests. > >> There are several such in the source archive. > >> > > > > Are these in src/test/resources/ or in src/it/ because if so they are > test > > data not software we distribute and build. > > One example is: > > > maven-core/src/test/projects/lifecycle-executor/project-with-additional-lifecycle-elements/src/main/java/org/apache/maven/lifecycle/test/App.java > They are all in the rat exclusions list as test resources. They are test data. They are not part of Maven core or part of the Maven plugins. > > They are all distributed, because they are in the source release. > > > Without inspecting each and every test data file and the corresponding > test > > case (which invokes the test case using e.g. maven verifier or maven > > invoker... i.e. files in src/test/java which clearly must have a license > > header) we cannot be certain that adding a license header will not affect > > the results of the test... yes the vast majority of them can probably > have > > the header added successfully... but I do not see anyone standing up > > willing to undertake that mammoth analysis task. > > Why not just add the header and see what breaks? > Aha! you miss the point. These are all tests that pass *because* the bug they fix is fixed. If we add the header, how do you know that adding the header does not render the test useless. If there is a regression the test is supposed to fail. If we add the header and introduce a regression and the test does not fail *because* of adding the header then we have rendered the test useless. Thus we cannot "just see what breaks" because the tests are all passing right now. Only by re-introducing the bug that the test was designed to detect can we confirm that the presence of the header does not affect the strength of the test. The only way to be sure that adding the header does not affect the test sensitivity is to inspect each test by hand, evaluate what it requires of the test data and then see if adding the header will affect sensitivity. > > I would much rather get an exception that lets us release and then turn > the > > screw and tighten which files need the exception to remain and which can > > have the headers added as we progress through multiple releases. That is > > the approach which will help the community as us taking what could be > > *years* to get the test cases with headers in *every* place where they > can > > safely be put quite frankly would kill this project. > > > > > >> > Pending the outcome of that discussion I will have to be > >> > > >> > -1 > >> > > >> > If the outcome is that we do not need to do anything for test data > sets, > >> > then I would be happy to switch to +1. > >> > > >> > If the outcome is that we need to add some additional text to the > NOTICE > >> > files to cover the test data sets, then we will need to respin as > nobody > >> on > >> > the PMC can vote +1 if we are aware that the release is in violation > of > >> the > >> > ASF policies and we would be neglecting our governance role. > >> > > >> > If the outcome is that we need to add the license headers to all the > test > >> > data files, then I think the PMC will have to review what we want to > do > >> as > >> > adding license headers to every file in the test data set runs the > risk > >> of > >> > invalidating the test data and that is an unnecessary risk that would > >> > cripple the project and as such I would be looking for the ASF to > change > >> > such a decision and provide us with a means of using the NOTICE file > to > >> > cover the test data. > >> > > >> > I hate being petty, but unfortunately that is part of the governance > role
Re: [VOTE] Apache 3.1.0
I will let Barrie decide on whether we *have to* cancel this vote because of the issues he identified in the NOTICE file. Until I hear back from legal-discuss, I do not know whether the test data issue has any changes required, so I do not know whether (on the bits I am focusing) there is a requirement for us to respin yet, so from my point of view I am ok with keeping the vote open until I hear back from legal-discuss on the test data issue... but if Barrie's view is that with the current NOTICE we cannot release, then no choice but to cancel the vote now. I'd rather have a vote open to pester legal for a more prompt answer (from a bunch of volunteers on the 4th of July weekend) than have no vote to push them with. On 4 July 2013 13:54, Jason van Zyl wrote: > Then just make the changes you see fit and I'll roll it again. It will > only take a few minutes. If we know what it should be like then we might as > well just do it, as it's likely to take less time than asking if an > exception can be made. > > I can cancel the vote. Make the changes you think are required for > compliance and I'll cut it again. > > On Jul 4, 2013, at 6:05 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > I have asked the legal-discuss list for an opinion on test data sets and > > license headers. From my reading of the current ASF position: > > http://www.apache.org/legal/src-headers.html#faq-exceptions we do not > > currently have an exception for test data sets. > > > > Pending the outcome of that discussion I will have to be > > > > -1 > > > > If the outcome is that we do not need to do anything for test data sets, > > then I would be happy to switch to +1. > > > > If the outcome is that we need to add some additional text to the NOTICE > > files to cover the test data sets, then we will need to respin as nobody > on > > the PMC can vote +1 if we are aware that the release is in violation of > the > > ASF policies and we would be neglecting our governance role. > > > > If the outcome is that we need to add the license headers to all the test > > data files, then I think the PMC will have to review what we want to do > as > > adding license headers to every file in the test data set runs the risk > of > > invalidating the test data and that is an unnecessary risk that would > > cripple the project and as such I would be looking for the ASF to change > > such a decision and provide us with a means of using the NOTICE file to > > cover the test data. > > > > I hate being petty, but unfortunately that is part of the governance role > > that the PMC is tasked with... :-( > > > > - Stephen > > > > > > On 1 July 2013 03:56, Barrie Treloar wrote: > > > >> On 1 July 2013 06:52, sebb wrote: > >>> Another problem: the NOTICE file contains the following spurious text: > >>> > >>> > >> > = > >>> == NOTICE file corresponding to the section 4 d of > >> == > >>> == the Apache License, Version 2.0, > >> == > >>> == in this case for the Apache Maven distribution. > >> == > >>> > >> > = > >>> > >>> This must not be present in NOTICE files, which are required to be as > >>> short as possible (but no shorter). > >>> > >>> ASF NOTICE files must start as per the following example: > >>> > >>> > >>> Apache Maven > >>> Copyright 2001-2013 The Apache Software Foundation > >>> > >>> This product includes software developed at > >>> The Apache Software Foundation (http://www.apache.org/). > >>> == > >>> > >>> Note also that the phrase should be "developed at" not "developed by" > >>> - the distinction is important. > >>> > >>> Furthermore, the NOTICE file refers to additonal 3rd party software, > >>> but there don't appear to be any LICENSE files for the software. > >>> The licenses should either be in LICENSE.txt or linked therefrom. > >> > >> From what I can tell we have been failing this since August 2010. > >> > >> > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=apache-maven/NOTICE.txt;hb=bfaf11090a212f8445f2ad929af8acce5a984bf0 > >> > >> I can't find change history for > >> http
Re: [VOTE] Apache 3.1.0
I am withdrawing my -1 on the basis of the feedback I have received from legal-discuss. My vote is now +0 as I have not tested the distribution and I am waiting for somebody else on the PMC to do the running and make a call on whether we need to fix the NOTICE file for this release. I intend testing the distribution tomorrow unless this vote gets cancelled ;-) - Stephen On Thursday, 4 July 2013, Jason van Zyl wrote: > Fair enough. > > On Jul 4, 2013, at 8:59 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > I will let Barrie decide on whether we *have to* cancel this vote because > > of the issues he identified in the NOTICE file. > > > > Until I hear back from legal-discuss, I do not know whether the test data > > issue has any changes required, so I do not know whether (on the bits I > am > > focusing) there is a requirement for us to respin yet, so from my point > of > > view I am ok with keeping the vote open until I hear back from > > legal-discuss on the test data issue... but if Barrie's view is that with > > the current NOTICE we cannot release, then no choice but to cancel the > vote > > now. > > > > I'd rather have a vote open to pester legal for a more prompt answer > (from > > a bunch of volunteers on the 4th of July weekend) than have no vote to > push > > them with. > > > > > > On 4 July 2013 13:54, Jason van Zyl wrote: > > > >> Then just make the changes you see fit and I'll roll it again. It will > >> only take a few minutes. If we know what it should be like then we > might as > >> well just do it, as it's likely to take less time than asking if an > >> exception can be made. > >> > >> I can cancel the vote. Make the changes you think are required for > >> compliance and I'll cut it again. > >> > >> On Jul 4, 2013, at 6:05 AM, Stephen Connolly < > >> stephen.alan.conno...@gmail.com> wrote: > >> > >>> I have asked the legal-discuss list for an opinion on test data sets > and > >>> license headers. From my reading of the current ASF position: > >>> http://www.apache.org/legal/src-headers.html#faq-exceptions we do not > >>> currently have an exception for test data sets. > >>> > >>> Pending the outcome of that discussion I will have to be > >>> > >>> -1 > >>> > >>> If the outcome is that we do not need to do anything for test data > sets, > >>> then I would be happy to switch to +1. > >>> > >>> If the outcome is that we need to add some additional text to the > NOTICE > >>> files to cover the test data sets, then we will need to respin as > nobody > >> on > >>> the PMC can vote +1 if we are aware that the release is in violation of > >> the > >>> ASF policies and we would be neglecting our governance role. > >>> > >>> If the outcome is that we need to add the license headers to all the > test > >>> data files, then I think the PMC will have to review what we want to do > >> as > >>> adding license headers to every file in the test data set runs the risk > >> of > >>> invalidating the test data and that is an unnecessary risk that would > >>> cripple the project and as such I would be looking for the ASF to > change > >>> such a decision and provide us with a means of using the NOTICE file to > >>> cover the test data. > >>> > >>> I hate being petty, but unfortunately that is part of the governance > role > >>> that the PMC is tasked with... :-( > >>> > >>> - Stephen > >>> > >>> > >>> On 1 July 2013 03:56, Barrie Treloar wrote: > >>> > >>>> On 1 July 2013 06:52, sebb wrote: > >>>>> Another problem: the NOTICE file contains the following spurious > text: > >>>>> > >>>>> > >>>> > >> > = > >>>>> == NOTICE file corresponding to the section 4 d of > >>>> == > >>>>> == the Apache License, Version 2.0, > >>>> == > >>>>> == in this case for the Apache Maven distribution. > >>>> == > >>>>> > >>>> > >> > = > >>>>We know what we are, but know not what we may be. > > -- Shakespeare > > > > > > > -- Sent from my phone
Re: [VOTE] Apache 3.1.0
On Thursday, 4 July 2013, sebb wrote: > On 4 July 2013 20:35, Stephen Connolly > > > wrote: > > I am withdrawing my -1 on the basis of the feedback I have received from > > legal-discuss. > > The question to legal-discuss was specifically about test data, not test > code. That "code" is actually test data. The test code is in src/test/java So my view is if it isn't compiled by the build process it is test data... The "code" you refer to is compiled by the code under test as part of verifying that it can build code correctly... As such it is clearly data. If you want to bring it up with legal-discuss, go for it... But I am not going to rush to modify test data without being sure that the modifications do not invalidate the tests... Now I view it rather unlikely that the test data which consists of .java files will be corrupted by adding a license header, but I cannot say that it will not have the effect, so this is case by case review and baby steps. > > Does the reply to your query about test data also apply to test code? > As I read it, that question was not asked. > > There are several test code files (and related poms) that don't have AL > headers. > > I think it would be worth clarifying the issue with regard to test > code before assuming that the answers also apply to test code. I don't believe you will get a different answer... These files have historically been distributed, the PMC is putting in place a process to get the number as close to zero as can be achieved without compromising on the quality of our extensive test suite... I do not think there is an issue here... I leave it up to others on the PMC to form their judgement on the situation... If others disagree or wish to seek further clarification, then they should do that. The Maven PMC is responsible for Maven releases and as a member if the PMC I am happy with the view of this as test data > > > My vote is now +0 as I have not tested the distribution and I am waiting > > for somebody else on the PMC to do the running and make a call on whether > > we need to fix the NOTICE file for this release. > > There are several problems with the NOTICE and/or LICENSE files. > One is that the NOTICE file mentions 3rd party software, but there are > no corresponding entries in the LICENSE file. If the 3rd party > software is not part of the source release, then the references need > to be removed. > > If the 3rd party software is included (presumably as source) then the > relevant licenses need to be included in the LICENSE file, or included > as separate files linked from the LICENSE file. > > Has anyone established whether there is any 3rd party software > included in the source release? Interesting questions... I wonder what others think > > > I intend testing the distribution tomorrow unless this vote gets > cancelled > > ;-) > > > > - Stephen > > > > On Thursday, 4 July 2013, Jason van Zyl wrote: > > > >> Fair enough. > >> > >> On Jul 4, 2013, at 8:59 AM, Stephen Connolly < > >> stephen.alan.conno...@gmail.com> wrote: > >> > >> > I will let Barrie decide on whether we *have to* cancel this vote > because > >> > of the issues he identified in the NOTICE file. > >> > > >> > Until I hear back from legal-discuss, I do not know whether the test > data > >> > issue has any changes required, so I do not know whether (on the bits > I > >> am > >> > focusing) there is a requirement for us to respin yet, so from my > point > >> of > >> > view I am ok with keeping the vote open until I hear back from > >> > legal-discuss on the test data issue... but if Barrie's view is that > with > >> > the current NOTICE we cannot release, then no choice but to cancel the > >> vote > >> > now. > >> > > >> > I'd rather have a vote open to pester legal for a more prompt answer > >> (from > >> > a bunch of volunteers on the 4th of July weekend) than have no vote to > >> push > >> > them with. > >> > > >> > > >> > On 4 July 2013 13:54, Jason van Zyl wrote: > >> > > >> >> Then just make the changes you see fit and I'll roll it again. It > will > >> >> only take a few minutes. If we know what it should be like then we > >> might as > >> >> well just do it, as it's likely to take less time than asking if an > >> >> exception can be made. > >> >> > >> >> I can cancel the vote. Make the changes you think are required
Re: [VOTE] Apache Maven War plugin 2.4
On 5 July 2013 14:32, sebb wrote: > On 5 July 2013 12:48, Olivier Lamy wrote: > > Hi, > > I'd like to release Apache Maven War Plugin 2.4. > > > > We fixed 10 issue > > > http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18840&styleName=Text&projectId=11150 > > > > Staging repository: > https://repository.apache.org/content/repositories/maven-105 > > > > Source release: > > > https://repository.apache.org/content/repositories/maven-105/org/apache/maven/plugins/maven-war-plugin/2.4/maven-war-plugin-2.4-source-release.zip > > > > Staged web site: > > http://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/ > > > > Vote open for 72H > > [+1] > > [0] > > [-1] X > > There are about 40 test files without AL headers. At least some of > them can and should have headers. > And as we already discussed we have put in place a process to track conformance in this regard. We will be reporting the total of violations to the board and we will be turning the screws to bring this total down. At this point I do not view "test data/resources" as blocking on a release. If you can point to a non-binary file outside of src/it, src/test/resources, or other similar folders that is missing a license header *and* that file was present in the previous release then I agree that it should be addressed before release. Similarly, new plugins or maven release roots should be clean before their first release. But in those cases where we have a legacy issue of missing license headers in test resources, this PMC has put a process in place to address the issue and until the board advises differently, test resources will be addressed by that process -Stephen > > > > > > -- > > Olivier Lamy > > Ecetera: http://ecetera.com.au > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > - > > 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] Apache Maven War plugin 2.4
On 5 July 2013 14:43, Stephen Connolly wrote: > On 5 July 2013 14:32, sebb wrote: > >> On 5 July 2013 12:48, Olivier Lamy wrote: >> > Hi, >> > I'd like to release Apache Maven War Plugin 2.4. >> > >> > We fixed 10 issue >> > >> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18840&styleName=Text&projectId=11150 >> > >> > Staging repository: >> https://repository.apache.org/content/repositories/maven-105 >> > >> > Source release: >> > >> https://repository.apache.org/content/repositories/maven-105/org/apache/maven/plugins/maven-war-plugin/2.4/maven-war-plugin-2.4-source-release.zip >> > >> > Staged web site: >> > http://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/ >> > >> > Vote open for 72H >> > [+1] >> > [0] >> > [-1] X >> >> There are about 40 test files without AL headers. At least some of >> them can and should have headers. >> > > And as we already discussed we have put in place a process to track > conformance in this regard. > > We will be reporting the total of violations to the board and we will be > turning the screws to bring this total down. > > At this point I do not view "test data/resources" as blocking on a release. > > If you can point to a non-binary file outside of src/it, > src/test/resources, or other similar folders that is missing a license > header *and* > that file was present in the previous release then I agree that it should > be addressed before release. > Should read before send. If a file was in a previous release and it is a test resource then the header situation will be addressed by the process the PMC has put in place If a file is not a test resource, then it needs the header for a release... irrespective of whether the file was present in the previous release or not. If a file is a *new* test resource, then it needs the header for a release *or* clear justification that the presence of the header would invalidate the test... we are trying to make things better not worse. -Stephen > > Similarly, new plugins or maven release roots should be clean before their > first release. > > But in those cases where we have a legacy issue of missing license headers > in test resources, this PMC has put a process in place to address the issue > and until the board advises differently, test resources will be addressed > by that process > > -Stephen > > >> > >> > >> > -- >> > Olivier Lamy >> > Ecetera: http://ecetera.com.au >> > http://twitter.com/olamy | http://linkedin.com/in/olamy >> > >> > - >> > 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] Apache Maven War plugin 2.4
On 5 July 2013 14:52, sebb wrote: > On 5 July 2013 14:43, Stephen Connolly wrote: > > On 5 July 2013 14:32, sebb wrote: > > > >> On 5 July 2013 12:48, Olivier Lamy wrote: > >> > Hi, > >> > I'd like to release Apache Maven War Plugin 2.4. > >> > > >> > We fixed 10 issue > >> > > >> > http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18840&styleName=Text&projectId=11150 > >> > > >> > Staging repository: > >> https://repository.apache.org/content/repositories/maven-105 > >> > > >> > Source release: > >> > > >> > https://repository.apache.org/content/repositories/maven-105/org/apache/maven/plugins/maven-war-plugin/2.4/maven-war-plugin-2.4-source-release.zip > >> > > >> > Staged web site: > >> > http://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/ > >> > > >> > Vote open for 72H > >> > [+1] > >> > [0] > >> > [-1] X > >> > >> There are about 40 test files without AL headers. At least some of > >> them can and should have headers. > >> > > > > And as we already discussed we have put in place a process to track > > conformance in this regard. > > > > We will be reporting the total of violations to the board and we will be > > turning the screws to bring this total down. > > > > At this point I do not view "test data/resources" as blocking on a > release. > > At what point will it be blocking? > After we get to zero > > > If you can point to a non-binary file outside of src/it, > > src/test/resources, or other similar folders that is missing a license > > header *and* that file was present in the previous release then I agree > > that it should be addressed before release. > > > > Similarly, new plugins or maven release roots should be clean before > their > > first release. > > > > But in those cases where we have a legacy issue of missing license > headers > > in test resources, this PMC has put a process in place to address the > issue > > and until the board advises differently, test resources will be addressed > > by that process > > So how many more releases will be needed before the WAR plugin is > compliant? > > Seems to me that plugins generally have relatively few files that need > to be addressed, and therefore they don't need to be exempt. > The process I agreed with Sam was that we would track and improve our compliance. We did not specify a time frame as we are all volunteers here. In my role as a member of the PMC I am not going to block releases because of the legacy test resources issue, others on the PMC may feel differently and they are entitled to their opinion if they so choose... no body on the PMC has a "special" role in regard to deciding what is right for the project. I have a veto over certain things by virtue of my position on the PMC. I am simply stating that as a PMC member I will veto any releases which I see containing missing headers on non-"legacy test resources". If the missing headers are on a "legacy test resource" I am stating that I will not attempt to block the release (I cannot veto it as you cannot veto releases, but I will vote -1 and encourage the rest of the PMC to refrain from voting +1) I am working on changes to the Maven project's root pom to add in RAT checks, but I want to be careful how it is done so as not to block releases -Stephen > > > -Stephen > > > > > >> > > >> > > >> > -- > >> > Olivier Lamy > >> > Ecetera: http://ecetera.com.au > >> > http://twitter.com/olamy | http://linkedin.com/in/olamy > >> > > >> > - > >> > 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] Apache Maven War plugin 2.4
On 5 July 2013 14:56, sebb wrote: > On 5 July 2013 14:46, Stephen Connolly wrote: > > On 5 July 2013 14:43, Stephen Connolly wrote: > > > >> On 5 July 2013 14:32, sebb wrote: > >> > >>> On 5 July 2013 12:48, Olivier Lamy wrote: > >>> > Hi, > >>> > I'd like to release Apache Maven War Plugin 2.4. > >>> > > >>> > We fixed 10 issue > >>> > > >>> > http://jira.codehaus.org/secure/ReleaseNote.jspa?version=18840&styleName=Text&projectId=11150 > >>> > > >>> > Staging repository: > >>> https://repository.apache.org/content/repositories/maven-105 > >>> > > >>> > Source release: > >>> > > >>> > https://repository.apache.org/content/repositories/maven-105/org/apache/maven/plugins/maven-war-plugin/2.4/maven-war-plugin-2.4-source-release.zip > >>> > > >>> > Staged web site: > >>> > http://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/ > >>> > > >>> > Vote open for 72H > >>> > [+1] > >>> > [0] > >>> > [-1] X > >>> > >>> There are about 40 test files without AL headers. At least some of > >>> them can and should have headers. > >>> > >> > >> And as we already discussed we have put in place a process to track > >> conformance in this regard. > >> > >> We will be reporting the total of violations to the board and we will be > >> turning the screws to bring this total down. > >> > >> At this point I do not view "test data/resources" as blocking on a > release. > >> > >> If you can point to a non-binary file outside of src/it, > >> src/test/resources, or other similar folders that is missing a license > >> header *and* > >> > > that file was present in the previous release then I agree that it should > >> be addressed before release. > >> > > > > Should read before send. > > > > If a file was in a previous release and it is a test resource then the > > header situation will be addressed by the process the PMC has put in > place > > > > If a file is not a test resource, then it needs the header for a > release... > > irrespective of whether the file was present in the previous release or > not. > > > > If a file is a *new* test resource, then it needs the header for a > release > > *or* clear justification that the presence of the header would invalidate > > the test... we are trying to make things better not worse. > > Agreed, but how are the new files to be identified? > > If the release contains any header violations, one way to identify > which files are new would be to include the SVN tag of the previous > release in the release vote. > That is a problem for the PMC to solve. The PMC has to figure out how to meet its responsibilities. If this determination proves too difficult or time consuming with our current processes then we will change our processes. If the PMC does not find any issues with our current processes with regard to fulfilling our obligations to the ASF, then it is not really an issue that you need to worry about ;-) By all means you can make suggestions, and suggestions are welcome... but really this is in the court of the PMC... you have done your responsibility to the foundation by airing your concerns... the PMC's responsibility is to come up with a solution that meets the needs of this project and the foundation. I do not view vote threads as an appropriate place to continue re-airing issues which the PMC is in the process of trying to address... but of course see my most recent commit to maven-site on project roles for a discussion on disagreement (that page is not published yet as we're still trying to get the content more complete) -Stephen > > -Stephen > > > > > >> > >> Similarly, new plugins or maven release roots should be clean before > their > >> first release. > >> > >> But in those cases where we have a legacy issue of missing license > headers > >> in test resources, this PMC has put a process in place to address the > issue > >> and until the board advises differently, test resources will be > addressed > >> by that process > >> > >> -Stephen > >> > >> > >>> > > >>> > > >>> > -- > >>> > Olivier Lamy > >>> > Ecetera: http://ecetera.com.au > >>> > http://twitter.com/olamy | http://linkedin.com/in/olamy > >>> > > >>> > - > >>> > 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: Spurious file in Apache Maven War plugin 2.4 reelease candidate - broken release process?
On Sunday, 7 July 2013, Arnaud Héritier wrote: > I understand the issue but for me all that problems will never disappear if > we don't find a solution to automate the process. > Yes PMCs (and devs) are responsible to do various controls as you mentioned > but I suppose that we aren't different to others projects and our time > spent in OSS projects is often limited. > About the problem of sources content I have two things in mind : > * The release:perform goal is doing a checkout of the tag and then does the > build/deploy of released stuffs. The problem is that the assembly which is > creating the sources archive is doing it after the build instead of doing > it just after the checkout. How could we change this to be sure that in the > archive we just have what we just checkouted ? If we bind the execution of the src assembly to the "validate" phase of the release profile, that would at least be capturing at the start... Should be possible to move the phase earlier for just the release profile. The alternative is to do a 2nd nested checkout to compare with... > * We could add a control (enforcer ?) that will compare the content of an > archive with an scm tag checkout > > Arnaud > > > On Sun, Jul 7, 2013 at 9:31 PM, sebb > > wrote: > > > On 7 July 2013 13:45, Chris Graham > > wrote: > > > In this instance, these files are derived files, so does it matter? > > > > I already said that this particular file is probably not an issue. > > > > The issue is that the release process is clearly not infallible. > > > > The assembly plugin does not identify every file it needs to include, > > so spurious files can be picked up if they happen to be in the wrong > > place. > > As happened here. > > Furthermore, AFAIK it does not report include failures, so a required > > file could be omitted. > > In this case, there was an issue with a test creating the spurious > > file. If test cases delete work files after use, it's not impossible > > to imagine that the wrong file is deleted. > > > > But regardless of the process used to create the release candidate, I > > think the way to check whether it has the correct contents is to > > compare it against the SCM from which it was derived. The comparison > > will identify missing and spurious files. > > Files that match the SCM also have a traceable provenance, and SCM > > files should already have been validated for license compatibility. > > > > I see this as basic quality control. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > -- > - > Arnaud Héritier > http://aheritier.net > Mail/GTalk: aheritier AT gmail DOT com > Twitter/Skype : aheritier > -- Sent from my phone
Re: Java version compatibility
On 8 July 2013 09:23, Arnaud Héritier wrote: > Hi, > > Last night I introduced by error a dependency requiring Java 6 in the > archetype plugin whereas we are always supposed to support Java 5 (Yes we > can :-) ) > Myself I don't have anymore a Java 5 on my computer and I'm often using > Java 7 by default and I'm probably not the only one. Even if we take care > of dependencies releases notes and we are taking care of APIs we are using > we may easily introduce some incompatibilities. > Jenkins is configured to use Java 5 thus it detects such errors ( > > https://builds.apache.org/view/M-R/view/Maven/job/maven-archetype-m3/138/console > ) > but myself I don't really succeed to follow its notifications because we > have too many false positives. > One think I'm doing at work that allows me to validate these stuffs > locally is to use some enforcer rules (in a release profile) > Bytecode version : > http://mojo.codehaus.org/extra-enforcer-rules/enforceBytecodeVersion.html > Animal Sniffer : http://mojo.codehaus.org/animal-sniffer/ > They are configured with maven.compiler.target thus if a project changes > this property value, our controls are automatically updated. > Could it be useful to have that on our side ? In a parent pom ? > I think if they are in a profile, or enabled by the release profile then that would be good... but if I need to run those every build then I would have concerns (alternatively put them late in the lifecycle so you can at least mvn package... it would make sense to bind them to the verify phase... finally a property to skip them while iterating would make sense too) > Maybe it's just overkill/useless. > Until we decide to bump up to 1.7 as pre-req I don't think it's useless or overkill... overkill is running every build > > WDYT ? > > > - > Arnaud Héritier > http://aheritier.net > Mail/GTalk: aheritier AT gmail DOT com > Twitter/Skype : aheritier >
Re: Java version compatibility
I think ultimately at maven parent, but if you want to play at a less wide level first I think that could be a good plan too On 8 July 2013 09:59, Arnaud Héritier wrote: > yes, far from me the idea to have such controls for every builds :-) > either in a dedicated profile launched manually by committers (and CI?) or > in the release profile > Something to add at which level ? plugins parent ? maven parent ? > > > On Mon, Jul 8, 2013 at 10:52 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On 8 July 2013 09:23, Arnaud Héritier wrote: > > > > > Hi, > > > > > > Last night I introduced by error a dependency requiring Java 6 in the > > > archetype plugin whereas we are always supposed to support Java 5 (Yes > we > > > can :-) ) > > > Myself I don't have anymore a Java 5 on my computer and I'm often > using > > > Java 7 by default and I'm probably not the only one. Even if we take > care > > > of dependencies releases notes and we are taking care of APIs we are > > using > > > we may easily introduce some incompatibilities. > > > Jenkins is configured to use Java 5 thus it detects such errors ( > > > > > > > > > https://builds.apache.org/view/M-R/view/Maven/job/maven-archetype-m3/138/console > > > ) > > > but myself I don't really succeed to follow its notifications because > we > > > have too many false positives. > > > One think I'm doing at work that allows me to validate these stuffs > > > locally is to use some enforcer rules (in a release profile) > > > Bytecode version : > > > > > > http://mojo.codehaus.org/extra-enforcer-rules/enforceBytecodeVersion.html > > > Animal Sniffer : http://mojo.codehaus.org/animal-sniffer/ > > > They are configured with maven.compiler.target thus if a project > > changes > > > this property value, our controls are automatically updated. > > > Could it be useful to have that on our side ? In a parent pom ? > > > > > > > I think if they are in a profile, or enabled by the release profile then > > that would be good... but if I need to run those every build then I would > > have concerns (alternatively put them late in the lifecycle so you can at > > least mvn package... it would make sense to bind them to the verify > > phase... finally a property to skip them while iterating would make sense > > too) > > > > > > > Maybe it's just overkill/useless. > > > > > > > Until we decide to bump up to 1.7 as pre-req I don't think it's useless > or > > overkill... overkill is running every build > > > > > > > > > > WDYT ? > > > > > > > > > - > > > Arnaud Héritier > > > http://aheritier.net > > > Mail/GTalk: aheritier AT gmail DOT com > > > Twitter/Skype : aheritier > > > > > > > > > -- > - > Arnaud Héritier > http://aheritier.net > Mail/GTalk: aheritier AT gmail DOT com > Twitter/Skype : aheritier >
Re: git commit: upgrade to rat:0.9 and defensively prepare for maven-parent 24
You haven't updated the site either... it's still 0.9-SNAPSHOT. If your release process leaves the -SNAPSHOT site deployed then your release process is broken ;-) On 8 July 2013 11:17, sebb wrote: > On 8 July 2013 10:36, wrote: > > Updated Branches: > > refs/heads/master 7bb5f1957 -> 50a24e541 > > > > > > upgrade to rat:0.9 and defensively prepare for maven-parent 24 > > Warning: RAT 0.9 is a lot slower than 0.8 when scanning large files > that don't have a valid license. > Make sure it does not try to scan any log files or javadocs. > > The issue [1] has been fixed and we're hoping to release an update > before too long. > > [1] https://issues.apache.org/jira/browse/RAT-138 > > > > > Project: http://git-wip-us.apache.org/repos/asf/maven/repo > > Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/50a24e54 > > Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/50a24e54 > > Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/50a24e54 > > > > Branch: refs/heads/master > > Commit: 50a24e5418a5eecfec5caa2502c59be3bd1b67a0 > > Parents: 7bb5f19 > > Author: Stephen Connolly > > Authored: Mon Jul 8 10:35:59 2013 +0100 > > Committer: Stephen Connolly > > Committed: Mon Jul 8 10:35:59 2013 +0100 > > > > -- > > pom.xml | 7 +++ > > 1 file changed, 3 insertions(+), 4 deletions(-) > > -- > > > > > > http://git-wip-us.apache.org/repos/asf/maven/blob/50a24e54/pom.xml > > -- > > diff --git a/pom.xml b/pom.xml > > index 95a25b8..fe5f418 100644 > > --- a/pom.xml > > +++ b/pom.xml > > @@ -435,12 +435,9 @@ > > > >org.apache.rat > >apache-rat-plugin > > - 0.8 > > + 0.9 > > > > > > - **/.git* > > - .git/** > > - .idea/** > >src/test/resources*/** > >src/test/projects/** > >src/test/remote-repo/** > > @@ -494,6 +491,8 @@ > > bootstrap/** > > README.bootstrap.txt > > > > + > > + false > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Apache 3.1.0
+1 On 4 July 2013 20:35, Stephen Connolly wrote: > I am withdrawing my -1 on the basis of the feedback I have received from > legal-discuss. > > My vote is now +0 as I have not tested the distribution and I am waiting > for somebody else on the PMC to do the running and make a call on whether > we need to fix the NOTICE file for this release. > > I intend testing the distribution tomorrow unless this vote gets cancelled > ;-) > > - Stephen > > > On Thursday, 4 July 2013, Jason van Zyl wrote: > >> Fair enough. >> >> On Jul 4, 2013, at 8:59 AM, Stephen Connolly < >> stephen.alan.conno...@gmail.com> wrote: >> >> > I will let Barrie decide on whether we *have to* cancel this vote >> because >> > of the issues he identified in the NOTICE file. >> > >> > Until I hear back from legal-discuss, I do not know whether the test >> data >> > issue has any changes required, so I do not know whether (on the bits I >> am >> > focusing) there is a requirement for us to respin yet, so from my point >> of >> > view I am ok with keeping the vote open until I hear back from >> > legal-discuss on the test data issue... but if Barrie's view is that >> with >> > the current NOTICE we cannot release, then no choice but to cancel the >> vote >> > now. >> > >> > I'd rather have a vote open to pester legal for a more prompt answer >> (from >> > a bunch of volunteers on the 4th of July weekend) than have no vote to >> push >> > them with. >> > >> > >> > On 4 July 2013 13:54, Jason van Zyl wrote: >> > >> >> Then just make the changes you see fit and I'll roll it again. It will >> >> only take a few minutes. If we know what it should be like then we >> might as >> >> well just do it, as it's likely to take less time than asking if an >> >> exception can be made. >> >> >> >> I can cancel the vote. Make the changes you think are required for >> >> compliance and I'll cut it again. >> >> >> >> On Jul 4, 2013, at 6:05 AM, Stephen Connolly < >> >> stephen.alan.conno...@gmail.com> wrote: >> >> >> >>> I have asked the legal-discuss list for an opinion on test data sets >> and >> >>> license headers. From my reading of the current ASF position: >> >>> http://www.apache.org/legal/src-headers.html#faq-exceptions we do not >> >>> currently have an exception for test data sets. >> >>> >> >>> Pending the outcome of that discussion I will have to be >> >>> >> >>> -1 >> >>> >> >>> If the outcome is that we do not need to do anything for test data >> sets, >> >>> then I would be happy to switch to +1. >> >>> >> >>> If the outcome is that we need to add some additional text to the >> NOTICE >> >>> files to cover the test data sets, then we will need to respin as >> nobody >> >> on >> >>> the PMC can vote +1 if we are aware that the release is in violation >> of >> >> the >> >>> ASF policies and we would be neglecting our governance role. >> >>> >> >>> If the outcome is that we need to add the license headers to all the >> test >> >>> data files, then I think the PMC will have to review what we want to >> do >> >> as >> >>> adding license headers to every file in the test data set runs the >> risk >> >> of >> >>> invalidating the test data and that is an unnecessary risk that would >> >>> cripple the project and as such I would be looking for the ASF to >> change >> >>> such a decision and provide us with a means of using the NOTICE file >> to >> >>> cover the test data. >> >>> >> >>> I hate being petty, but unfortunately that is part of the governance >> role >> >>> that the PMC is tasked with... :-( >> >>> >> >>> - Stephen >> >>> >> >>> >> >>> On 1 July 2013 03:56, Barrie Treloar wrote: >> >>> >> >>>> On 1 July 2013 06:52, sebb wrote: >> >>>>> Another problem: the NOTICE file contains the following spurious >> text: >> >>>>> >> >>>>> >> >>>> >> >> >> = >> >>>>> == NOTICE file corresponding to the section 4 d of >> >>>> == >> >>>>> == the Apache License, Version 2.0, >> >>>> == >> >>>>> == in this case for the Apache Maven distribution. >> >>>> == >> >>>>> >> >>>> >> >> >> = >> >>>>We know what we are, but know not what we may be. >> >> -- Shakespeare >> >> >> >> >> >> >> > > -- > Sent from my phone >
Re: Next release for master
Remember folks, we are CTR not RTC so we shouldn't be holding up getting stuff done On Monday, 15 July 2013, Arnaud Héritier wrote: > I think we won't debate a lot :-) > Pushed > > > On Mon, Jul 15, 2013 at 10:02 PM, Hervé BOUTEMY > > >wrote: > > > +1 > > > > Regards, > > > > Hervé > > > > Le lundi 15 juillet 2013 21:02:37 Arnaud Héritier a écrit : > > > Hi all, > > > > > > Now that 3.1 is out we'll have to think to the future. > > > I saw on twitter that Jason has already many ideas to share. > > > For now the version in master is 3.1-SNAPSHOT. > > > Do we bump it to 3.2-SNAPSHOT ? > > > (We can always create a 3.1.x branch later from the tag if we need > some > > > bugfix releases) > > > > > > WDYT ? > > > > > > - > > > Arnaud Héritier > > > http://aheritier.net > > > Mail/GTalk: aheritier AT gmail DOT com > > > Twitter/Skype : aheritier > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > -- > - > Arnaud Héritier > http://aheritier.net > Mail/GTalk: aheritier AT gmail DOT com > Twitter/Skype : aheritier > -- Sent from my phone
Re: Log4j2/Logback integration updates
So what I am hearing is that until we bump core to require JDK6 (or 7) then logback is the only runner from a technical point of view (never mind that log4j2 is still not GA) OTOH I would be interested in bumping JDK all the way to 7 if we were happy that toolchains is good enough and we had tests in play that use toolchains On Tuesday, 16 July 2013, Arnaud Héritier wrote: > Hi > > FYI I rebased both branches on current master : > * > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/slf4j-log4j2 > * > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/slf4j-logback > With all work done by Herve both branches have only one interesting commit > to update few deps. > > If you want to test them I shared some archives : > * > > https://dl.dropboxusercontent.com/u/501043/apache-maven-3.2-SNAPSHOT-log4j2-bin.tar.gz > * > > https://dl.dropboxusercontent.com/u/501043/apache-maven-3.2-SNAPSHOT-log4j2-bin.zip > * > > https://dl.dropboxusercontent.com/u/501043/apache-maven-3.2-SNAPSHOT-logback-bin.tar.gz > * > > https://dl.dropboxusercontent.com/u/501043/apache-maven-3.2-SNAPSHOT-logback-bin.zip > (You just have to replace the non-color config file in conf/logging by the > -color one) > > LOG4J2 has 2 issues : > ** It requires Java 6 (while our core is always requiring Java 5 for now) > ** beta 7 and beta 8 aren't supporting some methods we used in our > integration : > [WARNING] setRootLoggerLevel: operation not supported > [WARNING] reset(): operation not supported > > Cheers > > - > Arnaud Héritier > http://aheritier.net > Mail/GTalk: aheritier AT gmail DOT com > Twitter/Skype : aheritier > -- Sent from my phone
Re: Java version usage survey
Given that Oracle have stated they will be more aggressive in forcing people to upgrade, eg -target (and I think -source too) will not got all the way down to 1.2 any more from JDK8 IIRC, we will need to sort out a few things: - is toolchains the way to go? - have we good test coverage with toolchains? Specifically building a JavaEE .ear for a JavaEE 5 container (ie using all/most of our plugins)? Better yet would be building a J2EE 1.4 .ear but I suspect we'd be fine with the JDK 5.0 rather than strict spec conformance. (A lot of "big business" use old containers and have Sarbains-Oxley heavyweight change control, so changing app server is a "very big thing") - have we a good store for toolchains and integration tests? (Invoker skipping tests if certain toolchains are missing, reporting what toolchains are required, merging in toolchains, providing mock toolchains... And have we any other users than the JDK?) - what is the experience of Surefire so far (being the first to completely ditch JRE < 1.5) On Tuesday, 16 July 2013, Mirko Friedenhagen wrote: > On Jul 16, 2013 2:08 AM, "Arnaud Héritier" > > wrote: > > > > Hi, > > > > Java 6 EOL was in feb and Maven and its plugins are always compatible > > with Java 5 (And probably various plugins with Java 4). > > Couldn't it be interesting to see which JDKs our users are using to see > > how we can schedule the end of support of Java 5 (and more). Perhaps a > > removal of Java 5 support in 3.2 or 3.5 ... > > Perhaps with a survey like this : > > > > https://docs.google.com/forms/d/1Jqxq2KgSricwS7YV7pmWvHA8m7_TE7c8JhusugPmGW4/viewform > > What do you think ? > > Useful ? Useless > > Very, very useful. > > Regards > Mirko > -- Sent from my phone
Re: Java version usage survey
As long as surefire can fork down to 1.5 and as long as tool chains can compile with 1.5, the only issue I can see is if the development environments where these older JVMs are running do not have newer JDKs available also. This is the same issue we face in the Jenkins project, were we are (considering/are - I would need to check the most recent decision) dropping JDK 5.0. But you do raise a valid point about other Java vendors than Oracle On Tuesday, 16 July 2013, Chris Graham wrote: > On Tue, Jul 16, 2013 at 10:07 AM, Arnaud Héritier > > >wrote: > > > Hi, > > > > Java 6 EOL was in feb and Maven and its plugins are always compatible > > > > Oracle Java 6 was EOL'd. > > IBM Java 6 was, and is not due to be for a few more years. They even > *extended* 1.5's life for a year. Sept this year, I think. > > -Chris > -- Sent from my phone
Re: Java version usage survey
I've put a question on Stack Overflow: http://stackoverflow.com/questions/17671899/when-is-java-6-end-of-life-in-the-context-of-writing-developer-toolsto see if we can get something that is a bit more focus on facts. e.g. we are all OSS developers: thus premium/extended/sustaining support contracts are outside our budget. If we cannot test it for free, we cannot support it. On 16 July 2013 09:01, Fred Cooke wrote: > My 2c: > >- J7 on Mac is unstable (trust me...) and non-performant, and thus I >require my users to use Apple's J6 on the Mac. >- On Linux there are lots of Swing bugs in all versions, but a lot less >in J7 than J6, so I recommend J7 for Linux guys. >- I don't use J5 for anything at all and none of my code can run on it >due to basics that are missing there. > > I didn't distinguish vendors because the comments apply across all of them > anyway. > Fred. > > On Tue, Jul 16, 2013 at 9:29 AM, Chris Graham > wrote: > > > Hi Arnaud. > > > > You need to at least add an OTHER (ie non oracle) entry as well. You you > > can track Oracle java 6 and Non-Oracle java 6. > > > > -Chris > > > > > > On Tue, Jul 16, 2013 at 4:19 PM, Arnaud Héritier > >wrote: > > > > > Good point. I updated the survey to tell it is the Oracle JDK EOL > > > Survey : > > > > > > > > > https://docs.google.com/forms/d/1Jqxq2KgSricwS7YV7pmWvHA8m7_TE7c8JhusugPmGW4/viewform > > > Replies : > > > > > > > > > https://docs.google.com/forms/d/1Jqxq2KgSricwS7YV7pmWvHA8m7_TE7c8JhusugPmGW4/viewanalytics > > > > > > > > > On Tue, Jul 16, 2013 at 8:06 AM, Chris Graham > > > wrote: > > > > > > > On Tue, Jul 16, 2013 at 10:07 AM, Arnaud Héritier < > aherit...@gmail.com > > > > >wrote: > > > > > > > > > Hi, > > > > > > > > > > Java 6 EOL was in feb and Maven and its plugins are always > > compatible > > > > > > > > > > > > > Oracle Java 6 was EOL'd. > > > > > > > > IBM Java 6 was, and is not due to be for a few more years. They even > > > > *extended* 1.5's life for a year. Sept this year, I think. > > > > > > > > -Chris > > > > > > > > > > > > > > > > -- > > > - > > > Arnaud Héritier > > > http://aheritier.net > > > Mail/GTalk: aheritier AT gmail DOT com > > > Twitter/Skype : aheritier > > > > > >
Re: Java version usage survey
Speaking as a Maven Developer... My primary development machine is OS-X. On that machine I have 1.6.0_24-b07-334, 1.7.0_17, 1.7.0_21, and 1.7.0_25 I have a personal linode running 1.6.0_22, and my famous Acer Aspire One that has some Java 1.5 and 1.6 versions on it... but I have not turned it on more than twice since March 2011... most likely I will wipe it and reinstall some more recent linux on it which will remove the older JDK versions leaving it with likely a 1.6 and a 1.7. I also have a windows box sitting beside me... powered off (the Sun Ultra T-20's are noisy don't you know) I only turn it on when I *need* windows and a virtual machine will not suffice (i.e. firmware updates on Samsung Galaxy S... which is now only used as a game console by my son) That has Java 1.4-1.7 on it but it is far from current in terms of AV and patches, so not something I would turn on for a quick test of a release. Effectively the lowest I can test releases is Java 1.6. It would be interesting to hear what the rest of the committers have as their testing capability. If very few committers have access to Java 1.5 across operating systems then I think the answer is clear... namely we would not be in a position to stand over a release that claims to work on Java 1.5, and hence moving to Java 1.6 as a baseline would seem a good idea. Tools like animal-sniffer are great to help developers who cannot set up the older JVMs on their development environment... but in my experience they are no substitute for running on the older JVM. If our test capability is basically the Windows/Java 1.5 slave and the *nix/Java 1.5 slave on the Apache Jenkins build server *and* we cannot keep that integration test suite passing *then* Java 1.5 is dead for Maven IMHO -Stephen On 16 July 2013 11:58, Robert Patrick wrote: > Oracle Java 5 and 6 are EOLed but Oracle continues to support customers > using commercial products that require them that themselves are not EOLed. > Given that current versions of Maven support Java 5 and 6, the real > question is how important is it for older applications that cannot support > Java 7 to be able to use future versions of Maven? > > As far as I know, there is nothing from preventing Maven developers from > using the existing versions of JDK 5/6 to build and test Maven. > > -- > Robert Patrick > VP, FMW Architects Team: The A-Team > Oracle Corporation Office: +1.940.725.0011 > 1148 Triple Crown Court Fax: +1.940.725.0012 > Bartonville, TX 76226, USA Mobile: +1.469.556.9450 > > Professional Oracle WebLogic Server > by Robert Patrick, Gregory Nyberg, and Philip Aston > with Josh Bregman and Paul Done > Book Home Page: http://www.wrox.com/ > Kindle Version: http://www.amazon.com/ > > > > -Original Message- > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > Sent: Tuesday, July 16, 2013 3:47 AM > To: Maven Developers List > Subject: Re: Java version usage survey > > I've put a question on Stack Overflow: > > http://stackoverflow.com/questions/17671899/when-is-java-6-end-of-life-in-the-context-of-writing-developer-toolsto > see if we can get something that is a bit more focus on facts. > > e.g. we are all OSS developers: thus premium/extended/sustaining support > contracts are outside our budget. If we cannot test it for free, we cannot > support it. > > > On 16 July 2013 09:01, Fred Cooke wrote: > > > My 2c: > > > >- J7 on Mac is unstable (trust me...) and non-performant, and thus I > >require my users to use Apple's J6 on the Mac. > >- On Linux there are lots of Swing bugs in all versions, but a lot > less > >in J7 than J6, so I recommend J7 for Linux guys. > >- I don't use J5 for anything at all and none of my code can run on it > >due to basics that are missing there. > > > > I didn't distinguish vendors because the comments apply across all of > > them anyway. > > Fred. > > > > On Tue, Jul 16, 2013 at 9:29 AM, Chris Graham > > wrote: > > > > > Hi Arnaud. > > > > > > You need to at least add an OTHER (ie non oracle) entry as well. You > > > you can track Oracle java 6 and Non-Oracle java 6. > > > > > > -Chris > > > > > > > > > On Tue, Jul 16, 2013 at 4:19 PM, Arnaud Héritier > > > > > >wrote: > > > > > > > Good point. I updated the survey to tell it is the Oracle JDK EOL > > > > Survey : > > > > > > > > > > > > > https://docs.google.com/forms/d/1Jqxq2KgSricwS7YV7pmWvHA8m7_TE7c8Jhusu > > gPmGW4/viewform > > > > Replies : > > > > > > > > > >
Re: Java version usage survey
s of Maven support Java 5 and 6, the real > > > question is how important is it for older applications that cannot > support > > > Java 7 to be able to use future versions of Maven? > > > > > > As far as I know, there is nothing from preventing Maven developers > from > > > using the existing versions of JDK 5/6 to build and test Maven. > > > > > > -- > > > Robert Patrick > > > VP, FMW Architects Team: The A-Team > > > Oracle Corporation Office: +1.940.725.0011 > > > 1148 Triple Crown Court Fax: +1.940.725.0012 > > > Bartonville, TX 76226, USA Mobile: +1.469.556.9450 > > > > > > Professional Oracle WebLogic Server > > > by Robert Patrick, Gregory Nyberg, and Philip Aston > > > with Josh Bregman and Paul Done > > > Book Home Page: http://www.wrox.com/ > > > Kindle Version: http://www.amazon.com/ > > > > > > > > > > > > -Original Message- > > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > > > Sent: Tuesday, July 16, 2013 3:47 AM > > > To: Maven Developers List > > > Subject: Re: Java version usage survey > > > > > > I've put a question on Stack Overflow: > > > > > > > http://stackoverflow.com/questions/17671899/when-is-java-6-end-of-life-in-the-context-of-writing-developer-toolsto > > > see if we can get something that is a bit more focus on facts. > > > > > > e.g. we are all OSS developers: thus premium/extended/sustaining > support > > > contracts are outside our budget. If we cannot test it for free, we > cannot > > > support it. > > > > > > > > > On 16 July 2013 09:01, Fred Cooke wrote: > > > > > > > My 2c: > > > > > > > >- J7 on Mac is unstable (trust me...) and non-performant, and > thus I > > > >require my users to use Apple's J6 on the Mac. > > > >- On Linux there are lots of Swing bugs in all versions, but a lot > > > less > > > >in J7 than J6, so I recommend J7 for Linux guys. > > > >- I don't use J5 for anything at all and none of my code can run > on it > > > >due to basics that are missing there. > > > > > > > > I didn't distinguish vendors because the comments apply across all of > > > > them anyway. > > > > Fred. > > > > > > > > On Tue, Jul 16, 2013 at 9:29 AM, Chris Graham > > > > wrote: > > > > > > > > > Hi Arnaud. > > > > > > > > > > You need to at least add an OTHER (ie non oracle) entry as well. > You > > > > > you can track Oracle java 6 and Non-Oracle java 6. > > > > > > > > > > -Chris > > > > > > > > > > > > > > > On Tue, Jul 16, 2013 at 4:19 PM, Arnaud Héritier > > > > > > > > > >wrote: > > > > > > > > > > > Good point. I updated the survey to tell it is the Oracle JDK EOL > > > > > > Survey : > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/forms/d/1Jqxq2KgSricwS7YV7pmWvHA8m7_TE7c8Jhusu > > > > gPmGW4/viewform > > > > > > Replies : > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/forms/d/1Jqxq2KgSricwS7YV7pmWvHA8m7_TE7c8Jhusu > > > > gPmGW4/viewanalytics > > > > > > > > > > > > > > > > > > On Tue, Jul 16, 2013 at 8:06 AM, Chris Graham > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Tue, Jul 16, 2013 at 10:07 AM, Arnaud Héritier < > > > > aherit...@gmail.com > > > > > > > >wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Java 6 EOL was in feb and Maven and its plugins are always > > > > > compatible > > > > > > > > > > > > > > > > > > > > > > Oracle Java 6 was EOL'd. > > > > > > > > > > > > > > IBM Java 6 was, and is not due to be for a few more years. They > > > > > > > even > > > > > > > *extended* 1.5's life for a year. Sept this year, I think. > > > > > > > > > > > > > > -Chris > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > - > > > > > > Arnaud Héritier > > > > > > http://aheritier.net > > > > > > Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier > > > > > > > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > >
Re: Java version usage survey
On 16 July 2013 21:52, Kristian Rosenvold wrote: > Look you chickens; until quite recently I kept a 1.3 JVM running on > windows to do the occasional > test of surefire on jdk 1.3. (I kept a vmware image since installing 1.3 > on linux required surrendering your first born to Sauron) All your > complaining about not being able to run 1.5 sounds like childish whining. > > On a more serious note, since we support all relevant new features in 1.6 > & 1.7 already, the only real reason > to move away from 1.5 (for me) is to get the improved generics notations > of 1.7. 1.6 was about as boring a release as Sun ever managed to make. > > So it would seem to me like animal-sniffer at 1.5 level is the way to go > until we can decide to move directly to 1.7? > It would seem to me like we'll just have to rely on this kind of sniffing > ? I still think 1.7 is at least a year away..? > > Most of plexus already has a java 7 compile time requirement right now, > which means we can avoid > using reflection for all kinds of stupid stuff. But since most of that is > handled, we only really have the diamond > notation left ? I don't think there's much to be gained by introducing a > 1.7 library level for the rest of maven ? > > I'm looking for use cases outside what animal sniffer should be able to > handle for us here? Jenkins also does a fairly nice JDK 1.5 test for most > of our projects ? > Until Jenkins gets upgraded to 1.520+ at which point the (crappy in my personal view) Maven job type will be unable to run 1.5 Can still keep trucking with a FreeStyle + Maven Build Step though (and I prefer that way anyway) -Stephen > > Kristian > > > > 16. juli 2013 kl. 02:07 skrev Arnaud Héritier : > > > Hi, > > > > Java 6 EOL was in feb and Maven and its plugins are always compatible > > with Java 5 (And probably various plugins with Java 4). > > Couldn't it be interesting to see which JDKs our users are using to see > > how we can schedule the end of support of Java 5 (and more). Perhaps a > > removal of Java 5 support in 3.2 or 3.5 ... > > Perhaps with a survey like this : > > > https://docs.google.com/forms/d/1Jqxq2KgSricwS7YV7pmWvHA8m7_TE7c8JhusugPmGW4/viewform > > What do you think ? > > Useful ? Useless ?he > > > > > > - > > Arnaud Héritier > > http://aheritier.net > > Mail/GTalk: aheritier AT gmail DOT com > > Twitter/Skype : aheritier > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Java version usage survey
On 16 July 2013 23:01, Arnaud Héritier wrote: > > > > > > > Until Jenkins gets upgraded to 1.520+ at which point the (crappy in my > > personal view) Maven job type will be unable to run 1.5 > > > > > The crappy one which doesn't work with Maven 3.1.0 too (I tested it this > afternoon) > I'm sure Olivier will rush to try and defend that job type... > > > > Can still keep trucking with a FreeStyle + Maven Build Step though (and I > > prefer that way anyway) > > > > > > Me too if we backport features from the crappy maven integration into the > freestyle job (automatic dependencies, post build deployment ..). > What was done in Hudson was good from my point UI (excepted the GWT UI > which was ugly) > > Ahem... there are other ways to skin this cat... but the people who know have been sworn to secrecy under pain of being shot, hung, drawn and quartered before having the entire troupé of Riverdance dance on their grave... so you'll just have to wait a month of so to find out!
Re: Java version usage survey
On 16 July 2013 23:25, Barrie Treloar wrote: > On 17 July 2013 07:31, Arnaud Héritier wrote: > >> Can still keep trucking with a FreeStyle + Maven Build Step though (and > I > >> prefer that way anyway) > >> > >> > > > > Me too if we backport features from the crappy maven integration into the > > freestyle job (automatic dependencies, post build deployment ..). > > What was done in Hudson was good from my point UI (excepted the GWT UI > > which was ugly) > > > > Should we not improve the crappy Maven job for Jenkins? > > I have plans... and I may even have the OK to implement them... we'll see how much I get done > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Java version usage survey
On 17 July 2013 10:09, Olivier Lamy wrote: > 2013/7/17 Olivier Lamy : > > 2013/7/17 Stephen Connolly : > >> On 16 July 2013 23:01, Arnaud Héritier wrote: > >> > >>> > > > >>> > > >>> > Until Jenkins gets upgraded to 1.520+ at which point the (crappy in > my > >>> > personal view) Maven job type will be unable to run 1.5 > >>> > > >>> > > >>> The crappy one which doesn't work with Maven 3.1.0 too (I tested it > this > >>> afternoon) > >>> > >> > >> I'm sure Olivier will rush to try and defend that job type... > By "defend" I meant that you would go and fix it again! I am quite happy to keep bashing that job type... been bashing it since 2007 BTW and I still haven't stopped having issues with it. For example all our automated internal release builds in CloudBees cannot work with the Maven job type and need to be FreeStyle + Maven Build step due to issues in the Maven job type. KK keeps on trying to convince me that some latest change or other will redeem the Maven job type... and we spin a week trying to make it work... and we go back to FreeStyle + Maven Build step... > > > > I prefer to keep my time to maybe update it to get it working with > > 3.1.x rather than waste my time on mailing list discussions. > > > > Apologize if the response looks rude. > I didn't take offence... I was actually trying to say that you would rush to fix the job type, so your reply was exactly in line with my thinking... hmmm perhaps my virtual Olivier simulation that I run in my head is not as inaccurate as I suspect most of my simulations are! :-P > I'm probably too upset to not have tested neither take care of that > before... > > First, I agree on the fact the Maven Integration in Jenkins is optimum > especially in the case of non backward compat change in maven core. > But now we have two options: > 1. rewrite that but we have to build a compatibility layer for all > plugins using MavenReporter extension point (and maybe having > something to move datas to the new model) (probably something to > discuss on jenkins-dev@) > Meh! I think there is a better way... but that is because I have a different plan whereby people don't want the old integrations > 2. hack the current one to make it working with 3.1.x too > > Perso, I don't have time for 1 (this can take a bit of time) (but I > have some ideas too :-)). > So at least we could take care of users and work on 2. (I already did > that for 3.0.x so I can again not sure for an other time :-)) (btw > thanks again to Hervé for the work on maven plugins!) > Hey I'm fine with you getting the job type fixed... I have enough fun trying to duck and avoid support tickets for the job type I *hate*... ;-) > > > > > > >> > >> > >>> > >>> > >>> > Can still keep trucking with a FreeStyle + Maven Build Step though > (and I > >>> > prefer that way anyway) > >>> > > >>> > > >>> > >>> Me too if we backport features from the crappy maven integration into > the > >>> freestyle job (automatic dependencies, post build deployment ..). > >>> What was done in Hudson was good from my point UI (excepted the GWT UI > >>> which was ugly) > >>> > >>> > >> > >> Ahem... there are other ways to skin this cat... but the people who know > >> have been sworn to secrecy under pain of being shot, hung, drawn and > >> quartered before having the entire troupé of Riverdance dance on their > >> grave... so you'll just have to wait a month of so to find out! > > > > > > > > -- > > Olivier Lamy > > Ecetera: http://ecetera.com.au > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Java version usage survey
That would likely be a fix that any organizations providing longer term support would likely backport for their enterprise versions of Jenkins... On 17 July 2013 10:53, Arnaud Héritier wrote: > Note that to have the fix and be able to use Maven 3.1.0, jenkins users > will have to upgrade which won't be soon for many of them > (Myself I'm using the latest really stable one : the 1.480 LTS) > > > On Wed, Jul 17, 2013 at 11:31 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On 17 July 2013 10:09, Olivier Lamy wrote: > > > > > 2013/7/17 Olivier Lamy : > > > > 2013/7/17 Stephen Connolly : > > > >> On 16 July 2013 23:01, Arnaud Héritier wrote: > > > >> > > > >>> > > > > > >>> > > > > >>> > Until Jenkins gets upgraded to 1.520+ at which point the (crappy > in > > > my > > > >>> > personal view) Maven job type will be unable to run 1.5 > > > >>> > > > > >>> > > > > >>> The crappy one which doesn't work with Maven 3.1.0 too (I tested it > > > this > > > >>> afternoon) > > > >>> > > > >> > > > >> I'm sure Olivier will rush to try and defend that job type... > > > > > > > By "defend" I meant that you would go and fix it again! > > > > I am quite happy to keep bashing that job type... been bashing it since > > 2007 BTW and I still haven't stopped having issues with it. For example > all > > our automated internal release builds in CloudBees cannot work with the > > Maven job type and need to be FreeStyle + Maven Build step due to issues > in > > the Maven job type. KK keeps on trying to convince me that some latest > > change or other will redeem the Maven job type... and we spin a week > trying > > to make it work... and we go back to FreeStyle + Maven Build step... > > > > > > > > > > > > I prefer to keep my time to maybe update it to get it working with > > > > 3.1.x rather than waste my time on mailing list discussions. > > > > > > > > > > Apologize if the response looks rude. > > > > > > > I didn't take offence... I was actually trying to say that you would rush > > to fix the job type, so your reply was exactly in line with my > thinking... > > hmmm perhaps my virtual Olivier simulation that I run in my head is not > as > > inaccurate as I suspect most of my simulations are! :-P > > > > > > > I'm probably too upset to not have tested neither take care of that > > > before... > > > > > > First, I agree on the fact the Maven Integration in Jenkins is optimum > > > especially in the case of non backward compat change in maven core. > > > But now we have two options: > > > 1. rewrite that but we have to build a compatibility layer for all > > > plugins using MavenReporter extension point (and maybe having > > > something to move datas to the new model) (probably something to > > > discuss on jenkins-dev@) > > > > > > > Meh! I think there is a better way... but that is because I have a > > different plan whereby people don't want the old integrations > > > > > > > 2. hack the current one to make it working with 3.1.x too > > > > > > Perso, I don't have time for 1 (this can take a bit of time) (but I > > > have some ideas too :-)). > > > So at least we could take care of users and work on 2. (I already did > > > that for 3.0.x so I can again not sure for an other time :-)) (btw > > > thanks again to Hervé for the work on maven plugins!) > > > > > > > Hey I'm fine with you getting the job type fixed... I have enough fun > > trying to duck and avoid support tickets for the job type I *hate*... > > > > ;-) > > > > > > > > > > > > > > > > > > > > >> > > > >> > > > >>> > > > >>> > > > >>> > Can still keep trucking with a FreeStyle + Maven Build Step > though > > > (and I > > > >>> > prefer that way anyway) > > > >>> > > > > >>> > > > > >>> > > > >>> Me too if we backport features from the crappy maven integration > into > > > the > > > >>> freestyle job (automatic dependencies, post build deployment .
Re: Maven 3.1 - Stable ?
Why is 3.1.0 labelled as 3.1.0-alpha-1 (and why have we two 3.1.0-alpha-1 labels... I expect the same answer) On 17 July 2013 21:01, Hervé BOUTEMY wrote: > Le mercredi 17 juillet 2013 14:13:38 Paul Benedict a écrit : > > Is 3.0.5 still the preferred version? I ask because the right-hand aside > is > > still "Get Maven 3.0.5" -- which makes sense if 3.1 is not GA, but I > think > > it is, right? > > > > PS: None of the release-notes.html pages include the release date. Can > this > > information be added (in the future)? It is difficult to determine how > long > > it has been since a prior release. > I wrote http://maven.apache.org/docs/history.html recently exactly for > this > purpose > > Regards, > > Hervé > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Maven 3.1.0 class loading error with Swagger Maven Plugin
If it's not in JIRA it doesn't exist On 18 July 2013 17:18, sebb wrote: > On 18 July 2013 16:35, Arnaud Héritier wrote: > > There are open issues with the detail of changes to do ? > > Create N&L files for the top-level of SCM. > As the source archive must be created from SCM, these N&L files will > be suitable for the source archive assuming nothing significant is > added or omitted. > > The License file for the binary archive can start with the source > License as presumably everything in source is compiled or copied to > the binary. > In addition, the License file will need to be adjusted to take account > of any additional bundled software, e.g. 3rd party jars > In some cases, the Notice file will also need to be adjusted, but note > the following: > > http://www.apache.org/dev/licensing-howto.html#mod-notice > > It's possible that the same NOTICE file will do for both source and > binary archives. > It's very unlikely that the same LICENSE file is suitable. > > Once the appropriate N&L files have been created, they will only need > to change if the bundled software is changed - or if some source code > is imported. > > Note that the N&L files must only relate to the bundled bits, so > individual jars are likely to need the same N&L files as the source. > > > > > On Thu, Jul 18, 2013 at 5:33 PM, sebb wrote: > > > >> On 18 July 2013 15:22, Arnaud Héritier wrote: > >> > On Thu, Jul 18, 2013 at 3:32 PM, Jason van Zyl > wrote: > >> > > >> >> When Sisu with this fix is released I'll cut a 3.1.1. > >> >> > >> > > >> > +1 > >> > >> Now would be a good time to start fixing the NOTICE and LICENSE files. > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> > > > > > > -- > > - > > Arnaud Héritier > > http://aheritier.net > > Mail/GTalk: aheritier AT gmail DOT com > > Twitter/Skype : aheritier > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Maven 3.1.0 class loading error with Swagger Maven Plugin
http://jira.codehaus.org/browse/MNG On 18 July 2013 17:39, sebb wrote: > Which JIRA would that be? > > On 18 July 2013 17:24, Stephen Connolly > wrote: > > If it's not in JIRA it doesn't exist > > > > > > On 18 July 2013 17:18, sebb wrote: > > > >> On 18 July 2013 16:35, Arnaud Héritier wrote: > >> > There are open issues with the detail of changes to do ? > >> > >> Create N&L files for the top-level of SCM. > >> As the source archive must be created from SCM, these N&L files will > >> be suitable for the source archive assuming nothing significant is > >> added or omitted. > >> > >> The License file for the binary archive can start with the source > >> License as presumably everything in source is compiled or copied to > >> the binary. > >> In addition, the License file will need to be adjusted to take account > >> of any additional bundled software, e.g. 3rd party jars > >> In some cases, the Notice file will also need to be adjusted, but note > >> the following: > >> > >> http://www.apache.org/dev/licensing-howto.html#mod-notice > >> > >> It's possible that the same NOTICE file will do for both source and > >> binary archives. > >> It's very unlikely that the same LICENSE file is suitable. > >> > >> Once the appropriate N&L files have been created, they will only need > >> to change if the bundled software is changed - or if some source code > >> is imported. > >> > >> Note that the N&L files must only relate to the bundled bits, so > >> individual jars are likely to need the same N&L files as the source. > >> > >> > > >> > On Thu, Jul 18, 2013 at 5:33 PM, sebb wrote: > >> > > >> >> On 18 July 2013 15:22, Arnaud Héritier wrote: > >> >> > On Thu, Jul 18, 2013 at 3:32 PM, Jason van Zyl > >> wrote: > >> >> > > >> >> >> When Sisu with this fix is released I'll cut a 3.1.1. > >> >> >> > >> >> > > >> >> > +1 > >> >> > >> >> Now would be a good time to start fixing the NOTICE and LICENSE > files. > >> >> > >> >> - > >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> >> For additional commands, e-mail: dev-h...@maven.apache.org > >> >> > >> >> > >> > > >> > > >> > -- > >> > - > >> > Arnaud Héritier > >> > http://aheritier.net > >> > Mail/GTalk: aheritier AT gmail DOT com > >> > Twitter/Skype : aheritier > >> > >> - > >> 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] Retire Maven Model Converter
+1 On Saturday, 20 July 2013, Dennis Lundberg wrote: > Hi, > > The only consumer of Maven Model Converter we have left at the Apache > Maven project is Maven One Plugin. If the vote for the retirement of > Maven One Plugin succeeds we should also retire Maven Model Converter. > The last release was made almost six years ago. Last time I checked > Maven Model Converter was also used by the Apache Archiva project. The > retirement plan is to move the component to the Apache Archiva > project, if they want it. > > http://maven.apache.org/shared/maven-model-converter/ > > I therefor propose that we retire maven-model-converter. > > If this vote is successful I will make one final release of the > component (there are some issues that have been fixed) making it clear > on the component site that it has been retired. After that the source > code will be moved to the Apache Archiva project in Subversion, or if > they do not want it to the "retired" area in Subversion. > > The process for retiring a plugin is described here: > http://maven.apache.org/developers/retirement-plan-plugins.html > > The vote is open for 72 hours. > > [ ] +1 Yes, it's about time > [ ] -1 No, because... > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: Do we document the protocol with the repo manager? And what about deploy:deploy-file and multiple attached artifacts?
On Sunday, 21 July 2013, Benson Margulies wrote: > On Sun, Jul 21, 2013 at 1:52 PM, Robert Scholte > > >wrote: > > > Hi Benson, > > > > I don't understand, because deploy:deploy-file should be able to upload > > pom + artifact + classified-artifacts at once. > > > > There's no provision for uploading one pom plus multiple classified > artifacts in a single transation. There is. I wrote the code so Cassandra could deploy to central > > > > > Robert > > > > > > Op Sun, 21 Jul 2013 19:40:04 +0200 schreef Benson Margulies < > > bimargul...@gmail.com >: > > > > > > Other than in the source of the deploy plugin, do we have a document for > >> 'deploy'? > >> > >> I sporadically run into the fact that the command-line deploy plugin > isn't > >> so hot when one has multiple classified objects. > >> > >> On the one hand, I'm thinking of creating deploy:deploy-files (note the > >> 's') with some scheme for supplying multiple files and such. On the > other > >> hand, I'm thinking about making a tool outside of Maven. > >> > > > > --**--**- > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org< > dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > -- Sent from my phone
Re: RAT setup
Revert my change upping to RAT 0.9 Stupid plugin has major regression in performance, but 0.8 needs excludes for git If I'd had notice I'd have reverted it my self but on a phone so no access to revert it... Once they get a proper usable release we *should* be ok... Though they don't seem to know how to cut releases with Maven... Like wtf is the deal with only -SNAPSHOT docs being public!!! On Sunday, 21 July 2013, Jason van Zyl wrote: > I just tried to cut a distribution using the existing Maven POM and it let > me get through the release:prepare phase without any issues and then failed > during the release:perform phase. I have no idea how RAT works, or who set > it up but that behavior is sub-optimal. Would probably be all right to be > on all the time in the validate phase. Certainly preferable to letting me > cut a tag and then blowing up while trying to release. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > Script timed out > > > > > > > -- Sent from my phone
Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+
+1 (binding) On 23 July 2013 14:59, Stephen Connolly wrote: > This vote is to cover the minimum required version of Java for Maven Core. > > Maven Plugins produced by the Apache Maven Project that are flagged as > compatible with older versions of Maven Core as their baseline will still > require to stick to the minimum Java requirements of that Maven Core > version. In other words, if for example maven-compiler-plugin advertises > compatibility with Maven Core 2.0.11+ then that will still need to be > compiled targeting Java 1.4 and only using dependencies that are aligned > with that runtime requirement. > > Additionally patch releases to existing releases of Maven Core will not be > subject to this requirement. > > For example [example]*if* this vote passes and *if* on Sep 29th we release > Maven 3.2.0 and *if* on Oct 2nd we release Maven 2.0.12, Maven 2.2.2, Maven > 3.0.6, Maven 3.1.1, Maven 3.2.1 and Maven 3.3.0 (due to say some security > issue that affected all versions of Maven) then only Maven 3.3.0 would be > require Java 6 as a minimum runtime requirement, the 2.0.12 release would > still require Java 1.4 and the 2.2.2, 3.0.6, 3.1.1 and 3.2.1 versions would > all still require Java 1.5.[/example] > > This is not a requirement that 3rd party plugins need use Java 6 as a > minimum. Third party plugins are free to require any Java version >= the > corresponding Maven minimum requirement, though obviously from a users > perspective it is best if plugins try to adhere to our contracts for > corresponding versions of Maven Core. > > Justification for the cut-off date: > > * Oracle has gone end of life on Java 6 Feb 2013 (note that there is still > extended and sustaining support for existing Oracle customers using Java 5) > * IBM will go end of life for z/OS on 30th Sep 2013 (other platforms are > still with support, but there are other Java vendors for other platforms) > * Apple no longer supports any hardware that does not have at least an > Apple Java 6 version available. > * Red Hat is providing support for OpenJDK 6 > * HP-UX, OpenVMS, and Tru64 all have a Java 6 implementation available. > > As I see it, that essentially ensures that for the vast majority of > platforms there is a very strong likelihood of a Java 6 compatible version > of Java available for that platform. Toolchains support or forking of the > compiler and surefire can provide support for users who still need to build > with older versions of Java (e.g., as was the case for Java 1.4.2 with > Maven 2.2.1). Additionally users who are forced to use a java version older > than Java 6 also are likely unable to upgrade their version of Maven, so > this change will not affect them > > This vote is open for 72 hours. A minimum of three +1 binding votes (i.e. > from the PMC) and the majority of votes cast from committers will be > required to pass this vote. > > +1000: Yes, and when can we have the vote to go for Java 7 as a minimum? > (This option is equivalent to +1 but provides people the ability to > indicate an additional preference while not contributing to the inevitible > noise) > +1: Yes > 0: No opinion > -1: No > > -Stephen >
[VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+
This vote is to cover the minimum required version of Java for Maven Core. Maven Plugins produced by the Apache Maven Project that are flagged as compatible with older versions of Maven Core as their baseline will still require to stick to the minimum Java requirements of that Maven Core version. In other words, if for example maven-compiler-plugin advertises compatibility with Maven Core 2.0.11+ then that will still need to be compiled targeting Java 1.4 and only using dependencies that are aligned with that runtime requirement. Additionally patch releases to existing releases of Maven Core will not be subject to this requirement. For example [example]*if* this vote passes and *if* on Sep 29th we release Maven 3.2.0 and *if* on Oct 2nd we release Maven 2.0.12, Maven 2.2.2, Maven 3.0.6, Maven 3.1.1, Maven 3.2.1 and Maven 3.3.0 (due to say some security issue that affected all versions of Maven) then only Maven 3.3.0 would be require Java 6 as a minimum runtime requirement, the 2.0.12 release would still require Java 1.4 and the 2.2.2, 3.0.6, 3.1.1 and 3.2.1 versions would all still require Java 1.5.[/example] This is not a requirement that 3rd party plugins need use Java 6 as a minimum. Third party plugins are free to require any Java version >= the corresponding Maven minimum requirement, though obviously from a users perspective it is best if plugins try to adhere to our contracts for corresponding versions of Maven Core. Justification for the cut-off date: * Oracle has gone end of life on Java 6 Feb 2013 (note that there is still extended and sustaining support for existing Oracle customers using Java 5) * IBM will go end of life for z/OS on 30th Sep 2013 (other platforms are still with support, but there are other Java vendors for other platforms) * Apple no longer supports any hardware that does not have at least an Apple Java 6 version available. * Red Hat is providing support for OpenJDK 6 * HP-UX, OpenVMS, and Tru64 all have a Java 6 implementation available. As I see it, that essentially ensures that for the vast majority of platforms there is a very strong likelihood of a Java 6 compatible version of Java available for that platform. Toolchains support or forking of the compiler and surefire can provide support for users who still need to build with older versions of Java (e.g., as was the case for Java 1.4.2 with Maven 2.2.1). Additionally users who are forced to use a java version older than Java 6 also are likely unable to upgrade their version of Maven, so this change will not affect them This vote is open for 72 hours. A minimum of three +1 binding votes (i.e. from the PMC) and the majority of votes cast from committers will be required to pass this vote. +1000: Yes, and when can we have the vote to go for Java 7 as a minimum? (This option is equivalent to +1 but provides people the ability to indicate an additional preference while not contributing to the inevitible noise) +1: Yes 0: No opinion -1: No -Stephen
[DISCUSS] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+
On 23 July 2013 15:29, Lennart Jörelid wrote: > +1000 which is a rather odd number for a vote; blame Stephen instead > of me. :) > > I think we can skip the 1.6 release of the JDK as a Maven basis; JDK 1.6 is > at or near EOL and the step from one > minimum JDK version to another (i.e. JDK 1.7) would be just as painful as > the step to JDK 1.6 - but with added > longevity, feature set and power. > > I am not against holding a vote for Java 1.7 *after* we have got up to Java 1.6. OpenJDK6 is an open source implementation of Java 6 that essentially means that it is possible to fix issues with Java 6 going forward. It is not possible to do that with Java 5 as there is no open source release. Let's get the baseline moved... the Jenkins project recently moved to Java 1.6 as the minimum runtime requirement (while keeping animal-sniffer so that only Java 1.5 APIs are permitted in Jenkins core... in case there is a backlash)... hopefully if we set a date, other projects will line up on that date (I know Kohsuke would be keen to see Jenkins drop the Java 1.5 API requirements on Jenkins and IBM EOLing JDK 5 for z/OS seems like a fine justification to cull JDK 5) -Stephen
Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+
On Tuesday, 23 July 2013, Michael-O <1983-01...@gmx.net> wrote: > Am 2013-07-23 15:59, schrieb Stephen Connolly: > >> This vote is to cover the minimum required version of Java for Maven Core. >> >> > Given than most companies/folks react only when something has been > discontinued, I would move to Java 6 as a baseline not before Christman > 2013. First release in 2014 can ben Java 6+. We are not changing the date in this vote. If the vote passes the date stands. If the vote fails we may decide to try again with a different date. Any date we pick will have objections. Users will be slow picking up new versions anyway, and this only talks about new major/minor versions of core after the date... It may be that we have no such release for a while (heck it took 6+ months to get a very small change set of 3.1.0 out the door) This vote tries to set a line in the sand against which we can say "fair notice was given" My €0.02 > > E.g., we now have a policy to make all apps run in Java 7 but this will > take months and even some are not compatible (doesn't concern mine...but). > > So -0, > > Michael > > > --**--**- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: [VOTE] Release Apache Maven IDEA Plugin version 2.2.1
+1 On Tuesday, 23 July 2013, Dennis Lundberg wrote: > Hi, > > This is the final release of this plugin. After this release it will > be retired, see separate vote thread for more info on that. > > We solved 1 issue: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11135&styleName=Html&version=14478 > > There are still a couple of issues left in JIRA: > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11135&status=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-008/ > > https://repository.apache.org/content/repositories/maven-008/org/apache/maven/plugins/maven-idea-plugin/2.2.1/maven-idea-plugin-2.2.1-source-release.zip > > For those interested, the SCM URL can be found in the pom.xml that is > in the staging repo. > > Staging site: > http://maven.apache.org/plugins-archives/maven-idea-plugin-2.2.1/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+
The split verifier should improve cli performance once core and most plugins are on -target 1.6 Any committer is free to call a vote to up the minimum to 1.7 if they want to. >From a build tool perspective there are some advantages in 1.6 as a baseline (compiler api, scripting api, split verifier for faster initial classloading, etc). >From a non build tool perspective, String.isEmpty() is rather paltry though! On Wednesday, 24 July 2013, Christian Schulte wrote: > Am 07/24/13 04:00, schrieb jieryn: > > > > Move forward or die. If you are stuck on 1.5, you can continue to use > > a full stack that is already supported. I am so sick of hearing people > > complain that they will be broken if a JDK migration to a newer > > version is undertaken. No, you are not broken, you simply can not > > upgrade. There is a huge difference between being broken and not > > having an upgrade path. > > Upgrade to Java 7 because you make use of the new APIs Java 7 introduces > or stay with Java 5. Java 6 does not introduce anything interesting to > Maven core. Java 7 does. > > > This form of anti-migration argument has less value than a "without > > any requirement" argument for not migrating. > > I do not argue against migrating. I do argue against migrating without > any reason. > > Since this is a vote thread: > > +1000 (non-binding) as long as someone explains why there is any need to > change '-target 1.5' to '-target 1.6'. Seriously. I don't get it. You > are really just changing the class file version and nothing else without > any reason. I would like to know the reasioning. Nothing more. > > -- > Christan > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: Passing information between goals
This is generally a tad tricky. 1. Because of class unloading it may not be possible to use the Hack-type solution of stashing the data in a Class level static field. Though that solution will work as long as the field uses a collection type that allows for GC when the MavenProject that it is caching a value for has been collected by GC (think of the users of Maven Embedder who's Maven process may be long lived and reused multiple times) 2. Easiest way may just be to serialize the value into a string form and set a project property with a non-maven resolvable name to the string value. For example I do not think it is possible to have a Maven property start with the null character. You code will need to be defensive, and if the property (or cache value if you go route 1) is missing it will have to calculate the value from scratch On 24 July 2013 12:57, Francesco Mari wrote: > Hi, > > I wrote some MOJOs which use common data. This data depends on the > structure of the project and can't be changed at runtime. > > I would like to compute this information at the beginiing of the build > process, and re-use it in each related goal. Ideally, the first goal should > compute the data, and the following ones will just use it. > > Which is the best option? Are there any plugins already implementing such a > strategy, so I can take a look at their source code? >
Re: Passing information between goals
Ahh yes... that's the one... I spent 3-5 min searching for it. getPluginContext() is the map you want (unless you want to span modules... even then I think you can cheat slightly by doing some funky stuff) On 24 July 2013 14:20, Baptiste MATHUS wrote: > Hi, > > I remember doing that for build-helper. It was for many executions of the > same mojo though, not sure how it behaves with different mojos. > See > > http://mojo.10943.n7.nabble.com/build-helper-m-p-thread-safety-issue-td39561.htmland > the ReserveListenerPortMojo > > My 2 cents. > > Cheers > Le 24 juil. 2013 14:17, "Stephen Connolly" < > stephen.alan.conno...@gmail.com> > a écrit : > > > This is generally a tad tricky. > > > > 1. Because of class unloading it may not be possible to use the Hack-type > > solution of stashing the data in a Class level static field. Though that > > solution will work as long as the field uses a collection type that > allows > > for GC when the MavenProject that it is caching a value for has been > > collected by GC (think of the users of Maven Embedder who's Maven process > > may be long lived and reused multiple times) > > > > 2. Easiest way may just be to serialize the value into a string form and > > set a project property with a non-maven resolvable name to the string > > value. For example I do not think it is possible to have a Maven property > > start with the null character. > > > > You code will need to be defensive, and if the property (or cache value > if > > you go route 1) is missing it will have to calculate the value from > scratch > > > > > > On 24 July 2013 12:57, Francesco Mari wrote: > > > > > Hi, > > > > > > I wrote some MOJOs which use common data. This data depends on the > > > structure of the project and can't be changed at runtime. > > > > > > I would like to compute this information at the beginiing of the build > > > process, and re-use it in each related goal. Ideally, the first goal > > should > > > compute the data, and the following ones will just use it. > > > > > > Which is the best option? Are there any plugins already implementing > > such a > > > strategy, so I can take a look at their source code? > > > > > >
Re: Passing information between goals
getPluginContext() is the one you want. Use that to stash your info.
On 24 July 2013 15:15, Francesco Mari wrote:
> Thank you for the link, but I don't need to coordinate multiple projects in
> the same session. My use case is only focused on one project.
>
> What about serializing the information somewhere in the
> ${project.build.directory} folder?
>
> Are there any issues I should aware of if I implement this solution?
>
>
> 2013/7/24 Stephen Connolly
>
> > Ahh yes... that's the one... I spent 3-5 min searching for it.
> >
> > getPluginContext() is the map you want (unless you want to span
> modules...
> > even then I think you can cheat slightly by doing some funky stuff)
> >
> >
> > On 24 July 2013 14:20, Baptiste MATHUS wrote:
> >
> > > Hi,
> > >
> > > I remember doing that for build-helper. It was for many executions of
> the
> > > same mojo though, not sure how it behaves with different mojos.
> > > See
> > >
> > >
> >
> http://mojo.10943.n7.nabble.com/build-helper-m-p-thread-safety-issue-td39561.htmland
> > > the ReserveListenerPortMojo
> > >
> > > My 2 cents.
> > >
> > > Cheers
> > > Le 24 juil. 2013 14:17, "Stephen Connolly" <
> > > stephen.alan.conno...@gmail.com>
> > > a écrit :
> > >
> > > > This is generally a tad tricky.
> > > >
> > > > 1. Because of class unloading it may not be possible to use the
> > Hack-type
> > > > solution of stashing the data in a Class level static field. Though
> > that
> > > > solution will work as long as the field uses a collection type that
> > > allows
> > > > for GC when the MavenProject that it is caching a value for has been
> > > > collected by GC (think of the users of Maven Embedder who's Maven
> > process
> > > > may be long lived and reused multiple times)
> > > >
> > > > 2. Easiest way may just be to serialize the value into a string form
> > and
> > > > set a project property with a non-maven resolvable name to the string
> > > > value. For example I do not think it is possible to have a Maven
> > property
> > > > start with the null character.
> > > >
> > > > You code will need to be defensive, and if the property (or cache
> value
> > > if
> > > > you go route 1) is missing it will have to calculate the value from
> > > scratch
> > > >
> > > >
> > > > On 24 July 2013 12:57, Francesco Mari
> > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I wrote some MOJOs which use common data. This data depends on the
> > > > > structure of the project and can't be changed at runtime.
> > > > >
> > > > > I would like to compute this information at the beginiing of the
> > build
> > > > > process, and re-use it in each related goal. Ideally, the first
> goal
> > > > should
> > > > > compute the data, and the following ones will just use it.
> > > > >
> > > > > Which is the best option? Are there any plugins already
> implementing
> > > > such a
> > > > > strategy, so I can take a look at their source code?
> > > > >
> > > >
> > >
> >
>
Re: [VOTE] Release Apache Maven Model Converter version 2.3
+1 On 23 July 2013 20:45, Dennis Lundberg wrote: > Hi, > > This will be the final release of this shared component. After this > release it will retire from the Apache Maven project and move to the > Apache Archiva project. See separate vote thread about that. > > We solved 6 issues: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleName=Html&version=14389 > > There are no issues left in JIRA (except for the one to retire, which > I'll close later): > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11761&component=13272&status=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-010/ > > https://repository.apache.org/content/repositories/maven-010/org/apache/maven/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.zip > > Staging site (not synced yet): > http://maven.apache.org/shared-archives/maven-model-converter-2.3/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSS] Moving unreleased shared components to the sandbox
I'm all for it On 24 July 2013 23:06, Dennis Lundberg wrote: > Hi > > I've been going through our shared components making sure they all > follow ASF branding rules. While doing this I became curious about a > couple of the components that seemed alien to me. It turns out that of > our 30 shared components we have 5 that have not yet had a release. I > haven't yet looked in svn to see if there has been any recent work on > these 5 components. Here are the components, that haven't yet had a > release: > > maven-ant > maven-plugin-enforcer > maven-project-utils > maven-script > maven-shared-monitor > > Is anyone working on these? > > If not then I think we should move them to the sandbox, until someone > steps up to do a release of them. > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
[DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)
There are two schools of thought amongst the current members of this projects PMC. Without wanting to deliberately tip my hand and reveal where my opinion is, we would like to solicit the opinions if the community that we serve. Please give us your thoughts. The topic is essentially: Do you want the members of the Maven PMC to be social leaders of the Maven community, who's actions demonstrate the best community behaviour? The alternative is that members of the Maven PMC are here purely to complete the legal requirements that an Apache TLP has delegated to PMCs This is not black and white... The answer can be grey... And everyone is human so can make mistakes... So community, what are you expecting? - Stephen Connolly On Thursday, 25 July 2013, wrote: > Author: jdcasey > Date: Wed Jul 24 23:21:58 2013 > New Revision: 1506778 > > URL: http://svn.apache.org/r1506778 > Log: > Adding section on PMC standards of community commitment > > Modified: > maven/site/trunk/content/markdown/project-roles.md > > Modified: maven/site/trunk/content/markdown/project-roles.md > URL: > http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778&r1=1506777&r2=1506778&view=diff > > == > --- maven/site/trunk/content/markdown/project-roles.md (original) > +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 > 23:21:58 2013 > @@ -176,6 +176,29 @@ The Project Management Committee has the > * Voting on release artifacts. > * > > + Standards for Community Commitment > + > +In the spirit of supporting the health of our community, Project > +Management Committee members refrain from actions that subvert the > +functioning of the committee itself. > + > +First, Project Management Committee members should not maintain > long-running > +forks of Maven code outside of the project itself. Making significant > +changes to Maven code outside of the project displays a lack of > +investment in the community. Additionally, attempting to re-integrate > +a large number of code changes in bulk overwhelms the ability of > +volunteers in the community to review (and potentially veto) the > +changes. This effectively thwarts the policing function of the > +PMC. > + > +Second, Project Management Committee members should not divert > +work on redesigning, reimplementing, or improving Maven code to > +alternative projects outside of this community for the purposes of > +reintroducing them as replacement for existing Maven code. While there > +is a danger here of falling into a Not Invented Here mentality, new > projects > +created by Maven PMC members strictly to replace Maven code should not be > +allowed. > + > ### [Project Management Chair]( > http://www.apache.org/foundation/how-it-works.html#pmc-chair) > > For various legal reasons, there are certain things that the Apache > > > -- Sent from my phone
Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)
Perhaps we could reframe the question a little then (as people seem to be testing hung up on the committed wording)... Should the PMC encourage people experimenting on new improvements to Maven to do that work at the ASF? And if so, should they then practice what they preach, and ensure that any experiments with Maven take place on the ASF SCM servers (at least once such experiments become semi-serious or progress enough not to cause egg-on-face syndrome)? Shoud the PMC promote other Apache projects, or moving non-Apache projects to Apache? (Right now, to work on an issue in core and effect the change yourself you may need to establish merit with: Apache Maven, Eclipse Sisu, Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be fine with half of these at Eclipse and the ther half here... Or maybe not... But that is a lot of projects where you need to establish merit and perhaps maintain merit just to be able to commit directly (which sometimes is the only way to effect the type of cross system changes that some of our more obscure bugs may require... GIT makes this less of a requirement, as patches on SVN are a PITA, though) ) These types of questions need resolution as they will, further down the road, rise up again and cause wounds... Eg logback vs log4j2 is one that simmers at the edge (any time anyone mentioned coloured loggers) -Stephen On Thursday, 25 July 2013, Paul Benedict wrote: > I don't think it is possible to force volunteer efforts and/or limit > development elsewhere. The idea of supporting a project is a vague notion. > I have my opinions too but this language is clearly unenforceable and > impractical. > > Cheers, > Paul > > > On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg wrote: > > > As a Maven user I think that everybody who is working on a project should > > behave the same. Hence, I would say, PMC members should rather certainly > > demonstrate how to live the community rules. > > > > -Ursprüngliche Nachricht- > > Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > > Gesendet: Donnerstag, 25. Juli 2013 15:16 > > An: Maven Users List; Maven Developers List > > Betreff: [DISCUSS] Should the Maven PMC be an example of how we want the > > Maven Community to behave (was Re: svn commit: r1506778 - > > /maven/site/trunk/content/markdown/project-roles.md) > > > > There are two schools of thought amongst the current members of this > > projects PMC. > > > > Without wanting to deliberately tip my hand and reveal where my opinion > > is, we would like to solicit the opinions if the community that we serve. > > > > Please give us your thoughts. > > > > The topic is essentially: > > > > Do you want the members of the Maven PMC to be social leaders of the > Maven > > community, who's actions demonstrate the best community behaviour? > > > > The alternative is that members of the Maven PMC are here purely to > > complete the legal requirements that an Apache TLP has delegated to PMCs > > > > This is not black and white... The answer can be grey... And everyone is > > human so can make mistakes... > > > > So community, what are you expecting? > > > > - Stephen Connolly > > > > On Thursday, 25 July 2013, wrote: > > > > > Author: jdcasey > > > Date: Wed Jul 24 23:21:58 2013 > > > New Revision: 1506778 > > > > > > URL: http://svn.apache.org/r1506778 > > > Log: > > > Adding section on PMC standards of community commitment > > > > > > Modified: > > > maven/site/trunk/content/markdown/project-roles.md > > > > > > Modified: maven/site/trunk/content/markdown/project-roles.md > > > URL: > > > http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project > > > -roles.md?rev=1506778&r1=1506777&r2=1506778&view=diff > > > > > > == > > > > > > --- maven/site/trunk/content/markdown/project-roles.md (original) > > > +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24 > > > 23:21:58 2013 > > > @@ -176,6 +176,29 @@ The Project Management Committee has the > > > * Voting on release artifacts. > > > * > > > > > > + Standards for Community Commitment > > > + > > > +In the spirit of supporting the health of our community, Project > > > +Management Committee members refrain from actions that subvert the > > > +functioning of the committee itself. > > > + > > > +First, Project Management Committee members should
Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)
On 25 July 2013 22:17, Paul Benedict wrote: > Stephen, those are great questions. Yet, I think these questions are riding > an assumption that PMC members are solely volunteering at Apache, because > the emphasis (as I interpret your words) is to place the Apache project > first/above other external contributions. Isn't that the heart of this > debate? A person who solely contributes to Apache and no other OS > organizations has no divided loyalties -- they do all their work here. But > what happens when contributions are here and elsewhere? If they feel they cannot resolve any conflict between their role on the PMC and any responsibilities the Maven community decide are part and parcel of that role with their roles in other projects, then quite simply they can just step down from the PMC and remain a committer. There is no shame in so doing. Which brings us back to what does the community expect from its PMC? > I ask rhetorically, > to solicit answers, of course... and I see where this is going and what > historical processes within Maven are being addressed. > > > On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > Perhaps we could reframe the question a little then (as people seem to be > > testing hung up on the committed wording)... > > > > Should the PMC encourage people experimenting on new improvements to > Maven > > to do that work at the ASF? And if so, should they then practice what > they > > preach, and ensure that any experiments with Maven take place on the ASF > > SCM servers (at least once such experiments become semi-serious or > progress > > enough not to cause egg-on-face syndrome)? > > > > Shoud the PMC promote other Apache projects, or moving non-Apache > projects > > to Apache? (Right now, to work on an issue in core and effect the change > > yourself you may need to establish merit with: Apache Maven, Eclipse > Sisu, > > Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be > > fine with half of these at Eclipse and the ther half here... Or maybe > > not... But that is a lot of projects where you need to establish merit > and > > perhaps maintain merit just to be able to commit directly (which > sometimes > > is the only way to effect the type of cross system changes that some of > our > > more obscure bugs may require... GIT makes this less of a requirement, as > > patches on SVN are a PITA, though) ) > > > > These types of questions need resolution as they will, further down the > > road, rise up again and cause wounds... Eg logback vs log4j2 is one that > > simmers at the edge (any time anyone mentioned coloured loggers) > > > > -Stephen > > > > On Thursday, 25 July 2013, Paul Benedict wrote: > > > > > I don't think it is possible to force volunteer efforts and/or limit > > > development elsewhere. The idea of supporting a project is a vague > > notion. > > > I have my opinions too but this language is clearly unenforceable and > > > impractical. > > > > > > Cheers, > > > Paul > > > > > > > > > On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg wrote: > > > > > > > As a Maven user I think that everybody who is working on a project > > should > > > > behave the same. Hence, I would say, PMC members should rather > > certainly > > > > demonstrate how to live the community rules. > > > > > > > > -Ursprüngliche Nachricht- > > > > Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > > > > Gesendet: Donnerstag, 25. Juli 2013 15:16 > > > > An: Maven Users List; Maven Developers List > > > > Betreff: [DISCUSS] Should the Maven PMC be an example of how we want > > the > > > > Maven Community to behave (was Re: svn commit: r1506778 - > > > > /maven/site/trunk/content/markdown/project-roles.md) > > > > > > > > There are two schools of thought amongst the current members of this > > > > projects PMC. > > > > > > > > Without wanting to deliberately tip my hand and reveal where my > opinion > > > > is, we would like to solicit the opinions if the community that we > > serve. > > > > > > > > Please give us your thoughts. > > > > > > > > The topic is essentially: > > > > > > > > Do you want the members of the Maven PMC to be social leaders of the > > > Maven > > > > community, who's actions demonstrate the best community behavi
Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)
On 25 July 2013 22:34, Nigel Magnay wrote: > > > > > > Should the PMC encourage people experimenting on new improvements to > Maven > > to do that work at the ASF? And if so, should they then practice what > they > > preach, and ensure that any experiments with Maven take place on the ASF > > SCM servers (at least once such experiments become semi-serious or > progress > > enough not to cause egg-on-face syndrome)? > > > > > That feels to me like swimming entirely against the tide, and a recipe for > irrelevance. > > Who, in 2013, *cares* about Apache's SCM? OSS, for just about everyone I > speak to these days runs thus: > > 1) Is it on Github? > 2) If no, fork onto GIthub. > > ASF might indeed value "community over code", but that doesn't seem to be a > winning strategy any longer, and those changes seem to be trying to > double-down on that strategy. > There is nothing preventing the project from being mirrored onto GitHub, and in fact the Maven project is mirrored there. We *legally* need to have the code end up back at ASF if we are to release it under the legal protections that the ASF provides. We *legally* are supposed to review aspects of the provenance of the code that gets released. The more code development that takes place on non ASF servers, the less we can be sure of. By having commits and forks at ASF, then each non-ASF set of commits will be smaller and more likely from a single author which means less work for reviewing. Code dumps from a long running fork are thus incompatible with releasing from the ASF If you are a YOLO developer, perhaps you don't care about the legal stuff... your prerogative... I think it is a mistake though. > > Perhaps Maven should extricate itself from the ASF. Maybe that's what long > standing forks will do. > Perhaps. Perhaps not. This is a different question... and one that also begs an answer to a different question: what value do users of Maven place on the legal protections that being released from the ASF provide. There is also the question of whether the developers value the legal protections. But at the end of they day there seems to be quite a large cohort of OSS developers who take a YOLO attitude towards legal stuff[1]... who knows what experiences they will encounter in the next few years and whether they will change their opinions in the light of their experiences and whether they will then see relevance in the ASF. [1]: There are lots of projects on GitHub that don't even bother to have a license
Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)
On 25 July 2013 23:15, Fred Cooke wrote: > So much in-crowd politics and unspoken but apparently well-known material. > > Who is the person, who if they were to come across this, would obviously > know they were being talked about anyway? > I would rather we not focus on specific people. This should be a question that is isolated from any specific person. Often times when there is a specific person in mind people can have biases both for that person or against that person which can colour their views of the question at hand. > > Where is the, almost certainly short lived, fork of Maven located? A quick > search failed to reveal this. > There is at least one Maven Committer who has been maintaining a fork of Maven for perhaps the greater part of a year. There is nothing wrong with committers maintaining their own private forks. If they intend on bringing the work back to the Maven project, then the best way to achieve that is in smaller parts and not as one big code drop at the end. The question is whether the community sees this as against the spirit of what it means to be part of the PMC. We could pick one specific individual as a "test case" but I don't think that would be productive. Any such individual is likely to bring a lot of other baggage with them and could therefore confuse the results of such a "test case" > Such material is best on the table. > I hope we don't have to devolve to specifics about specific individuals. > > Fred. > > On Fri, Jul 26, 2013 at 12:07 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On 25 July 2013 22:34, Nigel Magnay wrote: > > > > > > > > > > > > > > Should the PMC encourage people experimenting on new improvements to > > > Maven > > > > to do that work at the ASF? And if so, should they then practice what > > > they > > > > preach, and ensure that any experiments with Maven take place on the > > ASF > > > > SCM servers (at least once such experiments become semi-serious or > > > progress > > > > enough not to cause egg-on-face syndrome)? > > > > > > > > > > > That feels to me like swimming entirely against the tide, and a recipe > > for > > > irrelevance. > > > > > > Who, in 2013, *cares* about Apache's SCM? OSS, for just about everyone > I > > > speak to these days runs thus: > > > > > > 1) Is it on Github? > > > 2) If no, fork onto GIthub. > > > > > > ASF might indeed value "community over code", but that doesn't seem to > > be a > > > winning strategy any longer, and those changes seem to be trying to > > > double-down on that strategy. > > > > > > > There is nothing preventing the project from being mirrored onto GitHub, > > and in fact the Maven project is mirrored there. > > > > We *legally* need to have the code end up back at ASF if we are to > release > > it under the legal protections that the ASF provides. > > > > We *legally* are supposed to review aspects of the provenance of the code > > that gets released. The more code development that takes place on non ASF > > servers, the less we can be sure of. > > > > By having commits and forks at ASF, then each non-ASF set of commits will > > be smaller and more likely from a single author which means less work for > > reviewing. > > > > Code dumps from a long running fork are thus incompatible with releasing > > from the ASF > > > > If you are a YOLO developer, perhaps you don't care about the legal > > stuff... your prerogative... I think it is a mistake though. > > > > > > > > > > Perhaps Maven should extricate itself from the ASF. Maybe that's what > > long > > > standing forks will do. > > > > > > > Perhaps. Perhaps not. This is a different question... and one that also > > begs an answer to a different question: what value do users of Maven > place > > on the legal protections that being released from the ASF provide. There > is > > also the question of whether the developers value the legal protections. > > > > But at the end of they day there seems to be quite a large cohort of OSS > > developers who take a YOLO attitude towards legal stuff[1]... who knows > > what experiences they will encounter in the next few years and whether > they > > will change their opinions in the light of their experiences and whether > > they will then see relevance in the ASF. > > > > [1]: There are lots of projects on GitHub that don't even bother to have > a > > license > > >
[RESULT] [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+
On 23 July 2013 14:59, Stephen Connolly wrote: > This vote is to cover the minimum required version of Java for Maven Core. > > Maven Plugins produced by the Apache Maven Project that are flagged as > compatible with older versions of Maven Core as their baseline will still > require to stick to the minimum Java requirements of that Maven Core > version. In other words, if for example maven-compiler-plugin advertises > compatibility with Maven Core 2.0.11+ then that will still need to be > compiled targeting Java 1.4 and only using dependencies that are aligned > with that runtime requirement. > > Additionally patch releases to existing releases of Maven Core will not be > subject to this requirement. > > For example [example]*if* this vote passes and *if* on Sep 29th we release > Maven 3.2.0 and *if* on Oct 2nd we release Maven 2.0.12, Maven 2.2.2, Maven > 3.0.6, Maven 3.1.1, Maven 3.2.1 and Maven 3.3.0 (due to say some security > issue that affected all versions of Maven) then only Maven 3.3.0 would be > require Java 6 as a minimum runtime requirement, the 2.0.12 release would > still require Java 1.4 and the 2.2.2, 3.0.6, 3.1.1 and 3.2.1 versions would > all still require Java 1.5.[/example] > > This is not a requirement that 3rd party plugins need use Java 6 as a > minimum. Third party plugins are free to require any Java version >= the > corresponding Maven minimum requirement, though obviously from a users > perspective it is best if plugins try to adhere to our contracts for > corresponding versions of Maven Core. > > Justification for the cut-off date: > > * Oracle has gone end of life on Java 6 Feb 2013 (note that there is still > extended and sustaining support for existing Oracle customers using Java 5) > * IBM will go end of life for z/OS on 30th Sep 2013 (other platforms are > still with support, but there are other Java vendors for other platforms) > * Apple no longer supports any hardware that does not have at least an > Apple Java 6 version available. > * Red Hat is providing support for OpenJDK 6 > * HP-UX, OpenVMS, and Tru64 all have a Java 6 implementation available. > > As I see it, that essentially ensures that for the vast majority of > platforms there is a very strong likelihood of a Java 6 compatible version > of Java available for that platform. Toolchains support or forking of the > compiler and surefire can provide support for users who still need to build > with older versions of Java (e.g., as was the case for Java 1.4.2 with > Maven 2.2.1). Additionally users who are forced to use a java version older > than Java 6 also are likely unable to upgrade their version of Maven, so > this change will not affect them > > This vote is open for 72 hours. A minimum of three +1 binding votes (i.e. > from the PMC) and the majority of votes cast from committers will be > required to pass this vote. > > +1000: Yes, and when can we have the vote to go for Java 7 as a minimum? > (This option is equivalent to +1 but provides people the ability to > indicate an additional preference while not contributing to the inevitible > noise) > +1: Yes > 0: No opinion > -1: No > > -Stephen > Results: +1 (binding): Stephen Connolly, Arguad Héritier, Dennis Lundberg, Wayne Fay, Barrie Treloar, Kristian Rosenvold, Olivier Lamy, John Casey, Robert Scholte. +1 (committers): Tony Chemit, Anders Hammar, Tamás Cservenák, Andreas Gudian. +1 (others): Fred Cooke, Lennart Jörelid, Jeff Jensen, Paul Benedict, Baptiste Mathus, Jeff Maury, Stevo Slavic, Chris Graham, Christian Schulte, Mirko Friedenhagen. 0: Michael O We have more than three PMC +1's Of those committers who voted, the majority voted +1 (all in fact) This vote passes.
[ANN] New release lines of Apache Maven after 30th Sep 2013 will require Java 6 or newer
As a result of a recent vote on the Maven Developers list the decision has been made to discontinue support for running Maven itself using Java 5.0. The Maven 2.0.x release line has a minimum Java requirement of 1.4 The Maven 2.1.x, 2.2.x, 3.0.x and 3.1.x release lines all have a minimum Java requirement of 5.0 After of 30th of September 2013, any new release lines will have a minimum Java requirement of 6.0 Existing release lines will retain their existing requirements for any new patch releases. Plugins will continue to default to following the Java requirements of the base version of Maven that those plugins run on (though specific plugins are always free to insist on a more recent version of Java than their base version of Maven core would indicate if there is a good reason for that action) No decision has been made as to when to move the minimum Java requirement higher. Note that this is only the minimum requirement for running Maven itself. It is possible to configure the Apache Maven Compiler plugin to compile using a different JDK than the JRE used to run Maven. (See http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html ) It is possible to configure Apache Maven Surefire and Failsafe plugins to run unit/integration tests using a different JDK than the JRE used to run Maven. (See either http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#jvm) Another useful resource is the Toolchains support: http://maven.apache.org/guides/mini/guide-using-toolchains.html which can be used to simplify using a different JDK for compiling and running unit tests. Thank you. -Stephen Connolly on behalf of the Maven Developers.
Re: [VOTE] Release Apache Maven One Plugin version 1.3
+1 On 27 July 2013 22:25, Dennis Lundberg wrote: > Hi, > > We solved 4 issues: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11241&styleName=Html&version=13719 > > There are still a couple of issues left in JIRA: > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11241&status=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-028/ > > https://repository.apache.org/content/repositories/maven-028/org/apache/maven/plugins/maven-one-plugin/1.3/maven-one-plugin-1.3-source-release.zip > > Staging site: > http://maven.apache.org/plugins-archives/maven-one-plugin-1.3/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Release Maven 3.1.1
On Sunday, 28 July 2013, Robert Scholte wrote: > Hi, > > Personally I'm not a huge fan of the release-model as done by Jenkins, > meaning releasing once or twice a week with only a few fixes. I am a really big fan of this model... But it won't work the same for Maven... Where the model falls down is when you want to evolve an API, you either have to hold back on a feature branch, rebasing all the time, or push it out piecemeal and have to maintain backwards compat for intermediary iterations. I would propose that every (1 week or 2 weeks... Lets pick one of these) we evaluate the changes to all active release lines... If there are confirmed bug fixes in the line, pull the trigger and get the release done. For 3.2, until it is ready to become a release line, I don't see value in cutting alphas... Anyone interested *should* be able to build their own -SNAPSHOT and we don't get uptake on alphas anyway > As a user I'm not going to update for every new release, it most have real > value before I upgrade. As a user, if a bug is blocking me I want the official release build now. > As both developer and user it's much more easier to recognize issues as > part of a specific version, if the number of releases stays small enough. Bull. Easier to try one up or one down and see the issue present/gone and now we have a smaller commit range to evaluate. > I'd prefer to gather more fixes per release and go for a 6-8 week (or 4-6 > week) release cycle. And that needs a release manager who is happy to run with the required cadence. The release manager decides when to release... If they are causing too much work reviewing releases, they will fail to get enough PMC votes and this will self regulate. > IIRC that was also the original intention with M3. > > How did that work out for us? Lets try faster, as a plan of 6-8 weeks ended up as > 1 year A plan of 1-2 weeks on that basis will probably end up at about every 8-10 weeks ;-) Robert > > Op Sun, 28 Jul 2013 18:36:32 +0200 schreef Jason van Zyl : > > On Jul 28, 2013, at 12:25 PM, Hervé BOUTEMY >> wrote: >> >> I'd like to work on cd tonight >>> >>> so if you wait for tomorrow... >>> >>> >> I don't really want to wait, why can't that just go in next week? You >> don't know how long it will take and I think we should just start releasing >> what we have. >> >> notice there are 2 ITs failing on ASF's Jenkins because of a failure to >>> find >>> artifacts that are available AFAIK in the local repo: I suppose I'm >>> missing >>> something trivial in the configuration >>> Can you help me on this, please? >>> >> >> The ITs need to work, I till take a look at report back. >> >> >>> Regards, >>> >>> Hervé >>> >>> Le dimanche 28 juillet 2013 12:08:35 Jason van Zyl a écrit : >>> I'd like to release Maven 3.1.1 and try to get the cadence revived for minor version releases by trying to release minor versions as frequently as there are fixes to make available. Just a couple simple fixes: [MNG-5499] maven-aether-provider leaks Sisu Plexus and ObjectWeb classes onto the classpath when they are not required [MNG-5495] API incompatibility causes Swagger Maven Plugin (and others) to fail under Maven 3.1.0 But helps consumers of the Maven Aether Provider and plugin issues caused by incompatibilities with the converters. There are lots of other things to fix, but as they become available they can be released. If possible I'd just like to start releasing any fixes we have on a weekly basis. Any objections? Thanks, Jason --** Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --**--- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language >>> >>> --**--** >>> - >>> 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 >> --**--- >> >> 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 >> >> >> >> >> >> > ---
Strange handling of + in version portion of GAV
http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/build-monitor-plugin/1.0+build.14/ Has anyone noticed that we don't seem to be encoding the + character when mapping GAV to URL?
Re: Release Maven 3.1.1
And we haven't had the vote thread yet... so still time for rot13:froo to chime in again! On 29 July 2013 15:06, Baptiste MATHUS wrote: > 2013/7/29 Fred Cooke > > > On Mon, Jul 29, 2013 at 3:57 PM, Baptiste MATHUS wrote: > > > >> 2013/7/29 Fred Cooke > >> > >> > Tag deleted? :-/ > >> > > >> > >> Wasn't it already discussed? Are you going to endlessly send that same > >> email here? > >> > > > > No, I'm going to spice it up a little each time, just for you. > > > > Wrong reply I guess. >
Re: Rationale behind non-standard dependency scopes
I find the lure of the custom scopes to be a siren's call. There are maybe 2-3 "missing" scopes. all other needs are better addressed with a different project structure in my view. We have the separation between test and non-test... but test is an all or nothing... need the symmetry between the non-test scopes and the test scopes, e.g. compile -> test-compile runtime -> test-runtime I'd also want a "none" scope so that things like the maven dependency and assembly plugins can reference project dependencies without polluting compile classpaths. of course the real issue that the above masks is that unit tests should not be using such tricks... and integration tests should be in a separate module, but we need the integration tests failing to block the module that they are testing from being built. What is also needed is a way to signify architecturally specific artifacts, and also a way to signify that artifact A subsumes or provides an equivalent API to artifact B so that when A is on the classpath, B is automatically excluded from transitive dependencies. But what I'd really like to understand is what you think you need these custom scopes for... because perhaps I am being arrogant and assuming I have thought of all the valid use cases and you can show me the error of my thinking -Stephen On 30 July 2013 13:22, Francesco Mari wrote: > Hi, > > I was wondering why using custom dependency scopes issues a warning > when the POM model is validated. Why Maven just don't ignore dependecy > scopes he cannot understand? > > I was thinking to treat dependency scopes in a different way. The only > logic I've found about dependency scopes is in [1] and [2] (I'm pretty > sure there is more around), respectively how dependency scope > inheritance is computed and whether to import POM dependencies with > scope "import". > > Can this logic be encapsulated in a component which is able to track > other optional "dependency scope" components? Each "dependency scope" > component will define a new dependency scope and will encapsulate the > rules about it (i.e. what happens if a dependency of the given scope > is inherited, if it can be imported, and so on). > > An alternative and simpler solution could be that a "dependency scope" > component maps a custom dependency scope to one standard scope defined > by Maven, so to establish an "is-a" relationship between a custom > dependency scope and a standard one. > > What do you think? > > [1]: > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L351 > [2]: > https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L876 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Rationale behind non-standard dependency scopes
On 30 July 2013 14:23, Francesco Mari wrote: > I missed to describe my use case. I will try to do it as detailed as I > can, but it can be quite verbose. > > I have a project which is built by aggregating other artifacts with > different roles: runtime OSGi bundles, plain content, testing OSGi > bundles, integration testing modules. You can't build this project > with executions of existing plugins (trust me, we tried), so a new > plugin has been written to handle the corner cases of the packaging > required by the project. The project is usually deployed as a runnable > JAR file and a .properties file containing metadata which cannot be > contained in a POM file. > > The packaging plugin contains a LifecycleParticipant as an extension, > and dependencies are automatically added on the project depending on > the configuration of the plugin. As you can imagine, the code of the > LifecycleParticipant is messy, as it tries to scan projects, plugins > and configurations to figure out what to use as dependencies of the > project. This is done for two reasons. First, the project is inside an > aggregator with the bundles it depends on, so it must be built after > its dependencies are built. Second, we often inspect dependencies of > our projects using the Maven Dependency Plugin or the Versions Maven > Plugin and we would like to have tooling support. > > The pure and correct solution would be to duplicate the same > information I have in the configuration of the plugin and to copy it > in the dependencies section of the POM. This will satisfy my > requirements, but will make the configuration of the build too > verbose. > > If I had custom dependency scopes like "runtime-bundle", > "testing-bundle", "content", etc. I could be able to still use the > dependency mechanism of Maven, let Maven assemble the POM model as > usual, parse the configuration and configure my plugin, instead of > doing it in my LifecycleParticipant, which is tedious and error prone > (other than duplicated logic). I could write my plugin to scan the > dependencies for custom scopes, instead of relying on the > configuration only. > > Do you have better ideas for this problem? > > So really this is a question of build-time information. The "exported" transitive dependencies will fit neatly into the existing scopes, but you would like a simplified *build time* configuration? > 2013/7/30 Stephen Connolly : > > I find the lure of the custom scopes to be a siren's call. > > > > There are maybe 2-3 "missing" scopes. all other needs are better > addressed > > with a different project structure in my view. > > > > We have the separation between test and non-test... but test is an all or > > nothing... need the symmetry between the non-test scopes and the test > > scopes, e.g. > > > > compile -> test-compile > > runtime -> test-runtime > > > > I'd also want a "none" scope so that things like the maven dependency and > > assembly plugins can reference project dependencies without polluting > > compile classpaths. > > > > of course the real issue that the above masks is that unit tests should > not > > be using such tricks... and integration tests should be in a separate > > module, but we need the integration tests failing to block the module > that > > they are testing from being built. > > > > What is also needed is a way to signify architecturally specific > artifacts, > > and also a way to signify that artifact A subsumes or provides an > > equivalent API to artifact B so that when A is on the classpath, B is > > automatically excluded from transitive dependencies. > > > > But what I'd really like to understand is what you think you need these > > custom scopes for... because perhaps I am being arrogant and assuming I > > have thought of all the valid use cases and you can show me the error of > my > > thinking > > > > -Stephen > > > > > > On 30 July 2013 13:22, Francesco Mari wrote: > > > >> Hi, > >> > >> I was wondering why using custom dependency scopes issues a warning > >> when the POM model is validated. Why Maven just don't ignore dependecy > >> scopes he cannot understand? > >> > >> I was thinking to treat dependency scopes in a different way. The only > >> logic I've found about dependency scopes is in [1] and [2] (I'm pretty > >> sure there is more around), respectively how dependency scope > >> inheritance is computed and whether to import POM dependencies with > >> scope "
Re: Rationale behind non-standard dependency scopes
Yeah, I think that is probably something that will need to be addressed in a future pom format... something along the line of dependency attributes or markers that can then be used by specific plugins to pull out sections of dependencies. Scope should not be abused for what is really a marker question for plugins, IMHO On 30 July 2013 15:39, Francesco Mari wrote: > Correct. I don't want to duplicate the configuration twice, the first > time in my plugin and the second time in the section to > let Maven correctly compute the build plan. > > 2013/7/30 Stephen Connolly : > > On 30 July 2013 14:23, Francesco Mari wrote: > > > >> I missed to describe my use case. I will try to do it as detailed as I > >> can, but it can be quite verbose. > >> > >> I have a project which is built by aggregating other artifacts with > >> different roles: runtime OSGi bundles, plain content, testing OSGi > >> bundles, integration testing modules. You can't build this project > >> with executions of existing plugins (trust me, we tried), so a new > >> plugin has been written to handle the corner cases of the packaging > >> required by the project. The project is usually deployed as a runnable > >> JAR file and a .properties file containing metadata which cannot be > >> contained in a POM file. > >> > >> The packaging plugin contains a LifecycleParticipant as an extension, > >> and dependencies are automatically added on the project depending on > >> the configuration of the plugin. As you can imagine, the code of the > >> LifecycleParticipant is messy, as it tries to scan projects, plugins > >> and configurations to figure out what to use as dependencies of the > >> project. This is done for two reasons. First, the project is inside an > >> aggregator with the bundles it depends on, so it must be built after > >> its dependencies are built. Second, we often inspect dependencies of > >> our projects using the Maven Dependency Plugin or the Versions Maven > >> Plugin and we would like to have tooling support. > >> > >> The pure and correct solution would be to duplicate the same > >> information I have in the configuration of the plugin and to copy it > >> in the dependencies section of the POM. This will satisfy my > >> requirements, but will make the configuration of the build too > >> verbose. > >> > >> If I had custom dependency scopes like "runtime-bundle", > >> "testing-bundle", "content", etc. I could be able to still use the > >> dependency mechanism of Maven, let Maven assemble the POM model as > >> usual, parse the configuration and configure my plugin, instead of > >> doing it in my LifecycleParticipant, which is tedious and error prone > >> (other than duplicated logic). I could write my plugin to scan the > >> dependencies for custom scopes, instead of relying on the > >> configuration only. > >> > >> Do you have better ideas for this problem? > >> > >> > > So really this is a question of build-time information. The "exported" > > transitive dependencies will fit neatly into the existing scopes, but you > > would like a simplified *build time* configuration? > > > > > >> 2013/7/30 Stephen Connolly : > >> > I find the lure of the custom scopes to be a siren's call. > >> > > >> > There are maybe 2-3 "missing" scopes. all other needs are better > >> addressed > >> > with a different project structure in my view. > >> > > >> > We have the separation between test and non-test... but test is an > all or > >> > nothing... need the symmetry between the non-test scopes and the test > >> > scopes, e.g. > >> > > >> > compile -> test-compile > >> > runtime -> test-runtime > >> > > >> > I'd also want a "none" scope so that things like the maven dependency > and > >> > assembly plugins can reference project dependencies without polluting > >> > compile classpaths. > >> > > >> > of course the real issue that the above masks is that unit tests > should > >> not > >> > be using such tricks... and integration tests should be in a separate > >> > module, but we need the integration tests failing to block the module > >> that > >> > they are testing from being built. > >> > > >> > What is also needed is a way to signify archi
Re: $PROJECT_NAME - Build # $BUILD_NUMBER - $BUILD_STATUS
This looks to be https://builds.apache.org/job/maven-indexer going to Failed... somebody needs to fix the $DEFAULT_CONTENT in the editable email template as a token parse error is rendering email notification kind of useless On 31 July 2013 12:24, Apache Jenkins Server wrote: > The Apache Jenkins build system has built $PROJECT_NAME (build > #$BUILD_NUMBER) > > Status: $BUILD_STATUS > > Check console output at $BUILD_URL to view the results.
[DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
I have updated the project-roles with my thoughts resulting from the healthy debate on the list and some debates elsewhere. If anyone wants to look at the resulting Work In Progress document as a whole: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594&view=markup Thoughts? -Stephen -- Forwarded message -- From: Date: 2 August 2013 10:52 Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/ project-roles.md To: comm...@maven.apache.org Author: stephenc Date: Fri Aug 2 09:52:11 2013 New Revision: 1509594 URL: http://svn.apache.org/r1509594 Log: After a lengthy discussion on the users@maven list and some side discussions on members@apache, I think the following changes are more in line with what we should be seeking as responsibilities of the PMC. * Forks are not bad... letting changes stack up in the fork is bad but more from a 'it will be hard to review' point of view... similarly using a fork to get external contributions complicates the tracablity * We are not obligated to promote other ASF projects... but there should be a symmetry in how that lack of obligation plays out * I identified some more responsibilities of the PMC (if I have missed any, please add) * There is a special case where the PMC Chair can wear the dictators hat... but that is only in the case of unresolvable consensus and the lack of consensus is causing damage to the project and the board is well aware of the issue and expects the chair to put on the dictators hat (with the board watching on) As always, this is a Commit Then Review community... so these changes are being committed for review. Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1509594&r1=1509593&r2=1509594&view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Fri Aug 2 09:52:11 2013 @@ -174,11 +174,31 @@ are kept confidential. The Project Management Committee has the following responsibilities: -* Proposing active contributors for committership, -* Binding votes in project decisions, -* Voting on release artifacts, -* Ensure [Developers Conventions][5] are followed, or updated/improved if necessary, -* +* Active management of those projects identified by the resolution of the Board + of Directors of the Apache Foundation; +* Ensure the project remains a healthy top-level project of the Apache Foundation + (if a PMC member wants the project to be hosted elsewhere they should resign + from the PMC stating their reason - if the PMC shrinks beyond the minimal viable + size then as a result of a desire by the bulk of the PMC to move the project + elsewhere, the Board of the Apache Foundation will take that into account + when moving the project into the Foundation's Attic) +* Prepare reports as required by the Board of the Apache Foundation and + ensure those reports are ready for presentation by the PMC Chair in a timely + manner; +* Defend the trademarks belonging to the project; +* Proposing active contributors for committership; +* Ensure that votes in the community are used as a tool to establish consensus + and not a weapon to disenfranchise or alienate a minority of the community; +* Binding votes in project decisions; +* Ensure that code committed to the project is either committed under a valid CLA + or is code that was contributed with a clear indication that the Apache License + applied (i.e. small patches submitted to the issue tracker or to the mailing list + are assumed to be submitted with the intent of being covered by the Apache + License unless the submitter clearly marks those patches as not being covered) +* Ensure that third part dependencies shipped as part of the project's releases + are covered by a compatible license. +* Voting on release artifacts; +* Ensure [Developers Conventions][5] are followed, or updated/improved if necessary; Standards for Community Commitment @@ -186,22 +206,77 @@ In the spirit of supporting the health o Management Committee members refrain from actions that subvert the functioning of the committee itself. -First, Project Management Committee members should not maintain long-running -forks of Maven code outside of the project itself. Making significant -changes to Maven code outside of the project displays a lack of -investment in the community. Additionally, attempting to re-integrate -a large number of code changes in bulk overwhelms the ability of -volunteers in the community to review (and potentially veto) the -changes. This effectively thwarts the policing function of the -PMC. - -Second, Project Management Committee members should not divert -work on redesigning,
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
On 2 August 2013 16:07, Brian Fox wrote: > I think the bulk of this is pretty good. On the fork section, specifically: > > " > As soon as changes in that > fork are identified which should be brought back to the project those > changes should be introduced into at least a branch hosted on the Apache > Maven > source control in order to facilitate the easier review by the community. > > The PMC should encourage by example the early committing of changes from a > fork back to Apache Maven source control. > " > > This seems to want to compel code to be brought back as a > responsibility, I don't think we need to spell that out. This is why I say "as soon as ... are identified" The wording could be clearer... if somebody can figure out a better way to say it. Basically, as soon as you say something like... "Oh commit 1a2b3d4e, we really need to get that into Maven itself, it's too good to be in our fork"... you should be trying to hasten getting that commit into Maven itself and if you are on the PMC and one of your commits is one that you say this of... you should just commit it back. Until you realise that a commit is one that you want to push to Maven, hey it's your work... whatever... but as soon as you identify the change as being one that should be at Maven, as a PMC member you are expected to try and get it into Maven quickly so that others working on the fork see that this is the example by which the PMC leads. If you can think of a clearer way to express that than my wording (which since you are not getting my intended meaning must therefore be lacking) please update. The section > about the downsides to not doing so and attempting to do it later is > really the core of the concerns... the extra diligence required to > consume large bodies of work is bigger. That doesn't mean that code > contributions are inherently bad just because they were developed > elsewhere, it's just harder to pull in. > Correct. > > On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly > wrote: > > I have updated the project-roles with my thoughts resulting from the > > healthy debate on the list and some debates elsewhere. > > > > If anyone wants to look at the resulting Work In Progress document as a > > whole: > > > http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594&view=markup > > > > Thoughts? > > > > -Stephen > > > > -- Forwarded message -- > > From: > > Date: 2 August 2013 10:52 > > Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/ > > project-roles.md > > To: comm...@maven.apache.org > > > > > > Author: stephenc > > Date: Fri Aug 2 09:52:11 2013 > > New Revision: 1509594 > > > > URL: http://svn.apache.org/r1509594 > > Log: > > After a lengthy discussion on the users@maven list and some > > side discussions on members@apache, I think the following changes > > are more in line with what we should be seeking as responsibilities > > of the PMC. > > > > * Forks are not bad... letting changes stack up in the fork is bad > > but more from a 'it will be hard to review' point of view... > > similarly using a fork to get external contributions complicates > > the tracablity > > > > * We are not obligated to promote other ASF projects... but there > > should be a symmetry in how that lack of obligation plays out > > > > * I identified some more responsibilities of the PMC (if I have missed > > any, please add) > > > > * There is a special case where the PMC Chair can wear the dictators > > hat... but that is only in the case of unresolvable consensus > > and the lack of consensus is causing damage to the project > > and the board is well aware of the issue and expects the chair > > to put on the dictators hat (with the board watching on) > > > > As always, this is a Commit Then Review community... so these > > changes are being committed for review. > > > > Modified: > > maven/site/trunk/content/markdown/project-roles.md > > > > Modified: maven/site/trunk/content/markdown/project-roles.md > > URL: > > > http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1509594&r1=1509593&r2=1509594&view=diff > > > == > > --- maven/site/trunk/content/markdown/project-roles.md (original) > > +++ maven/site/trunk/content/markdown/project-roles.md Fri Aug 2 > 09:52:11 > > 2013 > > @@ -174,11 +174,31
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
On 2 August 2013 16:08, Curtis Rueden wrote: > Hi Stephen, > > > If anyone wants to look at the resulting Work In Progress document as > > a whole: > > > > http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594&view=markup > > > > Thoughts? > > Big thumbs up to all your changes. Nice work. > > Some brief comments from a technical perspective: > > > It is self evident that the opportunity for review is much greater if > > the code is committed to the project's source control as early as > > possible. Similarly small commits are easier to review than large > > commits. > > Technologies like GitHub and Gerrit are making code review extremely easy > these days. I am not sure what tools Apache projects use for code review, > but in the interest of facilitating such review, I definitely believe that > going with the best available *technical* option(s) makes sense, regardless > of whether the tool itself is an Apache project. Use what works. > Unfortunately the review must be of what lands at Apache servers. It could be a bare bones review because the bulk of the review happened elsewhere, but there must still be eyes on the code when it lands at Apache at least that is my understanding. > > The old text said: "there is a danger here of falling into a Not Invented > Here mentality" and I couldn't agree more. The new language is much better, > which clearly warns of the consequences of long-running forks while also > stating that they may sometimes be useful and/or appropriate. > > > GIT commits can be squashed and history re-written to mask or > > otherwise hide the source of contributions. > > True, and it is good to warn about this. However, ultimately I think Git is > a better choice (than SVN) because it often makes code review much easier. > SVN history can be rewritten if you have admin access to the Subversion server... SVN revision properties can be edited to, e.g. change author or commit message, etc. This is not just a GIT issue, this is a "not happening at Apache hardware" issue... when it happens at Apache hardware, we can be more lax about probing for those kind of issues as we have the excuse that we rely on infra to put in place the controls to ensure the required traceability... when it happens on 3rd party controlled hardware, we don't have that option, so the review needs to be more strict. > If a new feature is properly developed on a topic branch with commits > squashed, rewritten and organized as needed, the history can be laid out in > a very easy-to-understand manner: new features and bugfixes done in > properly isolated commits, unit tests added immediately thereafter, etc. If > a commit is too large or conflates many different changes, Git provides the > tools to split up that work for rereview. > Yes, and I don't think anyone was suggesting we move away from GIT... if anything we are migrating our repositories from Subversion to GIT because it is the better tool. > > Again, thanks for writing this. The new words give me more confidence that > Apache has the community's best interest at heart, rather than only "Apache > for Apache's sake." > Keep in mind that there will always be some things that we need to do in slightly strange ways because we need to maintain the legal protection that the foundation provides for Committers... but keep in mind that none of us enjoy that!!! > > Regards, > Curtis > > P.S. For those interested, Stephen's changes are more clear when reading > the side-by-side diff: > > http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?r1=1507630&r2=1509594&diff_format=h > > > On Fri, Aug 2, 2013 at 4:59 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > I have updated the project-roles with my thoughts resulting from the > > healthy debate on the list and some debates elsewhere. > > > > If anyone wants to look at the resulting Work In Progress document as a > > whole: > > > > > http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594&view=markup > > > > Thoughts? > > > > -Stephen > > > > -- Forwarded message -- > > From: > > Date: 2 August 2013 10:52 > > Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/ > > project-roles.md > > To: comm...@maven.apache.org > > > > > > Author: stephenc > > Date: Fri Aug 2 09:52:11 2013 > > New Revision: 1509594 > > > > URL: http://svn.apache.org/r1509594 > > Log: > > After a lengthy discus
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
On 2 August 2013 16:32, Paul Benedict wrote: > Furthermore, I'd like to see explicit procedural rules on Maven Core and > forking. For example, if there's a critical component needing development > for Core, and a PMC expresses that such development will be done outside of > Apache and then used as a dependency, shouldn't there be a vote on that? > Votes should be a tool to confirm consensus... not an iron hand. If the consensus of the developers is to use the dependency which is external to the project, then that is fine. If there is no consensus then the dependency will not be introduced. We already have a policy that adding Category B dependencies to Core requires approval of the PMC, I don't see that there is much value in adding even more to this document... but if you can suggest a patch and people agree with it... -Stephen
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
We cannot stop somebody from developing something outside of Apache. So I could go off and write a High Performance Logging API... now I could be doing that because I want to foist that Logging API on Maven... or I could be doing it as an experiment that, if successful, I may offer for Maven to consume... or I could be doing it because I need it for my Day Job... We cannot know the reasons why somebody is doing something outside of Maven... we can ask, but we cannot *know* if the answer we are given is truthful. So anyway, I now have this ultra whizzbang high performance logging API and I am aware of some deficit in the logging performance of Maven, so I spin up a private fork (it could be a hidden private fork, or it could be a public one... doesn't matter) and integrate the logging API and low and behold I see a whopping X% improvement... so I want to bring that back to Maven... Is there anything wrong with the above? If the library I created is under a Category A license and open source and I go with CTR and nobody vetos my commit... we have consensus... why do we need to go all Iron Fist and require a vote? We already have established tools: review of commits, vetos on commits, mandatory votes for Category B dependencies... Do we really need *more* processes and procedures to follow? On 2 August 2013 16:51, Paul Benedict wrote: > I don't understand the iron hand analogy. I was expressing the use of a > vote to allow or disallow critical development outside of Apache. The vote > would lead to a consensus, no? > > > On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On 2 August 2013 16:32, Paul Benedict wrote: > > > > > Furthermore, I'd like to see explicit procedural rules on Maven Core > and > > > forking. For example, if there's a critical component needing > development > > > for Core, and a PMC expresses that such development will be done > outside > > of > > > Apache and then used as a dependency, shouldn't there be a vote on > that? > > > > > > > Votes should be a tool to confirm consensus... not an iron hand. > > > > If the consensus of the developers is to use the dependency which is > > external to the project, then that is fine. If there is no consensus then > > the dependency will not be introduced. > > > > We already have a policy that adding Category B dependencies to Core > > requires approval of the PMC, I don't see that there is much value in > > adding even more to this document... but if you can suggest a patch and > > people agree with it... > > > > -Stephen > > > > > > -- > Cheers, > Paul >
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Correct. And it would be subject to the same CTR and potential veto if Cat A. If Cat B and being added to core then you'd have a mandatory vote by the PMC where the majority *of the whole PMC* are required to approve. The rational being, a Cat A licensed dependency can always be forked into Maven if we need to. On Friday, 2 August 2013, Igor Fedorenko wrote: > Is this really specific to PMC? Can't a regular developer like myself do > the same, i.e. setup a project elsewhere, then commit to > maven core? > > -- > Regards, > Igor > > On 2013-08-02 8:29 PM, Paul Benedict wrote: > > I've stated from the beginning of this thread that it's impossible to > prevent someone from developing outside of Apache. I stand by that still. > That can't be prevented and any attempt will fail since it's not practical. > > If my words today aren't clear, I'll try again. My stance isn't about > halting developing elsewhere, but to halt what I (and maybe some others) > perceive as a way of getting around the Apache community. > > I won't use your "ultra whizzbang high performance logging" :-) example > because it doesn't fit what my concern; but imagine an existing component > (I won't name any) that is critical and Maven's existence and Maven can't > function without it. It's very easy for any PMC member to go to another OSS > community, develop it, and then kind of leave the other PMCs with no real > "choice" but to use it because the code realizes the future of Maven. Those > other PMCs are really backed into a corner; they have no real recourse to > preventing this, lest Maven development is simply halted altogether. The > other OSS community has other committers, other mailing lists, other > deliberations, etc. Community work and input becomes marginalized here. > > Does this make sense to you? That kind of community-splitting effort needs > to stop and that's what I am trying to address. > > Cheers, > Paul > > > > On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > We cannot stop somebody from developing something outside of Apache. > > So I could go off and write a High Performance Logging API... now I could > be doing that because I want to foist that Logging API on Maven... or I > could be doing it as an experiment that, if successful, I may offer for > Maven to consume... or I could be doing it because I need it for my Day > Job... > > We cannot know the reasons why somebody is doing something outside of > Maven... we can ask, but we cannot *know* if the answer we are given is > truthful. > > So anyway, I now have this ultra whizzbang high performance logging API and > I am aware of some deficit in the logging performance of Maven, so I spin > up a private fork (it could be a hidden private fork, or it could be a > public one... doesn't matter) and integrate the logging API and low and > behold I see a whopping X% improvement... so I want to bring that back to > Maven... > > Is there anything wrong with the above? > > If the library I created is under a Category A license and open source and > I go with CTR and nobody vetos my commit... we have consensus... why do we > need to go all Iron Fist and require a vote? > > We already have established tools: review of commits, vetos on commits, > mandatory votes for Category B dependencies... > > Do we really need *more* processes and procedures to follow? > > On 2 August 2013 16:51, Paul Benedict wrote: > > I don't understand the iron hand analogy. I was expressing the use of a > vote to allow or disallow critical development outside of Apache. The > > vote > > would lead to a consensus, no? > > > On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > On 2 August 2013 16:32, Paul Benedict wrote: > > Furthermore, I'd like to see explicit procedural rules on Maven Core > > and > > forking. For example, if there's a critical component needing > > development > > for Core, and a PMC expresses that such development will be done > > outside > > of > > --**--**- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Google: Apache third party licenses Should work on lucky... Or look at the head revision where I added the link. There is a 3rd category: Category X... Eg GPL, which we are not allowed to use On Friday, 2 August 2013, Fred Cooke wrote: > Are definitions of cat A and B and others listed anywhere? I searched but > failed. > > I assume Cat A = permissive and Cat B = copyleft? or? > > On Fri, Aug 2, 2013 at 6:54 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > Correct. And it would be subject to the same CTR and potential veto if > Cat > > A. If Cat B and being added to core then you'd have a mandatory vote by > the > > PMC where the majority *of the whole PMC* are required to approve. > > > > The rational being, a Cat A licensed dependency can always be forked into > > Maven if we need to. > > > > On Friday, 2 August 2013, Igor Fedorenko wrote: > > > > > Is this really specific to PMC? Can't a regular developer like myself > do > > > the same, i.e. setup a project elsewhere, then commit to > > > maven core? > > > > > > -- > > > Regards, > > > Igor > > > > > > On 2013-08-02 8:29 PM, Paul Benedict wrote: > > > > > > I've stated from the beginning of this thread that it's impossible to > > > prevent someone from developing outside of Apache. I stand by that > still. > > > That can't be prevented and any attempt will fail since it's not > > practical. > > > > > > If my words today aren't clear, I'll try again. My stance isn't about > > > halting developing elsewhere, but to halt what I (and maybe some > others) > > > perceive as a way of getting around the Apache community. > > > > > > I won't use your "ultra whizzbang high performance logging" :-) example > > > because it doesn't fit what my concern; but imagine an existing > component > > > (I won't name any) that is critical and Maven's existence and Maven > can't > > > function without it. It's very easy for any PMC member to go to another > > OSS > > > community, develop it, and then kind of leave the other PMCs with no > real > > > "choice" but to use it because the code realizes the future of Maven. > > Those > > > other PMCs are really backed into a corner; they have no real recourse > to > > > preventing this, lest Maven development is simply halted altogether. > The > > > other OSS community has other committers, other mailing lists, other > > > deliberations, etc. Community work and input becomes marginalized here. > > > > > > Does this make sense to you? That kind of community-splitting effort > > needs > > > to stop and that's what I am trying to address. > > > > > > Cheers, > > > Paul > > > > > > > > > > > > On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly < > > > stephen.alan.conno...@gmail.com> wrote: > > > > > > We cannot stop somebody from developing something outside of Apache. > > > > > > So I could go off and write a High Performance Logging API... now I > could > > > be doing that because I want to foist that Logging API on Maven... or I > > > could be doing it as an experiment that, if successful, I may offer for > > > Maven to consume... or I could be doing it because I need it for my Day > > > Job... > > > > > > We cannot know the reasons why somebody is doing something outside of > > > Maven... we can ask, but we cannot *know* if the answer we are given is > > > truthful. > > > > > > So anyway, I now have this ultra whizzbang high performance logging API > > and > > > I am aware of some deficit in the logging performance of Maven, so I > spin > > > up a private fork (it could be a hidden private fork, or it could be a > > > public one... doesn't matter) and integrate the logging API and low and > > > behold I see a whopping X% improvement... so I want to bring that back > to > > > Maven... > > > > > > Is there anything wrong with the above? > > > > > > If the library I created is under a Category A license and open source > > and > > > I go with CTR and nobody vetos my commit... we have consensus... why do > > we > > > need to go all Iron Fist and require a vote? > > > > > > We already have established tools: review of commits, vetos on commits, > > > mandatory votes for Category B dependencies... > > > > > > Do we really need *more* processes and procedures to follow? > > > > > > On 2 August 2013 16:51, Paul Benedict wrote: > > > > > > I don't under> > > --**--**- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > -- > > Sent from my phone > > > -- Sent from my phone
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Brian, Did you have any suggested changes to the forks section wording to clear up my intent for that section? I'd like to start wrapping this up and move towards making it "official" Everyone else, Time to shout out if you have any issues / suggested improvements on the content - Stephen On Friday, 2 August 2013, Stephen Connolly wrote: > On 2 August 2013 16:07, Brian Fox 'cvml', 'bri...@infinity.nu');>> wrote: > >> I think the bulk of this is pretty good. On the fork section, >> specifically: >> >> " >> As soon as changes in that >> fork are identified which should be brought back to the project those >> changes should be introduced into at least a branch hosted on the Apache >> Maven >> source control in order to facilitate the easier review by the community. >> >> The PMC should encourage by example the early committing of changes from a >> fork back to Apache Maven source control. >> " >> >> This seems to want to compel code to be brought back as a >> responsibility, I don't think we need to spell that out. > > > This is why I say "as soon as ... are identified" > > The wording could be clearer... if somebody can figure out a better way to > say it. > > Basically, as soon as you say something like... "Oh commit 1a2b3d4e, we > really need to get that into Maven itself, it's too good to be in our > fork"... you should be trying to hasten getting that commit into Maven > itself and if you are on the PMC and one of your commits is one that > you say this of... you should just commit it back. > > Until you realise that a commit is one that you want to push to Maven, hey > it's your work... whatever... but as soon as you identify the change as > being one that should be at Maven, as a PMC member you are expected to try > and get it into Maven quickly so that others working on the fork see that > this is the example by which the PMC leads. > > If you can think of a clearer way to express that than my wording (which > since you are not getting my intended meaning must therefore be lacking) > please update. > > The section >> about the downsides to not doing so and attempting to do it later is >> really the core of the concerns... the extra diligence required to >> consume large bodies of work is bigger. That doesn't mean that code >> contributions are inherently bad just because they were developed >> elsewhere, it's just harder to pull in. >> > > Correct. > > > > On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly > wrote: > > I have updated the project-roles with my thoughts resulting from the > > healthy debate on the list and some debates elsewhere. > > > > If anyone wants to look at the resulting Work In Progress document as a > > whole: > > > http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594&view=markup > > > > Thoughts? > > > > -Stephen > > > > -- Forwarded message -- > > From: > > Date: 2 August 2013 10:52 > > Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/ > > project-roles.md > > To: comm...@maven.apache.org > > > > > > Author: stephenc > > Date: Fri Aug 2 09:52:11 2013 > > New Revision: 1509594 > > > > URL: http://svn.apache.org/r1509594 > > Log: > > After a lengthy discussion on the users@maven list and some > > side discussions on members@apache, I think the following changes > > are more in line with what we should be seeking as responsibilities > > of the PMC. > > > > * Forks are not bad... letting changes stack up in the fork is bad > > but more from a 'it will be hard to review' point of view... > > similarly using a fork to get external contributions complicates > > the tracablity > > > > * We are not obligated to promote other ASF projects... but there > > should be a symmetry in how that lack of obligation plays out > > > > * I identified some > > > -- Sent from my phone
Re: maven-scm-provider-jgit
On 8 August 2013 02:12, Olivier Lamy wrote: > mvn clean install -pl :maven-scm-provider-jgit -am works on my mac
Re: svn access
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html On 8 August 2013 01:37, Jigar Joshi wrote: > I want to check in some code in maven > > How can I have svn access > > Thanks! > Jigar >
Re: [VOTE] Release Apache Maven Mapping version 1.0
+1 On 11 August 2013 00:09, Dennis Lundberg wrote: > Hi, > > This is a new shared component consisting of code from Maven WAR > Plugin, that has been repackaged for reuse by other plugins. > > We solved 1 issues: > > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleName=Html&version=19526 > > There no issues left in JIRA: > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11761&component=16150&status=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-083/ > > https://repository.apache.org/content/repositories/maven-083/org/apache/maven/shared/maven-mapping/1.0/maven-mapping-1.0-source-release.zip > > Staging site: > http://maven.apache.org/shared-archives/maven-mapping-1.0/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Dennis Lundberg > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven Model Converter version 2.3
On 14 August 2013 09:47, sebb wrote: > On 13 August 2013 18:58, Dennis Lundberg wrote: > > On Tue, Aug 13, 2013 at 12:30 AM, sebb wrote: > >> On 12 August 2013 20:10, Jason van Zyl wrote: > >>> > > > > I have now read the threads that are referring to, and have not found > > a single link to any ASF rule stating that we need to include these > > things in a VOTE thread. > > So how do you propose that reviewers check the provenance of the files > in the source release? > >>> > >>> Are you looking for files that are in a distribution that didn't come > from source control? Everything else as far as provenance goes is covered. > Errant content is a potential problem, but everything in a distribution > should come from source control which no one has access to until they have > a signed CLA on file. > >> > >> Yes. That is where the whole saga started. > >> > >> Proving provenance is why the SCM coordinates are needed for the vote. > >> > >> The SCM details may also be useful to discover files accidentally > >> omitted from the source archive. > > > > You want to compare the contents of the *-source-release.zip with > > something from SCM, to make nothing bad has crept into the source > > bundle. So you need to know where in SCM you can find it. Have I > > understood you correctly? > > It's vital to be able to link the files in the source release > archive(s) to their origin in SCM. > Simply not true. It is a nice convenience for somebody tracing the provenance of files in a source release, but it is by no means vital. > > The provenance of any source files the ASF releases must be clearly > traceable. > Being able to link the files in the source release archive(s) to their origin in SCM is certainly one way to make the provenance of source files the ASF releases easily traceable, but there is *no* foundation requirement for such. As I understand it, we *could*, as a project, decide to abandon SCM entirely for some specific module - something I would be strongly against - and we would be within our rights to do so. All that the foundation requires is that the PMC have verified the provenance of the files in the source releases they vote on. If you feel that individual members of the PMC are voting without having taken their required due diligence into account then I suggest you take that up with those individual members. -Stephen > > >>> Thanks, > >>> > >>> Jason > >>> > >>> -- > >>> Jason van Zyl > >>> Founder, Apache Maven > >>> http://twitter.com/jvanzyl > >>> - > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> - > >> 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 > >
