I also wasn't fond of yet another myfaces.jar, but I think the
advantages of releasing different versions of Tomahawk and Impl make
up for it.   At some point, Impl should become stable and mature, but
hopefully tomahawk is going to constantly change and grow.  I don't
think Impl and Tomahawk should have the same release cycles
indefinitely.

As an end-user I also like having the ability to upgrade either one separately.

On 11/29/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> I wanted to resurrect one of our favorite threads ... "Should the
> shared code be in its own jar?"
>
> The reason why I bring this up now is that I'm starting to experiment
> with an M2 build for MyFaces.  In addition to some of the arguments
> made earlier we can now add Maven to the list of reasons why we might
> want to consider this.
>
> From my early exploration of Maven it seems like the shared stuff can
> be handled best by making the impl and tomahawk subprojects have a
> dependency on the share project.  In the past I have not been too wild
> about the shared jar idea but I think Maven may be able to help keep
> us and our users informed as to the exact dependencies when using
> MyFaces or Tomahawk.
>
> First off, I would suggest we call it *core* instead of share.  I
> think "core" helps to imply that it is mandatory.  They already know
> they need api and impl (if they have read the JSF spec.)  The "core"
> wording will let them know they need this also.
>
> Maven has some cool stuff for maintaining and documenting
> dependencies.  The tomahawk page of the website can automatically be
> updated so that for each new release of tomahawk, the dependency list
> will be updated.  Its also possible that we can have tomahawk depend
> on an earlier version of the core then the impl.  So we can compile
> against older versions that might be in the third party J2EE distros
> (like JBoss).  Anyways, the point is that Maven may finally provide
> the best solution to this problem so far.
>
> Thoughts?
>
> sean
>

Reply via email to