You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@apache.org> on 2006/03/28 23:13:16 UTC
Apache Jackrabbit 1.0 release candidate 3
Hi,
The Apache Jackrabbit 1.0 release candidate 3 can be found at:
http://people.apache.org/~jukka/jackrabbit/1.0-rc3/
See the RELEASE-NOTES.txt for more details about the release contents.
The key used to sign the releases can be found at:
http://people.apache.org/~jukka/jackrabbit/KEYS
This release candidate contains fixes for the blocker policy issues
(JCR-356, JCR-357, and JCR-373), one major bug fix (JCR-257) and a
number of other low-risk fixes and improvements. The list of changes
since 1.0-rc2 is:
[JCR-375] jcr:encoding not respected in NodeIndexer
[JCR-373] all references to incubator need to be replaced with new ...
[JCR-370] SearchIndex class contains garbled String
[JCR-368] Add support for simple test cases
[JCR-365] Web client/WebDAV fails to unescape workspace names
[JCR-357] Move to jackrabbit.apache.org
[JCR-356] Replace license headers with new policy text
[JCR-353] TransientRepository does not shutdown if first login fails
[JCR-338] Query Builder and jcr:deref problem. Can't add predicate ...
[JCR-333] NodeTypeDef depends on supertype ordering
[JCR-257] Use separate index for jcr:system tree
There are no more pending 1.0 issues, so I'm hoping to start the 1.0
release vote based on this release candidate as soon as the JSR-170
conformance test results are in and given that no unexpected problems
have been reported.
NOTE: It is a known issue that the test suite reports two observation
unit test failures. This is mentioned in the release notes and
recorded as issue JCR-374.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 3/29/06, Alexandru Popescu <th...@gmail.com> wrote:
> 1. Why the JCA distro has only the src?
Oops, I hadn't uploaded the generated rar file. I also noticed some
small dependency mistakes in the release, so I'll make a fresh upload
in a moment.
> 2. What is the server.war?
It's one of the jcr-server packages. The war file is generated without
a version number.
> 3. Why jcr-client and jcr-webdav are distributed only as binary?
They are (in addition to jcr-server.jar and jackrabbit-server.war)
built from the jcr-server-src.jar. See the RELEASE-NOTES.txt for
information on which -src file generates which binary files.
> Any pointers to where I can read about this distros is perfect for me, and
> sorry if you answered these questions too many times.
No problem, I much appreciate the feedback! See the RELEASE-NOTES.txt
file for an overview of the release contents.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Alexandru Popescu <th...@gmail.com>.
Congrats once again!
Probably these has been asked in the past but I cannot find any reference to
it.
1. Why the JCA distro has only the src?
2. What is the server.war?
3. Why jcr-client and jcr-webdav are distributed only as binary?
Any pointers to where I can read about this distros is perfect for me, and
sorry if you answered these questions too many times.
./alex
--
.w( the_mindstorm )p.
On 3/29/06, Jukka Zitting <ju...@apache.org> wrote:
>
> Hi,
>
> The Apache Jackrabbit 1.0 release candidate 3 can be found at:
>
> http://people.apache.org/~jukka/jackrabbit/1.0-rc3/
>
> See the RELEASE-NOTES.txt for more details about the release contents.
>
> The key used to sign the releases can be found at:
>
> http://people.apache.org/~jukka/jackrabbit/KEYS
>
> This release candidate contains fixes for the blocker policy issues
> (JCR-356, JCR-357, and JCR-373), one major bug fix (JCR-257) and a
> number of other low-risk fixes and improvements. The list of changes
> since 1.0-rc2 is:
>
> [JCR-375] jcr:encoding not respected in NodeIndexer
> [JCR-373] all references to incubator need to be replaced with new ...
> [JCR-370] SearchIndex class contains garbled String
> [JCR-368] Add support for simple test cases
> [JCR-365] Web client/WebDAV fails to unescape workspace names
> [JCR-357] Move to jackrabbit.apache.org
> [JCR-356] Replace license headers with new policy text
> [JCR-353] TransientRepository does not shutdown if first login fails
> [JCR-338] Query Builder and jcr:deref problem. Can't add predicate ...
> [JCR-333] NodeTypeDef depends on supertype ordering
> [JCR-257] Use separate index for jcr:system tree
>
> There are no more pending 1.0 issues, so I'm hoping to start the 1.0
> release vote based on this release candidate as soon as the JSR-170
> conformance test results are in and given that no unexpected problems
> have been reported.
>
> NOTE: It is a known issue that the test suite reports two observation
> unit test failures. This is mentioned in the release notes and
> recorded as issue JCR-374.
>
> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 3/29/06, Angela Schreiber <an...@day.com> wrote:
> sure. my concerns didn't touch the jackrabbit prefix.
> only the 'webdav' part :))
Excellent, I'll go on and change the names as suggested.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Angela Schreiber <an...@day.com>.
hi jukka
> Good point. I still think that Roy's point about Jackrabbit branding
> applies, so adding the jackrabbit prefix would make sense.
sure. my concerns didn't touch the jackrabbit prefix.
only the 'webdav' part :))
> Just adding the prefix (and a version number to the war) would give us:
> jackrabbit-jcr-server-1.0-src.jar
>
> jackrabbit-jcr-webdav-1.0.jar
> jackrabbit-jcr-client-1.0.jar
> jackrabbit-jcr-server-1.0.jar
> jackrabbit-server-1.0.war
>
> Would you be OK with this?
yes. fine with me.
>>perhaps there are simply too much things in a
>>single project.
> Agreed, it might be clearer to better separate the subprojects, but
> there's no point rushing that.
oh no :))... i just wanted to explain my concerns. in
addition i think this should be a point to be addressed
in the future. no pressure whatsoever.
the project simply turned from the original 'jcr-server'
for general jcr-remoting (dav as an example only) into multi
target thing, with the 'simple server' getting a project
of its own (not so simple any more). ;)
kind regards
angela
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 3/29/06, Torgeir Veimo <to...@pobox.com> wrote:
> On Wed, 2006-03-29 at 16:49 +0300, Jukka Zitting wrote:
> > jackrabbit-jcr-server-1.0-src.jar
> >
> > jackrabbit-jcr-webdav-1.0.jar
> > jackrabbit-jcr-client-1.0.jar
> > jackrabbit-jcr-server-1.0.jar
> > jackrabbit-server-1.0.war
>
> What do I download as a total newbie?
That depends on what you want:
* You want a deployable Jackrabbit installation with WebDAV and
optional RMI support? Download jackrabbit-server-1.0.war.
* You want to add webdav support to your existing JCR implementation?
Download all the jar files.
* You want to use a generic webdav library as a dependency in some
other project? Download jackrabbit-jcr-webdav-1.0.jar.
I agree that there isn't much in the way of documentation about these
things, but that will hopefully improve by time.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Torgeir Veimo <to...@pobox.com>.
On Wed, 2006-03-29 at 16:49 +0300, Jukka Zitting wrote:
>
> jackrabbit-jcr-server-1.0-src.jar
>
> jackrabbit-jcr-webdav-1.0.jar
> jackrabbit-jcr-client-1.0.jar
> jackrabbit-jcr-server-1.0.jar
> jackrabbit-server-1.0.war
What do I download as a total newbie?
--
Torgeir Veimo <to...@pobox.com>
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 3/29/06, Angela Schreiber <an...@day.com> wrote:
> >>> jackrabbit-jcr-webdav
>
> > Do you prefer jackrabbit-jcr-server?
>
> yes... not because i think its a very good name.
> but 'jackrabbit-jcr-webdav' focus too much on
> the webdav part. the aim of the original contrib
> was not focused on webdav (see the 'webapp' project).
Good point. I still think that Roy's point about Jackrabbit branding
applies, so adding the jackrabbit prefix would make sense. Just adding
the prefix (and a version number to the war) would give us:
jackrabbit-jcr-server-1.0-src.jar
jackrabbit-jcr-webdav-1.0.jar
jackrabbit-jcr-client-1.0.jar
jackrabbit-jcr-server-1.0.jar
jackrabbit-server-1.0.war
Would you be OK with this?
> perhaps there are simply too much things in a
> single project. but i would rather keep the
> current name and think about a meaningful split
> of webdav and non-webdav as well as jcr- and
> non-jcr-specific parts for a next release.
Agreed, it might be clearer to better separate the subprojects, but
there's no point rushing that.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Angela Schreiber <an...@day.com>.
>>> jackrabbit-jcr-webdav
> Do you prefer jackrabbit-jcr-server?
yes... not because i think its a very good name.
but 'jackrabbit-jcr-webdav' focus too much on
the webdav part. the aim of the original contrib
was not focused on webdav (see the 'webapp' project).
similarly, the dav library has nothing to do with
jackrabbit (nor with jcr). so jackrabbit-jcr-webdav
would point in a wrong direction.
perhaps there are simply too much things in a
single project. but i would rather keep the
current name and think about a meaningful split
of webdav and non-webdav as well as jcr- and
non-jcr-specific parts for a next release.
regards
angela
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 3/29/06, Angela Schreiber <an...@day.com> wrote:
> > jackrabbit-jcr-webdav
>
> i'm not totally convinced about this one...
Do you prefer jackrabbit-jcr-server?
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Angela Schreiber <an...@day.com>.
hi
> That's reasonable. I'll go and change the names unless anyone objects.
> While doing that I'd also like to change the svn paths to match the
> project names. The svn trunk (and branches/1.0) would then look like
> this:
>
> jackrabbit-jcr-webdav
i'm not totally convinced about this one...
regards
angela
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 3/29/06, Roy T. Fielding <fi...@gbiv.com> wrote:
> We should be prefixing all of the files with jackrabbit-.
> I know that the jcr-* packages are usable with any JCR
> implementation, but the jackrabbit- prefix applies to everything
> produced in this project (not just the repository). Its a
> brand thing (and name collision avoidance as well).
That's reasonable. I'll go and change the names unless anyone objects.
While doing that I'd also like to change the svn paths to match the
project names. The svn trunk (and branches/1.0) would then look like
this:
jackrabbit-core
jackrabbit-index-filters
jackrabbit-jca
jackrabbit-jcr-rmi
jackrabbit-jcr-webdav
contrib
> Also, the package naming remains incoherent to me. I can't imagine
> what it would look like to a new user, especially since there is
> no documentation for the former contrib projects.
>
> Here is what I suggest for making the names coherent:
Looks good, I'll adopt that.
> Should we be marking the non-core projects as alpha releases?
> It seems very strange to me to be releasing software without
> any documentation.
I believe we should release those projects as they are pretty stable
and have a number of users judging from the number of mailing list
discussions and Jira issues. Having a released version makes it easier
to track down reported issues and also encourages users to stick with
a known good version. I also believe that more users will bring us
more documentation.
I'd also like to keep the version numbering in sync so that we don't
have separate release cycles for the non-core projects at least for
now. The best way to mark this status would IMHO be something like the
following added to the release notes:
This release contains the following modules in addition to the
Apache Jackrabbit
core. They contain extra functionality that can be used with
either Apache Jackrabbit
core or any JCR compliant content repository. These modules should
be considered
alpha quality.
> > There are no more pending 1.0 issues, so I'm hoping to start the 1.0
> > release vote based on this release candidate as soon as the JSR-170
> > conformance test results are in and given that no unexpected problems
> > have been reported.
>
> Right, here is another versioning issue then. We only vote to
> release complete and signed jar/tarballs. We can't actually have a
> vote on something called 1.0-rc3 because it wouldn't be a candidate
> if it gets approved, and we can't change the contents after it has
> been approved because then we would have to do all the testing again.
My intention with "based on this release candidate" was not to have
the release vote on 1.0-rc3, but that the only changes between 1.0-rc3
and 1.0 would be the version number change and other minor tweaks that
don't affect any of the functionality. The reasoning for this to make
the release vote smoother as the exact functionality has already been
tested by more than one person. I'm sorry for the misleading sentence.
> That is why we have three version numbers. Let's just stop using
> rcX and call the next set of jars 1.0.4. The first release doesn't
> have to end in 0 -- version numbers are free (and all versioned jars
> are release candidates).
-1 That would be very confusing in my mind. The -rcX suffix makes it
explicit that the package hasn't been officially approved as a
release. Otherwise someone with 1.0.3 and 1.0.4 packages has no clear
way to determine which one was officially released.
> OT: why does jcr-rmi have a dependency on commons-logging?
Hmm, good point. It was introduced a while ago in one of Felix's
contributions and I never really got worried about it as I always run
my RMI server from within Tomcat that has the commons-logging classes
already available. I'll remove that dependency.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Alexandru Popescu <th...@gmail.com>.
Outside pov:
1/ namings: I don't understand what is the jackrabbit-core and what is
jackrabbit-jcr-commons, and a newbie would definitely look for jackrabbit
distribution. Probably, I would understand the renaming jackrabbit-commons
to jackrabbit-jcr-X. The other names are oke with me (ohh, just another one:
why change textfilters to index-filters?)
2/ versioning: imo 1.0.4 is something that comes after a 1.0 version which
is a major version. Moreover an 1.0.x is usually a bug fix for the
1.0version. But so far there was no
1.0 release. Moreover, I think the document discribing the versioning policy
is very good and would give everybody the level of understanding needed.
A project should be able to mark pre-release versions: like dev, beta, rc.
Without this, everybody would consider that the distribution is a
good/tested/validated releases that can be dropped in production.
Unfortunately, I don't think this is true.
hth,
./alex
--
.w( the_mindstorm )p.
On 3/29/06, Roy T. Fielding <fi...@gbiv.com> wrote:
>
> On Mar 28, 2006, at 1:13 PM, Jukka Zitting wrote:
> > The Apache Jackrabbit 1.0 release candidate 3 can be found at:
> >
> > http://people.apache.org/~jukka/jackrabbit/1.0-rc3/
> >
> > See the RELEASE-NOTES.txt for more details about the release contents.
>
> Hmm. This is getting a little hairy.
>
> We should be prefixing all of the files with jackrabbit-.
> I know that the jcr-* packages are usable with any JCR
> implementation, but the jackrabbit- prefix applies to everything
> produced in this project (not just the repository). Its a
> brand thing (and name collision avoidance as well).
>
> Also, the package naming remains incoherent to me. I can't imagine
> what it would look like to a new user, especially since there is
> no documentation for the former contrib projects.
>
> Here is what I suggest for making the names coherent:
>
> * Jackrabbit content repository and general-purpose JCR utilities
>
> jackrabbit-core-1.0.3-src.jar
>
> jackrabbit-core-1.0.3.jar
> jackrabbit-jcr-commons-1.0.3.jar
>
> * RMI network layer for the JCR API.
>
> jackrabbit-jcr-rmi-1.0.3-src.jar
> jackrabbit-jcr-rmi-1.0-rc3.jar
>
> * WebDAV network layer for the JCR API.
>
> jackrabbit-jcr-webdav-1.0.3-src.jar
>
> jackrabbit-jcr-webdav-main-1.0.3.jar
> jackrabbit-jcr-webdav-client-1.0.3.jar
> jackrabbit-jcr-webdav-server-1.0.3.jar
> jackrabbit-jcr-webdav-server-1.0.3.war
>
> * J2EE Connector Architecture (JCA) resource adapter for Jackrabbit.
>
> jackrabbit-jca-1.0.3-src.jar
> jackrabbit-jca-1.0.3.rar
>
> * Text indexing filters for Jackrabbit. Includes example filters
> for Adobe PDF and MS Excel, PowerPoint, and Word.
>
> jackrabbit-index-filters-1.0.3-src.jar
> jackrabbit-index-filters-1.0.3.jar
>
> Should we be marking the non-core projects as alpha releases?
> It seems very strange to me to be releasing software without
> any documentation.
>
> > There are no more pending 1.0 issues, so I'm hoping to start the 1.0
> > release vote based on this release candidate as soon as the JSR-170
> > conformance test results are in and given that no unexpected problems
> > have been reported.
>
> Right, here is another versioning issue then. We only vote to
> release complete and signed jar/tarballs. We can't actually have a
> vote on something called 1.0-rc3 because it wouldn't be a candidate
> if it gets approved, and we can't change the contents after it has
> been approved because then we would have to do all the testing again.
> That is why we have three version numbers. Let's just stop using
> rcX and call the next set of jars 1.0.4. The first release doesn't
> have to end in 0 -- version numbers are free (and all versioned jars
> are release candidates).
>
> OT: why does jcr-rmi have a dependency on commons-logging?
>
> ....Roy
>
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 3/29/06, Felix Meschberger <Fe...@day.com> wrote:
> > OT: why does jcr-rmi have a dependency on commons-logging?
> As Jukka pointed out, it was added by me some time ago: This dependency
> was added because there is some logging in the event triggering
> implementation. If logging is removed, the dependency may be removed as
> well. Maybe, now that we use SL4J for logging, we might add a dependency
> to SL4J ?
SLF4J should be fine for now. In longer term I think we should avoid
the event pooling/polling mechanism in favor of remote callbacks (see
JCR-302) to make the RMI layer as transparent as possible. That would
also remove the need for logging in JCR-RMI. The callback approach
however has some issues related to the remote listener codebase, so
the issue is postponed.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Felix Meschberger <Fe...@day.com>.
Hi,
> OT: why does jcr-rmi have a dependency on commons-logging?
As Jukka pointed out, it was added by me some time ago: This dependency
was added because there is some logging in the event triggering
implementation. If logging is removed, the dependency may be removed as
well. Maybe, now that we use SL4J for logging, we might add a dependency
to SL4J ?
Regards
Felix
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 28, 2006, at 1:13 PM, Jukka Zitting wrote:
> The Apache Jackrabbit 1.0 release candidate 3 can be found at:
>
> http://people.apache.org/~jukka/jackrabbit/1.0-rc3/
>
> See the RELEASE-NOTES.txt for more details about the release contents.
Hmm. This is getting a little hairy.
We should be prefixing all of the files with jackrabbit-.
I know that the jcr-* packages are usable with any JCR
implementation, but the jackrabbit- prefix applies to everything
produced in this project (not just the repository). Its a
brand thing (and name collision avoidance as well).
Also, the package naming remains incoherent to me. I can't imagine
what it would look like to a new user, especially since there is
no documentation for the former contrib projects.
Here is what I suggest for making the names coherent:
* Jackrabbit content repository and general-purpose JCR utilities
jackrabbit-core-1.0.3-src.jar
jackrabbit-core-1.0.3.jar
jackrabbit-jcr-commons-1.0.3.jar
* RMI network layer for the JCR API.
jackrabbit-jcr-rmi-1.0.3-src.jar
jackrabbit-jcr-rmi-1.0-rc3.jar
* WebDAV network layer for the JCR API.
jackrabbit-jcr-webdav-1.0.3-src.jar
jackrabbit-jcr-webdav-main-1.0.3.jar
jackrabbit-jcr-webdav-client-1.0.3.jar
jackrabbit-jcr-webdav-server-1.0.3.jar
jackrabbit-jcr-webdav-server-1.0.3.war
* J2EE Connector Architecture (JCA) resource adapter for Jackrabbit.
jackrabbit-jca-1.0.3-src.jar
jackrabbit-jca-1.0.3.rar
* Text indexing filters for Jackrabbit. Includes example filters
for Adobe PDF and MS Excel, PowerPoint, and Word.
jackrabbit-index-filters-1.0.3-src.jar
jackrabbit-index-filters-1.0.3.jar
Should we be marking the non-core projects as alpha releases?
It seems very strange to me to be releasing software without
any documentation.
> There are no more pending 1.0 issues, so I'm hoping to start the 1.0
> release vote based on this release candidate as soon as the JSR-170
> conformance test results are in and given that no unexpected problems
> have been reported.
Right, here is another versioning issue then. We only vote to
release complete and signed jar/tarballs. We can't actually have a
vote on something called 1.0-rc3 because it wouldn't be a candidate
if it gets approved, and we can't change the contents after it has
been approved because then we would have to do all the testing again.
That is why we have three version numbers. Let's just stop using
rcX and call the next set of jars 1.0.4. The first release doesn't
have to end in 0 -- version numbers are free (and all versioned jars
are release candidates).
OT: why does jcr-rmi have a dependency on commons-logging?
....Roy
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
Based on the various comments I've now made the following
modifications to svn trunk and the 1.0 branch:
1) Renamed the project artifacts to always include the jackrabbit
prefix. (JCR-377) This includes the following name changes proposed by
Roy:
jackrabbit -> jackrabbit-core
jackrabbit-commons -> jackrabbit-jcr-commons
jackrabbit-textfilters -> jackrabbit-index-filters
The jcr-server names were not modified other than by adding the
jackrabbit prefix.
2) Updated the release notes to match the better structure proposed by
Roy. Also added the note about the non-core components being
alpha-status.
3) Replaced the commons-logging dependency in JCR-RMI with
slf4j-log4j12 (JCR-376)
4) Added the missing slf4j-log4j12 dependency to jackrabbit-server.war (JCR-378)
5) Removed the unneeded cqfs dependencies from jackrabbit-server.war
and jackrabbit-jca.rar. (JCR-379) This removes the problem of
accidentally bundling non-free components.
All these changes are cosmetic in nature, so unless other problems are
reported I won't be making another release candidate.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: Apache Jackrabbit 1.0 release candidate 3
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
Thanks to Alex, I just refreshed the 1.0-rc3 release directory with
the following changes:
* Added the missing jackrabbit-jca-1.0-rc3.rar and related files
* Changed some unspotted 1.0 dependencies to 1.0-rc3
The dependency change has no functional consequences as the 1.0
dependencies that were erroneously used were created from the 1.0
branch just before 1.0-rc3 was tagged, and were thus essentially
identical to the correct versions.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development