commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morgan Delagrange <mdela...@yahoo.com>
Subject Re: [jelly] Re: Inheriting Dependencies
Date Sun, 26 Jan 2003 17:35:21 GMT

--- dion@multitask.com.au wrote:
> I'll test this and the reactor, as it means we can
> do away with:
> 1) The included entity in all project.xmls

Yup.  I'd still like to keep using an entity, but it
looks like our pesky XML parsers are not going to
cooperate.  At least we'll only have two build files
to keep in sync, rather than thirty-two.

> 2) The ant build-all file

Still need that, I think.

> and have an easy way to do things to all taglibs at
> once, e.g.
> - Regen gump descriptor

Yup.

> - Regen ant build file

Yup.

> - Build jars etc

I don't think Maven is a replacement for the build-all
script when it comes to thorough regression testing. 
The build-all script is much closer to the GUMP
environment, so it's a good script to check when Maven
is building fine but GUMP is puking.  Especially
problematic is the fact that Maven uses Jelly
internally; I'm not sure the classpath isolation is
all there yet.  Also, the build-all script is set up
to do some tedious tasks very quickly; for example:

    ant -f build-all.xml clean-skiplibs jar-jsl

will rebuild the JSL taglib and all its Jelly
dependencies (core, xml taglib, ant taglib, log
taglib, junit taglib) from scratch in about a minute
or so.

- Morgan

> --
> dIon Gillard, Multitask Consulting
> Blog:     
> http://www.freeroller.net/page/dion/Weblog
> Work:      http://www.multitask.com.au
> 
> 
> Jason van Zyl <jason@zenplex.com> wrote on
> 25/01/2003 02:09:55 AM:
> 
> > Hi,
> > 
> > As a result of splitting up the Jelly tag
> libraries the folks doing the
> > split (Dion and others) discovered a need to share
> a set of common
> > dependencies so as a result I've tentatively added
> the ability for a
> > child to take it's parent's dependencies. The
> dependencies are the only
> > place where this aggregation is happening as
> opposed to overriding
> > inheritance.
> > 
> > For me I know this will help in situations that
> involve building a set
> > of components. Currently in Plexus there is a
> build and test for each
> > component. There are JARs that are required for
> the tests to run, and
> > prior to this change I had to declare the test
> time JARs in each of the
> > components. So now I can define them in the parent
> and everything works
> > just fine.
> > 
> > This may bring up other problems during the
> copying of dependencies and
> > I'm not sure what else, but it's in HEAD now so if
> it causes untold
> > grief I'll back it out.
> > 
> > -- 
> > jvz.
> > 
> > Jason van Zyl
> > jason@zenplex.com
> > http://tambora.zenplex.org
> > 
> > In short, man creates for himself a new religion
> of a rational
> > and technical order to justify his work and to be
> justified in it.
> > 
> >   -- Jacques Ellul, The Technological Society
> > 
> > 
> > --
> > To unsubscribe, e-mail:  
> <mailto:turbine-maven-user-
> > unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:turbine-maven-user-
> > help@jakarta.apache.org>
> > 
> 
> > ForwardSourceID:NT000A809E 
> 
> --
> To unsubscribe, e-mail:  
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> 


=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message