Ted, I'll work on the 2.0.8 tickets for now. I'd like to resolve
everything on the 'Struts 2.0.8 TODO' page.
Next, I'd like to step up and release 2.0.8. At this time, I'm not
sure about a time table. I'll post back as soon as the time frame is
set.
Personally, I'm winding down
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?
2007/4/26, Ted Husted [EMAIL PROTECTED]:
If we're not going on to 2.0.9, then the JIRA stuff is mainly done.
We'd just need to bulk-change whatever we don't close in 2.0.8 to
2.1.0.
Currently the Tiles 2 plugin depends on Tiles 2.0.1, but since Tiles
2.0.3 is going to be released (well in fact
If need be, we could also release a plugin separately. The JARs are
built separately, we just glom it all together as an administrative
convenience. If someone wanted to re-roll the Tiles plugin against a
new Tiles 2 build and call it release 2.0.8.1, that would be simple to
do.
On 4/26/07,
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 use
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 since
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
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:
*
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:
*
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 too
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 a
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
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
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 suggest
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, it
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
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
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
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 external
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),
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
21 matches
Mail list logo
