Re: fix for issue 924 (merging the JSF api and impl jar into a single jar)

From: Sheetal Vartak <>
Date: Mon, 15 Nov 2010 12:38:50 -0800

Hi Andy,

Sorry for the late reply.
Please see comments inline.

On Nov 12, 2010, at 8:24 AM, Andy Schwartz wrote:

> Hi Sheetal -
> On Fri, Nov 5, 2010 at 2:04 PM, Sheetal Vartak
> <> wrote:
>> Just wanted to give an heads up that I am planning on fixing issue 924 that talks about merging the
>> jsf-api.jar and jsf-impl.jar into a single jar. Once this fix is checked in, for updating the JSF bits in an
>> environment, one would need to delete both jsf-api.jar and jsf-impl.jar and then copy the new single jar file
> Just wanted to verify that the jsf-api.jar and jsf-impl.jar will
> continue to exist as always - ie. the new merged jar will be provided
> as a convenience, not as a requirement. This isn't clear from the
> issue tracker.

After this fix is checked in, there will be 2 jars available as follows :
1> javax.faces.jar = api + impl classes
2> javax.faces-api.jar = only api classes

The names have been changed to adhere to the maven naming and versioning rules that the Glassfish team follows. I can certainly also keep the old names along with the new ones for backward compatibility.
>> This fix is a partial fix for issue 1826 as well.
> I am concerned about coupling these two issues. 1826 seems like a
> functional issue that needs to be resolved independently of jar
> packaging.

 You are right about 1826 being a functional issue. I have tried different ways of fixing this issue (using the Export-Package directive along with the mandatory directive in OSGi, using the Fragment-Host directive in OSGi). None of these worked seamlessly. The only option that looked easy enough to accomplish this task was to merge the 2 jars. I have also consulted some of the Spec leads (Bill Shannon, Ed Burns) to see if it is OK to go ahead with this option.

> Also, I find the following statement from the issue tracker troubling:
>> If we did this, then code in jsf-api could access com.sun.faces classes directly.
> API classes should not reference implementation (com.sun.faces)
> classes directly. One of the main reasons for the very common
> practice of splitting API and implementation into separate jars is to
> avoid exactly this sort of reverse dependency.

I agree with you on this as well. Since I have exhausted all viable solutions that I know of, would love to hear if there is a better way to approach this.

> Andy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: