Six additional lines for the user (as long as he/she uses maven ;-) is
not that much more additional inconvenience I think:
<dependency>
<groupId>myfaces-jsfcommons</groupId>
<artifactId>myfaces-jsfcommons-impl</artifactId>
<version>1.0.0</version>
<scope>runtime</scope>
</dependency>
But I see your point and if I'm the only one who prefers separate
jars, I'm ok with only separating them by different package namespace.
However, the idea is a really stable API. That is crucial. If you
think we can manage it with one jar I'm ok with that.
--Manfred
On 11/29/07, Simon Kitching <[EMAIL PROTECTED]> wrote:
> 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 ;-) ?
>
>
--
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German
Professional Support for Apache MyFaces
