Jitendra Kotamraju wrote:
> 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.
> Similarly, how do we install standalone jax-ws ri distribution on GF
> v2 and GFv3 ?
>>
>> 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.
> Yes, as you said we may have to revisit this in future. In future, if
> jersey is part of metro, then this will become very coarse grained. If
> a module has dependency on JAX-WS, there is no problem in adding
> dependency on metro. But the same thing cannot be said about a module
> that has dependency just on JAXB. I think we need to know which
> modules depend on which metro components, for e.g HK2 depends on a
> StAX impl. Is there any advantage to deliver a module that contains
> all, and also individual components as separate modules ?
independently of good software practices, the main benefit is to provide
flexibility in distributions to only package the minimum set of
technologies they require. The more coarse grained, the harder to create
flexible distributions. So it might be ok that for TP2 timeframe, you
come up with one big jar but I have no doubt that this will have to be
revisited later on...
>
> Jitu
>>
>>
>> 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
>>
>>
>