Craig McClanahan wrote:
(b) JSRs that Apache does not host implementations for, but where projects
might
want to rely on implementations acquired elsewhere.
For group (a), the current practice is to host the API classes inside the
project that is also providing the implementation. That makes sense to me
for a number of reasons,
Let me reply from the view of the JaxMe project, which has recently
voted for moving the public API to Geronimo. Of course, we see the
advantage of hosting both API and implementation. However, they
typically apply only, if the API is changing. Fact is, the project is
typically divided into two parts with very difficult characteristics:
The API is rarely (if ever) changing, the implementation is changing
quite frequently.
On the other hands, we see the following advantage of a centralized
location:
- Visibility: If you, as a user, are looking for a replacement of Sun's
jar files, you wouldn't look for JaxMe. But you'd probably look for
a central location of SPEC jar files.
- Continuous Integration: Currently, a number of projects are depending
on JaxMe in Gump. In fact, none or only a small number depend on the
implementation: They are actually depending on the API jar file.
Having the API as a separate project reduces the dependency tree. But
if the API already is a separate project, we are already loosing the
advantages of a combined project.
- Project size: Having a smaller project pays. Build time is faster,
build scripts become smaller, ...
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
