On Fri, 26 Mar 2004, Ted Husted wrote:
> On Thu, 25 Mar 2004 08:22:48 -0600, Joe Germuska wrote:
> > As I've been saying (a lot, it seems, lately) on struts-user, I
> > think there are legitimate Struts JSP tags like "html:messages"
> > that are not best replaced by JSTL. Any time Struts tools pu
Quoting "Peter A. Pilgrim" <[EMAIL PROTECTED]>:
> Craig R. McClanahan wrote:
> > Quoting "Peter A. Pilgrim" <[EMAIL PROTECTED]>:
> >
> >
> >>Joe Germuska wrote:
> >>
> > Whether the "classic" and "el" taglibs are one chunk or two isn't
>
>
> > hugely important to me either --
+1. Just keeping the functionality facts straight...
Quoting David Graham <[EMAIL PROTECTED]>:
>
> --- Kris Schneider <[EMAIL PROTECTED]> wrote:
> > Nope. does substring matching.
>
> IMO, any tag that does not interact with Struts' core resources should
> live in the Jakarta Taglibs project.
--- Kris Schneider <[EMAIL PROTECTED]> wrote:
> Nope. does substring matching.
IMO, any tag that does not interact with Struts' core resources should
live in the Jakarta Taglibs project. This allows non-Struts projects to
benefit from the functionality while freeing Struts to focus on its core
With JSTL 1.1 (JSP 2.0), you get a set of string manipulaton functions (which
Peter was referring to) that includes:
fn:contains(string, substring)
fn:startsWith(string, prefix)
fn:endsWith(string, suffix)
In addition, you also get a length function that operates on collections and
strings:
fn:l
You're right (as usual ;))
I was using the String taglib in addition to the JSTL 1.0 taglib to do
the test. (duh)
Although looking at it now.. there isnt any support for begin and ends
in that neither.
-Tim
Kris Schneider wrote:
Nope. does substring matching.
Quoting Tim Chen <[EMAIL PROTECT
Nope. does substring matching.
Quoting Tim Chen <[EMAIL PROTECTED]>:
> ...
> no equalivant in JSTL 1.0 but exists String functions in
> JSTL 1.1
> ...
>
> logic:match equivalent is :
> >>
> >>
> >>> Joe Germuska wrote:
> >>>
> > > Whether the "classic" and "el" taglibs are one chunk or
--- "Peter A. Pilgrim" <[EMAIL PROTECTED]> wrote:
> we need a simple tag lib action for JSP 1.2 and JSTL 1.0 to
> get
> the size of java.uitl.Collection until there is widespread
> support JSP 2.0 JSTL 1.1
The current proposal is for Struts 2.0 to be based on Servlet 2.4/JSP 2.0
so we don't n
...
no equalivant in JSTL 1.0 but exists String functions in
JSTL 1.1
...
logic:match equivalent is Craig R. McClanahan wrote:
Quoting "Peter A. Pilgrim" <[EMAIL PROTECTED]>:
Joe Germuska wrote:
> Whether the "classic" and "el" taglibs are one chunk or two isn't
hugely important to me eit
Craig R. McClanahan wrote:
Quoting "Peter A. Pilgrim" <[EMAIL PROTECTED]>:
Joe Germuska wrote:
> Whether the "classic" and "el" taglibs are one chunk or two isn't
hugely important to me either -- I would prefer that this decision be
made by developers who've done more work on that code to date
--- Ted Husted <[EMAIL PROTECTED]> wrote:
> On Thu, 25 Mar 2004 08:22:48 -0600, Joe Germuska wrote:
> > As I've been saying (a lot, it seems, lately) on struts-user, I
> > think there are legitimate Struts JSP tags like "html:messages"
> > that are not best replaced by JSTL. Any time Struts tools
On Thu, 25 Mar 2004 08:22:48 -0600, Joe Germuska wrote:
> As I've been saying (a lot, it seems, lately) on struts-user, I
> think there are legitimate Struts JSP tags like "html:messages"
> that are not best replaced by JSTL. Any time Struts tools put
> resources in special locations in request or
--- Arron Bates <[EMAIL PROTECTED]> wrote:
> > --- Joe Germuska <[EMAIL PROTECTED]> wrote:
> > > > > Whether the "classic" and "el" taglibs are one chunk or two
> isn't
> > > >> hugely important to me either -- I would prefer that this
> decision
> > > be
> > > >> made by developers who've done
> --- Joe Germuska <[EMAIL PROTECTED]> wrote:
> > > > Whether the "classic" and "el" taglibs are one chunk or two isn't
> > >> hugely important to me either -- I would prefer that this decision
> > be
> > >> made by developers who've done more work on that code to date.
> > >> However, I did fi
Quoting "Peter A. Pilgrim" <[EMAIL PROTECTED]>:
> Joe Germuska wrote:
> >> > Whether the "classic" and "el" taglibs are one chunk or two isn't
> >>
> >>> hugely important to me either -- I would prefer that this decision be
> >>> made by developers who've done more work on that code to date.
>
Joe Germuska wrote:
> Whether the "classic" and "el" taglibs are one chunk or two isn't
hugely important to me either -- I would prefer that this decision be
made by developers who've done more work on that code to date.
However, I did find that when I patched
o.a.s.t.html.JavascriptValidator
At 7:44 AM -0500 3/25/04, Ted Husted wrote:
On Tue, 23 Mar 2004 20:52:03 -0800 (PST), Martin Cooper wrote:
So, there are pros and cons both ways, of course. Now we just need
to make a decision and move on it. ;-
If all the deliverables are in a single module, is there a way that
we can generate
At 6:30 AM -0800 3/25/04, David Graham wrote:
Yep, notice I mentioned removing "many" tags and not *all* tags :-).
There are certainly tags we should keep around but I just don't see a need
for most of the logic and bean tags in Struts 2.0.
Whoops. I read
>Is there any reason that the EL tags wo
--- Joe Germuska <[EMAIL PROTECTED]> wrote:
> > > Whether the "classic" and "el" taglibs are one chunk or two isn't
> >> hugely important to me either -- I would prefer that this decision
> be
> >> made by developers who've done more work on that code to date.
> >> However, I did find that whe
> Whether the "classic" and "el" taglibs are one chunk or two isn't
hugely important to me either -- I would prefer that this decision be
made by developers who've done more work on that code to date.
However, I did find that when I patched
o.a.s.t.html.JavascriptValidator, I had to go and mak
On Tue, 23 Mar 2004 20:52:03 -0800 (PST), Martin Cooper wrote:
> So, there are pros and cons both ways, of course. Now we just need
> to make a decision and move on it. ;-
If all the deliverables are in a single module, is there a way that we can generate a
separate changelog for each one?
http:
--- Joe Germuska <[EMAIL PROTECTED]> wrote:
> >This makes it easy for the apps to extend a common Maven
> >project.xml. We could still offer a single zip/tarball with all the
> >applications WARs within.
> >
> >/apps
> > - examples
> > - mailreader
> > - tilesPortal
> > - userdb
> >
> >Now t
Quoting Ted Husted <[EMAIL PROTECTED]>:
> On Wed, 24 Mar 2004 20:35:41 +, Peter A. Pilgrim wrote:
> > Are keeping the basic `src' and `web' main sub directory under each
> > top level directory?
>
> I'd prefer we followed the Maven project layout recommendations for each
> deliverable. This w
This makes it easy for the apps to extend a common Maven
project.xml. We could still offer a single zip/tarball with all the
applications WARs within.
/apps
- examples
- mailreader
- tilesPortal
- userdb
Now that I say it, the same approach might conceivably be used for
el, taglibs, and fac
On Wed, 24 Mar 2004 20:35:41 +, Peter A. Pilgrim wrote:
> Are keeping the basic `src' and `web' main sub directory under each
> top level directory?
I'd prefer we followed the Maven project layout recommendations for each deliverable.
This will be the easiest for everyone to grok in the longr
Ted Husted wrote:
On Tue, 23 Mar 2004 20:52:03 -0800 (PST), Martin Cooper wrote:
So, there are pros and cons both ways, of course. Now we just need to make a decision
and
move on it. ;-)
The consensus seems to be to use a single module with top-level-directories
representing each
subproject, s
At 2:17 PM -0500 3/24/04, Ted Husted wrote:
>> \opt-el
Hmm. This is also a taglib...
But with different platform requirements. :)
Yes, but is there any reason not to treat them as a single
deliverable? They have interdependencies that would make this
attractive, and if users use the correct T
On Wed, 24 Mar 2004 11:03:58 -0800 (PST), Martin Cooper wrote:
>> \opt-dev (whiteboard or "sandbox")
>
> So 'dev', 'whiteboard' or 'sandbox'? ;-) I don't have a strong
> preference, although 'sandbox' is used by at least 4 Jakarta sub-
> projects. (In those, it's a separate repo, though. Do we wa
On Wed, 24 Mar 2004, Ted Husted wrote:
> On Tue, 23 Mar 2004 20:52:03 -0800 (PST), Martin Cooper wrote:
> > So, there are pros and cons both ways, of course. Now we just need
> > to make a decision and move on it. ;-)
>
> The consensus seems to be to use a single module with top-level-directories
> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> > Personally, I'd like to see a 1.2 release before any CVS
> changes are
> > made. I think the user community would agree.
>
> Well, did-ja have anything to add to the list, Matt? :)
>
Nope - release, release!!
On Wed, 24 Mar 2004 07:45:29 -0700, Matt Raible wrote:
>> ** Last but not least: What else do we need to do for 1.2.1 ? --
>> Just the three problem tickets on the bugzilla list now?
>>
>
> Personally, I'd like to see a 1.2 release before any CVS changes
> are made. I think the user community
At 6:08 AM -0800 3/24/04, David Graham wrote:
--- Joe Germuska <[EMAIL PROTECTED]> wrote:
Hope that helps. If we stick to our guns about avoiding dependencies
on unreleased software, this won't come up again... it's not Maven's
fault!
Commons Validator is a special case because it's mostly use
On Mar 24, 2004, at 4:19 AM, Ted Husted wrote:
Next question. In making changes like this, at what point do we start
breaking the CVS history? I'd definitely want to keep it all for core
and taglibs. The other components might be less important.
** Last but not least: What else do we need to do
--- Joe Germuska <[EMAIL PROTECTED]> wrote:
> Hope that helps. If we stick to our guns about avoiding dependencies
> on unreleased software, this won't come up again... it's not Maven's
> fault!
Commons Validator is a special case because it's mostly used with Struts.
The standalone user po
On Tue, 23 Mar 2004 20:52:03 -0800 (PST), Martin Cooper wrote:
> So, there are pros and cons both ways, of course. Now we just need
> to make a decision and move on it. ;-)
The consensus seems to be to use a single module with top-level-directories
representing each subproject, so lets move forwa
On Tue, 23 Mar 2004, Ted Husted wrote:
> On Tue, 23 Mar 2004 18:16:53 +, Peter A. Pilgrim wrote:
> > 1) I think you should keep the same elementary structure
>
> Moving forward, we have already decided to use Maven as our build environment, which
> addresses a number of consistency and struct
Joe Germuska wrote:
java:jar-resources:
Copying 16 files to /new/peterp/jakarta-struts/m-target/classes
====
[style]
new/peterp/jakarta-struts/doc/userGuide/struts-html.xml:1440:2: Fatal
Error! The content of elements must consist of well-formed character
data or markup.
[style] Fai
java:jar-resources:
Copying 16 files to /new/peterp/jakarta-struts/m-target/classes
[style] Transforming into
/new/peterp/jakarta-struts/m-target/classes/META-INF/tlds
[style] Processing
/new/peterp/jakarta-struts/doc/userGuide/struts-bean.xml to
/new/peterp/jakarta-struts/m-target/class
Joe Germuska wrote:
I just to try build Struts with Maven, what am I doing wrong?
...
Attempting to download commons-validator-1.1.2-dev.jar.
WARNING: Failed to download commons-validator-1.1.2-dev.jar.
The build cannot continue because of the following unsatisfied
dependency:
I cannot seem to bu
Joe Germuska wrote:
I just to try build Struts with Maven, what am I doing wrong?
...
Attempting to download commons-validator-1.1.2-dev.jar.
WARNING: Failed to download commons-validator-1.1.2-dev.jar.
The build cannot continue because of the following unsatisfied
dependency:
The problem is tha
I just to try build Struts with Maven, what am I doing wrong?
...
Attempting to download commons-validator-1.1.2-dev.jar.
WARNING: Failed to download commons-validator-1.1.2-dev.jar.
The build cannot continue because of the following unsatisfied dependency:
The problem is that the project.xml file
Joe Germuska wrote:
At 3:47 PM -0500 3/23/04, Ted Husted wrote:
At this point, we're down to whether to organize the subprojects
(units of release) into multiple modules or around
top-level-directories in a single module.
My only feeling is that should we start inviting some of the popular
ext
At 3:47 PM -0500 3/23/04, Ted Husted wrote:
At this point, we're down to whether to organize the subprojects
(units of release) into multiple modules or around
top-level-directories in a single module.
My only feeling is that should we start inviting some of the popular
extensions to join us, t
On Tue, 23 Mar 2004 18:16:53 +, Peter A. Pilgrim wrote:
> 1) I think you should keep the same elementary structure
Moving forward, we have already decided to use Maven as our build environment, which
addresses a number of consistency and structural issues. We had also decided to
distribute n
Peter A. Pilgrim wrote:
Ted Husted wrote:
On Tue, 23 Mar 2004 10:07:55 +, Peter A. Pilgrim wrote:
In my experienc multiple CVS repositories can make a project much
harder to manage. But are we singing from the same hymn sheet? Is a
"multiple repository" equal ( or not equal) to a CVS module?
either way :-)
Steve
> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]
> Sent: March 22, 2004 11:50 PM
> To: Craig R. McClanahan
> Cc: Struts Developers List
> Subject: Re: Making Struts Build Easier (Re: "coming out" for JSF +
> Struts,
Ted Husted wrote:
On Tue, 23 Mar 2004 10:07:55 +, Peter A. Pilgrim wrote:
In my experienc multiple CVS repositories can make a project much
harder to manage. But are we singing from the same hymn sheet? Is a
"multiple repository" equal ( or not equal) to a CVS module?
We mean multiple CVS mo
Ted Husted wrote:
On Mon, 22 Mar 2004 23:49:31 -0800 (PST), Martin Cooper wrote:
Well, as you mentioned, another way to go would be for some one to write a tool that could burst and rejar an arbitrary set of jars. (If one doesn't already exist.) The source for such a tool could live in the core
On Mon, 22 Mar 2004 23:49:31 -0800 (PST), Martin Cooper wrote:
>> On the multi-repository projects I've worked on, we had a special
>> repository just for integration tasks like this.
>
> So we'd need yet another repo - say struts-integration - just for
> this. Why is that better than just doing w
On Tue, 23 Mar 2004 10:07:55 +, Peter A. Pilgrim wrote:
> In my experienc multiple CVS repositories can make a project much
> harder to manage. But are we singing from the same hymn sheet? Is a
> "multiple repository" equal ( or not equal) to a CVS module?
We mean multiple CVS modules. The ori
Martin Cooper wrote:
On Mon, 22 Mar 2004, Craig R. McClanahan wrote:
Quoting Martin Cooper <[EMAIL PROTECTED]>:
On Mon, 22 Mar 2004, Ted Husted wrote:
On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote:
While it's great to break out things into separate "modules" - I'd
love to be able to
On Mon, 22 Mar 2004, Craig R. McClanahan wrote:
> Quoting Martin Cooper <[EMAIL PROTECTED]>:
>
> > On Mon, 22 Mar 2004, Ted Husted wrote:
> >
> > > On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote:
> > > > While it's great to break out things into separate "modules" - I'd
> > > > love to be a
Quoting Martin Cooper <[EMAIL PROTECTED]>:
> On Mon, 22 Mar 2004, Ted Husted wrote:
>
> > On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote:
> > > While it's great to break out things into separate "modules" - I'd
> > > love to be able to get struts.jar w/ everything in it - including
> > > E
On Mon, 22 Mar 2004, Ted Husted wrote:
> On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote:
> > While it's great to break out things into separate "modules" - I'd
> > love to be able to get struts.jar w/ everything in it - including
> > EL and tags. I can live with all the commons-* JARs (eve
se with which you can just type
'maven' and have everything happen.)
--
Martin Cooper
>
> Hermod
>
> -Opprinnelig melding-
> Fra: Joe Germuska [mailto:[EMAIL PROTECTED]
> Sendt: 22. mars 2004 15:28
> Til: Struts Developers List
> Emne: Making Struts B
> From: Matt Raible [mailto:[EMAIL PROTECTED]
> I don't care how things are partitioned in CVS, as long as everything
> builds with one checkout and one command.
Along those lines, I'd like to suggest that a complete WAR and/or EAR of
examples be included as one command to checkout. I'd even be
On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote:
> While it's great to break out things into separate "modules" - I'd
> love to be able to get struts.jar w/ everything in it - including
> EL and tags. I can live with all the commons-* JARs (even if it is
> annoying), but in general - the les
On Mar 22, 2004, at 11:28 AM, Ted Husted wrote:
On Mon, 22 Mar 2004 09:53:02 -0800, Craig R. McClanahan wrote:
Yep ... that's why we need to finish the "how many repositories"
discussion so we can start migrating towards something that is
simpler.
I continue to think that the easiest thing in the
On Mon, 22 Mar 2004 09:53:02 -0800, Craig R. McClanahan wrote:
> Yep ... that's why we need to finish the "how many repositories"
> discussion so we can start migrating towards something that is
> simpler.
I continue to think that the easiest thing in the long run will be a module for each
produc
At 11:52 AM -0500 3/22/04, Mike Kienenberger wrote:
Two weeks ago, I tried to build the struts 1.1 source package against
commons-collections-3.0.jar in order to run the unit tests and insure struts
still worked properly. After several hours of trying to set it up and make
...
Like those who post
Quoting David Graham <[EMAIL PROTECTED]>:
> Personally, I find the Struts build files to be complex and confusing.
> I've come to associate Maven with easy builds because building commons
> components (including the distro, website, tests, etc) is a snap compared
> to Struts. I agree that storin
David Graham <[EMAIL PROTECTED]> wrote:
> Personally, I find the Struts build files to be complex and confusing.
Two weeks ago, I tried to build the struts 1.1 source package against
commons-collections-3.0.jar in order to run the unit tests and insure struts
still worked properly. After sever
ve no good answers for this, just passing on my $.02...
Edgar
> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 22, 2004 9:47 AM
> To: Struts Developers List
> Subject: Re: Making Struts Build Easier (Re: "coming out" for J
: David Graham <[EMAIL PROTECTED]>
Date: Mon, 22 Mar 2004 06:46:32 -0800 (PST)
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: Making Struts Build Easier (Re: "coming out" for JSF + Struts, was:
Struts JSR?)
> Personally, I find the Struts build files to
I have a somewhat "nutty" suggestion. I suggest that we have someone who
is an "administrative" genius with a flair for teaching and simple
statement be an available guide to assist new people in getting the proper
builds to work on struts. Such a person would, I predict, be worth 100
times t
I agree 100% with Matt and make the same prognostication.
At 06:46 AM 3/22/2004, you wrote:
On Mar 22, 2004, at 7:28 AM, Joe Germuska wrote:
For me, the main discouraging thing about contributing to the
development of Struts has been the build process. In the past, you had
to download all of
Personally, I find the Struts build files to be complex and confusing.
I've come to associate Maven with easy builds because building commons
components (including the distro, website, tests, etc) is a snap compared
to Struts. I agree that storing jars in cvs isn't a good idea which is
why using
On Mar 22, 2004, at 7:28 AM, Joe Germuska wrote:
For me, the main discouraging thing about contributing to the
development of Struts has been the build process. In the past, you
had to download all of jakarta-commons and spend a day or two
figuring out how to get that to build. Recently, I tr
offline.
Hermod
-Opprinnelig melding-
Fra: Joe Germuska [mailto:[EMAIL PROTECTED]
Sendt: 22. mars 2004 15:28
Til: Struts Developers List
Emne: Making Struts Build Easier (Re: "coming out" for JSF + Struts,
was: Struts JSR?)
>For me, the main discouraging thing about contri
For me, the main discouraging thing about contributing to the
development of Struts has been the build process. In the past, you
had to download all of jakarta-commons and spend a day or two
figuring out how to get that to build. Recently, I tried to build
Struts and was successful using the
70 matches
Mail list logo
