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 <[email protected]> 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 <[email protected]> >> 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 >>>> <[email protected]> >>>> 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 >>>> <[email protected]> >>>> 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 >>>>> >>>>> >>>> >>> >>> >> > >
