> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> list-help: <mailto:[EMAIL PROTECTED]>
> list-unsubscribe: <mailto:[EMAIL PROTECTED]>
> list-post: <mailto:[EMAIL PROTECTED]>
> Delivered-To: mailing list [EMAIL PROTECTED]
> From: Theo Keyzer <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: RE: What is Jakarta?
> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N
>
> Thursday, February 08, 2001 10:29 AM GOMEZ Henri wrote:
> > I'm +1 with Arieh Markel about
> >
> > . Jakarta Base Network Utilities
> > . Jakarta Base JSP Utilities
> > . Jakarta XML Utilities
> > . Jakarta SMTP Utilities
> > . Jakarta Tools
>
> How do you make the tools so that they don't tie
> into applications too closely, or become
> sub-applications - not needed to build any Jakarta project.
> Or can they if they are still add on tools for a Jakarta package.
I would venture that projects meet on the committed deliverables:
a. software bundles, ready to be deployed, built with a single
command, and installed on the target hosts
(i.e.: download, untar, configure, make, make install)
and/or
b. O.S. - specific packaged installable units, which means
that the per-project repository needs to include:
linux rpms
solaris pkgadd images
installshield units
.
.
etc
Both approaches need to be able to point out the dependencies that the
project may have on other 'components'. In the case of case 'a', the
'configure' phase (autoconf based perhaps) may detect those.
In the case of 'b' the native O.S. packaging system will do that by
establishing/pointing at the correct dependencies.
The mention on a previous thread about Richard Gabriel's points about
code reuse brings to light the fact that a 'registry/repository' needs
to be in place, where the code-to-reuse can be found.
The repository should also include documentation (overview, Javadocs)
for the different 'components', and be able to preserve the history
of the releases, to the degree of even
proj_A/
doc/
src/
nightly/
latest/ -> link to latest
mon/
tue/
.
.
sun/
rels/
latest/ -> link to latest
1.0.1/
1.0.1/
1.0.2/
.
.
2.0.0/
2.0.1/
.
.
providing access to the latest bleeding-edge version (from the nightly
builds), or the latest approved released version, or any previous rev.
The ability to not tie into applications is dependent on the 'generality',
perhaps the 'bean-like' approach to building the tools/utilities/libraries.
What would be necessary, IMHO, is a more structured approach, with the
committers, for example, reviewing the APIs that are developed for
appropriateness. This will also lead to issues like insuring backwards
compatibility when advancing from one revision to another, so that
projects dependent on a specific 'component' are not surprised when the
next revision of the 'component' changed some API.
Secondly, the issue of not tying as sub-applications of a specific
application is in the establishment of how a project is composed,
and what it depends on:
productA
composed of:
components of project_1
components of project_2
project_1
depends on:
components implementing Interface_X
components implementing Interface_Y
.
.
components implementing Interface_Z
and so forth ...
The point is that if products are built in a 'component-like' manner,
the release engineering and distribution environment should be built
to match, otherwise, the scaling and leveraging gained by being
a component based 'architecture' is lost because of the inability to
productize it.
Arieh (who has been lately dealing with similar subjects in my daily job)
--
Arieh Markel Sun Microsystems Inc.
Network Storage 500 Eldorado Blvd. MS UBRM11-194
e-mail: [EMAIL PROTECTED] Broomfield, CO 80021
Let's go Panthers !!!! Phone: (303) 272-8547 x78547
(e-mail me with subject SEND PUBLIC KEY to get public key)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
