Re: Update on ASF Release requirements
This particular assembly descriptor is a one-time case for the assembly plugin only. It's not the one that Brian was talking about, since that one will have to be much more generalized to handle the variability of other projects. In this case, I know that the build directory for the assembly plugin is 'target' so there's no danger here. The descriptor isn't included in the binary artifact, so we should be fine. -john Barrie Treloar wrote: On Sat, Jun 13, 2009 at 7:40 AM, Barrie Treloarbaerr...@gmail.com wrote: On Sat, Jun 13, 2009 at 7:21 AM, Barrie Treloarbaerr...@gmail.com wrote: On Sat, Jun 13, 2009 at 12:04 AM, John Caseyjdca...@commonjava.org wrote: Is this still happening with maven-assembly-plugin 2.2-beta-4? It was 2.2-beta-2, I'll check -4 2.2-beta-4 behaves correctly. http://svn.apache.org/repos/asf/maven/plugins/branches/maven-assembly-plugin-2.2-beta-4/src/main/assembly/source-release.xml uses ${project.build.directory} except in the excludes block: excludes exclude*.log/exclude excludetarget/**/exclude /excludes I tried excludes exclude*.log/exclude exclude${project.build.directory}/**/exclude and it correctly gets replaced with target. - 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: Update on ASF Release requirements
Is this still happening with maven-assembly-plugin 2.2-beta-4? Barrie Treloar wrote: On Fri, Jun 12, 2009 at 12:11 AM, John Caseyjdca...@commonjava.org wrote: I had to include these files for the recent maven-assembly-plugin release. It was fairly simple, just take a look at this: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin/src/main/assembly/source-release.xml Be aware than under Maven 2.0.9 and windows that I had to use hard coded paths. Interpolated values did not get replaced correctly (i.e. the paths were \a\windows\path instead of a Java path and therefore replacements are failing) See http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin/src/assemble/source-release.xml - 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: Update on ASF Release requirements
On Sat, Jun 13, 2009 at 12:04 AM, John Caseyjdca...@commonjava.org wrote: Is this still happening with maven-assembly-plugin 2.2-beta-4? It was 2.2-beta-2, I'll check -4 Barrie Treloar wrote: On Fri, Jun 12, 2009 at 12:11 AM, John Caseyjdca...@commonjava.org wrote: I had to include these files for the recent maven-assembly-plugin release. It was fairly simple, just take a look at this: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin/src/main/assembly/source-release.xml Be aware than under Maven 2.0.9 and windows that I had to use hard coded paths. Interpolated values did not get replaced correctly (i.e. the paths were \a\windows\path instead of a Java path and therefore replacements are failing) See http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin/src/assemble/source-release.xml - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
On Sat, Jun 13, 2009 at 7:21 AM, Barrie Treloarbaerr...@gmail.com wrote: On Sat, Jun 13, 2009 at 12:04 AM, John Caseyjdca...@commonjava.org wrote: Is this still happening with maven-assembly-plugin 2.2-beta-4? It was 2.2-beta-2, I'll check -4 2.2-beta-4 behaves correctly. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
On Sat, Jun 13, 2009 at 7:40 AM, Barrie Treloarbaerr...@gmail.com wrote: On Sat, Jun 13, 2009 at 7:21 AM, Barrie Treloarbaerr...@gmail.com wrote: On Sat, Jun 13, 2009 at 12:04 AM, John Caseyjdca...@commonjava.org wrote: Is this still happening with maven-assembly-plugin 2.2-beta-4? It was 2.2-beta-2, I'll check -4 2.2-beta-4 behaves correctly. http://svn.apache.org/repos/asf/maven/plugins/branches/maven-assembly-plugin-2.2-beta-4/src/main/assembly/source-release.xml uses ${project.build.directory} except in the excludes block: excludes exclude*.log/exclude excludetarget/**/exclude /excludes I tried excludes exclude*.log/exclude exclude${project.build.directory}/**/exclude and it correctly gets replaced with target. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
On Thu, Jun 11, 2009 at 4:22 AM, David Jencksdavid_jen...@yahoo.com wrote: On Jun 10, 2009, at 6:59 PM, Brian Fox wrote: Update: The new assembly plugin and the regex in the source bundle seem to be working great. I have just one thing to resolve that I had previously overlooked: The source archive must also contain license and notice files, even if svn doesn't. I don't have the quote handy but Roy stated pretty clearly that expected checkout roots are sufficiently distribution-like to be required to have LICENSE and NOTICE files in svn. I don't recall anything like that, in fact I understood the opposite, that the svn roots are not sufficient to be source releases. If that's the case, they can't be considered distributions and thus don't fall under the license and notice requirements. So I think that verifying that the LICENSE and NOTICE files are there is enough, you don't need to add them. thanks david jencks I need to understand better the default resource bundle processing and how to pull the right pieces together into the assembly. Otherwise we are pretty close to getting all this staged and released. --Brian On Thu, Jun 4, 2009 at 5:50 PM, Brian Foxbri...@infinity.nu wrote: Just to bring the thread back up in light of the recent discussions of plugin releases: John has taken over the assembly release that contains the fix I put in for the ASF stuff. I've been travelling a lot the past two weeks and haven't progressed much on the poms. Tomorrow or monday I should have time to take the latest assembly stage and get the apache assembly descriptor and all the poms updated and tested out. Note that the work we are doing here is to make it easier to define this for all maven (and later asf) projects and be inherited correctly. This does not mean that all pending releases must be blocked waiting for these changes. You can make a source release quite easily with the existing plugin versions. It's also worth nothing that now we know about the requirement, we must have a source release, ignoring the requirement simply because we didn't know it was a requirement in the past isn't an option. On Wed, May 27, 2009 at 12:49 PM, Brian Fox bri...@infinity.nu wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey jdca...@commonjava.org wrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter br...@apache.org wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
I had to include these files for the recent maven-assembly-plugin release. It was fairly simple, just take a look at this: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin/src/main/assembly/source-release.xml -john Brian Fox wrote: Update: The new assembly plugin and the regex in the source bundle seem to be working great. I have just one thing to resolve that I had previously overlooked: The source archive must also contain license and notice files, even if svn doesn't. I need to understand better the default resource bundle processing and how to pull the right pieces together into the assembly. Otherwise we are pretty close to getting all this staged and released. --Brian On Thu, Jun 4, 2009 at 5:50 PM, Brian Foxbri...@infinity.nu wrote: Just to bring the thread back up in light of the recent discussions of plugin releases: John has taken over the assembly release that contains the fix I put in for the ASF stuff. I've been travelling a lot the past two weeks and haven't progressed much on the poms. Tomorrow or monday I should have time to take the latest assembly stage and get the apache assembly descriptor and all the poms updated and tested out. Note that the work we are doing here is to make it easier to define this for all maven (and later asf) projects and be inherited correctly. This does not mean that all pending releases must be blocked waiting for these changes. You can make a source release quite easily with the existing plugin versions. It's also worth nothing that now we know about the requirement, we must have a source release, ignoring the requirement simply because we didn't know it was a requirement in the past isn't an option. On Wed, May 27, 2009 at 12:49 PM, Brian Fox bri...@infinity.nu wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey jdca...@commonjava.org wrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter br...@apache.org wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - 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: Update on ASF Release requirements
On Jun 11, 2009, at 4:52 AM, Brian Fox wrote: On Thu, Jun 11, 2009 at 4:22 AM, David Jencksdavid_jen...@yahoo.com wrote: On Jun 10, 2009, at 6:59 PM, Brian Fox wrote: Update: The new assembly plugin and the regex in the source bundle seem to be working great. I have just one thing to resolve that I had previously overlooked: The source archive must also contain license and notice files, even if svn doesn't. I don't have the quote handy but Roy stated pretty clearly that expected checkout roots are sufficiently distribution-like to be required to have LICENSE and NOTICE files in svn. I don't recall anything like that, in fact I understood the opposite, that the svn roots are not sufficient to be source releases. If that's the case, they can't be considered distributions and thus don't fall under the license and notice requirements. There's a very long thread in jan 2008 I'm not a master of mail archives but it's here http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/thread LICENSE and NOTICE files and SVN and a particularly relevant post http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3ce9d17d5f-3a68-4968-ab26-49586d558...@gbiv.com%3e - Maybe you could point to some documentation that makes your point that the Apache svn repository is itself a distribution subject to LICENSE and NOTICE requirements. The NOTICE file exists to fulfill our obligations under our license and the licenses of any third-party code that we redistribute. We try to be as proactive about that as possible. The NOTICE is in subversion because the board added a notice that all of our projects must carry. It needs to be in subversion when a third-party something that requires such a notice is also within subversion. Finally, each release package's NOTICE must reflect all of the required notices of all of the parts within that package. - Given this I think it's more in line with apache policy to fail if the LICENSE/NOTICE files are missing than to try to guess at what should be in and add them. thanks david jencks So I think that verifying that the LICENSE and NOTICE files are there is enough, you don't need to add them. thanks david jencks I need to understand better the default resource bundle processing and how to pull the right pieces together into the assembly. Otherwise we are pretty close to getting all this staged and released. --Brian On Thu, Jun 4, 2009 at 5:50 PM, Brian Foxbri...@infinity.nu wrote: Just to bring the thread back up in light of the recent discussions of plugin releases: John has taken over the assembly release that contains the fix I put in for the ASF stuff. I've been travelling a lot the past two weeks and haven't progressed much on the poms. Tomorrow or monday I should have time to take the latest assembly stage and get the apache assembly descriptor and all the poms updated and tested out. Note that the work we are doing here is to make it easier to define this for all maven (and later asf) projects and be inherited correctly. This does not mean that all pending releases must be blocked waiting for these changes. You can make a source release quite easily with the existing plugin versions. It's also worth nothing that now we know about the requirement, we must have a source release, ignoring the requirement simply because we didn't know it was a requirement in the past isn't an option. On Wed, May 27, 2009 at 12:49 PM, Brian Fox bri...@infinity.nu wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey jdca...@commonjava.org wrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter br...@apache.org wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
Well, I'm not sure what to say about that. I guess I could say if it's not on the release docs, it's not policy? It's a little frustrating to constantly chase a standard that isn't documented and which there are many opinions of. I'll solve this particular problem of the source release for now. I haven't built up the motivation to open yet another open ended discussion to get something agreed upon after the last fiasco to be honest. On Thu, Jun 11, 2009 at 12:56 PM, David Jencksdavid_jen...@yahoo.com wrote: On Jun 11, 2009, at 4:52 AM, Brian Fox wrote: On Thu, Jun 11, 2009 at 4:22 AM, David Jencksdavid_jen...@yahoo.com wrote: On Jun 10, 2009, at 6:59 PM, Brian Fox wrote: Update: The new assembly plugin and the regex in the source bundle seem to be working great. I have just one thing to resolve that I had previously overlooked: The source archive must also contain license and notice files, even if svn doesn't. I don't have the quote handy but Roy stated pretty clearly that expected checkout roots are sufficiently distribution-like to be required to have LICENSE and NOTICE files in svn. I don't recall anything like that, in fact I understood the opposite, that the svn roots are not sufficient to be source releases. If that's the case, they can't be considered distributions and thus don't fall under the license and notice requirements. There's a very long thread in jan 2008 I'm not a master of mail archives but it's here http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/thread LICENSE and NOTICE files and SVN and a particularly relevant post http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3ce9d17d5f-3a68-4968-ab26-49586d558...@gbiv.com%3e - Maybe you could point to some documentation that makes your point that the Apache svn repository is itself a distribution subject to LICENSE and NOTICE requirements. The NOTICE file exists to fulfill our obligations under our license and the licenses of any third-party code that we redistribute. We try to be as proactive about that as possible. The NOTICE is in subversion because the board added a notice that all of our projects must carry. It needs to be in subversion when a third-party something that requires such a notice is also within subversion. Finally, each release package's NOTICE must reflect all of the required notices of all of the parts within that package. - Given this I think it's more in line with apache policy to fail if the LICENSE/NOTICE files are missing than to try to guess at what should be in and add them. thanks david jencks So I think that verifying that the LICENSE and NOTICE files are there is enough, you don't need to add them. thanks david jencks I need to understand better the default resource bundle processing and how to pull the right pieces together into the assembly. Otherwise we are pretty close to getting all this staged and released. --Brian On Thu, Jun 4, 2009 at 5:50 PM, Brian Foxbri...@infinity.nu wrote: Just to bring the thread back up in light of the recent discussions of plugin releases: John has taken over the assembly release that contains the fix I put in for the ASF stuff. I've been travelling a lot the past two weeks and haven't progressed much on the poms. Tomorrow or monday I should have time to take the latest assembly stage and get the apache assembly descriptor and all the poms updated and tested out. Note that the work we are doing here is to make it easier to define this for all maven (and later asf) projects and be inherited correctly. This does not mean that all pending releases must be blocked waiting for these changes. You can make a source release quite easily with the existing plugin versions. It's also worth nothing that now we know about the requirement, we must have a source release, ignoring the requirement simply because we didn't know it was a requirement in the past isn't an option. On Wed, May 27, 2009 at 12:49 PM, Brian Fox bri...@infinity.nu wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey jdca...@commonjava.org wrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter br...@apache.org wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
On Jun 11, 2009, at 9:56 AM, David Jencks wrote: On Jun 11, 2009, at 4:52 AM, Brian Fox wrote: On Thu, Jun 11, 2009 at 4:22 AM, David Jencksdavid_jen...@yahoo.com wrote: On Jun 10, 2009, at 6:59 PM, Brian Fox wrote: Update: The new assembly plugin and the regex in the source bundle seem to be working great. I have just one thing to resolve that I had previously overlooked: The source archive must also contain license and notice files, even if svn doesn't. I don't have the quote handy but Roy stated pretty clearly that expected checkout roots are sufficiently distribution-like to be required to have LICENSE and NOTICE files in svn. I don't recall anything like that, in fact I understood the opposite, that the svn roots are not sufficient to be source releases. If that's the case, they can't be considered distributions and thus don't fall under the license and notice requirements. There's a very long thread in jan 2008 I'm not a master of mail archives but it's here http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/thread LICENSE and NOTICE files and SVN and a particularly relevant post http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/%3ce9d17d5f-3a68-4968-ab26-49586d558...@gbiv.com%3e - Maybe you could point to some documentation that makes your point that the Apache svn repository is itself a distribution subject to LICENSE and NOTICE requirements. The NOTICE file exists to fulfill our obligations under our license and the licenses of any third-party code that we redistribute. We try to be as proactive about that as possible. The NOTICE is in subversion because the board added a notice that all of our projects must carry. It needs to be in subversion when a third-party something that requires such a notice is also within subversion. Finally, each release package's NOTICE must reflect all of the required notices of all of the parts within that package. - Given this I think it's more in line with apache policy to fail if the LICENSE/NOTICE files are missing than to try to guess at what should be in and add them. And one more thing :-D Also, in general the LICENSE and NOTICE files apply to what's actually in the artifact. So for the source-archive it's for the actual source code in svn and shouldn't include any stuff for other code that may get into binary artifacts by shading, unpacking, copying, generating, including, etc etc. that the binary artifact legal files have to talk about. I think it would be too confusing to try to generate separate files for the source and binary artifacts. thanks david jencks thanks david jencks So I think that verifying that the LICENSE and NOTICE files are there is enough, you don't need to add them. thanks david jencks I need to understand better the default resource bundle processing and how to pull the right pieces together into the assembly. Otherwise we are pretty close to getting all this staged and released. --Brian On Thu, Jun 4, 2009 at 5:50 PM, Brian Foxbri...@infinity.nu wrote: Just to bring the thread back up in light of the recent discussions of plugin releases: John has taken over the assembly release that contains the fix I put in for the ASF stuff. I've been travelling a lot the past two weeks and haven't progressed much on the poms. Tomorrow or monday I should have time to take the latest assembly stage and get the apache assembly descriptor and all the poms updated and tested out. Note that the work we are doing here is to make it easier to define this for all maven (and later asf) projects and be inherited correctly. This does not mean that all pending releases must be blocked waiting for these changes. You can make a source release quite easily with the existing plugin versions. It's also worth nothing that now we know about the requirement, we must have a source release, ignoring the requirement simply because we didn't know it was a requirement in the past isn't an option. On Wed, May 27, 2009 at 12:49 PM, Brian Fox bri...@infinity.nu wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey jdca...@commonjava.org wrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter br...@apache.org wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
On Fri, Jun 12, 2009 at 12:11 AM, John Caseyjdca...@commonjava.org wrote: I had to include these files for the recent maven-assembly-plugin release. It was fairly simple, just take a look at this: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin/src/main/assembly/source-release.xml Be aware than under Maven 2.0.9 and windows that I had to use hard coded paths. Interpolated values did not get replaced correctly (i.e. the paths were \a\windows\path instead of a Java path and therefore replacements are failing) See http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin/src/assemble/source-release.xml - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
Update: The new assembly plugin and the regex in the source bundle seem to be working great. I have just one thing to resolve that I had previously overlooked: The source archive must also contain license and notice files, even if svn doesn't. I need to understand better the default resource bundle processing and how to pull the right pieces together into the assembly. Otherwise we are pretty close to getting all this staged and released. --Brian On Thu, Jun 4, 2009 at 5:50 PM, Brian Foxbri...@infinity.nu wrote: Just to bring the thread back up in light of the recent discussions of plugin releases: John has taken over the assembly release that contains the fix I put in for the ASF stuff. I've been travelling a lot the past two weeks and haven't progressed much on the poms. Tomorrow or monday I should have time to take the latest assembly stage and get the apache assembly descriptor and all the poms updated and tested out. Note that the work we are doing here is to make it easier to define this for all maven (and later asf) projects and be inherited correctly. This does not mean that all pending releases must be blocked waiting for these changes. You can make a source release quite easily with the existing plugin versions. It's also worth nothing that now we know about the requirement, we must have a source release, ignoring the requirement simply because we didn't know it was a requirement in the past isn't an option. On Wed, May 27, 2009 at 12:49 PM, Brian Fox bri...@infinity.nu wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey jdca...@commonjava.org wrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter br...@apache.org wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - 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: Update on ASF Release requirements
Just to bring the thread back up in light of the recent discussions of plugin releases: John has taken over the assembly release that contains the fix I put in for the ASF stuff. I've been travelling a lot the past two weeks and haven't progressed much on the poms. Tomorrow or monday I should have time to take the latest assembly stage and get the apache assembly descriptor and all the poms updated and tested out. Note that the work we are doing here is to make it easier to define this for all maven (and later asf) projects and be inherited correctly. This does not mean that all pending releases must be blocked waiting for these changes. You can make a source release quite easily with the existing plugin versions. It's also worth nothing that now we know about the requirement, we must have a source release, ignoring the requirement simply because we didn't know it was a requirement in the past isn't an option. On Wed, May 27, 2009 at 12:49 PM, Brian Fox bri...@infinity.nu wrote: On Wed, May 27, 2009 at 12:25 PM, John Casey jdca...@commonjava.orgwrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter br...@apache.org wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
On Tue, May 26, 2009 at 10:18 PM, Brett Porter br...@apache.org wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. Then we can do (?!.*/src/.*).*/target/.* Ew :) What if the build directory isn't target? (unlikely, I know). What if there are both src and target packages in a source tree? (not unthinkable) What if it's a pom project with no src directory and still generates a target? Seems a little magic to me. My main goal is to get something working for Maven projects now, which all use target. A more elaborate solution will require a longer cycle and this is already long enough. Apache projects that also use target (don't they all?) will also be able to use this --- after all, this descriptor is specific to us, i'm not trying to solve the world's problems here, just ours. - Brett On Mon, May 25, 2009 at 6:58 PM, Brett Porter br...@apache.org wrote: How about an option excludeBuildDirectoriestrue/excludeBuildDirectories that uses the list of build directories from all projects in the reactor an applies that to the fileset excludes? It could be either descriptor-wide, or per-fileset I guess. Short of that, I'd say to get it off the ground to tell projects they need to alter the descriptor when using it to explicitly include their non-build target directories. - Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter br...@apache.org wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) -john - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
On Wed, May 27, 2009 at 12:25 PM, John Casey jdca...@commonjava.org wrote: Brian Fox wrote: On Tue, May 26, 2009 at 10:18 PM, Brett Porter br...@apache.org wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? It's already to go, John is staging it now. *Ahem* I'm still troubleshooting an IT issue dealing with these regexes, so once that's done I'll stage the release. Just didn't want anyone thinking they'd missed the vote thread. ;-) Yeah, that's what I meant ;-) -john - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Then we can do (?!.*/src/.*).*/target/.* On Mon, May 25, 2009 at 6:58 PM, Brett Porter br...@apache.org wrote: How about an option excludeBuildDirectoriestrue/excludeBuildDirectories that uses the list of build directories from all projects in the reactor an applies that to the fileset excludes? It could be either descriptor-wide, or per-fileset I guess. Short of that, I'd say to get it off the ground to tell projects they need to alter the descriptor when using it to explicitly include their non-build target directories. - Brett On 21/05/2009, at 7:14 AM, Brian Fox wrote: Introducing the configurability in the descriptor itself requires more changes to the assembly code than I think we should tackle right now. I also think we should strive to build a descriptor that works for all projects to the extent possible. That said, I'll make a property in the plugin config to make it easier for projects to disable this execution and/or use a different descriptor of their choosing. Now, I solved the MASSEMBLY-405 issue, but this causes a few more problems we need to look into. It causes us to need something like **\target\** to exclude the build artifacts from the assembly, but several projects in maven use target folders in their test resources (archetype, install, deploy). The solution to this yet is still undefined. On Mon, May 18, 2009 at 11:36 AM, Ate Douma a...@douma.nu wrote: Brian Fox wrote: On Mon, May 18, 2009 at 8:57 AM, Ate Douma a...@douma.nu wrote: Brian Fox wrote: It's been a little slow going, but here's an update of where I'm at: I branched assembly 2.2-beta-4-SNAPSHOT[1] from the 2.2-beta-3 tag and renamed the trunk to 2.2-beta-5. The runOnlyOnExecutionRoot flag has been added to 2.2-beta-4 (MASSEMBLY-406). I created a custom descriptor bundle[2] to be used for the asf source releases. Initially this is a copy of the default project.xml with the bz2 removed. Having it separate will give us more flexibility to make updates w/o having to re-release the plugin. The configuration for making a bundle with this setup currently looks like this: plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-4-SNAPSHOT/version executions execution goals goalsingle/goal /goals phasevalidate/phase configuration runOnlyAtExecutionRoottrue/runOnlyAtExecutionRoot descriptorRefs descriptorRef source-release /descriptorRef /descriptorRefs /configuration /execution /executions dependencies dependency groupIdorg.apache/groupId artifactIdapache-source-release-assembly-descriptor/artifactId version1.0-SNAPSHOT/version /dependency /dependencies /plugin Once I test and work out any kinks, this will be added to the maven pom and released. There is one bug that David Jenks found in the beta-3 code that needs to be addressed since it affects the bundle content (MASSEMBLY-405). I hope to have the bug fixed and assembly staged by tuesday, followed by the descriptor bundle and then the maven/shared/plugin/etc parents later this week. Hi Brian, I just created issue MASSEMBLY-409 which describes two other problems we encountered by using the project assembly for our recent Apache Portals releases. It would be great if you can take that issue and the recommended fixes/solutions into consideration for the next release too: http://jira.codehaus.org/browse/MASSEMBLY-409 I don't see those as being problems with the approach I'm taking. The asf descriptor will be separate from the plugin so we can tweak it as needed, and projects can introduce their own descriptors instead of the default if they want. Well, yes. But with the current restrictions (no configuration overrides) it might result in a lot (most) ASF projects needing to provide their own which makes the whole point of this project descriptor a bit useless IMO. The current descriptor produces tar.gz and zip, does anyone have strong feelings if this is ok or should we go with only one of them? (and which one?) Why drop .bz2 in the first place? The source archives for everything are going to significantly increase the bandwidth to mirror and disk to store millions of artifacts. We should be conservative and use the minimum, which imo is zip and bz2. We have been using .bz2, .tar.gz and .zip based distro releases always and AFAIK most other ASF projects too. With this change, we'll be forced to build the missing ones manually ourselves and/or won't be able to use *only* the new project assembly within our release procedures. But, as I indicated in MASSEMBLY-409 (see above), if predefined assemblies can be modified to accept
Re: Update on ASF Release requirements
On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? Then we can do (?!.*/src/.*).*/target/.* Ew :) What if the build directory isn't target? (unlikely, I know). What if there are both src and target packages in a source tree? (not unthinkable) What if it's a pom project with no src directory and still generates a target? Seems a little magic to me. - Brett On Mon, May 25, 2009 at 6:58 PM, Brett Porter br...@apache.org wrote: How about an option excludeBuildDirectoriestrue/ excludeBuildDirectories that uses the list of build directories from all projects in the reactor an applies that to the fileset excludes? It could be either descriptor-wide, or per-fileset I guess. Short of that, I'd say to get it off the ground to tell projects they need to alter the descriptor when using it to explicitly include their non-build target directories. - Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
On 27/05/2009, at 3:18 PM, Brett Porter wrote: On 26/05/2009, at 11:11 PM, Brian Fox wrote: We're fixing the directoryscanner to allow regular expressions in addition to the ant syntax. Cool, but that's another release in the chain, right? Then we can do (?!.*/src/.*).*/target/.* Ew :) What if the build directory isn't target? (unlikely, I know). What if there are both src and target packages in a source tree? (not unthinkable) What if it's a pom project with no src directory and still generates a target? ok, sorry... I completely misread that regex as meaning target where there is a source directory. So this would work ok... but I think I'd still prefer something more deterministic such as the below as it could improve the out-of-the-box source descriptor as well. Seems a little magic to me. - Brett On Mon, May 25, 2009 at 6:58 PM, Brett Porter br...@apache.org wrote: How about an option excludeBuildDirectoriestrue/ excludeBuildDirectories that uses the list of build directories from all projects in the reactor an applies that to the fileset excludes? It could be either descriptor-wide, or per-fileset I guess. Short of that, I'd say to get it off the ground to tell projects they need to alter the descriptor when using it to explicitly include their non-build target directories. - Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
How about an option excludeBuildDirectoriestrue/ excludeBuildDirectories that uses the list of build directories from all projects in the reactor an applies that to the fileset excludes? It could be either descriptor-wide, or per-fileset I guess. Short of that, I'd say to get it off the ground to tell projects they need to alter the descriptor when using it to explicitly include their non-build target directories. - Brett On 21/05/2009, at 7:14 AM, Brian Fox wrote: Introducing the configurability in the descriptor itself requires more changes to the assembly code than I think we should tackle right now. I also think we should strive to build a descriptor that works for all projects to the extent possible. That said, I'll make a property in the plugin config to make it easier for projects to disable this execution and/or use a different descriptor of their choosing. Now, I solved the MASSEMBLY-405 issue, but this causes a few more problems we need to look into. It causes us to need something like **\target \** to exclude the build artifacts from the assembly, but several projects in maven use target folders in their test resources (archetype, install, deploy). The solution to this yet is still undefined. On Mon, May 18, 2009 at 11:36 AM, Ate Douma a...@douma.nu wrote: Brian Fox wrote: On Mon, May 18, 2009 at 8:57 AM, Ate Douma a...@douma.nu wrote: Brian Fox wrote: It's been a little slow going, but here's an update of where I'm at: I branched assembly 2.2-beta-4-SNAPSHOT[1] from the 2.2-beta-3 tag and renamed the trunk to 2.2-beta-5. The runOnlyOnExecutionRoot flag has been added to 2.2-beta-4 (MASSEMBLY-406). I created a custom descriptor bundle[2] to be used for the asf source releases. Initially this is a copy of the default project.xml with the bz2 removed. Having it separate will give us more flexibility to make updates w/o having to re-release the plugin. The configuration for making a bundle with this setup currently looks like this: plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-4-SNAPSHOT/version executions execution goals goalsingle/goal /goals phasevalidate/phase configuration runOnlyAtExecutionRoottrue/runOnlyAtExecutionRoot descriptorRefs descriptorRef source-release /descriptorRef /descriptorRefs /configuration /execution /executions dependencies dependency groupIdorg.apache/groupId artifactIdapache-source-release-assembly-descriptor/artifactId version1.0-SNAPSHOT/version /dependency /dependencies /plugin Once I test and work out any kinks, this will be added to the maven pom and released. There is one bug that David Jenks found in the beta-3 code that needs to be addressed since it affects the bundle content (MASSEMBLY-405). I hope to have the bug fixed and assembly staged by tuesday, followed by the descriptor bundle and then the maven/shared/plugin/etc parents later this week. Hi Brian, I just created issue MASSEMBLY-409 which describes two other problems we encountered by using the project assembly for our recent Apache Portals releases. It would be great if you can take that issue and the recommended fixes/solutions into consideration for the next release too: http://jira.codehaus.org/browse/MASSEMBLY-409 I don't see those as being problems with the approach I'm taking. The asf descriptor will be separate from the plugin so we can tweak it as needed, and projects can introduce their own descriptors instead of the default if they want. Well, yes. But with the current restrictions (no configuration overrides) it might result in a lot (most) ASF projects needing to provide their own which makes the whole point of this project descriptor a bit useless IMO. The current descriptor produces tar.gz and zip, does anyone have strong feelings if this is ok or should we go with only one of them? (and which one?) Why drop .bz2 in the first place? The source archives for everything are going to significantly increase the bandwidth to mirror and disk to store millions of artifacts. We should be conservative and use the minimum, which imo is zip and bz2. We have been using .bz2, .tar.gz and .zip based distro releases always and AFAIK most other ASF projects too. With this change, we'll be forced to build the missing ones manually ourselves and/or won't be able to use *only* the new project assembly within our release procedures. But, as I indicated in MASSEMBLY-409 (see above), if predefined assemblies can be modified to accept additional configuration settings/ overrides, *then* this would not be a problem as we can configure the needed formats ourselves then. I'll talk with John to see what might be possible to introduce wrt
Re: Update on ASF Release requirements
Introducing the configurability in the descriptor itself requires more changes to the assembly code than I think we should tackle right now. I also think we should strive to build a descriptor that works for all projects to the extent possible. That said, I'll make a property in the plugin config to make it easier for projects to disable this execution and/or use a different descriptor of their choosing. Now, I solved the MASSEMBLY-405 issue, but this causes a few more problems we need to look into. It causes us to need something like **\target\** to exclude the build artifacts from the assembly, but several projects in maven use target folders in their test resources (archetype, install, deploy). The solution to this yet is still undefined. On Mon, May 18, 2009 at 11:36 AM, Ate Douma a...@douma.nu wrote: Brian Fox wrote: On Mon, May 18, 2009 at 8:57 AM, Ate Douma a...@douma.nu wrote: Brian Fox wrote: It's been a little slow going, but here's an update of where I'm at: I branched assembly 2.2-beta-4-SNAPSHOT[1] from the 2.2-beta-3 tag and renamed the trunk to 2.2-beta-5. The runOnlyOnExecutionRoot flag has been added to 2.2-beta-4 (MASSEMBLY-406). I created a custom descriptor bundle[2] to be used for the asf source releases. Initially this is a copy of the default project.xml with the bz2 removed. Having it separate will give us more flexibility to make updates w/o having to re-release the plugin. The configuration for making a bundle with this setup currently looks like this: plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-4-SNAPSHOT/version executions execution goals goalsingle/goal /goals phasevalidate/phase configuration runOnlyAtExecutionRoottrue/runOnlyAtExecutionRoot descriptorRefs descriptorRef source-release /descriptorRef /descriptorRefs /configuration /execution /executions dependencies dependency groupIdorg.apache/groupId artifactIdapache-source-release-assembly-descriptor/artifactId version1.0-SNAPSHOT/version /dependency /dependencies /plugin Once I test and work out any kinks, this will be added to the maven pom and released. There is one bug that David Jenks found in the beta-3 code that needs to be addressed since it affects the bundle content (MASSEMBLY-405). I hope to have the bug fixed and assembly staged by tuesday, followed by the descriptor bundle and then the maven/shared/plugin/etc parents later this week. Hi Brian, I just created issue MASSEMBLY-409 which describes two other problems we encountered by using the project assembly for our recent Apache Portals releases. It would be great if you can take that issue and the recommended fixes/solutions into consideration for the next release too: http://jira.codehaus.org/browse/MASSEMBLY-409 I don't see those as being problems with the approach I'm taking. The asf descriptor will be separate from the plugin so we can tweak it as needed, and projects can introduce their own descriptors instead of the default if they want. Well, yes. But with the current restrictions (no configuration overrides) it might result in a lot (most) ASF projects needing to provide their own which makes the whole point of this project descriptor a bit useless IMO. The current descriptor produces tar.gz and zip, does anyone have strong feelings if this is ok or should we go with only one of them? (and which one?) Why drop .bz2 in the first place? The source archives for everything are going to significantly increase the bandwidth to mirror and disk to store millions of artifacts. We should be conservative and use the minimum, which imo is zip and bz2. We have been using .bz2, .tar.gz and .zip based distro releases always and AFAIK most other ASF projects too. With this change, we'll be forced to build the missing ones manually ourselves and/or won't be able to use *only* the new project assembly within our release procedures. But, as I indicated in MASSEMBLY-409 (see above), if predefined assemblies can be modified to accept additional configuration settings/overrides, *then* this would not be a problem as we can configure the needed formats ourselves then. I'll talk with John to see what might be possible to introduce wrt configurability for the asf descriptor. If you can enable that, all issues I described in MSASSEMBLY-409 would be solvable automatically too :) Also, I used source-release as the id which would produce bundles like foo-1.0-source-release.zip. Any strong feelings on this? That is a workaround for the second issue I described in MASSEMBLY-409, but I'd still prefer being able to configure the classifier ourselves. We have been using -src as standard
Re: Update on ASF Release requirements
Brian Fox wrote: It's been a little slow going, but here's an update of where I'm at: I branched assembly 2.2-beta-4-SNAPSHOT[1] from the 2.2-beta-3 tag and renamed the trunk to 2.2-beta-5. The runOnlyOnExecutionRoot flag has been added to 2.2-beta-4 (MASSEMBLY-406). I created a custom descriptor bundle[2] to be used for the asf source releases. Initially this is a copy of the default project.xml with the bz2 removed. Having it separate will give us more flexibility to make updates w/o having to re-release the plugin. The configuration for making a bundle with this setup currently looks like this: plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-4-SNAPSHOT/version executions execution goals goalsingle/goal /goals phasevalidate/phase configuration runOnlyAtExecutionRoottrue/runOnlyAtExecutionRoot descriptorRefs descriptorRef source-release /descriptorRef /descriptorRefs /configuration /execution /executions dependencies dependency groupIdorg.apache/groupId artifactIdapache-source-release-assembly-descriptor/artifactId version1.0-SNAPSHOT/version /dependency /dependencies /plugin Once I test and work out any kinks, this will be added to the maven pom and released. There is one bug that David Jenks found in the beta-3 code that needs to be addressed since it affects the bundle content (MASSEMBLY-405). I hope to have the bug fixed and assembly staged by tuesday, followed by the descriptor bundle and then the maven/shared/plugin/etc parents later this week. Hi Brian, I just created issue MASSEMBLY-409 which describes two other problems we encountered by using the project assembly for our recent Apache Portals releases. It would be great if you can take that issue and the recommended fixes/solutions into consideration for the next release too: http://jira.codehaus.org/browse/MASSEMBLY-409 The current descriptor produces tar.gz and zip, does anyone have strong feelings if this is ok or should we go with only one of them? (and which one?) Why drop .bz2 in the first place? We have been using .bz2, .tar.gz and .zip based distro releases always and AFAIK most other ASF projects too. With this change, we'll be forced to build the missing ones manually ourselves and/or won't be able to use *only* the new project assembly within our release procedures. But, as I indicated in MASSEMBLY-409 (see above), if predefined assemblies can be modified to accept additional configuration settings/overrides, *then* this would not be a problem as we can configure the needed formats ourselves then. Also, I used source-release as the id which would produce bundles like foo-1.0-source-release.zip. Any strong feelings on this? That is a workaround for the second issue I described in MASSEMBLY-409, but I'd still prefer being able to configure the classifier ourselves. We have been using -src as standard extension to indicate a source distribution for all our previous releases, just as most other ASF projects AFAIK, and very much prefer being able to continue to do so. Regards, Ate [1] https://svn.apache.org/repos/asf/maven/plugins/branches/maven-assembly-plugin-2.2-beta-4 [2] https://svn.apache.org/repos/asf/maven/resources/trunk/apache-source-release-assembly-descriptor On Mon, May 4, 2009 at 9:01 PM, Brian Fox bri...@infinity.nu wrote: There have been a few threads spawned on various ASF lists lately about the release process at the ASF and Maven projects and other Apache projects that use Maven being compliant. A documentation patch for the release page at http://www.apache.org/dev/release.html is pending, but it's close enough that I can summarize it here. The ASF produces Open _Source_ releases. The primary artifact that is to be released and voted upon is a source archive that is sufficient for others to use to produce the product. Binaries that are also released have additional requirements such as NOTICE and LICENSE files, but these are not considered to be the primary release -- the source archive is. Part of the default release profile in Maven is to generate sources jars. These sources jars contain the java packages only and not the pom.xml or any resources or test resources actually used to build the project. In short, they aren't really close at all to what you might find in an svn tag for the same release. The primary use of these jars is by IDEs for debugging purposes. The Maven Core releases do produce source archives using the assembly plugin. Plugins, Shared, and other smaller releases do not. This part is not in compliance with the ASF release process and needs to be fixed before the next release. A simple solution to this problem is to bind the assembly plugin using a src
Re: Update on ASF Release requirements
On 18/05/2009, at 10:57 PM, Ate Douma wrote: The current descriptor produces tar.gz and zip, does anyone have strong feelings if this is ok or should we go with only one of them? (and which one?) Why drop .bz2 in the first place? We have been using .bz2, .tar.gz and .zip based distro releases always and AFAIK most other ASF projects too. With this change, we'll be forced to build the missing ones manually ourselves and/or won't be able to use *only* the new project assembly within our release procedures. But, as I indicated in MASSEMBLY-409 (see above), if predefined assemblies can be modified to accept additional configuration settings/overrides, *then* this would not be a problem as we can configure the needed formats ourselves then. Yeah, in general I Think configuring the formats from the plugin config instead of the assembly descriptor makes more sense. Maybe it could be set to at least override. I like zip, tgz as they tend to be the respective preferences of Windows (no tgz installed by default) and *nix-like users. Also, I used source-release as the id which would produce bundles like foo-1.0-source-release.zip. Any strong feelings on this? That is a workaround for the second issue I described in MASSEMBLY-409, but I'd still prefer being able to configure the classifier ourselves. We have been using -src as standard extension to indicate a source distribution for all our previous releases, just as most other ASF projects AFAIK, and very much prefer being able to continue to do so. Agree, configuring classifier is better than using the id in hindsight as they rarely match up. Otherwise, Brian - plan looks good to me. Thanks for doing this! - Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
On Mon, May 18, 2009 at 8:57 AM, Ate Douma a...@douma.nu wrote: Brian Fox wrote: It's been a little slow going, but here's an update of where I'm at: I branched assembly 2.2-beta-4-SNAPSHOT[1] from the 2.2-beta-3 tag and renamed the trunk to 2.2-beta-5. The runOnlyOnExecutionRoot flag has been added to 2.2-beta-4 (MASSEMBLY-406). I created a custom descriptor bundle[2] to be used for the asf source releases. Initially this is a copy of the default project.xml with the bz2 removed. Having it separate will give us more flexibility to make updates w/o having to re-release the plugin. The configuration for making a bundle with this setup currently looks like this: plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-4-SNAPSHOT/version executions execution goals goalsingle/goal /goals phasevalidate/phase configuration runOnlyAtExecutionRoottrue/runOnlyAtExecutionRoot descriptorRefs descriptorRef source-release /descriptorRef /descriptorRefs /configuration /execution /executions dependencies dependency groupIdorg.apache/groupId artifactIdapache-source-release-assembly-descriptor/artifactId version1.0-SNAPSHOT/version /dependency /dependencies /plugin Once I test and work out any kinks, this will be added to the maven pom and released. There is one bug that David Jenks found in the beta-3 code that needs to be addressed since it affects the bundle content (MASSEMBLY-405). I hope to have the bug fixed and assembly staged by tuesday, followed by the descriptor bundle and then the maven/shared/plugin/etc parents later this week. Hi Brian, I just created issue MASSEMBLY-409 which describes two other problems we encountered by using the project assembly for our recent Apache Portals releases. It would be great if you can take that issue and the recommended fixes/solutions into consideration for the next release too: http://jira.codehaus.org/browse/MASSEMBLY-409 I don't see those as being problems with the approach I'm taking. The asf descriptor will be separate from the plugin so we can tweak it as needed, and projects can introduce their own descriptors instead of the default if they want. The current descriptor produces tar.gz and zip, does anyone have strong feelings if this is ok or should we go with only one of them? (and which one?) Why drop .bz2 in the first place? The source archives for everything are going to significantly increase the bandwidth to mirror and disk to store millions of artifacts. We should be conservative and use the minimum, which imo is zip and bz2. We have been using .bz2, .tar.gz and .zip based distro releases always and AFAIK most other ASF projects too. With this change, we'll be forced to build the missing ones manually ourselves and/or won't be able to use *only* the new project assembly within our release procedures. But, as I indicated in MASSEMBLY-409 (see above), if predefined assemblies can be modified to accept additional configuration settings/overrides, *then* this would not be a problem as we can configure the needed formats ourselves then. I'll talk with John to see what might be possible to introduce wrt configurability for the asf descriptor. Also, I used source-release as the id which would produce bundles like foo-1.0-source-release.zip. Any strong feelings on this? That is a workaround for the second issue I described in MASSEMBLY-409, but I'd still prefer being able to configure the classifier ourselves. We have been using -src as standard extension to indicate a source distribution for all our previous releases, just as most other ASF projects AFAIK, and very much prefer being able to continue to do so. Regards, Ate [1] https://svn.apache.org/repos/asf/maven/plugins/branches/maven-assembly-plugin-2.2-beta-4 [2] https://svn.apache.org/repos/asf/maven/resources/trunk/apache-source-release-assembly-descriptor On Mon, May 4, 2009 at 9:01 PM, Brian Fox bri...@infinity.nu wrote: There have been a few threads spawned on various ASF lists lately about the release process at the ASF and Maven projects and other Apache projects that use Maven being compliant. A documentation patch for the release page at http://www.apache.org/dev/release.html is pending, but it's close enough that I can summarize it here. The ASF produces Open _Source_ releases. The primary artifact that is to be released and voted upon is a source archive that is sufficient for others to use to produce the product. Binaries that are also released have additional requirements such as NOTICE and LICENSE files, but these are not considered to be the primary release -- the source archive is. Part of the
Re: Update on ASF Release requirements
Brian Fox wrote: On Mon, May 18, 2009 at 8:57 AM, Ate Douma a...@douma.nu wrote: Brian Fox wrote: It's been a little slow going, but here's an update of where I'm at: I branched assembly 2.2-beta-4-SNAPSHOT[1] from the 2.2-beta-3 tag and renamed the trunk to 2.2-beta-5. The runOnlyOnExecutionRoot flag has been added to 2.2-beta-4 (MASSEMBLY-406). I created a custom descriptor bundle[2] to be used for the asf source releases. Initially this is a copy of the default project.xml with the bz2 removed. Having it separate will give us more flexibility to make updates w/o having to re-release the plugin. The configuration for making a bundle with this setup currently looks like this: plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-4-SNAPSHOT/version executions execution goals goalsingle/goal /goals phasevalidate/phase configuration runOnlyAtExecutionRoottrue/runOnlyAtExecutionRoot descriptorRefs descriptorRef source-release /descriptorRef /descriptorRefs /configuration /execution /executions dependencies dependency groupIdorg.apache/groupId artifactIdapache-source-release-assembly-descriptor/artifactId version1.0-SNAPSHOT/version /dependency /dependencies /plugin Once I test and work out any kinks, this will be added to the maven pom and released. There is one bug that David Jenks found in the beta-3 code that needs to be addressed since it affects the bundle content (MASSEMBLY-405). I hope to have the bug fixed and assembly staged by tuesday, followed by the descriptor bundle and then the maven/shared/plugin/etc parents later this week. Hi Brian, I just created issue MASSEMBLY-409 which describes two other problems we encountered by using the project assembly for our recent Apache Portals releases. It would be great if you can take that issue and the recommended fixes/solutions into consideration for the next release too: http://jira.codehaus.org/browse/MASSEMBLY-409 I don't see those as being problems with the approach I'm taking. The asf descriptor will be separate from the plugin so we can tweak it as needed, and projects can introduce their own descriptors instead of the default if they want. Well, yes. But with the current restrictions (no configuration overrides) it might result in a lot (most) ASF projects needing to provide their own which makes the whole point of this project descriptor a bit useless IMO. The current descriptor produces tar.gz and zip, does anyone have strong feelings if this is ok or should we go with only one of them? (and which one?) Why drop .bz2 in the first place? The source archives for everything are going to significantly increase the bandwidth to mirror and disk to store millions of artifacts. We should be conservative and use the minimum, which imo is zip and bz2. We have been using .bz2, .tar.gz and .zip based distro releases always and AFAIK most other ASF projects too. With this change, we'll be forced to build the missing ones manually ourselves and/or won't be able to use *only* the new project assembly within our release procedures. But, as I indicated in MASSEMBLY-409 (see above), if predefined assemblies can be modified to accept additional configuration settings/overrides, *then* this would not be a problem as we can configure the needed formats ourselves then. I'll talk with John to see what might be possible to introduce wrt configurability for the asf descriptor. If you can enable that, all issues I described in MSASSEMBLY-409 would be solvable automatically too :) Also, I used source-release as the id which would produce bundles like foo-1.0-source-release.zip. Any strong feelings on this? That is a workaround for the second issue I described in MASSEMBLY-409, but I'd still prefer being able to configure the classifier ourselves. We have been using -src as standard extension to indicate a source distribution for all our previous releases, just as most other ASF projects AFAIK, and very much prefer being able to continue to do so. Regards, Ate [1] https://svn.apache.org/repos/asf/maven/plugins/branches/maven-assembly-plugin-2.2-beta-4 [2] https://svn.apache.org/repos/asf/maven/resources/trunk/apache-source-release-assembly-descriptor On Mon, May 4, 2009 at 9:01 PM, Brian Fox bri...@infinity.nu wrote: There have been a few threads spawned on various ASF lists lately about the release process at the ASF and Maven projects and other Apache projects that use Maven being compliant. A documentation patch for the release page at http://www.apache.org/dev/release.html is pending, but it's close enough that I can summarize it here. The ASF produces Open _Source_ releases. The primary artifact that is to be released and voted upon is
Re: Update on ASF Release requirements
It's been a little slow going, but here's an update of where I'm at: I branched assembly 2.2-beta-4-SNAPSHOT[1] from the 2.2-beta-3 tag and renamed the trunk to 2.2-beta-5. The runOnlyOnExecutionRoot flag has been added to 2.2-beta-4 (MASSEMBLY-406). I created a custom descriptor bundle[2] to be used for the asf source releases. Initially this is a copy of the default project.xml with the bz2 removed. Having it separate will give us more flexibility to make updates w/o having to re-release the plugin. The configuration for making a bundle with this setup currently looks like this: plugin artifactIdmaven-assembly-plugin/artifactId version2.2-beta-4-SNAPSHOT/version executions execution goals goalsingle/goal /goals phasevalidate/phase configuration runOnlyAtExecutionRoottrue/runOnlyAtExecutionRoot descriptorRefs descriptorRef source-release /descriptorRef /descriptorRefs /configuration /execution /executions dependencies dependency groupIdorg.apache/groupId artifactIdapache-source-release-assembly-descriptor/artifactId version1.0-SNAPSHOT/version /dependency /dependencies /plugin Once I test and work out any kinks, this will be added to the maven pom and released. There is one bug that David Jenks found in the beta-3 code that needs to be addressed since it affects the bundle content (MASSEMBLY-405). I hope to have the bug fixed and assembly staged by tuesday, followed by the descriptor bundle and then the maven/shared/plugin/etc parents later this week. The current descriptor produces tar.gz and zip, does anyone have strong feelings if this is ok or should we go with only one of them? (and which one?) Also, I used source-release as the id which would produce bundles like foo-1.0-source-release.zip. Any strong feelings on this? [1] https://svn.apache.org/repos/asf/maven/plugins/branches/maven-assembly-plugin-2.2-beta-4 [2] https://svn.apache.org/repos/asf/maven/resources/trunk/apache-source-release-assembly-descriptor On Mon, May 4, 2009 at 9:01 PM, Brian Fox bri...@infinity.nu wrote: There have been a few threads spawned on various ASF lists lately about the release process at the ASF and Maven projects and other Apache projects that use Maven being compliant. A documentation patch for the release page at http://www.apache.org/dev/release.html is pending, but it's close enough that I can summarize it here. The ASF produces Open _Source_ releases. The primary artifact that is to be released and voted upon is a source archive that is sufficient for others to use to produce the product. Binaries that are also released have additional requirements such as NOTICE and LICENSE files, but these are not considered to be the primary release -- the source archive is. Part of the default release profile in Maven is to generate sources jars. These sources jars contain the java packages only and not the pom.xml or any resources or test resources actually used to build the project. In short, they aren't really close at all to what you might find in an svn tag for the same release. The primary use of these jars is by IDEs for debugging purposes. The Maven Core releases do produce source archives using the assembly plugin. Plugins, Shared, and other smaller releases do not. This part is not in compliance with the ASF release process and needs to be fixed before the next release. A simple solution to this problem is to bind the assembly plugin using a src descriptor to the pom. This will work in the short term for releases ready to go like the archetype plugin. However, it won't be very maintainable since we have over 60 modules (i stopped counting after plugins and shared) that are individually released. If we bind the plugin in the Maven pom, it would produce source archives for every single module recursively, which is not what we want here. To solve this, I've added a new flag to the Assembly plugin that will tell the plugin to only run in the Execution Root folder and skip everything else. The enforcer plugin tree is a good example of how this will work. The plugin binding would be defined in the Maven pom and thus inherited down to the Enforcer. The Enforcer tree looks like this: \ +---enforcer-api +---enforcer-rules +---maven-enforcer-plugin \---pom.xml Normally I would do a release of the enforcer from the top and release the parent, the api, rules and plugin all at once. In this case I want the source archive to zip up the entire tree. However, I may do a release of the plugin only. In this case I would run from the \enforcer\maven-enforcer-plugin subfolder. In this case, I want the just maven-enforcer-plugin source archive because that's what I'm releasing. The new flag
Re: Update on ASF Release requirements
Could I ask what's going to happen after you get the assembly plugin improved? Will there be an apache 7 pom or, how else would we get this new functionality? thanks david jencks On May 7, 2009, at 8:13 PM, Brian E. Fox wrote: I just need to finish the ITs. --Brian (mobile) On May 7, 2009, at 10:45 PM, Stephane Nicoll stephane.nic...@gmail.com wrote: On Tue, May 5, 2009 at 3:21 AM, Brett Porter br...@apache.org wrote: On 05/05/2009, at 11:01 AM, Brian Fox wrote: To make this happen relatively quickly, I'll take finish my patch by adding tests, and then stage a release of the assembly plugin 2.2- beta-3.1 by applying only this patch to the existing beta-3 tag so we can cut a release without a bunch of hand wrangling over what needs to be fixed in beta-4. Any concerns or objections to the above plan? Only the version. Release it as beta 4 using the approach above (or any since committed fixes) and tell anyone that complains to go jump :) +1 I was about to stage ear plugin 2.3.2 so I suppose I need to wait a bit. Brian, what is the status of this one? Thanks, Stéphane Cheers, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - 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: Update on ASF Release requirements
My plan is to implement the packaging in the maven pom and then later promote it to the apache pom once any kinks are worked out. --Brian (mobile) On May 8, 2009, at 8:17 PM, David Jencks david_jen...@yahoo.com wrote: Could I ask what's going to happen after you get the assembly plugin improved? Will there be an apache 7 pom or, how else would we get this new functionality? thanks david jencks On May 7, 2009, at 8:13 PM, Brian E. Fox wrote: I just need to finish the ITs. --Brian (mobile) On May 7, 2009, at 10:45 PM, Stephane Nicoll stephane.nic...@gmail.com wrote: On Tue, May 5, 2009 at 3:21 AM, Brett Porter br...@apache.org wrote: On 05/05/2009, at 11:01 AM, Brian Fox wrote: To make this happen relatively quickly, I'll take finish my patch by adding tests, and then stage a release of the assembly plugin 2.2-beta-3.1 by applying only this patch to the existing beta-3 tag so we can cut a release without a bunch of hand wrangling over what needs to be fixed in beta-4. Any concerns or objections to the above plan? Only the version. Release it as beta 4 using the approach above (or any since committed fixes) and tell anyone that complains to go jump :) +1 I was about to stage ear plugin 2.3.2 so I suppose I need to wait a bit. Brian, what is the status of this one? Thanks, Stéphane Cheers, Brett --- -- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - 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: Update on ASF Release requirements
On Tue, May 5, 2009 at 3:21 AM, Brett Porter br...@apache.org wrote: On 05/05/2009, at 11:01 AM, Brian Fox wrote: To make this happen relatively quickly, I'll take finish my patch by adding tests, and then stage a release of the assembly plugin 2.2-beta-3.1 by applying only this patch to the existing beta-3 tag so we can cut a release without a bunch of hand wrangling over what needs to be fixed in beta-4. Any concerns or objections to the above plan? Only the version. Release it as beta 4 using the approach above (or any since committed fixes) and tell anyone that complains to go jump :) +1 I was about to stage ear plugin 2.3.2 so I suppose I need to wait a bit. Brian, what is the status of this one? Thanks, Stéphane Cheers, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge
Re: Update on ASF Release requirements
I just need to finish the ITs. --Brian (mobile) On May 7, 2009, at 10:45 PM, Stephane Nicoll stephane.nic...@gmail.com wrote: On Tue, May 5, 2009 at 3:21 AM, Brett Porter br...@apache.org wrote: On 05/05/2009, at 11:01 AM, Brian Fox wrote: To make this happen relatively quickly, I'll take finish my patch by adding tests, and then stage a release of the assembly plugin 2.2- beta-3.1 by applying only this patch to the existing beta-3 tag so we can cut a release without a bunch of hand wrangling over what needs to be fixed in beta-4. Any concerns or objections to the above plan? Only the version. Release it as beta 4 using the approach above (or any since committed fixes) and tell anyone that complains to go jump :) +1 I was about to stage ear plugin 2.3.2 so I suppose I need to wait a bit. Brian, what is the status of this one? Thanks, Stéphane Cheers, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Update on ASF Release requirements
On 05/05/2009, at 11:01 AM, Brian Fox wrote: To make this happen relatively quickly, I'll take finish my patch by adding tests, and then stage a release of the assembly plugin 2.2- beta-3.1 by applying only this patch to the existing beta-3 tag so we can cut a release without a bunch of hand wrangling over what needs to be fixed in beta-4. Any concerns or objections to the above plan? Only the version. Release it as beta 4 using the approach above (or any since committed fixes) and tell anyone that complains to go jump :) Cheers, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org