Fedor Karpelevitch wrote:
>
> Just my 2c:
>
> I agree in general, but I would like to make sure that it will only depend on
> bare Ant without any additional jars or something- just what you get when you
> install Ant from the distro. The reason is the same why you do not want to
> depend on any jars being avail in system classpath or in lib/ext - because it
> creates all sorts of trouble when you are working on more than one project.
> What happens if two projects depend on two different versions of a jar (say
> xerces) available?
I don't use the bare ant, I place all the jars I need for all my
projects
in $ANT_HOME/lib. I use this version of Ant to build all my projects,
and this should work and it's what GUMP tries to detect problems when
they occur.
What CJAN might do eventually is place a set of common jars in a
location
where ant can use them. We could probably come up with a system where
a build.xml file could specify a specific version of a jar that would
be used in and placed in the classpath first if required.
Right now everything in $ANT_HOME/lib is placed in the classpath in
scripts distributed with Ant, but maybe a standard part of Ant build
files could use an ${ant.home} property and build a <path> from the jars
in the ${ant.home}/lib directory so that anything could be placed in
the classpath before the standard jars if you needed it.
> So i may only be good to share jars between coordinated
> project and still not always...
Yes, I agree that it should be encourage and I think most times it
works but we definitely have to account for exceptions even if it
is only a stopgap solution to a localized problem.
> And I'd be very careful about not depending on some features/bugs of a
> specific Ant version for the same reason.
I think Ant is rapidly becoming standard, I don't think this is
much of a problem and the goal of the Ant 2.0 release to make it
even more standard. They are shooting for an ever constant API :-)
But again they're might be localized problems. Maybe another standard
part of build files could be a stated version requirement if there are
bugs in certain beta releases that people are using they can be warned
to get a version that is known to work.
>
> PS. BTW, Jason, could you clarify what CJAN stands for? I assume C is for
> Common or smth. and J is either Java or Jakarta....
CJAN = Comprehensive Java Archive Network, the same was taken from
the perl equivalent which is CPAN :-)
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://jakarta.apache.org/commons
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
