incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <>
Subject Re: [VOTE] Approve the 2.0.1 release of Cayenne
Date Sun, 01 Oct 2006 18:42:43 GMT
On 10/1/06, Andrus Adamchik <> wrote:
> Hi Robert,
> On Oct 1, 2006, at 12:57 PM, robert burrell donkin wrote:
> > oh yes: the LICENSE and NOTICE files are ok but the LICENSE file could
> > be improved by including an indication about to which artifact or
> > source file the particular license applies.
> I guess then it would duplicate NOTICE file (not that it is bad, just
> more chance for the two to get out of sync in the future). NOTICE
> does it in a way already, so I think of it as an "index" for the more
> verbose LICENSE.

i like the way httpd does things:

but i can see the cayenne approach working ok provided that there a
small note somewhere telling people to look in the NOTICE file

> On Oct 1, 2006, at 12:35 PM, robert burrell donkin wrote:
> > a RAT run turned up a few issues:
> >
> > *IMPORTANT* not under open source license:
> >
> > cayenne/cayenne-other/wiki-docs/Documentation/User%20Guide/
> > Introduction/Guide%20to%201.1%20Features/cayenne-data-map-1_2.dtd
> Everything except for DTD's are generated files. We'll will fix the
> DTD's shortly.

interesting. there were a number of files which were clearly generated
that i ignored. these had notices in noting that they were generated.

the ones i highlighted didn't look like they were hand crafted to me
and lacked notices that they were generated.

for example
looked to me like an example of a hand-crafted subclass. the
preferences files didn't look like it was generated to me either:
though perhaps i was fooled...

one good practice often adopted by projects which make extensive use
of generated source is to ensure that it's clear (either by including
notes in the documents or by creating them in directories with clear
names) which documents are generated and which are not. it would make
it a lot easier and quicker to audit cayenne releases if this practice
were adopted.

> > interesting that this is a(nother) binary-with-source distribution.
> > this looks like it's been constructed by a build process rather than a
> > direct svn snapshot.
> True - this was a conscious decision made a few years ago with the
> goal to make the release artifacts user-friendly.

nothing wrong with that :-)

> Looking at some projects that post releases as SVN snapshots can be a
> nightmare - it is organized for development, not for end-user
> consumption. It will be a nightmare for Cayenne too, as Cayenne trunk
> (targeting 3.0 release) is switched to Maven, and there is no one-to-
> one correspondence between final release jars and Maven artifacts
> because of multiple JDK versions support, lightweight stripped down
> jars for remote clients, etc.

it's not a case of either a user-friendly binary release or a
developer-friendly source release: most projects release a source
distribution and various user friendly binary distributions. (a binary
distribution is anything which isn't a straight export from the

> > i hope that cayenne will also be made available as a source
> > distribution.
> I'd like to hear arguments why this would be a good thing?
> I can think of two:
> * Smaller download. IMO this is addressed by clean SVN tagging (users
> can always build a given version if they want); widespread use of
> broadband (not only in the West); and much more user-friendly release
> (you get binaries, source and tools in one place and in place where
> you expect to find it).
> * Binaries are not cross-platform. Aside from the tool launchers,
> everything is Java.

my list:

philosophical - it's open source: releases should include a source distribution

social - apache projects need to recruit new developers to retain
their health and vigour. it therefore makes sense to ship source
distributions aimed at developers as well as binaries aimed at users

practical - a source distribution future proofs the release (this is
important at apache where release are preserved indefinitely). from a
source distribution, a binary can be rebuilt even if subversion is not
available (or is suspect or corrupt). so this is a useful perspective
from an archival perspective.

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message