FAQ
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

Search Discussions

  • Andrus Adamchik at Aug 18, 2010 at 9:53 am
    Ok, now I also re-read Roy's thoughts on that (hard to keep track of everything, when you doing million things at once... sorry for lots of back and force on the same issue).

    It does go contrary to what I said. Specifically <quote>Binary packages MUST be built from the SIGNED and RELEASED source package, NOT FROM SUBVERSION TAGS.</quote> - http://markmail.org/message/3odlybipss4wnczl ... So maybe instead of arguing against this further, I should try creating a source package assembly and building it into binary assemblies. Sure it will be fun :-/

    Andrus
  • Aristedes Maniatis at Aug 19, 2010 at 5:03 am

    On 18/08/10 7:52 PM, Andrus Adamchik wrote:
    It does go contrary to what I said. Specifically<quote>Binary packages MUST be built from the SIGNED and RELEASED source package, NOT FROM SUBVERSION TAGS.</quote> -http://markmail.org/message/3odlybipss4wnczl ... So maybe instead of arguing against this further, I should try creating a source package assembly and building it into binary assemblies. Sure it will be fun :-/
    I don't understand how this is practical or useful. I just read that thread on the legal-discuss list. Apart there being an hour of my life I'll never get back, it is clear that almost no one actually follows the advice Roy espoused in his email. Here were some interesting emails:

    http://markmail.org/thread/uugenepmbvodc4wu
    http://markmail.org/thread/di7lflnzsoymyz2v


    At any rate, I think it is up to us (the PMC) to decide on some policies and make them clear in our own documentation. As Mike says, the responsibilities of the PMC members are not crystal clear to us all. We should put them in writing. Obviously we follow the general Apache policies, but where they are vague we need to come up with our own interpretations. The general documentation about PMC responsibilities doesn't even mention releases ( http://www.apache.org/dev/pmc.html ) and the official release documentation ( http://www.apache.org/dev/release-publishing.html ) says only this:

    ...the fundamental requirement for a release is that it consist of the necessary source code to build the project. Optionally, a release may include compiled binaries for the convenience of users.


    As a PMC I suggest that our rules should be:

    1. Every release must include both the source and binaries built for supported platforms. They can be packaged separately but must be made available from the same download page.

    2. Although not an Apache requirement to do so, we will package all essential runtime dependencies within our binary distribution packages, but not within the source package. Optional dependencies will not be included in the distribution.

    3. All committers are encouraged to vote on releases. Committer votes will be considered by the PMC (particularly -1 votes will be discussed) when making the final decision, but are not binding.

    4. Each PMC member will do the following before voting on a release:

    a. download the artifacts
    b. satisfy themselves that the source matches the appropriate svn tag (I don't know how to do that though: how do I check that Andrus didn't accidentally build the distribution without a clean svn checkout or that his git-svn tool didn't do something wacky?)
    c. satisfy themselves that the licensing requirements are met (this will usually be achieved by [b] since all committers have a CLA, and ensuring that all notices are in place)
    d. satisfy themselves that the binary distribution is sane and passes basic usability tests. For example, that the Cayenne modeler runs and the main jar passes some basic tests.
    e. satisfy themselves that the source passes agreed unit tests (either by running them manually or verifying that Hudson has run those tests against the equivalent source).



    In many of the cases above, the difficulty comes down to verifying that the source == svn checkout. If we assume that might not be the case, then we can't rely on Hudson for running the right tests, or the svn commit rights for controlling who has submitted the CLA. We would in theory have to verify that every line of the source was appropriately licensed. I have no idea how to verify that Andrus' evil twin didn't inject some bit of GPL code into the source before building it.

    Other than my problem around point 4b are the above rules a good summary of the process? Can we agree on everything else and then see what 4b means to us?


    Ari


    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
  • Andrus Adamchik at Aug 26, 2010 at 8:12 am
    Hi Ari, this all makes sense. See my comments on the details below.
    On Aug 19, 2010, at 8:00 AM, Aristedes Maniatis wrote:

    As a PMC I suggest that our rules should be:
    I suggest to call this "guidelines", not "rules". Please let's preserve the commonsense approach we've been using all along. Just look at the release to see if you can spot anything wrong. This discussion hopefully provided better understanding of the specific things that need to be checked, but *how* everybody checks that is up to each person. In fact diversity in evaluation techniques should in theory provide better coverage of possible holes than algorithmic rules.

    3. All committers are encouraged to vote on releases. Committer votes will be considered by the PMC (particularly -1 votes will be discussed) when making the final decision, but are not binding. +1
    4. Each PMC member will do the following before voting on a release:

    a. download the artifacts
    b. satisfy themselves that the source matches the appropriate svn tag (I don't know how to do that though: how do I check that Andrus didn't accidentally build the distribution without a clean svn checkout or that his git-svn tool didn't do something wacky?)
    Technically this is doable (with a "diff -u" command against a local checkout). If somebody's willing to do it at least occasionally, please do it. Alternatively you may look at some recent commits and see that they are present in the source distro, or use some other simple sanity check approach.
    d. satisfy themselves that the binary distribution is sane and passes basic usability tests. For example, that the Cayenne modeler runs and the main jar passes some basic tests.
    In line with what I said above, a user may take any extra steps (s)he deems appropriate. E.g. stick cayenne-server.jar in a production app :-)

    Andrus
  • Mike Kienenberger at Aug 27, 2010 at 4:19 pm

    On Thu, Aug 19, 2010 at 1:00 AM, Aristedes Maniatis wrote:
    As a PMC I suggest that our rules should be:

    1. Every release must include both the source and binaries built for
    supported platforms. They can be packaged separately but must be made
    available from the same download page.
    Rule: must include a source package
    Guideline: would be nice to also have binaries

    2. Although not an Apache requirement to do so, we will package all
    essential runtime dependencies within our binary distribution packages, but
    not within the source package. Optional dependencies will not be included in
    the distribution.
    I see value in providing a package containing essential runtime dependencies.
    However, I don't see it as a requirement. I suspect that due to the
    size of the dependencies and the prevalence of maven, most people
    would prefer that the binary package not contain the dependencies.
    Might be wrong about this, though.

    To me, it might make more sense to include them with the source since
    they are a required piece to build the source. Or, as I said earlier,
    a separate dependency package. However, all of this would have to
    wait until someone is willing to do the work to make it happen.

    3. All committers are encouraged to vote on releases. Committer votes will
    be considered by the PMC (particularly -1 votes will be discussed) when
    making the final decision, but are not binding.
    That's a rule.

    4. Each PMC member will do the following before voting on a release:

    a. download the artifacts Yes.
    b. satisfy themselves that the source matches the appropriate svn tag (I
    don't know how to do that though: how do I check that Andrus didn't
    accidentally build the distribution without a clean svn checkout or that his
    git-svn tool didn't do something wacky?)
    No -- why does it matter where the source came from for the purposes
    of a release?

    c. satisfy themselves that the licensing requirements are met (this will
    usually be achieved by [b] since all committers have a CLA, and ensuring
    that all notices are in place)
    Yes. Rule.
    d. satisfy themselves that the binary distribution is sane and passes basic
    usability tests. For example, that the Cayenne modeler runs and the main jar
    passes some basic tests.
    Not a rule, but a good idea. Not legally required for a release.
    e. satisfy themselves that the source passes agreed unit tests (either by
    running them manually or verifying that Hudson has run those tests against
    the equivalent source).
    Not a rule, but a good idea. Not legally required for a release.

    In many of the cases above, the difficulty comes down to verifying that the
    source == svn checkout. If we assume that might not be the case, then we
    can't rely on Hudson for running the right tests, or the svn commit rights
    for controlling who has submitted the CLA. We would in theory have to verify
    that every line of the source was appropriately licensed. I have no idea how
    to verify that Andrus' evil twin didn't inject some bit of GPL code into the
    source before building it.
    I don't agree that the source == svn checkout has to match as a
    release rule, although it's a good guideline.
    However, I don't see it as a really big deal -- I'm pretty sure our
    source package is mostly a svn snapshot (correct me if I'm wrong), and
    a recursive diff tool could compare the two easily.

    This is part of the due dilligence that should be performed for every
    commit message. Sometimes things do sneak in -- we've had it happen
    a number of times for MyFaces -- and they have to be dealt with at a
    later date.

    Running RAT against the source package (not SVN) is one tool that
    helps. Spot checking a few files can help.
    I think MyFaces has a code style rule that also verifies copyright
    notices in each file. Running diffs against the current source
    versus the last releases source might be another such tool. While
    this is one of the most important responsibilities of the PMC, it's
    also one of the most difficult to be comprehensive about.
    Other than my problem around point 4b are the above rules a good summary of
    the process? Can we agree on everything else and then see what 4b means to
    us?
    Again, the goal of our releases is to provide quality software, but
    the only legal requirements of a release are that it meet certain
    legal and procedural criteria, not that it's quality software.
  • Andrus Adamchik at Aug 27, 2010 at 4:51 pm

    On Aug 27, 2010, at 7:18 PM, Mike Kienenberger wrote:

    our
    source package is mostly a svn snapshot (correct me if I'm wrong), and
    a recursive diff tool could compare the two easily.
    Yes, it is the exact copy of the SVN tag contents (sans any SCM files, like .svn or .git).

    Andrus
  • Aristedes Maniatis at Aug 28, 2010 at 6:14 am

    On 28/08/10 2:18 AM, Mike Kienenberger wrote:
    On Thu, Aug 19, 2010 at 1:00 AM, Aristedes Maniatiswrote:
    As a PMC I suggest that our rules should be:

    1. Every release must include both the source and binaries built for
    supported platforms. They can be packaged separately but must be made
    available from the same download page.
    Rule: must include a source package
    Guideline: would be nice to also have binaries
    I'm not talking about Apache Foundation rules here, I'm talking about the rules we as a PMC want to create for ourselves. We need to encompass the requirements of the Foundation, but we need to do it in relation to how we operate and what outcomes we want.

    In our case, we want to release binaries every time, and I personally will be voting against any release which does not contain binaries. Let me know if you disagree, but I'm putting that down as a 'rule'.


    2. Although not an Apache requirement to do so, we will package all
    essential runtime dependencies within our binary distribution packages, but
    not within the source package. Optional dependencies will not be included in
    the distribution.
    I see value in providing a package containing essential runtime dependencies.
    However, I don't see it as a requirement. I suspect that due to the
    size of the dependencies and the prevalence of maven, most people
    would prefer that the binary package not contain the dependencies.
    Might be wrong about this, though.
    Some of our dependencies are a little obscure, so perhaps it is a good idea to bundle them unless we are confident they are in a repo somewhere reliable. I've seen that Andrus is working on improving this already.

    Obviously there is a line to draw. We can never release source which has *everything* you need to build the binaries since we aren't bundling the JDK.

    b. satisfy themselves that the source matches the appropriate svn tag (I
    don't know how to do that though: how do I check that Andrus didn't
    accidentally build the distribution without a clean svn checkout or that his
    git-svn tool didn't do something wacky?)
    No -- why does it matter where the source came from for the purposes
    of a release?
    Because you yourself said:
    In practice, I think the primary bulk of the rest of the source
    licensing checks happen during the the commit process as a "best
    effort" rather than "guaranteed perfection".
    Personally I'm confident that the code in SVN is appropriately licensed since I read pretty much every commit that goes past. But I've been chastised twice now about my voting methodology. I've previously taken it for granted that the source in SVN is what ends up in the release and therefore until now I've done little independent checking of the packaged source. I've focussed on ensuring the binaries are sane. Mike, as you say, more emphasis should be given to verifying the source, but I'm trying to understand what that means in reality.

    c. satisfy themselves that the licensing requirements are met (this will
    usually be achieved by [b] since all committers have a CLA, and ensuring
    that all notices are in place)
    Yes. Rule.
    d. satisfy themselves that the binary distribution is sane and passes basic
    usability tests. For example, that the Cayenne modeler runs and the main jar
    passes some basic tests.
    Not a rule, but a good idea. Not legally required for a release.
    Again, I'm trying to create some rules for ourselves as PMC members against your (correct) statement that new PMC members don't always know what is expected of them. Having a checklist for releases seems like a starting point.

    Again, the goal of our releases is to provide quality software, but
    the only legal requirements of a release are that it meet certain
    legal and procedural criteria, not that it's quality software.
    As PMC members we have a responsibility to do both regardless of the Foundation rules.


    Regards
    Ari

    --
    -------------------------->
    Aristedes Maniatis
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
  • Mike Kienenberger at Aug 28, 2010 at 2:56 pm

    On Sat, Aug 28, 2010 at 2:13 AM, Aristedes Maniatis wrote:
    On 28/08/10 2:18 AM, Mike Kienenberger wrote:

    On Thu, Aug 19, 2010 at 1:00 AM, Aristedes Maniatis<ari@maniatis.org>
    wrote:
    As a PMC I suggest that our rules should be:

    1. Every release must include both the source and binaries built for
    supported platforms. They can be packaged separately but must be made
    available from the same download page.
    Rule: must include a source package
    Guideline: would be nice to also have binaries
    I'm not talking about Apache Foundation rules here, I'm talking about the
    rules we as a PMC want to create for ourselves. We need to encompass the
    requirements of the Foundation, but we need to do it in relation to how we
    operate and what outcomes we want.

    In our case, we want to release binaries every time, and I personally will
    be voting against any release which does not contain binaries. Let me know
    if you disagree, but I'm putting that down as a 'rule'.
    I disagree. A release will be whatever a release requires. Extreme
    example. At some point, we might have a security issue with Cayenne, and we
    might decide that we want to make an immediate release of a single source
    file, with no binaries. Most of the time our releases will probably
    contain binaries, but if someone decided to make a milestone release of only
    source code, I see no reason why we'd disallow it.


    2. Although not an Apache requirement to do so, we will package all
    essential runtime dependencies within our binary distribution packages,
    but
    not within the source package. Optional dependencies will not be included
    in
    the distribution.
    I see value in providing a package containing essential runtime
    dependencies.
    However, I don't see it as a requirement. I suspect that due to the
    size of the dependencies and the prevalence of maven, most people
    would prefer that the binary package not contain the dependencies.
    Might be wrong about this, though.
    Some of our dependencies are a little obscure, so perhaps it is a good idea
    to bundle them unless we are confident they are in a repo somewhere
    reliable. I've seen that Andrus is working on improving this already.

    Obviously there is a line to draw. We can never release source which has
    *everything* you need to build the binaries since we aren't bundling the
    JDK.
    I am in favor of doing this. But it needs more discussion. I still think
    rule/requirement is too strong of a word, though. General
    practice/guideline if we come to agreement on it.


    b. satisfy themselves that the source matches the appropriate svn tag (I
    don't know how to do that though: how do I check that Andrus didn't
    accidentally build the distribution without a clean svn checkout or that
    his
    git-svn tool didn't do something wacky?)
    No -- why does it matter where the source came from for the purposes
    of a release?
    Because you yourself said:

    In practice, I think the primary bulk of the rest of the source
    licensing checks happen during the the commit process as a "best
    effort" rather than "guaranteed perfection".
    Personally I'm confident that the code in SVN is appropriately licensed
    since I read pretty much every commit that goes past. But I've been
    chastised twice now about my voting methodology. I've previously taken it
    for granted that the source in SVN is what ends up in the release and
    therefore until now I've done little independent checking of the packaged
    source. I've focussed on ensuring the binaries are sane. Mike, as you say,
    more emphasis should be given to verifying the source, but I'm trying to
    understand what that means in reality.

    c. satisfy themselves that the licensing requirements are met (this will
    usually be achieved by [b] since all committers have a CLA, and ensuring
    that all notices are in place)
    Yes. Rule.
    d. satisfy themselves that the binary distribution is sane and passes
    basic
    usability tests. For example, that the Cayenne modeler runs and the main
    jar
    passes some basic tests.
    Not a rule, but a good idea. Not legally required for a release.
    Again, I'm trying to create some rules for ourselves as PMC members against
    your (correct) statement that new PMC members don't always know what is
    expected of them. Having a checklist for releases seems like a starting
    point.
    These sounds fine as an item or items on our checklist. It might even be
    reasonable as a requirement rather than a guideline.


    Again, the goal of our releases is to provide quality software, but
    the only legal requirements of a release are that it meet certain
    legal and procedural criteria, not that it's quality software.
    As PMC members we have a responsibility to do both regardless of the
    Foundation rules.
    I don't want to nitpick, but that's not accurate. As project members we
    have a desire to produce quality software. As PMC members we have a
    responsibility to meet certain legal and procedural criteria. There are
    two different roles (what some people call "hats") involved here. In our
    PMC role, our responsibility is to meet the requirements of ASF releases.
    But I agree that we also have a strong desire to do more than just release
    legally-satisfying packages. But if I consider two people on the extreme
    edges -- one who only cares if the software works and one who only cares if
    the software meets the legal requirements of the ASF -- the second one is
    the only one qualified to be a PMC member.

    In summary:
    Meeting the legal/procedural requirements of the ASF is a PMC member
    requirement. If somone is not willing to do this, they should step down.
    There is sometimes room for interpretation on how to determine if we're
    meeting the legal requirements (ie, [monitor all commits and verify that the
    svn tag matches the source download] VERSUS [run RAT tools] VERSUS [spot
    check the code]), but it has to be done. Other times there is no room for
    interpretation -- the signatures have to be checked, the source has to be
    provided.

    And unfortunately, I'm no expert. I've been around a long time and have
    seen how many other ASF projects operate, and I read through what
    documentation is available, but in the end, I'm not even an Apache member.
    I no longer follow infrastructure, legal-discuss, nor the incubator general
    mailing list. I did sign up for the new release management mailing list a
    couple weeks back. Maybe that's a place we could be asking some of these
    questions on topics that are more open for interpretation, but because of
    the nature of the ASF, if it's not documented somewhere, it's up for debate,
    and often the debate takes several years to work out. The mailing thread
    that we've referred to eventually lead to documentation changes, but it
    didn't happen right away.

    I do have the advantage that I'm a PMC member on the MyFaces project, and
    just because of the shear number of subprojects, people involved there, and
    the variety of issues there (3rd party add-ons/modules/app-servers with all
    kinds of licenses, Java Community Process, NDAs, security issues, maven,
    ant, J2EE integration, GSoC), I get to eavesdrop on a lot of
    How-It-Works-At-ASF discussions involving people from a bunch of other ASF
    projects.

    And sometimes when I see something relevant from there pop up, I try to
    share over here at Cayenne, where we seem to be a bit more isolated from the
    rest of the ASF.
  • Andrus Adamchik at Aug 21, 2010 at 5:27 pm
    FYI, problem solved: https://issues.apache.org/jira/browse/CAY-1471

    I will commit this after I finish the remaining assembly descriptors. The assembly build process is much more sane now. Each distro (src, mac, win, generic) is done in a single step. Hopefully will get rid of the build-mac.sh script as well.

    The new binary assemblies are identical to the the ones we had, sans the "src" folder, as sources are now distribute separately.

    Andrus

    On Aug 18, 2010, at 12:52 PM, Andrus Adamchik wrote:

    Ok, now I also re-read Roy's thoughts on that (hard to keep track of everything, when you doing million things at once... sorry for lots of back and force on the same issue).

    It does go contrary to what I said. Specifically <quote>Binary packages MUST be built from the SIGNED and RELEASED source package, NOT FROM SUBVERSION TAGS.</quote> - http://markmail.org/message/3odlybipss4wnczl ... So maybe instead of arguing against this further, I should try creating a source package assembly and building it into binary assemblies. Sure it will be fun :-/

    Andrus

  • Andrus Adamchik at Aug 23, 2010 at 1:49 pm
    This is in, and with lots of improvements to the build/assembly process [1], as Maven files are now our public API. I will restart 3.0.1 soon.

    Andrus

    [1] http://cayenne.apache.org/building-cayenne.html
    On Aug 21, 2010, at 8:26 PM, Andrus Adamchik wrote:
    FYI, problem solved: https://issues.apache.org/jira/browse/CAY-1471

    I will commit this after I finish the remaining assembly descriptors. The assembly build process is much more sane now. Each distro (src, mac, win, generic) is done in a single step. Hopefully will get rid of the build-mac.sh script as well.

    The new binary assemblies are identical to the the ones we had, sans the "src" folder, as sources are now distribute separately.

    Andrus

    On Aug 18, 2010, at 12:52 PM, Andrus Adamchik wrote:

    Ok, now I also re-read Roy's thoughts on that (hard to keep track of everything, when you doing million things at once... sorry for lots of back and force on the same issue).

    It does go contrary to what I said. Specifically <quote>Binary packages MUST be built from the SIGNED and RELEASED source package, NOT FROM SUBVERSION TAGS.</quote> - http://markmail.org/message/3odlybipss4wnczl ... So maybe instead of arguing against this further, I should try creating a source package assembly and building it into binary assemblies. Sure it will be fun :-/

    Andrus

  • Michael Gentry at Aug 18, 2010 at 1:28 pm
    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 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
  • Andrus Adamchik at Aug 18, 2010 at 3:03 pm

    On Aug 18, 2010, at 4:28 PM, Michael Gentry wrote:

    To me, a separate cayenne-src.tar.gz makes the most sense.
    Yeah, that's what we'll likely end up with.
    Also, I'd split the OS-specific Cayenne Modeler distributions up a bit more
    I have a number of long standing gripes about OS-specific assemblies (both code separation and the build process). With 3.1 preferences refactoring some of those became even more obvious (e.g. I got a Windows look and feel for 3.1 now). I have some ideas, but this is a separate discussion.
    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.
    I didn't quite get that. Which jars are you referring to?

    Andrus
  • Michael Gentry at Aug 18, 2010 at 3:10 pm
    When I downloaded the 3.0.1 DMG for OS X, I have CayenneModeler.app
    (good), README.txt (fine), and a cayenne-3.0.1 folder with
    doc/lib/src/tutorials/etc in it (stuff I ignore/throw away). I'd just
    as soon not have that in the DMG and have a separate download if I
    wanted it. For people using Maven, that stuff will get pulled in via
    the POM, so it is a bit overkill when you just want the modeler (which
    is used outside of Maven).

    mrg


    On Wed, Aug 18, 2010 at 11:02 AM, Andrus Adamchik
    wrote:
    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.
    I didn't quite get that. Which jars are you referring to?
  • Andrus Adamchik at Aug 18, 2010 at 3:29 pm
    I see.

    We have to have a sane number of downloads. That's the only reason we have packaging that we have now. Don't see anything wrong with a few extra megabytes of stuff in there. I am personally very annoyed with other projects not including the docs for instance.

    Andrus

    On Aug 18, 2010, at 6:09 PM, Michael Gentry wrote:

    When I downloaded the 3.0.1 DMG for OS X, I have CayenneModeler.app
    (good), README.txt (fine), and a cayenne-3.0.1 folder with
    doc/lib/src/tutorials/etc in it (stuff I ignore/throw away). I'd just
    as soon not have that in the DMG and have a separate download if I
    wanted it. For people using Maven, that stuff will get pulled in via
    the POM, so it is a bit overkill when you just want the modeler (which
    is used outside of Maven).

    mrg
  • Mike Kienenberger at Aug 18, 2010 at 3:37 pm
    Everyone is going to have different preferences.

    Personally, I like to have the src, sometimes the docs, but don't care
    to much for any of the rest of it. And I don't use maven.

    I think if our basic source package contains the "extras", then the
    binary package can just contain the minimal parts needed to make
    Cayenne run. In my opinion, the best package schemes allow you to
    download the binary package, then download the source/docs/examples
    package over the top of it.

    I wonder how practical it might be to also create a dependencies
    package, something that only contains all of the third-party jars
    needed to make things work. That could address some of the concerns
    which were mentioned before. And as a separate package, it wouldn't
    inconvenience those who don't need it.

    On Wed, Aug 18, 2010 at 11:29 AM, Andrus Adamchik
    wrote:
    I see.

    We have to have a sane number of downloads. That's the only reason we have packaging that we have now. Don't see anything wrong with a few extra megabytes of stuff in there. I am personally very annoyed with other projects not including the docs for instance.

    Andrus

    On Aug 18, 2010, at 6:09 PM, Michael Gentry wrote:

    When I downloaded the 3.0.1 DMG for OS X, I have CayenneModeler.app
    (good), README.txt (fine), and a cayenne-3.0.1 folder with
    doc/lib/src/tutorials/etc in it (stuff I ignore/throw away).  I'd just
    as soon not have that in the DMG and have a separate download if I
    wanted it.  For people using Maven, that stuff will get pulled in via
    the POM, so it is a bit overkill when you just want the modeler (which
    is used outside of Maven).

    mrg
  • Andrus Adamchik at Aug 18, 2010 at 3:52 pm
    I am very much in favor of a single download per environment. So that users don't have to hunt for the pieces they need. They get all in one file. So I don't see why we should change our current practice, and in fact think it is quite elegant. Haven't seen a single complaint about it.

    Ok, we need a separate cayenne-src.tar.gz for reasons unrelated to the end users, but why change anything else?

    Andrus

    On Aug 18, 2010, at 6:36 PM, Mike Kienenberger wrote:
    Everyone is going to have different preferences.

    Personally, I like to have the src, sometimes the docs, but don't care
    to much for any of the rest of it. And I don't use maven.

    I think if our basic source package contains the "extras", then the
    binary package can just contain the minimal parts needed to make
    Cayenne run. In my opinion, the best package schemes allow you to
    download the binary package, then download the source/docs/examples
    package over the top of it.

    I wonder how practical it might be to also create a dependencies
    package, something that only contains all of the third-party jars
    needed to make things work. That could address some of the concerns
    which were mentioned before. And as a separate package, it wouldn't
    inconvenience those who don't need it.

    On Wed, Aug 18, 2010 at 11:29 AM, Andrus Adamchik
    wrote:
    I see.

    We have to have a sane number of downloads. That's the only reason we have packaging that we have now. Don't see anything wrong with a few extra megabytes of stuff in there. I am personally very annoyed with other projects not including the docs for instance.

    Andrus

    On Aug 18, 2010, at 6:09 PM, Michael Gentry wrote:

    When I downloaded the 3.0.1 DMG for OS X, I have CayenneModeler.app
    (good), README.txt (fine), and a cayenne-3.0.1 folder with
    doc/lib/src/tutorials/etc in it (stuff I ignore/throw away). I'd just
    as soon not have that in the DMG and have a separate download if I
    wanted it. For people using Maven, that stuff will get pulled in via
    the POM, so it is a bit overkill when you just want the modeler (which
    is used outside of Maven).

    mrg
  • Mike Kienenberger at Aug 18, 2010 at 4:08 pm
    Michael was just complaining about it, so you've seen one :)
    I explained why we might want a separate dependencies download (size reasons).

    My personal preference is that every binary package would also contain
    the entire contents of our source package (docs, examples, src, etc),
    but I was throwing out an alternative idea since the complaint came
    up.

    On Wed, Aug 18, 2010 at 11:51 AM, Andrus Adamchik
    wrote:
    I am very much in favor of a single download per environment. So that users don't have to hunt for the pieces they need. They get all in one file. So I don't see why we should change our current practice, and in fact think it is quite elegant. Haven't seen a single complaint about it.

    Ok, we need a separate cayenne-src.tar.gz for reasons unrelated to the end users, but why change anything else?

    Andrus

    On Aug 18, 2010, at 6:36 PM, Mike Kienenberger wrote:
    Everyone is going to have different preferences.

    Personally, I like to have the src, sometimes the docs, but don't care
    to much for any of the rest of it.   And I don't use maven.

    I think if our basic source package contains the "extras", then the
    binary package can just contain the minimal parts needed to make
    Cayenne run.   In my opinion, the best package schemes allow you to
    download the binary package, then download the source/docs/examples
    package over the top of it.

    I wonder how practical it might be to also create a dependencies
    package, something that only contains all of the third-party jars
    needed to make things work.  That could address some of the concerns
    which were mentioned before.   And as a separate package, it wouldn't
    inconvenience those who don't need it.

    On Wed, Aug 18, 2010 at 11:29 AM, Andrus Adamchik
    wrote:
    I see.

    We have to have a sane number of downloads. That's the only reason we have packaging that we have now. Don't see anything wrong with a few extra megabytes of stuff in there. I am personally very annoyed with other projects not including the docs for instance.

    Andrus

    On Aug 18, 2010, at 6:09 PM, Michael Gentry wrote:

    When I downloaded the 3.0.1 DMG for OS X, I have CayenneModeler.app
    (good), README.txt (fine), and a cayenne-3.0.1 folder with
    doc/lib/src/tutorials/etc in it (stuff I ignore/throw away).  I'd just
    as soon not have that in the DMG and have a separate download if I
    wanted it.  For people using Maven, that stuff will get pulled in via
    the POM, so it is a bit overkill when you just want the modeler (which
    is used outside of Maven).

    mrg
  • Andrew Lindesay at Aug 18, 2010 at 8:03 pm
    Hi;

    I only started using Cayenne this last few months and was working at source level to understand and patch a couple of small things and haven't had any problem getting anything -- it all seemed clear and straight forward.

    cheers.
    ... So that users don't have to hunt for the pieces they need. They get all i...
    ___
    Andrew Lindesay
    www.silvereye.co.nz
  • Malcolm Edgar at Aug 18, 2010 at 11:47 pm
    One thing we do in the Apache Click project is that we package the
    source code in the library JAR files.

    I know this is a little unusual and makes the JAR files larger.
    However its great from an IDE perspective as the source code is
    already there and you can drill straight into methods. Its also good
    from the perspective you know exactly what you are dealing with, i.e.
    its the source used to compile the classes.

    regards Malcolm Edgar
    On Thu, Aug 19, 2010 at 6:03 AM, Andrew Lindesay wrote:
    Hi;

    I only started using Cayenne this last few months and was working at source level to understand and patch a couple of small things and haven't had any problem getting anything -- it all seemed clear and straight forward.

    cheers.
    ... So that users don't have to hunt for the pieces they need. They get all i...
    ___
    Andrew Lindesay
    www.silvereye.co.nz
  • Andrei Ionescu at Aug 19, 2010 at 4:44 pm

    One thing we do in the Apache Click project is that we package the
    source code in the library JAR files.

    I know this is a little unusual and makes the JAR files larger.
    However its great from an IDE perspective as the source code is
    already there and you can drill straight into methods. Its also good
    from the perspective you know exactly what you are dealing with, i.e.
    its the source used to compile the classes.
    +1.

    And this can be done very easily with Maven too:
    -------------------------------------
    <build>
    ....
    <resources>
    <resource>
    <directory>src/java</directory>
    </resource>
    </resources>
    ...
    -------------------------------------
    so Maven will include this way the *.java files in the JARs.

    regards,
    Andrei.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedAug 18, '10 at 7:34a
activeAug 28, '10 at 2:56p
posts20
users7
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase