struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Don Brown" <mr...@twdata.org>
Subject Re: [PROPOSAL] Merge Annotations and Archetype into the trunk for the 2.1.x series (was struts-annotations)
Date Thu, 15 Mar 2007 06:03:33 GMT
To clarify, are we talking about moving the annotations project under the
struts2/trunk directory or integrating the Java and APT code into core?  If
the former, I'm all for it, if the latter, I vote against it as I'd like to
keep core as focused as possible.

Don

On 3/14/07, Rene Gielen <gielen@it-neering.net> wrote:
>
> Basically I'm convinced that annotations is an independent project in
> theory, but currently we have only two realistic usecases:
>
> 1) build s2 distribution
> 2) let users of s2 extend /customize existing s2 tags or add custom tags
> in their own projects
>
> Both usecases can be served with annotations integrated in s2 codebase,
> so if this is easier to maintain, why not.
>
> For the second usecase, we should think of improving documentation to
> help users build their own tags. If we integrate annotations in the s2
> codebase, we should add annotations/tag development documentation to s2
> docs.
>
> After all, here's my
> +1 for integrating annotations in s2 codebase
>
> - Rene
>
> Don Brown wrote:
> > Yeah, while I know there are good reasons to keep annotations and the
> > archetypes outside the struts 2 codebase, from a pragmatic standpoint,
> I'd
> > also like to bring them back in.  Sure, the annotations could be useful
> for
> > other projects, but until anyone signs up to do to the work, I just
> don't
> > see it getting anywhere.  As for the archetypes, every time I question
> > this,
> > Wendy has a list of good reasons we need to keep them outside Struts,
> but
> > still, Maven 2 issues aside, I think they would be better served in
> Struts
> > 2, tagged and released with everything else.
> >
> > However, things aren't _that_ bad the way they are, so consider my vote
> > a +0
> > :)
> >
> > Don
> >
> > On 3/12/07, James Mitchell <james.l.mitchell@mac.com> 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 <musachy@gmail.com> 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 <martinc@apache.org> wrote:
> >> >> >
> >> >> > On 3/11/07, Ted Husted <husted@apache.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message