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
> <sheetal.vartak_at_oracle.com> 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.
Thanks
Sheetal
>
> Andy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>