On 4/29/07, Paul Benedict <[EMAIL PROTECTED]> 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?
A
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 cl
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) wha
2007/4/23, Ted Husted <[EMAIL PROTECTED]>:
On 4/23/07, Antonio Petrelli <[EMAIL PROTECTED]> 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.o
On 4/23/07, Antonio Petrelli <[EMAIL PROTECTED]> 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-distribut
On 4/23/07, Antonio Petrelli <[EMAIL PROTECTED]> 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-
2007/4/23, Paul Benedict <[EMAIL PROTECTED]>:
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 assem
2007/4/22, Ted Husted <[EMAIL PROTECTED]>:
On 4/22/07, Antonio Petrelli <[EMAIL PROTECTED]> 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
On 4/22/07, Ted Husted <[EMAIL PROTECTED]> wrote:
On 4/22/07, Antonio Petrelli <[EMAIL PROTECTED]> 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
On 4/22/07, Antonio Petrelli <[EMAIL PROTECTED]> 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 d
On 4/22/07, Paul Benedict <[EMAIL PROTECTED]> 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
2007/4/21, Paul Benedict <[EMAIL PROTECTED]>:
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
On 4/21/07, Ted Husted <[EMAIL PROTECTED]> 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 initia
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)
I am fine either way. Thanks for "explain"-ing :-)
On 4/21/07, Martin Cooper <[EMAIL PROTECTED]> 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
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,
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 <[EMAIL PROTE
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
Wendy, I was thinking of the first.
On 4/21/07, Wendy Smoak <[EMAIL PROTECTED]> wrote:
On 4/21/07, Paul Benedict <[EMAIL PROTECTED]> 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
On 4/21/07, Paul Benedict <[EMAIL PROTECTED]> 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 sugge
20 matches
Mail list logo
