You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2007/08/19 14:56:06 UTC
[S2] [2.1.x] Bundled Plugins (was Re: Ajax Theme)
On 8/18/07, Musachy Barroso <mu...@gmail.com> wrote:
> do you mean to move the plugin out of Struts? Because Dojo is already
> on its own plugin in trunk.
My question was whether we wanted to keep Dojo as part of the project,
or move it GoogleCode, along with the YUI plugin. I think some of the
other questions misunderstood where we already are, in that for 2.1.x
Dojo is one of our bundled plugins, like Spring and JasperReports.
Right now the bundled plugin list for 2.1.x is
* codebehind
* config-browser
* dojo
* jasperreports
* jfreechart
* jsf
* pell-multichart
* plexus
* spring
* struts1
* tiles
The underlying question is whether we have active committers who
actually *want* to maintain all of these plugins as part of the trunk.
Initially, we dragged most of these along because there were part of
WebWork and 2.0 was the backward-compatibility series. Moving forward,
we might want to be more careful about the plugins that we bundle. One
idea would be to create a Struts Plugin project somewhere, where
third-party plugins could be maintained jointly.
My suggestion would be to retain
* codebehind
* config-browser
* jsf
* struts1
* tiles
and add (with the permission of the owners)
* JSON Plugin
* Table Tags
* Smart URLs
And then encourage the remainder be adopted by an independant open
source project (while we keep a snapshot of what we have now in the
Archive).
* dojo
* jasperreports
* jfreechart
* pell-multichart
* plexus
* spring
Ideally, some of the other plugin projects might merge into the
independant Struts Plugin project, making it easier for people to gain
access later if the original author drifts awqay.
Thoughts?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [S2] [2.1.x] Bundled Plugins
Posted by Martin Cooper <ma...@apache.org>.
On 8/19/07, Don Brown <mr...@twdata.org> wrote:
>
> Agreed, Spring should be a first-tier plugin. I'm fine with spinning
> off the others, but who would maintain them? If it will be the same
> people, then perhaps we should keep them in the repository.
Perhaps I'm missing something here, but how would spinning out plugins fit
with the original intent to have Struts 2.x be a more unified framework,
with less of a need for accretion of scattered pieces to get what you need
to build an application? It seems to me that the more we spin out, and the
more places we spin out to, the more we're back to one of the main problems
we wanted to solve with Struts 2.
--
Martin Cooper
How does Maven handle this situation? Wendy?
>
> Don
>
> On 8/20/07, Tom Schneider <sc...@gmail.com> wrote:
> > I disagree with moving the Spring plugin outside of the core set of
> > plugins. I think a lot of people use Spring and it would be a shame to
> > not have it as a core feature. Keep in mind that I think we run a huge
> > risk (IMO) of plugins being unmaintained if we set them free, however,
> > I'm more than happy to do it for the more fringe plugins that not a lot
> > of people use. I also think the JSF plugin is more of a fringe
> > plugin--I'd be curious to know how many people are actually using it in
> > production.
> >
> > There has been no interest whatsoever of anyone helping out on table
> > tags. I knew I wouldn't have the time to work on it after I initially
> > created it, but I was hoping other developers would take interest. That
> > hasn't happened. (I may get some time if we upgrade to struts 2 at
> > work) If we want to integrate it into core, we need developers to
> > really run with it and make it real. Right now it isn't production
> > ready--I just haven't spent enough time with it.
> >
> > Everything else in your list looks good to me.
> > Tom
> >
> > Ted Husted wrote:
> > > On 8/18/07, Musachy Barroso <mu...@gmail.com> wrote:
> > >
> > >> do you mean to move the plugin out of Struts? Because Dojo is already
> > >> on its own plugin in trunk.
> > >>
> > >
> > > My question was whether we wanted to keep Dojo as part of the project,
> > > or move it GoogleCode, along with the YUI plugin. I think some of the
> > > other questions misunderstood where we already are, in that for 2.1.x
> > > Dojo is one of our bundled plugins, like Spring and JasperReports.
> > > Right now the bundled plugin list for 2.1.x is
> > >
> > > * codebehind
> > > * config-browser
> > > * dojo
> > > * jasperreports
> > > * jfreechart
> > > * jsf
> > > * pell-multichart
> > > * plexus
> > > * spring
> > > * struts1
> > > * tiles
> > >
> > > The underlying question is whether we have active committers who
> > > actually *want* to maintain all of these plugins as part of the trunk.
> > >
> > > Initially, we dragged most of these along because there were part of
> > > WebWork and 2.0 was the backward-compatibility series. Moving forward,
> > > we might want to be more careful about the plugins that we bundle. One
> > > idea would be to create a Struts Plugin project somewhere, where
> > > third-party plugins could be maintained jointly.
> > >
> > > My suggestion would be to retain
> > >
> > > * codebehind
> > > * config-browser
> > > * jsf
> > > * struts1
> > > * tiles
> > >
> > > and add (with the permission of the owners)
> > >
> > > * JSON Plugin
> > > * Table Tags
> > > * Smart URLs
> > >
> > > And then encourage the remainder be adopted by an independant open
> > > source project (while we keep a snapshot of what we have now in the
> > > Archive).
> > >
> > > * dojo
> > > * jasperreports
> > > * jfreechart
> > > * pell-multichart
> > > * plexus
> > > * spring
> > >
> > > Ideally, some of the other plugin projects might merge into the
> > > independant Struts Plugin project, making it easier for people to gain
> > > access later if the original author drifts awqay.
> > >
> > > Thoughts?
> > >
> > > -Ted.
> > >
> > > ---------------------------------------------------------------------
> > > 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
>
>
Re: [S2] [2.1.x] Bundled Plugins
Posted by Wendy Smoak <ws...@gmail.com>.
On 8/19/07, Don Brown <mr...@twdata.org> wrote:
> Sorry, what I meant was what has Maven learned about managing plugins?
> As Martin pointed out, it can easily become scattered and confusing
> for users, but on the other hand, opening up plugins for outside
> contributions let's us focus on the core of Struts 2. How does Maven
> ensure the support of popular plugins?
There is a mojo project over at Codehaus, and Maven searches that
groupId by default along with org.apache.maven.plugins. That covers
most of the useful 'generic' plugins.
Other projects and individuals are also releasing Maven plugins along
with their stuff-- Jetty, MyFaces, Cargo, several Docbook plugins,
etc.
You can ask questions about any Maven plugin on users@maven, even if
it's not a "core" plugin there's usually someone around who can either
help or get you to the right place (Cargo users list, etc.)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [S2] [2.1.x] Bundled Plugins
Posted by Don Brown <mr...@twdata.org>.
Sorry, what I meant was what has Maven learned about managing plugins?
As Martin pointed out, it can easily become scattered and confusing
for users, but on the other hand, opening up plugins for outside
contributions let's us focus on the core of Struts 2. How does Maven
ensure the support of popular plugins?
Don
On 8/20/07, Wendy Smoak <ws...@gmail.com> wrote:
> On 8/19/07, Don Brown <mr...@twdata.org> wrote:
>
> > Agreed, Spring should be a first-tier plugin. I'm fine with spinning
> > off the others, but who would maintain them? If it will be the same
> > people, then perhaps we should keep them in the repository.
> >
> > How does Maven handle this situation? Wendy?
>
> How does Maven handle what? Ted seems to be talking about moving
> these plugins out of 'trunk' -- so presumably to sandbox or out to
> another place entirely. You'll need to take them out of the <modules>
> list, and adjust the assembly descriptors for the release
> distributions.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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
Re: [S2] [2.1.x] Bundled Plugins
Posted by Wendy Smoak <ws...@gmail.com>.
On 8/19/07, Don Brown <mr...@twdata.org> wrote:
> Agreed, Spring should be a first-tier plugin. I'm fine with spinning
> off the others, but who would maintain them? If it will be the same
> people, then perhaps we should keep them in the repository.
>
> How does Maven handle this situation? Wendy?
How does Maven handle what? Ted seems to be talking about moving
these plugins out of 'trunk' -- so presumably to sandbox or out to
another place entirely. You'll need to take them out of the <modules>
list, and adjust the assembly descriptors for the release
distributions.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [S2] [2.1.x] Bundled Plugins
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Martin Cooper wrote:
> I honestly don't see that we could point at some other project outside the
> ASF and say that we "endorse" the plugins produced by that project when what
> we are really saying is that we don't consider those plugins to be
> sufficiently worthy to live at the ASF.
I suppose that's one interpretation. I'd see it more like
struts.sourceforge.net though... it's just an external location where
things can live and develop. Maybe saying it's "endorsed" does go too
far, but just pointing it out and saying "there's some plugins that may
or may not eventually make it into the mainline distribution", wouldn't
that be OK? I mean, I haven't looked in a while, but I recall there
being a link to struts.sourceforge.net on the main Struts site... does
that qualify as an endorsement? I wouldn't think so, but maybe I'm
wrong there.
> Plus, I personally would have a
> pretty fundamental problem with "endorsing" any one specific project outside
> the ASF in preference to any other.
I would too from the perspective of Struts as a project endorsing
something, no question. But I think it's a question of semantics:
calling something a project carries certain connotations, so maybe
that's the wrong word to use... Repository? Registry? Catalog? I
don't think these carry the same connotations, but all could equally
describe such an external entity.
> I suspect we could get into legal trouble over that sort of thing.
You may be right about that, my Bar card hasn't arrived yet so I can't
say ;)
> --
> Martin Cooper
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [S2] [2.1.x] Bundled Plugins
Posted by Martin Cooper <ma...@apache.org>.
On 8/19/07, Frank W. Zammetti <fz...@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.
We already have the notion of "experimental" pieces. I see this as being
somewhere between the core and the experimental pieces.
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.
I honestly don't see that we could point at some other project outside the
ASF and say that we "endorse" the plugins produced by that project when what
we are really saying is that we don't consider those plugins to be
sufficiently worthy to live at the ASF. Plus, I personally would have a
pretty fundamental problem with "endorsing" any one specific project outside
the ASF in preference to any other. I suspect we could get into legal
trouble over that sort of thing.
--
Martin Cooper
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
>
>
Re: [S2] [2.1.x] Bundled Plugins
Posted by Ted Husted <hu...@apache.org>.
On 8/20/07, Musachy Barroso <mu...@gmail.com> wrote:
> I'm sold with Paul's idea, now a question, could it be possible for
> people to become committers to the plugins in this subproject without
> being an struts committer?
Write access and being a committer are the same thing. So, no. :(
> I have 2 people helping me with the GWT plugin, and the JSON plugin,
> in the first case one of them rewrote the plugin for the new GWT
> version, on the second case the other one is fixing bugs and making
> improvements. It would be great if people could become committers to
> this subproject easier (compared to becoming an struts committer).
Yes, a big plus of hosting the plugin sites elsewhere is that its
possible to have a lower bar.
If these sites started to merge together into a a larger S2 plugin
site, it might be even easier for people to work together on various
plugins. It would make a great deal of sense for the GWT, JSON, Dojo,
and YUI plugins to all be part of the same site.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [S2] [2.1.x] Bundled Plugins
Posted by Musachy Barroso <mu...@gmail.com>.
I'm sold with Paul's idea, now a question, could it be possible for
people to become committers to the plugins in this subproject without
being an struts committer?
I have 2 people helping me with the GWT plugin, and the JSON plugin,
in the first case one of them rewrote the plugin for the new GWT
version, on the second case the other one is fixing bugs and making
improvements. It would be great if people could become committers to
this subproject easier (compared to becoming an struts committer).
musachy
On 8/19/07, Paul Benedict <pb...@apache.org> wrote:
> Don,
>
> I want to propose independent projects/releases. The only problem is going
> to be versioning, because all plug-ins are probably 2.0.x, right?
>
> Paul
>
> On 8/19/07, Don Brown <mr...@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 <pb...@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 <fz...@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
> >
> >
>
--
"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
Re: [S2] [2.1.x] Bundled Plugins
Posted by Paul Benedict <pb...@apache.org>.
Don,
I want to propose independent projects/releases. The only problem is going
to be versioning, because all plug-ins are probably 2.0.x, right?
Paul
On 8/19/07, Don Brown <mr...@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 <pb...@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 <fz...@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
>
>
Re: [S2] [2.1.x] Bundled Plugins
Posted by Nils-Helge Garli <ni...@gmail.com>.
Since it was refactored into a plugin, it has really undergone a face
lift, with a lot off issues resolved and stability improved. I can see
that there's a lot of documentation to be written. But other than
that, in your (as in everyone) opinion, what are the major areas where
it needs to be improved? I'm really interested in getting feedback on
this.
Nils-H
On 8/21/07, Don Brown <mr...@twdata.org> wrote:
> Although it is a lot of work, I'd too like to see the portlet plugin
> in the first-tier list.
>
> Don
>
> On 8/21/07, Nils-Helge Garli <ni...@gmail.com> wrote:
> > 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 <mr...@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 <pb...@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 <fz...@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
Re: [S2] [2.1.x] Bundled Plugins
Posted by Don Brown <mr...@twdata.org>.
Although it is a lot of work, I'd too like to see the portlet plugin
in the first-tier list.
Don
On 8/21/07, Nils-Helge Garli <ni...@gmail.com> wrote:
> 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 <mr...@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 <pb...@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 <fz...@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
Re: [S2] [2.1.x] Bundled Plugins
Posted by Nils-Helge Garli <ni...@gmail.com>.
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 <mr...@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 <pb...@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 <fz...@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
Re: [S2] [2.1.x] Bundled Plugins
Posted by Don Brown <mr...@twdata.org>.
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 <pb...@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 <fz...@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
Re: [S2] [2.1.x] Bundled Plugins
Posted by Paul Benedict <pb...@apache.org>.
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 <fz...@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
>
>
Re: [S2] [2.1.x] Bundled Plugins
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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
Re: [S2] [2.1.x] Bundled Plugins
Posted by Martin Cooper <ma...@apache.org>.
On 8/19/07, Ted Husted <hu...@apache.org> wrote:
>
> I'm not sure that anyone is maintaining them now. I'm not sure that
> they all work.
>
> My thinking is that if they are kept at another location where there
> is a lower bar to entry, then perhaps we can attract someone to
> maintain them.
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. By pushing
plugins out of the Struts distribution, we force additional approvals at
such companies just to be able to use the plugins. Many will opt to avoid
those additional dependencies, either because of the hassle or because they
cannot justify the additional external dependency that now doesn't come from
a respected source such as the ASF.
My concern is that some of the code in our distribution is not being
> used, or otherwise fully tested, by anyone in the group. When that is
> the case, then we should not be distributing the code.
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.
--
Martin Cooper
We should
> archive it, and, perhaps, for added value, make it available at
> another location.
>
> -Ted.
>
> On 8/19/07, Don Brown <mr...@twdata.org> wrote:
> > Agreed, Spring should be a first-tier plugin. I'm fine with spinning
> > off the others, but who would maintain them? If it will be the same
> > people, then perhaps we should keep them in the repository.
> >
> > How does Maven handle this situation? Wendy?
> >
> > Don
> >
> > On 8/20/07, Tom Schneider <sc...@gmail.com> wrote:
> > > I disagree with moving the Spring plugin outside of the core set of
> > > plugins. I think a lot of people use Spring and it would be a shame
> to
> > > not have it as a core feature. Keep in mind that I think we run a
> huge
> > > risk (IMO) of plugins being unmaintained if we set them free, however,
> > > I'm more than happy to do it for the more fringe plugins that not a
> lot
> > > of people use. I also think the JSF plugin is more of a fringe
> > > plugin--I'd be curious to know how many people are actually using it
> in
> > > production.
> > >
> > > There has been no interest whatsoever of anyone helping out on table
> > > tags. I knew I wouldn't have the time to work on it after I initially
> > > created it, but I was hoping other developers would take
> interest. That
> > > hasn't happened. (I may get some time if we upgrade to struts 2 at
> > > work) If we want to integrate it into core, we need developers to
> > > really run with it and make it real. Right now it isn't production
> > > ready--I just haven't spent enough time with it.
> > >
> > > Everything else in your list looks good to me.
> > > Tom
> > >
> > > Ted Husted wrote:
> > > > On 8/18/07, Musachy Barroso <mu...@gmail.com> wrote:
> > > >
> > > >> do you mean to move the plugin out of Struts? Because Dojo is
> already
> > > >> on its own plugin in trunk.
> > > >>
> > > >
> > > > My question was whether we wanted to keep Dojo as part of the
> project,
> > > > or move it GoogleCode, along with the YUI plugin. I think some of
> the
> > > > other questions misunderstood where we already are, in that for
> 2.1.x
> > > > Dojo is one of our bundled plugins, like Spring and JasperReports.
> > > > Right now the bundled plugin list for 2.1.x is
> > > >
> > > > * codebehind
> > > > * config-browser
> > > > * dojo
> > > > * jasperreports
> > > > * jfreechart
> > > > * jsf
> > > > * pell-multichart
> > > > * plexus
> > > > * spring
> > > > * struts1
> > > > * tiles
> > > >
> > > > The underlying question is whether we have active committers who
> > > > actually *want* to maintain all of these plugins as part of the
> trunk.
> > > >
> > > > Initially, we dragged most of these along because there were part of
> > > > WebWork and 2.0 was the backward-compatibility series. Moving
> forward,
> > > > we might want to be more careful about the plugins that we bundle.
> One
> > > > idea would be to create a Struts Plugin project somewhere, where
> > > > third-party plugins could be maintained jointly.
> > > >
> > > > My suggestion would be to retain
> > > >
> > > > * codebehind
> > > > * config-browser
> > > > * jsf
> > > > * struts1
> > > > * tiles
> > > >
> > > > and add (with the permission of the owners)
> > > >
> > > > * JSON Plugin
> > > > * Table Tags
> > > > * Smart URLs
> > > >
> > > > And then encourage the remainder be adopted by an independant open
> > > > source project (while we keep a snapshot of what we have now in the
> > > > Archive).
> > > >
> > > > * dojo
> > > > * jasperreports
> > > > * jfreechart
> > > > * pell-multichart
> > > > * plexus
> > > > * spring
> > > >
> > > > Ideally, some of the other plugin projects might merge into the
> > > > independant Struts Plugin project, making it easier for people to
> gain
> > > > access later if the original author drifts awqay.
> > > >
> > > > Thoughts?
> > > >
> > > > -Ted.
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > 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
> >
> >
>
>
> --
> HTH, Ted <http://www.husted.com/ted/blog/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [S2] [2.1.x] Bundled Plugins
Posted by Musachy Barroso <mu...@gmail.com>.
> For the plugins itself: I believe that the spring plugin as well as the
> portlet plugin belong (close) to the core, since they are widely used
> and , afaik at least for the portlet plugin, actively maintained. Btw,
> what are the current issues with spring plugin, if there are?
+1
>
> So, why don't we fork off a 0.9 dojo plugin under the proposed struts
> external umbrella at google code or sourceforge? I think this would be a
> very attractive starting point with the potential to have many
> developers involved soon. The 0.4 dojo plugin would stay under the asf
> struts umbrella, ensuring people will find what they are known to find.
> Maybe we would want to strip it down to a more base functionality then.
> Maybe we should also put some thoughts into splitting up UI
> functionality integration from the pure AJAX functionalities
> integration, regarding dojo encapsulation through the struts framework.
>
I would agree if it wasn't for the fact of how unstable Dojo is. After
seen how many things would just stop working from one minor release to
the other I wouldn't want to touch 0.9 for a while.
musachy
--
"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
Re: [S2] [2.1.x] Bundled Plugins
Posted by Ted Husted <hu...@apache.org>.
On 8/22/07, Rene Gielen <rg...@apache.org> wrote:
> In another post Ted mentioned that this was tried in struts1 before, and
> it did not work. This was before the merger, so I don't know why that
> happened. I'm not sure if preconditions would be the same now, maybe it
> works better this time?
The two concerns were creating so many release artifacts, and tracking
which artifact release went with each core release.
A key question will be whether most plugins remain stable between
point releases. If each point release forces several plugins to be
released, then we're creating extra work without accomplishing much.
Though, given the nature of plugins, they may tend to be stable.
We could start to address the second question using Maven as a
stopgap, but I don't know if we want to make Maven critical to our API
for very long. If we are going to have separate release cycles, then I
would strongly prefer that a plugin fail fast and hard if the minimum
core requirements are not met. (The way, say, FireFox does.)
Of course, if we minimize how many plugins we carry here, then both
concerns are also minimized.
> For the jasper, pell, plexus and jfreechart I don't see moving them out
> to some external project would give us. Do we have major open points for
> these plugins? IMO they should reside within the ASF part of the framework.
That's fine, so long as another committer says to me: "I'm using this
plugin in production, or I have tested it throughly and realistically
on my local machine, and I vouch that it works as advertised. And, if
it doesn't, I'll fix it!"
Otherwise, I'm strongly -1 on distributing code that everyone here is
ignoring just because we think someone, somewhere might be using it.
If it's in the distribution, people expect it to work. It's cruel to
let some hapless soul find out something is broken the hard way.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [S2] [2.1.x] Bundled Plugins
Posted by Rene Gielen <rg...@apache.org>.
I believe that since in 2.1 the functionalities are cleanly separated
into core and plugins for the first time, the next logical step is to
have independant life cycles for them. This would give us the
opportunity to assure core distribution quality better, as well as
marking experimental/beta for what _is_ experimental or beta. With
maven2 we have the tool to manage dependencies / requirements easily
(man, I never believed I'm going to become a maven fellow ... :))
In another post Ted mentioned that this was tried in struts1 before, and
it did not work. This was before the merger, so I don't know why that
happened. I'm not sure if preconditions would be the same now, maybe it
works better this time? If we start off with an independent lifecycle
for non core plugins under the ASF/Struts umbrella and we see that it
does not fit for one ore more of these plugins, we would still be free
to move them out a google code plugin zoo project, which is a good idea
at all to set up IMO. But in the first place, I personally would like to
offer people the functionalities they might be using for years now
(including those moving over from ww to struts2) from a single source.
For the plugins itself: I believe that the spring plugin as well as the
portlet plugin belong (close) to the core, since they are widely used
and , afaik at least for the portlet plugin, actively maintained. Btw,
what are the current issues with spring plugin, if there are?
For the jasper, pell, plexus and jfreechart I don't see moving them out
to some external project would give us. Do we have major open points for
these plugins? IMO they should reside within the ASF part of the framework.
Although dojo needs a lot of work, there seem to be lot of people out
there to use functionalities we give them with dojo under the hood,
mostly the widgets and the event systen integration. If people talk
about broken, they often refer to the AJAX integration, but that's not
all we (and many s2 users) use dojo for.
On the other hand, to get momentum into the dojo development, a easy to
entry community with many hands would help a lot. And 0.9 integration
will be a point soon...
So, why don't we fork off a 0.9 dojo plugin under the proposed struts
external umbrella at google code or sourceforge? I think this would be a
very attractive starting point with the potential to have many
developers involved soon. The 0.4 dojo plugin would stay under the asf
struts umbrella, ensuring people will find what they are known to find.
Maybe we would want to strip it down to a more base functionality then.
Maybe we should also put some thoughts into splitting up UI
functionality integration from the pure AJAX functionalities
integration, regarding dojo encapsulation through the struts framework.
For the table tag plugin, and maybe even the JSF plugin, I believe that
it is not that widely used till now and they might be also candidates to
attract external developers by moving it out.
Regards,
Rene
Ian Roughley schrieb:
>
>
> Ted Husted wrote:
>> I'm not sure that anyone is maintaining them now. I'm not sure that
>> they all work.
>>
>> My thinking is that if they are kept at another location where there
>> is a lower bar to entry, then perhaps we can attract someone to
>> maintain them.
>>
> Or, the other option is that no one picks them up and then they are
> outdated to the changes in the s2 code base.
>> My concern is that some of the code in our distribution is not being
>> used, or otherwise fully tested, by anyone in the group. When that is
>> the case, then we should not be distributing the code.
> This is my biggest concern. When I look at rails the biggest thing I
> see is that every aspect of the core code works well, is integrated and
> documented (or maybe I'm just lucky and this is all I've come across so
> far). There is also a thriving plugin community, which is independent
> from the core.
>
> Perhaps what is needed is a more understood labeling mechanism. So far
> we have "experimental", but there are experimental features that are
> documented and in excellent shape - so much so that I am using them in
> production code. And there is other non-labeled code that I am very
> cautious of using (XSLT results).
>
> For the plugins kept in s2, the other change I would like to see is
> independent life cycles. If the code has not changed, I'm not sure why
> its version needs to be incremented (other than staying with the s2 core
> version). Would independent SVN repos help here?
>
> In retrospect, perhaps keeping the dojo plugin in s2 is the way to go
> (the discussion that started this), but I still believe that an
> independent life cycle is needed (someone just asked whether 2.0.x was
> going to upgrade dojo from 0.4 to 0.9).
>> We should
>> archive it, and, perhaps, for added value, make it available at
>> another location.
>>
>> -Ted.
>>
>>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [S2] [2.1.x] Bundled Plugins
Posted by Don Brown <mr...@twdata.org>.
Actually, plugins already have a robust, tested versioning and
dependency management system - Maven 2. Since Struts 2 plugins are
built-time resources, their version and what versions they require are
specified in the pom.xml and managed by Maven 2. If you want to use a
Struts 2 plugin that requires an older version of Struts 2, you'll
have to explicitly, in Maven 2, handle that conflict.
Of course, not everyone uses Maven 2, so perhaps we could build
something that uses the pom.xml that Maven 2 automatically puts in the
jar. I'd love to have a little plugin that did printed out something
like php's phpinfo() method, or it could process the pom.xml's in a
more intelligent way to do things like print warnings for mismatched
versions.
Don
On 8/22/07, Ted Husted <hu...@apache.org> wrote:
> On 8/21/07, Ian Roughley <ia...@fdar.com> wrote:
> > For the plugins kept in s2, the other change I would like to see is
> > independent life cycles. If the code has not changed, I'm not sure why
> > its version needs to be incremented (other than staying with the s2 core
> > version). Would independent SVN repos help here?
>
> What might help most would be a slightly more sophisticated plugin
> system, so that a plugin could declare its own minimum version of
> Struts Core, and loudly refuse to load if the minimum requirements are
> not met. (Of course, the same should be true of any external
> dependencies!)
>
> Following Don's lead, it might be a good idea to look toward OSGi as a
> plugin model, which is what Eclipse also uses.
>
> -Ted.
>
> ---------------------------------------------------------------------
> 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
Re: [S2] [2.1.x] Bundled Plugins
Posted by Ted Husted <hu...@apache.org>.
On 8/21/07, Ian Roughley <ia...@fdar.com> wrote:
> For the plugins kept in s2, the other change I would like to see is
> independent life cycles. If the code has not changed, I'm not sure why
> its version needs to be incremented (other than staying with the s2 core
> version). Would independent SVN repos help here?
What might help most would be a slightly more sophisticated plugin
system, so that a plugin could declare its own minimum version of
Struts Core, and loudly refuse to load if the minimum requirements are
not met. (Of course, the same should be true of any external
dependencies!)
Following Don's lead, it might be a good idea to look toward OSGi as a
plugin model, which is what Eclipse also uses.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [S2] [2.1.x] Bundled Plugins
Posted by Ian Roughley <ia...@fdar.com>.
Ted Husted wrote:
> I'm not sure that anyone is maintaining them now. I'm not sure that
> they all work.
>
> My thinking is that if they are kept at another location where there
> is a lower bar to entry, then perhaps we can attract someone to
> maintain them.
>
Or, the other option is that no one picks them up and then they are
outdated to the changes in the s2 code base.
> My concern is that some of the code in our distribution is not being
> used, or otherwise fully tested, by anyone in the group. When that is
> the case, then we should not be distributing the code.
This is my biggest concern. When I look at rails the biggest thing I
see is that every aspect of the core code works well, is integrated and
documented (or maybe I'm just lucky and this is all I've come across so
far). There is also a thriving plugin community, which is independent
from the core.
Perhaps what is needed is a more understood labeling mechanism. So far
we have "experimental", but there are experimental features that are
documented and in excellent shape - so much so that I am using them in
production code. And there is other non-labeled code that I am very
cautious of using (XSLT results).
For the plugins kept in s2, the other change I would like to see is
independent life cycles. If the code has not changed, I'm not sure why
its version needs to be incremented (other than staying with the s2 core
version). Would independent SVN repos help here?
In retrospect, perhaps keeping the dojo plugin in s2 is the way to go
(the discussion that started this), but I still believe that an
independent life cycle is needed (someone just asked whether 2.0.x was
going to upgrade dojo from 0.4 to 0.9).
> We should
> archive it, and, perhaps, for added value, make it available at
> another location.
>
> -Ted.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [S2] [2.1.x] Bundled Plugins
Posted by Ted Husted <hu...@apache.org>.
I'm not sure that anyone is maintaining them now. I'm not sure that
they all work.
My thinking is that if they are kept at another location where there
is a lower bar to entry, then perhaps we can attract someone to
maintain them.
My concern is that some of the code in our distribution is not being
used, or otherwise fully tested, by anyone in the group. When that is
the case, then we should not be distributing the code. We should
archive it, and, perhaps, for added value, make it available at
another location.
-Ted.
On 8/19/07, Don Brown <mr...@twdata.org> wrote:
> Agreed, Spring should be a first-tier plugin. I'm fine with spinning
> off the others, but who would maintain them? If it will be the same
> people, then perhaps we should keep them in the repository.
>
> How does Maven handle this situation? Wendy?
>
> Don
>
> On 8/20/07, Tom Schneider <sc...@gmail.com> wrote:
> > I disagree with moving the Spring plugin outside of the core set of
> > plugins. I think a lot of people use Spring and it would be a shame to
> > not have it as a core feature. Keep in mind that I think we run a huge
> > risk (IMO) of plugins being unmaintained if we set them free, however,
> > I'm more than happy to do it for the more fringe plugins that not a lot
> > of people use. I also think the JSF plugin is more of a fringe
> > plugin--I'd be curious to know how many people are actually using it in
> > production.
> >
> > There has been no interest whatsoever of anyone helping out on table
> > tags. I knew I wouldn't have the time to work on it after I initially
> > created it, but I was hoping other developers would take interest. That
> > hasn't happened. (I may get some time if we upgrade to struts 2 at
> > work) If we want to integrate it into core, we need developers to
> > really run with it and make it real. Right now it isn't production
> > ready--I just haven't spent enough time with it.
> >
> > Everything else in your list looks good to me.
> > Tom
> >
> > Ted Husted wrote:
> > > On 8/18/07, Musachy Barroso <mu...@gmail.com> wrote:
> > >
> > >> do you mean to move the plugin out of Struts? Because Dojo is already
> > >> on its own plugin in trunk.
> > >>
> > >
> > > My question was whether we wanted to keep Dojo as part of the project,
> > > or move it GoogleCode, along with the YUI plugin. I think some of the
> > > other questions misunderstood where we already are, in that for 2.1.x
> > > Dojo is one of our bundled plugins, like Spring and JasperReports.
> > > Right now the bundled plugin list for 2.1.x is
> > >
> > > * codebehind
> > > * config-browser
> > > * dojo
> > > * jasperreports
> > > * jfreechart
> > > * jsf
> > > * pell-multichart
> > > * plexus
> > > * spring
> > > * struts1
> > > * tiles
> > >
> > > The underlying question is whether we have active committers who
> > > actually *want* to maintain all of these plugins as part of the trunk.
> > >
> > > Initially, we dragged most of these along because there were part of
> > > WebWork and 2.0 was the backward-compatibility series. Moving forward,
> > > we might want to be more careful about the plugins that we bundle. One
> > > idea would be to create a Struts Plugin project somewhere, where
> > > third-party plugins could be maintained jointly.
> > >
> > > My suggestion would be to retain
> > >
> > > * codebehind
> > > * config-browser
> > > * jsf
> > > * struts1
> > > * tiles
> > >
> > > and add (with the permission of the owners)
> > >
> > > * JSON Plugin
> > > * Table Tags
> > > * Smart URLs
> > >
> > > And then encourage the remainder be adopted by an independant open
> > > source project (while we keep a snapshot of what we have now in the
> > > Archive).
> > >
> > > * dojo
> > > * jasperreports
> > > * jfreechart
> > > * pell-multichart
> > > * plexus
> > > * spring
> > >
> > > Ideally, some of the other plugin projects might merge into the
> > > independant Struts Plugin project, making it easier for people to gain
> > > access later if the original author drifts awqay.
> > >
> > > Thoughts?
> > >
> > > -Ted.
> > >
> > > ---------------------------------------------------------------------
> > > 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
>
>
--
HTH, Ted <http://www.husted.com/ted/blog/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [S2] [2.1.x] Bundled Plugins
Posted by Don Brown <mr...@twdata.org>.
Agreed, Spring should be a first-tier plugin. I'm fine with spinning
off the others, but who would maintain them? If it will be the same
people, then perhaps we should keep them in the repository.
How does Maven handle this situation? Wendy?
Don
On 8/20/07, Tom Schneider <sc...@gmail.com> wrote:
> I disagree with moving the Spring plugin outside of the core set of
> plugins. I think a lot of people use Spring and it would be a shame to
> not have it as a core feature. Keep in mind that I think we run a huge
> risk (IMO) of plugins being unmaintained if we set them free, however,
> I'm more than happy to do it for the more fringe plugins that not a lot
> of people use. I also think the JSF plugin is more of a fringe
> plugin--I'd be curious to know how many people are actually using it in
> production.
>
> There has been no interest whatsoever of anyone helping out on table
> tags. I knew I wouldn't have the time to work on it after I initially
> created it, but I was hoping other developers would take interest. That
> hasn't happened. (I may get some time if we upgrade to struts 2 at
> work) If we want to integrate it into core, we need developers to
> really run with it and make it real. Right now it isn't production
> ready--I just haven't spent enough time with it.
>
> Everything else in your list looks good to me.
> Tom
>
> Ted Husted wrote:
> > On 8/18/07, Musachy Barroso <mu...@gmail.com> wrote:
> >
> >> do you mean to move the plugin out of Struts? Because Dojo is already
> >> on its own plugin in trunk.
> >>
> >
> > My question was whether we wanted to keep Dojo as part of the project,
> > or move it GoogleCode, along with the YUI plugin. I think some of the
> > other questions misunderstood where we already are, in that for 2.1.x
> > Dojo is one of our bundled plugins, like Spring and JasperReports.
> > Right now the bundled plugin list for 2.1.x is
> >
> > * codebehind
> > * config-browser
> > * dojo
> > * jasperreports
> > * jfreechart
> > * jsf
> > * pell-multichart
> > * plexus
> > * spring
> > * struts1
> > * tiles
> >
> > The underlying question is whether we have active committers who
> > actually *want* to maintain all of these plugins as part of the trunk.
> >
> > Initially, we dragged most of these along because there were part of
> > WebWork and 2.0 was the backward-compatibility series. Moving forward,
> > we might want to be more careful about the plugins that we bundle. One
> > idea would be to create a Struts Plugin project somewhere, where
> > third-party plugins could be maintained jointly.
> >
> > My suggestion would be to retain
> >
> > * codebehind
> > * config-browser
> > * jsf
> > * struts1
> > * tiles
> >
> > and add (with the permission of the owners)
> >
> > * JSON Plugin
> > * Table Tags
> > * Smart URLs
> >
> > And then encourage the remainder be adopted by an independant open
> > source project (while we keep a snapshot of what we have now in the
> > Archive).
> >
> > * dojo
> > * jasperreports
> > * jfreechart
> > * pell-multichart
> > * plexus
> > * spring
> >
> > Ideally, some of the other plugin projects might merge into the
> > independant Struts Plugin project, making it easier for people to gain
> > access later if the original author drifts awqay.
> >
> > Thoughts?
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > 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
RE: [S2] [2.1.x] Bundled Plugins
Posted by James Holmes <ja...@jamesholmes.com>.
+1 for keeping the Spring module at the Struts project.
-----Original Message-----
From: Tom Schneider [mailto:schneidh@gmail.com]
Sent: Sunday, August 19, 2007 10:18 AM
To: Struts Developers List
Subject: Re: [S2] [2.1.x] Bundled Plugins
I disagree with moving the Spring plugin outside of the core set of
plugins. I think a lot of people use Spring and it would be a shame to
not have it as a core feature. Keep in mind that I think we run a huge
risk (IMO) of plugins being unmaintained if we set them free, however,
I'm more than happy to do it for the more fringe plugins that not a lot
of people use. I also think the JSF plugin is more of a fringe
plugin--I'd be curious to know how many people are actually using it in
production.
There has been no interest whatsoever of anyone helping out on table
tags. I knew I wouldn't have the time to work on it after I initially
created it, but I was hoping other developers would take interest. That
hasn't happened. (I may get some time if we upgrade to struts 2 at
work) If we want to integrate it into core, we need developers to
really run with it and make it real. Right now it isn't production
ready--I just haven't spent enough time with it.
Everything else in your list looks good to me.
Tom
Ted Husted wrote:
> On 8/18/07, Musachy Barroso <mu...@gmail.com> wrote:
>
>> do you mean to move the plugin out of Struts? Because Dojo is already
>> on its own plugin in trunk.
>>
>
> My question was whether we wanted to keep Dojo as part of the project,
> or move it GoogleCode, along with the YUI plugin. I think some of the
> other questions misunderstood where we already are, in that for 2.1.x
> Dojo is one of our bundled plugins, like Spring and JasperReports.
> Right now the bundled plugin list for 2.1.x is
>
> * codebehind
> * config-browser
> * dojo
> * jasperreports
> * jfreechart
> * jsf
> * pell-multichart
> * plexus
> * spring
> * struts1
> * tiles
>
> The underlying question is whether we have active committers who
> actually *want* to maintain all of these plugins as part of the trunk.
>
> Initially, we dragged most of these along because there were part of
> WebWork and 2.0 was the backward-compatibility series. Moving forward,
> we might want to be more careful about the plugins that we bundle. One
> idea would be to create a Struts Plugin project somewhere, where
> third-party plugins could be maintained jointly.
>
> My suggestion would be to retain
>
> * codebehind
> * config-browser
> * jsf
> * struts1
> * tiles
>
> and add (with the permission of the owners)
>
> * JSON Plugin
> * Table Tags
> * Smart URLs
>
> And then encourage the remainder be adopted by an independant open
> source project (while we keep a snapshot of what we have now in the
> Archive).
>
> * dojo
> * jasperreports
> * jfreechart
> * pell-multichart
> * plexus
> * spring
>
> Ideally, some of the other plugin projects might merge into the
> independant Struts Plugin project, making it easier for people to gain
> access later if the original author drifts awqay.
>
> Thoughts?
>
> -Ted.
>
> ---------------------------------------------------------------------
> 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
Re: [S2] [2.1.x] Bundled Plugins
Posted by Tom Schneider <sc...@gmail.com>.
I disagree with moving the Spring plugin outside of the core set of
plugins. I think a lot of people use Spring and it would be a shame to
not have it as a core feature. Keep in mind that I think we run a huge
risk (IMO) of plugins being unmaintained if we set them free, however,
I'm more than happy to do it for the more fringe plugins that not a lot
of people use. I also think the JSF plugin is more of a fringe
plugin--I'd be curious to know how many people are actually using it in
production.
There has been no interest whatsoever of anyone helping out on table
tags. I knew I wouldn't have the time to work on it after I initially
created it, but I was hoping other developers would take interest. That
hasn't happened. (I may get some time if we upgrade to struts 2 at
work) If we want to integrate it into core, we need developers to
really run with it and make it real. Right now it isn't production
ready--I just haven't spent enough time with it.
Everything else in your list looks good to me.
Tom
Ted Husted wrote:
> On 8/18/07, Musachy Barroso <mu...@gmail.com> wrote:
>
>> do you mean to move the plugin out of Struts? Because Dojo is already
>> on its own plugin in trunk.
>>
>
> My question was whether we wanted to keep Dojo as part of the project,
> or move it GoogleCode, along with the YUI plugin. I think some of the
> other questions misunderstood where we already are, in that for 2.1.x
> Dojo is one of our bundled plugins, like Spring and JasperReports.
> Right now the bundled plugin list for 2.1.x is
>
> * codebehind
> * config-browser
> * dojo
> * jasperreports
> * jfreechart
> * jsf
> * pell-multichart
> * plexus
> * spring
> * struts1
> * tiles
>
> The underlying question is whether we have active committers who
> actually *want* to maintain all of these plugins as part of the trunk.
>
> Initially, we dragged most of these along because there were part of
> WebWork and 2.0 was the backward-compatibility series. Moving forward,
> we might want to be more careful about the plugins that we bundle. One
> idea would be to create a Struts Plugin project somewhere, where
> third-party plugins could be maintained jointly.
>
> My suggestion would be to retain
>
> * codebehind
> * config-browser
> * jsf
> * struts1
> * tiles
>
> and add (with the permission of the owners)
>
> * JSON Plugin
> * Table Tags
> * Smart URLs
>
> And then encourage the remainder be adopted by an independant open
> source project (while we keep a snapshot of what we have now in the
> Archive).
>
> * dojo
> * jasperreports
> * jfreechart
> * pell-multichart
> * plexus
> * spring
>
> Ideally, some of the other plugin projects might merge into the
> independant Struts Plugin project, making it easier for people to gain
> access later if the original author drifts awqay.
>
> Thoughts?
>
> -Ted.
>
> ---------------------------------------------------------------------
> 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