[jbosstools-dev] [Soa-tools-list] JBTIS: Managment of External Components

[Max Rydahl Andersen]

(adding jbosstools-dev to this since think it applies to both soa and 
core)

> I think this could also apply to the BPEL component as well, but I 
> don't remember if we create a feature around that in JBT or if we pull 
> the feature from Eclipse.

So i'm open to suggestions on how to improve this but lets not go change 
the TP process on a whim just yet.

We have recently got similar challenge in jbosstools core recently with 
Eclipse Thym which is receiving more often updates than in past.

For now we have added an exemption to allow TP updates to be smoother 
see 
https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/target_platforms/target_platforms_updates.adoc#or-from-requester-only 
(basically if just update to existing TP units owned by a project we 
know/control the full TP process update is not required)

Now, back to the reason why we have them as TP entries as opposed to 
other components is a few:

a) to make sure we have a download.jboss.org mirror since eclipse 
mirrors are unreliable/slower (especially for people outside US)

b) it is to ensure we are not just using the "master"/nightly builds of 
external dependencies

c) it is to ensure we do not drag in transitive dependencies from 
eclipse.org component updatesites which (at least in the past) have had
lots of updatesite references to mix of p2 sites that resulted in 
duplicated dependencies and/or wrong/non-deterministic p2 resolution 
(because the updatessites
was one of a or b)

d) the eclipse.org parts tend to participate in the eclipse release 
train - thus (for simplicity) using them via TP makes it easier to track

e) finally it is there to ensure we don't see a drift in multiple 
modules adding different versions into their dependency/build chain. 
(For core that is less likely since we have jbosstools parent pom to at 
least centralize where the various updatesites are located, but jbtis is 
much more spread out...hence a TP seem more relevant?)

So that is the reasons...now ...does the bpmn2 and bpel parts receive 
many active updates that makes it non-feasible just including updates 
via the "normal" TP update process ?

..and/or are there some hidden burdens in this that might not be visible 
?

/max


>
> ----- Original Message -----
>>
>> +1!
>>
>> reducing the TP complexity is certainly a good idea - can we get a 
>> show of
>> virtual hands who in IS component land actually pulls the BPMN2 
>> modeler
>> from the JBTIS TP??
>>
>>  --paull
>>
>>
>>
>> ----- Original Message -----
>>> From: "Rob Cernich" <rcernich at redhat.com>
>>> To: "soa-tools-list" <soa-tools-list at redhat.com>
>>> Sent: Wednesday, August 27, 2014 3:13:31 PM
>>> Subject: [Soa-tools-list] JBTIS: Managment of External Components
>>>
>>> Hey all,
>>>
>>> The recent update of BPMN2 modeller caused me to think about the way 
>>> we
>>> handle components that come from external sources.  To me, it makes 
>>> sense
>>> if
>>> we treat these components the same way we treat our internal 
>>> components.
>>> If
>>> we were to do that, these components would no longer be part of the 
>>> JBTIS
>>> target platform and would instead be part of the features list 
>>> described in
>>> the jbosstools and devstudio modules.
>>>
>>> In my opinion, this is a better way to treat these types of 
>>> dependencies as
>>> they are components in their own right (i.e. no different than 
>>> SwitchYard
>>> or
>>> Teiid, e.g.).  If they are also dependencies used by other 
>>> components, they
>>> would need to be managed by those other components using the same 
>>> mechanism
>>> used to reference other internal component dependencies (e.g. SAVARA 
>>> and
>>> SwitchYard).  (SwitchYard actually references the BPMN2 repository 
>>> directly
>>> specifically to avoid circularities within the tp/repo chain; i.e.
>>> SwitchYard does not require the TP be updated in order to update 
>>> BPMN2
>>> modeller).
>>>
>>> Just an idea.
>>>
>>> Rob
>>>
>>> _______________________________________________
>>> Soa-tools-list mailing list
>>> Soa-tools-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/soa-tools-list
>>>
>>
>
> _______________________________________________
> Soa-tools-list mailing list
> Soa-tools-list at redhat.com
> https://www.redhat.com/mailman/listinfo/soa-tools-list


/max
http://about.me/maxandersen