You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Paul Benedict <pb...@apache.org> on 2007/04/21 21:13:31 UTC
PROPOSAL: s1 modules module
I am proposing a new module for Struts 1.x called "modules" which would
contain integration classes into popular open source libraries. For
starters, it would contain a new command to let Spring wire up the CRP
using a command.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: PROPOSAL: s1 modules module
Posted by Wendy Smoak <ws...@gmail.com>.
On 4/29/07, Paul Benedict <pb...@apache.org> wrote:
> Based on the emails, it sounds like having a module for various
> integration libraries is preferred.
A separate module for each new integration library, yes.
> Fine by me. How can we get the
> proposal to out of the think tank and into SVN?
Add a directory, commit the new files, and then hook it up in the
Maven pom (add a <module>) so it gets built. If you need help, ask a
specific question.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: PROPOSAL: s1 modules module
Posted by Paul Benedict <pb...@apache.org>.
Based on the emails, it sounds like having a module for various
integration libraries is preferred. Fine by me. How can we get the
proposal to out of the think tank and into SVN?
Paul Benedict wrote:
> I am proposing a new module for Struts 1.x called "modules" which
> would contain integration classes into popular open source libraries.
> For starters, it would contain a new command to let Spring wire up the
> CRP using a command.
>
> Paul
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: PROPOSAL: s1 modules module
Posted by Ted Husted <hu...@apache.org>.
On 4/22/07, Paul Benedict <pb...@apache.org> wrote:
> We already have a plug-in system in 1.x. I don't think I want to develop
> plugins -- but I do want to provide a standard community library for
> integration classes.
We have a filter-like interface that we named "plugin", but I wouldn't
call it a plugin system.
The key component to a modern "plugin system' is being able to drop in
a JAR or two with preferably zero configruation.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: PROPOSAL: s1 modules module
Posted by Paul Benedict <pb...@apache.org>.
On 4/21/07, Ted Husted <hu...@apache.org> wrote:
> A key problem with an omnibus JAR isn't so much the other classes
> (that the JVM wouldn't load) or the dependencies (that Maven wouldn't
> import), but just handling the logging statements. In practice, the
> optional code might want to try and initialize itself if the
> dependency is present, or not if the dependency is absent. Either way,
> we'd probably want to log whether it found the dependency and loaded
> or not, otherwise a lot of people will be wondering why an extra
> doesn't work. But, if there is more than one extra in a JAR, then not
> loading might be a normal occurrence, so we end up with half-hearted
> statements like "The Spring Extra didn't initialize, but that might be
> OK if you're not using Spring!".
Alright. Having an "extras" project per integration technology is fine. I
agree with you and Martin. That sounds very good tome.
We tried the optional route with Struts 2 and ultimately went to a
> full-blown plugin system, because of issues like these.
>
> We might want to think about framing this initiative as a strategy
> that third-parties could also follow, as we did with the Struts 2
> plugins.
We already have a plug-in system in 1.x. I don't think I want to develop
plugins -- but I do want to provide a standard community library for
integration classes.
Paul
Re: PROPOSAL: s1 modules module
Posted by Ted Husted <hu...@apache.org>.
Another popular term for something like this is "extras". So, there
might be a Struts 1 Spring Extras JAR and maybe a Struts 1
JasperReports Extras JARs.
A key problem with an omnibus JAR isn't so much the other classes
(that the JVM wouldn't load) or the dependencies (that Maven wouldn't
import), but just handling the logging statements. In practice, the
optional code might want to try and initialize itself if the
dependency is present, or not if the dependency is absent. Either way,
we'd probably want to log whether it found the dependency and loaded
or not, otherwise a lot of people will be wondering why an extra
doesn't work. But, if there is more than one extra in a JAR, then not
loading might be a normal occurrence, so we end up with half-hearted
statements like "The Spring Extra didn't initialize, but that might be
OK if you're not using Spring!".
We tried the optional route with Struts 2 and ultimately went to a
full-blown plugin system, because of issues like these.
We might want to think about framing this initiative as a strategy
that third-parties could also follow, as we did with the Struts 2
plugins.
-Ted.
On 4/21/07, Paul Benedict <pb...@apache.org> wrote:
> I am proposing a new module for Struts 1.x called "modules" which would
> contain integration classes into popular open source libraries. For
> starters, it would contain a new command to let Spring wire up the CRP
> using a command.
>
> Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: PROPOSAL: s1 modules module
Posted by Ted Husted <hu...@apache.org>.
On 4/23/07, Antonio Petrelli <an...@gmail.com> wrote:
> What I don't want is to see another case of snapshot dependency. In
> the case of Struts 2 probably it was due to the lack of knowledge of
> integration package status: not all people knew, for example, that the
> dependency to Tiles 2 was to 2.0-SNAPSHOT, and it inadvertently went
> GA: what is happening is that some people are using Tiles 2 in a wrong
> (or better, old) way. When Struts 2 will depend on a stable release of
> Tiles 2, we must say: we are sorry, you have to change all your XMLs
> and JSPs.
In the release notes, we listed several plugins and features that were
considered "experimental", and the Tiles 2 plugin is among those.
Realistically, the alternative would have been to withhold the Tiles 2
plugin from the Struts 2 release. Likewise, if we couldn't release the
Maven artifacts because of the internal snapshot dependency on
annotations, we probably wouldn't have had a release at all.
As things are setup now, we could start releasing plugins
independently whenever we choose, or mix and match. We could, for
example, easily create a struts-tiles-plugins-2.0.7.1 release, if need
be, and release it on its own. Each plugin has its own POM, we simply
choose to distribute the artifacts together.
The issues are social. People just don't want to deal with managing
releases of 18 distinct S2 artifacts (literally). I don't know if
Struts 1 would ever get to eighteen now, but if we had Struts 1
plugins three years ago, it certainly would have.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: PROPOSAL: s1 modules module
Posted by Antonio Petrelli <an...@gmail.com>.
2007/4/23, Paul Benedict <pb...@apache.org>:
> I totally agree, even to this day, that breaking out Struts 1 modules into
> independent releases is a bad idea. Why? Because it's essentially the
> framework spread across separate jars, and those truly have tight cohesion.
Isn't it a problem of assemblying the artifacts? We've got the
assembly plugin for this!
> Usually a significant upgrade in one library requires an upgrade of the
> rest. So I believe it was a mightily good decision to keep them all together
> as one version.
I see your point, and you're right when you say that, when changing
the base library, the depending items must change accordingly. But
this process happens usually only in early development cycles, not
when the base code is stabilized.
What I don't want is to see another case of snapshot dependency. In
the case of Struts 2 probably it was due to the lack of knowledge of
integration package status: not all people knew, for example, that the
dependency to Tiles 2 was to 2.0-SNAPSHOT, and it inadvertently went
GA: what is happening is that some people are using Tiles 2 in a wrong
(or better, old) way. When Struts 2 will depend on a stable release of
Tiles 2, we must say: we are sorry, you have to change all your XMLs
and JSPs.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: PROPOSAL: s1 modules module
Posted by Paul Benedict <pb...@apache.org>.
On 4/22/07, Ted Husted <hu...@apache.org> wrote:
>
> On 4/22/07, Antonio Petrelli <an...@gmail.com> wrote:
> > If all integrations were projects on themselves, this would not happen.
> > This is due probably to the fact that Struts 2 did not use the Maven
> > release plugin, and I think that we need to use it since it forces us
> > to follow the correct way of doing releases.
>
> In Struts 1, we tried breaking it down and giving each major artificat
> its own release series, but people complained that it made the release
> process too complex, and there would be too much bookkeeping in
> keeping track of which plugin release went with which core release.
> So, we decided to lump everything together, Spring-style.
I totally agree, even to this day, that breaking out Struts 1 modules into
independent releases is a bad idea. Why? Because it's essentially the
framework spread across separate jars, and those truly have tight cohesion.
Usually a significant upgrade in one library requires an upgrade of the
rest. So I believe it was a mightily good decision to keep them all together
as one version.
With that said, the cohesion between the Struts library and integration
libraries are less so. I do not object to separate release cycles with we
had a s1-extras or s1-integration (or whatever) project. That would be the
best of both worlds.
Paul
Re: PROPOSAL: s1 modules module
Posted by James Mitchell <jm...@gmail.com>.
Ted, I'm willing to do s2 releases. However, even with the
documentation on the wiki, the process still seems very complicated.
As far as building and pushing bits around, I'm ok with it, but when
it comes to the release notes and open/close jira issues, it's not
totally clear (to me) what needs to happen.
If you don't mind a little hand holding, I don't mind volunteering
the time.
--
James Mitchell
On Apr 23, 2007, at 8:04 AM, Ted Husted wrote:
> On 4/23/07, Antonio Petrelli <an...@gmail.com> wrote:
>> Probably because making releases is (or better "was") a painful
>> operation. What if with 2 mere commands you created a release?
>
> The Struts 2 process is documented here:
>
> * http://struts.apache.org/2.0.6/docs/creating-and-signing-a-
> distribution.html
>
> I wouldn't call it painful, but it still "stings" a bit.
>
> I know Wendy has mentioned using the release plugin, but I'm not clear
> on what changes that would make to the workflow.
>
> One missing step is that we aren't generating "docs" or "J4"
> artifacts. I've been pulling them out of "-all" and zipping them up
> nonindependent. The J4 artifact might be problematic since we also
> need to run the backport utility, though I've heard there might be a
> plugin for that too.
>
> We're in desperate need of more Struts 2 release managers. I'm swamped
> this month, and I'll be very busy through the end of June. Unless
> someone else steps up, I'm afraid the S2 releases will grind to a
> halt.
>
> -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: PROPOSAL: s1 modules module
Posted by Antonio Petrelli <an...@gmail.com>.
2007/4/23, Ted Husted <hu...@apache.org>:
> On 4/23/07, Antonio Petrelli <an...@gmail.com> wrote:
> > Probably because making releases is (or better "was") a painful
> > operation. What if with 2 mere commands you created a release?
>
> The Struts 2 process is documented here:
>
> * http://struts.apache.org/2.0.6/docs/creating-and-signing-a-distribution.html
>
> I wouldn't call it painful, but it still "stings" a bit.
>
> I know Wendy has mentioned using the release plugin, but I'm not clear
> on what changes that would make to the workflow.
AFAICT the only difference between this process and the release plugin
is that the lattern does not allow snapshot dependencies.
>
> One missing step is that we aren't generating "docs" or "J4"
> artifacts. I've been pulling them out of "-all" and zipping them up
> nonindependent. The J4 artifact might be problematic since we also
> need to run the backport utility, though I've heard there might be a
> plugin for that too.
Do you mean the retrotranslator plugin?
>
> We're in desperate need of more Struts 2 release managers. I'm swamped
> this month, and I'll be very busy through the end of June. Unless
> someone else steps up, I'm afraid the S2 releases will grind to a
> halt.
Once Tiles 2.0.3 gets release I can help, is being a simple committer
enough to make releases?
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: PROPOSAL: s1 modules module
Posted by Ted Husted <hu...@apache.org>.
On 4/23/07, Antonio Petrelli <an...@gmail.com> wrote:
> Probably because making releases is (or better "was") a painful
> operation. What if with 2 mere commands you created a release?
The Struts 2 process is documented here:
* http://struts.apache.org/2.0.6/docs/creating-and-signing-a-distribution.html
I wouldn't call it painful, but it still "stings" a bit.
I know Wendy has mentioned using the release plugin, but I'm not clear
on what changes that would make to the workflow.
One missing step is that we aren't generating "docs" or "J4"
artifacts. I've been pulling them out of "-all" and zipping them up
nonindependent. The J4 artifact might be problematic since we also
need to run the backport utility, though I've heard there might be a
plugin for that too.
We're in desperate need of more Struts 2 release managers. I'm swamped
this month, and I'll be very busy through the end of June. Unless
someone else steps up, I'm afraid the S2 releases will grind to a
halt.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: PROPOSAL: s1 modules module
Posted by Antonio Petrelli <an...@gmail.com>.
2007/4/22, Ted Husted <hu...@apache.org>:
> On 4/22/07, Antonio Petrelli <an...@gmail.com> wrote:
> > If all integrations were projects on themselves, this would not happen.
> > This is due probably to the fact that Struts 2 did not use the Maven
> > release plugin, and I think that we need to use it since it forces us
> > to follow the correct way of doing releases.
>
> In Struts 1, we tried breaking it down and giving each major artificat
> its own release series, but people complained that it made the release
> process too complex, and there would be too much bookkeeping in
> keeping track of which plugin release went with which core release.
Did they use the Maven release plugin? We used at Tiles 2 and
everything is much easier. If it is a question of configuring the
poms, I can help.
> If we had a line of volunteers eagerly waiting their turn to do a
> release, it might be different. But, right now, we have almost no
> volunteers willing to create releases, rightly or wrongly.
Probably because making releases is (or better "was") a painful
operation. What if with 2 mere commands you created a release?
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: PROPOSAL: s1 modules module
Posted by Ted Husted <hu...@apache.org>.
On 4/22/07, Antonio Petrelli <an...@gmail.com> wrote:
> If all integrations were projects on themselves, this would not happen.
> This is due probably to the fact that Struts 2 did not use the Maven
> release plugin, and I think that we need to use it since it forces us
> to follow the correct way of doing releases.
In Struts 1, we tried breaking it down and giving each major artificat
its own release series, but people complained that it made the release
process too complex, and there would be too much bookkeeping in
keeping track of which plugin release went with which core release.
So, we decided to lump everything together, Spring-style.
If we had a line of volunteers eagerly waiting their turn to do a
release, it might be different. But, right now, we have almost no
volunteers willing to create releases, rightly or wrongly.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: PROPOSAL: s1 modules module
Posted by Antonio Petrelli <an...@gmail.com>.
2007/4/21, Paul Benedict <pb...@apache.org>:
> I am proposing a new module for Struts 1.x called "modules" which would
> contain integration classes into popular open source libraries. For
> starters, it would contain a new command to let Spring wire up the CRP
> using a command.
Sorry for jumping in too late, but I think that this is not the right
path to follow.
I hoped that, for each integration "module" a new project is created.
Since each integration project is independent from the core of Struts
1, can have its version management and its snapshot dependencies.
What I mean is that releasing the Struts 1 core must not depend on the
stability of its plugins/integrations. And since the Maven release
plugin does not accept a snapshot dependency of any kind, this would
mean that we cannot release Struts 1 until all of its integration
modules reach a certain amount of stability.
I am writing this because in Struts 2 there was some sort of "snapshot
hell" with lots of snapshots dependencies (including Tiles
2.0-SNAPSHOT!) that were released as GA. Almost surely the Struts 2
core is GA, but at least Tiles 2 integration is not.
If all integrations were projects on themselves, this would not happen.
This is due probably to the fact that Struts 2 did not use the Maven
release plugin, and I think that we need to use it since it forces us
to follow the correct way of doing releases.
Just my 2 eurocents
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: PROPOSAL: s1 modules module
Posted by Paul Benedict <pb...@apache.org>.
I am fine either way. Thanks for "explain"-ing :-)
On 4/21/07, Martin Cooper <ma...@apache.org> wrote:
>
> I'll assume that "explain" was intended between "you" and "your". ;-)
>
> In response to Wendy's question, you indicated that you are proposing one
> jar that includes the integration for multiple external libraries. If I
> want
> integration with Spring, for example, and not the other external
> libraries,
> Maven isn't going to help me. In my example from before, I need 1/6th of
> the
> integration jar, but I have to take the other 5/6ths of it as well. That
> 5/6ths is baggage that I don't want or need.
>
> --
> Martin Cooper
>
>
> On 4/21/07, Paul Benedict <pb...@apache.org> wrote:
> >
> > Martin,
> >
> > Point taken on the module naming: "integration" is better.
> >
> > Can you your focus on the "baggage"? With maven 2, dependencies can be
> > marked as optional. They all have to be there when compiling the source,
> > but
> > not when depending on the library.
> >
> > Paul
> >
> > On 4/21/07, Martin Cooper <ma...@apache.org> wrote:
> > >
> > > First off, calling this "modules" would be very confusing, since
> Struts
> > 1
> > > already has a concept of modules that is not at all related to what
> you
> > > are
> > > looking to create. Since the purpose is integration with other
> > libraries,
> > > I
> > > would suggest "integration".
> > >
> > > Second, I would strongly recommend against creating one
> all-encompassing
> > > jar
> > > file. The problem with that approach is that almost every user will be
> > > carrying around baggage that they don't want or need. If we provide
> > > integration with a half dozen other libraries, the chances are that
> any
> > > given developer will need at most one of them. That leaves 5/6 of the
> > jar
> > > as
> > > baggage.
> > >
> > > I like Wendy's suggestion - start with one struts-spring jar and see
> how
> > > that works out.
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > > On 4/21/07, Paul Benedict <pb...@apache.org> wrote:
> > > >
> > > > Wendy, I was thinking of the first.
> > > >
> > > > On 4/21/07, Wendy Smoak <ws...@gmail.com> wrote:
> > > > >
> > > > > On 4/21/07, Paul Benedict <pb...@apache.org> wrote:
> > > > >
> > > > > > I am proposing a new module for Struts 1.x called "modules"
> which
> > > > would
> > > > > > contain integration classes into popular open source libraries.
> > For
> > > > > > starters, it would contain a new command to let Spring wire up
> the
> > > CRP
> > > > > > using a command.
> > > > >
> > > > > I would suggest adding one new module called struts-spring, and
> see
> > > > > how things go from there.
> > > > >
> > > > > (It's not clear to me whether you want to add a jar called
> > > > > "struts-modules" which would have integration code with Spring and
> > > > > other third-party libraries, or whether "modules" is intended to
> be
> > a
> > > > > directory structure like "plugins" in the s2 build.)
> > > > >
> > > > > --
> > > > > Wendy
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: PROPOSAL: s1 modules module
Posted by Martin Cooper <ma...@apache.org>.
I'll assume that "explain" was intended between "you" and "your". ;-)
In response to Wendy's question, you indicated that you are proposing one
jar that includes the integration for multiple external libraries. If I want
integration with Spring, for example, and not the other external libraries,
Maven isn't going to help me. In my example from before, I need 1/6th of the
integration jar, but I have to take the other 5/6ths of it as well. That
5/6ths is baggage that I don't want or need.
--
Martin Cooper
On 4/21/07, Paul Benedict <pb...@apache.org> wrote:
>
> Martin,
>
> Point taken on the module naming: "integration" is better.
>
> Can you your focus on the "baggage"? With maven 2, dependencies can be
> marked as optional. They all have to be there when compiling the source,
> but
> not when depending on the library.
>
> Paul
>
> On 4/21/07, Martin Cooper <ma...@apache.org> wrote:
> >
> > First off, calling this "modules" would be very confusing, since Struts
> 1
> > already has a concept of modules that is not at all related to what you
> > are
> > looking to create. Since the purpose is integration with other
> libraries,
> > I
> > would suggest "integration".
> >
> > Second, I would strongly recommend against creating one all-encompassing
> > jar
> > file. The problem with that approach is that almost every user will be
> > carrying around baggage that they don't want or need. If we provide
> > integration with a half dozen other libraries, the chances are that any
> > given developer will need at most one of them. That leaves 5/6 of the
> jar
> > as
> > baggage.
> >
> > I like Wendy's suggestion - start with one struts-spring jar and see how
> > that works out.
> >
> > --
> > Martin Cooper
> >
> >
> > On 4/21/07, Paul Benedict <pb...@apache.org> wrote:
> > >
> > > Wendy, I was thinking of the first.
> > >
> > > On 4/21/07, Wendy Smoak <ws...@gmail.com> wrote:
> > > >
> > > > On 4/21/07, Paul Benedict <pb...@apache.org> wrote:
> > > >
> > > > > I am proposing a new module for Struts 1.x called "modules" which
> > > would
> > > > > contain integration classes into popular open source libraries.
> For
> > > > > starters, it would contain a new command to let Spring wire up the
> > CRP
> > > > > using a command.
> > > >
> > > > I would suggest adding one new module called struts-spring, and see
> > > > how things go from there.
> > > >
> > > > (It's not clear to me whether you want to add a jar called
> > > > "struts-modules" which would have integration code with Spring and
> > > > other third-party libraries, or whether "modules" is intended to be
> a
> > > > directory structure like "plugins" in the s2 build.)
> > > >
> > > > --
> > > > Wendy
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > >
> > > >
> > >
> >
>
Re: PROPOSAL: s1 modules module
Posted by Paul Benedict <pb...@apache.org>.
Martin,
Point taken on the module naming: "integration" is better.
Can you your focus on the "baggage"? With maven 2, dependencies can be
marked as optional. They all have to be there when compiling the source, but
not when depending on the library.
Paul
On 4/21/07, Martin Cooper <ma...@apache.org> wrote:
>
> First off, calling this "modules" would be very confusing, since Struts 1
> already has a concept of modules that is not at all related to what you
> are
> looking to create. Since the purpose is integration with other libraries,
> I
> would suggest "integration".
>
> Second, I would strongly recommend against creating one all-encompassing
> jar
> file. The problem with that approach is that almost every user will be
> carrying around baggage that they don't want or need. If we provide
> integration with a half dozen other libraries, the chances are that any
> given developer will need at most one of them. That leaves 5/6 of the jar
> as
> baggage.
>
> I like Wendy's suggestion - start with one struts-spring jar and see how
> that works out.
>
> --
> Martin Cooper
>
>
> On 4/21/07, Paul Benedict <pb...@apache.org> wrote:
> >
> > Wendy, I was thinking of the first.
> >
> > On 4/21/07, Wendy Smoak <ws...@gmail.com> wrote:
> > >
> > > On 4/21/07, Paul Benedict <pb...@apache.org> wrote:
> > >
> > > > I am proposing a new module for Struts 1.x called "modules" which
> > would
> > > > contain integration classes into popular open source libraries. For
> > > > starters, it would contain a new command to let Spring wire up the
> CRP
> > > > using a command.
> > >
> > > I would suggest adding one new module called struts-spring, and see
> > > how things go from there.
> > >
> > > (It's not clear to me whether you want to add a jar called
> > > "struts-modules" which would have integration code with Spring and
> > > other third-party libraries, or whether "modules" is intended to be a
> > > directory structure like "plugins" in the s2 build.)
> > >
> > > --
> > > Wendy
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
>
Re: PROPOSAL: s1 modules module
Posted by Martin Cooper <ma...@apache.org>.
First off, calling this "modules" would be very confusing, since Struts 1
already has a concept of modules that is not at all related to what you are
looking to create. Since the purpose is integration with other libraries, I
would suggest "integration".
Second, I would strongly recommend against creating one all-encompassing jar
file. The problem with that approach is that almost every user will be
carrying around baggage that they don't want or need. If we provide
integration with a half dozen other libraries, the chances are that any
given developer will need at most one of them. That leaves 5/6 of the jar as
baggage.
I like Wendy's suggestion - start with one struts-spring jar and see how
that works out.
--
Martin Cooper
On 4/21/07, Paul Benedict <pb...@apache.org> wrote:
>
> Wendy, I was thinking of the first.
>
> On 4/21/07, Wendy Smoak <ws...@gmail.com> wrote:
> >
> > On 4/21/07, Paul Benedict <pb...@apache.org> wrote:
> >
> > > I am proposing a new module for Struts 1.x called "modules" which
> would
> > > contain integration classes into popular open source libraries. For
> > > starters, it would contain a new command to let Spring wire up the CRP
> > > using a command.
> >
> > I would suggest adding one new module called struts-spring, and see
> > how things go from there.
> >
> > (It's not clear to me whether you want to add a jar called
> > "struts-modules" which would have integration code with Spring and
> > other third-party libraries, or whether "modules" is intended to be a
> > directory structure like "plugins" in the s2 build.)
> >
> > --
> > Wendy
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
Re: PROPOSAL: s1 modules module
Posted by Paul Benedict <pb...@apache.org>.
Wendy, I was thinking of the first.
On 4/21/07, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 4/21/07, Paul Benedict <pb...@apache.org> wrote:
>
> > I am proposing a new module for Struts 1.x called "modules" which would
> > contain integration classes into popular open source libraries. For
> > starters, it would contain a new command to let Spring wire up the CRP
> > using a command.
>
> I would suggest adding one new module called struts-spring, and see
> how things go from there.
>
> (It's not clear to me whether you want to add a jar called
> "struts-modules" which would have integration code with Spring and
> other third-party libraries, or whether "modules" is intended to be a
> directory structure like "plugins" in the s2 build.)
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: PROPOSAL: s1 modules module
Posted by Wendy Smoak <ws...@gmail.com>.
On 4/21/07, Paul Benedict <pb...@apache.org> wrote:
> I am proposing a new module for Struts 1.x called "modules" which would
> contain integration classes into popular open source libraries. For
> starters, it would contain a new command to let Spring wire up the CRP
> using a command.
I would suggest adding one new module called struts-spring, and see
how things go from there.
(It's not clear to me whether you want to add a jar called
"struts-modules" which would have integration code with Spring and
other third-party libraries, or whether "modules" is intended to be a
directory structure like "plugins" in the s2 build.)
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org