commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morgan Delagrange <>
Subject [Jelly] Release Issue 2 - Jelly public API
Date Thu, 02 Jan 2003 18:05:02 GMT
Hey all,

I think it would be a good idea to identify the 1.0
Jelly API.  By API, I mean the "external interface" as
described in the Commons versioning guidelines
For many Commons components we have simply defaulted
to the public and protected methods of all classes. 
In Jelly's case this is not sufficient.  Defining a
more restricted Java API gives us a convenient way to
describe our core functionality in the documentation,
plus we can change underlying implementations without
compatibility issues.  Also, we have command line and
XML elements to our API.

Certainly the API should include the XML syntax of the
core taglibs (core, ant?, logging?, junit?, util?). 
It should also include the syntax of the command line
interface.  Which classes should be part of the API? 
I think I can safely say  that every class in the
'jelly' package
is part of the external interface, but every class in
is part of the internal interface.  I'm also pretty
sure that all classes in 'jelly.servlet' should be
public-facing.  I'm not sure about the classes in
'jelly.expression', 'jelly.expression.jexl',
'jelly.impl', and 'jelly.tags'.

I'm inclined to say that only the XML syntax of tags
is officially part of the API.  Classes in
'jelly.tags.*' should be considered an internal
interface, and modifying/extending those classes
should be unsupported.  I don't believe that we are
going to spend enough effort on the internals of those
tag classes to make them suitable for extension. 

Also, any ideas on how best to communicate the details
of the API to the user?  I think an explicit section
in the Jelly documentation is the minimum, but Javadoc
comments might also be useful.

- Morgan

Morgan Delagrange

Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message