Hi Hong,
So is the plan to add "compatibility" as a property of the
sun-application element in the sun-application.xml file? I assume this
would have the same default and functionality as the "compatibility"
property of the application element in domain.xml. Currently the
sun-application element doesn't have an optional property subelement,
but adding one wouldn't break backward compatibility. You may have to
increment the sun-application DTD version though.
Please let Dixie and me know what you plan to do so we can make sure
it's doc'd properly.
June
On 10/30/09 09:20 AM, Hong Zhang wrote:
> Thanks for all the discussions!
>
> It seems the main concern that the earlier versions of the NB
> packaging the application incorrectly is not much of an issue. The
> problem only happens when the earlier versions of the NB was used
> together with maven (maven ignores the manifest entry) which will have
> far less impact.
>
> So my current plan is to keep the default behavior as it is, but make
> additional changes to provide a way for autodeploy (and JSR88) to
> specify this property. We certainly encourage the users to re-package
> the application the spec defined way, but we are not forcing it
> (that's why we have this property). And we will try to provide useful
> warnings for the cases where we could detect such packaging.
>
> Thanks,
>
> - Hong
>
> Sahoo wrote:
>
>>
>>
>> Tim Quinn wrote:
>>
>>>> I still don't see how we can force users to package the app in one
>>>> particular way.
>>>
>>> I don't think anyone suggested that. If you're thinking about my
>>> note to Vince earlier, I described an approach that's probably
>>> better from a design and information hiding point of view. I did
>>> not say we should impose that or any approach on users.
>>
>>
>> I am not saying you suggested the packaging was wrong. I thought one
>> of the reasons this whole thread was started was because v3 rejected
>> deployment of such apps unless compatibility=v2 mode was not enabled.
>> If that's not the case, I am confused why we raised NB packaging
>> issue to start with.
>>
>> Sahoo
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>