struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Musachy Barroso" <musa...@gmail.com>
Subject Re: [S2] [2.1.x] Bundled Plugins
Date Tue, 21 Aug 2007 16:20:42 GMT
"Write access and being a committer are the same thing. So, no. :("


On 8/21/07, Paul Benedict <pbenedict@apache.org> wrote:
> I seem to have lost that email. What was Ted's reason?
>
> On 8/21/07, Musachy Barroso <musachy@gmail.com> wrote:
> >
> > Yeah that's what I thought, per Ted's comments we can't do that.
> > Having independent releases for the plugins would be another boost.
> >
> > musachy
> >
> > On 8/21/07, Paul Benedict <pbenedict@apache.org> wrote:
> > > What's the traction on having S2 plugin-only committers? I am referring
> > to a
> > > previous email from Antonio. Just like people sign CLA to write
> > > documentation, I think our plugin development would have a major boost
> > if we
> > > could have plugin-only committers too.
> > >
> > > Paul
> > >
> > > On 8/21/07, Nils-Helge Garli <nilsga@gmail.com> wrote:
> > > >
> > > > I guess that's a question of definition, viewed in a historical
> > > > perspective ;) But I do intend to keep actively maintaining it, and a
> > > > few more people maintaining it would be very welcome!
> > > >
> > > > Nils-H
> > > >
> > > > On 8/21/07, James Holmes <james@jamesholmes.com> wrote:
> > > > > +1 for keeping the Portlet plugin in the core Struts 2 distribution
> > and
> > > > project. Nils-H is actively maintaining it and I am
> > > > > interested in maintaining it as well.
> > > > >
> > > > > James
> > > > >
> > > > >
> > > > > On Tue Aug 21  1:43 , 'Nils-Helge Garli' <nilsga@gmail.com>
sent:
> > > > >
> > > > > >I couldn't fint the portlet plugin mentioned on the list of plugins
> > > > > >for the different tiers. Where does it fit in?
> > > > > >
> > > > > >As a plugin developer, I would definetively see it as a motivation
> > > > > >having the "Struts 2" brand on the plugin.
> > > > > >
> > > > > >Nils-H
> > > > > >
> > > > > >On 8/20/07, Don Brown mrdon@twdata.org> wrote:
> > > > > >> Makes sense to me.   Would we bundle the second-tier plugins
in
> > our
> > > > > >> release or just the first tier?  Would second-tier plugins
each
> > get
> > > > > >> their own release cycle, share one together, or be linked
to the
> > main
> > > > > >> Struts 2 release cycle?
> > > > > >>
> > > > > >> Don
> > > > > >>
> > > > > >> On 8/20/07, Paul Benedict pbenedict@apache.org> wrote:
> > > > > >> > Hi all.
> > > > > >> >
> > > > > >> > I think the Spring framework has a great model for
this kind of
> > > > problem.
> > > > > >> > They call it the "Spring portfolio" which is the Spring
> > Framework
> > > > (proper)
> > > > > >> > and then subprojects for very special criteria (security,
web
> > > > services,
> > > > > >> > etc.). We all know Spring is pretty good at integrating
> > > > technologies, but
> > > > > >> > not every technology has the "weight" to get first
tier
> > support.
> > > > When it is
> > > > > >> > lesser, they get maintained in the "Spring Modules"
project.
> > > > > >> >
> > > > > >> > I think we could do the same thing here. Struts 2 could
include
> > > > only
> > > > > >> > first-tier plugins that actually are part of the Struts
> > release,
> > > > but then
> > > > > >> > have another Struts subproject that maintains other
plugins.
> > > > > >> >
> > > > > >> > In case someone may bring up Shale and the old "umbrella"
> > framework
> > > > > >> > argument, I think my proposal is quite different. I
am not
> > > > proposing
> > > > > >> > different frameworks and communities, but simply creating
> > another
> > > > Maven
> > > > > >> > project under Struts for Struts plugins.
> > > > > >> >
> > > > > >> > Paul
> > > > > >> >
> > > > > >> > On 8/19/07, Frank W. Zammetti fzlists@omnytex.com>
wrote:
> > > > > >> > >
> > > > > >> > > Martin Cooper wrote:
> > > > > >> > > > Perhaps. Perhaps not. But it's pretty much
guaranteed that
> > we
> > > > would
> > > > > >> > > lower
> > > > > >> > > > the base of people who _could_ use them if
they're not
> > here.
> > > > Some
> > > > > >> > > companies
> > > > > >> > > > (my current employer included) require approval
for each
> > and
> > > > every open
> > > > > >> > > > source component before it can be used within
the company.
> > > > > >> > >
> > > > > >> > > FYI, I'm in the same boat where I am, and I know
the hassles
> > we
> > > > go
> > > > > >> > > through sometimes to get various
> > libraries/components/whatever
> > > > approved,
> > > > > >> > > so I definitely know where your coming from with
this
> > point.  In
> > > > talking
> > > > > >> > > to other folks, this doesn't seem to be unusual
at all.
> > > > > >> > >
> > > > > >> > > > I disagree. I think it is just fine to distribute
such
> > code. If
> > > > people
> > > > > >> > > start
> > > > > >> > > > to use it and have problems with it, then
perhaps this will
> > > > drive
> > > > > >> > > additional
> > > > > >> > > > contributors to it. Gaining additional contributors
to it
> > as
> > > > part of
> > > > > >> > > Struts
> > > > > >> > > > seems much more likely to me than if it's
off in the weeds
> > > > somewhere.
> > > > > >> > >
> > > > > >> > > You mentioned the "...respected source such as
the ASF" in
> > the
> > > > previous
> > > > > >> > > paragraph, and I certainly agree.  I think however
that if
> > the
> > > > approach
> > > > > >> > > was as you say, that potentially untested code,
or more
> > > > accurately code
> > > > > >> > > not used to a great extent by active committers,
which I
> > believe
> > > > is what
> > > > > >> > > Ted was talking about, was coming out of a respected
ASF
> > project,
> > > > it's
> > > > > >> > > not hard to imagine that respect declining when
a lot of bug
> > > > reports are
> > > > > >> > > opened for a particular plugin.  One plugin could
wind up
> > ruining
> > > > the
> > > > > >> > > good reputation of the larger project.
> > > > > >> > >
> > > > > >> > > And if no one was maintaining and using that code
to begin
> > with,
> > > > I think
> > > > > >> > > it's a bit of a gamble to hope someone will be
spurred into
> > > > action by
> > > > > >> > > some negative feedback.  Maybe someone will be,
but I don't
> > think
> > > > that's
> > > > > >> > > a risk worth taking if you want to keep a good
reputation and
> > > > keep being
> > > > > >> > > a respected project :)
> > > > > >> > >
> > > > > >> > > I for one see Ted's suggestion as a good compromise...
you
> > could
> > > > almost
> > > > > >> > > in a sense view the external location, wherever
that happens
> > to
> > > > be, as
> > > > > >> > > something of a plugin incubator... assure the
code has a
> > > > community of
> > > > > >> > > developers willing to maintain it and ensure it's
at a level
> > of
> > > > quality
> > > > > >> > > that fits in with the rest of the S2 distro proper,
and
> > *then*
> > > > roll it
> > > > > >> > > in to the distro later.  For any plugin that there's
any
> > doubt
> > > > about
> > > > > >> > > today (and I don't know which those are), they
can be shifted
> > > > there and
> > > > > >> > > allowed to grow that community.  And if some never
do, it's
> > not
> > > > the end
> > > > > >> > > of the world: they're still there for anyone that
wants them.
> > > > > >> > >
> > > > > >> > > To address the concern you raised about approvals,
I think it
> > > > would be
> > > > > >> > > important to make the external location an endorsed
source of
> > > > plugins.
> > > > > >> > > Maybe it makes more sense to have a plugins subproject
under
> > > > Struts, I
> > > > > >> > > don't know, but whatever the case, so long as
people
> > understood
> > > > that
> > > > > >> > > yes, this plugin repository/incubator/whatever
was *the*
> > approved
> > > > place
> > > > > >> > > to get plugins from, I believe the approval process
would be
> > > > eased a bit
> > > > > >> > > for most users in that same situation as we are.
> > > > > >> > >
> > > > > >> > > At the end of the day, it's always said that an
ASF project
> > > > depends on
> > > > > >> > > developers who themselves are using the code.
 It's supposed
> > to
> > > > be code
> > > > > >> > > for themselves that they happen to share with
others, that's
> > how
> > > > I've
> > > > > >> > > come to understand the underlying concept anyway.
 If that's
> > > > true, then
> > > > > >> > > it seems like keeping code in S2 that might not
be maintained
> > and
> > > > > >> > > actually used by active commutters is a contradiction
of
> > that,
> > > > and Ted's
> > > > > >> > > suggestion offers a viable alternative that keeps
the code
> > alive,
> > > > and in
> > > > > >> > > fact presents (possibly) a better chance for it
to succeed.
> > > > > >> > >
> > > > > >> > > > --
> > > > > >> > > > Martin Cooper
> > > > > >> > >
> > > > > >> > > Frank
> > > > > >> > >
> > > > > >> > > --
> > > > > >> > > Frank W. Zammetti
> > > > > >> > > Founder and Chief Software Architect
> > > > > >> > > Omnytex Technologies
> > > > > >> > > http://www.omnytex.com
> > > > > >> > > AIM/Yahoo: fzammetti
> > > > > >> > > MSN: fzammetti@hotmail.com
> > > > > >> > > Author of "Practical Ajax Projects With Java Technology"
> > > > > >> > >   (2006, Apress, ISBN 1-59059-695-1)
> > > > > >> > > and "JavaScript, DOM Scripting and Ajax Projects"
> > > > > >> > >   (2007, Apress, ISBN 1-59059-816-4)
> > > > > >> > > Java Web Parts - http://javawebparts.sourceforge.net
> > > > > >> > >   Supplying the wheel, so you don't have to reinvent
it!
> > > > > >> > >
> > > > > >> > >
> > > > ---------------------------------------------------------------------
> > > > > >> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > > >> > > For additional commands, e-mail: dev-help@struts.apache.org
> > > > > >> > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >>
> > ---------------------------------------------------------------------
> > > > > >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > > >> For additional commands, e-mail: dev-help@struts.apache.org
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > >---------------------------------------------------------------------
> > > > > >To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > > >For additional commands, e-mail: dev-help@struts.apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > "Hey you! Would you help me to carry the stone?" Pink Floyd
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>


-- 
"Hey you! Would you help me to carry the stone?" Pink Floyd

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message