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=414466&view=rev
Log:
Add a new top-level assembly for the framework, inspired by Wendy's
version in shale-dist, but with a singularl
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 debu
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 Devel
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 pag
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
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 seem
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 PROTECTE
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.
-
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 suppo
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 fo
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
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 complic
We should probably put this in a Jira ticket so it won't get lost.
Do you agree?
--
James Mitchell
On Jun 14, 2006, at 1:28 PM, Michael Jouravlev wrote:
By using ISO date format "-mm-dd HH:mm:ss" Struts/Apache can
promote international standards including unambiguous 24-hour format
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 o
Going back to my point about overkill. If you have a complicated
problem that cannot be summarized in a sentence or two, yes, then
definitely a JIRA issue is in order. But if its a bug that was not
reported by anyone and it was introduced in the current release cycle
(say a tweak to a Maven POM)
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, e-mail
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
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 crea
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
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
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 distribu
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, 2
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".
Anno
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 unre
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=414249&view=rev
Log:
- added javadoc & s
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: http://svn.apache.o
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 t
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: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 eval
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 closes
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 t
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 unnecessar
> 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'l
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 some
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 1.2.
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.
O
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 interpre
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 libs/J
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)
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 wra
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 th
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
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 attribu
43 matches
Mail list logo
