On 10/1/06, Andrus Adamchik <[EMAIL PROTECTED]> 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:
http://incubator.apache.org/guides/examples/LICENSE
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:
> http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/
> 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
http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/tutorials/quick-start/cayenne-tutorial/src/cayenne/tutorial/Artist.java
looked to me like an example of a hand-crafted subclass. the
preferences files didn't look like it was generated to me either:
http://svn.apache.org/repos/asf/incubator/cayenne/main/tags/2.0.1/cayenne/cayenne-java/src/modeler/resources/pref/ModelerPreferences.map.xml.
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
source.)
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
