Ted Husted <[EMAIL PROTECTED]> 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
