On Mon, Mar 28, 2011 at 2:11 PM, Howard Lewis Ship <[email protected]> wrote: > On Mon, Mar 28, 2011 at 2:04 PM, Kalle Korhonen > <[email protected]> wrote: >> 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. > In terms of another high level project under the Tapestry umbrella ... > I'd be for that if the "cost" of releasing new versions wasn't so > high. Having to make a change to plastic, then run through a > vote/release cycle, so that the change could be picked up (as a > non-snapshot version number) in tapestry-core seems unwieldy. Outside > Apache, you can Just Do It, but it would not be the Apache Way.
That is true. I would hate it though if we couldn't do it just because of bureaucracy. At the same time, Apache communities are supposed to be semi-autonomous, so I wonder if we really have the power to do it if we so decide. If we claim it as a separately versioned component to Tapestry, announce plastic versions and its source releases with main Tapestry releases, I wonder if we could "just do it" and get away with it. All devs would still have their say about plastic at the time the main release is being voted. Apache Extras is another way, but we loose some of the prestige of Apache and the dependencies "flow to wrong direction". I don't see it as being considerably better than github. > Keeping it under the Tapestry project means that it will have a > version number that tracks the other related projects that depend on > it, and they can transition from snapshot to release together. Absolutely. But at least Maven excels in version management and I always feel there's so much waste in multi-module builds when you are needlessly building/releasing the whole thing just because you made a tiny change in one sub-module. 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] >> >> > > > > -- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
