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 "Geir Magnusson Jr." <ge...@optonline.net> on 2001/07/12 16:40:56 UTC
Re: using jjar (was Re: thoughts on new builds (was: Re:
[UPDATE]Converting existingtaglibs to use new build))
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!
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