From: Craig McClanahan [EMAIL PROTECTED]
Craig wrote:
There was talk on some thread or another ... hmm, I seem to
remember a certain advocate for a compromise position :-) ... that you
could have it both ways by simply generating a build.xml file from
Maven.
I advocated for both... but not
Do you think the Maven developers can be convinced to make this the
default behavior for generated build.xml files? It isn't at the
moment. Case in point ... I generate nightly builds for a large
number of Jakarta Commons (and Commons Sandbox) projects. The
standard execution path for my
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35895.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
In keeping with the Maven-or-Ant thread, it's time to think about switching
to the Maven-generated multi-project website. James has had the basic
Maven-generated site available for a while now with the nightly builds.
I made a start on integrating the existing site with Maven's, and posted the
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36096.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36096.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
btw. I just looked at the binary jar file (after runing maven; not ant) and saw,
that there is no o.a.t.resources *folder* inside.
in $SRC the XmlParser.java says:
protected String registrations[] = {
-//Apache Software Foundation//DTD Tiles Configuration 1.1//EN,
On 8/8/05, James Mitchell [EMAIL PROTECTED] wrote:
Very well said Ted. I was initially opposed to moving Struts over to Maven
(way back when) more out of the frustration of having to learn another tool.
While there is not (and probably never will be) a standard for build tools,
with enough
Although access to the other components by navigating the component
tree is guaranteed to work, I take your point that it makes the logic
of this check type validator more fragile. Here's a technique to
consider that might alleviate the issue somewhat:
Yes that was my point. Wouldn't you
On Aug 8, 2005, at 8:18 PM, Wendy Smoak wrote:
Both is also an option. :) There is already a Maven build for
Standalone Tiles-- it came over from struts-tiles when the files were
copied, and it works. The project.xml file needs a few changes-- I'll
check them in if no one minds.
In the
Frank W. Zammetti said:
* StrictDuplicateCode
Duplicate code is just plain bad... not in terms of something not
working, although that is certainly possible in some
situations, but
it's just a sign of carelessness. If nothing else, I'm sure no one
wants the Struts code base to
On Tue, August 9, 2005 1:04 am, Martin Cooper said:
You forgot FindBugs. It really does find bugs. ;-)
Your right, I did :) My builds at work do include it actually.
Checkstyle is run from Maven, so whether or not we move to Checkstyle
3.5 right now depends on whether or not the Maven
* PackageDeclaration
This is almost a silly check frankly, but again, no harm no foul.
Yes, this is silly. If Struts committers are checking in classes with
no package declaration, then I think we have bigger problems. ;-)
Such as it won't work on a JDK 1.4 platform :-)
No need to
Thanks for the heads-up... I didn't look to see what the complaints were
actually flagging... your right, rules like that definitely shouldn't be
enabled if that's the kind of thing it is going to catch... and that one
doesn't look configurable enough to get rid of those, and I certainly
don't
Ted-
You're exactly right about not being able to turn on a dime. At my
current client, the team I work with has been doing struts for about 1
1/2 years and have made an investment in tools and training. It would
be difficult (aka politicial suicide) for someone to suggest turning
the ship around
Thanks for all the hard work Wendy. This looks great!
Do you know how that affects the generation of the tld files? Or is it a
non-issue (meaning that hasn't changed)
I am +1 for moving over to this approach. My +1 also means that I am
willing to help (which I guess I sort of already have
Agreed, this looks great! Not knowing much about Maven, I wasn't sure
what would happen to the user guide and other such docs. Now I see I
don't need to worry about those. Good work!
Hubert
On 8/9/05, James Mitchell [EMAIL PROTECTED] wrote:
Thanks for all the hard work Wendy. This looks
At 11:04 PM -0400 8/8/05, Sean Schofield wrote:
How is Maven with deploying to Tomcat? I've always found that part of
Ant to be a bit cumbersome. If cactus is much easier, it sounds like
your Tomcat experience in general is much easier. Is that true? What
about support for other app servers?
I would very much like to see this duplicated code feature improved. I think
it goes along with good refactoring so if it worked well it would be really
helpful. I see way too much duplicated code in the code reviews I have to do.
--
The only problem with doing it right the first time is that
Good stuff! I was fiddling around with trying to generate the site
with Maven a while ago, but I think I was trying to kill too many
birds with the same stone, so to speak. Tackling it as you have seems
like a more expedient approach.
I do have the same question as James, though: Can we still
On 8/9/05, Sean Schofield [EMAIL PROTECTED] wrote:
Although access to the other components by navigating the component
tree is guaranteed to work, I take your point that it makes the logic
of this check type validator more fragile. Here's a technique to
consider that might alleviate the
On 8/8/05, Phil Steitz [EMAIL PROTECTED] wrote:
Do you think the Maven developers can be convinced to make this the
default behavior for generated build.xml files? It isn't at the
moment. Case in point ... I generate nightly builds for a large
number of Jakarta Commons (and Commons
I do have the same question as James, though: Can we still generate
the TLDs from the same XML as the taglib docs? This is one place that
I got bogged down, since it seemed that Maven wouldn't take the extra
XML elements, and I would absolutely hate to lose the guaranteed
synchronisation we get
On 8/9/05, Joe Germuska [EMAIL PROTECTED] wrote:
I do have the same question as James, though: Can we still generate
the TLDs from the same XML as the taglib docs? This is one place that
I got bogged down, since it seemed that Maven wouldn't take the extra
XML elements, and I would absolutely
From: Martin Cooper [EMAIL PROTECTED]
Another thing I was trying to tackle - which, in retrospect, was much
too big to do in one chunk, let alone with everything else too - was
creating a completely generic main site that hands off to the
sub-project sites, where the main site doesn't get into
From: James Mitchell [EMAIL PROTECTED]
Do you know how that affects the generation of the tld files? Or is it a
non-issue (meaning that hasn't changed)
I don't know yet. I noticed that the html taglib docs are missing from the
test site, and it's on the list to check out. (The tlds have
Both sounds good to me too. If nobody objects, that's what we'll do.
david
Le 05-08-08 à 19:59, Craig McClanahan a écrit :
On 8/8/05, Wendy Smoak [EMAIL PROTECTED] wrote:
From: David Geary [EMAIL PROTECTED]
I'm +1 for ANT. I agree with Joe's comment, but standalone Tiles
is not
part
My client is currently with a global bank. How could can Maven help
with project dependencies? What are the win-wins here?
When I last looked at Maven, it looked like complete C++/C Macro
nonsense. I did NOT get it all. So what gives?
Does the Struts SVN has a full MAVEN build now? When I
-Original Message-
From: Sean Schofield [mailto:[EMAIL PROTECTED]
====
I do see the dependency advantage but as Craig mentioned, Maven isn't
the only way to manage this.
James figured out a nifty way to handle this through a
download-dependencies target in ant. He showed me
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36107.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
+1 for me to.
A few notes might be:
* The Download links could point to anchors on the Acquiring page, to
provide a single gateway.
* In the end, I expect we would have a single Subprojects or Projects
section, instead of two. For subproject labels, I would suggest
dropping Struts as
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36107.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35127.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Author: mrdon
Date: Tue Aug 9 20:27:15 2005
New Revision: 231158
URL: http://svn.apache.org/viewcvs?rev=231158view=rev
Log:
* Adding form scoping
* Adding form create chain
* Adding action execution chain
Added:
struts/sandbox/trunk/ti/src/java/org/apache/ti/processor/InvokeAction.java
Author: mrdon
Date: Tue Aug 9 20:47:32 2005
New Revision: 231161
URL: http://svn.apache.org/viewcvs?rev=231161view=rev
Log:
* Fixed dumb compile error
* Fixed bad velocity syntax
Modified:
struts/sandbox/trunk/ti/src/java/org/apache/ti/config/xdocletToXWork.vm
Author: mrdon
Date: Tue Aug 9 21:24:37 2005
New Revision: 231166
URL: http://svn.apache.org/viewcvs?rev=231166view=rev
Log:
* Adding unit tests for form scope handling
* Fixing small errors to get form scope to work correctly
Added:
36 matches
Mail list logo
