There doesn't need to be only two choices. Am I the only one who prefers independently releaseable modules? Since the primary use case is for Tapestry, I'd bring it in, but as it's own sub-project and have it follow a separate release cycle. You could ask what's the point of bringing it in then, but the answer is the same as for any other Apache project that started its life elsewhere, but wanted to become an Apache project.
Kalle On Mon, Mar 28, 2011 at 12:58 PM, Thiago H. de Paula Figueiredo <[email protected]> wrote: > On Mon, 28 Mar 2011 16:29:55 -0300, Igor Drobiazko > <[email protected]> wrote: > >> Thiago, the main use case (and probably the only one for a quite long >> time) for plastic is Tapestry. Having plastic as a tapestry module has an >> big >> advantage when coding and improving Tapestry's features. I believe we >> should concentrate on this in the first place. >> A lot of people are using tapestry-ioc without tapestry-core. Same will >> apply for plastic. > > When I said "integrate", I meant option 2, Plastic classes being inside > tapestry-core or tapestry-ioc. ;) As Howard said about Tapestry-IoC having > this name, I don't think ignoring the use of Plastic outside Tapestry to be > a good idea. If you have good code, people will always find creative, > unpredicted ways of using it. Plastic is standalone now, so should it > remain, outside Tapestry's SVN or not. > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and > instructor > Owner, Ars Machina Tecnologia da Informação Ltda. > http://www.arsmachina.com.br > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
