Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
From: "Adam Murdoch" <adammurdoch@apache.org>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Subject: RE: [myrmidon] Move framework outta myrmidon?
Date: Wed, 3 Apr 2002 21:35:07 +1000
Message-ID: <CLEMKEJLBJDGBHEDNCPHKEJFEJAA.adammurdoch@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Importance: Normal
In-Reply-To: <200203280734.g2S7YXl00589@mail017.syd.optusnet.com.au>


> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]

>=20
> On Thu, 28 Mar 2002 16:02, Adam Murdoch wrote:
> > > hmmm. I didn't notice that. Was this something you added? In
> > > theory it could
> > > completely be removed because I can't see how you would want=20
> to use it as
> > > DataTypes are not likely to match the role unless they were
> > > registered under
> > > role in which case the next bit of code will never get executed.
> > >
> > >  // Use the generic 'data-type' role.
> > >         final TypeFactory factory =3D m_typeManager.getFactory(
> > > DataType.ROLE );
> > >         if( !factory.canCreate( name ) )
> > >         {
> > >             throw new NoSuchPropertyException();
> > >         }
> > >         return factory.create( name );
> > >
> > > So can't we just delete that code ?
> >
> > It's used for 2 (experimental) cases, that are kinda handy:
> >
> > * Where the add() method's type does not map to a role type,=20
> data-type is
> > used as the role.  This means you don't have to create a role,=20
> and can just
> > use plain data-types instead.
>=20
> Really don't like that use ;) Seems like an ugly hack. Either it=20
> is pluggable=20
> or its not. And if it is pluggable we want it to be as strongly typed =
as=20
> possible (ie it implements the correct interface) and all objects that =

> implement a role interface should register themselves under that role.
>=20

Fair enough.  I'm happy to axe that one.

> > * Allows you to use a plain data-type as a nested element=20
> instead of a role
> > type, and the configurer will attempt to convert it to the=20
> expected type.
>=20
> Hmm not sure what use this is. If you wanted this behaviour why=20
> not just add=20
> in something like
>=20
> addName( MyType myType )
>=20
> ?=20
>=20
> I think I must be missing something.
>=20

It's handy for evolution, since:

* The container type doesn't need to know anything about the source =
type.  This lets you, for example, add new nested elements to a =
container type that you don't control the source for, and where =
polymorphism won't work (like, say, where you don't control the source =
for the source types either).

* The conversion is decoupled from both the container type and the =
source types.  This means that you can easily replace the conversion.  =
It also is useful for bridging between 2 polymorphic type hierarchies.

Having said that, implicit conversion might be a bit too much.  For one =
thing, the above things can be done using an explicit adaptor type.  It =
also blurs the namespace of nested elements, since any datatype can be =
used (which makes error reporting a little harder).

If we were to remove this, I wonder whether we should also get rid of =
implicit conversion of references too?


> > It *does* encourage bad practice.  What we need is a solution that =
sits
> > somewhere between the extremes of no sharing, and opening up=20
> everything.=20
> > Some controlled sharing would be a good thing.  For example, we want =
the
> > stuff in the ant1compat antlib to be visible to those antlibs=20
> that need it,
> > without making it visible to everything.  Same is true of a lot of =
the
> > stuff in framework.
>=20
> True. Hmm ... I really think that the extension mechanism can be=20
> made to do=20
> this. I really don't want users having to worry about mucking=20
> about with all=20
> this stuff. It may be an absolute PITA for us to code it but I=20
> think that is=20
> better than making users suffer.=20
>=20

Yep, +10000 for pushing complexity into the engine.  Of course, we =
shouldn't forget that task writers are users as well.  Whatever we come =
up with needs to be easy to write antlibs against.


> How about we try enhancing the extension / classloader system so=20
> that we can=20
> have multi-parent classloaders (assuming disjoint class sets).=20
> The we try and=20
> build an appropriate dependency tree for each library dependency=20
> tree. if we=20
> detect conflicts (ie dependency 1 uses X lib in classloader A while=20
> dependency 2 uses X lib in classloader B) then we throw an=20
> exception and hope=20
> things work out for the best ;)
>=20

I just checked in a bunch of changes to do this.  Let's see how it goes =
...


> > We can do this to some degree by fixing up the handling of =
extensions
> > (resolving them for jars in lib/, fixing up the classloaders,=20
> and so on).=20
> > I'm not sure how this will go long term.  In particular, what=20
> would be nice
> > is if an antlib writer could distribute a single .atl file,=20
> rather than a
> > .jar that has to get installed in ${myrmidon.home}/lib, one=20
> that has to get
> > installed in ${myrmidon.home}/ext, and an .atl that has to get=20
> installed in
> > the antlib search path somewhere.
>=20
> Yer. needs redoing. I need to redo it in phoenix aswell and may=20
> try tackling=20
> them both at the same time. Then again I am not sure when I can=20
> get to it.=20
> For the time being my main aim is breaking down the build system and=20
> documentation.=20
>=20

Any thoughts on how it might be redone?

One simple option I was toying with, was to add a 'final' attribute to =
the antlib descriptor.  Antlibs that are declared final cannot be used =
by other antlibs.  Non-final antlibs would be made available as =
extensions that can be used by other antlibs.

This would (kinda) handle the main antipattern we're trying to solve, =
which is where the classes in an antlib are used directly, where they =
weren't intended to be by the antlib writer.


Adam


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