Re: [jelly] Jelly build fun and Library registration

[Justin Wood <ju...@braidquest.com>]

On Saturday 01 November 2003 00:18, Paul Libbrecht wrote:
> Justin Wood wrote:
> > Firstly let me say that I'm a big fan of jelly and give big kudos to the
> > developers.   I use some of the standard Jelly tags but mostly I use my
> > own libraries and tags to add a generic scripting capability to other
> > applications.   These are some of the niggles I have with regard to the
> > way Jelly is built and how custom (non Apache) libraries are added
> >
> > - Currently if you want to build jelly you got to get 30 jars to satisfy
> > dependancies.   Does it have to be this way?
>
> No, you actually don't need this to build the core and most of the
> taglibs. My jelly copies are mostly locally compiled but I never took
> the time to download the 30 jars.
> The need to download is related to licenses... these jars can't be
> distributed with jelly or be put in the maven repository.
>
> I think the best would be to have a finer way to control the taglibs
> being built....
>
Yes! 

> > If I look at the Maven distribution I see there is a Jelly  jar there and
> > it only has the core jelly packages and then there are some other jars
> > with separate jelly taglibs in them eg the ant and util tags.    Looking
> > at the jelly.properties file from Maven, it is also appears to be
> > different from the stand alone jelly version so it looks as if those
> > files are being made by mavens build (haven't downloaded the maven
> > source).    Since Jelly was split off from Maven this is understandable. 
> >  Is it the intention of the Jelly team to split the libraries and the
> > build in this way too?   ... cos I'd really like to see that and I think
> > a couple of others might (might they? ...)    Something like a
> > jelly-full.jar or jelly-core.jar with
> > jelly-optional.jar or jelly-core.jar with jelly-ant.jar, jelly-util.jar
> > ... etc would be cool
>
> It would sort of prevent the philosophy of small-projects of maven, I
> believe.
> Your request is closer to a request to get better runnables, or do I
> mistake ?
> An uberjar or something like this would probably be the best.
>
> Remember though... without the non-downloadable jars!

What I'm really trying to get at is a separation of the "Jelly engine" from 
the jelly tags.    The ideal situation would be some kind of run time 
discovery of dependancies so you can have an uberjar and you can figure out 
what dependancies are missing.    Like in ant when you run 

$~>ant -diagnostics 

and you get something like

...
ANT_HOME/lib jar listing
-------------------------------------------
catalina-ant.jar (14979 bytes)
xercesImpl.jar (831473 bytes)
ant.jar (720318 bytes)
xml-apis.jar (108484 bytes)
optional.jar (654735 bytes)
junit.jar (121070 bytes)

-------------------------------------------
 Tasks availability
-------------------------------------------
stlist : Missing dependency com.starbase.starteam.Item
telnet : Missing dependency com.oroinc.net.SocketClient
ftp : Missing dependency com.oroinc.net.ftp.FTP
jdepend : Missing dependency jdepend.xmlui.JDepend
script : Missing dependency com.ibm.bsf.BSFException
stcheckin : Missing dependency com.starbase.starteam.Folder
...

I suppose this would also benefit from commons discovery mentioned below.

Thank
Justin

>
> > - Also If you want to include your own neat namespace declaration
> >
> > like this
> > 	<jelly xmlns="jelly:core" xmlns:f="jelly:BQData">
> >
> > instead of this
> > 	<jelly xmlns="jelly:core"
> >                 
> > xmlns:f="jelly:com.braidquest.jelly.data.BQDataTagLibrary">
> >
> > ... then you have to edit the jelly.properties file inside the jar which
> > is a bit messy
>
> In the tasklist in the documentation there is a little hint about this,
> I think James Strachan intended to use something like the
> META-INF/services... but no-one has made the work since then.
> Presumably that work would be easier as commons-discovery has evolved.
>
> Paul
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [jelly] Jelly build fun and Library registration

[Paul Libbrecht <pa...@ags.uni-sb.de>]

On Lundi, nove 3, 2003, at 06:59 Europe/Paris, Justin Wood wrote:
>> I think the best would be to have a finer way to control the taglibs
>> being built....
>
> Yes!

Someone would need to do this. In the meantime you can simply remove 
the directories to be bothering you in the jelly-tags directory... that 
works fine (the recursive build is done through the reactor and only 
listing the projects).

> What I'm really trying to get at is a separation of the "Jelly engine" 
> from
> the jelly tags.    The ideal situation would be some kind of run time
> discovery of dependancies so you can have an uberjar and you can 
> figure out
> what dependancies are missing.    Like in ant when you run
>
> $~>ant -diagnostics
>
> and you get something like

I presume ant does this using the bootstrap mechanism...

But, hold-on, it might actually be that maven is providing exactly 
this... in maven you have to state your dependencies in the project.xml 
and it will download them for you if need be...
And you could crawl the list-archives for jellypack, there was 
something that was generating a project.xml from a jelly file.

But of course, if there was a better approach, possibly independent of 
Maven it would be nicer...

Paul


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org