[jbosstools-dev] Some modules in jbosstools-4.0.x require version update

[Max Andersen]

No, I don't think changing bundle Ids are a requirement. Some of these could easily be maintained separate from their "homes" IMO. 

What I mean ownership is that someone will be developing and testing these in context of eap,soap, JPP etc. and not just only individual runtime projects. 

That's what the runtime detection is about - making the setup easy across runtimes and versions. 

/max (sent from my phone)


On 21/02/2013, at 20.18, Denis Golovin <dgolovin at exadel.com> wrote:

> On 02/21/2013 01:52 AM, Max Rydahl Andersen wrote:
>> On 21 Feb 2013, at 04:05, Nick Boldt <nboldt at redhat.com> wrote:
>> 
>>>>>> runtime-soa - nick suggested it can be deleted, because all runtime
>>> detection plugins moved to corresponding modules
>>> 
>>> To be clear, this only applies to jbosstools-runtime-soa
>>> 4.0.x/4.1.0.Alpha1x/master branches in github. The older 3.3.x stuff in
>>> SVN should not be touched as it's part of the JBDS SOA 5 stream. And I
>>> meant it COULD be deleted once the migration of all three
>>> plugins/features was complete.
>> For me *move* of a runtime plugins means that the features are
>> 
>> A) The project owners taken ownership of these  (just applying a PR blindly without testing doesn't count does it ? ;)
>> B) setup and verified to build and be included properly in JBTIS
>> C) no longer present in https://github.com/jbosstools/jbosstools-runtime-soa/tree/master/plugins
> 
> "take ownership" means some changes in original runtime detector plugin, like:
> - change plugin/feature name to match module namespace;
> - do the refactoring in plug-in's packages to match module namespace
> 
> It is good time to do so, because it is first development release.
> 
> Does that sound right?
> 
> Denis
>> 
>> None o
>>> I opened PRs to move the contents from that repo into ESB, jbpm, and
>>> droolsjbpm, but the droolsjbpm stuff requires further changes as it
>>> changes the way they build. With this change they will depend on JBT,
>>> and therefore will need to retool they way they produce their update
>>> site. They've also asked to upversion the feature/plugin to match their
>>> release version (eg., 6.0.0).
>>> 
>>> Ref: https://github.com/droolsjbpm/droolsjbpm-tools/pull/14
>> Okey - if Drools pluginrefer to one of our sites is that stripped out when composited/aggregated in JBTIS ?
>> 
>> Otherwise when user point to this site they will have jboss tools updatesite show up twice with possible incompatible versions, right ?
>> 
>> /max
>