cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <>
Subject Re: 3.0.1 - next steps
Date Wed, 18 Aug 2010 13:28:08 GMT
Since we are talking about packaging ...

To me, a separate cayenne-src.tar.gz makes the most sense.  Also, I'd
split the OS-specific Cayenne Modeler distributions up a bit more to
not even include the Cayenne libraries.  More and more people are
using Maven now and don't need the JARs in the Cayenne Modeler
distribution.  You can have a separate cayenne-lib.tar.gz.


On Wed, Aug 18, 2010 at 3:33 AM, Andrus Adamchik <> wrote:
> Taking a fresh look at all the points made in this discussion, my conclusions are the
> 1. Lack of mention of VPP in the NOTICE file is an omission that we must fix.
> 2. Other than (1), Cayenne has been making valid and compliant releases all along, as
we did include the source code that can be built into Cayenne runtime that matches the binaries
that we distribute. The issue of build file is secondary. It is an issue of quality, not compliance
if you will. Source is now distributed as a single module, and writing build.xml to make a
jar out of it is *not* hard (or alternatively importing it in Eclipse, adding needed deps
based on errors in import statements, and exporting it as a jar is trivial). But in any event,
this is still a "quality" argument.
> Addressing Mike's earlier comment:
>> if you want to say that we're meeting the source build
>> requirement, consider this. It would mean that everyone voting +1 on a
>> release has somehow thrown a home-grown build-system on top of the
>> source release and successfully built it.   Because that's the only
>> way an evaluator can be sure that the release has met the condition
>> and the release manager hasn't accidentally left out some required
>> piece of source.
> Actually being able to build the source doesn't prove that release manager haven't missed
some files. The source can still build in such case (e.g. consider an absurd case of RM throwing
out Cayenne source entirely, replacing it with one HelloWorld class). What exactly is proven
by building the source? It is just one of the parts of a release "smoke test" [1]. I guess
you could check out the tag and checksum individual source files and then checksum the same
files from release sources. This will guarantee no rogue or missing contents. But this doesn't
require a build.
> 3. Next steps. I suggest to restart 3.0.1 vote by fixing (1), and later discuss whether
we want to provide a separate source artifact made by tar'ing up the source tree sans test
cases and a few special modules. I think this can be easily done with assembly plugin. So
in addition to cayenne.tar.gz,, cayenne-osx.dmg, we'd also distribute cayenne-src.tar.gz
(or we put it in each one of the 3 platform files). Once we agree on a format, we can open
a Jira and add it in the following releases. My preference would be to leave 3.0.* release
structure untouched, and put it in 3.1.
> Andrus
> [1]

View raw message