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 <[EMAIL PROTECTED]>
09/20/2006 09:04 AM
Please respond to
muse-user@ws.apache.org
To
[EMAIL PROTECTED], Daniel Jemiolo/Durham/[EMAIL PROTECTED]
cc
muse-dev@ws.apache.org, muse-user@ws.apache.org, Maven Developers List
<dev@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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
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]
