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
On 8/22/07, Rene Gielen [EMAIL PROTECTED] 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
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
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
+1 for keeping the Portlet plugin in the core Struts 2 distribution and
project. Nils-H is actively maintaining it and I am
interested in maintaining it as well.
James
On Tue Aug 21 1:43 , 'Nils-Helge Garli' [EMAIL PROTECTED] sent:
I couldn't fint the portlet plugin mentioned on the list of
What's the traction on having S2 plugin-only committers? I am referring to a
previous email from Antonio. Just like people sign CLA to write
documentation, I think our plugin development would have a major boost if we
could have plugin-only committers too.
Paul
On 8/21/07, Nils-Helge Garli
I guess that's a question of definition, viewed in a historical
perspective ;) But I do intend to keep actively maintaining it, and a
few more people maintaining it would be very welcome!
Nils-H
On 8/21/07, James Holmes [EMAIL PROTECTED] wrote:
+1 for keeping the Portlet plugin in the core
Yeah that's what I thought, per Ted's comments we can't do that.
Having independent releases for the plugins would be another boost.
musachy
On 8/21/07, Paul Benedict [EMAIL PROTECTED] wrote:
What's the traction on having S2 plugin-only committers? I am referring to a
previous email from
I seem to have lost that email. What was Ted's reason?
On 8/21/07, Musachy Barroso [EMAIL PROTECTED] wrote:
Yeah that's what I thought, per Ted's comments we can't do that.
Having independent releases for the plugins would be another boost.
musachy
On 8/21/07, Paul Benedict [EMAIL
Write access and being a committer are the same thing. So, no. :(
On 8/21/07, Paul Benedict [EMAIL PROTECTED] wrote:
I seem to have lost that email. What was Ted's reason?
On 8/21/07, Musachy Barroso [EMAIL PROTECTED] wrote:
Yeah that's what I thought, per Ted's comments we can't do that.
On 8/21/07, Paul Benedict [EMAIL PROTECTED] wrote:
What's the traction on having S2 plugin-only committers? I am referring to a
previous email from Antonio. Just like people sign CLA to write
documentation, I think our plugin development would have a major boost if we
could have plugin-only
Another way to boost plugin development would be to create an umbrella
GoogleCode site to host plugins, rather than a separate site for each
one, and offer membership to all the Struts committers, as well as any
developer with a plugin to commit. If that group then wants to
encourage people
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
On 8/21/07, Ian Roughley [EMAIL PROTECTED] 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
Oooh, good thinking! I mean on the minimum version check thing.
On Tue Aug 21 14:38 , 'Ted Husted' [EMAIL PROTECTED] sent:
On 8/21/07, Ian Roughley [EMAIL PROTECTED] wrote:
For the plugins kept in s2, the other change I would like to see is
independent life cycles. If the code has not
If someone is good enough to support a plugin, then they should also be good
enough to support Struts proper too.
In this line of thinking, it may good to outsource the lesser plugins into
GoogleCode (or whatever). If any plugins gain enough traction with outside
committers, perhaps then you do
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
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
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
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 [EMAIL PROTECTED]
+1 for keeping the Spring module at the Struts project.
-Original Message-
From: Tom Schneider [mailto:[EMAIL PROTECTED]
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
On 8/19/07, Don Brown [EMAIL PROTECTED] 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?
On 8/19/07, Don Brown [EMAIL PROTECTED] 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
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
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
On 8/19/07, Ted Husted [EMAIL PROTECTED] 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.
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
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,
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 [EMAIL PROTECTED] wrote:
Hi all.
On 8/19/07, Don Brown [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote:
Makes sense to me. Would we bundle the second-tier plugins in our
release or just the first
On 8/19/07, Frank W. Zammetti [EMAIL PROTECTED] 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
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
33 matches
Mail list logo
