Re: [VOTE] release 3.0.1

From: Mike Kienenberger (mkienen..mail.com)
Date: Mon Aug 16 2010 - 19:48:37 UTC

  • Next message: Aristedes Maniatis: "Re: [VOTE] release 3.0.1"

    Down the road, perhaps we should consider bundling only those jars which

    a) are not maintained by the ASF
    b) are required by the runtime

    A lot of these jars are used by the modeler. In a theoretical "5
    years down the road" situation, the end user is probably not going to
    care all that much if he can build the modeler -- worse case he can
    edit the xml files by hand. But he'll be really unhappy if he can't
    get the runtime recompiled. I see the typical use case as minor
    patching for bugs, probably security bugs.

    On Mon, Aug 16, 2010 at 3:30 PM, Andrus Adamchik <andru..bjectstyle.org> wrote:
    > I don't think Maven would allow to pull libs from an arbitrary folder, but I
    > guess we can have a README telling users to mvn install:file from
    > lib/third-party or some other source prior to the build.
    >
    > I am sure that won't cover everything - there's lots and lots of deps that
    > we don't include to prevent the size of the download from going out of
    > proportion on things like JMS, JPA, etc. etc. We'll have to compromise
    > anyways... I guess having a POM will give a user a good starting point as it
    > shows everything that's required, but from there they will have to be
    > creative in finding replacements for missing libs.
    >
    >> If there's a chance the package is unavailable, we probably should bundle
    >> it.
    >> That's what we're doing with the ashwood graph library, right?
    >
    > yes, in fact I want to internalize it in our code. But we have to draw a
    > line somewhere... Below is a list of deps from the 3.1 master POM with only
    > "compiled" and "provided" dependencies minus what's already bundled
    > (although I left jars that are also bundled into a fat CayenneModeler.jar).
    > Say hi to a 50 MB distribution of Cayenne...
    >
    > I feel like we should go with an imperfect compromise everybody else is
    > using - just giving source with the POMs and no extra deps :-/
    >
    > Andrus
    >
    >
    > <dependency>
    >        <groupId>ant</groupId>
    >        <artifactId>ant</artifactId>
    >        <version>1.6.5</version>
    > </dependency>
    > <dependency>
    >        <groupId>commons-dbcp</groupId>
    >        <artifactId>commons-dbcp</artifactId>
    >        <version>1.2.1</version>
    > </dependency>
    > <dependency>
    >        <groupId>commons-pool</groupId>
    >        <artifactId>commons-pool</artifactId>
    >        <version>1.2</version>
    > </dependency>
    > <dependency>
    >        <groupId>hsqldb</groupId>
    >        <artifactId>hsqldb</artifactId>
    >        <version>1.8.0.4</version>
    > </dependency>
    > <dependency>
    >        <groupId>com.caucho</groupId>
    >        <artifactId>resin-hessian</artifactId>
    >        <version>3.1.6</version>
    >        <scope>provided</scope>
    > </dependency>
    > <dependency> <!-- ?????? -->
    >        <groupId>javacc</groupId>
    >        <artifactId>javacc</artifactId>
    >        <version>3.2</version>
    >        <scope>test</scope>
    > </dependency>
    > <dependency>
    >        <groupId>org.objectstyle</groupId>
    >        <artifactId>jdbc4-compat</artifactId>
    >        <version>1.0</version>
    > </dependency>
    > <dependency>
    >        <groupId>jgoodies</groupId>
    >        <artifactId>forms</artifactId>
    >        <version>1.0.5</version>
    > </dependency>
    > <dependency>
    >        <groupId>jgoodies</groupId>
    >        <artifactId>looks</artifactId>
    >        <version>1.3.1</version>
    > </dependency>
    > <dependency>
    >        <groupId>jgroups</groupId>
    >        <artifactId>jgroups-all</artifactId>
    >        <version>2.2.7</version>
    > </dependency>
    > <dependency>
    >        <groupId>org.apache.geronimo.specs</groupId>
    >        <artifactId>geronimo-jms_1.1_spec</artifactId>
    >        <version>1.1</version>
    > </dependency>
    > <dependency>
    >        <groupId>org.apache.geronimo.specs</groupId>
    >        <artifactId>geronimo-jta_1.1_spec</artifactId>
    >        <version>1.0</version>
    > </dependency>
    > <dependency>
    >        <groupId>ognl</groupId>
    >        <artifactId>ognl</artifactId>
    >        <version>2.6.7</version>
    > </dependency>
    > <dependency>
    >        <groupId>opensymphony</groupId>
    >        <artifactId>oscache</artifactId>
    >        <version>2.3.2</version>
    > </dependency>
    > <dependency>
    >        <groupId>org.scopemvc</groupId>
    >        <artifactId>scopemvc</artifactId>
    >        <version>1.0.1</version>
    > </dependency>
    > <dependency>
    >        <groupId>javax.servlet</groupId>
    >        <artifactId>servlet-api</artifactId>
    >        <version>2.4</version>
    > </dependency>
    > <dependency>
    >        <groupId>jivesoftware</groupId>
    >        <artifactId>smack</artifactId>
    >        <version>2.2.1</version>
    > </dependency>
    > <dependency>
    >        <groupId>jivesoftware</groupId>
    >        <artifactId>smackx</artifactId>
    >        <version>2.2.1</version>
    > </dependency>
    >
    >
    >
    > On Aug 16, 2010, at 10:04 PM, Mike Kienenberger wrote:
    >>
    >> If there's a chance the package is unavailable, we probably should bundle
    >> it.
    >> That's what we're doing with the ashwood graph library, right?
    >>
    >> I still am pretty ignorant about maven, but I'd say that a first pass
    >> of a buildable source distribution would be to take the svn checkout
    >> of the project, and then somehow point all non-ASF jar file references
    >> to a local lib directory containing jar files that aren't under ASF
    >> maintenance, and build from that.
    >>
    >> Again, I haven't looked at Cayenne 3, so I don't know just how many
    >> files we're talking about at this point, but our list of licensed jar
    >> files doesn't seem like it's that large.
    >>
    >> On Mon, Aug 16, 2010 at 2:43 PM, Andrus Adamchik <andru..bjectstyle.org>
    >> wrote:
    >>>
    >>> Yeah I vaguely remember this discussion -
    >>> http://markmail.org/thread/njray5dbazwcdcts and I have to agree with
    >>> Roy's
    >>> logic, which convinces me better than a mention of "policy" :-)
    >>>
    >>> Ok, so say we have a Maven build system that exports buildable source
    >>> with
    >>> poms... which, considering the reliance on a public Maven repo for
    >>> dependencies may not be that "buildable" 6 months from now :-/ Even
    >>> open-source Apache-licensed (but not ASF-managed) packages may disappear.
    >>> How far can we go with that? (a good experiment would be to take a year
    >>> old
    >>> existing ASF package and trying to build it, say Geronimo or something of
    >>> that level of complexity..)
    >>>
    >>> Andrus
    >>>
    >>>
    >>> On Aug 16, 2010, at 9:28 PM, Mike Kienenberger wrote:
    >>>>
    >>>> It's one thing to state that it may not be a requirement to provide
    >>>> buildable source, but it's quite a stretch to claim that we do provide
    >>>> buildable source immediately after a message stating "It is
    >>>> practically impossible to do that as the build system is ... well,
    >>>> complex"  Taken to extremes, you could say that a jar file full of
    >>>> classes is buildable source, since, with the right tools, you can
    >>>> decompile the class files back to java code.
    >>>>
    >>>> But 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.   We wouldn't say that we know that the release has a
    >>>> valid checksum without checking it ourselves or that the release has a
    >>>> valid signature without checking it ourselves.   Same goes for
    >>>> building it.
    >>>>
    >>>>
    >>>> On Mon, Aug 16, 2010 at 2:08 PM, Andrus Adamchik
    >>>> <andru..bjectstyle.org>
    >>>> wrote:
    >>>>>
    >>>>> On Aug 16, 2010, at 6:32 PM, Mike Kienenberger wrote:
    >>>>>
    >>>>>> Every ASF release must contain a source package, which must be
    >>>>>> sufficient for a user to build and test the release provided they have
    >>>>>> access to the appropriate platform and tools. The source package must
    >>>>>> be cryptographically signed by the Release Manager with a detached
    >>>>>> signature; and that package together with its signature must be tested
    >>>>>> prior to voting +1 for release. Folks who vote +1 for release may
    >>>>>> offer their own cryptographic signature to be concatenated with the
    >>>>>> detached signature file (at the Release Manager's discretion) prior to
    >>>>>> release.
    >>>>>
    >>>>> Actually, re-reading the above and it doesn't state a need of a working
    >>>>> pom.xml or build.xml, just the source that is matching the binaries. In
    >>>>> this
    >>>>> respect we don't violate this. We do not provide a buildfile, but a
    >>>>> Java
    >>>>> developer will be able to build the source regardless (e.g. by writing
    >>>>> build.xml himself, or importing sources in Eclipse).
    >>>>>
    >>>>> Andrus
    >>>>>
    >>>>>
    >>>>
    >>>>
    >>>>
    >>>> On Mon, Aug 16, 2010 at 2:08 PM, Andrus Adamchik
    >>>> <andru..bjectstyle.org>
    >>>> wrote:
    >>>>>
    >>>>> On Aug 16, 2010, at 6:32 PM, Mike Kienenberger wrote:
    >>>>>
    >>>>>> Every ASF release must contain a source package, which must be
    >>>>>> sufficient for a user to build and test the release provided they have
    >>>>>> access to the appropriate platform and tools. The source package must
    >>>>>> be cryptographically signed by the Release Manager with a detached
    >>>>>> signature; and that package together with its signature must be tested
    >>>>>> prior to voting +1 for release. Folks who vote +1 for release may
    >>>>>> offer their own cryptographic signature to be concatenated with the
    >>>>>> detached signature file (at the Release Manager's discretion) prior to
    >>>>>> release.
    >>>>>
    >>>>> Actually, re-reading the above and it doesn't state a need of a working
    >>>>> pom.xml or build.xml, just the source that is matching the binaries. In
    >>>>> this
    >>>>> respect we don't violate this. We do not provide a buildfile, but a
    >>>>> Java
    >>>>> developer will be able to build the source regardless (e.g. by writing
    >>>>> build.xml himself, or importing sources in Eclipse).
    >>>>>
    >>>>> Andrus
    >>>>>
    >>>>>
    >>>>
    >>>
    >>>
    >>
    >
    >



    This archive was generated by hypermail 2.0.0 : Mon Aug 16 2010 - 19:49:26 UTC