cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
Subject Re: [VOTE] release 3.0.1
Date Mon, 16 Aug 2010 19:48:37 GMT
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 <andrus@objectstyle.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 <andrus@objectstyle.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
>>>> <andrus@objectstyle.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
>>>> <andrus@objectstyle.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
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

Mime
View raw message