On Wed, 16 Mar 2005 08:45:32 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: > > * Shipping the API and IMPL classes in two jars, instead of one, > > will be friendlier to people (like me :-) who have build.xml scripts > > set up for the JSF RI, which is shipped in two JARs. All I need to > > do is set both build properties to use MyFaces instead. > > > > * If you ship COMP and SHARED in a single jar, you get the ability > > to use it with other implementations, which is good -- but you'd get > > that same benefit from shipping COMP and SHARED in separate jars > > and just saying you need both of them. > > These two statements seem slightly at odds with each other. If SHARED > is a separate jar then you don't just have API and IMPL jars, you will > also need the SHARED jar. Or are you proposing that SHARED be merged > with the IMPL one? If that's the case, then why keep it separate from > COMP?
After typing that (odd :-) sentence, it struck me that you could treat SHARED just like any of the external dependencies (Commons jars, etc.) that are needed by IMPL (which would still have an "api" and an "impl" jar to match the pattern of typical build.xml scripts set up for the RI). The components project would ship COMP and SHARED in its releases, declaring that you need them both (plus any other external dependencies, of course) to run on any JSF implementation. The implementation project would ship API, IMPL, and SHARED (again, along with any other external dependencies). As Sean points out in further mail, there are coordination issues around "releases" of SHARED to meet the needs of both other subprojects that might make it worth separating into its own small subproject, focused on backwards compatibility so a user of both IMPL and COMP will not have problems, no matter which version of SHARED they happen to include in their app. > > > Craig > > sean > Craig
