You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Roland Huss <Ro...@consol.de> on 2001/06/26 01:25:52 UTC
/contrib
"Craig R. McClanahan" <cr...@apache.org> writes:
> Therefore, I'm great with adding some additional committers and starting
> work on the TODO list in the 1.1 tree. I've also asked Ted Husted to
> create a "contrib" directory at the top-level (in the 1.1 branch) and
> manage the posting of other contributions that have not yet been
> integrated into the Struts main codebase. (If there is a high volume of
> this, we might want to create a "jakarta-struts-sandbox" repository for
> such things, analogous to what several other Jakarta projects have done.
Ted Husted <hu...@apache.org> writes:
> You can send it to me, Francois. I'll post it on my Struts page right
> away, and add it to the Contributor's area in the Struts CVS later this
> week.
Great !
I really like the idea of a contrib area in struts as well as a the
suggestion of a sandbox repository. As you might have noticed, I
spent already some thoughts about a walkable way of integrating user
contributions to struts. (I came up with strutsx.org. This was
probably not a very good idea according to the zero resonance)
I would like to start a discussion about the structure about such a
contribution area. What can be done to make it as painless as possible
for the maintainers to integrate a new contribution ? How can some
minimal quality standards be guaranteed ? What are the requirements
for a user contribution ?
To support these goals, I have the following suggestions:
* contributions are stored below
$STRUTS/contrib/<user id>/<contribution id>
* A directory hierarchy is suggested,e.g.:
$CONTRIB/src/share
$CONTRIB/src/unit-test
$CONTRIB/src/example
$CONTRIB/doc
$CONTRIB/doc/taglib
* A skeleton build.xml is provided, which uses a set of
predefined ant-subroutines.
* An XML deployment descriptor for an user contribution could be
introduced, which contains essential information about name,
author, version, prerequisites, summary, unit test: yes/no,
example: yes/no, scope of contribution
(Action,ActionServlet,taglib,util).... . This deployment
descriptor could be used by an ant task for integration into the
main build process (e.g. dynamically building up the
documentation, building jars & wars, ...)
Since I have quite a lot of experience in building up and maintaining
large repositories, I really would like to contribute on this
issue (like the ant stuff or the deployment descriptor).
cu...
--
...roland huss
consol.de
Re: /contrib
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 25 Jun 2001, Robert Leland wrote:
>
>
> > Personally, I think what we really need is an automated system where
> > people could upload things and have them posted automatically for other
> > people to download. Like a "Braughtigan Library", or CPAN. This might be
>
> I agree many sites have a community for uploads.
> I was thinking about something like
> code central at community.borland.com.
> Users have to self register themselves with
> an account name, password and a valid e-mail
> address that is verified. Then they are allowed to
> upload/download software to the site, and later update it
> with newer versions. So the software isn't
> in a CVS format.
>
> I am sure there must be dozens of well used Java based
> portals, perhaps on Sourceforge, that we could start with.
> We could get that up pretty quickly. Then over time
> if we wish, we could replace the Interface with a struts based
> GUI as the resources are available. Ideally we could maintain
> database format level compatability,
>
There's been talk in the Commons community (but only a little code so
far) about building a CJAN type environment (the name being a pun on
CPAN). Note that, to host such a thing at Apache, there would need to be
some agreement that any uploaded code is licensed under the Apache License
(as is all of the code in the Struts CVS repository). But this doesn't
preclude hosting something similar elsewhere.
Hmm, it would make a really cool Struts example app if someone wanted to
build a CJAN thing using Struts for the web admin parts. Any volunteers?
>
> -Rob
>
Craig
> Ted Husted wrote:
>
> > Personally, I think what we really need is an automated system where
> > people could upload things and have them posted automatically for other
> > people to download. Like a "Braughtigan Library", or CPAN. This might be
> > a good niche for Strutsx, if the facilities are available. It would also
> > make a great working demo for attaching a database to Struts.
> >
> > Starting this morning, I am making a point of scooping up the
> > attachments and making them immediately available on the "More About
> > Struts" page. When I have a few of these together, we can get a better
> > idea of what a /contrib folder would look like.
> >
> > What large repositories have you been maintaining, Roland?
> >
> > The Commons gang could probably use some help in this regard too.
> >
> > Roland Huss wrote:
> > >
> > > "Craig R. McClanahan" <cr...@apache.org> writes:
> > >
> > > > Therefore, I'm great with adding some additional committers and starting
> > > > work on the TODO list in the 1.1 tree. I've also asked Ted Husted to
> > > > create a "contrib" directory at the top-level (in the 1.1 branch) and
> > > > manage the posting of other contributions that have not yet been
> > > > integrated into the Struts main codebase. (If there is a high volume of
> > > > this, we might want to create a "jakarta-struts-sandbox" repository for
> > > > such things, analogous to what several other Jakarta projects have done.
> > >
> > > Ted Husted <hu...@apache.org> writes:
> > >
> > > > You can send it to me, Francois. I'll post it on my Struts page right
> > > > away, and add it to the Contributor's area in the Struts CVS later this
> > > > week.
> > >
> > > Great !
> > >
> > > I really like the idea of a contrib area in struts as well as a the
> > > suggestion of a sandbox repository. As you might have noticed, I
> > > spent already some thoughts about a walkable way of integrating user
> > > contributions to struts. (I came up with strutsx.org. This was
> > > probably not a very good idea according to the zero resonance)
> > >
> > > I would like to start a discussion about the structure about such a
> > > contribution area. What can be done to make it as painless as possible
> > > for the maintainers to integrate a new contribution ? How can some
> > > minimal quality standards be guaranteed ? What are the requirements
> > > for a user contribution ?
> > >
> > > To support these goals, I have the following suggestions:
> > >
> > > * contributions are stored below
> > > $STRUTS/contrib/<user id>/<contribution id>
> > >
> > > * A directory hierarchy is suggested,e.g.:
> > > $CONTRIB/src/share
> > > $CONTRIB/src/unit-test
> > > $CONTRIB/src/example
> > > $CONTRIB/doc
> > > $CONTRIB/doc/taglib
> > >
> > > * A skeleton build.xml is provided, which uses a set of
> > > predefined ant-subroutines.
> > >
> > > * An XML deployment descriptor for an user contribution could be
> > > introduced, which contains essential information about name,
> > > author, version, prerequisites, summary, unit test: yes/no,
> > > example: yes/no, scope of contribution
> > > (Action,ActionServlet,taglib,util).... . This deployment
> > > descriptor could be used by an ant task for integration into the
> > > main build process (e.g. dynamically building up the
> > > documentation, building jars & wars, ...)
> > >
> > > Since I have quite a lot of experience in building up and maintaining
> > > large repositories, I really would like to contribute on this
> > > issue (like the ant stuff or the deployment descriptor).
> > >
> > > cu...
> > > --
> > > ...roland huss
> > > consol.de
>
> --
> Robert Leland Robert@free2create.org
> 804 N. Kenmore Street +01-703-525-3580
> Arlington VA 22201
>
>
>
Re: /contrib
Posted by Robert Leland <rl...@freetocreate.org>.
> Personally, I think what we really need is an automated system where
> people could upload things and have them posted automatically for other
> people to download. Like a "Braughtigan Library", or CPAN. This might be
I agree many sites have a community for uploads.
I was thinking about something like
code central at community.borland.com.
Users have to self register themselves with
an account name, password and a valid e-mail
address that is verified. Then they are allowed to
upload/download software to the site, and later update it
with newer versions. So the software isn't
in a CVS format.
I am sure there must be dozens of well used Java based
portals, perhaps on Sourceforge, that we could start with.
We could get that up pretty quickly. Then over time
if we wish, we could replace the Interface with a struts based
GUI as the resources are available. Ideally we could maintain
database format level compatability,
-Rob
Ted Husted wrote:
> Personally, I think what we really need is an automated system where
> people could upload things and have them posted automatically for other
> people to download. Like a "Braughtigan Library", or CPAN. This might be
> a good niche for Strutsx, if the facilities are available. It would also
> make a great working demo for attaching a database to Struts.
>
> Starting this morning, I am making a point of scooping up the
> attachments and making them immediately available on the "More About
> Struts" page. When I have a few of these together, we can get a better
> idea of what a /contrib folder would look like.
>
> What large repositories have you been maintaining, Roland?
>
> The Commons gang could probably use some help in this regard too.
>
> Roland Huss wrote:
> >
> > "Craig R. McClanahan" <cr...@apache.org> writes:
> >
> > > Therefore, I'm great with adding some additional committers and starting
> > > work on the TODO list in the 1.1 tree. I've also asked Ted Husted to
> > > create a "contrib" directory at the top-level (in the 1.1 branch) and
> > > manage the posting of other contributions that have not yet been
> > > integrated into the Struts main codebase. (If there is a high volume of
> > > this, we might want to create a "jakarta-struts-sandbox" repository for
> > > such things, analogous to what several other Jakarta projects have done.
> >
> > Ted Husted <hu...@apache.org> writes:
> >
> > > You can send it to me, Francois. I'll post it on my Struts page right
> > > away, and add it to the Contributor's area in the Struts CVS later this
> > > week.
> >
> > Great !
> >
> > I really like the idea of a contrib area in struts as well as a the
> > suggestion of a sandbox repository. As you might have noticed, I
> > spent already some thoughts about a walkable way of integrating user
> > contributions to struts. (I came up with strutsx.org. This was
> > probably not a very good idea according to the zero resonance)
> >
> > I would like to start a discussion about the structure about such a
> > contribution area. What can be done to make it as painless as possible
> > for the maintainers to integrate a new contribution ? How can some
> > minimal quality standards be guaranteed ? What are the requirements
> > for a user contribution ?
> >
> > To support these goals, I have the following suggestions:
> >
> > * contributions are stored below
> > $STRUTS/contrib/<user id>/<contribution id>
> >
> > * A directory hierarchy is suggested,e.g.:
> > $CONTRIB/src/share
> > $CONTRIB/src/unit-test
> > $CONTRIB/src/example
> > $CONTRIB/doc
> > $CONTRIB/doc/taglib
> >
> > * A skeleton build.xml is provided, which uses a set of
> > predefined ant-subroutines.
> >
> > * An XML deployment descriptor for an user contribution could be
> > introduced, which contains essential information about name,
> > author, version, prerequisites, summary, unit test: yes/no,
> > example: yes/no, scope of contribution
> > (Action,ActionServlet,taglib,util).... . This deployment
> > descriptor could be used by an ant task for integration into the
> > main build process (e.g. dynamically building up the
> > documentation, building jars & wars, ...)
> >
> > Since I have quite a lot of experience in building up and maintaining
> > large repositories, I really would like to contribute on this
> > issue (like the ant stuff or the deployment descriptor).
> >
> > cu...
> > --
> > ...roland huss
> > consol.de
--
Robert Leland Robert@free2create.org
804 N. Kenmore Street +01-703-525-3580
Arlington VA 22201
Re: /contrib
Posted by Ted Husted <hu...@apache.org>.
Personally, I keep thinking that if we had a CJAN, then we really
wouldn't need a contributors area. Just a Struts category therein.
The CJAN idea comes up on the Jakarta General list regularly, and I
think it would be the big fix for many problems in Javaland right now.
("Where do I find" comes up with great regularly on any list I've seen.)
The original proposal for the Commons included the beginnings of a CJAN,
but may be a while yet before I can get to it myself.
It would seem to me that between JAR's and Javadocs, the language is
ready-made for something like CJAN, if someone had the energy to get
that ball rolling.
Roland Huss wrote:
> Ted Husted <hu...@apache.org> writes:
> Fortunately, I got a machine (plus free internet connectitivity)
> donated by ConSol on which I can play around. So I suggest, that I
> will try to set up some demonstration of the kind of "contib area"
> mentioned above and it would be really great if you could comment on
> this, if the time has come.
Re: /contrib
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On 27 Jun 2001, Roland Huss wrote:
>
> BTW:
>
> > As Craig mentioned, the 1.0 release branch will probably become 1.1 (or
> > 1.01) before long, but that should be a maintenance release. So,
> > critical patches can be applied to both the HEAD and the 1.0 branches
> > when appropriate, but all new development should take place solely in
> > the HEAD branch.
>
> I wonder, why you recommend to apply bug fixes to BOTH struts
> branches ? Why don't simply put them into the patch branch and merge it
> back later on into the main trunk with CVS ? For us, CVS merging works
> perfectly, the resulting conflicts were always resolved in less than
> four hours.
>
This is mostly my personal preference. It's primarily based on the
following beliefs:
* I've been burned more than once on CVS merges, so I'm
a little gunshy ... :-)
* The internals of the HEAD branch are likely to diverge
pretty rapidly from 1.0 as we add new features, so there
will be more and more times when the patch would have to
be different anyway.
* I want us to be picky about the patches we apply to the
1.0 patch, to avoid the prospect of disrupting stability
in a 1.0.x patch release.
* I don't believe that there will be so many patches that
the "double commit" workload is particularly onerous :-).
Craig
Re: /contrib
Posted by Roland Huss <Ro...@consol.de>.
Ted Husted <hu...@apache.org> writes:
> Personally, I think what we really need is an automated system where
> people could upload things and have them posted automatically for other
> people to download. Like a "Braughtigan Library", or CPAN. This might be
> a good niche for Strutsx, if the facilities are available. It would also
> make a great working demo for attaching a database to Struts.
I absolutely agree with you at this point. But I think this is the
second step. First, I think, some commonly accepted rules about the
structure of user contributions are necessary. This is even true for
CPAN. Being quite familiar with CPAN (as a contributor, too), maybe
let's compare my suggestions against the recommended CPAN submission
rules:
> > * contributions are stored below
> > $STRUTS/contrib/<user id>/<contribution id>
The same is true for CPAN, except for the extra level of an
<contribution id>. This extra level is achieved by CPAN with the
different tar archives maintained by each contributor. However, if
Struts extension should go into the CVS repository, this extra
directory level seems to be appropriate.
> > * A directory hierarchy is suggested,e.g.:
> > $CONTRIB/src/share
> > $CONTRIB/src/unit-test
> > $CONTRIB/src/example
> > $CONTRIB/doc
> > $CONTRIB/doc/taglib
This is valid for CPAN, too. There is a suggested directory structure
for package submissions (e.g. a "t/" directory for unit tests), which
can be used by the automatic build procedure.
> > * A skeleton build.xml is provided, which uses a set of
> > predefined ant-subroutines.
The CPAN analogy is ExtUtils::MakeMaker, which provides a simple
mechanism for hooking into the build procedure, without knowing
details how the concrete build mechanism works (in this case
"make"). This perl support module could be directly translated into an
ant taskdef like <struts-contrib name="bla" version="1.0" ....>
> > * An XML deployment descriptor for an user contribution could be
> > introduced, which contains essential information about name,
> > author, version, prerequisites, summary, unit test: yes/no,
> > example: yes/no, scope of contribution
> > (Action,ActionServlet,taglib,util).... . This deployment
> > descriptor could be used by an ant task for integration into the
> > main build process (e.g. dynamically building up the
> > documentation, building jars & wars, ...)
There is no equivalent on CPAN (maybe some aspects (like dependency
checking) of MakeMaker fits in here, too). Well, I think such a piece
of meta information can be very useful, e.g. for checking
dependencies, building up a catalog or integrating in the overall
build process.
However, there's a big difference between CPAN and a (possible) Struts
contrib area. Since CPAN tries to capture the complete Perl world,
contributions are much less tightly coupled into a specific build
process as it is the case for a application framework like
Struts. There are only a countable number of (orthogonal) ways how to
integrate extensions to Struts (Actions,ActionServlets,taglibs). So,
the coupling is much tighter and contributions can be integrated
directly into the Struts' CVS repository (instead of merely a
collection of loosely related archives as it is the case for CPAN).
> What large repositories have you been maintaining, Roland?
Within our company, I build up maybe a dozen of CVS repositories for
projects and products. Maybe the biggest task was to introduce CVS and
ant into an already existing project with 800k lines of code, docs and
contrib files instead of an homegrown RCS derivate and a wild
combination of imake/nmake makefiles. Well, "large" was quite a bit
overstated in the face of "CPAN" ;-)
Since this time, I got a fairly well understanding about "good" ant
patterns. Well, I confess, most of them are probably a matter of taste
;-)
BTW:
> As Craig mentioned, the 1.0 release branch will probably become 1.1 (or
> 1.01) before long, but that should be a maintenance release. So,
> critical patches can be applied to both the HEAD and the 1.0 branches
> when appropriate, but all new development should take place solely in
> the HEAD branch.
I wonder, why you recommend to apply bug fixes to BOTH struts
branches ? Why don't simply put them into the patch branch and merge it
back later on into the main trunk with CVS ? For us, CVS merging works
perfectly, the resulting conflicts were always resolved in less than
four hours.
--
Fortunately, I got a machine (plus free internet connectitivity)
donated by ConSol on which I can play around. So I suggest, that I
will try to set up some demonstration of the kind of "contib area"
mentioned above and it would be really great if you could comment on
this, if the time has come.
cu....
--
...roland huss
consol.de
Re: /contrib
Posted by Ted Husted <hu...@apache.org>.
Personally, I think what we really need is an automated system where
people could upload things and have them posted automatically for other
people to download. Like a "Braughtigan Library", or CPAN. This might be
a good niche for Strutsx, if the facilities are available. It would also
make a great working demo for attaching a database to Struts.
Starting this morning, I am making a point of scooping up the
attachments and making them immediately available on the "More About
Struts" page. When I have a few of these together, we can get a better
idea of what a /contrib folder would look like.
What large repositories have you been maintaining, Roland?
The Commons gang could probably use some help in this regard too.
Roland Huss wrote:
>
> "Craig R. McClanahan" <cr...@apache.org> writes:
>
> > Therefore, I'm great with adding some additional committers and starting
> > work on the TODO list in the 1.1 tree. I've also asked Ted Husted to
> > create a "contrib" directory at the top-level (in the 1.1 branch) and
> > manage the posting of other contributions that have not yet been
> > integrated into the Struts main codebase. (If there is a high volume of
> > this, we might want to create a "jakarta-struts-sandbox" repository for
> > such things, analogous to what several other Jakarta projects have done.
>
> Ted Husted <hu...@apache.org> writes:
>
> > You can send it to me, Francois. I'll post it on my Struts page right
> > away, and add it to the Contributor's area in the Struts CVS later this
> > week.
>
> Great !
>
> I really like the idea of a contrib area in struts as well as a the
> suggestion of a sandbox repository. As you might have noticed, I
> spent already some thoughts about a walkable way of integrating user
> contributions to struts. (I came up with strutsx.org. This was
> probably not a very good idea according to the zero resonance)
>
> I would like to start a discussion about the structure about such a
> contribution area. What can be done to make it as painless as possible
> for the maintainers to integrate a new contribution ? How can some
> minimal quality standards be guaranteed ? What are the requirements
> for a user contribution ?
>
> To support these goals, I have the following suggestions:
>
> * contributions are stored below
> $STRUTS/contrib/<user id>/<contribution id>
>
> * A directory hierarchy is suggested,e.g.:
> $CONTRIB/src/share
> $CONTRIB/src/unit-test
> $CONTRIB/src/example
> $CONTRIB/doc
> $CONTRIB/doc/taglib
>
> * A skeleton build.xml is provided, which uses a set of
> predefined ant-subroutines.
>
> * An XML deployment descriptor for an user contribution could be
> introduced, which contains essential information about name,
> author, version, prerequisites, summary, unit test: yes/no,
> example: yes/no, scope of contribution
> (Action,ActionServlet,taglib,util).... . This deployment
> descriptor could be used by an ant task for integration into the
> main build process (e.g. dynamically building up the
> documentation, building jars & wars, ...)
>
> Since I have quite a lot of experience in building up and maintaining
> large repositories, I really would like to contribute on this
> issue (like the ant stuff or the deployment descriptor).
>
> cu...
> --
> ...roland huss
> consol.de
Re: /contrib
Posted by Ted Husted <hu...@apache.org>.
Thanks, Rob. I just found it as I was going back through the CVS
messages.
Since we're probably going to have a 1.0.1 release before 1.1, I've made
that release-notes-1.0.1.xml and added a just plain release-notes.xml
for the nightly release (which should become 1.1).
So anything committed to the 1_0_BRANCH should be reflected in
release-notes.1.0.1.xml and anything committed to the HEAD should be
reflected in release-notes.xml.
The beta release notes will be linked in through release-notes-1.0 and
so forth, but I'm removing them from the project menu to keep the
clutter down ;-)
If that makes sense to everyone ...
Robert Leland wrote:
>
> I placed a Release notes 1.0-ms1 under doc about a 2 weeks ago,
> for the 1.0X release.
Re: /contrib
Posted by Robert Leland <le...@dc.net>.
I placed a Release notes 1.0-ms1 under doc about a 2 weeks ago,
for the 1.0X release.
Ted Husted wrote:
> I just added a contrib directory to the main repository. This would be
> a good place to upload the working copies of the packages we are
> working on, including David's validator, Oleg's bean factory, and
> Cedric's components.
>
> If you all can add your contributions under this directory, it would
> help us get started on whatever refactoring and other work is needed.
>
> Other code contributed to the Struts can also be uploaded here by a
> committer, so long as it carries the Apache software license.
>
> I'm also going to start a release notes page for the nightly build
> (HEAD) and for Struts 1.x (the 1.0_BRANCH), and backfill what we have
> committed thus far. Since we're in 1.0 now, I'll also remove the release
> notes for the beta's (since these would be available in the
> distributions themselves, if anyone is still interested).
>
> -Ted.
--
Robert Leland Robert@free2create.org
804 N. Kenmore Street +01-703-525-3580
Arlington VA 22201
Re: /contrib
Posted by Ted Husted <hu...@apache.org>.
To be honest, I'm not sure what the goal is ;-)
I've been thinking there should be a place to post codebases that
haven't made it to distribution. Sometimes because we haven't had a
chance to look at them, sometimes because they wouldn't fit in with a
general-purpose lightweight framework. Some people have done this using
our own Web pages, but others have asked me to host the code on my Web
site instead. In the end, I'd like to put together an electronic catalog
where people can post and update their own ZIPs or WARs for all of
Jakarta and Java-land.
Craig suggested that we go ahead a put up a /contrib folder, and start
checking in anything appropriate (except for David's, Oleg's, and
Cedric's packages). I then began to wonder if checking in code authored
by someone without access to the CVS was the best way to go. And if I
check it in, it would seem like I'd be on the hook for any maintenance,
which implies I should take a good look at the code first. Since there
are a number of packages out there already, and I haven't gone through
them all yet, as an interim step, I expanded the contributor's section
on the Resources page, and will keep that updated.
Meanwhile, there seemed to be some uncertainity about whether David and
Oleg's codebases belonged in the core distribution or not (- not making
an opinion statement here ;-), so I suggested they all post them to
/contrib first -- really just to get things rolling.
As to your question:
The /contrib area is maintained by the Committers, who should take
responsiblity for managing the namespaces. My first inclination is to
suggest we name the packages so they could be moved under /src/shared at
any time, though I could easily be convinced otherwise. Perhaps we could
also open a dummy directory under shared to reserve a place for a
contrib package. Or, maybe skip the whole thing and just put them under
/src/shared now ;-)
As it stands, I would suggest that the goal of the Struts /contrib area
is to be a staging area for packages that may be moved into the main
source tree later (under /src/shared), or left in contrib indefinately.
For any packages being maintained anywhere else by anyone else, I would
suggest that they use their own namespace until it is moved under
/contrib or /src/shared in the Struts repository.
... Comments and alternatives welcome ...
-Ted.
Martin Cooper wrote:
>
> I think we will need to establish some guidelines for the structure of
> contributions, though. If the goal is that someone can pick up Struts, and
> add Contribution A and Contribution B, and have a combined package that
> works, then not only should the 'namespaces' (i.e. package names and taglib
> names) for A and B be distinct from each other, but they should both be
> distinct from Struts proper. Otherwise, it will be hard to migrate
> contributed code to Struts proper without breaking existing code that
> already uses the contributed functionality.
>
> --
> Martin Cooper
Re: /contrib
Posted by Martin Cooper <ma...@tumbleweed.com>.
I think we will need to establish some guidelines for the structure of
contributions, though. If the goal is that someone can pick up Struts, and
add Contribution A and Contribution B, and have a combined package that
works, then not only should the 'namespaces' (i.e. package names and taglib
names) for A and B be distinct from each other, but they should both be
distinct from Struts proper. Otherwise, it will be hard to migrate
contributed code to Struts proper without breaking existing code that
already uses the contributed functionality.
--
Martin Cooper
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: <st...@jakarta.apache.org>
Sent: Wednesday, July 04, 2001 7:56 PM
Subject: Re: /contrib
> Sure, if that works for you. It's just that it might be simplier to
> update and maintain under CVS.
>
> David Winterfeldt wrote:
> >
> > Do you want everything checked in as is for now
> > (package names, jsp tags, etc.)?
> >
> > David
>
Re: ErrorsTag (was /contrib)
Posted by David Winterfeldt <dw...@yahoo.com>.
I checked in the changes I've made. There is an
html:messages tag that iterates through the errors and
is basically the same as the tag I had in the
validator class except for the changes that were
discussed. I've made an ActionMessages class and
ActionMessage class. ActionErrors now extends
ActionMessages and ActionError extends ActionMessage,
but should work the exact same (basically the code
from the errors classes is just in the parent). My
thinking was that an error is basically a more a
specific type of message.
I haven't added the messagesExist tag yet because I'm
not sure where it belongs. All the logic tags are
very generic. Maybe it belongs in a taglib/validator
package. If you read this Craig, maybe you could
comment.
David
--- Ted Husted <hu...@apache.org> wrote:
> David Winterfeldt wrote:
> > This would work, but would it be confusing for a
> > general message tag to default to errors?
> Originally
> > when I did this I was thinking that for general
> > messages there could be ActionMessage,
> ActionMessages,
> > Action.MESSAGE_KEY, etc. And there would still be
> the
> > equivalent ones for errors, but they would
> subclass
> > the general message ones and use Action.ERROR_KEY.
>
> I'm just thinking that the "default" messages would
> be errors, but you
> could also use the same tags for general messages by
> supplying another
> id, for example the Action.MESSAGE_KEY.
>
> So "errors" are just the default messages, but you
> can use the same tags
> for managing any other message queues desired, just
> by supplying a
> message id (and/or alternate headers and footers).
>
> Alternatively, the tag could take a switch like
> "messages=true" to use
> the MESSAGE_KEY key. The default could be
> "messages=false", which would
> use the standard ERROR_key.
>
> To be consistent, we would use messagesExist with
> the same properties,
> and let it default to the ERROR_KEY.
>
> This leaves the html:errors as it is, and makes the
> message tags a new
> series with more functionality, that use the old
> ERROR_KEY by default,
> but can be used with other queues as well.
>
> -Ted.
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Re: ErrorsTag (was /contrib)
Posted by David Winterfeldt <dw...@yahoo.com>.
This sounds good. I adding 'messages=true'. That
makes it easier to use than have to put in a long key
each time.
David
--- Ted Husted <hu...@apache.org> wrote:
> David Winterfeldt wrote:
> > This would work, but would it be confusing for a
> > general message tag to default to errors?
> Originally
> > when I did this I was thinking that for general
> > messages there could be ActionMessage,
> ActionMessages,
> > Action.MESSAGE_KEY, etc. And there would still be
> the
> > equivalent ones for errors, but they would
> subclass
> > the general message ones and use Action.ERROR_KEY.
>
> I'm just thinking that the "default" messages would
> be errors, but you
> could also use the same tags for general messages by
> supplying another
> id, for example the Action.MESSAGE_KEY.
>
> So "errors" are just the default messages, but you
> can use the same tags
> for managing any other message queues desired, just
> by supplying a
> message id (and/or alternate headers and footers).
>
> Alternatively, the tag could take a switch like
> "messages=true" to use
> the MESSAGE_KEY key. The default could be
> "messages=false", which would
> use the standard ERROR_key.
>
> To be consistent, we would use messagesExist with
> the same properties,
> and let it default to the ERROR_KEY.
>
> This leaves the html:errors as it is, and makes the
> message tags a new
> series with more functionality, that use the old
> ERROR_KEY by default,
> but can be used with other queues as well.
>
> -Ted.
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Re: ErrorsTag (was /contrib)
Posted by Ted Husted <hu...@apache.org>.
David Winterfeldt wrote:
> This would work, but would it be confusing for a
> general message tag to default to errors? Originally
> when I did this I was thinking that for general
> messages there could be ActionMessage, ActionMessages,
> Action.MESSAGE_KEY, etc. And there would still be the
> equivalent ones for errors, but they would subclass
> the general message ones and use Action.ERROR_KEY.
I'm just thinking that the "default" messages would be errors, but you
could also use the same tags for general messages by supplying another
id, for example the Action.MESSAGE_KEY.
So "errors" are just the default messages, but you can use the same tags
for managing any other message queues desired, just by supplying a
message id (and/or alternate headers and footers).
Alternatively, the tag could take a switch like "messages=true" to use
the MESSAGE_KEY key. The default could be "messages=false", which would
use the standard ERROR_key.
To be consistent, we would use messagesExist with the same properties,
and let it default to the ERROR_KEY.
This leaves the html:errors as it is, and makes the message tags a new
series with more functionality, that use the old ERROR_KEY by default,
but can be used with other queues as well.
-Ted.
Re: ErrorsTag (was /contrib)
Posted by David Winterfeldt <dw...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> "Craig R. McClanahan" wrote:
> > Following this philosophy, we'd create a new tag
> (perhaps
> > <html:messages>?) for the new functionality, and
> deprecate
> > <html:errors>. In addition, we'd need to change
> the 1.1 implementation of
> > <html:errors> so that it did something sensible,
> even in the face of a
> > "new and improved" error messages object.
>
> The Validator package actually includes a general
> messages tag, which
> isn't much different from its errors tag.
>
> So maybe we should just add that one, and have it
> start by using the
> default ERRORS key. I believe people could then also
> use it for other
> messages just by specifying a different id property,
> and a different
> header or footer, if desired. I think all we would
> have to do is add an
> optional "property" property to messages and
> messagesExist.
This would work, but would it be confusing for a
general message tag to default to errors? Originally
when I did this I was thinking that for general
messages there could be ActionMessage, ActionMessages,
Action.MESSAGE_KEY, etc. And there would still be the
equivalent ones for errors, but they would subclass
the general message ones and use Action.ERROR_KEY.
Where would the messagesExist tag go?
David
>
> <
> http://home.earthlink.net/~dwinterfeldt/jsptags.html
> >
>
> -Ted.
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Re: /contrib
Posted by Ted Husted <hu...@apache.org>.
"Craig R. McClanahan" wrote:
> Following this philosophy, we'd create a new tag (perhaps
> <html:messages>?) for the new functionality, and deprecate
> <html:errors>. In addition, we'd need to change the 1.1 implementation of
> <html:errors> so that it did something sensible, even in the face of a
> "new and improved" error messages object.
The Validator package actually includes a general messages tag, which
isn't much different from its errors tag.
So maybe we should just add that one, and have it start by using the
default ERRORS key. I believe people could then also use it for other
messages just by specifying a different id property, and a different
header or footer, if desired. I think all we would have to do is add an
optional "property" property to messages and messagesExist.
< http://home.earthlink.net/~dwinterfeldt/jsptags.html >
-Ted.
Re: /contrib
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 7 Jul 2001, Ted Husted wrote:
> David Winterfeldt wrote:
> > I don't know. I could go either way. I think it
> > makes sense having the ValidatorForm in
> > org.apache.struts.action.
>
> +1 on org.apache.struts.action if that's what you want to do.
>
> > Are there any issues with breaking backwards
> > compatibility? I'm for replacing the validator
> > version for the current since iterating throught the
> > errors further encourages formatting to be in the
> > view. If we do replace the old tag, would it still be
> > somewhere for people to access the old tag that
> > migrate from Struts 1.0 to Struts 1.1? Possibly
> > called html:errorsOld or old-html:errors. Or the new
> > one could be html:errorsIterator.
>
> Craig setup a 1.1 DTD so we could make changes there without affecting
> the 1.0 users. I guess we need a similar strategy for the taglibs
> themselves. If we made the old taglib available as struts-html-10, then
> they could keep compatible just by changing the web.xml reference, or
> something.
>
Setting up a different taglib (struts-html-10) still forces old users to
change every page when they migrate to 1.1 :-(.
If its feasible, I'd like us to stick with a policy like this for tags:
* You can add new optional attributes to an existing tag,
as long as the default behavior remains as it was before.
* If you are creating a substantially improved version of an
old tag, deprecate the old one and create the new tag with
a new name (or the same name in a new taglib).
Following this philosophy, we'd create a new tag (perhaps
<html:messages>?) for the new functionality, and deprecate
<html:errors>. In addition, we'd need to change the 1.1 implementation of
<html:errors> so that it did something sensible, even in the face of a
"new and improved" error messages object.
What do you think?
> -Ted.
>
Craig
Re: /contrib
Posted by Ted Husted <hu...@apache.org>.
David Winterfeldt wrote:
> I don't know. I could go either way. I think it
> makes sense having the ValidatorForm in
> org.apache.struts.action.
+1 on org.apache.struts.action if that's what you want to do.
> Are there any issues with breaking backwards
> compatibility? I'm for replacing the validator
> version for the current since iterating throught the
> errors further encourages formatting to be in the
> view. If we do replace the old tag, would it still be
> somewhere for people to access the old tag that
> migrate from Struts 1.0 to Struts 1.1? Possibly
> called html:errorsOld or old-html:errors. Or the new
> one could be html:errorsIterator.
Craig setup a 1.1 DTD so we could make changes there without affecting
the 1.0 users. I guess we need a similar strategy for the taglibs
themselves. If we made the old taglib available as struts-html-10, then
they could keep compatible just by changing the web.xml reference, or
something.
-Ted.
Re: /contrib
Posted by David Winterfeldt <dw...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> I don't have access to the CVS permission list, and
> can't check on how
> you're setup myself. I could ask root, or wait for
> Craig to get back.
>
> I did commit a file to the contrib root, and did a
> fresh checkout to be
> sure it made the round trip.
>
> If you have a chance, see if you can commit some
> change to the README in
> /contrib, and also try the others again.
>
> One thing we can discuss now is whether the
> ValidatorForm should be part
> of the core distribution, or a standard option.
>
> At this point, personally I wouldn't dream of
> writing a Struts app
> without the ValidatorForm ;-), and it wouldn't take
> much to convince me
> that it should live under shared with the core
> distribution. On the
> other hand, if we can load the validations as a
> "Struts Extension", it
> would also be a great example of how a "standard
> option" can work.
I don't know. I could go either way. I think it
makes sense having the ValidatorForm in
org.apache.struts.action. Although having it setup as
an extension might provide more flexibility going into
the future. I was personally thinking of trying to
keep the dependencies on Struts minimized, but the
Struts specific interfaces would go somewhere in the
core (like ValidatorForm).
>
> Also there is the question of whether we should
> update the html:error
> tags to use the Validator versions (+1 for me).
Are there any issues with breaking backwards
compatibility? I'm for replacing the validator
version for the current since iterating throught the
errors further encourages formatting to be in the
view. If we do replace the old tag, would it still be
somewhere for people to access the old tag that
migrate from Struts 1.0 to Struts 1.1? Possibly
called html:errorsOld or old-html:errors. Or the new
one could be html:errorsIterator.
David
>
> David Winterfeldt wrote:
> >
> > I started to check everything into a validator
> > directory under contrib. It looks like I
> successfully
> > added directories, but I get this error when
> checking
> > in a file. I checked in one of the documentation
> xsl
> > files a few days ago and that didn't cause a
> problem.
> > Has anyone seen these error messages before? Do I
> not
> > have write permission in the cvs logs?
> >
> > cvs add: cannot add special file `CVS'; skipping
> > cvs add: scheduling file `INSTALL' for addition
> > cvs add: scheduling file `LICENSE' for addition
> > cvs add: scheduling file `README' for addition
> > cvs add: scheduling file `build-test.xml' for
> addition
> > cvs add: scheduling file `build.properties' for
> > addition
> > cvs add: scheduling file `build.xml' for addition
> > Cannot open
> > /home/cvspublic/CVSROOT/commitlogs/jakarta-struts:
> > Permission denied
> > Mailing the commit message...
> > Directory
> >
>
/home/cvspublic/jakarta-struts/contrib/validator/conf
> > added to the repository
> > Cannot open
> > /home/cvspublic/CVSROOT/commitlogs/jakarta-struts:
> > Permission denied
> > Mailing the commit message...
> >
> > I ran 'cvs add' first.
> > cvs ci INSTALL
> > **** Access denied: Insufficient Karma
> > (dwinterfeldt|jakarta-struts/contrib/validator)
> > cvs commit: Pre-commit check failed
> > cvs [commit aborted]: correct above errors first!
> >
> > The status shows it checked in locally, but not
> into
> > the main repository.
> >
> > David
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Re: /contrib
Posted by Ted Husted <hu...@apache.org>.
I don't have access to the CVS permission list, and can't check on how
you're setup myself. I could ask root, or wait for Craig to get back.
I did commit a file to the contrib root, and did a fresh checkout to be
sure it made the round trip.
If you have a chance, see if you can commit some change to the README in
/contrib, and also try the others again.
One thing we can discuss now is whether the ValidatorForm should be part
of the core distribution, or a standard option.
At this point, personally I wouldn't dream of writing a Struts app
without the ValidatorForm ;-), and it wouldn't take much to convince me
that it should live under shared with the core distribution. On the
other hand, if we can load the validations as a "Struts Extension", it
would also be a great example of how a "standard option" can work.
Also there is the question of whether we should update the html:error
tags to use the Validator versions (+1 for me).
David Winterfeldt wrote:
>
> I started to check everything into a validator
> directory under contrib. It looks like I successfully
> added directories, but I get this error when checking
> in a file. I checked in one of the documentation xsl
> files a few days ago and that didn't cause a problem.
> Has anyone seen these error messages before? Do I not
> have write permission in the cvs logs?
>
> cvs add: cannot add special file `CVS'; skipping
> cvs add: scheduling file `INSTALL' for addition
> cvs add: scheduling file `LICENSE' for addition
> cvs add: scheduling file `README' for addition
> cvs add: scheduling file `build-test.xml' for addition
> cvs add: scheduling file `build.properties' for
> addition
> cvs add: scheduling file `build.xml' for addition
> Cannot open
> /home/cvspublic/CVSROOT/commitlogs/jakarta-struts:
> Permission denied
> Mailing the commit message...
> Directory
> /home/cvspublic/jakarta-struts/contrib/validator/conf
> added to the repository
> Cannot open
> /home/cvspublic/CVSROOT/commitlogs/jakarta-struts:
> Permission denied
> Mailing the commit message...
>
> I ran 'cvs add' first.
> cvs ci INSTALL
> **** Access denied: Insufficient Karma
> (dwinterfeldt|jakarta-struts/contrib/validator)
> cvs commit: Pre-commit check failed
> cvs [commit aborted]: correct above errors first!
>
> The status shows it checked in locally, but not into
> the main repository.
>
> David
Re: /contrib
Posted by David Winterfeldt <dw...@yahoo.com>.
Thanks.
--- "Craig R. McClanahan" <cr...@apache.org> wrote:
>
>
> On Wed, 4 Jul 2001, David Winterfeldt wrote:
>
> > I started to check everything into a validator
> > directory under contrib. It looks like I
> successfully
> > added directories, but I get this error when
> checking
> > in a file. I checked in one of the documentation
> xsl
> > files a few days ago and that didn't cause a
> problem.
> > Has anyone seen these error messages before? Do I
> not
> > have write permission in the cvs logs?
> >
> > cvs add: cannot add special file `CVS'; skipping
> > cvs add: scheduling file `INSTALL' for addition
> > cvs add: scheduling file `LICENSE' for addition
> > cvs add: scheduling file `README' for addition
> > cvs add: scheduling file `build-test.xml' for
> addition
> > cvs add: scheduling file `build.properties' for
> > addition
> > cvs add: scheduling file `build.xml' for addition
> > Cannot open
> > /home/cvspublic/CVSROOT/commitlogs/jakarta-struts:
>
> It looks like you are trying to do this from a
> checkout that was made via
> anonymous CVS.
>
> You need to re-check-out the repository under the
> new CVSROOT
> (dwinterfeldt@localhost:/home/cvs) before you can do
> check-ins.
>
> Craig
>
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Re: /contrib
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 4 Jul 2001, David Winterfeldt wrote:
> I started to check everything into a validator
> directory under contrib. It looks like I successfully
> added directories, but I get this error when checking
> in a file. I checked in one of the documentation xsl
> files a few days ago and that didn't cause a problem.
> Has anyone seen these error messages before? Do I not
> have write permission in the cvs logs?
>
> cvs add: cannot add special file `CVS'; skipping
> cvs add: scheduling file `INSTALL' for addition
> cvs add: scheduling file `LICENSE' for addition
> cvs add: scheduling file `README' for addition
> cvs add: scheduling file `build-test.xml' for addition
> cvs add: scheduling file `build.properties' for
> addition
> cvs add: scheduling file `build.xml' for addition
> Cannot open
> /home/cvspublic/CVSROOT/commitlogs/jakarta-struts:
It looks like you are trying to do this from a checkout that was made via
anonymous CVS.
You need to re-check-out the repository under the new CVSROOT
(dwinterfeldt@localhost:/home/cvs) before you can do check-ins.
Craig
Re: /contrib
Posted by David Winterfeldt <dw...@yahoo.com>.
I started to check everything into a validator
directory under contrib. It looks like I successfully
added directories, but I get this error when checking
in a file. I checked in one of the documentation xsl
files a few days ago and that didn't cause a problem.
Has anyone seen these error messages before? Do I not
have write permission in the cvs logs?
cvs add: cannot add special file `CVS'; skipping
cvs add: scheduling file `INSTALL' for addition
cvs add: scheduling file `LICENSE' for addition
cvs add: scheduling file `README' for addition
cvs add: scheduling file `build-test.xml' for addition
cvs add: scheduling file `build.properties' for
addition
cvs add: scheduling file `build.xml' for addition
Cannot open
/home/cvspublic/CVSROOT/commitlogs/jakarta-struts:
Permission denied
Mailing the commit message...
Directory
/home/cvspublic/jakarta-struts/contrib/validator/conf
added to the repository
Cannot open
/home/cvspublic/CVSROOT/commitlogs/jakarta-struts:
Permission denied
Mailing the commit message...
I ran 'cvs add' first.
cvs ci INSTALL
**** Access denied: Insufficient Karma
(dwinterfeldt|jakarta-struts/contrib/validator)
cvs commit: Pre-commit check failed
cvs [commit aborted]: correct above errors first!
The status shows it checked in locally, but not into
the main repository.
David
--- Ted Husted <hu...@apache.org> wrote:
> Sure, if that works for you. It's just that it might
> be simplier to
> update and maintain under CVS.
>
> David Winterfeldt wrote:
> >
> > Do you want everything checked in as is for now
> > (package names, jsp tags, etc.)?
> >
> > David
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Re: /contrib
Posted by Ted Husted <hu...@apache.org>.
Sure, if that works for you. It's just that it might be simplier to
update and maintain under CVS.
David Winterfeldt wrote:
>
> Do you want everything checked in as is for now
> (package names, jsp tags, etc.)?
>
> David
Re: /contrib
Posted by David Winterfeldt <dw...@yahoo.com>.
Do you want everything checked in as is for now
(package names, jsp tags, etc.)?
David
--- Ted Husted <hu...@apache.org> wrote:
> I just added a contrib directory to the main
> repository. This would be
> a good place to upload the working copies of the
> packages we are
> working on, including David's validator, Oleg's bean
> factory, and
> Cedric's components.
>
> If you all can add your contributions under this
> directory, it would
> help us get started on whatever refactoring and
> other work is needed.
>
> Other code contributed to the Struts can also be
> uploaded here by a
> committer, so long as it carries the Apache software
> license.
>
> I'm also going to start a release notes page for the
> nightly build
> (HEAD) and for Struts 1.x (the 1.0_BRANCH), and
> backfill what we have
> committed thus far. Since we're in 1.0 now, I'll
> also remove the release
> notes for the beta's (since these would be available
> in the
> distributions themselves, if anyone is still
> interested).
>
> -Ted.
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
Re: /contrib
Posted by Ted Husted <hu...@apache.org>.
I just added a contrib directory to the main repository. This would be
a good place to upload the working copies of the packages we are
working on, including David's validator, Oleg's bean factory, and
Cedric's components.
If you all can add your contributions under this directory, it would
help us get started on whatever refactoring and other work is needed.
Other code contributed to the Struts can also be uploaded here by a
committer, so long as it carries the Apache software license.
I'm also going to start a release notes page for the nightly build
(HEAD) and for Struts 1.x (the 1.0_BRANCH), and backfill what we have
committed thus far. Since we're in 1.0 now, I'll also remove the release
notes for the beta's (since these would be available in the
distributions themselves, if anyone is still interested).
-Ted.