I don't think a separation between api and impl jars is useful. Myfaces core has broken code I've been working on many times. And the issue there is not a change in the api (the JSF api is clearly static). Instead the problem has been changes in behaviour.
So a stable API jar only solves about 20% of the stability problem. But it doubles the number of jars a user has to manage. Doesn't seem to me like the inconvenience is work it. Instead, having a decent test suite to check for application stability is better; that can test both API and behaviourable stability. Possibly having non-public classes in a separate package within the jar (eg org.myfaces.jsfcommons.impl.*) would be worthwile. At release time, then a simple check of the commits to the api packages would be sufficient to double-check api stability. Regards, Simon ---- Manfred Geiler <[EMAIL PROTECTED]> schrieb: > yes, fine! > please consider the following structure: > > myfaces-jsfcommons > |---- myfaces-jsfcommons-api > |---- myfaces-jsfcommons-impl > |---- myfaces-jsfcommons-sandbox > > (we must avoid the name "myfaces-commons" for there was once a project > with that name - see maven repo!) > > api = the classes and interfaces, that users will directly use (ie. > import) in their code (= compile scope dependency) > impl = internal implementation classes, users will need during runtime > only (= runtime scope dependency) > > furthermore: > - api classes and interfaces must not change between two bugfix > releases (eg. from 1.0.0 to 1.0.1) > - api classes and interfaces might vary (be extended) between two > minor releases (eg. from 1.0.3 to 1.1.0) - BUT only backwards > compatible! > - api classes and interfaces might be totally different between two > major releases (eg. from 1.5.3 to 2.0.0) - BUT need not ;-) > - impl classes (and interfaces) can be changed, added, removed, > refactored whenever needed > > This is no unnecessary effort IMHO. jsfcommons can only be successful > and widely accepted if users can confide in a stable API that is not > subject to change on every single release. In a community driven > project this is only possible with some rules. And systematically > separating API from Impl classes in different JARs make these rules > very simple and intuitive. > > --Manfred > > > > > On Nov 28, 2007 10:41 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > Hi, > > > > it is that case, that Bernd I and meet next weekend. > > If you guys don't mind, we start the commons project, as discussed here. > > > > Like maven-stuff etc. > > > > -Matthias > > > > > > On Nov 13, 2007 7:27 PM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > > Hi! > > > > BTW, I do not understand why some of you are so scared by multiple > > > > jsfcommons artifacts. > > > I see it being much work to maintain ... but anyway, since you are the > > > one who is going to do the initial maven work :-) I do no longer argue > > > against. > > > So, can we start now ;-) ?
