You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Scott Stirling <ss...@macromedia.com> on 2001/07/12 02:11:50 UTC
RE: thoughts on new builds (was: Re: [UPDATE] Converting existing
taglibs to use new build)
This sounds like something I've heard referred to as CJAN (a la PERL's
CPAN), and that was tossed around on the ant-dev list a while back. I don't
know why it hasn't taken off -- lack of a standard place to keep all the
libraries? Anyway, it's a great idea if we could implement it somehow.
Scott Stirling
-----Original Message-----
From: Glenn Nielsen
Shawn Bayern wrote:
>
> On Wed, 11 Jul 2001, Glenn Nielsen wrote:
>
> > I have a proposal.
> >
> > Why not give everyone a few weeks or so to use the new system.
> > Then we can call a VOTE on it.
>
> There are also middle-ground ideas, like providing a little script
written
> in Java to download the necessary libraries. (Does Ant support
anything
> like that? An "acquire and unpack" action?) If we kept all the
relevant
> URLs to libraries up to date, such a process might be as easy as
including
> all of our dependencies in CVS, and might not have any of the
drawbacks
> (which I agree are severe) of including other distributions with ours.
>
> Shawn
That is a great idea Shawn!
Ant does support getting files from remote systems using the <get> tag.
The only potential drawback are those remote sites which require a login
to download the jar file or distribution (Some Sun provided Java API's).
Hmmm, I wonder if we can get anyone to volunteer to test and/or
implement
this. James seems to have the itch that needs scatching. ;-)
Regards,
Glenn
Re: thoughts on new builds (was: Re: [UPDATE]
Convertingexistingtaglibs to use new build)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
James Strachan wrote:
>
> Hi Geir
>
> From: "Geir Magnusson Jr." <ge...@optonline.net>
> > James Strachan wrote:
> > >
> > > > This sounds like something I've heard referred to as CJAN (a la PERL's
> > > > CPAN), and that was tossed around on the ant-dev list a while back. I
> > > don't
> > > > know why it hasn't taken off -- lack of a standard place to keep all
> the
> > > > libraries? Anyway, it's a great idea if we could implement it
> somehow.
> > >
> > > Agreed.
> > >
> > > I'll see how CJAN is looking on jakarta-commons - last time I looked it
> > > wasn't too far away from being able to do some basic downloading - I
> think
> > > we've a great test case here on jakarta-tagilbs for CJAN ;-).
> > >
> > > I'll see if I can get some kind of ant target that will download all the
> > > required jars from somewhere. If we can get CJAN working then everyones
> > > happy (and we can use this technique on other jakarta projects too).
> I'll
> > > investigate further...
> >
> >
> > As the author of one of the implementations, I would be happy to work
> > here on this. I wrote the 'jjar' version currently sitting in
> > commons-sandbox.
> >
> > It is called 'jjar' for Jakarta Java Archive Repository. I felt that
> > CPAN was too big of a target to go after at first, with mirroring
> > servers and submission infrastructure - further, Java offers some unique
> > capabilities that allow us to think differently and tailor a solution
> > specifically for Java.
> >
> > The basic idea is that there is a repository of named, versioned jars
> > with a repository descriptor that allows the determination of
> > dependencies and such. This allows dependency requirements to be
> > flexible - you may then specify only what you need, and jjar figures out
> > the rest dependency-wise.
> >
> > Currently, the proof of concept code contains an ant task and a
> > standalone 'commandline' task which allow you to specify on the cmd line
> > and in ant any given jar(s) and it/they and dependencies are fetched
> > into your local repository.
> >
> > It works fine. I have a jar repository hosted on a publically
> > accessable machine, and the examples included demonstrate how it works.
> >
> > My next step was to add a 'jjar-aware' classloader, so the functionality
> > could be done on the fly at runtime.
> >
> > I am very interested in continuing work on this - it was something I
> > worked on very intensely after giving it much thought, but interest
> > seemed to die, so I stopped and did other things. (usual story :)
> >
> > So let me know if this is appealing :)
>
> Yes its appealing! :-)
>
> I followed the jjar / cjan discussions on jakarta-commons a while back and
> always meant to try out jjar (usual story :-)
> I was actually thinking of jjar in this thread, not CJAN (sorry Geir).
>
> This sounds exactly what we need!
Ok - I am going to review the thread (been a rough couple of days, so
have been dumping lists other than Velocity...) and see if I can try to
solve whatever problem needs to be solved :)
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: thoughts on new builds (was: Re: [UPDATE] Converting existingtaglibs to use new build)
Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Geir
From: "Geir Magnusson Jr." <ge...@optonline.net>
> James Strachan wrote:
> >
> > > This sounds like something I've heard referred to as CJAN (a la PERL's
> > > CPAN), and that was tossed around on the ant-dev list a while back. I
> > don't
> > > know why it hasn't taken off -- lack of a standard place to keep all
the
> > > libraries? Anyway, it's a great idea if we could implement it
somehow.
> >
> > Agreed.
> >
> > I'll see how CJAN is looking on jakarta-commons - last time I looked it
> > wasn't too far away from being able to do some basic downloading - I
think
> > we've a great test case here on jakarta-tagilbs for CJAN ;-).
> >
> > I'll see if I can get some kind of ant target that will download all the
> > required jars from somewhere. If we can get CJAN working then everyones
> > happy (and we can use this technique on other jakarta projects too).
I'll
> > investigate further...
>
>
> As the author of one of the implementations, I would be happy to work
> here on this. I wrote the 'jjar' version currently sitting in
> commons-sandbox.
>
> It is called 'jjar' for Jakarta Java Archive Repository. I felt that
> CPAN was too big of a target to go after at first, with mirroring
> servers and submission infrastructure - further, Java offers some unique
> capabilities that allow us to think differently and tailor a solution
> specifically for Java.
>
> The basic idea is that there is a repository of named, versioned jars
> with a repository descriptor that allows the determination of
> dependencies and such. This allows dependency requirements to be
> flexible - you may then specify only what you need, and jjar figures out
> the rest dependency-wise.
>
> Currently, the proof of concept code contains an ant task and a
> standalone 'commandline' task which allow you to specify on the cmd line
> and in ant any given jar(s) and it/they and dependencies are fetched
> into your local repository.
>
> It works fine. I have a jar repository hosted on a publically
> accessable machine, and the examples included demonstrate how it works.
>
> My next step was to add a 'jjar-aware' classloader, so the functionality
> could be done on the fly at runtime.
>
> I am very interested in continuing work on this - it was something I
> worked on very intensely after giving it much thought, but interest
> seemed to die, so I stopped and did other things. (usual story :)
>
> So let me know if this is appealing :)
Yes its appealing! :-)
I followed the jjar / cjan discussions on jakarta-commons a while back and
always meant to try out jjar (usual story :-)
I was actually thinking of jjar in this thread, not CJAN (sorry Geir).
This sounds exactly what we need!
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: using jjar (was Re: thoughts on new builds (was:
Re:[UPDATE]Converting existingtaglibs to use new build))
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
James Strachan wrote:
>
> From: "Geir Magnusson Jr." <ge...@optonline.net>
> > > I'll gladly help all I can integrating jjar into the jakarta-taglibs
> build
> > > process (as an optional target).
> >
> > How do you see it working? In just the build process, or at runtime?
>
> I think for now, just a build process that can download all the required
> jars to a local directory somewhere will do.
Yep - that concept is there already - the notion of a local repository.
We can either make it local by default in the build tree (say /lib
although that might not make sense - I haven't seen your build tree :),
and then extend through build.properties the ability to let a developer
use their 'global' local repository - a repository they use for all of
their projects, to limit duplication and save disk space.
> So then if a developer wishes to build the jakarta-taglibs for the first
> time they could do
>
> build download
> (then jjar kicks off, downloading local copies of all the required jars
> into a local repository)
> build dist
> (now do a build as we've got the jars somewhere).
or build dist, dist being dependant upon download
> Then the default build.properties could contain links to where the jars will
> be downloaded to.
Yep. Further, I made an example that bootstraps the whole thing - all
you need is jjar and a jdk, and it gets ant from the repository and
kicks off the build. Very cool, I think.
( I am one of the heretics that believe that while Ant is great as an
installed app, it's spectacular as a build tool that can come with a
distro ...)
> So the build would just run out of the box by default. If a user didn't want
> to use jjar but would rather use their own jars elsewhere, they could
> provide their own build.local.properties to override the defaults in
> build.properties.
Yep
geir
> > My vision for this kind of stuff is to see how far we can push
> > runtime-ish stuff... However, the build process use is easy, as it's
> > just another use of runtime...
>
> Agreed. I'm interested in the runtime side of things too - though probably
> not for the jakarta-taglibs build. Lets keep those thoughts for
> jakarta-commons.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: using jjar (was Re: thoughts on new builds (was: Re: [UPDATE]Converting existingtaglibs to use new build))
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Geir Magnusson Jr." <ge...@optonline.net>
> > I'll gladly help all I can integrating jjar into the jakarta-taglibs
build
> > process (as an optional target).
>
> How do you see it working? In just the build process, or at runtime?
I think for now, just a build process that can download all the required
jars to a local directory somewhere will do.
So then if a developer wishes to build the jakarta-taglibs for the first
time they could do
build download
(then jjar kicks off, downloading local copies of all the required jars
into a local repository)
build dist
(now do a build as we've got the jars somewhere).
Then the default build.properties could contain links to where the jars will
be downloaded to.
So the build would just run out of the box by default. If a user didn't want
to use jjar but would rather use their own jars elsewhere, they could
provide their own build.local.properties to override the defaults in
build.properties.
> My vision for this kind of stuff is to see how far we can push
> runtime-ish stuff... However, the build process use is easy, as it's
> just another use of runtime...
Agreed. I'm interested in the runtime side of things too - though probably
not for the jakarta-taglibs build. Lets keep those thoughts for
jakarta-commons.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: using jjar (was Re: thoughts on new builds
(was:Re:[UPDATE]Converting existingtaglibs to use new build))
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Glenn Nielsen wrote:
>
> Have you considered using SOAP, UDDI, and WSDL.
> Perhaps we can leverage those technologies to provide a directory
> service for different java technology API's, etc.
Yep - what I was trying to achieve with jjar is smallness, so it's easy
to get or include with a package. I found a very small SAX parser and
use that. The whole thing is quite small.
But yes, maybe UDDI is the way to go - let it boostrap itself and then
use UDDI for a better repository.
One strategy might be to stay the course with what we have, and figure
out what we really want, what is really effective, then roll a 2nd
version using UDDI...
>
> Rather than have one location where all the archives are stored,
> they can be distributed anywhere as long as the WSDL registry is
> kept up to date on one central server.
Right.
> I haven't had time to look at how jjar works.
It's pretty simple.. :)
geir
> Regards,
>
> Glenn
>
> "Geir Magnusson Jr." wrote:
> >
> > James Strachan wrote:
> > >
> > > Hi Geir
> > >
> > > I've had a little play with JJAR and it looks great. How shall we proceed?
> > >
> > > I'm guessing we'll need a shared repository document of all the JARs and
> > > where they can be downloaded from. Were you indending for the repository.xml
> > > to be on the jakarta site, shared across all jakarta projects, or for each
> > > seperate project to have their own?
> >
> > Right now, I have it on a publically accessable machine (but mine...)
> > and will move to jakarta.
> >
> > I think that to start, we can at least be the keepers of the jakarta
> > ones, and anything else that is useful. But the design intent is to
> > allow non-jakarta projects (say, JDOM) to host their own - our
> > repository map would keep a pointer to either the jar directly, or
> > another map there in JDOM-land. Not sure yet.
> >
> > For the momement, for jakarta projects, it can work either way. The
> > only requirement is that the jar manifest contains the 'project' name
> > and version of that distro. Its assumed that a format of
> >
> > X.Y-Z
> >
> > is sufficient for versioning anything. It's not clear if Y can be
> > '1.2', for example, but if we keep the versioning simple (i.e. break on
> > first . then on - ) it gives projects a bit of freedom. We just don't
> > want to get wacky...
> >
> > >
> > > I'll gladly help all I can integrating jjar into the jakarta-taglibs build
> > > process (as an optional target).
> >
> > How do you see it working? In just the build process, or at runtime?
> > My vision for this kind of stuff is to see how far we can push
> > runtime-ish stuff... However, the build process use is easy, as it's
> > just another use of runtime...
> >
> > geir
> >
> > --
> > Geir Magnusson Jr. geirm@optonline.net
> > System and Software Consulting
> > Developing for the web? See http://jakarta.apache.org/velocity/
> > You have a genius for suggesting things I've come a cropper with!
>
> --
> ----------------------------------------------------------------------
> Glenn Nielsen glenn@more.net | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: using jjar (was Re: thoughts on new builds (was:
Re:[UPDATE]Converting existingtaglibs to use new build))
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Have you considered using SOAP, UDDI, and WSDL.
Perhaps we can leverage those technologies to provide a directory
service for different java technology API's, etc.
Rather than have one location where all the archives are stored,
they can be distributed anywhere as long as the WSDL registry is
kept up to date on one central server.
I haven't had time to look at how jjar works.
Regards,
Glenn
"Geir Magnusson Jr." wrote:
>
> James Strachan wrote:
> >
> > Hi Geir
> >
> > I've had a little play with JJAR and it looks great. How shall we proceed?
> >
> > I'm guessing we'll need a shared repository document of all the JARs and
> > where they can be downloaded from. Were you indending for the repository.xml
> > to be on the jakarta site, shared across all jakarta projects, or for each
> > seperate project to have their own?
>
> Right now, I have it on a publically accessable machine (but mine...)
> and will move to jakarta.
>
> I think that to start, we can at least be the keepers of the jakarta
> ones, and anything else that is useful. But the design intent is to
> allow non-jakarta projects (say, JDOM) to host their own - our
> repository map would keep a pointer to either the jar directly, or
> another map there in JDOM-land. Not sure yet.
>
> For the momement, for jakarta projects, it can work either way. The
> only requirement is that the jar manifest contains the 'project' name
> and version of that distro. Its assumed that a format of
>
> X.Y-Z
>
> is sufficient for versioning anything. It's not clear if Y can be
> '1.2', for example, but if we keep the versioning simple (i.e. break on
> first . then on - ) it gives projects a bit of freedom. We just don't
> want to get wacky...
>
> >
> > I'll gladly help all I can integrating jjar into the jakarta-taglibs build
> > process (as an optional target).
>
> How do you see it working? In just the build process, or at runtime?
> My vision for this kind of stuff is to see how far we can push
> runtime-ish stuff... However, the build process use is easy, as it's
> just another use of runtime...
>
> geir
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> Developing for the web? See http://jakarta.apache.org/velocity/
> You have a genius for suggesting things I've come a cropper with!
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Addition for the Mailer taglib - recipient tag
Posted by Jayson Falkner <ja...@jspinsider.com>.
Hello,
I'd like to contribute this tag to the Mailer taglib. Currently the mailer
tags use different tags for a "to", "cc", and "bcc" address. This tag
provides the functionality of all three in one tag. The benefit being ease
of use.
Attached is the code for RecipientTag.java, the modified mailer.tld, and an
example JSP.
Jayson Falkner
jayson@jspinsider.com
Re: using jjar (was Re: thoughts on new
builds(was:Re:[UPDATE]Converting existingtaglibs to use new build))
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Shawn Bayern wrote:
>
> On Thu, 12 Jul 2001, Geir Magnusson Jr. wrote:
>
> > It is dangerous. However, in a network application - if the network
> > is unavailable, you are hosed anyway... that's they way I see it
> > working in a pure 'fetch' mode - when the network is down, the app is
> > useless, so the classloader having problems would be the least of your
> > worries.
>
> But just to play devil's advocate, "the network" isn't a monolithic
> entity. My institution's connection to Jakarta might be down because of a
> dropped link on the part of an intervening router.
>
Yes. However, Mr. Devil, I assume that when we get to the stage where a
bare classloader is ready, we can start fanning out the repository.
And yes, there will be a risk.
Further (and really dreaming here) that something like this will really
be useful where a connection provider can also provide application
services like the repository - an example would be how I understand the
NTT DoCoMo system works - NTT is the gatekeeper, and make sure that
facilities and services are available for their phone customers.
> If the plan would be to suggest always using local repositories, that's
> definitely less dangerous, but then I'm not convinced I'd prefer using a
> custom classloader over an NFS share. :-)
I think local if you can is best, as we know that the versions are
right, and it would be the fastest...
> Dunno... just exploring the ideas. Don't mean to sound negative; I think
> the overall effort is quite cool. I may just not (yet?) share your
> enthusiasm about the custom classloader, personally. The build-time
> advantages seem clear; the runtime ones, to me, seem less so.
No worries. I don't share the enthusiasm either for the custom
classloader yet when it comes to putting the rubber to the road - much
diddling has to be done. And in the end it may just suck :)
> Shawn
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: using jjar (was Re: thoughts on new builds (was:Re:[UPDATE]Converting
existingtaglibs to use new build))
Posted by Shawn Bayern <ba...@essentially.net>.
On Thu, 12 Jul 2001, Geir Magnusson Jr. wrote:
> It is dangerous. However, in a network application - if the network
> is unavailable, you are hosed anyway... that's they way I see it
> working in a pure 'fetch' mode - when the network is down, the app is
> useless, so the classloader having problems would be the least of your
> worries.
But just to play devil's advocate, "the network" isn't a monolithic
entity. My institution's connection to Jakarta might be down because of a
dropped link on the part of an intervening router.
If the plan would be to suggest always using local repositories, that's
definitely less dangerous, but then I'm not convinced I'd prefer using a
custom classloader over an NFS share. :-)
Dunno... just exploring the ideas. Don't mean to sound negative; I think
the overall effort is quite cool. I may just not (yet?) share your
enthusiasm about the custom classloader, personally. The build-time
advantages seem clear; the runtime ones, to me, seem less so.
Shawn
Re: using jjar (was Re: thoughts on new builds
(was:Re:[UPDATE]Converting existingtaglibs to use new build))
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Shawn Bayern wrote:
>
> On Thu, 12 Jul 2001, Geir Magnusson Jr. wrote:
>
> > > I think the idea is cool, but there are dangers that make it seem, at
> > > first glance, unwieldy. The runtime behavior of an application could be
> > > modified without local action on a user's end, for instance.
> >
> > Not if you specify versions specifically - because Velocity 1.1 is
> > Velocity 1.1. If you said Velocity *, then yes, if we in Velocity land
> > weren't so good about deprecation :) then you could get into real
> > trouble. And that's what happens when you use a classpath, right? :)
> >
> > (I think the classpath is evil...)
> >
> > > Also, do you have any thoughts about a particular security model? (E.g.,
> > > how to accommodate unsigned jars or to determine what certificates are
> > > appropriate?)
> >
> > No - that's a good thing to think about.
>
> The two are related, I think; the thing I was getting at by asking how
> much you anticipate occuring at runtime (via a custom classloader) is that
> it becomes hard to ensure that an application is "knowable" if it's
> affected by things like network availability, or perhaps by a compromised
> server somewhere. I can't imagine setting up a production application,
> for instance, that has dependencies this far beyond the production
> entity's control. (However, the classloader might simplify development
> and testing... still, without an explicit security model, it feel like too
> much would be happening automatically if the classloader automatically
> fetched new versions of things.)
>
> I think the idea is rather cool, and it's a novel approach, but I also
> think it's very dangerous. :)
It is dangerous. However, in a network application - if the network is
unavailable, you are hosed anyway... that's they way I see it working
in a pure 'fetch' mode - when the network is down, the app is useless,
so the classloader having problems would be the least of your worries.
For a non network dependant app, its a great way to deploy if it uses a
local repository... although it may not be a big deal...
>
> Shawn
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: using jjar (was Re: thoughts on new builds
(was:Re:[UPDATE]Converting existingtaglibs to use new build))
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
James Strachan wrote:
>
> From: "Shawn Bayern" <ba...@essentially.net>
> > On Thu, 12 Jul 2001, Geir Magnusson Jr. wrote:
> >
> > > > I think the idea is cool, but there are dangers that make it seem, at
> > > > first glance, unwieldy. The runtime behavior of an application could
> be
> > > > modified without local action on a user's end, for instance.
> > >
> > > Not if you specify versions specifically - because Velocity 1.1 is
> > > Velocity 1.1. If you said Velocity *, then yes, if we in Velocity land
> > > weren't so good about deprecation :) then you could get into real
> > > trouble. And that's what happens when you use a classpath, right? :)
> > >
> > > (I think the classpath is evil...)
> > >
> > > > Also, do you have any thoughts about a particular security model?
> (E.g.,
> > > > how to accommodate unsigned jars or to determine what certificates are
> > > > appropriate?)
> > >
> > > No - that's a good thing to think about.
> >
> > The two are related, I think; the thing I was getting at by asking how
> > much you anticipate occuring at runtime (via a custom classloader) is that
> > it becomes hard to ensure that an application is "knowable" if it's
> > affected by things like network availability, or perhaps by a compromised
> > server somewhere. I can't imagine setting up a production application,
> > for instance, that has dependencies this far beyond the production
> > entity's control. (However, the classloader might simplify development
> > and testing... still, without an explicit security model, it feel like too
> > much would be happening automatically if the classloader automatically
> > fetched new versions of things.)
> >
> > I think the idea is rather cool, and it's a novel approach, but I also
> > think it's very dangerous. :)
>
> I see jjar as being a *great* development tool. It could be used to make a
> binary release which would contain all the JARs used to make the build.
>
> So jjar can be used to make a production release but the production release
> itself (a tarball) defines exactly which JARs are used. That way there is no
> uncertainty in a production release.
>
yep :)
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: using jjar (was Re: thoughts on new builds (was: Re:[UPDATE]Converting
existingtaglibs to use new build))
Posted by Shawn Bayern <ba...@essentially.net>.
On Fri, 13 Jul 2001, James Strachan wrote:
> I see jjar as being a *great* development tool. It could be used to
> make a binary release which would contain all the JARs used to make
> the build.
>
> So jjar can be used to make a production release but the production
> release itself (a tarball) defines exactly which JARs are used. That
> way there is no uncertainty in a production release.
Right. My fears are just about a runtime custom classloader.
Shawn
Re: using jjar (was Re: thoughts on new builds (was: Re:[UPDATE]Converting existingtaglibs to use new build))
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Shawn Bayern" <ba...@essentially.net>
> On Thu, 12 Jul 2001, Geir Magnusson Jr. wrote:
>
> > > I think the idea is cool, but there are dangers that make it seem, at
> > > first glance, unwieldy. The runtime behavior of an application could
be
> > > modified without local action on a user's end, for instance.
> >
> > Not if you specify versions specifically - because Velocity 1.1 is
> > Velocity 1.1. If you said Velocity *, then yes, if we in Velocity land
> > weren't so good about deprecation :) then you could get into real
> > trouble. And that's what happens when you use a classpath, right? :)
> >
> > (I think the classpath is evil...)
> >
> > > Also, do you have any thoughts about a particular security model?
(E.g.,
> > > how to accommodate unsigned jars or to determine what certificates are
> > > appropriate?)
> >
> > No - that's a good thing to think about.
>
> The two are related, I think; the thing I was getting at by asking how
> much you anticipate occuring at runtime (via a custom classloader) is that
> it becomes hard to ensure that an application is "knowable" if it's
> affected by things like network availability, or perhaps by a compromised
> server somewhere. I can't imagine setting up a production application,
> for instance, that has dependencies this far beyond the production
> entity's control. (However, the classloader might simplify development
> and testing... still, without an explicit security model, it feel like too
> much would be happening automatically if the classloader automatically
> fetched new versions of things.)
>
> I think the idea is rather cool, and it's a novel approach, but I also
> think it's very dangerous. :)
I see jjar as being a *great* development tool. It could be used to make a
binary release which would contain all the JARs used to make the build.
So jjar can be used to make a production release but the production release
itself (a tarball) defines exactly which JARs are used. That way there is no
uncertainty in a production release.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: using jjar (was Re: thoughts on new builds (was: Re:[UPDATE]Converting
existingtaglibs to use new build))
Posted by Shawn Bayern <ba...@essentially.net>.
On Thu, 12 Jul 2001, Geir Magnusson Jr. wrote:
> > I think the idea is cool, but there are dangers that make it seem, at
> > first glance, unwieldy. The runtime behavior of an application could be
> > modified without local action on a user's end, for instance.
>
> Not if you specify versions specifically - because Velocity 1.1 is
> Velocity 1.1. If you said Velocity *, then yes, if we in Velocity land
> weren't so good about deprecation :) then you could get into real
> trouble. And that's what happens when you use a classpath, right? :)
>
> (I think the classpath is evil...)
>
> > Also, do you have any thoughts about a particular security model? (E.g.,
> > how to accommodate unsigned jars or to determine what certificates are
> > appropriate?)
>
> No - that's a good thing to think about.
The two are related, I think; the thing I was getting at by asking how
much you anticipate occuring at runtime (via a custom classloader) is that
it becomes hard to ensure that an application is "knowable" if it's
affected by things like network availability, or perhaps by a compromised
server somewhere. I can't imagine setting up a production application,
for instance, that has dependencies this far beyond the production
entity's control. (However, the classloader might simplify development
and testing... still, without an explicit security model, it feel like too
much would be happening automatically if the classloader automatically
fetched new versions of things.)
I think the idea is rather cool, and it's a novel approach, but I also
think it's very dangerous. :)
Shawn
Re: using jjar (was Re: thoughts on new builds (was:
Re:[UPDATE]Converting existingtaglibs to use new build))
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Shawn Bayern wrote:
>
> On Thu, 12 Jul 2001, Geir Magnusson Jr. wrote:
>
> > How do you see it working? In just the build process, or at runtime?
> > My vision for this kind of stuff is to see how far we can push
> > runtime-ish stuff... However, the build process use is easy, as it's
> > just another use of runtime...
>
> What's your vision of how it would work at runtime? Would it create a
> local cache and check whether new versions were available at runtime?
There are multiple questions there...
1) My use of 'runtime' here is very misleading and I promise to stop - I
really mean letting an app use a configured classloader to let classes
be loaded w/o the fetch step. The idea was that a programmer can
specify in the application itself what it needs, setting up a
classloader to service the rest of the app. But for using in ant, no
such thing is needed - it already works in ant.
2) Yes, the notion of local cache is already there for speed.
3) Re the versions, that trickier - because things are specifically
versioned, you have the option of specifying if you want a specific
version of something, say Velocity 1.1, or you don't care, so Velocity
*. In the former, you can check the local cache directly because you
need a specific version. With the latter, you check the repository to
see what the latest is, and then if not in the local cache, you fetch.
So it does (or is suppsoed to) support the specification of either a
specific or latest.
>
> I think the idea is cool, but there are dangers that make it seem, at
> first glance, unwieldy. The runtime behavior of an application could be
> modified without local action on a user's end, for instance.
Not if you specify versions specifically - because Velocity 1.1 is
Velocity 1.1. If you said Velocity *, then yes, if we in Velocity land
weren't so good about deprecation :) then you could get into real
trouble. And that's what happens when you use a classpath, right? :)
(I think the classpath is evil...)
> Also, do you have any thoughts about a particular security model? (E.g.,
> how to accommodate unsigned jars or to determine what certificates are
> appropriate?)
No - that's a good thing to think about.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: using jjar (was Re: thoughts on new builds (was: Re: [UPDATE]Converting
existingtaglibs to use new build))
Posted by Shawn Bayern <ba...@essentially.net>.
On Thu, 12 Jul 2001, Geir Magnusson Jr. wrote:
> How do you see it working? In just the build process, or at runtime?
> My vision for this kind of stuff is to see how far we can push
> runtime-ish stuff... However, the build process use is easy, as it's
> just another use of runtime...
What's your vision of how it would work at runtime? Would it create a
local cache and check whether new versions were available at runtime?
I think the idea is cool, but there are dangers that make it seem, at
first glance, unwieldy. The runtime behavior of an application could be
modified without local action on a user's end, for instance.
Also, do you have any thoughts about a particular security model? (E.g.,
how to accommodate unsigned jars or to determine what certificates are
appropriate?)
Shawn
Re: using jjar (was Re: thoughts on new builds (was: Re:
[UPDATE]Converting existingtaglibs to use new build))
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
James Strachan wrote:
>
> Hi Geir
>
> I've had a little play with JJAR and it looks great. How shall we proceed?
>
> I'm guessing we'll need a shared repository document of all the JARs and
> where they can be downloaded from. Were you indending for the repository.xml
> to be on the jakarta site, shared across all jakarta projects, or for each
> seperate project to have their own?
Right now, I have it on a publically accessable machine (but mine...)
and will move to jakarta.
I think that to start, we can at least be the keepers of the jakarta
ones, and anything else that is useful. But the design intent is to
allow non-jakarta projects (say, JDOM) to host their own - our
repository map would keep a pointer to either the jar directly, or
another map there in JDOM-land. Not sure yet.
For the momement, for jakarta projects, it can work either way. The
only requirement is that the jar manifest contains the 'project' name
and version of that distro. Its assumed that a format of
X.Y-Z
is sufficient for versioning anything. It's not clear if Y can be
'1.2', for example, but if we keep the versioning simple (i.e. break on
first . then on - ) it gives projects a bit of freedom. We just don't
want to get wacky...
>
> I'll gladly help all I can integrating jjar into the jakarta-taglibs build
> process (as an optional target).
How do you see it working? In just the build process, or at runtime?
My vision for this kind of stuff is to see how far we can push
runtime-ish stuff... However, the build process use is easy, as it's
just another use of runtime...
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
using jjar (was Re: thoughts on new builds (was: Re: [UPDATE] Converting existingtaglibs to use new build))
Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Geir
I've had a little play with JJAR and it looks great. How shall we proceed?
I'm guessing we'll need a shared repository document of all the JARs and
where they can be downloaded from. Were you indending for the repository.xml
to be on the jakarta site, shared across all jakarta projects, or for each
seperate project to have their own?
I'll gladly help all I can integrating jjar into the jakarta-taglibs build
process (as an optional target).
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: thoughts on new builds (was: Re: [UPDATE] Converting
existingtaglibs to use new build)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
James Strachan wrote:
>
> > This sounds like something I've heard referred to as CJAN (a la PERL's
> > CPAN), and that was tossed around on the ant-dev list a while back. I
> don't
> > know why it hasn't taken off -- lack of a standard place to keep all the
> > libraries? Anyway, it's a great idea if we could implement it somehow.
>
> Agreed.
>
> I'll see how CJAN is looking on jakarta-commons - last time I looked it
> wasn't too far away from being able to do some basic downloading - I think
> we've a great test case here on jakarta-tagilbs for CJAN ;-).
>
> I'll see if I can get some kind of ant target that will download all the
> required jars from somewhere. If we can get CJAN working then everyones
> happy (and we can use this technique on other jakarta projects too). I'll
> investigate further...
As the author of one of the implementations, I would be happy to work
here on this. I wrote the 'jjar' version currently sitting in
commons-sandbox.
It is called 'jjar' for Jakarta Java Archive Repository. I felt that
CPAN was too big of a target to go after at first, with mirroring
servers and submission infrastructure - further, Java offers some unique
capabilities that allow us to think differently and tailor a solution
specifically for Java.
The basic idea is that there is a repository of named, versioned jars
with a repository descriptor that allows the determination of
dependencies and such. This allows dependency requirements to be
flexible - you may then specify only what you need, and jjar figures out
the rest dependency-wise.
Currently, the proof of concept code contains an ant task and a
standalone 'commandline' task which allow you to specify on the cmd line
and in ant any given jar(s) and it/they and dependencies are fetched
into your local repository.
It works fine. I have a jar repository hosted on a publically
accessable machine, and the examples included demonstrate how it works.
My next step was to add a 'jjar-aware' classloader, so the functionality
could be done on the fly at runtime.
I am very interested in continuing work on this - it was something I
worked on very intensely after giving it much thought, but interest
seemed to die, so I stopped and did other things. (usual story :)
So let me know if this is appealing :)
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!
Re: thoughts on new builds (was: Re: [UPDATE] Converting existing taglibs to use new build)
Posted by James Strachan <ja...@yahoo.co.uk>.
> This sounds like something I've heard referred to as CJAN (a la PERL's
> CPAN), and that was tossed around on the ant-dev list a while back. I
don't
> know why it hasn't taken off -- lack of a standard place to keep all the
> libraries? Anyway, it's a great idea if we could implement it somehow.
Agreed.
I'll see how CJAN is looking on jakarta-commons - last time I looked it
wasn't too far away from being able to do some basic downloading - I think
we've a great test case here on jakarta-tagilbs for CJAN ;-).
I'll see if I can get some kind of ant target that will download all the
required jars from somewhere. If we can get CJAN working then everyones
happy (and we can use this technique on other jakarta projects too). I'll
investigate further...
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: New calendar tag is ready
Posted by Boyd Waters <bw...@aoc.nrao.edu>.
Matthias Bohlen wrote:
> a few days ago, I announced that I was going to develop a new tag for the
> datetime taglib called "calendar". The first version is ready now. It
> generates a monthly calendar as an HTML table with clickable day numbers
> that call JavaScript event handlers. The colors and CSS classes of all the
> table elements are configurable via JSP attributes of the calendar tag.
Great!
Last December I submitted a taglib that did this same thing, but used
the <PRE> tag for the HTML.
My tag had quite a bit of flexibility to it, which is perhaps why no one
cared. But anyhow, please look at
http://www.aoc.nrao.edu/~bwaters/pub/taglib/calendar-taglib.html
Perhaps we could merge these two:
<dt:calendar output="pre" />
would emit the <pre> - formatted HTML, and
<dt:calendar output="table" />
would emit the table HTML.
Thank you for using CSS!
So.. merge them?
-- boyd
---------
Boyd Waters bwaters@nrao.edu
National Radio Astronomy Observatory http://www.nrao.edu
PO Box 0 Socorro, NM 87801 505.835.7346
http://www.zocalo.net/~waters
waters@zocalo.net
---------
RE: New calendar tag is ready
Posted by Christoph Wilhelms <Ch...@t-online.de>.
> Hi,
>
> a few days ago, I announced that I was going to develop a new tag for the
> datetime taglib called "calendar". The first version is ready now. It
> generates a monthly calendar as an HTML table with clickable day numbers
> that call JavaScript event handlers. The colors and CSS classes of all the
> table elements are configurable via JSP attributes of the calendar tag.
>
> To give you an impression of what is going on, I have attached
> the files for
> you: the JSP source and the HTML sample output that even works
> off-line! The
> CSS is also included.
>
> Pleas test it and give me a feedback. If someone tells me how to get into
> the CVS system, I'll check in the code.
Hi!
I submitted such a thing - including (JavaSript) Calendar-Popup Field and
simple i18n about 6 month ago - I did not even got a response :-( - I
couldn't see the reason :-(. Hope you are more Lucky then I was :-)
Greetinx,
Chris
New calendar tag is ready
Posted by Matthias Bohlen <mb...@mbohlen.de>.
Hi,
a few days ago, I announced that I was going to develop a new tag for the
datetime taglib called "calendar". The first version is ready now. It
generates a monthly calendar as an HTML table with clickable day numbers
that call JavaScript event handlers. The colors and CSS classes of all the
table elements are configurable via JSP attributes of the calendar tag.
To give you an impression of what is going on, I have attached the files for
you: the JSP source and the HTML sample output that even works off-line! The
CSS is also included.
Pleas test it and give me a feedback. If someone tells me how to get into
the CVS system, I'll check in the code.
Yours...
Matthias
---
Matthias Bohlen
Luise-Albertz-Str. 25
53340 Meckenheim
Germany
Fon: +49 170 772 8545
Fax: +49 1212 5 11 43 44 26
Email: mbohlen@mbohlen.de
Web: http://www.mbohlen.de/
Re: thoughts on new builds (was: Re: [UPDATE] Converting existingtaglibs
to use new build)
Posted by "Joseph B. Ottinger" <jo...@adjacency.org>.
I'd worked on something like this for the taglib roadmap at adjacency.org,
but it was *hardly* dynamic - I also note that jsptags does something like
this, although it's rarely maintained nowadays. I'd be happy to commit
some resources to this idea, though.
On Thu, 12 Jul 2001, Eduardo Pelegri-Llopart wrote:
> I think that a CPAN for tag libraries would be just GREAT! If anybody
> is willing, go for it. It will be work, but I think it would be very
> useful for the whole community.
>
> ====
>
> The one-click downloader thingie can be done independently of the tag
> lib repository. One only needs some sort of stable URLs for the
> resources.
>
> A variation could take advantage that your customers already have a
> Servlet/JSP container around and use a Web Application...
>
> - eduard/o
>
>
>
> Scott Stirling wrote:
> >
> > This sounds like something I've heard referred to as CJAN (a la PERL's
> > CPAN), and that was tossed around on the ant-dev list a while back. I don't
> > know why it hasn't taken off -- lack of a standard place to keep all the
> > libraries? Anyway, it's a great idea if we could implement it somehow.
> >
> > Scott Stirling
> >
> > -----Original Message-----
> > From: Glenn Nielsen
> >
> > Shawn Bayern wrote:
> > >
> > > On Wed, 11 Jul 2001, Glenn Nielsen wrote:
> > >
> > > > I have a proposal.
> > > >
> > > > Why not give everyone a few weeks or so to use the new system.
> > > > Then we can call a VOTE on it.
> > >
> > > There are also middle-ground ideas, like providing a little script
> > written
> > > in Java to download the necessary libraries. (Does Ant support
> > anything
> > > like that? An "acquire and unpack" action?) If we kept all the
> > relevant
> > > URLs to libraries up to date, such a process might be as easy as
> > including
> > > all of our dependencies in CVS, and might not have any of the
> > drawbacks
> > > (which I agree are severe) of including other distributions with ours.
> > >
> > > Shawn
> >
> > That is a great idea Shawn!
> >
> > Ant does support getting files from remote systems using the <get> tag.
> > The only potential drawback are those remote sites which require a login
> > to download the jar file or distribution (Some Sun provided Java API's).
> >
> > Hmmm, I wonder if we can get anyone to volunteer to test and/or
> > implement
> > this. James seems to have the itch that needs scatching. ;-)
> >
> > Regards,
> >
> > Glenn
>
-----------------------------------------------------------
Joseph B. Ottinger joeo@adjacency.org
http://adjacency.org/ IT Consultant
Re: thoughts on new builds (was: Re: [UPDATE] Converting existingtaglibs
to use new build)
Posted by Eduardo Pelegri-Llopart <Ed...@Sun.COM>.
I think that a CPAN for tag libraries would be just GREAT! If anybody
is willing, go for it. It will be work, but I think it would be very
useful for the whole community.
====
The one-click downloader thingie can be done independently of the tag
lib repository. One only needs some sort of stable URLs for the
resources.
A variation could take advantage that your customers already have a
Servlet/JSP container around and use a Web Application...
- eduard/o
Scott Stirling wrote:
>
> This sounds like something I've heard referred to as CJAN (a la PERL's
> CPAN), and that was tossed around on the ant-dev list a while back. I don't
> know why it hasn't taken off -- lack of a standard place to keep all the
> libraries? Anyway, it's a great idea if we could implement it somehow.
>
> Scott Stirling
>
> -----Original Message-----
> From: Glenn Nielsen
>
> Shawn Bayern wrote:
> >
> > On Wed, 11 Jul 2001, Glenn Nielsen wrote:
> >
> > > I have a proposal.
> > >
> > > Why not give everyone a few weeks or so to use the new system.
> > > Then we can call a VOTE on it.
> >
> > There are also middle-ground ideas, like providing a little script
> written
> > in Java to download the necessary libraries. (Does Ant support
> anything
> > like that? An "acquire and unpack" action?) If we kept all the
> relevant
> > URLs to libraries up to date, such a process might be as easy as
> including
> > all of our dependencies in CVS, and might not have any of the
> drawbacks
> > (which I agree are severe) of including other distributions with ours.
> >
> > Shawn
>
> That is a great idea Shawn!
>
> Ant does support getting files from remote systems using the <get> tag.
> The only potential drawback are those remote sites which require a login
> to download the jar file or distribution (Some Sun provided Java API's).
>
> Hmmm, I wonder if we can get anyone to volunteer to test and/or
> implement
> this. James seems to have the itch that needs scatching. ;-)
>
> Regards,
>
> Glenn