subject:"Update on ASF Release requirements"

Re: Update on ASF Release requirements

2009-06-15 Thread John Casey

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

2009-06-12 Thread John Casey


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

2009-06-12 Thread Barrie Treloar

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

2009-06-12 Thread Barrie Treloar

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

2009-06-12 Thread Barrie Treloar

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

2009-06-11 Thread Brian Fox

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

2009-06-11 Thread John Casey

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

Re: Update on ASF Release requirements

2009-06-11 Thread David Jencks

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

2009-06-11 Thread Brian Fox

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:

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.

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.

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

2009-06-11 Thread David Jencks

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.

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

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

2009-06-11 Thread Barrie Treloar

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

2009-06-10 Thread Brian Fox

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

2009-06-04 Thread Brian Fox

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

2009-05-27 Thread Brian Fox

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

2009-05-27 Thread John Casey




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

2009-05-27 Thread Brian Fox

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

2009-05-26 Thread Brian Fox

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

2009-05-26 Thread Brett Porter



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

2009-05-26 Thread Brett Porter



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

2009-05-25 Thread Brett Porter

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

2009-05-20 Thread Brian Fox

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

2009-05-18 Thread Ate Douma

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

2009-05-18 Thread Brett Porter



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

2009-05-18 Thread Brian Fox

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.

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?

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

2009-05-18 Thread Ate Douma

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.

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,

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?

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?

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.

Re: Update on ASF Release requirements

2009-05-17 Thread Brian Fox

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.

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 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

2009-05-08 Thread David Jencks

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

2009-05-08 Thread Brian E. Fox

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

2009-05-07 Thread Stephane Nicoll

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

2009-05-07 Thread Brian E. Fox


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

AW: Update on ASF Release requirements

2009-05-05 Thread Mark Struberg


Hi Brian!

 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.

I'm not sure if this solution will work. I know of a few projects using the 
assembly plugin in submodules for other things than distribution.src.tar.gz 
creation.

What about quickly hacking a maven-sourcedistribution-plugin.
This plugin may safely use your trick with the parent disabling the clients, 
which I find a very cool thing.

Maybe this could also be an additional mojo in the assembly plugin and so reuse 
many of the existing functionality?

3rd way (and possibly the cleanest) would be to additionally to 2) add 
something like a 'skipOnParentInvocation' flag to the single assembly XMLs.

LieGrue,
strub



- Ursprüngliche Mail 
 Von: Brian Fox bri...@infinity.nu
 An: dev@maven.apache.org
 Gesendet: Dienstag, den 5. Mai 2009, 03:01:25 Uhr
 Betreff: Update on ASF Release requirements
 
 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 in the assembly plugin would allow both cases to work without 
 changing the poms, because the goal would skip in any project that doesn't 
 match 
 where Maven was executed (!session.getExecutionRootDir().equals(basedir))
 
 Eventually if we get this perfected, it would be appropriate to bump up to 
 the 
 Apache pom so it would just work out of the box for most projects. Since we 
 may 
 have to adjust the archive contents down the road, we should make the 
 descriptor 
 separate from the plugin itself. This can be done by producing a jar that 
 contains an Apache Source Bundle descriptor, and adding this to the assembly 
 plugin classpath in the execution. This will allow us to release this 
 independent and it would also make it easier for projects to override the 
 descriptor in their projects as needed.
 
 I'll also add a skip property specific to this execution in the release 
 profile 
 to allow projects that have existing source archives to be unaffected.
 
 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

Re: AW: Update on ASF Release requirements

2009-05-05 Thread Brian Fox




Mark Struberg wrote:

Hi Brian!

  
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.



I'm not sure if this solution will work. I know of a few projects using the 
assembly plugin in submodules for other things than distribution.src.tar.gz 
creation.

  
This will be a separate config in a specific release profile execution, 
the flag won't affect other distributions.

What about quickly hacking a maven-sourcedistribution-plugin.
This plugin may safely use your trick with the parent disabling the clients, 
which I find a very cool thing.

  
No need, it's a simple flag in the assembly plugin that won't conflict 
with anyone else.

Maybe this could also be an additional mojo in the assembly plugin and so reuse 
many of the existing functionality?

  
I was going to do that originally, but it's such a tiny bit of code to 
make it work for any assembly mojo, i went with the flag.

3rd way (and possibly the cleanest) would be to additionally to 2) add 
something like a 'skipOnParentInvocation' flag to the single assembly XMLs.

LieGrue,
strub



- Ursprüngliche Mail 
  

Von: Brian Fox bri...@infinity.nu
An: dev@maven.apache.org
Gesendet: Dienstag, den 5. Mai 2009, 03:01:25 Uhr
Betreff: Update on ASF Release requirements

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 in the assembly plugin would allow both cases to work without 
changing the poms, because the goal would skip in any project that doesn't match 
where Maven was executed (!session.getExecutionRootDir().equals(basedir))


Eventually if we get this perfected, it would be appropriate to bump up to the 
Apache pom so it would just work out of the box for most projects. Since we may 
have to adjust the archive contents down the road, we should make the descriptor 
separate from the plugin itself. This can be done by producing a jar that 
contains an Apache Source Bundle descriptor, and adding this to the assembly 
plugin classpath in the execution. This will allow us to release this 
independent and it would also make it easier for projects to override the 
descriptor in their projects as needed.


I'll also add a skip property specific to this execution in the release profile 
to allow projects that have existing source archives to be unaffected.


To make this happen

Update on ASF Release requirements

2009-05-04 Thread Brian Fox

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 in the assembly plugin would allow both cases to work 
without changing the poms, because the goal would skip in any project 
that doesn't match where Maven was executed 
(!session.getExecutionRootDir().equals(basedir))


Eventually if we get this perfected, it would be appropriate to bump up 
to the Apache pom so it would just work out of the box for most 
projects. Since we may have to adjust the archive contents down the 
road, we should make the descriptor separate from the plugin itself. 
This can be done by producing a jar that contains an Apache Source 
Bundle descriptor, and adding this to the assembly plugin classpath in 
the execution. This will allow us to release this independent and it 
would also make it easier for projects to override the descriptor in 
their projects as needed.


I'll also add a skip property specific to this execution in the release 
profile to allow projects that have existing source archives to be 
unaffected.


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?


-
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

2009-05-04 Thread Brett Porter



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

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

Re: Update on ASF Release requirements

AW: Update on ASF Release requirements

Re: AW: Update on ASF Release requirements

Update on ASF Release requirements

Re: Update on ASF Release requirements

34 matches

Site Navigation

Mail list logo

Footer information