We should use jarjar: http://tonicsystems.com/products/jarjar/
Bob
On 6/13/06, Don Brown [EMAIL PROTECTED] wrote:
What about doing what Sun does with Xalan for Java 5 and rename XWork
packages? With the changes we are making to XWork 2.0, I don't think
it will co-exist with WebWork 2.2.2/3
Very tempting if it wasn't GPL :(
Don
Bob Lee wrote:
We should use jarjar: http://tonicsystems.com/products/jarjar/
Bob
On 6/13/06, Don Brown [EMAIL PROTECTED] wrote:
What about doing what Sun does with Xalan for Java 5 and rename XWork
packages? With the changes we are making to XWork
It's a tool though, so it won't be distrubuted. If it's a big issue,
I'm sure we can talk Chris into something. Chris?
Bob
On 6/13/06, Don Brown [EMAIL PROTECTED] wrote:
Very tempting if it wasn't GPL :(
Don
Bob Lee wrote:
We should use jarjar: http://tonicsystems.com/products/jarjar/
Bob
Greg Reddin ha scritto:
Of the attributes that are currently supported by InsertTag, I believe
the following are redundant:
1) attribute, definition, name could all be resolved to name.
...
In addition the name attribute can be interpreted as either a pointer
to a Tiles definition or
Antonio Petrelli ha scritto:
Maybe an optional type attribute could be used to distinguish
between attribute and name
Errata corrige: I meant to distinguish between attribute and definition
-
To unsubscribe, e-mail: [EMAIL
I'm not sure how easy it would be to change the license, but that really
shouldn't be necessary. As you say it is just a build tool so there is no
need to distribute the source, or even have the source checked in. I did a
few quick searches and found:
ASF projects can use GPL/LGPL code during
On 6/14/06, Don Brown [EMAIL PROTECTED] wrote:
Theoretically, I agree with you. However, pushing a project through
Incubation takes a lot of work, and we are already stretched trying to
get a stable Action 2 release out. In order to meet our August target,
we have to get the feature scope
Would you care if we use this ticket for all Struts projects?
(Action 1.2.x, 1.3.x, 2.0.x, Shale, and Tiles)
Sean and I are meeting today for our mini hackathon and it might be a
good idea to keep all of these together.
--
James Mitchell
On Jun 14, 2006, at 7:29 AM, Ted Husted (JIRA)
Would you consider some kind of compatibility mode? That is, before
you remove support for these, could there be a way for people to
configure things for a more strict or more compatible evaluation, to
ease migration? It seems like the closest you can get to deprecation
warnings in tag
On Jun 14, 2006, at 2:09 AM, Antonio Petrelli wrote:
Greg Reddin ha scritto:
Of the attributes that are currently supported by InsertTag, I
believe the following are redundant:
1) attribute, definition, name could all be resolved to name.
...
In addition the name attribute can be
I like the idea. I've always felt tiles was more complicated than
necessary. Simplify it. Antonio's question is a good one. The
lookup order needs to be well documented and a
type=definition|attribute attribute would probably need to be
available to override the standard lookup procedure.
On
I stated to do that, and then realized that might be confusing, since
we have a JIRA project for each subproject.
Do we want to setup an INFRA or SITE project?
-Ted.
On 6/14/06, James Mitchell [EMAIL PROTECTED] wrote:
Would you care if we use this ticket for all Struts projects?
(Action
Is this really an issue? If users are running WW2.2 with Struts2
everything should be fine, so this case will be only when running WW2.0
or WW1 with Struts2 - correct? And it would only be a problem when
running in the same web application (and thus same class loader).
I'll probably get
Is this really an issue? If users are running WW2.2
with Struts2
everything should be fine, so this case will be only
when running WW2.0
or WW1 with Struts2 - correct? And it would only be
a problem when
running in the same web application (and thus same
class loader).
I'll
Greg Reddin asked:
I'm not really sure what the use of the beanName and beanProperty
values are, so if someone wants to enlighten me on that, I'd
appreciate it.
I would guess that's just to get the tile name from a bean property.
With the availability of EL, that seems like an unnecessary
On Jun 14, 2006, at 9:32 AM, [EMAIL PROTECTED] wrote:
Greg Reddin asked:
I'm not really sure what the use of the beanName and beanProperty
values are, so if someone wants to enlighten me on that, I'd
appreciate it.
I would guess that's just to get the tile name from a bean property.
With
On 6/14/06, Joe Germuska [EMAIL PROTECTED] wrote:
Would you consider some kind of compatibility mode? That is, before
you remove support for these, could there be a way for people to
configure things for a more strict or more compatible evaluation, to
ease migration? It seems like the closest
On Jun 14, 2006, at 11:00 AM, Wendy Smoak wrote:
On 6/14/06, Joe Germuska [EMAIL PROTECTED] wrote:
Would you consider some kind of compatibility mode? That is, before
you remove support for these, could there be a way for people to
configure things for a more strict or more compatible
At 9:00 AM -0700 6/14/06, Wendy Smoak wrote:
On 6/14/06, Joe Germuska [EMAIL PROTECTED] wrote:
Would you consider some kind of compatibility mode? That is, before
you remove support for these, could there be a way for people to
configure things for a more strict or more compatible evaluation,
On Jun 14, 2006, at 11:21 AM, Joe Germuska wrote:
At 9:00 AM -0700 6/14/06, Wendy Smoak wrote:
On 6/14/06, Joe Germuska [EMAIL PROTECTED] wrote:
Would you consider some kind of compatibility mode? That is, before
you remove support for these, could there be a way for people to
configure
Sean, this has been released. Please change the version to 3-SNAPSHOT.
(We need to add the new committers and release it again anyway.)
--
Wendy
On 6/14/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: schof
Date: Wed Jun 14 09:44:06 2006
New Revision: 414316
URL:
Don't forget to associate a JIRA ticket with each commit to make it easier to
track changes in a release... :)
Thanks,
Don
[EMAIL PROTECTED] wrote:
Author: tmjee
Date: Wed Jun 14 06:48:08 2006
New Revision: 414249
URL: http://svn.apache.org/viewvc?rev=414249view=rev
Log:
- added javadoc
I'm fine with combining the tasks as long as they are all resolved in one fell
swoop. Considering we generally have little spare time to work on open source
projects, I'd like to see tickets at a level of granularity that it only
requires a few hours to resolve them, avoiding the basically
By using ISO date format -mm-dd HH:mm:ss Struts/Apache can
promote international standards including unambiguous 24-hour format
for time.
For example, the home page of Struts project [1] has the following
subheader: Last Published: 06/11/2006. Should be Last Published:
2006-06-11.
Yes. There is a wiki page for this as well.
http://wiki.apache.org/struts/StrutsContinuum
It's a work in progress, and I'm about to head out, but I'd like to
ask Wendy a few questions wrt pom, parent-pom, snapshot vs. released,
etc, etc.
Back in a bit.
--
James Mitchell
On Jun 14,
If that is the case, then jarjar seems to be a great solution. Anyone know if
it has a Maven 2 plugin?
Don
Chris Nokleberg wrote:
I'm not sure how easy it would be to change the license, but that really
shouldn't be necessary. As you say it is just a build tool so there is no
need to
Okie dokie. Thx for the reminder.
Do we need to create a jira issue even if its just changing some javadoc, like
typo or snippet id is wrongly assigned etc.?
regards.
- Original Message
From: Don Brown [EMAIL PROTECTED]
To: dev@struts.apache.org
Sent: Thursday, 15 June, 2006 1:16:48
Hi,
The problem is that these things were designed before the
IOC/Dependency Injection design patterns had really infected the minds
of open source architects, and there was no standard way to have a
framework discover implementations of various interfaces. Add that
to the fact that no one
Well, if we really are going to require a JIRA ticket for each commit, I guess
we'd have to open up a couple general purpose Javadoc/typo fix tickets, as much
as I hate open ended tickets.
What do the rest of you think?
Don
tm jee wrote:
Okie dokie. Thx for the reminder.
Do we need to
We have a ticket up for the current round of documentation updates
[WW-1340] so you can use that.
-Ted.
On 6/14/06, tm jee [EMAIL PROTECTED] wrote:
Okie dokie. Thx for the reminder.
Do we need to create a jira issue even if its just changing some javadoc, like
typo or snippet id is wrongly
Do we need to create a jira issue even if its just changing some javadoc, like
typo or snippet id is wrongly assigned etc.?
IMO that's overkill.
Sean
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
I went ahead and setup a SITE project in JIRA where we can log issues
with the Site subproject along with the Maven builds, Continuum, et
cetera, and added a ticket for Minihachathon James mentioned.
* http://issues.apache.org/struts/browse/SITE-1
and made setting up the SAF2 nightly a subtask
That makes sense too. I guess the big draw for everything a JIRA ticket is it
is easier to create the release notes. If you are just fixing a typo, that
probably wouldn't go in the release notes anyways.
Don
Sean Schofield wrote:
Going back to my point about overkill. If you have a
On 6/14/06, Don Brown [EMAIL PROTECTED] wrote:
That makes sense too. I guess the big draw for everything a JIRA ticket
is it
is easier to create the release notes. If you are just fixing a typo,
that
probably wouldn't go in the release notes anyways.
That's exactly the standard I like to
I can't comment on how people are actually using it, but changing the
request processor workflow on a per module basis is quite easy with
Struts 1.2. Assuming that this is something which some people are doing,
then it would seem to make sense to support this for Struts 1.3 as well,
at least
At 9:09 PM +0100 6/14/06, Phil Zoio wrote:
I can't comment on how people are actually using it, but changing
the request processor workflow on a per module basis is quite easy
with Struts 1.2. Assuming that this is something which some people
are doing, then it would seem to make sense to
I don't think JarJar fixes the root problem: 2 API level incompatible libraries
(Xwork 1.x and Xwork 2.x) with the same packages. Just because we fix it for
SAF2 doesn't fix it for anyone else that wants to use XWork 2 and WebWork 2.x
separately.
How about one for the milestone itself?
* http://issues.apache.org/struts/browse/WW-1349
Though, in the case of SAF 2.0.0, I'd prefer that anything releated to
Javadocs or the wiki be related to WW-1340, since there will be more
changes than usual.
-Ted.
On 6/14/06, Don Brown [EMAIL
Joe Germuska wrote:
At 9:09 PM +0100 6/14/06, Phil Zoio wrote:
I can't comment on how people are actually using it, but changing the
request processor workflow on a per module basis is quite easy with
Struts 1.2. Assuming that this is something which some people are
doing, then it would
On 6/14/06, Don Brown [EMAIL PROTECTED] wrote:
Considering we generally have little spare time to work on open source
projects, I'd like to see tickets at a level of granularity that it only
requires a few hours to resolve them, avoiding the basically unresolvable
tickets like Struts Action 1
No one is going to argue with that, Michael. Just make it so.
-Ted.
On 6/14/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
By using ISO date format -mm-dd HH:mm:ss Struts/Apache can
promote international standards including unambiguous 24-hour format
for time.
For example, the home page
thx for the feedback guys.
Just to sum up, we'll use
WW-1349 - issues related to milestone
WW-1340 - javadocs wiki snippet related (including adding comments and debug
statement s in code)
Cheers. :-)
- Original Message
From: Ted Husted [EMAIL PROTECTED]
To: Struts
On 6/14/06, tm jee [EMAIL PROTECTED] wrote:
Just to sum up, we'll use
WW-1349 - issues related to milestone
+ ... that -- for some reason -- don't have their own issue and are
too picayune to justify an issue
WW-1340 - javadocs wiki snippet related (including adding comments and debug
On 6/14/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: craigmcc
Date: Wed Jun 14 22:10:00 2006
New Revision: 414466
URL: http://svn.apache.org/viewvc?rev=414466view=rev
Log:
Add a new top-level assembly for the framework, inspired by Wendy's
version in shale-dist, but with a singularly
44 matches
Mail list logo
