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:36:37 UTC