I would definitely prefer the option 2). It is much easier to fix something
inside Tapestry if plastic is built-in rather than waiting for a fix release
of Plastic. Best examples are HiveMind and OGNL. I remember the nightmare as
Tapestry user, when I was using Tapestry snapshots which depended on OGNL
snapshots.

If Plastic should become successful, we can it out to be useful for other
projects. But for now it is much easier to have everything in your own tool
belt.

It would be great if we could have the 5.3 release in summer. Let's say June
or July.

On Mon, Mar 28, 2011 at 7:22 PM, Howard Lewis Ship <[email protected]> wrote:

> I've been having a lot of fun working on plastic
> (https://github.com/hlship/plastic) ... I've been crafting it on
> GitHub, learning a lot, and targetting it as a replacement for both
> ClassFactory and the
> ComponentInstantiatorSource/ComponentClassTransformer pipeline.
>
> I'm starting to think about reworking tapestry-ioc and tapestry-core
> to make use of Plastic.
>
> ClassFactory will be deprecated, to be removed in a later release
> (probably 5.5).
>
> I've already extended tapestry-ioc to support contributions that can
> be coerced.  My intent for that was to allow existing code that
> contributes to ComponentClassTransformWorker to stay the same
> (operating through a wrapper layer that emulates the
> ClassTransformation API on top of Plastic) ... and allow contributions
> to a new API (ComponentClassTransformWorker2, perhaps) that explicitly
> binds to Plastic.
>
> In terms of a dependency on Plastic, there's two directions we can go in:
>
> 1) Keep Plastic separate; give it a non-snapshot version number and a
> non-snapshot repository.
>
> 2) Import Plastic into Tapestry: rename the packages and integrate
> into the overall build.
>
> I'm ok with either approach but I need to make a decision soon.
>
> For me, Tapestry 5.3 will be sufficient if it includes the changes
> I've already made and starts the transition away from Javassist, the
> rest of the minimization support, plus a few new components (imported
> from TapX). My current thinking is to get a 5.3 out pretty soon, and
> work on revising JavaScript in Tapestry as 5.4, and maybe get a stable
> beta of that out before the end of the year.
>
> I think we should work to get a new release out pretty soon ... with
> Igor's book coming out in a few months, and the new web site, a
> reasonably meaty, and TIMELY, release will help with any questions
> about the viability of Tapestry.  More frequent releases that are less
> ambitious is a good pattern, one that's already been discussed here
> (and yet, there's the strong temptation ... I feel it in myself ... to
> always throw in some really significant enhancements).
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>


-- 
Best regards,

Igor Drobiazko
http://tapestry5.de

Reply via email to