Andrus Adamchik <andru..bjectstyle.org> wrote:
> Yes, I've upgraded commons-collections to 3.0. My bad, I should've
> posted an announcement. The reason I did that was that there were some
> bugs with chained iterators (something I am planning to use) in 2.1. If
> this creates unbearable problems with Struts (does it? I think 3.0 is
> fully backwards compatible, though old classes are deprecated), we can
> roll back.
I'll go ahead and upgrade to 3.0 and see if I have any problems.
I haven't heard any specific issues with Collections 3.0. I know that it
was not true of some of the other commons projects (lang in particular).
> True, jdom that is only used by dataview package is not bundled with
> cayenne.jar. The thing is, "cayenne.jar" is growing out of proportion
> now. The original nice idea of keeping everything in one jar has
> outgrown itself, so we have to make concessions... With Java Groups it
> is a different story. It is distributed under LGPL, so there is a
> sensitive license compatibility issues with that. It is not bundled
> intentionally.
I've always thought the idea of "one jar" was a bad one. It was never an
option for me -- I've always used the no-deps option.
> However this raises an issue of whether we should even continue
> maintaining the build.xml script as a part of the distribution. Having
> two independent build systems (one for developers and one for users) is
> becoming a maintenance nightmare. I have a very strong opinion that we
> should stop shipping the build script and tell users who build Cayenne
> on their own to use anonymous CVS (or CVS snapshots from the website).
> CVS includes all the jars and is guaranteed to build without glitches.
> Besides it should be very easy to find a particular date or a release
> label.
As long as there's a way to get buildable source packages without using CVS,
I think that's fair.
I'd rather see the released binary packages actually look like the cvs
packages.
I think another alternative is to stop providing "cayenne.jar" source
packages. Instead, package the libraries as is, and just include them --
the "otherlib" we see in cvs. If one build a package, you only get the
no-deps version. Actually, I'd just go a step further and stop creating the
dependent version. As you've said above, it's reached the point that it no
longer makes sense to bundle them all together.
This archive was generated by hypermail 2.0.0 : Tue Mar 02 2004 - 17:41:52 EST