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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
> 804 N. Kenmore Street +01-703-525-3580
> Arlington VA 22201
>
>
>
