Tim,
FYI We do not separate client runtime from server runtime. If there is
an appclient built with metro it will need webservices-rt.jar in
classpath at runtime.
Regards,
Bhakti
Timothy Quinn wrote:
> My (predictable) contribution to this topic is to ask whether it makes
> sense to have a JAR (or set of JARs) that supports what clients need
> separate from what servers need. This comes from the continuing
> effort we all need to share to keep the footprint for app clients as
> small as possible. In the past I've heard that there is not much
> possibility for improvement in this, but I will continue to raise the
> issue at every chance! Especially as long as GlassFish needs a
> different version of such JARs vs. what is in the JRE the size of
> these JARs will remain an issue for app clients.
>
> - Tim
>
> Kohsuke Kawaguchi wrote:
>>
>> Putting my Metro hat on here,
>>
>> Really *the* motivation for Metro to deliver things as one big blob
>> is so that we can release one set of binaries as stand-alone and then
>> deliver the same bits to v2 and v3.
>>
>> Metro needs to keep delivering into v2 and v3 for some time to come,
>> and we do stand-alone releases for foreseeable future. If we can
>> deliver our bits in the exact same fashion into two versions of GF,
>> that would considerably simplify our build qualification and testing
>> effort. And this is one area where we are really stretched thin.
>>
>> This also has an added benefits to users, as they can take the
>> stand-alone bits and upgrade GF by simply copying the jars. (Although
>> this is a secondary issue for v3, assuming it has its own update
>> channel to deliver new bits.)
>>
>> You are right that there's a possibility that EE6 defines profiles
>> that only require a certain portion of Metro but not the others, but
>> so far that hasn't happened yet, and I thought it won't be too late
>> to revisit the packaging when/if that happens.
>>
>> There's also a small issue that nucleus already depends on a StAX
>> implementation, which is today delivered as a part of Metro, but we
>> felt that that was small enough duplication and the benefit of single
>> bits delivery outweighs the problem.
>>
>> So all in all, what I'm suggesting is to start the Metro integration
>> into v3 according to Bhakti's suggestion, with the understanding that
>> we should be open to the possibility of revisiting this.
>>
>>
>> Bhakti Mehta wrote:
>>> Jerome,
>>> Please read inline
>>> Jerome Dochez wrote:
>>>> my initial feeling is that it is too coarse grained.
>>> I tend to agree but if different profiles start plugging in their
>>> own versions of the subparts wouldnt that be a nightmare to debug?
>>> Hence I brought up this question here should metro be a module or
>>> should there be dependencies for individual technologies in metro?
>>>
>>> Regards,
>>> Bhakti
>>>>
>>>> For instance, for people who don't care about java ee compatibility
>>>> and would want to only support say JAXB+JAXWS (which I assume would
>>>> be doable), how would that work ?
>>>>
>>>> also in Java EE 6, different profiles may require different subpart
>>>> of the metro stack, wouldn't that make things harder to decouple...
>>>>
>>>> Jerome
>>>>
>>>> On Feb 28, 2008, at 3:18 PM, Bhakti Mehta wrote:
>>>>
>>>>> Hi,
>>>>> I wanted to check if there are individual modules in v3 depending
>>>>> on various technologies from the metro stack like jaxb, jaxws,
>>>>> sjsxp, stax-ex,saaj?
>>>>>
>>>>> Since all these technologies are bundled in
>>>>> webservices-rt/webservices-tools.jar and the 1.1.2-SNAPSHOT
>>>>> version of metro is already on maven repository
>>>>> Imaybe we should just refer to webservices-rt,webservices-api and
>>>>> webservices-tools in our dependencies
>>>>>
>>>>> The only case maybe where Kohsuke suggested sjsxp (people just
>>>>> wanting to use the parser may not want to get the whole metro stack)
>>>>> In that case we can let the dependency for sjsxp remain in the
>>>>> poms but for other technologies I can just update the poms to use
>>>>> metro.
>>>>>
>>>>> Do other modules see issues with that?
>>>>>
>>>>> Thanks,
>>>>> Bhakti
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>