You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Steve Loughran <st...@apache.org> on 2006/09/20 15:04:41 UTC
Re: [VOTE] Muse 2.0.0 release
Daniel Jemiolo wrote:
> The Muse development team has worked hard over the spring and summer
> months, enhancing, refactoring, fixing, and polishing the 2.x code base,
> and the time has come to vote on a release for version 2.0.0. I am very
> proud of the members of our team - both the committers who have
> contributed and taken responsibility for large sections of code, and
> non-committers who have rolled up their sleeves and wrestled with the
> code, samples, and build artifacts until the project met the
expectations
> we had set for it. I'm also excited to see other open source projects
> already using our code, as it gives us fresh perspectives on how to make
> WSRF and WSDM easier for other programmers.
>
> To the committers and PMC members: please cast your vote on the
release of
> Muse 2.0.0, the artifacts for which are found here:
>
> http://www.apache.org/~danj/muse/2.0.0
>
> Here's my +1 for this release.
>
Daniel,
I'm going to vote -1 until the binaries dont include any dependent jars
marked -SNAPSHOT
We had this problem with muse 1.0, which also shipped using -SNAPSHOT
libraries. It was impossible for anyone else to rebuild the application.
you take the source as supplied, point maven at it, and end up pulling
down different artifacts which may not link, and if they do, may not
work correctly. It also raises problems downstream with support calks.
If axiom-on-muse fails, who do I take this up with? Muse will bounce to
Axiom, axiom will say 'old snapshot, not supported, go away'.
I raised this issue with the muse 1.0 team in personal emails, and have
just reviewed the 2.0 .zip file to see if the problem has gone away. It
hasnt.
In an ideal world, a project would not release with dependencies on
anything other than supported, x.0 artifacts, just as in an ideal world
standards cannot depend on anything other than stable release of other
standards. Given that WSN must go down in OASIS history as the first
specification to depend on two different draft versions of another spec,
namely WS-A 2003/03 and WSA 2004/04, you will surely appreciate the
value in having stable and consistent underpinnings.
If the -SNAPSHOT artifacts can be dated and the ant/maven build which
ships with the source includes these dated artifacts such that I can do
a build from that source snapshot and have .class files that match those
of the release, then I will vote +1.
Please dont take this as any fault of the muse 2.0 release itself; I
look forward to interop testing a public endpoint against my Alpine
stack. I just dont want us to ship out as a point release something that
end users cannot rebuild. If we do that, we have lost the downstream
developer community.
-Steve
cc:d the maven dev list to emphasise that somehow this needs to be
addressed. the ease of pulling in snapshots of other projects means that
people tend to do it at release time. kept the muse-dev and -user lists,
but I'm not sure if they will get through as I am not subscribing to them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Muse 2.0.0 release
Posted by Steve Loughran <st...@apache.org>.
Jason van Zyl wrote:
>
> On 20 Sep 06, at 3:04 PM 20 Sep 06, Steve Loughran wrote:
>
>> Daniel Jemiolo wrote:
>> > The Muse development team has worked hard over the spring and summer
>> > months, enhancing, refactoring, fixing, and polishing the 2.x code
>> base,
>> > and the time has come to vote on a release for version 2.0.0. I am very
>> > proud of the members of our team - both the committers who have
>> > contributed and taken responsibility for large sections of code, and
>> > non-committers who have rolled up their sleeves and wrestled with the
>> > code, samples, and build artifacts until the project met the
>> expectations
>> > we had set for it. I'm also excited to see other open source projects
>> > already using our code, as it gives us fresh perspectives on how to
>> make
>> > WSRF and WSDM easier for other programmers.
>> >
>> > To the committers and PMC members: please cast your vote on the
>> release of
>> > Muse 2.0.0, the artifacts for which are found here:
>> >
>> > http://www.apache.org/~danj/muse/2.0.0
>> >
>> > Here's my +1 for this release.
>> >
>>
>> Daniel,
>>
>> I'm going to vote -1 until the binaries dont include any dependent
>> jars marked -SNAPSHOT
>>
>
> This problem can easily be alleviated using the release plugin. I also
> had an experience the other day that leads me to believe that official
> releases should be barred unless you use the release plugin. Exposing
> the options to enable release info should be turned off. Usually it's
> inadvertent but it happens all the time. I was helping Dan (Xfire) the
> other day and he did a release by enabling the updateReleaseInfo
> property so he release the JARs only. The sources and javadoc did not go
> up which is bad. There should only be one way to do a release and the
> release should go through archiva which could detect the intactness of a
> release. Releases without sources or Javadocs should just get rejected,
> and if the release plugin is used it's impossible for SNAPSHOTs to slip
> through. As far as releases go, if projects don't use the release plugin
> it's not a release.
+1 to that.
Perhaps the Apache repository could somehow detect which artifacts had
been tagged as formally released, or at least approved by archiva. Of
course, non-maven projects still have the right to update content, but
their stuff may need to go through some staging process before it is
accepted as legitimate.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Muse 2.0.0 release
Posted by Jason van Zyl <ja...@maven.org>.
On 20 Sep 06, at 3:04 PM 20 Sep 06, Steve Loughran wrote:
> Daniel Jemiolo wrote:
> > The Muse development team has worked hard over the spring and summer
> > months, enhancing, refactoring, fixing, and polishing the 2.x
> code base,
> > and the time has come to vote on a release for version 2.0.0. I
> am very
> > proud of the members of our team - both the committers who have
> > contributed and taken responsibility for large sections of code, and
> > non-committers who have rolled up their sleeves and wrestled with
> the
> > code, samples, and build artifacts until the project met the
> expectations
> > we had set for it. I'm also excited to see other open source
> projects
> > already using our code, as it gives us fresh perspectives on how
> to make
> > WSRF and WSDM easier for other programmers.
> >
> > To the committers and PMC members: please cast your vote on the
> release of
> > Muse 2.0.0, the artifacts for which are found here:
> >
> > http://www.apache.org/~danj/muse/2.0.0
> >
> > Here's my +1 for this release.
> >
>
> Daniel,
>
> I'm going to vote -1 until the binaries dont include any dependent
> jars marked -SNAPSHOT
>
This problem can easily be alleviated using the release plugin. I
also had an experience the other day that leads me to believe that
official releases should be barred unless you use the release plugin.
Exposing the options to enable release info should be turned off.
Usually it's inadvertent but it happens all the time. I was helping
Dan (Xfire) the other day and he did a release by enabling the
updateReleaseInfo property so he release the JARs only. The sources
and javadoc did not go up which is bad. There should only be one way
to do a release and the release should go through archiva which could
detect the intactness of a release. Releases without sources or
Javadocs should just get rejected, and if the release plugin is used
it's impossible for SNAPSHOTs to slip through. As far as releases go,
if projects don't use the release plugin it's not a release.
> We had this problem with muse 1.0, which also shipped using -
> SNAPSHOT libraries. It was impossible for anyone else to rebuild
> the application. you take the source as supplied, point maven at
> it, and end up pulling down different artifacts which may not link,
> and if they do, may not work correctly. It also raises problems
> downstream with support calks. If axiom-on-muse fails, who do I
> take this up with? Muse will bounce to Axiom, axiom will say 'old
> snapshot, not supported, go away'.
>
> I raised this issue with the muse 1.0 team in personal emails, and
> have just reviewed the 2.0 .zip file to see if the problem has gone
> away. It hasnt.
>
> In an ideal world, a project would not release with dependencies on
> anything other than supported, x.0 artifacts, just as in an ideal
> world standards cannot depend on anything other than stable release
> of other standards. Given that WSN must go down in OASIS history as
> the first specification to depend on two different draft versions
> of another spec, namely WS-A 2003/03 and WSA 2004/04, you will
> surely appreciate the value in having stable and consistent
> underpinnings.
>
> If the -SNAPSHOT artifacts can be dated and the ant/maven build
> which ships with the source includes these dated artifacts such
> that I can do a build from that source snapshot and have .class
> files that match those of the release, then I will vote +1.
>
> Please dont take this as any fault of the muse 2.0 release itself;
> I look forward to interop testing a public endpoint against my
> Alpine stack. I just dont want us to ship out as a point release
> something that end users cannot rebuild. If we do that, we have
> lost the downstream developer community.
>
> -Steve
>
> cc:d the maven dev list to emphasise that somehow this needs to be
> addressed. the ease of pulling in snapshots of other projects means
> that people tend to do it at release time. kept the muse-dev and -
> user lists, but I'm not sure if they will get through as I am not
> subscribing to them.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Jason van Zyl
jason@maven.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Muse 2.0.0 release
Posted by Jason van Zyl <ja...@maven.org>.
On 20 Sep 06, at 3:43 PM 20 Sep 06, Daniel Jemiolo wrote:
> Hi Steve,
>
> Thanks for taking the time to check out our project. The SNAPSHOT jars
> that are in Muse are from Axis2 - we are dependent on fixes that
> happened
> post-1.0, and the 1.1 version is not out yet.
You can still use timestamped versions or you can get access to make
an interim release.
> We only included the Axis2
> WAR as a convenience to people who wanted to use the code generation
> tooling (it generates a complete Axis2 project, not just Java
> code). We
> could modify the build to not include the Axis2 WAR and ask people to
> download it themselves if that would help.
That's probably inconvenient for your users. You just need to create
artifacts with versions which are not subject to arbitrary changes.
SNAPSHOTs are subject to arbitrary changes which makes the build
unstable for your users.
>
> Thanks,
> Dan
>
>
>
>
>
> Steve Loughran <st...@apache.org>
> 09/20/2006 09:04 AM
> Please respond to
> muse-user@ws.apache.org
>
>
> To
> private@ws.apache.org, Daniel Jemiolo/Durham/IBM@IBMUS
> cc
> muse-dev@ws.apache.org, muse-user@ws.apache.org, Maven Developers List
> <de...@maven.apache.org>
> Subject
> Re: [VOTE] Muse 2.0.0 release
>
>
>
>
>
>
> Daniel Jemiolo wrote:
>> The Muse development team has worked hard over the spring and summer
>> months, enhancing, refactoring, fixing, and polishing the 2.x code
> base,
>> and the time has come to vote on a release for version 2.0.0. I am
>> very
>> proud of the members of our team - both the committers who have
>> contributed and taken responsibility for large sections of code, and
>> non-committers who have rolled up their sleeves and wrestled with the
>> code, samples, and build artifacts until the project met the
> expectations
>> we had set for it. I'm also excited to see other open source projects
>> already using our code, as it gives us fresh perspectives on how to
> make
>> WSRF and WSDM easier for other programmers.
>>
>> To the committers and PMC members: please cast your vote on the
> release of
>> Muse 2.0.0, the artifacts for which are found here:
>>
>> http://www.apache.org/~danj/muse/2.0.0
>>
>> Here's my +1 for this release.
>>
>
> Daniel,
>
> I'm going to vote -1 until the binaries dont include any dependent
> jars
> marked -SNAPSHOT
>
> We had this problem with muse 1.0, which also shipped using -SNAPSHOT
> libraries. It was impossible for anyone else to rebuild the
> application.
> you take the source as supplied, point maven at it, and end up pulling
> down different artifacts which may not link, and if they do, may not
> work correctly. It also raises problems downstream with support calks.
> If axiom-on-muse fails, who do I take this up with? Muse will
> bounce to
> Axiom, axiom will say 'old snapshot, not supported, go away'.
>
> I raised this issue with the muse 1.0 team in personal emails, and
> have
> just reviewed the 2.0 .zip file to see if the problem has gone
> away. It
> hasnt.
>
> In an ideal world, a project would not release with dependencies on
> anything other than supported, x.0 artifacts, just as in an ideal
> world
> standards cannot depend on anything other than stable release of other
> standards. Given that WSN must go down in OASIS history as the first
> specification to depend on two different draft versions of another
> spec,
> namely WS-A 2003/03 and WSA 2004/04, you will surely appreciate the
> value in having stable and consistent underpinnings.
>
> If the -SNAPSHOT artifacts can be dated and the ant/maven build which
> ships with the source includes these dated artifacts such that I
> can do
> a build from that source snapshot and have .class files that match
> those
> of the release, then I will vote +1.
>
> Please dont take this as any fault of the muse 2.0 release itself; I
> look forward to interop testing a public endpoint against my Alpine
> stack. I just dont want us to ship out as a point release something
> that
> end users cannot rebuild. If we do that, we have lost the downstream
> developer community.
>
> -Steve
>
> cc:d the maven dev list to emphasise that somehow this needs to be
> addressed. the ease of pulling in snapshots of other projects means
> that
> people tend to do it at release time. kept the muse-dev and -user
> lists,
> but I'm not sure if they will get through as I am not subscribing
> to them.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Jason van Zyl
jason@maven.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [VOTE] Muse 2.0.0 release
Posted by Daniel Jemiolo <da...@us.ibm.com>.
Hi Steve,
Thanks for taking the time to check out our project. The SNAPSHOT jars
that are in Muse are from Axis2 - we are dependent on fixes that happened
post-1.0, and the 1.1 version is not out yet. We only included the Axis2
WAR as a convenience to people who wanted to use the code generation
tooling (it generates a complete Axis2 project, not just Java code). We
could modify the build to not include the Axis2 WAR and ask people to
download it themselves if that would help.
Thanks,
Dan
Steve Loughran <st...@apache.org>
09/20/2006 09:04 AM
Please respond to
muse-user@ws.apache.org
To
private@ws.apache.org, Daniel Jemiolo/Durham/IBM@IBMUS
cc
muse-dev@ws.apache.org, muse-user@ws.apache.org, Maven Developers List
<de...@maven.apache.org>
Subject
Re: [VOTE] Muse 2.0.0 release
Daniel Jemiolo wrote:
> The Muse development team has worked hard over the spring and summer
> months, enhancing, refactoring, fixing, and polishing the 2.x code
base,
> and the time has come to vote on a release for version 2.0.0. I am very
> proud of the members of our team - both the committers who have
> contributed and taken responsibility for large sections of code, and
> non-committers who have rolled up their sleeves and wrestled with the
> code, samples, and build artifacts until the project met the
expectations
> we had set for it. I'm also excited to see other open source projects
> already using our code, as it gives us fresh perspectives on how to
make
> WSRF and WSDM easier for other programmers.
>
> To the committers and PMC members: please cast your vote on the
release of
> Muse 2.0.0, the artifacts for which are found here:
>
> http://www.apache.org/~danj/muse/2.0.0
>
> Here's my +1 for this release.
>
Daniel,
I'm going to vote -1 until the binaries dont include any dependent jars
marked -SNAPSHOT
We had this problem with muse 1.0, which also shipped using -SNAPSHOT
libraries. It was impossible for anyone else to rebuild the application.
you take the source as supplied, point maven at it, and end up pulling
down different artifacts which may not link, and if they do, may not
work correctly. It also raises problems downstream with support calks.
If axiom-on-muse fails, who do I take this up with? Muse will bounce to
Axiom, axiom will say 'old snapshot, not supported, go away'.
I raised this issue with the muse 1.0 team in personal emails, and have
just reviewed the 2.0 .zip file to see if the problem has gone away. It
hasnt.
In an ideal world, a project would not release with dependencies on
anything other than supported, x.0 artifacts, just as in an ideal world
standards cannot depend on anything other than stable release of other
standards. Given that WSN must go down in OASIS history as the first
specification to depend on two different draft versions of another spec,
namely WS-A 2003/03 and WSA 2004/04, you will surely appreciate the
value in having stable and consistent underpinnings.
If the -SNAPSHOT artifacts can be dated and the ant/maven build which
ships with the source includes these dated artifacts such that I can do
a build from that source snapshot and have .class files that match those
of the release, then I will vote +1.
Please dont take this as any fault of the muse 2.0 release itself; I
look forward to interop testing a public endpoint against my Alpine
stack. I just dont want us to ship out as a point release something that
end users cannot rebuild. If we do that, we have lost the downstream
developer community.
-Steve
cc:d the maven dev list to emphasise that somehow this needs to be
addressed. the ease of pulling in snapshots of other projects means that
people tend to do it at release time. kept the muse-dev and -user lists,
but I'm not sure if they will get through as I am not subscribing to them.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
Re: [VOTE] Muse 2.0.0 release
Posted by Daniel Jemiolo <da...@us.ibm.com>.
Hi Steve,
Thanks for taking the time to check out our project. The SNAPSHOT jars
that are in Muse are from Axis2 - we are dependent on fixes that happened
post-1.0, and the 1.1 version is not out yet. We only included the Axis2
WAR as a convenience to people who wanted to use the code generation
tooling (it generates a complete Axis2 project, not just Java code). We
could modify the build to not include the Axis2 WAR and ask people to
download it themselves if that would help.
Thanks,
Dan
Steve Loughran <st...@apache.org>
09/20/2006 09:04 AM
Please respond to
muse-user@ws.apache.org
To
private@ws.apache.org, Daniel Jemiolo/Durham/IBM@IBMUS
cc
muse-dev@ws.apache.org, muse-user@ws.apache.org, Maven Developers List
<de...@maven.apache.org>
Subject
Re: [VOTE] Muse 2.0.0 release
Daniel Jemiolo wrote:
> The Muse development team has worked hard over the spring and summer
> months, enhancing, refactoring, fixing, and polishing the 2.x code
base,
> and the time has come to vote on a release for version 2.0.0. I am very
> proud of the members of our team - both the committers who have
> contributed and taken responsibility for large sections of code, and
> non-committers who have rolled up their sleeves and wrestled with the
> code, samples, and build artifacts until the project met the
expectations
> we had set for it. I'm also excited to see other open source projects
> already using our code, as it gives us fresh perspectives on how to
make
> WSRF and WSDM easier for other programmers.
>
> To the committers and PMC members: please cast your vote on the
release of
> Muse 2.0.0, the artifacts for which are found here:
>
> http://www.apache.org/~danj/muse/2.0.0
>
> Here's my +1 for this release.
>
Daniel,
I'm going to vote -1 until the binaries dont include any dependent jars
marked -SNAPSHOT
We had this problem with muse 1.0, which also shipped using -SNAPSHOT
libraries. It was impossible for anyone else to rebuild the application.
you take the source as supplied, point maven at it, and end up pulling
down different artifacts which may not link, and if they do, may not
work correctly. It also raises problems downstream with support calks.
If axiom-on-muse fails, who do I take this up with? Muse will bounce to
Axiom, axiom will say 'old snapshot, not supported, go away'.
I raised this issue with the muse 1.0 team in personal emails, and have
just reviewed the 2.0 .zip file to see if the problem has gone away. It
hasnt.
In an ideal world, a project would not release with dependencies on
anything other than supported, x.0 artifacts, just as in an ideal world
standards cannot depend on anything other than stable release of other
standards. Given that WSN must go down in OASIS history as the first
specification to depend on two different draft versions of another spec,
namely WS-A 2003/03 and WSA 2004/04, you will surely appreciate the
value in having stable and consistent underpinnings.
If the -SNAPSHOT artifacts can be dated and the ant/maven build which
ships with the source includes these dated artifacts such that I can do
a build from that source snapshot and have .class files that match those
of the release, then I will vote +1.
Please dont take this as any fault of the muse 2.0 release itself; I
look forward to interop testing a public endpoint against my Alpine
stack. I just dont want us to ship out as a point release something that
end users cannot rebuild. If we do that, we have lost the downstream
developer community.
-Steve
cc:d the maven dev list to emphasise that somehow this needs to be
addressed. the ease of pulling in snapshots of other projects means that
people tend to do it at release time. kept the muse-dev and -user lists,
but I'm not sure if they will get through as I am not subscribing to them.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
Re: [VOTE] Muse 2.0.0 release
Posted by Daniel Jemiolo <da...@us.ibm.com>.
Hi Steve,
Thanks for taking the time to check out our project. The SNAPSHOT jars
that are in Muse are from Axis2 - we are dependent on fixes that happened
post-1.0, and the 1.1 version is not out yet. We only included the Axis2
WAR as a convenience to people who wanted to use the code generation
tooling (it generates a complete Axis2 project, not just Java code). We
could modify the build to not include the Axis2 WAR and ask people to
download it themselves if that would help.
Thanks,
Dan
Steve Loughran <st...@apache.org>
09/20/2006 09:04 AM
Please respond to
muse-user@ws.apache.org
To
private@ws.apache.org, Daniel Jemiolo/Durham/IBM@IBMUS
cc
muse-dev@ws.apache.org, muse-user@ws.apache.org, Maven Developers List
<de...@maven.apache.org>
Subject
Re: [VOTE] Muse 2.0.0 release
Daniel Jemiolo wrote:
> The Muse development team has worked hard over the spring and summer
> months, enhancing, refactoring, fixing, and polishing the 2.x code
base,
> and the time has come to vote on a release for version 2.0.0. I am very
> proud of the members of our team - both the committers who have
> contributed and taken responsibility for large sections of code, and
> non-committers who have rolled up their sleeves and wrestled with the
> code, samples, and build artifacts until the project met the
expectations
> we had set for it. I'm also excited to see other open source projects
> already using our code, as it gives us fresh perspectives on how to
make
> WSRF and WSDM easier for other programmers.
>
> To the committers and PMC members: please cast your vote on the
release of
> Muse 2.0.0, the artifacts for which are found here:
>
> http://www.apache.org/~danj/muse/2.0.0
>
> Here's my +1 for this release.
>
Daniel,
I'm going to vote -1 until the binaries dont include any dependent jars
marked -SNAPSHOT
We had this problem with muse 1.0, which also shipped using -SNAPSHOT
libraries. It was impossible for anyone else to rebuild the application.
you take the source as supplied, point maven at it, and end up pulling
down different artifacts which may not link, and if they do, may not
work correctly. It also raises problems downstream with support calks.
If axiom-on-muse fails, who do I take this up with? Muse will bounce to
Axiom, axiom will say 'old snapshot, not supported, go away'.
I raised this issue with the muse 1.0 team in personal emails, and have
just reviewed the 2.0 .zip file to see if the problem has gone away. It
hasnt.
In an ideal world, a project would not release with dependencies on
anything other than supported, x.0 artifacts, just as in an ideal world
standards cannot depend on anything other than stable release of other
standards. Given that WSN must go down in OASIS history as the first
specification to depend on two different draft versions of another spec,
namely WS-A 2003/03 and WSA 2004/04, you will surely appreciate the
value in having stable and consistent underpinnings.
If the -SNAPSHOT artifacts can be dated and the ant/maven build which
ships with the source includes these dated artifacts such that I can do
a build from that source snapshot and have .class files that match those
of the release, then I will vote +1.
Please dont take this as any fault of the muse 2.0 release itself; I
look forward to interop testing a public endpoint against my Alpine
stack. I just dont want us to ship out as a point release something that
end users cannot rebuild. If we do that, we have lost the downstream
developer community.
-Steve
cc:d the maven dev list to emphasise that somehow this needs to be
addressed. the ease of pulling in snapshots of other projects means that
people tend to do it at release time. kept the muse-dev and -user lists,
but I'm not sure if they will get through as I am not subscribing to them.
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org