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.
mrg On Wed, Aug 18, 2010 at 3:33 AM, Andrus Adamchik <[email protected]> wrote: > Taking a fresh look at all the points made in this discussion, my conclusions > are the following: > > 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-win.zip, 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] http://en.wikipedia.org/wiki/Smoke_testing
