You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@taverna.apache.org by Stian Soiland-Reyes <st...@apache.org> on 2015/01/23 14:54:56 UTC
Practice-release of taverna-language? [MENTOR] [RELEASE]
Hi,
The IP clearance from Manchester is pulling out (we are pinging every
day now - any updates, Shoaib?)
.. so what if we do a practice-release-candidate of taverna-language?
After Alan's package rename and (I think today) he's putting in the
Apache headers, it should in theory be ready to go. It builds and run
fine, as far as I can see.
That is we do the preparation and build and figure out (and document)
the release procedure - and then we test and vote internally over that
release candidate? The difference from "proper release candidate" is
that it won't go anywhere on a successful vote.
That should allow the mentors to give us a heads-up with any IP issues
remaining - as we probably will have to iterate here - and for
dev@taverna to experience collectively what the release process is
like.
It should also hopefully avoid severe delays later when we can prepare
a proper release candidate and get it past the IPMC.
Thoughts about this proposal? Mentors?
Would we be allowed to put those release candidates on the
https://dist.apache.org/repos/dist/dev/incubator/taverna/ even though
the source code might still live on Github at that point? We can host
them on mygrid.org.uk if not - but it would be great to get the
release process as close to natural early.
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
Re: Practice-release of taverna-language? [MENTOR] [RELEASE]
Posted by "Donal K. Fellows" <do...@manchester.ac.uk>.
On 25/01/2015 12:56, Alan Williams wrote:
> On 25-Jan-15 11:49, Andy Seaborne wrote:
>> On 23/01/15 13:54, Stian Soiland-Reyes wrote:
>>> The IP clearance from Manchester is pulling out (we are pinging every
>>> day now - any updates, Shoaib?)
>>
>> Clarification?
>>
>> Is a there anything that can be done to help?
>
> Stian did not mean "pulling out". The IP clearance is still ongoing. If
> it is not sorted out next week then it will be "escalated" - professors
> making scary phonecalls etc. :-D
Yeah. The phrase I heard mentioned in relation to Legal was “We're
thinking about drafting a letter to all the organizations and
individuals that have contributed in the past to see if they're all OK
with this”, despite the fact that we already have their copyright
assigments on file. We're deeply frustrated by this. I'm not sure
whether they're dragging heels or knuckles more...
Apart from glacial^W Legal, I think we're about ready to go, at least
with the SCUFL2 libraries (and associated support bits). The executable
engine will take a bit longer from an engineering perspective as that's
a lot more complicated and needs more testing. But that's a good thing
to be taking a bit of time over. :-)
Donal.
Re: Practice-release of taverna-language? [MENTOR] [RELEASE]
Posted by Alan Williams <al...@googlemail.com>.
On 25-Jan-15 11:49, Andy Seaborne wrote:
> On 23/01/15 13:54, Stian Soiland-Reyes wrote:
>> Hi,
>>
>> The IP clearance from Manchester is pulling out (we are pinging every
>> day now - any updates, Shoaib?)
>
> Clarification?
>
> Is a there anything that can be done to help?
Stian did not mean "pulling out". The IP clearance is still ongoing. If
it is not sorted out next week then it will be "escalated" - professors
making scary phonecalls etc. :-D
It will be done as it will be included in presentations at a project
review next month.
Alan
Re: Practice-release of taverna-language? [MENTOR] [RELEASE]
Posted by Andy Seaborne <an...@apache.org>.
On 23/01/15 13:54, Stian Soiland-Reyes wrote:
> Hi,
>
> The IP clearance from Manchester is pulling out (we are pinging every
> day now - any updates, Shoaib?)
Clarification?
Is a there anything that can be done to help?
> .. so what if we do a practice-release-candidate of taverna-language?
> After Alan's package rename and (I think today) he's putting in the
> Apache headers, it should in theory be ready to go. It builds and run
> fine, as far as I can see.
>
>
> That is we do the preparation and build and figure out (and document)
> the release procedure - and then we test and vote internally over that
> release candidate? The difference from "proper release candidate" is
> that it won't go anywhere on a successful vote.
>
>
> That should allow the mentors to give us a heads-up with any IP issues
> remaining - as we probably will have to iterate here - and for
> dev@taverna to experience collectively what the release process is
> like.
>
>
> It should also hopefully avoid severe delays later when we can prepare
> a proper release candidate and get it past the IPMC.
>
>
> Thoughts about this proposal? Mentors?
Good thought.
> Would we be allowed to put those release candidates on the
> https://dist.apache.org/repos/dist/dev/incubator/taverna/ even though
> the source code might still live on Github at that point?
Only formally released Apache code can do there.
An ASF release is from ASF hosted and IP-cleared code. That includes
incubator releases. They are still real and proper Apache releases,
voted on (and hence legally cleared) to the same degree as a TLP.
> We can host
> them on mygrid.org.uk if not - but it would be great to get the
> release process as close to natural early.
The non-Apache Taverna project can do what it likes, just don't make an
Apache claims or associations.
You can go through all the motions of a release if you don't associate
with Apache -- so artifacts should not are not under group id
org.apache.taverna.
Personally, I am not so worried about Java package names myself but
others might be. This is a new one on me. Java package names are not
what people come across first in accessing the build.
The maven group id is something the user comes across first and implies
the origin, and all the associated Apache effects like defined IP and
License. So I think it must not be rooted at "org.apache".
If this is to practice and clean a release, and that is a good thought,
do you really need to let artifacts hit a publicly accessible maven
repository at all?
That is, separate the process checking goal from delivering
code/binaries to users (a longer term commitment).
Andy
Re: Practice-release of taverna-language? [MENTOR] [RELEASE]
Posted by Stian Soiland-Reyes <st...@apache.org>.
In scufl2-rdfxml we configure JAXB to validate against the schemas
from the classpath on reading and writing:
https://github.com/taverna-incubator/incubator-taverna-language/blob/master/taverna-scufl2-rdfxml/src/main/java/org/apache/taverna/scufl2/rdfxml/RDFXMLSerializer.java#L641
https://github.com/taverna-incubator/incubator-taverna-language/blob/master/taverna-scufl2-t2flow/src/main/java/org/apache/taverna/scufl2/translator/t2flow/T2FlowParser.java#L516
This is not done in taverna-robundle though - perhaps it should?
On 25 January 2015 at 13:21, Donal K. Fellows
<do...@manchester.ac.uk> wrote:
> On 23/01/2015 15:55, Stian Soiland-Reyes wrote:
>>
>> The scufl2-rdfxml XSDs, although also used for code generation, are a
>> formal part of the scufl2 language definitions (as the ontologies) and
>> are in src/main/resources exactly to be exposed in the JAR - I'm not
>> sure, but this might be used by a test somewhere.
>>
>> Arguably if you are in Java you could be using the scufl2 API instead
>> of dealing with the XSD - but who are we to decide that? :)
>>
>>
>> Perhaps the "official" SCUFL2 XSDs (and the ontologies which are now
>> hidden in scufl2-rdf/src/main/resources/something) should be in a
>> separate module taverna-scufl2-schemas -- similar to
>>
>> https://github.com/taverna-incubator/incubator-taverna-osgi/tree/master/taverna-osgi-schemas/
>> which I found rather clean. Thoughts?
>
>
> My take? I've never seen the need for shipping the XSDs in the JAR (as
> opposed to a source-jar), not unless they're going to be directly used
> at runtime. A straight document should just be published online
> somewhere where both people and code can read it. They're also the sort
> of thing that it might make a load of sense to get a DOI for; a
> significant schema should be a citable artefact.
>
> What's more, the schema for code generation might vary from the one that
> you publish. The most likely reason for that variation would be if you
> were doing something like putting extra JAXB binding metadata in there,
> such as I've done on:
>
>
> https://github.com/taverna-incubator/taverna-plugin-component/blob/master/taverna-component-activity/src/main/resources/NewMyExperimentSchema.xsd
>
> (Hmm, and I see that I've put that XSD in the wrong place. Do as I say,
> not as I do… :-D)
>
> Donal.
>
--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/0000-0001-9842-9718
Re: Practice-release of taverna-language? [MENTOR] [RELEASE]
Posted by "Donal K. Fellows" <do...@manchester.ac.uk>.
On 23/01/2015 15:55, Stian Soiland-Reyes wrote:
> The scufl2-rdfxml XSDs, although also used for code generation, are a
> formal part of the scufl2 language definitions (as the ontologies) and
> are in src/main/resources exactly to be exposed in the JAR - I'm not
> sure, but this might be used by a test somewhere.
>
> Arguably if you are in Java you could be using the scufl2 API instead
> of dealing with the XSD - but who are we to decide that? :)
>
>
> Perhaps the "official" SCUFL2 XSDs (and the ontologies which are now
> hidden in scufl2-rdf/src/main/resources/something) should be in a
> separate module taverna-scufl2-schemas -- similar to
> https://github.com/taverna-incubator/incubator-taverna-osgi/tree/master/taverna-osgi-schemas/
> which I found rather clean. Thoughts?
My take? I've never seen the need for shipping the XSDs in the JAR (as
opposed to a source-jar), not unless they're going to be directly used
at runtime. A straight document should just be published online
somewhere where both people and code can read it. They're also the sort
of thing that it might make a load of sense to get a DOI for; a
significant schema should be a citable artefact.
What's more, the schema for code generation might vary from the one that
you publish. The most likely reason for that variation would be if you
were doing something like putting extra JAXB binding metadata in there,
such as I've done on:
https://github.com/taverna-incubator/taverna-plugin-component/blob/master/taverna-component-activity/src/main/resources/NewMyExperimentSchema.xsd
(Hmm, and I see that I've put that XSD in the wrong place. Do as I say,
not as I do… :-D)
Donal.
Re: Practice-release of taverna-language? [MENTOR] [RELEASE]
Posted by Stian Soiland-Reyes <so...@cs.manchester.ac.uk>.
+1 - I think the reasoning behind it is roughly like you said - XSDs
only for code generation are in the default for the code generating
plugin, e.g. src/main/xsd.
The scufl2-rdfxml XSDs, although also used for code generation, are a
formal part of the scufl2 language definitions (as the ontologies) and
are in src/main/resources exactly to be exposed in the JAR - I'm not
sure, but this might be used by a test somewhere.
Arguably if you are in Java you could be using the scufl2 API instead
of dealing with the XSD - but who are we to decide that? :)
Perhaps the "official" SCUFL2 XSDs (and the ontologies which are now
hidden in scufl2-rdf/src/main/resources/something) should be in a
separate module taverna-scufl2-schemas -- similar to
https://github.com/taverna-incubator/incubator-taverna-osgi/tree/master/taverna-osgi-schemas/
which I found rather clean. Thoughts?
They are also meant to be published on
http://ns.taverna.org.uk/2010/scufl2 (the namespace) - but I just
notice this was missing the XSDs. (added - now
http://ns.taverna.org.uk/2010/scufl2.xsd and content negotiation for
application/xml works)
On 23 January 2015 at 14:21, Donal K. Fellows
<do...@manchester.ac.uk> wrote:
> On 23/01/2015 14:05, alaninmcr wrote:
>>
>> There is also inconsistency between where different packages keep xsd's.
>> taverna-robundle has them in src/main/xsd but scufl2-rdfxml has them in
>> src/main/resources/org/... and taverna-scufl2-ucfpackage has them back
>> in src/main/xsd again. It may seem trivial but it's confusing and I
>> think best to sort out.
>
>
> It all depends on whether the XSD is to be shipped in the binary build.
>
> If you want the XSD to ship in the binary build (i.e, the JAR), you
> should put them beneath src/main/resources; those are all copied
> (typically with substitutions applied) by the maven-resources-plugin to
> the JAR.
>
> If you do not want the XSD to ship (e.g., because you're just using it
> for code generation) then put it somewhere else, e.g., src/main/xsd. The
> plugin that uses the XSDs may need to be told where they are, but I've
> never seen one that couldn't do it.
>
> It all comes down to whether the binary build users need a copy of the
> XSD. My take is that it's probably not necessary unless you're doing
> *very* fancy stuff (fancier than I ever needed for Taverna Server); JAXB
> can generate a serviceable one for you from the JAR if asked nicely.
>
> Donal.
>
--
Stian Soiland-Reyes, eScience Lab
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
Re: Practice-release of taverna-language? [MENTOR] [RELEASE]
Posted by "Donal K. Fellows" <do...@manchester.ac.uk>.
On 23/01/2015 14:05, alaninmcr wrote:
> There is also inconsistency between where different packages keep xsd's.
> taverna-robundle has them in src/main/xsd but scufl2-rdfxml has them in
> src/main/resources/org/... and taverna-scufl2-ucfpackage has them back
> in src/main/xsd again. It may seem trivial but it's confusing and I
> think best to sort out.
It all depends on whether the XSD is to be shipped in the binary build.
If you want the XSD to ship in the binary build (i.e, the JAR), you
should put them beneath src/main/resources; those are all copied
(typically with substitutions applied) by the maven-resources-plugin to
the JAR.
If you do not want the XSD to ship (e.g., because you're just using it
for code generation) then put it somewhere else, e.g., src/main/xsd. The
plugin that uses the XSDs may need to be told where they are, but I've
never seen one that couldn't do it.
It all comes down to whether the binary build users need a copy of the
XSD. My take is that it's probably not necessary unless you're doing
*very* fancy stuff (fancier than I ever needed for Taverna Server); JAXB
can generate a serviceable one for you from the JAR if asked nicely.
Donal.
Re: Practice-release of taverna-language? [MENTOR] [RELEASE]
Posted by alaninmcr <al...@googlemail.com>.
On 23/01/2015 13:54, Stian Soiland-Reyes wrote:
> Hi,
>
> The IP clearance from Manchester is pulling out (we are pinging every
> day now - any updates, Shoaib?)
I hope you do not actually mean "pulling out".
> .. so what if we do a practice-release-candidate of taverna-language?
> After Alan's package rename and (I think today) he's putting in the
> Apache headers, it should in theory be ready to go. It builds and run
> fine, as far as I can see.
I still need to check the licensing of any referenced artifacts.
There is also inconsistency between where different packages keep xsd's.
taverna-robundle has them in src/main/xsd but scufl2-rdfxml has them in
src/main/resources/org/... and taverna-scufl2-ucfpackage has them back
in src/main/xsd again. It may seem trivial but it's confusing and I
think best to sort out.
> That is we do the preparation and build and figure out (and document)
> the release procedure - and then we test and vote internally over that
> release candidate? The difference from "proper release candidate" is
> that it won't go anywhere on a successful vote.
I think we can do that once the licensing of referenced artifacts is
sorted out. Moving the xsd's can wait until the proper RC.
[snip]
Alan