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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Jason van Zyl
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
