On Tue, 30 Sep 2003, Robert Leland wrote:
snip /
I prefer Maven because it provides builds, testing, QA tools, and site
generation in one tool.
The repository of binaries makes building a distribution or maven
enabled site as easy as typeing,
'maven' for new users.
Changing the look/skin is
Don Brown wrote:
Further, deciding between Forrest and Maven isn't an either/or situation.
There exists a Forrest plugin for Maven and it would be easy to integrate
Maven's reports into a Forrest site build.
.../
If we did decide to go with Forrest, I'm willing to convert the old site
over and
Hi,
I've got a number of issues that I'd like to raise regarding feature requests with
suggested fixes. Can someone inform me of the best way to go about this? I'd like
to know what the process is to suggesting, raising and fixing features and problems so
that they can be destined for the
To discuss whether a feature might be a good idea, you can post here.
Though, it can take several days before everyone weighs in. We're all
volunteers with real jobs. Many of us can only work on Struts on the
weekends.
To raise and fix issues, you can post tickets to Bugzilla. This is where
--- Ted Husted [EMAIL PROTECTED] wrote:
Don Brown wrote:
Further, deciding between Forrest and Maven isn't an either/or
situation.
There exists a Forrest plugin for Maven and it would be easy to
integrate
Maven's reports into a Forrest site build.
.../
If we did decide to go with
decloak/
(it's sad the number of lists I lurk on)
Just thought I'd throw in a few points..
- Forrest is *purely* a documentation tool. It is comparable to Maven's
xdoc plugin, not Maven itself. Compared to the xdoc plugin, it is
bigger, slower, more powerful. Running Forrest feels
David Graham wrote:
The Forrest features Don mentioned aren't significant to me and I'm
already familiar with Maven so I'm leaning towards Maven but I really
don't care as long as the build is as easy as maven jar or equivalent.
But please let's not try to maintain multiple build processes.
I
rleland 2003/10/01 08:07:57
Modified:conf/share validator-rules.xml
Log:
Bug reported to user list by Olivier Dutrieux
Update validator-rules.xml to reflect the fact that
the validate methods now take a ActionMessages
not ActionErrors.
Revision ChangesPath
1.42
rleland 2003/10/01 08:43:12
Modified:conf/share validator-rules.xml
Log:
Remove all javescript definitions except the 'required',
and default to the ones stored in commons-validator.
The 'required' was kept to prevent a regression
in functionality ityat is n the CVS version
- Original Message -
From: Ted Husted [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Tuesday, September 30, 2003 6:29 AM
Subject: Re: Reviving PageController (ViewController?) discussion?
Jing Zhou wrote:
- A well designed framework should not have overlapped
I'm trying to write a Command or set of Commands that will process a
Tiles definition to help complete the 1.x-compatible chained request
processor. I've got something working, but I would like some community
input before I submit it.
First, I created another subclass of
Don Brown wrote:
I know the discussion on whether to use Forrest or Maven to generate the
Struts website was a few weeks back, but unfortunately, at the time, I was
too busy to participate. I'd like to lay out a case for Forrest, not to
insist Struts uses it, but rather to make sure the decision
Hi gang,
Currently, the html:errors tag doesn't work well with
indexed properties, because it looks for an exact match on
the property name. So if you have an error in
petFish[3].species, you need to have:
html:errors property=petFish[3].species
I'd like to propose (and will implement if
Greg Reddin wrote:
I'm trying to write a Command or set of Commands that will process a
Tiles definition to help complete the 1.x-compatible chained request
processor. I've got something working, but I would like some
community input before I submit it.
First, I created another subclass of
Don,
I have one request and that is to leave the existing maven files
in place since they do currently generate a web site with the reports.
Craig R. McClanahan wrote:
Don Brown wrote:
I know the discussion on whether to use Forrest or Maven to generate the
Struts website was a few weeks
I belive I had reported in bugzzila multi row validation problme 2
years ago, as well as posts.
Here is the code I have been shiping for a long time with bP (writen by
Jose/Ben):
package com.fX.base;
/*
* MultiRowValidator.java
* by Ben Tomasini - original by Jose Quiteriono ?
* 12/10/2002
-Original Message-
From: James Turner [mailto:[EMAIL PROTECTED]
Hi gang,
Currently, the html:errors tag doesn't work well with
indexed properties, because it looks for an exact match on
the property name. So if you have an error in
petFish[3].species, you need to have:
--- Robert Leland [EMAIL PROTECTED] wrote:
Don,
I have one request and that is to leave the existing maven files
in place since they do currently generate a web site with the reports.
I must be confused with the several projects I'm working on. So, Maven is
already setup in Struts to
There's a conditional behavior use case in the existing code as well;
when validation fails, we want to redisplay the input form. Originally,
I modelled this command as a Chain that conditionally executed its child
commands, but that seemed a little hokey. Now, this command definition
says:
Don Brown wrote:
For example, currently, we have quite a few Struts extensions, example
applications, and related frameworks that I feel Struts could do a better
job of encouraging. Instead of requiring an extension developer to submit
a patch to bugzilla to change a description or add their
Greg Reddin wrote:
There's a conditional behavior use case in the existing code as
well; when validation fails, we want to redisplay the input form.
Originally, I modelled this command as a Chain that conditionally
executed its child commands, but that seemed a little hokey. Now,
this
I have to agree with David. Lets find one way to do it and make it simple,
if a build process can be. I have worked a little with Maven, and it seems
tobe simple. I am not knocking Forrest. I have not had a chance to look into
it. If that is more simple than Maven then I am all for it. Lets not
Chris Gastin wrote:
I have to agree with David. Lets find one way to do it and make it simple,
if a build process can be. I have worked a little with Maven, and it seems
tobe simple. I am not knocking Forrest. I have not had a chance to look into
it. If that is more simple than Maven then I am all
--- Ted Husted [EMAIL PROTECTED] wrote:
Chris Gastin wrote:
I have to agree with David. Lets find one way to do it and make it
simple,
if a build process can be. I have worked a little with Maven, and it
seems
tobe simple. I am not knocking Forrest. I have not had a chance to
look into
I've found that experimenting has worked a lot better once I started
doing it in the open :-).
Point taken :-) Here's what I have so far, most definitely to be
changed sometime soon.
Greg
/*
* $Header:
On Wed, 1 Oct 2003, David Graham wrote:
snip /
Rob mentioned something about Struts being setup for Maven already and I
asked for clarification. If that's true then I see no point in
complicating things with another build tool. Also, it seems that Maven in
some ways is a superset of Forrest
--- Don Brown [EMAIL PROTECTED] wrote:
On Wed, 1 Oct 2003, David Graham wrote:
snip /
Rob mentioned something about Struts being setup for Maven already and
I
asked for clarification. If that's true then I see no point in
complicating things with another build tool. Also, it seems that
The whole Maven idea came because we felt the build
process of ant struts-legacy was broken or needed some
serious work. If Don wants to put energy into redoing our site's look
and feel that then here is my +1. Just know we are still
left with the original problem.
-Rob
David Graham wrote:
--- Robert Leland [EMAIL PROTECTED] wrote:
Don,
I have one request and that is to leave the existing maven files
in place since they do currently generate a web site with the reports.
I must be confused with the several projects I'm working on. So, Maven is
already
Don:
I don't know much about Forrest, but I am starting to read up on it, where
possible. I am willing to throw some muscle work your way, just let me know
what I can do.
Chris Gastin
- Original Message -
From: Don Brown [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Robert Leland wrote:
The whole Maven idea came because we felt the build
process of ant struts-legacy was broken or needed some
serious work. If Don wants to put energy into redoing our site's look
and feel that then here is my +1. Just know we are still
left with the original problem.
Don Brown wrote:
Yes, this won't help our build at all. Until we get Maven running, there
are some options to bring some Maven features over to Ant. For example,
if we wanted to get rid of jars in our CVS, we could use something like
http://www.krysalis.org/ruper/ or
--- Ted Husted [EMAIL PROTECTED] wrote:
David Graham wrote:
Rob mentioned something about Struts being setup for Maven already and
I
asked for clarification. If that's true then I see no point in
complicating things with another build tool. Also, it seems that
Maven in
some ways is a
On Wed, 1 Oct 2003, Ted Husted wrote:
snip /
Ah, well, you see we don't have JARs in our CVS. That's one of the
reasons people have trouble building Struts at first. They have to go
off and snag all the JARs themselves. Though, it seems like ruper might
help in that regard.
Doh! I blocked
David Graham wrote:
--- Ted Husted [EMAIL PROTECTED] wrote:
David Graham wrote:
Rob mentioned something about Struts being setup for Maven already and
I
asked for clarification. If that's true then I see no point in
complicating things with another build tool. Also, it seems
Most of us have given (or at least hinted at) our opinions, so let's give a
show of hands:
Mavenization:
[X] +1 - I am in favor of using Maven for build/dist/test/etc.
[ ] +0 - I agree, but cannot help at this time.
[ ] -0 - I don't agree, but not enough to give a -1.
[ ] -1 - I am not in favor
I believe the question is not between maven and forrest, but rather
between Anakia/xdoc and forrest. It is entirely possible to even use all
the report output from Maven and include it in a forrest build of the
website. Default Maven uses the xdoc plugin. All forrest would be doing
is replacing
Maven: +1
Forrest: -0
Forrest plug-in: Possibly, but not yet.
I'm more interested in streamlining the build and I don't consider the
website production to be broken, so Forrest is not a big priority for me.
I'm not saying never, but I see Maven as more of a priority and would rather
wait and see
38 matches
Mail list logo