incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dirk Frederickx" <>
Subject Re: Summary of votes for Andrew's 3 items
Date Sun, 04 Jan 2009 13:15:03 GMT
So far, I didn't got involved nor voted on the ongoing *api pakcage*
discussion as my voice is not much worth compared to all that java-brains on
this mailing list ;-)
Anyway, here is my 2 cents ...

We need to be able to better distinguish *stable* api's from the rest of the
However, by using the java package mechanism, we need to artificially
separate implementation from interface in the source code tree.  This may be
realitvely low-pain, as IDE's seems to provide support for this; but is also
counter-intuitive from a design perspective.

Why not use java annotations to resolve this issue ?

Annotations do not directly affect program semantics, but they allow to add
meta-data to the source-code.

A *@Stable-api* qualifier could provide some kind of meta-data tagging of
the stable java interfaces.
Such an annotation can be treated by tools (apt) to eg generate
documentation or extract classes into eg. API jar.
And it would be very clear to any developer what the status of that
interface is.  But still allow the structure of the source code package tree
be based upon logical design decisions.


Best whishes for 2009, and let's gear up for the upcoming v3.0.x !

On Sun, Jan 4, 2009 at 11:52 AM, Janne Jalkanen <>
>> I don't have an answer for how to achieve consensus here. I understand
Murray's point that moving an interface or class is itself disruptive, not
stable. On the other hand, changing the package from ecyrd to apache is
equally disruptive and will need to be done at some point anyway.
> Yes, and that is why I proposed that this is done for 3.0, since
everything will break *anyway*.  It would be much easier to tell the
developer that from now on out, the APIs you've been using will be living in
this namespace, and if you stick to that namespace, we'll try really hard to
make sure that your apps don't break.
> It's a simple, friendly message, and it gives us the option to move our
internal classes around as much as we please while retaining stability for
plugin developers.
> (For example, I would like to move the WikiPage and the rest of the
classes aside from the Release class into org.apache.jspwiki.core to keep
them from polluting the top-level package. This gives a clear indication as
to what they do.)
> /Janne

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message