You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Donald <pe...@apache.org> on 2002/05/06 12:30:19 UTC
[myrmidon] Type Librarys
Hi,
I just went and updated some of my older tasks to latest stuff you are doing
with Librarys. Anyways before I got too far with that I was wondering where
exactly you are going with the library stuff. Have you got a grand unified
plan and if so want to xml-ize it and add it to our xdocs :)
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Adam Murdoch <ad...@apache.org>.
On Wed, 8 May 2002 22:12, Darrell DeBoer wrote:
> > > 1) Types/TypeLibs can be registered under a namespace, which *may* be
> > > taken from the AntlibDescriptor (say, an AntLib name attribute), but
> > > can also be specified in other ways (eg <typelib library="ant1compat"
> > > namespace="ant1"/>)
> >
> > I would prefer it to be based on the name of the antlib (ie internal name
> > specified in manifest). I suppose we could support aliasing but I would
> > like the importing to be very obvious that it is aliasing that is
> > occuring. Maybe something like
> >
> > <typelib library="ant1compat" namespace-alias="ant1"/>
>
> This is (almost) exactly how it now works:
> <typelib library="ant1compat" namespace="ant1"/>
>
> Maybe we can default to use the antlib name if available, where namespace
> isn't specified.
Definitely. <typelib library="somelib"/> should work pretty much like
on-demand imports in Java (ie, import somepackage.*), so that each type is
available by fqn, and by short name if unambiguous.
> Me too - and that's how it is. As long as we're aware that this means that
> Type names cannot include '.'.
And a bunch of other characters - we should run the type and role names
through a really strict NameValidator, eg, letters and digits only.
> Converter classname is munged in the
> ConverterDefinition into a type name. (SInce converter names are never
> exposed it doesn't really matter what they look like internally)
Well, not entirely. You need to know the name when importing an individual
converter from an antlib: <typelib library=".." role="converter" name=".."/>.
Not a big deal, the munged name is probably fine there.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Darrell DeBoer <da...@apache.org>.
G'day
On Wed, 8 May 2002 19:43, Peter Donald wrote:
> On Mon, 6 May 2002 22:53, Darrell DeBoer wrote:
> > On Mon, 6 May 2002 20:30, Peter Donald wrote:
>
> > 1) Types/TypeLibs can be registered under a namespace, which *may* be
> > taken from the AntlibDescriptor (say, an AntLib name attribute), but can
> > also be specified in other ways (eg <typelib library="ant1compat"
> > namespace="ant1"/>)
>
> I would prefer it to be based on the name of the antlib (ie internal name
> specified in manifest). I suppose we could support aliasing but I would
> like the importing to be very obvious that it is aliasing that is occuring.
> Maybe something like
>
> <typelib library="ant1compat" namespace-alias="ant1"/>
This is (almost) exactly how it now works:
<typelib library="ant1compat" namespace="ant1"/>
Maybe we can default to use the antlib name if available, where namespace
isn't specified. Currently, the default/empty namespace ("") would be used
where the namespace wasn't defined. The empty namespace means that these
types, once hidden, can't be accessed by FQNames.
> > 3) When a TypeFactory is requested from the TypeManager, the name used
> > can be fully qualified (has a namespace), or not. A fully-qualified name
> > requests a named type registered under a particular namespace, whereas an
> > unqualified name involves searching all namespaces for the type name. If
> > the name cannot be resolved unambiguously within the context, an error
> > occurs.
>
> Sounds good. Basically this is the same way as imports are handled in java
> yes?
similar, yes.
>
> > 4) The core antlibs (ant/lib/*) will be registered under an antlib name,
>
> +1
Currently under a hardcoded "ant" namespace - marked as "todo".
>
> > 4a) Perhaps types explicitly type-def'd (not an entire library, a single
> > type), would be considered higher precedence again, above <import>ed
> > library types.
>
> +1
NYI
>
> > Question:
> > Is it appropriate to use XML namespaces for ant type namespaces?
>
> It has been -1'ed before due to complexity and extra cruft that it adds. We
> could still use ":" as separator but type resolution should follow the java
> import tules which I believe what you propose does ;) However I would
> prefer "."
Me too - and that's how it is. As long as we're aware that this means that
Type names cannot include '.'. Converter classname is munged in the
ConverterDefinition into a type name. (SInce converter names are never
exposed it doesn't really matter what they look like internally)
My next step is to get the Ant1Compat stuff working again, to write an
Ant1TargetTask, and to change the transforming project builder to do nothing
more than add the following to the top of Ant1 build files.
<typelib library="ant1compat" namespace="ant1"/>
That will be cool...
--
ciao,
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Adam Murdoch <ad...@apache.org>.
On Wed, 8 May 2002 19:43, Peter Donald wrote:
> > 1) Types/TypeLibs can be registered under a namespace, which *may* be
> > taken from the AntlibDescriptor (say, an AntLib name attribute), but can
> > also be specified in other ways (eg <typelib library="ant1compat"
> > namespace="ant1"/>)
>
> I would prefer it to be based on the name of the antlib (ie internal name
> specified in manifest).
As in the 'extension-name' attribute, or something else? Using extension-name
fits nicely with the antlib == extension + descriptor model.
> I suppose we could support aliasing
We already support aliasing on <typelib>, <import> and the various -def tasks
(though the attribute is called 'namespace' rather than 'namespace-alias').
You should check out the patch - It's very cool.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Peter Donald <pe...@apache.org>.
On Mon, 6 May 2002 22:53, Darrell DeBoer wrote:
> On Mon, 6 May 2002 20:30, Peter Donald wrote:
> > Hi,
> >
> > I just went and updated some of my older tasks to latest stuff you are
> > doing with Librarys. Anyways before I got too far with that I was
> > wondering where exactly you are going with the library stuff. Have you
> > got a grand unified plan and if so want to xml-ize it and add it to our
> > xdocs :)
>
> Hi Pete,
>
> Not exactly what you're asking, but I've been playing around with something
> related, which I think will prove quite powerful.
excellent.
> The idea is to provide a namespace mechanism for type names, so that
> multiple types with the same name can coexist. The idea runs as follows:
woohoo!
> 1) Types/TypeLibs can be registered under a namespace, which *may* be taken
> from the AntlibDescriptor (say, an AntLib name attribute), but can also be
> specified in other ways (eg <typelib library="ant1compat"
> namespace="ant1"/>)
I would prefer it to be based on the name of the antlib (ie internal name
specified in manifest). I suppose we could support aliasing but I would like
the importing to be very obvious that it is aliasing that is occuring. Maybe
something like
<typelib library="ant1compat" namespace-alias="ant1"/>
> 2) As works currently, Type name resolution occurs by first looking in the
> local context, and then up through the parent contexts.
yep.
Same as propertys, and resources and anything else we add?
> 3) When a TypeFactory is requested from the TypeManager, the name used can
> be fully qualified (has a namespace), or not. A fully-qualified name
> requests a named type registered under a particular namespace, whereas an
> unqualified name involves searching all namespaces for the type name. If
> the name cannot be resolved unambiguously within the context, an error
> occurs.
Sounds good. Basically this is the same way as imports are handled in java
yes?
> 4) The core antlibs (ant/lib/*) will be registered under an antlib name,
+1
> 4a) Perhaps types explicitly type-def'd (not an entire library, a single
> type), would be considered higher precedence again, above <import>ed
> library types.
+1
> 5) I'm also thinking about separating the TypeManager interface into a
> superinterface (TypeRegistry?) with just the lookup methods, together with
+1 (Matches how Converter evolved).
> Question:
> Is it appropriate to use XML namespaces for ant type namespaces?
It has been -1'ed before due to complexity and extra cruft that it adds. We
could still use ":" as separator but type resolution should follow the java
import tules which I believe what you propose does ;) However I would prefer
"."
> (And if not, are we planning to utilise XML namespaces for anything?).
At one stage I played with idea of basing "aspects" on namespaces but that
turned out to be too complex an idea and most of its benefits can be got by
simpler/better mechanisms (ie use ContainerTasks rather than aspects).
Considering aspects are largely axed atm I am not sure I can see it be using
at all ...
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Darrell DeBoer <da...@apache.org>.
G'day,
I just committed some stuff - before I read this email. So it's lucky you
didn't put forward any strenuous objections ;).
On Wed, 8 May 2002 13:01, Adam Murdoch wrote:
> On Mon, 6 May 2002 22:53, Darrell DeBoer wrote:
> > 4) The core antlibs (ant/lib/*) will be registered under an antlib name,
> > or maybe a default namespace.
>
> Antlib name, I reckon. Keep the default namespace empty for the project to
> play with.
>
Currently, the DefaultEmbeddor puts them into a hard-coded "ant" namespace.
But once Library.getName() gives us something useful, we can use that.
The container stuff is added under the "myrmidon" namespace. I'm not sure if
this is necessary, or makes any difference.
> > 4a) Perhaps types explicitly type-def'd (not an entire library, a single
> > type), would be considered higher precedence again, above <import>ed
> > library types.
>
> +1. Have it search from most specific -> least specific.
Since the TypeManager doesn't yet have methods for adding a set of types as a
whole, this is not yet done. (One step at a time). We'll need to add support
to the NamespaceAwareTypeFactory for this, but it shouldn't be too hard.
(You'll see one commented-out method where I was playing with this idea, but
it needs a bit more work).
>
> > 5) I'm also thinking about separating the TypeManager interface into a
> > superinterface (TypeRegistry?) with just the lookup methods, together
> > with the full TypeManger, which will include the registration methods.
>
> Have a look at how Converter/ConverterRegistry and RoleManager/RoleRegistry
> have been split up. TypeManager should be consistent with them.
Will do.
>
> > Question:
> > Is it appropriate to use XML namespaces for ant type namespaces?
>
> Not if you don't declare it as an XML namespace. Which is just extra crap
> that would have to be added to project files (and which is going to cause
> weirdness when projects move between validating and non-validating
> parsers).
>
> Let's go with the '.' separator. We'll need to do something about
> converters, since its class name is used as its type name.
That's what I did, and for converters I'm hacking the classname to remove the
'.' characters within the ConverterTypeDeployer. (or ConverterDefinition? - I
can't remember exactly).
>
> > (And if not, are we planning to utilise XML namespaces for anything?).
>
> Maybe. A good candidate would be the aspecty stuff that has been talked
> about. But that would involve using a single ant: namespace, rather than a
> bunch of different namespaces.
Fair enough.
Have a play with it and let me know what you reckon.
One thing I'm thinking about is the ability to add a library under a
namespace, but not have it intrude on the default namespace. So that you
could import the Ant1Compat antlib under the "ant1" namespace, but <javac>
etc would still refer to the core tasks. The only way to access the imported
types would be with a qualified name (<ant1.javac>).
--
ciao,
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Adam Murdoch <ad...@apache.org>.
On Mon, 6 May 2002 22:53, Darrell DeBoer wrote:
> The idea is to provide a namespace mechanism for type names, so that
> multiple types with the same name can coexist.
Yay.
> 4) The core antlibs (ant/lib/*) will be registered under an antlib name, or
> maybe a default namespace.
Antlib name, I reckon. Keep the default namespace empty for the project to
play with.
> 4a) Perhaps types explicitly type-def'd (not an entire library, a single
> type), would be considered higher precedence again, above <import>ed
> library types.
+1. Have it search from most specific -> least specific.
> 5) I'm also thinking about separating the TypeManager interface into a
> superinterface (TypeRegistry?) with just the lookup methods, together with
> the full TypeManger, which will include the registration methods.
Have a look at how Converter/ConverterRegistry and RoleManager/RoleRegistry
have been split up. TypeManager should be consistent with them.
> Question:
> Is it appropriate to use XML namespaces for ant type namespaces?
Not if you don't declare it as an XML namespace. Which is just extra crap
that would have to be added to project files (and which is going to cause
weirdness when projects move between validating and non-validating parsers).
Let's go with the '.' separator. We'll need to do something about converters,
since its class name is used as its type name.
> (And if not, are we planning to utilise XML namespaces for anything?).
Maybe. A good candidate would be the aspecty stuff that has been talked
about. But that would involve using a single ant: namespace, rather than a
bunch of different namespaces.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Darrell DeBoer <da...@apache.org>.
On Mon, 6 May 2002 20:30, Peter Donald wrote:
> Hi,
>
> I just went and updated some of my older tasks to latest stuff you are
> doing with Librarys. Anyways before I got too far with that I was wondering
> where exactly you are going with the library stuff. Have you got a grand
> unified plan and if so want to xml-ize it and add it to our xdocs :)
Hi Pete,
Not exactly what you're asking, but I've been playing around with something
related, which I think will prove quite powerful.
The idea is to provide a namespace mechanism for type names, so that multiple
types with the same name can coexist. The idea runs as follows:
1) Types/TypeLibs can be registered under a namespace, which *may* be taken
from the AntlibDescriptor (say, an AntLib name attribute), but can also be
specified in other ways (eg <typelib library="ant1compat" namespace="ant1"/>)
2) As works currently, Type name resolution occurs by first looking in the
local context, and then up through the parent contexts.
3) When a TypeFactory is requested from the TypeManager, the name used can be
fully qualified (has a namespace), or not. A fully-qualified name requests a
named type registered under a particular namespace, whereas an unqualified
name involves searching all namespaces for the type name. If the name cannot
be resolved unambiguously within the context, an error occurs.
4) The core antlibs (ant/lib/*) will be registered under an antlib name, or
maybe a default namespace. But other versions of these antlibs could be
imported under a different namespace. A build file could then mix-and-match
tasks from different versions of libraries, by using FQ names.
Example: The Ant1compat antlib will be in ant/ext, and will be explicitly
imported by the Ant1Compat project builder. But the task names will not need
to be munged, because they will simply override the core ones with the same
name. Then, a build file could mix core and ant1compat tasks,
eg
- <if>: comes from "core" antlib, since ant1compat has no such task.
- <core.javac>: use the myrmidon version of javac
- <ant1.javadoc>: use the ant1compat version of javadoc
- <javadoc>: resolve to the ant1compat version (same as <ant1.javadoc> because
it's imported in the project, and thus has higher precedence - this is the
current behaviour with imported typelibs).
4a) Perhaps types explicitly type-def'd (not an entire library, a single
type), would be considered higher precedence again, above <import>ed library
types.
5) I'm also thinking about separating the TypeManager interface into a
superinterface (TypeRegistry?) with just the lookup methods, together with
the full TypeManger, which will include the registration methods. Then, the
actual TypeManager could allow registration of an entire TypeRegistry (rather
than registering each type separately) under a particular namespace. One
implementation of TypeRegistry would provide all types for a type library,
and would be provided by the TypeLibraryDeployer. Then, the TypeRegistry
would be reused, rather than all types needing re-registration every time a
type library is deployed/imported.
Question:
Is it appropriate to use XML namespaces for ant type namespaces? If so, we can
use the <namespace:typename> syntax in our build files. Otherwise, should we
use '.', and disallow this in regular type names? We can't really use a
character that's permitted in type names, as there's no was to distinguish
between "namespace.typename" and "type.name".
(And if not, are we planning to utilise XML namespaces for anything?).
--
ciao,
Daz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
How about some ANT related name: like ANT Colony (a collection of ANT tasks that work/live toguether).
Maybe ANT tasks, should be "ANT worker" tasks.
:-)
Jose Alberto
----- Original Message -----
From: "Peter Donald" <pe...@apache.org>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Wednesday, May 08, 2002 10:54 AM
Subject: Re: [myrmidon] Type Librarys
On Wed, 8 May 2002 11:57, Adam Murdoch wrote:
> Nothing that good. The goal is to add a 'virtual antlib' layer, to
> consolidate how we deal with all the different classpaths and classloaders
> we have - things like antlibs, extensions, the myrmidon api, and ad hoc
> classpaths.
Thats kinda neat. So an antlib == Extension with a descriptor? I like that.
> * Come up with a better name for Library. Any ideas?
Traditional Names: Module, Unit, Extension, Plugin,
Java-esque Names: Box, Barrel, Bag, Pocket, Sack etc
Nothing really jumps out at me. About the only thing that could be useful
would be using some kooky terminology (Box, Barrel, Bag etc) because it has
no intellectual baggae and we can effectively decide exactly what the word
means.
> * Expose the myrmidon api, extensions, and antlibs as libraries via
> LibraryManager (kinda done). Also expose tools.jar and a jaxp impl, either
> as extensions or directly as libraries. I'm not happy with LibraryManager
> atm, maybe the lookup and factory methods need to be split into separate
> interfaces.
Be careful about breaking things up too much. More interfaces/ideas/concepts
mean more complexity and it is starting to get a bit hairy as it stands. ie
the difference between Extension/LibraryManager, *Descriptors, Extension,
Library, Deploying vs registering vs managing etc.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Peter Donald <pe...@apache.org>.
On Wed, 8 May 2002 23:24, Adam Murdoch wrote:
> On Wed, 8 May 2002 22:33, Peter Donald wrote:
> > > Yep. Looking at what I was planning, it will be a fair bit simpler if
> > > I axe the antlib/extension split sooner rather than later. If we're
> > > happy with this model, I'll make the changes.
> >
> > +1 from me. However we are going to have to enhance the
> > ExtensionManager/LibraryManager so that it does caching. ie We need to
> > cache the name/version/spec of each library outside library so that we
> > don't have to scan all the manifests which can be a costly operation.
> > Everytime a jar changes, is added or disapears we update the cache file
> > and go from there.
>
> Um, not sure what you mean. Sounds like a persistent cache, containing the
> extension info for each jar?
Basically - yep ;)
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Adam Murdoch <ad...@apache.org>.
On Wed, 8 May 2002 22:33, Peter Donald wrote:
> > Yep. Looking at what I was planning, it will be a fair bit simpler if I
> > axe the antlib/extension split sooner rather than later. If we're happy
> > with this model, I'll make the changes.
>
> +1 from me. However we are going to have to enhance the
> ExtensionManager/LibraryManager so that it does caching. ie We need to
> cache the name/version/spec of each library outside library so that we
> don't have to scan all the manifests which can be a costly operation.
> Everytime a jar changes, is added or disapears we update the cache file and
> go from there.
Um, not sure what you mean. Sounds like a persistent cache, containing the
extension info for each jar?
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Peter Donald <pe...@apache.org>.
On Wed, 8 May 2002 20:53, Adam Murdoch wrote:
> On Wed, 8 May 2002 19:54, Peter Donald wrote:
> > On Wed, 8 May 2002 11:57, Adam Murdoch wrote:
> > > Nothing that good. The goal is to add a 'virtual antlib' layer, to
> > > consolidate how we deal with all the different classpaths and
> > > classloaders we have - things like antlibs, extensions, the myrmidon
> > > api, and ad hoc classpaths.
> >
> > Thats kinda neat. So an antlib == Extension with a descriptor?
>
> Yep. Looking at what I was planning, it will be a fair bit simpler if I
> axe the antlib/extension split sooner rather than later. If we're happy
> with this model, I'll make the changes.
+1 from me. However we are going to have to enhance the
ExtensionManager/LibraryManager so that it does caching. ie We need to cache
the name/version/spec of each library outside library so that we don't have
to scan all the manifests which can be a costly operation. Everytime a jar
changes, is added or disapears we update the cache file and go from there.
> I wonder if we want to do away with the .atl filenames, and just make
> everything a .jar?
+1
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Peter Donald <pe...@apache.org>.
On Wed, 8 May 2002 21:14, Rob Oxspring wrote:
> Surely "antlet" would be the most Java-esque name.
I like that ;)
> Really can't decide which should win the dull+descriptive vs kooky debate
> though.
>
> :o)
Comes down to how much baggage we want to inherit from existing terminology or
names. ie Whenever I am talking about Java "Optional Packages/Extensions" I
basically have to point people at relevant spec page because it is
meaningless generic term (and inconsistent with other java terminology).
Terms like "jar", "servlet" or "EJB" held no meaning prior to being used and
thus carried no baggage. You either knew what they were or you didn't.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Rob Oxspring <ro...@imapmail.org>.
Surely "antlet" would be the most Java-esque name.
Really can't decide which should win the dull+descriptive vs kooky debate
though.
:o)
Rob
----- Original Message -----
From: "Peter Donald" <pe...@apache.org>
To: "Ant Developers List" <an...@jakarta.apache.org>
Sent: Wednesday, May 08, 2002 10:54 AM
Subject: Re: [myrmidon] Type Librarys
On Wed, 8 May 2002 11:57, Adam Murdoch wrote:
> Nothing that good. The goal is to add a 'virtual antlib' layer, to
> consolidate how we deal with all the different classpaths and classloaders
> we have - things like antlibs, extensions, the myrmidon api, and ad hoc
> classpaths.
Thats kinda neat. So an antlib == Extension with a descriptor? I like that.
> * Come up with a better name for Library. Any ideas?
Traditional Names: Module, Unit, Extension, Plugin,
Java-esque Names: Box, Barrel, Bag, Pocket, Sack etc
Nothing really jumps out at me. About the only thing that could be useful
would be using some kooky terminology (Box, Barrel, Bag etc) because it has
no intellectual baggae and we can effectively decide exactly what the word
means.
> * Expose the myrmidon api, extensions, and antlibs as libraries via
> LibraryManager (kinda done). Also expose tools.jar and a jaxp impl,
either
> as extensions or directly as libraries. I'm not happy with LibraryManager
> atm, maybe the lookup and factory methods need to be split into separate
> interfaces.
Be careful about breaking things up too much. More interfaces/ideas/concepts
mean more complexity and it is starting to get a bit hairy as it stands. ie
the difference between Extension/LibraryManager, *Descriptors, Extension,
Library, Deploying vs registering vs managing etc.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Adam Murdoch <ad...@apache.org>.
On Wed, 8 May 2002 19:54, Peter Donald wrote:
> On Wed, 8 May 2002 11:57, Adam Murdoch wrote:
> > Nothing that good. The goal is to add a 'virtual antlib' layer, to
> > consolidate how we deal with all the different classpaths and
> > classloaders we have - things like antlibs, extensions, the myrmidon api,
> > and ad hoc classpaths.
>
> Thats kinda neat. So an antlib == Extension with a descriptor?
Yep. Looking at what I was planning, it will be a fair bit simpler if I axe
the antlib/extension split sooner rather than later. If we're happy with
this model, I'll make the changes.
I wonder if we want to do away with the .atl filenames, and just make
everything a .jar?
> > * Come up with a better name for Library. Any ideas?
>
> Traditional Names: Module, Unit, Extension, Plugin,
> Java-esque Names: Box, Barrel, Bag, Pocket, Sack etc
>
> Nothing really jumps out at me. About the only thing that could be useful
> would be using some kooky terminology (Box, Barrel, Bag etc) because it has
> no intellectual baggae and we can effectively decide exactly what the word
> means.
Maybe antlib or typelibrary or something like that might be a good name.
Otherwise a kooky name would work.
> > * Expose the myrmidon api, extensions, and antlibs as libraries via
> > LibraryManager (kinda done). Also expose tools.jar and a jaxp impl,
> > either as extensions or directly as libraries. I'm not happy with
> > LibraryManager atm, maybe the lookup and factory methods need to be split
> > into separate interfaces.
>
> Be careful about breaking things up too much. More
> interfaces/ideas/concepts mean more complexity and it is starting to get a
> bit hairy as it stands. ie the difference between Extension/LibraryManager,
> *Descriptors, Extension, Library, Deploying vs registering vs managing etc.
Yep, absolutely. The motivation for all this was to streamline the whole
model, and to clean up as much of the complexity as possible. We're still in
the early stages of building the new infrastructure around the old stuff, so
its all a bit complicated. A bit of pruning, and things should be much
better.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Peter Donald <pe...@apache.org>.
On Wed, 8 May 2002 11:57, Adam Murdoch wrote:
> Nothing that good. The goal is to add a 'virtual antlib' layer, to
> consolidate how we deal with all the different classpaths and classloaders
> we have - things like antlibs, extensions, the myrmidon api, and ad hoc
> classpaths.
Thats kinda neat. So an antlib == Extension with a descriptor? I like that.
> * Come up with a better name for Library. Any ideas?
Traditional Names: Module, Unit, Extension, Plugin,
Java-esque Names: Box, Barrel, Bag, Pocket, Sack etc
Nothing really jumps out at me. About the only thing that could be useful
would be using some kooky terminology (Box, Barrel, Bag etc) because it has
no intellectual baggae and we can effectively decide exactly what the word
means.
> * Expose the myrmidon api, extensions, and antlibs as libraries via
> LibraryManager (kinda done). Also expose tools.jar and a jaxp impl, either
> as extensions or directly as libraries. I'm not happy with LibraryManager
> atm, maybe the lookup and factory methods need to be split into separate
> interfaces.
Be careful about breaking things up too much. More interfaces/ideas/concepts
mean more complexity and it is starting to get a bit hairy as it stands. ie
the difference between Extension/LibraryManager, *Descriptors, Extension,
Library, Deploying vs registering vs managing etc.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [myrmidon] Type Librarys
Posted by Adam Murdoch <ad...@apache.org>.
On Mon, 6 May 2002 20:30, Peter Donald wrote:
> Hi,
>
> I just went and updated some of my older tasks to latest stuff you are
> doing with Librarys. Anyways before I got too far with that I was wondering
> where exactly you are going with the library stuff. Have you got a grand
> unified plan
Nothing that good. The goal is to add a 'virtual antlib' layer, to
consolidate how we deal with all the different classpaths and classloaders we
have - things like antlibs, extensions, the myrmidon api, and ad hoc
classpaths.
The plan is something like:
* Come up with a better name for Library. Any ideas?
* Use the library abstraction in the deployer, so that it does not need to
know what it is deploying from (done).
* Move code for searching for antlibs out of the embeddor, workspace, and
import tasks, into a new TypeLibraryManager service, and model antlibs as
libraries (done).
* Expose the myrmidon api, extensions, and antlibs as libraries via
LibraryManager (kinda done). Also expose tools.jar and a jaxp impl, either
as extensions or directly as libraries. I'm not happy with LibraryManager
atm, maybe the lookup and factory methods need to be split into separate
interfaces.
* Add some library query datatypes and/or tasks, so you can do things like
include the classpath for a library in a <path>, or use the classloader for a
library in the <java> task. Probably add some kind of <library> datatype, so
that an ad hoc library can be defined in a project and used in the same way.
* Allow antlibs to extend other non-final antlibs. Maybe do away with the
distinction between antlibs and extensions at that point.
* Move descriptor parsing out of the deployer, and behind Library somewhere.
* Make ExtensionManager (and maybe TypeLibraryManager) into a compound
service, which delegates to a bunch of child ExtensionManagers.
Plus a bunch more stuff - it's a bit of an experiment at this stage.
> and if so want to xml-ize it and add it to our xdocs :)
Sure. I might java-fy it first.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>