--On Dienstag, 5. Februar 2002 05:20 -0800 Andy Clark <[EMAIL PROTECTED]>
wrote:
> Torsten Curdt wrote:
>> ...why don't we just store the uri where the required jar can
>> be found and let "ant" get those jars for us?
>
> For the same reason that I was opposed to changing the Xerces-J
> build
>> Also requiring a net connection to do every build is a
>really bad idea
>> IMO - there are plenty of valid reasons why folks might want
>to do work
>> without the network. This also goes for being
>cross-platform: we need
>> to support users on Windoze as well as the unixes of the world so
Tangent to this dicussion - beside fetching .jars from URL's it is also
possible to use the CVSROOT/modules to make 'virtual directories' or files
- which during checkout are mapped from one cvs tree; see the -ant tree;
into the another one, say -batik. You would still have to ensure that it
is m
Ainsi parlait Shane Curcuru :
> you Guillaume Rousse <[EMAIL PROTECTED]> wrote
>
> > Yes, it requires a net connection, but from
> > where did you get your initial source tarball anyway ?
>
> Well, a couple of points:
> -- The initial download requires a net connection somewhere, but man
you Guillaume Rousse <[EMAIL PROTECTED]> wrote
> Yes, it requires a net connection, but from
> where did you get your initial source tarball anyway ?
Well, a couple of points:
-- The initial download requires a net connection somewhere, but many
folks only download once and then work on
From: "Torsten Curdt" <[EMAIL PROTECTED]>
> [snip]
>
> > What about having each needed jar as a property, and have a setup task
check
> > if those file are effectively present, and if not, downloading them for
a
> > known location ?
> > This way, someone already having those jars locally just ha
[snip]
> What about having each needed jar as a property, and have a setup task check
> if those file are effectively present, and if not, downloading them for a
> known location ?
> This way, someone already having those jars locally just have to set those
> properties on the command line, and s
Ainsi parlait Shane Curcuru :
> Torsten Curdt wrote:
>
> > > ...why don't we just store the uri where the required jar can
> > > be found and let "ant" get those jars for us?
>
> you Andy Clark <[EMAIL PROTECTED]> wrote
>
> > For the same reason that I was opposed to changing t
Torsten Curdt wrote:
> > ...why don't we just store the uri where the required jar can
> > be found and let "ant" get those jars for us?
you Andy Clark <[EMAIL PROTECTED]> wrote
> For the same reason that I was opposed to changing the Xerces-J
> build to pull the xml-commons
Torsten Curdt wrote:
> ...why don't we just store the uri where the required jar can
> be found and let "ant" get those jars for us?
For the same reason that I was opposed to changing the Xerces-J
build to pull the xml-commons code from CVS: it requires a net
connection to build the code. Plus, s
This is just an idea...
All the messages about 3rd party licensing made me think...
...why don't we just store the uri where the required jar can
be found and let "ant" get those jars for us?
Comments?
--
Torsten
-
In case of
On 4 Feb 2002, Theodore W. Leung wrote:
> I believe that checking in a copy of the W3C license file as
> w3c.LICENSE will solve the problem. I have a small doubt because w3c
> jar is a collection of files from multiple jars. If someone on the PMC
> with more legal background can confirm, that
The w3c jar looks like a concatenation of various java-binding jars
from the W3C web site. It only appears in xml-cocoon/lib.
I believe that checking in a copy of the W3C license file as
w3c.LICENSE will solve the problem. I have a small doubt because w3c
jar is a collection of files from mult
13 matches
Mail list logo
