Re: Shale - Release
On 6/22/07, Rahul Akolkar [EMAIL PROTECTED] wrote: SCENARIO A: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.1, seeded from current trunk 1.2.x -- JSF 1.2 SCENARIO B: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.2, seeded from current trunk I'd be happy with either of the above, perhaps some preference for A. It depends on the workload involved with upgrading to the 1.2 spec. If the load is heavy, A would be better. If it's lighter, B would be better. I wonder how many people are still using 1.1. We are currently still bound to it, but could upgrade without too much work, and probably will as soon as MyFaces 1.2 is released. Greg
Re: Shale - Release
I like A. I would prefer version 2.0 for JSF 1.2 because it allows more version flexibilty for the JSF 1.1. I am partial to a major release.minor release.maintaince release model where their is upward API compatibility within a major release, 1.1 to 1.2. Paul Spencer Rahul Akolkar wrote: On 6/22/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Greg Reddin [EMAIL PROTECTED] On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Matthias Wessendorf wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? For the most part, the trunk and 1_0_x branch are the same. I can only think of one commit that was not made to the both. I'd like to see us move the trunk to JSF 1.2 and then we could mix in the annotations as part of the base libraries. snip/ shale-dialog has considerable deltas (the helper class, some new listener methods etc. -- many @since 1.1.0 tags if you dig into the code). This was under the understanding that no new features went into the 1.0.x line after v1.0.4. If we want to move trunk to JSF 1.2, that should either happen at v1.1.0 or should wait for the next line of development (v1.2.0) IMO. Depending on JSF versions and when currently unreleased new features frum trunk get released, here are the potential release scenarios: SCENARIO A: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.1, seeded from current trunk 1.2.x -- JSF 1.2 SCENARIO B: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.2, seeded from current trunk SCENARIO C: 1.0.x -- JSF 1.1, merge current deltas (mostly dialog new features) from trunk in 1.0.x line 1.1.x -- JSF 1.2, seeded from current trunk Preferences? -Rahul
Re: Shale - Release
From: Craig McClanahan [EMAIL PROTECTED] Sorry for the late response ... still catching up from a backlog due to being on the road for most of May. Comments below. On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Gary VanMatre wrote: From: Greg Reddin On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Matthias Wessendorf wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? For the most part, the trunk and 1_0_x branch are the same. I can only think of one commit that was not made to the both. I'd like to see us move the trunk to JSF 1.2 and then we could mix in the annotations as part of the base libraries. shale-dialog has considerable deltas (the helper class, some new listener methods etc. -- many @since 1.1.0 tags if you dig into the code). This was under the understanding that no new features went into the 1.0.x line after v1.0.4. If we want to move trunk to JSF 1.2, that should either happen at v1.1.0 or should wait for the next line of development (v1.2.0) IMO. Depending on JSF versions and when currently unreleased new features frum trunk get released, here are the potential release scenarios: SCENARIO A: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.1, seeded from current trunk 1.2.x -- JSF 1.2 SCENARIO B: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.2, seeded from current trunk SCENARIO C: 1.0.x -- JSF 1.1, merge current deltas (mostly dialog new features) from trunk in 1.0.x line 1.1.x -- JSF 1.2, seeded from current trunk Preferences? My personal preference would be for scenario A over scenario B or C, but with a twist ... target the JSF 1.2 based stuff for a 2.x release series, rather than 1.1 or 1.2. Why? Because a redesign of the existing APIs to take JSF 1.2 into account (and therefore also become dependent on Java SE 5) is very likely to require some significant changes (just as one example, much of tiger basically goes away and becomes part of the core functionality in view and other places), so upping the major version number would be more appropriate. I'd like also like to see the annotation processor moved to the core with a pluggable way to register handlers. It seems silly to scan the classpath multiple times for each library that might have future annotations. Maybe a commons chain would be a good way to register annotation handlers? Version numbers aside, I would prefer A over B. We need to put out a new release anyway; the ease of use additions in the current trunk are modest but nice, and if we focused on just finishing 1.1 we might actually get a release out this year :-). +1 I don't like C -- we still want to have the *ability* to go back and do a 1.0.5 if some security problem or something rears its head; in the mean time, lets just get 1.1 done and out the door while we start talking about what the future might hold. And that starts from us (yes, me included :-) rolling up our sleeves and addressing the current issues in the trunk code -- and *perhaps* backporting bugfixes to the 1.0 branch, but that needn't be a priority. -Rahul Craig Gary
Re: Shale - Release
On 6/25/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Craig McClanahan [EMAIL PROTECTED] Sorry for the late response ... still catching up from a backlog due to being on the road for most of May. Comments below. On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Gary VanMatre wrote: From: Greg Reddin On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Matthias Wessendorf wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? For the most part, the trunk and 1_0_x branch are the same. I can only think of one commit that was not made to the both. I'd like to see us move the trunk to JSF 1.2 and then we could mix in the annotations as part of the base libraries. shale-dialog has considerable deltas (the helper class, some new listener methods etc. -- many @since 1.1.0 tags if you dig into the code). This was under the understanding that no new features went into the 1.0.x line after v1.0.4. If we want to move trunk to JSF 1.2, that should either happen at v1.1.0 or should wait for the next line of development (v1.2.0) IMO. Depending on JSF versions and when currently unreleased new features frum trunk get released, here are the potential release scenarios: SCENARIO A: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.1, seeded from current trunk 1.2.x -- JSF 1.2 SCENARIO B: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.2, seeded from current trunk SCENARIO C: 1.0.x -- JSF 1.1, merge current deltas (mostly dialog new features) from trunk in 1.0.x line 1.1.x -- JSF 1.2, seeded from current trunk Preferences? My personal preference would be for scenario A over scenario B or C, but with a twist ... target the JSF 1.2 based stuff for a 2.x release series, rather than 1.1 or 1.2. Why? Because a redesign of the existing APIs to take JSF 1.2 into account (and therefore also become dependent on Java SE 5) is very likely to require some significant changes (just as one example, much of tiger basically goes away and becomes part of the core functionality in view and other places), so upping the major version number would be more appropriate. I'd like also like to see the annotation processor moved to the core with a pluggable way to register handlers. It seems silly to scan the classpath multiple times for each library that might have future annotations. Maybe a commons chain would be a good way to register annotation handlers? Silly it may be, the alternative seems to be everyone agreeing to use a common low level library to abstract away the very real differences between what kinds of annotations different projects would look for. That should work about as successfully as Commons Logging has :-). More seriously: * What is really important is a way to scan for runtime annotations that does not require loading all the classes in a way that runs all the static initializers. * It turns out that there is such a scheme to look at ... the Class.forName() variant of class loading (at least; hopefully there are others as well so you can do the discovery from a parent class loader) that does exactly this. Thanks to Bob Lee of Google for a pointer to look at this (which is the mechanism Google Guice uses). Craig
Fwd: Shale - Release
hi, are there any plans for 1.1.0 release ? -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
Re: Shale - Release
On 6/22/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 6/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? Agreed. I've been meaning (for months) to update the Tiles support and haven't gotten around to it. I'll try to make that a priority. Greg
Re: Shale - Release
From: Greg Reddin [EMAIL PROTECTED] On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Matthias Wessendorf wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? For the most part, the trunk and 1_0_x branch are the same. I can only think of one commit that was not made to the both. I'd like to see us move the trunk to JSF 1.2 and then we could mix in the annotations as part of the base libraries. Agreed. I've been meaning (for months) to update the Tiles support and haven't gotten around to it. I'll try to make that a priority. That would be good and a Tiles usecase would also be helpful. I think there is a few bug we need to fix in the view controller before the next release. Greg Gary
Re: Shale - Release
On 6/22/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Greg Reddin [EMAIL PROTECTED] On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Matthias Wessendorf wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? For the most part, the trunk and 1_0_x branch are the same. I can only think of one commit that was not made to the both. I'd like to see us move the trunk to JSF 1.2 and then we could mix in the annotations as part of the base libraries. snip/ shale-dialog has considerable deltas (the helper class, some new listener methods etc. -- many @since 1.1.0 tags if you dig into the code). This was under the understanding that no new features went into the 1.0.x line after v1.0.4. If we want to move trunk to JSF 1.2, that should either happen at v1.1.0 or should wait for the next line of development (v1.2.0) IMO. Depending on JSF versions and when currently unreleased new features frum trunk get released, here are the potential release scenarios: SCENARIO A: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.1, seeded from current trunk 1.2.x -- JSF 1.2 SCENARIO B: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.2, seeded from current trunk SCENARIO C: 1.0.x -- JSF 1.1, merge current deltas (mostly dialog new features) from trunk in 1.0.x line 1.1.x -- JSF 1.2, seeded from current trunk Preferences? -Rahul
Re: Shale - Release
From: Rahul Akolkar [EMAIL PROTECTED] On 6/22/07, Gary VanMatre wrote: From: Greg Reddin On 6/22/07, Rahul Akolkar wrote: On 6/22/07, Matthias Wessendorf wrote: hi, are there any plans for 1.1.0 release ? As an aside, IMO its worthwhile to have a v1.0.5 as well so we can attempt to go GA in the 1.0.x line. Opinions? For the most part, the trunk and 1_0_x branch are the same. I can only think of one commit that was not made to the both. I'd like to see us move the trunk to JSF 1.2 and then we could mix in the annotations as part of the base libraries. shale-dialog has considerable deltas (the helper class, some new listener methods etc. -- many @since 1.1.0 tags if you dig into the code). This was under the understanding that no new features went into the 1.0.x line after v1.0.4. If we want to move trunk to JSF 1.2, that should either happen at v1.1.0 or should wait for the next line of development (v1.2.0) IMO. Depending on JSF versions and when currently unreleased new features frum trunk get released, here are the potential release scenarios: SCENARIO A: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.1, seeded from current trunk 1.2.x -- JSF 1.2 SCENARIO B: 1.0.x -- JSF 1.1, no new features beyond v1.0.4 1.1.x -- JSF 1.2, seeded from current trunk SCENARIO C: 1.0.x -- JSF 1.1, merge current deltas (mostly dialog new features) from trunk in 1.0.x line 1.1.x -- JSF 1.2, seeded from current trunk Preferences? I can see how A would provide a good match to JSF but the question is how many new features do we want to target at JSF 1.1 when 1.2 is the new frontier. I'd rather target the trunk at JSF 1.2/ JDK 1.5 so the trunk is always the latest. -Rahul Gary
