taverna-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry <redmi...@list.ru>
Subject Re: Apache headers
Date Wed, 18 Mar 2015 13:57:30 GMT
Hello Stian,

> I think you argued earlier that wsdlgeneric is useful outside the WSDL
> Activity, and hence stays as its own module/package.
I have an experimental "wsdl-generic" which is based on XML-tree model 
(directly based on XML Schema model) instead of splitters.
This package may be used as a stand-alone commandline tool for web 
services execution.

Because Taverna is deeply based on splitters (I think not only GUI, but 
also SCUFL2 (?)) I do not expect this branch be included into Taverna 3.0.

The question is about numbering. Once we change some package to 
"org.apache.taverna.*" other modules must be also changed.

Regarding "wsdl-generic" we have:

2.1.0-incubating-SNAPSHOT - the master (same as TAV 2.5)

Then I did (locally) just for development
3.0.0-incubating-SNAPSHOT - the same as 2.1.0 but with new 
3.1.0-incubating-SNAPSHOT - WSDL4j + WODEN based parser (WSDL 1.1/2.0)
3.5.0-incubating-SNAPSHOT - XML-Schema based (no splitters)

I would like to put WSDL4j + WODEN based parser (WSDL 1.1/2.0)
as 3.0.0 incubating, so the first Apache release will have a new parser 
(still with splitters, so no need to change UI).

I am ready to refactor modules as 3.0.0-incubating-SNAPSHOT changing the 
Just waiting the signal to start.


On 3/18/2015 2:32 PM, Stian Soiland-Reyes wrote:
> On 17 March 2015 at 16:18, alaninmcr <alaninmcr@googlemail.com> wrote:
>>> I see there are many taverna pieces in incubator that are still in
>>> taverna's "uk" package.
>> They should all be changed to org.apache in the near future.
> Anyone can do this job, it's just a bit of labour in the Refactor menu
> in Eclipse (or similar).   Feel free to have a go!
> Package rename is easier to do in "leaf" modules like
> incubator-taverna-common-activities, as you won't have to update
> imports elsewhere (just remember to also update those spring XML files
> in src/main/resources).
> In earlier discussion (sorry, I can't find exactly which thread now)
> we discussed having "simple" package hierarchies which relate to the
> Maven artifact (but not necessarily to its Maven parent), with one
> optional more level. E.g.:
> org.apache.taverna.beanshell.BeanshellActivity
> org.apache.taverna.wsdlgeneric.soap.SOAPResponseParser.java
> org.apache.taverna.wsdl.WSDLActivity
> I think you argued earlier that wsdlgeneric is useful outside the WSDL
> Activity, and hence stays as its own module/package.
>>> I'd like to make two branches of "wsdl-generic":
>>> "3.0.0-incubating-SNAPSHOT" - the same as "2.1.1" but within
>>> "org.apache.taverna.wsdl.*" package.
>>> "3.1.0-incubating-SNAPSHOT" - the new one based on wsdl4j/woden + Apache
>>> XML Schema
>> I am not convinced those are the right names.
> I am a bit confused over the version numbers - we have these tags:
> old/wsdl-generic-1.10
> old/wsdl-generic-1.10.0
> old/wsdl-generic-1.4
> old/wsdl-generic-1.5
> old/wsdl-generic-1.6
> old/wsdl-generic-1.7
> old/wsdl-generic-1.8
> old/wsdl-generic-1.9
> old/wsdl-generic-3.0-20150106
> old/wsdl-generic-3.0-woden-20150106
> old/wsdl-generic-3.0.0-service-catalographer
> old/wsdl-generic-before-security-2009-10-28
> old/wsdl-generic-maintenance-2010-09-06
> old/wsdl-generic-maintenance-20150106
> old/wsdl-generic-pre-incubator-20150106
> old/wsdl-generic-pre-security-2009-10-28
> old/wsdl-generic-service-catalogue-parser-20150106
> old/wsdl-generic-wsdl4j-maintenance-20150106
> The latest released activity version I found was 2.0, so I set
> common-activities to all be 2.1.0-incubating-SNAPSHOT.
> http://repository.mygrid.org.uk/artifactory/mygrid-all/net/sf/taverna/wsdl-generic/
> does not list version 3.0.0-service-catalographer
> So I am not sure why we have introduced version 3.0 here - but I'm OK
> for bumping master of taverna-activities to 3.1.0-incubating-SNAPSHOT.
>    (3.1.x to avoid confusion with those earlier kind-of-3.0 tags)
> We can't keep the version numbers in-sync across all the repositories,
> as that would imply always releasing all the repositories (in which
> case they should be a single repository.  Therefore I didn't suggest
> earlier to change everything to version 3.x - as that could give false
> leads in that direction. (This has alerady happened in Taverna 2.x..)
> I am not so sure about the version number in the branches - perhaps
> add a qualifier instead? It should not matter during development as
> long as it's not overlapping SNAPSHOT versions in the snapshot
> repository.  In fact, if we don't deploy snapshots of the branches,
> then why would they need a separate version number?

View raw message