Ludovic Champenois wrote:
> Bill Shannon wrote:
>> A way to set the property in sun-application.xml is reasonable.
>> Can't any deployment time property be set there?
>>
>> Can anyone provide more information on what situations NetBeans would
>> package an app incorrectly?
> Not sure...
>> I'd especially like to hear from the
>> NetBeans developer who implemented this feature to understand why
>> he thought he should do it that way.
> Bill, so far Nb uses an extended JSR 88 style deployment...Having all
> the new props we have today in cli mode (which is not JSR 88 style)
> would be very nice to have. This way, the developer could change a
> sun-web.xml and or a sun-application.xml to add Galssfish Specific
> deployment properties. This way, this would be from the Nb side a server
> agnostic feature: just edit the Sun* files, and do not provide more GUI
> for specific properties.
> I asked for that a long time ago, and time/resource constraints have
> other priorities.
> There is no way so far that Nb would expose this new "compatibility"
> property unless we change UI post UI freeze, a usal no-no.
> Changing sun-web.xml dtd is also way too late...
My understanding was that the issue we're talking about only effects
ear files. As I said above, I agree that having a way to set this
property in the sun-application.xml file would be good.
But I'm still interested in the details of when NetBeans packages jar
files in the root of the ear file with the expectation that they'll
be available to all modules in the ear file, and why the NetBeans
developer who implemented it that way thought that was a good thing
to do.