Well, it isn't really specific to Struts in anyway, and we wrote it because there wasn't anything else to do the job (xdoclet needed to be patched If I remember right). At the end is not big deal, it is just 4 classes anyway :)
musachy On 3/12/07, Martin Cooper <[EMAIL PROTECTED]> wrote:
On 3/12/07, Musachy Barroso <[EMAIL PROTECTED]> wrote: > > What I really wish is that there was some external project doing > this(which > is supposed to be a fairly common task) so we wouldn't have to maintain > it, > but if we are going to keep it, I'd rather have it as part of the > distribution. Why would you want to convert something that's part of, and a dependency of, an ASF project into something that's potentially outwith our control? -- Martin Cooper musachy > > On 3/12/07, James Mitchell <[EMAIL PROTECTED]> wrote: > > > > I'd prefer that it be part of the distribution. Having it separate > > just seems to add complexity to the build and I'm sure to the release > > process. > > > > Just my 2 cents. > > > > > > -- > > James Mitchell > > > > > > > > > > On Mar 12, 2007, at 9:05 AM, Ted Husted wrote: > > > > > Under the Apache License, anyone who wanted to do that would be free > > > to do so. It's just a matter of changing the product name, and > > > following the other provisions of the license. > > > > > > But, that doesn't solve the problem, it just changes the venue. If > > > there's anyone who is ready, willing, and able to run Annotations as a > > > GoogleCode project, AFAIC, they would also be welcome to help maintain > > > Annotations as a Struts subproject. It's not about venue, it's about > > > volunteers. > > > > > > The problem is that no one is doing the work of making Annotations > > > reusable. It is not documented as a separate entity, no one is > > > releasing it, or announcing it, or otherwise promoting it. Some of our > > > own committers don't even know it exists. > > > > > > If someone wants to be the Struts Annotations release manager, now is > > > the time to step up. Otherwise, we should declare it an orphan and > > > make the JAR part of the general distribution. > > > > > > -Ted. > > > > > > On 3/12/07, Musachy Barroso <[EMAIL PROTECTED]> wrote: > > >> After the changes I just added, I don't think annotations will > > >> change much > > >> from now on, if any. We could set it up somewhere else > > >> (googlecode?) and > > >> avoid both the subproject and the multiple release problems. > > >> > > >> musachy > > >> > > >> On 3/12/07, Martin Cooper <[EMAIL PROTECTED]> wrote: > > >> > > > >> > On 3/11/07, Ted Husted <[EMAIL PROTECTED]> wrote: > > >> > > > > >> > > Annotations was originally setup as a separate JAR with an > > >> independent > > >> > > version so as to encourage reuse. However, until other product > > >> > > indicate an interest in using Annotaitons and participating in > > >> its > > >> > > development, managing a separate release process provides no > > >> tangible > > >> > > benefit. > > >> > > > >> > > > >> > It provides the tangible benefit of actually allowing for reuse... > > >> > > > >> > Therefore, it's proposed that annotations become a part of > > >> > > the general Struts 2 distribution, along with the various > > >> plugins, but > > >> > > remain in its own JAR, so as to encourage reuse. If an > > >> independent > > >> > > community forms around Annotations, we can revisit the issue > > >> of making > > >> > > it a subproject with its own release cycle. > > >> > > > >> > > > >> > An independent community is simply not going to form around > > >> something > > >> > that's > > >> > buried inside of Struts. We've already seen that in the past. I > > >> know this > > >> > is > > >> > a bit of a Catch 22 situation, but unless we actually allow for > > >> reuse in > > >> > the > > >> > first place, as we do today, there is very little chance that it > > >> will ever > > >> > be reused. Therefore I would prefer to see the annotations stay > > >> separate. > > >> > > > >> > -- > > >> > Martin Cooper > > >> > > > >> > > > >> > Archetype was original setup as a separate entity, but it might be > > >> > > simpler to reduce the number of independent artifacts being > > >> released > > >> > > by the project. The S2 Release Manager will have to update the > > >> version > > >> > > number in the templates, but that seems like less work that > > >> > > coordinating tandem releases, that might end up being handled > > >> by the > > >> > > same volunteer anyway. > > >> > > > > >> > > Again, this is as to the trunk. For now, we can let the 2.0 > > >> branch > > >> > > stay as it is. > > >> > > > > >> > > Further thoughts? > > >> > > > > >> > > -Ted. > > >> > > > > >> > > > > >> --------------------------------------------------------------------- > > >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> > > For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> -- > > >> "Hey you! Would you help me to carry the stone?" Pink Floyd > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd >
-- "Hey you! Would you help me to carry the stone?" Pink Floyd
