Adam,
I was repeating what'd been said before rather than stating an opinion.
However, after thinking about it a little, I think there's two
different products we're talking about.
One product, CommonComponents, is targeted for general JSF developers.
It's stuff that can easily be used in any project no matter what the
rendering kit or other component sets. These people may never create
a component on their own, and theoretically may not even be Java
programmers -- they may be page designers. The "API" for these items
are simply the available attributes on the components.
The other product, CommonAPI, is targeted at component developers.
It's code APIs that allow someone to more quickly and consistently
develop new components. There's nothing here that would directly be
used in an application. The api here has to be far more carefully
considered.
Obviously, these are glaring generalizations, and there's bound to be
some overlap.
On 5/3/07, Adam Winer <[EMAIL PROTECTED]> wrote:
Ahhh! :) Makes much more sense. Like you said,
I think there's already some confusion, this sets it
mostly straight. Maybe some naming is in order?
What about:
"MyFaces Basics": components/validators/filters, etc.
that users can use anywhere (== CommonComponents)
"MyFaces Commons": public APIs that we expose across
the stack (== CommonAPIs)
"MyFaces Shared": internal APIs that all the component
libraries + the impl can collaborate and depend on?
But I'm not 100% convinced that there really is a difference
between CommonComponents and CommonAPIs, or
at least enough of a difference to merit splitting them.
Mike, what about the two makes you want to split
them?
Cheers,
Adam
On 5/3/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> Adam,
>
> Our past discussion on "commons" was to provide JSF
> components/validators/converters that could be used in any component
> library, even if that component library is not compatible with any
> other component library (ie, tobago). I think perhaps this should be
> called CommonComponents.
>
> "Commons" as was used in this thread is not about building a component
> development API. That is a different but often-brought-up topic that
> also needs a "vision". We will want a CommonAPI to cover the area
> that Adam brought up.
>
> We should try to be clear about which we're talking about since we're
> already seeing some confusion in the thread. For example,
> AddResources would probably be a part of CommonAPI rather than
> CommonComponents.
>
> Note that MyFaces also has a "shared" module where code is shared
> between MyFaces Core and MyFaces Tomahawk.
>
> On 5/3/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > Before we do this, we have to be careful on our vision:
> > - Are we looking to define internal utilities shared among
> > Trinidad/Tomahawk/Tobago?
> > - Are we looking to define public APIs shared among these
> > projects?
> > - Are we going to have a common package name for all
> > such code?
> >
> > IMO, we should:
> > - Have no components at all in here, at least to start,
> > whether or not they render markup.
> > - Use a common package name
> > - Be very cautious and slow as we build this up, being *really*
> > sure about the APIs we're adding. This should be a foundational
> > stone for a long time.
> > - Start enforcing a public vs. private API split for real, and
> > be rigorous about when we change public APIs without
> > preserving backwards compatibility.
> >
> > Also, I don't think build dependencies belong in here, at least
> > not in terms of a packaged JAR. Whether they live in
> > a "commons" in terms of SVN locations is fine.
> >
> > -- Adam
> >
> >
> >
> > On 5/3/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > > Greetings from the ApacheCon in Amsterdam.
> > >
> > > It was discussed a lot on the list and Bernd and I are now taking the
> > > time to layout a "apache-myfaces-commons-[SUBSET]-VERSION.jar" file.
> > >
> > > Commons:
> > > -What should go into a commons JAR?
> > > Non renderKit related things like
> > > -Converters and Validators
> > > -NonFacesRequestServlet from Tobago
> > > -FacesContextFactory from Tobago to ensure a kind of common layer
> > > for doing uploads
> > > -the selectItems component from Tomahawk
> > > -what are we missing ???
> > >
> > > Build dependencies:
> > > - Trinidad's plugins/utils to generate stuff like the TagClass file.
> > >
> > > The vision:
> > > Why this is needed ?
> > > It is kind of hard to actually use only some "common" pieces of
> > > Tomahawk. At least to add a custom validator, the complete jar is
> > > needed. The vision is also to add some "common" pieces from
> > > Trinidad/tobago to it.
> > >
> > > For Tomahawk this will not mean, you have to introduce a new namespace
> > > for adding the converter/validator, the "commons-jar" can be a rt
> > > dependency so that the TLD file is only referencing to the classes
> > > w/in the commons.jar.
> > >
> > > What are you missing ?
> > > We will compile a list into the MyFaces wiki, based on your
feedback/comments
> > >
> > > -Bernd/Matthias
> > >
> >
>
