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 2016/02/28 00:33:04 UTC
[DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Use this thread to discuss any issues with RC5 which is currently
under VOTE. If needed we'll also make Jira issues.
Under the corresponding [VOTE] thread - only reply with your vote,
e.g. "+1". It is a single vote for releasing all three artifacts at
once.
Vote thread:
http://apache-taverna-dev.markmail.org/thread/vfwbtfdpie4t24ng
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and
taverna-osgi-0.2.1
Posted by Andy Seaborne <an...@apache.org>.
On 01/03/16 11:22, alaninmcr wrote:
> For dmitry mainly,
>
> You probably have to put
>
> +1
>
> in the VOTE message. It's not enough to say it worked :)
>
> Alan
>
>
>
All - you ought to confirm you have checked the NOTICE and LICENSE (or not).
Andy
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and
taverna-osgi-0.2.1
Posted by Dmitry <re...@list.ru>.
OK (vale :-) )
+1.
D.
On 3/1/2016 12:22 PM, alaninmcr wrote:
> For dmitry mainly,
>
> You probably have to put
>
> +1
>
> in the VOTE message. It's not enough to say it worked :)
>
> Alan
>
>
>
>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and
taverna-osgi-0.2.1
Posted by alaninmcr <al...@googlemail.com>.
For dmitry mainly,
You probably have to put
+1
in the VOTE message. It's not enough to say it worked :)
Alan
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Gale Naylor <Ga...@noventussolutions.com>.
RE: collecting release testing tips
I agree. I have several pages of notes, plus these emails. I thought I'd
start a wiki page, unless someone else wants to.
On Wed, Mar 2, 2016, 4:05 AM Ian Dunlop <ia...@gmail.com> wrote:
> Hello,
>
> I think we need to capture all these tricks somewhere. Stian suggested we
> propose updating the 'official' apache release page - sounds like a good
> idea - but I think we could add it to the taverna pages first and then
> maybe send a link to it to the (I don't know) incubator list to gauge
> interest.
>
> Cheers,
>
> Ian
>
> On 1 March 2016 at 22:42, Gale Naylor <Ga...@noventussolutions.com> wrote:
>
> > Thank you, Stian! Some of my questions I figured out today, but some I
> did
> > not, so I very much appreciate the hints and instructions.
> >
> >
> > On Tue, Mar 1, 2016 at 2:28 PM Stian Soiland-Reyes <st...@apache.org>
> > wrote:
> >
> > > Thanks for reviewing!
> > >
> > >
> > > > (1) How do I verify that the commit id in the downloaded files
> matches
> > > that
> > > > in the VOTE email? (I've looked on the internet, but have yet to find
> > > > anything helpful.)
> > >
> > > I don't think most people check this deeply.. but I guess at least one
> > > voter should.
> > >
> > > Here's what I do:
> > >
> > > mkdir 1 ; cd 1 # new folder
> > > git clone that-repository
> > > git checkout that-commit-id-from-the-email-asdfjaskdjfsakjdfksajdf
> > > rm -rf *
> > > unzip ../the-release-candidate.zip
> > > mv apache-taverna-*/* . (one level up)
> > > git status
> > >
> > > Git will then check the checksums of every file and let you know what
> > > has 'changed' (as it would believe you have edited it).
> > >
> > >
> > > Here's another way that doesn't require using the 'git' command:
> > >
> > > Download the git commit corresponding to the email by browsing for it
> on
> > > GitHub:
> > >
> > >
> > >
> >
> https://github.com/apache/incubator-taverna-language/tree/66866a5454ed23262c055f65155d7a195c68a17d
> > > Click "Download ZIP"
> > >
> > > mkdir 1 ; cd 1
> > > unzip ../66866a5454ed23262c055f65155d7a195c68a17d.zip
> > >
> > > cd ../ ; mkdir 2 ; cd 2
> > > unzip release-candidate.zip
> > >
> > > cd ..
> > > diff -uR 1 2
> > >
> > > The files that differ (and their differences!) will be shown.
> > >
> > > Make sure you don't have any target/ folders before diff-ing (run mvn
> > > clean to be sure)
> > >
> > > If you do the above with a git clone instead - remember that the zip
> > > doesn't include the .git/ folder - so you would have to delete the
> > > checked out .git folder before diffing. (Don't do this on your
> > > regular checkout as you would lose all local branches!)
> > >
> > >
> > >
> > > > (2) Are the "binary artifacts" in the target folders? Which files are
> > > > considered "binary artifacts?"
> > >
> > > Well, the target/ files are binary artifacts, but they (should) have
> > > been made by your build on your machine - not be part of the source
> > > ZIP.
> > >
> > >
> > > One thing to look out for is in the downloaded source ZIP that there
> > > are no unexpected binary artifacts in it *before you build* - e.g.
> > > there should not be any *.jars in there. (The source distribution
> > > should be 'clean'). We do have some *expected* binaries, pictures and
> > > test workflows for instance. As those can't have license headers they
> > > should be declared in NOTICE/LICENSE if they came from third-parties.
> > > (E.g. if we used a Creative Commons-licensed JPEG picture)
> > >
> > >
> > > In terms of release candidate, the binaries would be installers and
> > > JARs etc., under
> > > https://dist.apache.org/repos/dist/dev/incubator/taverna/binaries/
> > > (But there are none for this release candidate)
> > >
> > > ..in addition to the JARs that have been staged to the Maven repository
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachetaverna-1011/org/apache/taverna/
> > >
> > >
> > > > (3) How do I verify that the build produces the binaries? By visual
> > > > inspection? What am I looking for?
> > >
> > >
> > > As for checking the Maven repository, if you want to do it really
> > > proper you should check that all the JARs that are staged can be built
> > > from the downloaded release candidate ZIP - e.g. that your target/
> > > folder contains all of the same ones. If I do this, I do a recursive
> > > wget of the repository, and then compare the result of "find . -name
> > > '*jar'" in the wget-tree with */*/target/*.jar. I don't think most
> > > people do this.
> > >
> > > Paranoid-mode would be to download each JAR and check that they only
> > > have the same *.class files - but these would differ for every build
> > > and so can't be compared any further without lots of clever tooling -
> > > so nobody does this. (I think there should be an Apache-hosted tool or
> > > Maven plugin that could do this).
> > >
> > >
> > > Practically the best is just to click briefly into the repository in a
> > > browser and see there are not any 'additional' folders that shouldn't
> > > be there, e.g. we are now voting on taverna-maven-parent, taverna-osgi
> > > and taverna-language, and so we should not see
> > > org/apache/taverna/engine in there - as that is a group Id from
> > > taverna-engine.
> > >
> > > (We have already changed the groupIDs to correspond to the repository
> > > which corresponds to the release name, so at least that correspondance
> > > is easy to check on Taverna, but not so on many other projects).
> > >
> > >
> > > As binary releases from Apache Software Foundation are considered
> > > "convenience only" they are not crucial for the vote - the source
> > > release is the golden thing which everything else should be made from.
> > > Practically speaking "everyone" uses the JARs from Maven repository
> > > though, so I wouldn't dismiss them totally - at least one person in
> > > the vote should do such a check.
> > >
> > >
> > > > (4) How do I check the dependencies?
> > >
> > > mvn dependency:tree gives a nice list - but what should you check for?
> > > Well, it's mainly about licensing -
> > > http://www.apache.org/legal/resolved.html lists what is compatible as
> > > dependencies of an ASF release. Now you don't need to go through the
> > > list - but sometimes there are Well Known forbidden dependencies that
> > > People (tm) recognize -e.g. mysql-connector and Hibernate are banned
> > > as they are (L)GPL.
> > >
> > > Luckily there's another Maven plugin that can do the job:
> > >
> > > mvn license:aggregate-add-third-party
> > >
> > > cat target/generated-sources/license/THIRD-PARTY.txt | sort
> > >
> > > (Aduna BSD license) OpenRDF Sesame: HTTP client
> > > (org.openrdf.sesame:sesame-http-client:2.7.0 -
> > > http://www.openrdf.org/sesame-core/sesame-http/sesame-http-client/)
> > > (Aduna BSD license) OpenRDF Sesame: HTTP protocol
> > > (org.openrdf.sesame:sesame-http-protocol:2.7.0 -
> > > http://www.openrdf.org/sesame-core/sesame-http/sesame-http-protocol/)
> > > (..)
> > > (The Apache Software License, Version 2.0) Xerces2-j
> > > (xerces:xercesImpl:2.11.0 - https://xerces.apache.org/xerces2-j/)
> > > (Unknown license) commons-beanutils
> > > (commons-beanutils:commons-beanutils:1.7.0 - no url defined)
> > > (Unknown license) com.springsource.org.jaxen
> > > (org.jaxen:com.springsource.org.jaxen:1.1.1 - no url defined)
> > > (Unknown license) com.springsource.org.jdom
> > > (org.jdom:com.springsource.org.jdom:1.1.0 - no url defined)
> > > (Unknown license) Logging (commons-logging:commons-logging:1.0.3
> > > - http://jakarta.apache.org/commons/logging/)
> > >
> > > (BTW, those last 4 are already checked to be OK, see
> > > http://dev.mygrid.org.uk/wiki/display/developer/Third-party+licenses )
> > >
> > >
> > > > Regarding the build output: Since this is the first time I've done
> > this,
> > > I
> > > > don't know what's okay to ignore. Here is a summary of the warning
> > > messages
> > > > I received when I ran mvn clean install. I sent the output to two
> > > different
> > > > files using the following command (Windows 10/ GitBash): mvn clean
> > > install
> > > >> output1.txt 2> output2.txt. I appreciate any insight.
> > >
> > > Great! I think those should be tracked in JIRA as we want to reduce
> > > warnings.
> > >
> > >
> > >
> > > Generally with Maven, if it finishes with a big SUCCESS, then that's
> > > true. The warnings are more like warnings for the developers doing
> > > bad-practice-stuff than warnings about something going wrong with the
> > > build. Often the fixes are simple, like adding a @Deprecated tag
> > > where you delibately use old APIs, or actually follow the fix
> > > suggested by the warning.
> > >
> > > I think we want to follow Andy's advice and "release early, release
> > > often" - which entails a "good enough" - not "super-perfect".
> > > Obviously each committer votes independenly by their own quality
> > > measures.
> > >
> > > While Apache Software Foundation always says that community is king -
> > > the Apache name is still recognized by the public as a kind of
> > > "quality mark" - if that is deserved or not I won't comment on, but of
> > > course there is also a sense of pride in that we don't want to set the
> > > standard too low. :)
> > >
> > > (E.g. Taverna just cancelled 3 release candidates as they didn't pass
> > > all their tests on Windows - but the community of another Apache
> > > project might not consider Windows important enough to halt a release)
> > >
> > >
> > >
> > >
> > > --
> > > Stian Soiland-Reyes
> > > Apache Taverna (incubating), Apache Commons RDF (incubating)
> > > http://orcid.org/0000-0001-9842-9718
> > >
> >
>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Stian Soiland-Reyes <st...@apache.org>.
No, I don't think we expose the Commons Collection types in any of our
APIs, so it should be easier to upgrade.
On 9 Mar 2016 20:02, "Gale Naylor" <Ga...@noventussolutions.com> wrote:
> Doesn't this pull request to Upgrade Apache Commons Collections to v3.2.2
> also
> affect Scufl2 API?
>
> http://mail-archives.apache.org/mod_mbox/incubator-taverna-dev/201603.mbox/%3Cgit-pr-1-incubator-taverna-server%40git.apache.org%3E
>
>
> On Wed, Mar 2, 2016 at 6:30 PM Gale Naylor <Ga...@noventussolutions.com>
> wrote:
>
> > Draft of How to Review a Release and Vote and outline of How to Check a
> > Release are on the wiki. I plan to fix links and add detailed tips/tricks
> > from mailing list later. Feel free to add/delete anything and correct any
> > errors. (In general, my comments and questions are in italics.)
> >
> > Cheers!
> >
> > On Wed, Mar 2, 2016 at 11:04 AM Gale Naylor <GaleN@noventussolutions.com
> >
> > wrote:
> >
> >> Definitely. I'm already working on an offline document. I hope to have
> >> something on the wiki by EOD today (PST).
> >>
> >> On Wed, Mar 2, 2016, 10:34 AM Stian Soiland-Reyes <st...@apache.org>
> >> wrote:
> >>
> >>> +1! Would you be OK to start? I guess Andy's list is a good starting
> >>> point. I can add my "shell tricks" where they fit. (and then we can
> >>> remove the more evil ones :))
> >>>
> >>> On 2 March 2016 at 17:42, Gale Naylor <Ga...@noventussolutions.com>
> >>> wrote:
> >>> > I like the "what do i do now" section. What if we develop it in the
> >>> wiki
> >>> > and then, when we're happy with it, migrate it to the community
> >>> section of
> >>> > the website?
> >>> >
> >>> > On Wed, Mar 2, 2016 at 7:18 AM Stian Soiland-Reyes <stain@apache.org
> >
> >>> wrote:
> >>> >
> >>> >> Yeah, we can develop it in the wiki, or append it to
> >>> >> http://taverna.incubator.apache.org/community/releasing perhaps?
> >>> >>
> >>> >> There should be a "I received a VOTE email, what do I do now?"
> >>> section.
> >>> >>
> >>> >> On 2 March 2016 at 11:59, Ian Dunlop <ia...@gmail.com> wrote:
> >>> >> > Hello,
> >>> >> >
> >>> >> > I think we need to capture all these tricks somewhere. Stian
> >>> suggested we
> >>> >> > propose updating the 'official' apache release page - sounds like
> a
> >>> good
> >>> >> > idea - but I think we could add it to the taverna pages first and
> >>> then
> >>> >> > maybe send a link to it to the (I don't know) incubator list to
> >>> gauge
> >>> >> > interest.
> >>> >> >
> >>> >> > Cheers,
> >>> >> >
> >>> >> > Ian
> >>> >> >
> >>> >> > On 1 March 2016 at 22:42, Gale Naylor <
> GaleN@noventussolutions.com>
> >>> >> wrote:
> >>> >> >
> >>> >> >> Thank you, Stian! Some of my questions I figured out today, but
> >>> some I
> >>> >> did
> >>> >> >> not, so I very much appreciate the hints and instructions.
> >>> >> >>
> >>> >> >>
> >>> >> >> On Tue, Mar 1, 2016 at 2:28 PM Stian Soiland-Reyes <
> >>> stain@apache.org>
> >>> >> >> wrote:
> >>> >> >>
> >>> >> >> > Thanks for reviewing!
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > > (1) How do I verify that the commit id in the downloaded
> files
> >>> >> matches
> >>> >> >> > that
> >>> >> >> > > in the VOTE email? (I've looked on the internet, but have yet
> >>> to
> >>> >> find
> >>> >> >> > > anything helpful.)
> >>> >> >> >
> >>> >> >> > I don't think most people check this deeply.. but I guess at
> >>> least one
> >>> >> >> > voter should.
> >>> >> >> >
> >>> >> >> > Here's what I do:
> >>> >> >> >
> >>> >> >> > mkdir 1 ; cd 1 # new folder
> >>> >> >> > git clone that-repository
> >>> >> >> > git checkout
> >>> that-commit-id-from-the-email-asdfjaskdjfsakjdfksajdf
> >>> >> >> > rm -rf *
> >>> >> >> > unzip ../the-release-candidate.zip
> >>> >> >> > mv apache-taverna-*/* . (one level up)
> >>> >> >> > git status
> >>> >> >> >
> >>> >> >> > Git will then check the checksums of every file and let you
> know
> >>> what
> >>> >> >> > has 'changed' (as it would believe you have edited it).
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > Here's another way that doesn't require using the 'git'
> command:
> >>> >> >> >
> >>> >> >> > Download the git commit corresponding to the email by browsing
> >>> for it
> >>> >> on
> >>> >> >> > GitHub:
> >>> >> >> >
> >>> >> >> >
> >>> >> >> >
> >>> >> >>
> >>> >>
> >>>
> https://github.com/apache/incubator-taverna-language/tree/66866a5454ed23262c055f65155d7a195c68a17d
> >>> >> >> > Click "Download ZIP"
> >>> >> >> >
> >>> >> >> > mkdir 1 ; cd 1
> >>> >> >> > unzip ../66866a5454ed23262c055f65155d7a195c68a17d.zip
> >>> >> >> >
> >>> >> >> > cd ../ ; mkdir 2 ; cd 2
> >>> >> >> > unzip release-candidate.zip
> >>> >> >> >
> >>> >> >> > cd ..
> >>> >> >> > diff -uR 1 2
> >>> >> >> >
> >>> >> >> > The files that differ (and their differences!) will be shown.
> >>> >> >> >
> >>> >> >> > Make sure you don't have any target/ folders before diff-ing
> >>> (run mvn
> >>> >> >> > clean to be sure)
> >>> >> >> >
> >>> >> >> > If you do the above with a git clone instead - remember that
> the
> >>> zip
> >>> >> >> > doesn't include the .git/ folder - so you would have to delete
> >>> the
> >>> >> >> > checked out .git folder before diffing. (Don't do this on your
> >>> >> >> > regular checkout as you would lose all local branches!)
> >>> >> >> >
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > > (2) Are the "binary artifacts" in the target folders? Which
> >>> files
> >>> >> are
> >>> >> >> > > considered "binary artifacts?"
> >>> >> >> >
> >>> >> >> > Well, the target/ files are binary artifacts, but they (should)
> >>> have
> >>> >> >> > been made by your build on your machine - not be part of the
> >>> source
> >>> >> >> > ZIP.
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > One thing to look out for is in the downloaded source ZIP that
> >>> there
> >>> >> >> > are no unexpected binary artifacts in it *before you build* -
> >>> e.g.
> >>> >> >> > there should not be any *.jars in there. (The source
> >>> distribution
> >>> >> >> > should be 'clean'). We do have some *expected* binaries,
> >>> pictures and
> >>> >> >> > test workflows for instance. As those can't have license
> >>> headers they
> >>> >> >> > should be declared in NOTICE/LICENSE if they came from
> >>> third-parties.
> >>> >> >> > (E.g. if we used a Creative Commons-licensed JPEG picture)
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > In terms of release candidate, the binaries would be installers
> >>> and
> >>> >> >> > JARs etc., under
> >>> >> >> >
> >>> https://dist.apache.org/repos/dist/dev/incubator/taverna/binaries/
> >>> >> >> > (But there are none for this release candidate)
> >>> >> >> >
> >>> >> >> > ..in addition to the JARs that have been staged to the Maven
> >>> >> repository
> >>> >> >> >
> >>> >> >> >
> >>> >> >>
> >>> >>
> >>>
> https://repository.apache.org/content/repositories/orgapachetaverna-1011/org/apache/taverna/
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > > (3) How do I verify that the build produces the binaries? By
> >>> visual
> >>> >> >> > > inspection? What am I looking for?
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > As for checking the Maven repository, if you want to do it
> really
> >>> >> >> > proper you should check that all the JARs that are staged can
> be
> >>> built
> >>> >> >> > from the downloaded release candidate ZIP - e.g. that your
> >>> target/
> >>> >> >> > folder contains all of the same ones. If I do this, I do a
> >>> recursive
> >>> >> >> > wget of the repository, and then compare the result of "find .
> >>> -name
> >>> >> >> > '*jar'" in the wget-tree with */*/target/*.jar. I don't think
> >>> most
> >>> >> >> > people do this.
> >>> >> >> >
> >>> >> >> > Paranoid-mode would be to download each JAR and check that they
> >>> only
> >>> >> >> > have the same *.class files - but these would differ for every
> >>> build
> >>> >> >> > and so can't be compared any further without lots of clever
> >>> tooling -
> >>> >> >> > so nobody does this. (I think there should be an Apache-hosted
> >>> tool or
> >>> >> >> > Maven plugin that could do this).
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > Practically the best is just to click briefly into the
> >>> repository in a
> >>> >> >> > browser and see there are not any 'additional' folders that
> >>> shouldn't
> >>> >> >> > be there, e.g. we are now voting on taverna-maven-parent,
> >>> taverna-osgi
> >>> >> >> > and taverna-language, and so we should not see
> >>> >> >> > org/apache/taverna/engine in there - as that is a group Id from
> >>> >> >> > taverna-engine.
> >>> >> >> >
> >>> >> >> > (We have already changed the groupIDs to correspond to the
> >>> repository
> >>> >> >> > which corresponds to the release name, so at least that
> >>> correspondance
> >>> >> >> > is easy to check on Taverna, but not so on many other
> projects).
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > As binary releases from Apache Software Foundation are
> considered
> >>> >> >> > "convenience only" they are not crucial for the vote - the
> source
> >>> >> >> > release is the golden thing which everything else should be
> made
> >>> from.
> >>> >> >> > Practically speaking "everyone" uses the JARs from Maven
> >>> repository
> >>> >> >> > though, so I wouldn't dismiss them totally - at least one
> person
> >>> in
> >>> >> >> > the vote should do such a check.
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > > (4) How do I check the dependencies?
> >>> >> >> >
> >>> >> >> > mvn dependency:tree gives a nice list - but what should you
> >>> check for?
> >>> >> >> > Well, it's mainly about licensing -
> >>> >> >> > http://www.apache.org/legal/resolved.html lists what is
> >>> compatible as
> >>> >> >> > dependencies of an ASF release. Now you don't need to go
> >>> through the
> >>> >> >> > list - but sometimes there are Well Known forbidden
> dependencies
> >>> that
> >>> >> >> > People (tm) recognize -e.g. mysql-connector and Hibernate are
> >>> banned
> >>> >> >> > as they are (L)GPL.
> >>> >> >> >
> >>> >> >> > Luckily there's another Maven plugin that can do the job:
> >>> >> >> >
> >>> >> >> > mvn license:aggregate-add-third-party
> >>> >> >> >
> >>> >> >> > cat target/generated-sources/license/THIRD-PARTY.txt | sort
> >>> >> >> >
> >>> >> >> > (Aduna BSD license) OpenRDF Sesame: HTTP client
> >>> >> >> > (org.openrdf.sesame:sesame-http-client:2.7.0 -
> >>> >> >> >
> >>> http://www.openrdf.org/sesame-core/sesame-http/sesame-http-client/)
> >>> >> >> > (Aduna BSD license) OpenRDF Sesame: HTTP protocol
> >>> >> >> > (org.openrdf.sesame:sesame-http-protocol:2.7.0 -
> >>> >> >> >
> >>> http://www.openrdf.org/sesame-core/sesame-http/sesame-http-protocol/)
> >>> >> >> > (..)
> >>> >> >> > (The Apache Software License, Version 2.0) Xerces2-j
> >>> >> >> > (xerces:xercesImpl:2.11.0 -
> https://xerces.apache.org/xerces2-j/
> >>> )
> >>> >> >> > (Unknown license) commons-beanutils
> >>> >> >> > (commons-beanutils:commons-beanutils:1.7.0 - no url defined)
> >>> >> >> > (Unknown license) com.springsource.org.jaxen
> >>> >> >> > (org.jaxen:com.springsource.org.jaxen:1.1.1 - no url defined)
> >>> >> >> > (Unknown license) com.springsource.org.jdom
> >>> >> >> > (org.jdom:com.springsource.org.jdom:1.1.0 - no url defined)
> >>> >> >> > (Unknown license) Logging
> >>> (commons-logging:commons-logging:1.0.3
> >>> >> >> > - http://jakarta.apache.org/commons/logging/)
> >>> >> >> >
> >>> >> >> > (BTW, those last 4 are already checked to be OK, see
> >>> >> >> >
> >>> http://dev.mygrid.org.uk/wiki/display/developer/Third-party+licenses
> >>> >> )
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > > Regarding the build output: Since this is the first time I've
> >>> done
> >>> >> >> this,
> >>> >> >> > I
> >>> >> >> > > don't know what's okay to ignore. Here is a summary of the
> >>> warning
> >>> >> >> > messages
> >>> >> >> > > I received when I ran mvn clean install. I sent the output to
> >>> two
> >>> >> >> > different
> >>> >> >> > > files using the following command (Windows 10/ GitBash): mvn
> >>> clean
> >>> >> >> > install
> >>> >> >> > >> output1.txt 2> output2.txt. I appreciate any insight.
> >>> >> >> >
> >>> >> >> > Great! I think those should be tracked in JIRA as we want to
> >>> reduce
> >>> >> >> > warnings.
> >>> >> >> >
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > Generally with Maven, if it finishes with a big SUCCESS, then
> >>> that's
> >>> >> >> > true. The warnings are more like warnings for the developers
> >>> doing
> >>> >> >> > bad-practice-stuff than warnings about something going wrong
> >>> with the
> >>> >> >> > build. Often the fixes are simple, like adding a @Deprecated
> >>> tag
> >>> >> >> > where you delibately use old APIs, or actually follow the fix
> >>> >> >> > suggested by the warning.
> >>> >> >> >
> >>> >> >> > I think we want to follow Andy's advice and "release early,
> >>> release
> >>> >> >> > often" - which entails a "good enough" - not "super-perfect".
> >>> >> >> > Obviously each committer votes independenly by their own
> quality
> >>> >> >> > measures.
> >>> >> >> >
> >>> >> >> > While Apache Software Foundation always says that community is
> >>> king -
> >>> >> >> > the Apache name is still recognized by the public as a kind of
> >>> >> >> > "quality mark" - if that is deserved or not I won't comment on,
> >>> but of
> >>> >> >> > course there is also a sense of pride in that we don't want to
> >>> set the
> >>> >> >> > standard too low. :)
> >>> >> >> >
> >>> >> >> > (E.g. Taverna just cancelled 3 release candidates as they
> didn't
> >>> pass
> >>> >> >> > all their tests on Windows - but the community of another
> Apache
> >>> >> >> > project might not consider Windows important enough to halt a
> >>> release)
> >>> >> >> >
> >>> >> >> >
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > --
> >>> >> >> > Stian Soiland-Reyes
> >>> >> >> > Apache Taverna (incubating), Apache Commons RDF (incubating)
> >>> >> >> > http://orcid.org/0000-0001-9842-9718
> >>> >> >> >
> >>> >> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Stian Soiland-Reyes
> >>> >> Apache Taverna (incubating), Apache Commons RDF (incubating)
> >>> >> http://orcid.org/0000-0001-9842-9718
> >>> >>
> >>>
> >>>
> >>>
> >>> --
> >>> Stian Soiland-Reyes
> >>> Apache Taverna (incubating), Apache Commons RDF (incubating)
> >>> http://orcid.org/0000-0001-9842-9718
> >>>
> >>
>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Gale Naylor <Ga...@noventussolutions.com>.
Doesn't this pull request to Upgrade Apache Commons Collections to v3.2.2 also
affect Scufl2 API?
http://mail-archives.apache.org/mod_mbox/incubator-taverna-dev/201603.mbox/%3Cgit-pr-1-incubator-taverna-server%40git.apache.org%3E
On Wed, Mar 2, 2016 at 6:30 PM Gale Naylor <Ga...@noventussolutions.com>
wrote:
> Draft of How to Review a Release and Vote and outline of How to Check a
> Release are on the wiki. I plan to fix links and add detailed tips/tricks
> from mailing list later. Feel free to add/delete anything and correct any
> errors. (In general, my comments and questions are in italics.)
>
> Cheers!
>
> On Wed, Mar 2, 2016 at 11:04 AM Gale Naylor <Ga...@noventussolutions.com>
> wrote:
>
>> Definitely. I'm already working on an offline document. I hope to have
>> something on the wiki by EOD today (PST).
>>
>> On Wed, Mar 2, 2016, 10:34 AM Stian Soiland-Reyes <st...@apache.org>
>> wrote:
>>
>>> +1! Would you be OK to start? I guess Andy's list is a good starting
>>> point. I can add my "shell tricks" where they fit. (and then we can
>>> remove the more evil ones :))
>>>
>>> On 2 March 2016 at 17:42, Gale Naylor <Ga...@noventussolutions.com>
>>> wrote:
>>> > I like the "what do i do now" section. What if we develop it in the
>>> wiki
>>> > and then, when we're happy with it, migrate it to the community
>>> section of
>>> > the website?
>>> >
>>> > On Wed, Mar 2, 2016 at 7:18 AM Stian Soiland-Reyes <st...@apache.org>
>>> wrote:
>>> >
>>> >> Yeah, we can develop it in the wiki, or append it to
>>> >> http://taverna.incubator.apache.org/community/releasing perhaps?
>>> >>
>>> >> There should be a "I received a VOTE email, what do I do now?"
>>> section.
>>> >>
>>> >> On 2 March 2016 at 11:59, Ian Dunlop <ia...@gmail.com> wrote:
>>> >> > Hello,
>>> >> >
>>> >> > I think we need to capture all these tricks somewhere. Stian
>>> suggested we
>>> >> > propose updating the 'official' apache release page - sounds like a
>>> good
>>> >> > idea - but I think we could add it to the taverna pages first and
>>> then
>>> >> > maybe send a link to it to the (I don't know) incubator list to
>>> gauge
>>> >> > interest.
>>> >> >
>>> >> > Cheers,
>>> >> >
>>> >> > Ian
>>> >> >
>>> >> > On 1 March 2016 at 22:42, Gale Naylor <Ga...@noventussolutions.com>
>>> >> wrote:
>>> >> >
>>> >> >> Thank you, Stian! Some of my questions I figured out today, but
>>> some I
>>> >> did
>>> >> >> not, so I very much appreciate the hints and instructions.
>>> >> >>
>>> >> >>
>>> >> >> On Tue, Mar 1, 2016 at 2:28 PM Stian Soiland-Reyes <
>>> stain@apache.org>
>>> >> >> wrote:
>>> >> >>
>>> >> >> > Thanks for reviewing!
>>> >> >> >
>>> >> >> >
>>> >> >> > > (1) How do I verify that the commit id in the downloaded files
>>> >> matches
>>> >> >> > that
>>> >> >> > > in the VOTE email? (I've looked on the internet, but have yet
>>> to
>>> >> find
>>> >> >> > > anything helpful.)
>>> >> >> >
>>> >> >> > I don't think most people check this deeply.. but I guess at
>>> least one
>>> >> >> > voter should.
>>> >> >> >
>>> >> >> > Here's what I do:
>>> >> >> >
>>> >> >> > mkdir 1 ; cd 1 # new folder
>>> >> >> > git clone that-repository
>>> >> >> > git checkout
>>> that-commit-id-from-the-email-asdfjaskdjfsakjdfksajdf
>>> >> >> > rm -rf *
>>> >> >> > unzip ../the-release-candidate.zip
>>> >> >> > mv apache-taverna-*/* . (one level up)
>>> >> >> > git status
>>> >> >> >
>>> >> >> > Git will then check the checksums of every file and let you know
>>> what
>>> >> >> > has 'changed' (as it would believe you have edited it).
>>> >> >> >
>>> >> >> >
>>> >> >> > Here's another way that doesn't require using the 'git' command:
>>> >> >> >
>>> >> >> > Download the git commit corresponding to the email by browsing
>>> for it
>>> >> on
>>> >> >> > GitHub:
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >>
>>> https://github.com/apache/incubator-taverna-language/tree/66866a5454ed23262c055f65155d7a195c68a17d
>>> >> >> > Click "Download ZIP"
>>> >> >> >
>>> >> >> > mkdir 1 ; cd 1
>>> >> >> > unzip ../66866a5454ed23262c055f65155d7a195c68a17d.zip
>>> >> >> >
>>> >> >> > cd ../ ; mkdir 2 ; cd 2
>>> >> >> > unzip release-candidate.zip
>>> >> >> >
>>> >> >> > cd ..
>>> >> >> > diff -uR 1 2
>>> >> >> >
>>> >> >> > The files that differ (and their differences!) will be shown.
>>> >> >> >
>>> >> >> > Make sure you don't have any target/ folders before diff-ing
>>> (run mvn
>>> >> >> > clean to be sure)
>>> >> >> >
>>> >> >> > If you do the above with a git clone instead - remember that the
>>> zip
>>> >> >> > doesn't include the .git/ folder - so you would have to delete
>>> the
>>> >> >> > checked out .git folder before diffing. (Don't do this on your
>>> >> >> > regular checkout as you would lose all local branches!)
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > > (2) Are the "binary artifacts" in the target folders? Which
>>> files
>>> >> are
>>> >> >> > > considered "binary artifacts?"
>>> >> >> >
>>> >> >> > Well, the target/ files are binary artifacts, but they (should)
>>> have
>>> >> >> > been made by your build on your machine - not be part of the
>>> source
>>> >> >> > ZIP.
>>> >> >> >
>>> >> >> >
>>> >> >> > One thing to look out for is in the downloaded source ZIP that
>>> there
>>> >> >> > are no unexpected binary artifacts in it *before you build* -
>>> e.g.
>>> >> >> > there should not be any *.jars in there. (The source
>>> distribution
>>> >> >> > should be 'clean'). We do have some *expected* binaries,
>>> pictures and
>>> >> >> > test workflows for instance. As those can't have license
>>> headers they
>>> >> >> > should be declared in NOTICE/LICENSE if they came from
>>> third-parties.
>>> >> >> > (E.g. if we used a Creative Commons-licensed JPEG picture)
>>> >> >> >
>>> >> >> >
>>> >> >> > In terms of release candidate, the binaries would be installers
>>> and
>>> >> >> > JARs etc., under
>>> >> >> >
>>> https://dist.apache.org/repos/dist/dev/incubator/taverna/binaries/
>>> >> >> > (But there are none for this release candidate)
>>> >> >> >
>>> >> >> > ..in addition to the JARs that have been staged to the Maven
>>> >> repository
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >>
>>> https://repository.apache.org/content/repositories/orgapachetaverna-1011/org/apache/taverna/
>>> >> >> >
>>> >> >> >
>>> >> >> > > (3) How do I verify that the build produces the binaries? By
>>> visual
>>> >> >> > > inspection? What am I looking for?
>>> >> >> >
>>> >> >> >
>>> >> >> > As for checking the Maven repository, if you want to do it really
>>> >> >> > proper you should check that all the JARs that are staged can be
>>> built
>>> >> >> > from the downloaded release candidate ZIP - e.g. that your
>>> target/
>>> >> >> > folder contains all of the same ones. If I do this, I do a
>>> recursive
>>> >> >> > wget of the repository, and then compare the result of "find .
>>> -name
>>> >> >> > '*jar'" in the wget-tree with */*/target/*.jar. I don't think
>>> most
>>> >> >> > people do this.
>>> >> >> >
>>> >> >> > Paranoid-mode would be to download each JAR and check that they
>>> only
>>> >> >> > have the same *.class files - but these would differ for every
>>> build
>>> >> >> > and so can't be compared any further without lots of clever
>>> tooling -
>>> >> >> > so nobody does this. (I think there should be an Apache-hosted
>>> tool or
>>> >> >> > Maven plugin that could do this).
>>> >> >> >
>>> >> >> >
>>> >> >> > Practically the best is just to click briefly into the
>>> repository in a
>>> >> >> > browser and see there are not any 'additional' folders that
>>> shouldn't
>>> >> >> > be there, e.g. we are now voting on taverna-maven-parent,
>>> taverna-osgi
>>> >> >> > and taverna-language, and so we should not see
>>> >> >> > org/apache/taverna/engine in there - as that is a group Id from
>>> >> >> > taverna-engine.
>>> >> >> >
>>> >> >> > (We have already changed the groupIDs to correspond to the
>>> repository
>>> >> >> > which corresponds to the release name, so at least that
>>> correspondance
>>> >> >> > is easy to check on Taverna, but not so on many other projects).
>>> >> >> >
>>> >> >> >
>>> >> >> > As binary releases from Apache Software Foundation are considered
>>> >> >> > "convenience only" they are not crucial for the vote - the source
>>> >> >> > release is the golden thing which everything else should be made
>>> from.
>>> >> >> > Practically speaking "everyone" uses the JARs from Maven
>>> repository
>>> >> >> > though, so I wouldn't dismiss them totally - at least one person
>>> in
>>> >> >> > the vote should do such a check.
>>> >> >> >
>>> >> >> >
>>> >> >> > > (4) How do I check the dependencies?
>>> >> >> >
>>> >> >> > mvn dependency:tree gives a nice list - but what should you
>>> check for?
>>> >> >> > Well, it's mainly about licensing -
>>> >> >> > http://www.apache.org/legal/resolved.html lists what is
>>> compatible as
>>> >> >> > dependencies of an ASF release. Now you don't need to go
>>> through the
>>> >> >> > list - but sometimes there are Well Known forbidden dependencies
>>> that
>>> >> >> > People (tm) recognize -e.g. mysql-connector and Hibernate are
>>> banned
>>> >> >> > as they are (L)GPL.
>>> >> >> >
>>> >> >> > Luckily there's another Maven plugin that can do the job:
>>> >> >> >
>>> >> >> > mvn license:aggregate-add-third-party
>>> >> >> >
>>> >> >> > cat target/generated-sources/license/THIRD-PARTY.txt | sort
>>> >> >> >
>>> >> >> > (Aduna BSD license) OpenRDF Sesame: HTTP client
>>> >> >> > (org.openrdf.sesame:sesame-http-client:2.7.0 -
>>> >> >> >
>>> http://www.openrdf.org/sesame-core/sesame-http/sesame-http-client/)
>>> >> >> > (Aduna BSD license) OpenRDF Sesame: HTTP protocol
>>> >> >> > (org.openrdf.sesame:sesame-http-protocol:2.7.0 -
>>> >> >> >
>>> http://www.openrdf.org/sesame-core/sesame-http/sesame-http-protocol/)
>>> >> >> > (..)
>>> >> >> > (The Apache Software License, Version 2.0) Xerces2-j
>>> >> >> > (xerces:xercesImpl:2.11.0 - https://xerces.apache.org/xerces2-j/
>>> )
>>> >> >> > (Unknown license) commons-beanutils
>>> >> >> > (commons-beanutils:commons-beanutils:1.7.0 - no url defined)
>>> >> >> > (Unknown license) com.springsource.org.jaxen
>>> >> >> > (org.jaxen:com.springsource.org.jaxen:1.1.1 - no url defined)
>>> >> >> > (Unknown license) com.springsource.org.jdom
>>> >> >> > (org.jdom:com.springsource.org.jdom:1.1.0 - no url defined)
>>> >> >> > (Unknown license) Logging
>>> (commons-logging:commons-logging:1.0.3
>>> >> >> > - http://jakarta.apache.org/commons/logging/)
>>> >> >> >
>>> >> >> > (BTW, those last 4 are already checked to be OK, see
>>> >> >> >
>>> http://dev.mygrid.org.uk/wiki/display/developer/Third-party+licenses
>>> >> )
>>> >> >> >
>>> >> >> >
>>> >> >> > > Regarding the build output: Since this is the first time I've
>>> done
>>> >> >> this,
>>> >> >> > I
>>> >> >> > > don't know what's okay to ignore. Here is a summary of the
>>> warning
>>> >> >> > messages
>>> >> >> > > I received when I ran mvn clean install. I sent the output to
>>> two
>>> >> >> > different
>>> >> >> > > files using the following command (Windows 10/ GitBash): mvn
>>> clean
>>> >> >> > install
>>> >> >> > >> output1.txt 2> output2.txt. I appreciate any insight.
>>> >> >> >
>>> >> >> > Great! I think those should be tracked in JIRA as we want to
>>> reduce
>>> >> >> > warnings.
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > Generally with Maven, if it finishes with a big SUCCESS, then
>>> that's
>>> >> >> > true. The warnings are more like warnings for the developers
>>> doing
>>> >> >> > bad-practice-stuff than warnings about something going wrong
>>> with the
>>> >> >> > build. Often the fixes are simple, like adding a @Deprecated
>>> tag
>>> >> >> > where you delibately use old APIs, or actually follow the fix
>>> >> >> > suggested by the warning.
>>> >> >> >
>>> >> >> > I think we want to follow Andy's advice and "release early,
>>> release
>>> >> >> > often" - which entails a "good enough" - not "super-perfect".
>>> >> >> > Obviously each committer votes independenly by their own quality
>>> >> >> > measures.
>>> >> >> >
>>> >> >> > While Apache Software Foundation always says that community is
>>> king -
>>> >> >> > the Apache name is still recognized by the public as a kind of
>>> >> >> > "quality mark" - if that is deserved or not I won't comment on,
>>> but of
>>> >> >> > course there is also a sense of pride in that we don't want to
>>> set the
>>> >> >> > standard too low. :)
>>> >> >> >
>>> >> >> > (E.g. Taverna just cancelled 3 release candidates as they didn't
>>> pass
>>> >> >> > all their tests on Windows - but the community of another Apache
>>> >> >> > project might not consider Windows important enough to halt a
>>> release)
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > --
>>> >> >> > Stian Soiland-Reyes
>>> >> >> > Apache Taverna (incubating), Apache Commons RDF (incubating)
>>> >> >> > http://orcid.org/0000-0001-9842-9718
>>> >> >> >
>>> >> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Stian Soiland-Reyes
>>> >> Apache Taverna (incubating), Apache Commons RDF (incubating)
>>> >> http://orcid.org/0000-0001-9842-9718
>>> >>
>>>
>>>
>>>
>>> --
>>> Stian Soiland-Reyes
>>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>>> http://orcid.org/0000-0001-9842-9718
>>>
>>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Gale Naylor <Ga...@noventussolutions.com>.
Draft of How to Review a Release and Vote and outline of How to Check a
Release are on the wiki. I plan to fix links and add detailed tips/tricks
from mailing list later. Feel free to add/delete anything and correct any
errors. (In general, my comments and questions are in italics.)
Cheers!
On Wed, Mar 2, 2016 at 11:04 AM Gale Naylor <Ga...@noventussolutions.com>
wrote:
> Definitely. I'm already working on an offline document. I hope to have
> something on the wiki by EOD today (PST).
>
> On Wed, Mar 2, 2016, 10:34 AM Stian Soiland-Reyes <st...@apache.org>
> wrote:
>
>> +1! Would you be OK to start? I guess Andy's list is a good starting
>> point. I can add my "shell tricks" where they fit. (and then we can
>> remove the more evil ones :))
>>
>> On 2 March 2016 at 17:42, Gale Naylor <Ga...@noventussolutions.com>
>> wrote:
>> > I like the "what do i do now" section. What if we develop it in the wiki
>> > and then, when we're happy with it, migrate it to the community section
>> of
>> > the website?
>> >
>> > On Wed, Mar 2, 2016 at 7:18 AM Stian Soiland-Reyes <st...@apache.org>
>> wrote:
>> >
>> >> Yeah, we can develop it in the wiki, or append it to
>> >> http://taverna.incubator.apache.org/community/releasing perhaps?
>> >>
>> >> There should be a "I received a VOTE email, what do I do now?" section.
>> >>
>> >> On 2 March 2016 at 11:59, Ian Dunlop <ia...@gmail.com> wrote:
>> >> > Hello,
>> >> >
>> >> > I think we need to capture all these tricks somewhere. Stian
>> suggested we
>> >> > propose updating the 'official' apache release page - sounds like a
>> good
>> >> > idea - but I think we could add it to the taverna pages first and
>> then
>> >> > maybe send a link to it to the (I don't know) incubator list to gauge
>> >> > interest.
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Ian
>> >> >
>> >> > On 1 March 2016 at 22:42, Gale Naylor <Ga...@noventussolutions.com>
>> >> wrote:
>> >> >
>> >> >> Thank you, Stian! Some of my questions I figured out today, but
>> some I
>> >> did
>> >> >> not, so I very much appreciate the hints and instructions.
>> >> >>
>> >> >>
>> >> >> On Tue, Mar 1, 2016 at 2:28 PM Stian Soiland-Reyes <
>> stain@apache.org>
>> >> >> wrote:
>> >> >>
>> >> >> > Thanks for reviewing!
>> >> >> >
>> >> >> >
>> >> >> > > (1) How do I verify that the commit id in the downloaded files
>> >> matches
>> >> >> > that
>> >> >> > > in the VOTE email? (I've looked on the internet, but have yet to
>> >> find
>> >> >> > > anything helpful.)
>> >> >> >
>> >> >> > I don't think most people check this deeply.. but I guess at
>> least one
>> >> >> > voter should.
>> >> >> >
>> >> >> > Here's what I do:
>> >> >> >
>> >> >> > mkdir 1 ; cd 1 # new folder
>> >> >> > git clone that-repository
>> >> >> > git checkout that-commit-id-from-the-email-asdfjaskdjfsakjdfksajdf
>> >> >> > rm -rf *
>> >> >> > unzip ../the-release-candidate.zip
>> >> >> > mv apache-taverna-*/* . (one level up)
>> >> >> > git status
>> >> >> >
>> >> >> > Git will then check the checksums of every file and let you know
>> what
>> >> >> > has 'changed' (as it would believe you have edited it).
>> >> >> >
>> >> >> >
>> >> >> > Here's another way that doesn't require using the 'git' command:
>> >> >> >
>> >> >> > Download the git commit corresponding to the email by browsing
>> for it
>> >> on
>> >> >> > GitHub:
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >>
>> https://github.com/apache/incubator-taverna-language/tree/66866a5454ed23262c055f65155d7a195c68a17d
>> >> >> > Click "Download ZIP"
>> >> >> >
>> >> >> > mkdir 1 ; cd 1
>> >> >> > unzip ../66866a5454ed23262c055f65155d7a195c68a17d.zip
>> >> >> >
>> >> >> > cd ../ ; mkdir 2 ; cd 2
>> >> >> > unzip release-candidate.zip
>> >> >> >
>> >> >> > cd ..
>> >> >> > diff -uR 1 2
>> >> >> >
>> >> >> > The files that differ (and their differences!) will be shown.
>> >> >> >
>> >> >> > Make sure you don't have any target/ folders before diff-ing (run
>> mvn
>> >> >> > clean to be sure)
>> >> >> >
>> >> >> > If you do the above with a git clone instead - remember that the
>> zip
>> >> >> > doesn't include the .git/ folder - so you would have to delete the
>> >> >> > checked out .git folder before diffing. (Don't do this on your
>> >> >> > regular checkout as you would lose all local branches!)
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > > (2) Are the "binary artifacts" in the target folders? Which
>> files
>> >> are
>> >> >> > > considered "binary artifacts?"
>> >> >> >
>> >> >> > Well, the target/ files are binary artifacts, but they (should)
>> have
>> >> >> > been made by your build on your machine - not be part of the
>> source
>> >> >> > ZIP.
>> >> >> >
>> >> >> >
>> >> >> > One thing to look out for is in the downloaded source ZIP that
>> there
>> >> >> > are no unexpected binary artifacts in it *before you build* - e.g.
>> >> >> > there should not be any *.jars in there. (The source distribution
>> >> >> > should be 'clean'). We do have some *expected* binaries, pictures
>> and
>> >> >> > test workflows for instance. As those can't have license headers
>> they
>> >> >> > should be declared in NOTICE/LICENSE if they came from
>> third-parties.
>> >> >> > (E.g. if we used a Creative Commons-licensed JPEG picture)
>> >> >> >
>> >> >> >
>> >> >> > In terms of release candidate, the binaries would be installers
>> and
>> >> >> > JARs etc., under
>> >> >> >
>> https://dist.apache.org/repos/dist/dev/incubator/taverna/binaries/
>> >> >> > (But there are none for this release candidate)
>> >> >> >
>> >> >> > ..in addition to the JARs that have been staged to the Maven
>> >> repository
>> >> >> >
>> >> >> >
>> >> >>
>> >>
>> https://repository.apache.org/content/repositories/orgapachetaverna-1011/org/apache/taverna/
>> >> >> >
>> >> >> >
>> >> >> > > (3) How do I verify that the build produces the binaries? By
>> visual
>> >> >> > > inspection? What am I looking for?
>> >> >> >
>> >> >> >
>> >> >> > As for checking the Maven repository, if you want to do it really
>> >> >> > proper you should check that all the JARs that are staged can be
>> built
>> >> >> > from the downloaded release candidate ZIP - e.g. that your target/
>> >> >> > folder contains all of the same ones. If I do this, I do a
>> recursive
>> >> >> > wget of the repository, and then compare the result of "find .
>> -name
>> >> >> > '*jar'" in the wget-tree with */*/target/*.jar. I don't think
>> most
>> >> >> > people do this.
>> >> >> >
>> >> >> > Paranoid-mode would be to download each JAR and check that they
>> only
>> >> >> > have the same *.class files - but these would differ for every
>> build
>> >> >> > and so can't be compared any further without lots of clever
>> tooling -
>> >> >> > so nobody does this. (I think there should be an Apache-hosted
>> tool or
>> >> >> > Maven plugin that could do this).
>> >> >> >
>> >> >> >
>> >> >> > Practically the best is just to click briefly into the repository
>> in a
>> >> >> > browser and see there are not any 'additional' folders that
>> shouldn't
>> >> >> > be there, e.g. we are now voting on taverna-maven-parent,
>> taverna-osgi
>> >> >> > and taverna-language, and so we should not see
>> >> >> > org/apache/taverna/engine in there - as that is a group Id from
>> >> >> > taverna-engine.
>> >> >> >
>> >> >> > (We have already changed the groupIDs to correspond to the
>> repository
>> >> >> > which corresponds to the release name, so at least that
>> correspondance
>> >> >> > is easy to check on Taverna, but not so on many other projects).
>> >> >> >
>> >> >> >
>> >> >> > As binary releases from Apache Software Foundation are considered
>> >> >> > "convenience only" they are not crucial for the vote - the source
>> >> >> > release is the golden thing which everything else should be made
>> from.
>> >> >> > Practically speaking "everyone" uses the JARs from Maven
>> repository
>> >> >> > though, so I wouldn't dismiss them totally - at least one person
>> in
>> >> >> > the vote should do such a check.
>> >> >> >
>> >> >> >
>> >> >> > > (4) How do I check the dependencies?
>> >> >> >
>> >> >> > mvn dependency:tree gives a nice list - but what should you check
>> for?
>> >> >> > Well, it's mainly about licensing -
>> >> >> > http://www.apache.org/legal/resolved.html lists what is
>> compatible as
>> >> >> > dependencies of an ASF release. Now you don't need to go through
>> the
>> >> >> > list - but sometimes there are Well Known forbidden dependencies
>> that
>> >> >> > People (tm) recognize -e.g. mysql-connector and Hibernate are
>> banned
>> >> >> > as they are (L)GPL.
>> >> >> >
>> >> >> > Luckily there's another Maven plugin that can do the job:
>> >> >> >
>> >> >> > mvn license:aggregate-add-third-party
>> >> >> >
>> >> >> > cat target/generated-sources/license/THIRD-PARTY.txt | sort
>> >> >> >
>> >> >> > (Aduna BSD license) OpenRDF Sesame: HTTP client
>> >> >> > (org.openrdf.sesame:sesame-http-client:2.7.0 -
>> >> >> >
>> http://www.openrdf.org/sesame-core/sesame-http/sesame-http-client/)
>> >> >> > (Aduna BSD license) OpenRDF Sesame: HTTP protocol
>> >> >> > (org.openrdf.sesame:sesame-http-protocol:2.7.0 -
>> >> >> >
>> http://www.openrdf.org/sesame-core/sesame-http/sesame-http-protocol/)
>> >> >> > (..)
>> >> >> > (The Apache Software License, Version 2.0) Xerces2-j
>> >> >> > (xerces:xercesImpl:2.11.0 - https://xerces.apache.org/xerces2-j/)
>> >> >> > (Unknown license) commons-beanutils
>> >> >> > (commons-beanutils:commons-beanutils:1.7.0 - no url defined)
>> >> >> > (Unknown license) com.springsource.org.jaxen
>> >> >> > (org.jaxen:com.springsource.org.jaxen:1.1.1 - no url defined)
>> >> >> > (Unknown license) com.springsource.org.jdom
>> >> >> > (org.jdom:com.springsource.org.jdom:1.1.0 - no url defined)
>> >> >> > (Unknown license) Logging
>> (commons-logging:commons-logging:1.0.3
>> >> >> > - http://jakarta.apache.org/commons/logging/)
>> >> >> >
>> >> >> > (BTW, those last 4 are already checked to be OK, see
>> >> >> >
>> http://dev.mygrid.org.uk/wiki/display/developer/Third-party+licenses
>> >> )
>> >> >> >
>> >> >> >
>> >> >> > > Regarding the build output: Since this is the first time I've
>> done
>> >> >> this,
>> >> >> > I
>> >> >> > > don't know what's okay to ignore. Here is a summary of the
>> warning
>> >> >> > messages
>> >> >> > > I received when I ran mvn clean install. I sent the output to
>> two
>> >> >> > different
>> >> >> > > files using the following command (Windows 10/ GitBash): mvn
>> clean
>> >> >> > install
>> >> >> > >> output1.txt 2> output2.txt. I appreciate any insight.
>> >> >> >
>> >> >> > Great! I think those should be tracked in JIRA as we want to
>> reduce
>> >> >> > warnings.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Generally with Maven, if it finishes with a big SUCCESS, then
>> that's
>> >> >> > true. The warnings are more like warnings for the developers doing
>> >> >> > bad-practice-stuff than warnings about something going wrong with
>> the
>> >> >> > build. Often the fixes are simple, like adding a @Deprecated tag
>> >> >> > where you delibately use old APIs, or actually follow the fix
>> >> >> > suggested by the warning.
>> >> >> >
>> >> >> > I think we want to follow Andy's advice and "release early,
>> release
>> >> >> > often" - which entails a "good enough" - not "super-perfect".
>> >> >> > Obviously each committer votes independenly by their own quality
>> >> >> > measures.
>> >> >> >
>> >> >> > While Apache Software Foundation always says that community is
>> king -
>> >> >> > the Apache name is still recognized by the public as a kind of
>> >> >> > "quality mark" - if that is deserved or not I won't comment on,
>> but of
>> >> >> > course there is also a sense of pride in that we don't want to
>> set the
>> >> >> > standard too low. :)
>> >> >> >
>> >> >> > (E.g. Taverna just cancelled 3 release candidates as they didn't
>> pass
>> >> >> > all their tests on Windows - but the community of another Apache
>> >> >> > project might not consider Windows important enough to halt a
>> release)
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Stian Soiland-Reyes
>> >> >> > Apache Taverna (incubating), Apache Commons RDF (incubating)
>> >> >> > http://orcid.org/0000-0001-9842-9718
>> >> >> >
>> >> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Stian Soiland-Reyes
>> >> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> >> http://orcid.org/0000-0001-9842-9718
>> >>
>>
>>
>>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> http://orcid.org/0000-0001-9842-9718
>>
>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Gale Naylor <Ga...@noventussolutions.com>.
Definitely. I'm already working on an offline document. I hope to have
something on the wiki by EOD today (PST).
On Wed, Mar 2, 2016, 10:34 AM Stian Soiland-Reyes <st...@apache.org> wrote:
> +1! Would you be OK to start? I guess Andy's list is a good starting
> point. I can add my "shell tricks" where they fit. (and then we can
> remove the more evil ones :))
>
> On 2 March 2016 at 17:42, Gale Naylor <Ga...@noventussolutions.com> wrote:
> > I like the "what do i do now" section. What if we develop it in the wiki
> > and then, when we're happy with it, migrate it to the community section
> of
> > the website?
> >
> > On Wed, Mar 2, 2016 at 7:18 AM Stian Soiland-Reyes <st...@apache.org>
> wrote:
> >
> >> Yeah, we can develop it in the wiki, or append it to
> >> http://taverna.incubator.apache.org/community/releasing perhaps?
> >>
> >> There should be a "I received a VOTE email, what do I do now?" section.
> >>
> >> On 2 March 2016 at 11:59, Ian Dunlop <ia...@gmail.com> wrote:
> >> > Hello,
> >> >
> >> > I think we need to capture all these tricks somewhere. Stian
> suggested we
> >> > propose updating the 'official' apache release page - sounds like a
> good
> >> > idea - but I think we could add it to the taverna pages first and then
> >> > maybe send a link to it to the (I don't know) incubator list to gauge
> >> > interest.
> >> >
> >> > Cheers,
> >> >
> >> > Ian
> >> >
> >> > On 1 March 2016 at 22:42, Gale Naylor <Ga...@noventussolutions.com>
> >> wrote:
> >> >
> >> >> Thank you, Stian! Some of my questions I figured out today, but some
> I
> >> did
> >> >> not, so I very much appreciate the hints and instructions.
> >> >>
> >> >>
> >> >> On Tue, Mar 1, 2016 at 2:28 PM Stian Soiland-Reyes <stain@apache.org
> >
> >> >> wrote:
> >> >>
> >> >> > Thanks for reviewing!
> >> >> >
> >> >> >
> >> >> > > (1) How do I verify that the commit id in the downloaded files
> >> matches
> >> >> > that
> >> >> > > in the VOTE email? (I've looked on the internet, but have yet to
> >> find
> >> >> > > anything helpful.)
> >> >> >
> >> >> > I don't think most people check this deeply.. but I guess at least
> one
> >> >> > voter should.
> >> >> >
> >> >> > Here's what I do:
> >> >> >
> >> >> > mkdir 1 ; cd 1 # new folder
> >> >> > git clone that-repository
> >> >> > git checkout that-commit-id-from-the-email-asdfjaskdjfsakjdfksajdf
> >> >> > rm -rf *
> >> >> > unzip ../the-release-candidate.zip
> >> >> > mv apache-taverna-*/* . (one level up)
> >> >> > git status
> >> >> >
> >> >> > Git will then check the checksums of every file and let you know
> what
> >> >> > has 'changed' (as it would believe you have edited it).
> >> >> >
> >> >> >
> >> >> > Here's another way that doesn't require using the 'git' command:
> >> >> >
> >> >> > Download the git commit corresponding to the email by browsing for
> it
> >> on
> >> >> > GitHub:
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >>
> https://github.com/apache/incubator-taverna-language/tree/66866a5454ed23262c055f65155d7a195c68a17d
> >> >> > Click "Download ZIP"
> >> >> >
> >> >> > mkdir 1 ; cd 1
> >> >> > unzip ../66866a5454ed23262c055f65155d7a195c68a17d.zip
> >> >> >
> >> >> > cd ../ ; mkdir 2 ; cd 2
> >> >> > unzip release-candidate.zip
> >> >> >
> >> >> > cd ..
> >> >> > diff -uR 1 2
> >> >> >
> >> >> > The files that differ (and their differences!) will be shown.
> >> >> >
> >> >> > Make sure you don't have any target/ folders before diff-ing (run
> mvn
> >> >> > clean to be sure)
> >> >> >
> >> >> > If you do the above with a git clone instead - remember that the
> zip
> >> >> > doesn't include the .git/ folder - so you would have to delete the
> >> >> > checked out .git folder before diffing. (Don't do this on your
> >> >> > regular checkout as you would lose all local branches!)
> >> >> >
> >> >> >
> >> >> >
> >> >> > > (2) Are the "binary artifacts" in the target folders? Which files
> >> are
> >> >> > > considered "binary artifacts?"
> >> >> >
> >> >> > Well, the target/ files are binary artifacts, but they (should)
> have
> >> >> > been made by your build on your machine - not be part of the source
> >> >> > ZIP.
> >> >> >
> >> >> >
> >> >> > One thing to look out for is in the downloaded source ZIP that
> there
> >> >> > are no unexpected binary artifacts in it *before you build* - e.g.
> >> >> > there should not be any *.jars in there. (The source distribution
> >> >> > should be 'clean'). We do have some *expected* binaries, pictures
> and
> >> >> > test workflows for instance. As those can't have license headers
> they
> >> >> > should be declared in NOTICE/LICENSE if they came from
> third-parties.
> >> >> > (E.g. if we used a Creative Commons-licensed JPEG picture)
> >> >> >
> >> >> >
> >> >> > In terms of release candidate, the binaries would be installers and
> >> >> > JARs etc., under
> >> >> > https://dist.apache.org/repos/dist/dev/incubator/taverna/binaries/
> >> >> > (But there are none for this release candidate)
> >> >> >
> >> >> > ..in addition to the JARs that have been staged to the Maven
> >> repository
> >> >> >
> >> >> >
> >> >>
> >>
> https://repository.apache.org/content/repositories/orgapachetaverna-1011/org/apache/taverna/
> >> >> >
> >> >> >
> >> >> > > (3) How do I verify that the build produces the binaries? By
> visual
> >> >> > > inspection? What am I looking for?
> >> >> >
> >> >> >
> >> >> > As for checking the Maven repository, if you want to do it really
> >> >> > proper you should check that all the JARs that are staged can be
> built
> >> >> > from the downloaded release candidate ZIP - e.g. that your target/
> >> >> > folder contains all of the same ones. If I do this, I do a
> recursive
> >> >> > wget of the repository, and then compare the result of "find .
> -name
> >> >> > '*jar'" in the wget-tree with */*/target/*.jar. I don't think
> most
> >> >> > people do this.
> >> >> >
> >> >> > Paranoid-mode would be to download each JAR and check that they
> only
> >> >> > have the same *.class files - but these would differ for every
> build
> >> >> > and so can't be compared any further without lots of clever
> tooling -
> >> >> > so nobody does this. (I think there should be an Apache-hosted
> tool or
> >> >> > Maven plugin that could do this).
> >> >> >
> >> >> >
> >> >> > Practically the best is just to click briefly into the repository
> in a
> >> >> > browser and see there are not any 'additional' folders that
> shouldn't
> >> >> > be there, e.g. we are now voting on taverna-maven-parent,
> taverna-osgi
> >> >> > and taverna-language, and so we should not see
> >> >> > org/apache/taverna/engine in there - as that is a group Id from
> >> >> > taverna-engine.
> >> >> >
> >> >> > (We have already changed the groupIDs to correspond to the
> repository
> >> >> > which corresponds to the release name, so at least that
> correspondance
> >> >> > is easy to check on Taverna, but not so on many other projects).
> >> >> >
> >> >> >
> >> >> > As binary releases from Apache Software Foundation are considered
> >> >> > "convenience only" they are not crucial for the vote - the source
> >> >> > release is the golden thing which everything else should be made
> from.
> >> >> > Practically speaking "everyone" uses the JARs from Maven repository
> >> >> > though, so I wouldn't dismiss them totally - at least one person in
> >> >> > the vote should do such a check.
> >> >> >
> >> >> >
> >> >> > > (4) How do I check the dependencies?
> >> >> >
> >> >> > mvn dependency:tree gives a nice list - but what should you check
> for?
> >> >> > Well, it's mainly about licensing -
> >> >> > http://www.apache.org/legal/resolved.html lists what is
> compatible as
> >> >> > dependencies of an ASF release. Now you don't need to go through
> the
> >> >> > list - but sometimes there are Well Known forbidden dependencies
> that
> >> >> > People (tm) recognize -e.g. mysql-connector and Hibernate are
> banned
> >> >> > as they are (L)GPL.
> >> >> >
> >> >> > Luckily there's another Maven plugin that can do the job:
> >> >> >
> >> >> > mvn license:aggregate-add-third-party
> >> >> >
> >> >> > cat target/generated-sources/license/THIRD-PARTY.txt | sort
> >> >> >
> >> >> > (Aduna BSD license) OpenRDF Sesame: HTTP client
> >> >> > (org.openrdf.sesame:sesame-http-client:2.7.0 -
> >> >> > http://www.openrdf.org/sesame-core/sesame-http/sesame-http-client/
> )
> >> >> > (Aduna BSD license) OpenRDF Sesame: HTTP protocol
> >> >> > (org.openrdf.sesame:sesame-http-protocol:2.7.0 -
> >> >> >
> http://www.openrdf.org/sesame-core/sesame-http/sesame-http-protocol/)
> >> >> > (..)
> >> >> > (The Apache Software License, Version 2.0) Xerces2-j
> >> >> > (xerces:xercesImpl:2.11.0 - https://xerces.apache.org/xerces2-j/)
> >> >> > (Unknown license) commons-beanutils
> >> >> > (commons-beanutils:commons-beanutils:1.7.0 - no url defined)
> >> >> > (Unknown license) com.springsource.org.jaxen
> >> >> > (org.jaxen:com.springsource.org.jaxen:1.1.1 - no url defined)
> >> >> > (Unknown license) com.springsource.org.jdom
> >> >> > (org.jdom:com.springsource.org.jdom:1.1.0 - no url defined)
> >> >> > (Unknown license) Logging
> (commons-logging:commons-logging:1.0.3
> >> >> > - http://jakarta.apache.org/commons/logging/)
> >> >> >
> >> >> > (BTW, those last 4 are already checked to be OK, see
> >> >> >
> http://dev.mygrid.org.uk/wiki/display/developer/Third-party+licenses
> >> )
> >> >> >
> >> >> >
> >> >> > > Regarding the build output: Since this is the first time I've
> done
> >> >> this,
> >> >> > I
> >> >> > > don't know what's okay to ignore. Here is a summary of the
> warning
> >> >> > messages
> >> >> > > I received when I ran mvn clean install. I sent the output to two
> >> >> > different
> >> >> > > files using the following command (Windows 10/ GitBash): mvn
> clean
> >> >> > install
> >> >> > >> output1.txt 2> output2.txt. I appreciate any insight.
> >> >> >
> >> >> > Great! I think those should be tracked in JIRA as we want to
> reduce
> >> >> > warnings.
> >> >> >
> >> >> >
> >> >> >
> >> >> > Generally with Maven, if it finishes with a big SUCCESS, then
> that's
> >> >> > true. The warnings are more like warnings for the developers doing
> >> >> > bad-practice-stuff than warnings about something going wrong with
> the
> >> >> > build. Often the fixes are simple, like adding a @Deprecated tag
> >> >> > where you delibately use old APIs, or actually follow the fix
> >> >> > suggested by the warning.
> >> >> >
> >> >> > I think we want to follow Andy's advice and "release early, release
> >> >> > often" - which entails a "good enough" - not "super-perfect".
> >> >> > Obviously each committer votes independenly by their own quality
> >> >> > measures.
> >> >> >
> >> >> > While Apache Software Foundation always says that community is
> king -
> >> >> > the Apache name is still recognized by the public as a kind of
> >> >> > "quality mark" - if that is deserved or not I won't comment on,
> but of
> >> >> > course there is also a sense of pride in that we don't want to set
> the
> >> >> > standard too low. :)
> >> >> >
> >> >> > (E.g. Taverna just cancelled 3 release candidates as they didn't
> pass
> >> >> > all their tests on Windows - but the community of another Apache
> >> >> > project might not consider Windows important enough to halt a
> release)
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Stian Soiland-Reyes
> >> >> > Apache Taverna (incubating), Apache Commons RDF (incubating)
> >> >> > http://orcid.org/0000-0001-9842-9718
> >> >> >
> >> >>
> >>
> >>
> >>
> >> --
> >> Stian Soiland-Reyes
> >> Apache Taverna (incubating), Apache Commons RDF (incubating)
> >> http://orcid.org/0000-0001-9842-9718
> >>
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/0000-0001-9842-9718
>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Stian Soiland-Reyes <st...@apache.org>.
+1! Would you be OK to start? I guess Andy's list is a good starting
point. I can add my "shell tricks" where they fit. (and then we can
remove the more evil ones :))
On 2 March 2016 at 17:42, Gale Naylor <Ga...@noventussolutions.com> wrote:
> I like the "what do i do now" section. What if we develop it in the wiki
> and then, when we're happy with it, migrate it to the community section of
> the website?
>
> On Wed, Mar 2, 2016 at 7:18 AM Stian Soiland-Reyes <st...@apache.org> wrote:
>
>> Yeah, we can develop it in the wiki, or append it to
>> http://taverna.incubator.apache.org/community/releasing perhaps?
>>
>> There should be a "I received a VOTE email, what do I do now?" section.
>>
>> On 2 March 2016 at 11:59, Ian Dunlop <ia...@gmail.com> wrote:
>> > Hello,
>> >
>> > I think we need to capture all these tricks somewhere. Stian suggested we
>> > propose updating the 'official' apache release page - sounds like a good
>> > idea - but I think we could add it to the taverna pages first and then
>> > maybe send a link to it to the (I don't know) incubator list to gauge
>> > interest.
>> >
>> > Cheers,
>> >
>> > Ian
>> >
>> > On 1 March 2016 at 22:42, Gale Naylor <Ga...@noventussolutions.com>
>> wrote:
>> >
>> >> Thank you, Stian! Some of my questions I figured out today, but some I
>> did
>> >> not, so I very much appreciate the hints and instructions.
>> >>
>> >>
>> >> On Tue, Mar 1, 2016 at 2:28 PM Stian Soiland-Reyes <st...@apache.org>
>> >> wrote:
>> >>
>> >> > Thanks for reviewing!
>> >> >
>> >> >
>> >> > > (1) How do I verify that the commit id in the downloaded files
>> matches
>> >> > that
>> >> > > in the VOTE email? (I've looked on the internet, but have yet to
>> find
>> >> > > anything helpful.)
>> >> >
>> >> > I don't think most people check this deeply.. but I guess at least one
>> >> > voter should.
>> >> >
>> >> > Here's what I do:
>> >> >
>> >> > mkdir 1 ; cd 1 # new folder
>> >> > git clone that-repository
>> >> > git checkout that-commit-id-from-the-email-asdfjaskdjfsakjdfksajdf
>> >> > rm -rf *
>> >> > unzip ../the-release-candidate.zip
>> >> > mv apache-taverna-*/* . (one level up)
>> >> > git status
>> >> >
>> >> > Git will then check the checksums of every file and let you know what
>> >> > has 'changed' (as it would believe you have edited it).
>> >> >
>> >> >
>> >> > Here's another way that doesn't require using the 'git' command:
>> >> >
>> >> > Download the git commit corresponding to the email by browsing for it
>> on
>> >> > GitHub:
>> >> >
>> >> >
>> >> >
>> >>
>> https://github.com/apache/incubator-taverna-language/tree/66866a5454ed23262c055f65155d7a195c68a17d
>> >> > Click "Download ZIP"
>> >> >
>> >> > mkdir 1 ; cd 1
>> >> > unzip ../66866a5454ed23262c055f65155d7a195c68a17d.zip
>> >> >
>> >> > cd ../ ; mkdir 2 ; cd 2
>> >> > unzip release-candidate.zip
>> >> >
>> >> > cd ..
>> >> > diff -uR 1 2
>> >> >
>> >> > The files that differ (and their differences!) will be shown.
>> >> >
>> >> > Make sure you don't have any target/ folders before diff-ing (run mvn
>> >> > clean to be sure)
>> >> >
>> >> > If you do the above with a git clone instead - remember that the zip
>> >> > doesn't include the .git/ folder - so you would have to delete the
>> >> > checked out .git folder before diffing. (Don't do this on your
>> >> > regular checkout as you would lose all local branches!)
>> >> >
>> >> >
>> >> >
>> >> > > (2) Are the "binary artifacts" in the target folders? Which files
>> are
>> >> > > considered "binary artifacts?"
>> >> >
>> >> > Well, the target/ files are binary artifacts, but they (should) have
>> >> > been made by your build on your machine - not be part of the source
>> >> > ZIP.
>> >> >
>> >> >
>> >> > One thing to look out for is in the downloaded source ZIP that there
>> >> > are no unexpected binary artifacts in it *before you build* - e.g.
>> >> > there should not be any *.jars in there. (The source distribution
>> >> > should be 'clean'). We do have some *expected* binaries, pictures and
>> >> > test workflows for instance. As those can't have license headers they
>> >> > should be declared in NOTICE/LICENSE if they came from third-parties.
>> >> > (E.g. if we used a Creative Commons-licensed JPEG picture)
>> >> >
>> >> >
>> >> > In terms of release candidate, the binaries would be installers and
>> >> > JARs etc., under
>> >> > https://dist.apache.org/repos/dist/dev/incubator/taverna/binaries/
>> >> > (But there are none for this release candidate)
>> >> >
>> >> > ..in addition to the JARs that have been staged to the Maven
>> repository
>> >> >
>> >> >
>> >>
>> https://repository.apache.org/content/repositories/orgapachetaverna-1011/org/apache/taverna/
>> >> >
>> >> >
>> >> > > (3) How do I verify that the build produces the binaries? By visual
>> >> > > inspection? What am I looking for?
>> >> >
>> >> >
>> >> > As for checking the Maven repository, if you want to do it really
>> >> > proper you should check that all the JARs that are staged can be built
>> >> > from the downloaded release candidate ZIP - e.g. that your target/
>> >> > folder contains all of the same ones. If I do this, I do a recursive
>> >> > wget of the repository, and then compare the result of "find . -name
>> >> > '*jar'" in the wget-tree with */*/target/*.jar. I don't think most
>> >> > people do this.
>> >> >
>> >> > Paranoid-mode would be to download each JAR and check that they only
>> >> > have the same *.class files - but these would differ for every build
>> >> > and so can't be compared any further without lots of clever tooling -
>> >> > so nobody does this. (I think there should be an Apache-hosted tool or
>> >> > Maven plugin that could do this).
>> >> >
>> >> >
>> >> > Practically the best is just to click briefly into the repository in a
>> >> > browser and see there are not any 'additional' folders that shouldn't
>> >> > be there, e.g. we are now voting on taverna-maven-parent, taverna-osgi
>> >> > and taverna-language, and so we should not see
>> >> > org/apache/taverna/engine in there - as that is a group Id from
>> >> > taverna-engine.
>> >> >
>> >> > (We have already changed the groupIDs to correspond to the repository
>> >> > which corresponds to the release name, so at least that correspondance
>> >> > is easy to check on Taverna, but not so on many other projects).
>> >> >
>> >> >
>> >> > As binary releases from Apache Software Foundation are considered
>> >> > "convenience only" they are not crucial for the vote - the source
>> >> > release is the golden thing which everything else should be made from.
>> >> > Practically speaking "everyone" uses the JARs from Maven repository
>> >> > though, so I wouldn't dismiss them totally - at least one person in
>> >> > the vote should do such a check.
>> >> >
>> >> >
>> >> > > (4) How do I check the dependencies?
>> >> >
>> >> > mvn dependency:tree gives a nice list - but what should you check for?
>> >> > Well, it's mainly about licensing -
>> >> > http://www.apache.org/legal/resolved.html lists what is compatible as
>> >> > dependencies of an ASF release. Now you don't need to go through the
>> >> > list - but sometimes there are Well Known forbidden dependencies that
>> >> > People (tm) recognize -e.g. mysql-connector and Hibernate are banned
>> >> > as they are (L)GPL.
>> >> >
>> >> > Luckily there's another Maven plugin that can do the job:
>> >> >
>> >> > mvn license:aggregate-add-third-party
>> >> >
>> >> > cat target/generated-sources/license/THIRD-PARTY.txt | sort
>> >> >
>> >> > (Aduna BSD license) OpenRDF Sesame: HTTP client
>> >> > (org.openrdf.sesame:sesame-http-client:2.7.0 -
>> >> > http://www.openrdf.org/sesame-core/sesame-http/sesame-http-client/)
>> >> > (Aduna BSD license) OpenRDF Sesame: HTTP protocol
>> >> > (org.openrdf.sesame:sesame-http-protocol:2.7.0 -
>> >> > http://www.openrdf.org/sesame-core/sesame-http/sesame-http-protocol/)
>> >> > (..)
>> >> > (The Apache Software License, Version 2.0) Xerces2-j
>> >> > (xerces:xercesImpl:2.11.0 - https://xerces.apache.org/xerces2-j/)
>> >> > (Unknown license) commons-beanutils
>> >> > (commons-beanutils:commons-beanutils:1.7.0 - no url defined)
>> >> > (Unknown license) com.springsource.org.jaxen
>> >> > (org.jaxen:com.springsource.org.jaxen:1.1.1 - no url defined)
>> >> > (Unknown license) com.springsource.org.jdom
>> >> > (org.jdom:com.springsource.org.jdom:1.1.0 - no url defined)
>> >> > (Unknown license) Logging (commons-logging:commons-logging:1.0.3
>> >> > - http://jakarta.apache.org/commons/logging/)
>> >> >
>> >> > (BTW, those last 4 are already checked to be OK, see
>> >> > http://dev.mygrid.org.uk/wiki/display/developer/Third-party+licenses
>> )
>> >> >
>> >> >
>> >> > > Regarding the build output: Since this is the first time I've done
>> >> this,
>> >> > I
>> >> > > don't know what's okay to ignore. Here is a summary of the warning
>> >> > messages
>> >> > > I received when I ran mvn clean install. I sent the output to two
>> >> > different
>> >> > > files using the following command (Windows 10/ GitBash): mvn clean
>> >> > install
>> >> > >> output1.txt 2> output2.txt. I appreciate any insight.
>> >> >
>> >> > Great! I think those should be tracked in JIRA as we want to reduce
>> >> > warnings.
>> >> >
>> >> >
>> >> >
>> >> > Generally with Maven, if it finishes with a big SUCCESS, then that's
>> >> > true. The warnings are more like warnings for the developers doing
>> >> > bad-practice-stuff than warnings about something going wrong with the
>> >> > build. Often the fixes are simple, like adding a @Deprecated tag
>> >> > where you delibately use old APIs, or actually follow the fix
>> >> > suggested by the warning.
>> >> >
>> >> > I think we want to follow Andy's advice and "release early, release
>> >> > often" - which entails a "good enough" - not "super-perfect".
>> >> > Obviously each committer votes independenly by their own quality
>> >> > measures.
>> >> >
>> >> > While Apache Software Foundation always says that community is king -
>> >> > the Apache name is still recognized by the public as a kind of
>> >> > "quality mark" - if that is deserved or not I won't comment on, but of
>> >> > course there is also a sense of pride in that we don't want to set the
>> >> > standard too low. :)
>> >> >
>> >> > (E.g. Taverna just cancelled 3 release candidates as they didn't pass
>> >> > all their tests on Windows - but the community of another Apache
>> >> > project might not consider Windows important enough to halt a release)
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Stian Soiland-Reyes
>> >> > Apache Taverna (incubating), Apache Commons RDF (incubating)
>> >> > http://orcid.org/0000-0001-9842-9718
>> >> >
>> >>
>>
>>
>>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> http://orcid.org/0000-0001-9842-9718
>>
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Gale Naylor <Ga...@noventussolutions.com>.
I like the "what do i do now" section. What if we develop it in the wiki
and then, when we're happy with it, migrate it to the community section of
the website?
On Wed, Mar 2, 2016 at 7:18 AM Stian Soiland-Reyes <st...@apache.org> wrote:
> Yeah, we can develop it in the wiki, or append it to
> http://taverna.incubator.apache.org/community/releasing perhaps?
>
> There should be a "I received a VOTE email, what do I do now?" section.
>
> On 2 March 2016 at 11:59, Ian Dunlop <ia...@gmail.com> wrote:
> > Hello,
> >
> > I think we need to capture all these tricks somewhere. Stian suggested we
> > propose updating the 'official' apache release page - sounds like a good
> > idea - but I think we could add it to the taverna pages first and then
> > maybe send a link to it to the (I don't know) incubator list to gauge
> > interest.
> >
> > Cheers,
> >
> > Ian
> >
> > On 1 March 2016 at 22:42, Gale Naylor <Ga...@noventussolutions.com>
> wrote:
> >
> >> Thank you, Stian! Some of my questions I figured out today, but some I
> did
> >> not, so I very much appreciate the hints and instructions.
> >>
> >>
> >> On Tue, Mar 1, 2016 at 2:28 PM Stian Soiland-Reyes <st...@apache.org>
> >> wrote:
> >>
> >> > Thanks for reviewing!
> >> >
> >> >
> >> > > (1) How do I verify that the commit id in the downloaded files
> matches
> >> > that
> >> > > in the VOTE email? (I've looked on the internet, but have yet to
> find
> >> > > anything helpful.)
> >> >
> >> > I don't think most people check this deeply.. but I guess at least one
> >> > voter should.
> >> >
> >> > Here's what I do:
> >> >
> >> > mkdir 1 ; cd 1 # new folder
> >> > git clone that-repository
> >> > git checkout that-commit-id-from-the-email-asdfjaskdjfsakjdfksajdf
> >> > rm -rf *
> >> > unzip ../the-release-candidate.zip
> >> > mv apache-taverna-*/* . (one level up)
> >> > git status
> >> >
> >> > Git will then check the checksums of every file and let you know what
> >> > has 'changed' (as it would believe you have edited it).
> >> >
> >> >
> >> > Here's another way that doesn't require using the 'git' command:
> >> >
> >> > Download the git commit corresponding to the email by browsing for it
> on
> >> > GitHub:
> >> >
> >> >
> >> >
> >>
> https://github.com/apache/incubator-taverna-language/tree/66866a5454ed23262c055f65155d7a195c68a17d
> >> > Click "Download ZIP"
> >> >
> >> > mkdir 1 ; cd 1
> >> > unzip ../66866a5454ed23262c055f65155d7a195c68a17d.zip
> >> >
> >> > cd ../ ; mkdir 2 ; cd 2
> >> > unzip release-candidate.zip
> >> >
> >> > cd ..
> >> > diff -uR 1 2
> >> >
> >> > The files that differ (and their differences!) will be shown.
> >> >
> >> > Make sure you don't have any target/ folders before diff-ing (run mvn
> >> > clean to be sure)
> >> >
> >> > If you do the above with a git clone instead - remember that the zip
> >> > doesn't include the .git/ folder - so you would have to delete the
> >> > checked out .git folder before diffing. (Don't do this on your
> >> > regular checkout as you would lose all local branches!)
> >> >
> >> >
> >> >
> >> > > (2) Are the "binary artifacts" in the target folders? Which files
> are
> >> > > considered "binary artifacts?"
> >> >
> >> > Well, the target/ files are binary artifacts, but they (should) have
> >> > been made by your build on your machine - not be part of the source
> >> > ZIP.
> >> >
> >> >
> >> > One thing to look out for is in the downloaded source ZIP that there
> >> > are no unexpected binary artifacts in it *before you build* - e.g.
> >> > there should not be any *.jars in there. (The source distribution
> >> > should be 'clean'). We do have some *expected* binaries, pictures and
> >> > test workflows for instance. As those can't have license headers they
> >> > should be declared in NOTICE/LICENSE if they came from third-parties.
> >> > (E.g. if we used a Creative Commons-licensed JPEG picture)
> >> >
> >> >
> >> > In terms of release candidate, the binaries would be installers and
> >> > JARs etc., under
> >> > https://dist.apache.org/repos/dist/dev/incubator/taverna/binaries/
> >> > (But there are none for this release candidate)
> >> >
> >> > ..in addition to the JARs that have been staged to the Maven
> repository
> >> >
> >> >
> >>
> https://repository.apache.org/content/repositories/orgapachetaverna-1011/org/apache/taverna/
> >> >
> >> >
> >> > > (3) How do I verify that the build produces the binaries? By visual
> >> > > inspection? What am I looking for?
> >> >
> >> >
> >> > As for checking the Maven repository, if you want to do it really
> >> > proper you should check that all the JARs that are staged can be built
> >> > from the downloaded release candidate ZIP - e.g. that your target/
> >> > folder contains all of the same ones. If I do this, I do a recursive
> >> > wget of the repository, and then compare the result of "find . -name
> >> > '*jar'" in the wget-tree with */*/target/*.jar. I don't think most
> >> > people do this.
> >> >
> >> > Paranoid-mode would be to download each JAR and check that they only
> >> > have the same *.class files - but these would differ for every build
> >> > and so can't be compared any further without lots of clever tooling -
> >> > so nobody does this. (I think there should be an Apache-hosted tool or
> >> > Maven plugin that could do this).
> >> >
> >> >
> >> > Practically the best is just to click briefly into the repository in a
> >> > browser and see there are not any 'additional' folders that shouldn't
> >> > be there, e.g. we are now voting on taverna-maven-parent, taverna-osgi
> >> > and taverna-language, and so we should not see
> >> > org/apache/taverna/engine in there - as that is a group Id from
> >> > taverna-engine.
> >> >
> >> > (We have already changed the groupIDs to correspond to the repository
> >> > which corresponds to the release name, so at least that correspondance
> >> > is easy to check on Taverna, but not so on many other projects).
> >> >
> >> >
> >> > As binary releases from Apache Software Foundation are considered
> >> > "convenience only" they are not crucial for the vote - the source
> >> > release is the golden thing which everything else should be made from.
> >> > Practically speaking "everyone" uses the JARs from Maven repository
> >> > though, so I wouldn't dismiss them totally - at least one person in
> >> > the vote should do such a check.
> >> >
> >> >
> >> > > (4) How do I check the dependencies?
> >> >
> >> > mvn dependency:tree gives a nice list - but what should you check for?
> >> > Well, it's mainly about licensing -
> >> > http://www.apache.org/legal/resolved.html lists what is compatible as
> >> > dependencies of an ASF release. Now you don't need to go through the
> >> > list - but sometimes there are Well Known forbidden dependencies that
> >> > People (tm) recognize -e.g. mysql-connector and Hibernate are banned
> >> > as they are (L)GPL.
> >> >
> >> > Luckily there's another Maven plugin that can do the job:
> >> >
> >> > mvn license:aggregate-add-third-party
> >> >
> >> > cat target/generated-sources/license/THIRD-PARTY.txt | sort
> >> >
> >> > (Aduna BSD license) OpenRDF Sesame: HTTP client
> >> > (org.openrdf.sesame:sesame-http-client:2.7.0 -
> >> > http://www.openrdf.org/sesame-core/sesame-http/sesame-http-client/)
> >> > (Aduna BSD license) OpenRDF Sesame: HTTP protocol
> >> > (org.openrdf.sesame:sesame-http-protocol:2.7.0 -
> >> > http://www.openrdf.org/sesame-core/sesame-http/sesame-http-protocol/)
> >> > (..)
> >> > (The Apache Software License, Version 2.0) Xerces2-j
> >> > (xerces:xercesImpl:2.11.0 - https://xerces.apache.org/xerces2-j/)
> >> > (Unknown license) commons-beanutils
> >> > (commons-beanutils:commons-beanutils:1.7.0 - no url defined)
> >> > (Unknown license) com.springsource.org.jaxen
> >> > (org.jaxen:com.springsource.org.jaxen:1.1.1 - no url defined)
> >> > (Unknown license) com.springsource.org.jdom
> >> > (org.jdom:com.springsource.org.jdom:1.1.0 - no url defined)
> >> > (Unknown license) Logging (commons-logging:commons-logging:1.0.3
> >> > - http://jakarta.apache.org/commons/logging/)
> >> >
> >> > (BTW, those last 4 are already checked to be OK, see
> >> > http://dev.mygrid.org.uk/wiki/display/developer/Third-party+licenses
> )
> >> >
> >> >
> >> > > Regarding the build output: Since this is the first time I've done
> >> this,
> >> > I
> >> > > don't know what's okay to ignore. Here is a summary of the warning
> >> > messages
> >> > > I received when I ran mvn clean install. I sent the output to two
> >> > different
> >> > > files using the following command (Windows 10/ GitBash): mvn clean
> >> > install
> >> > >> output1.txt 2> output2.txt. I appreciate any insight.
> >> >
> >> > Great! I think those should be tracked in JIRA as we want to reduce
> >> > warnings.
> >> >
> >> >
> >> >
> >> > Generally with Maven, if it finishes with a big SUCCESS, then that's
> >> > true. The warnings are more like warnings for the developers doing
> >> > bad-practice-stuff than warnings about something going wrong with the
> >> > build. Often the fixes are simple, like adding a @Deprecated tag
> >> > where you delibately use old APIs, or actually follow the fix
> >> > suggested by the warning.
> >> >
> >> > I think we want to follow Andy's advice and "release early, release
> >> > often" - which entails a "good enough" - not "super-perfect".
> >> > Obviously each committer votes independenly by their own quality
> >> > measures.
> >> >
> >> > While Apache Software Foundation always says that community is king -
> >> > the Apache name is still recognized by the public as a kind of
> >> > "quality mark" - if that is deserved or not I won't comment on, but of
> >> > course there is also a sense of pride in that we don't want to set the
> >> > standard too low. :)
> >> >
> >> > (E.g. Taverna just cancelled 3 release candidates as they didn't pass
> >> > all their tests on Windows - but the community of another Apache
> >> > project might not consider Windows important enough to halt a release)
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Stian Soiland-Reyes
> >> > Apache Taverna (incubating), Apache Commons RDF (incubating)
> >> > http://orcid.org/0000-0001-9842-9718
> >> >
> >>
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/0000-0001-9842-9718
>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Stian Soiland-Reyes <st...@apache.org>.
Yeah, we can develop it in the wiki, or append it to
http://taverna.incubator.apache.org/community/releasing perhaps?
There should be a "I received a VOTE email, what do I do now?" section.
On 2 March 2016 at 11:59, Ian Dunlop <ia...@gmail.com> wrote:
> Hello,
>
> I think we need to capture all these tricks somewhere. Stian suggested we
> propose updating the 'official' apache release page - sounds like a good
> idea - but I think we could add it to the taverna pages first and then
> maybe send a link to it to the (I don't know) incubator list to gauge
> interest.
>
> Cheers,
>
> Ian
>
> On 1 March 2016 at 22:42, Gale Naylor <Ga...@noventussolutions.com> wrote:
>
>> Thank you, Stian! Some of my questions I figured out today, but some I did
>> not, so I very much appreciate the hints and instructions.
>>
>>
>> On Tue, Mar 1, 2016 at 2:28 PM Stian Soiland-Reyes <st...@apache.org>
>> wrote:
>>
>> > Thanks for reviewing!
>> >
>> >
>> > > (1) How do I verify that the commit id in the downloaded files matches
>> > that
>> > > in the VOTE email? (I've looked on the internet, but have yet to find
>> > > anything helpful.)
>> >
>> > I don't think most people check this deeply.. but I guess at least one
>> > voter should.
>> >
>> > Here's what I do:
>> >
>> > mkdir 1 ; cd 1 # new folder
>> > git clone that-repository
>> > git checkout that-commit-id-from-the-email-asdfjaskdjfsakjdfksajdf
>> > rm -rf *
>> > unzip ../the-release-candidate.zip
>> > mv apache-taverna-*/* . (one level up)
>> > git status
>> >
>> > Git will then check the checksums of every file and let you know what
>> > has 'changed' (as it would believe you have edited it).
>> >
>> >
>> > Here's another way that doesn't require using the 'git' command:
>> >
>> > Download the git commit corresponding to the email by browsing for it on
>> > GitHub:
>> >
>> >
>> >
>> https://github.com/apache/incubator-taverna-language/tree/66866a5454ed23262c055f65155d7a195c68a17d
>> > Click "Download ZIP"
>> >
>> > mkdir 1 ; cd 1
>> > unzip ../66866a5454ed23262c055f65155d7a195c68a17d.zip
>> >
>> > cd ../ ; mkdir 2 ; cd 2
>> > unzip release-candidate.zip
>> >
>> > cd ..
>> > diff -uR 1 2
>> >
>> > The files that differ (and their differences!) will be shown.
>> >
>> > Make sure you don't have any target/ folders before diff-ing (run mvn
>> > clean to be sure)
>> >
>> > If you do the above with a git clone instead - remember that the zip
>> > doesn't include the .git/ folder - so you would have to delete the
>> > checked out .git folder before diffing. (Don't do this on your
>> > regular checkout as you would lose all local branches!)
>> >
>> >
>> >
>> > > (2) Are the "binary artifacts" in the target folders? Which files are
>> > > considered "binary artifacts?"
>> >
>> > Well, the target/ files are binary artifacts, but they (should) have
>> > been made by your build on your machine - not be part of the source
>> > ZIP.
>> >
>> >
>> > One thing to look out for is in the downloaded source ZIP that there
>> > are no unexpected binary artifacts in it *before you build* - e.g.
>> > there should not be any *.jars in there. (The source distribution
>> > should be 'clean'). We do have some *expected* binaries, pictures and
>> > test workflows for instance. As those can't have license headers they
>> > should be declared in NOTICE/LICENSE if they came from third-parties.
>> > (E.g. if we used a Creative Commons-licensed JPEG picture)
>> >
>> >
>> > In terms of release candidate, the binaries would be installers and
>> > JARs etc., under
>> > https://dist.apache.org/repos/dist/dev/incubator/taverna/binaries/
>> > (But there are none for this release candidate)
>> >
>> > ..in addition to the JARs that have been staged to the Maven repository
>> >
>> >
>> https://repository.apache.org/content/repositories/orgapachetaverna-1011/org/apache/taverna/
>> >
>> >
>> > > (3) How do I verify that the build produces the binaries? By visual
>> > > inspection? What am I looking for?
>> >
>> >
>> > As for checking the Maven repository, if you want to do it really
>> > proper you should check that all the JARs that are staged can be built
>> > from the downloaded release candidate ZIP - e.g. that your target/
>> > folder contains all of the same ones. If I do this, I do a recursive
>> > wget of the repository, and then compare the result of "find . -name
>> > '*jar'" in the wget-tree with */*/target/*.jar. I don't think most
>> > people do this.
>> >
>> > Paranoid-mode would be to download each JAR and check that they only
>> > have the same *.class files - but these would differ for every build
>> > and so can't be compared any further without lots of clever tooling -
>> > so nobody does this. (I think there should be an Apache-hosted tool or
>> > Maven plugin that could do this).
>> >
>> >
>> > Practically the best is just to click briefly into the repository in a
>> > browser and see there are not any 'additional' folders that shouldn't
>> > be there, e.g. we are now voting on taverna-maven-parent, taverna-osgi
>> > and taverna-language, and so we should not see
>> > org/apache/taverna/engine in there - as that is a group Id from
>> > taverna-engine.
>> >
>> > (We have already changed the groupIDs to correspond to the repository
>> > which corresponds to the release name, so at least that correspondance
>> > is easy to check on Taverna, but not so on many other projects).
>> >
>> >
>> > As binary releases from Apache Software Foundation are considered
>> > "convenience only" they are not crucial for the vote - the source
>> > release is the golden thing which everything else should be made from.
>> > Practically speaking "everyone" uses the JARs from Maven repository
>> > though, so I wouldn't dismiss them totally - at least one person in
>> > the vote should do such a check.
>> >
>> >
>> > > (4) How do I check the dependencies?
>> >
>> > mvn dependency:tree gives a nice list - but what should you check for?
>> > Well, it's mainly about licensing -
>> > http://www.apache.org/legal/resolved.html lists what is compatible as
>> > dependencies of an ASF release. Now you don't need to go through the
>> > list - but sometimes there are Well Known forbidden dependencies that
>> > People (tm) recognize -e.g. mysql-connector and Hibernate are banned
>> > as they are (L)GPL.
>> >
>> > Luckily there's another Maven plugin that can do the job:
>> >
>> > mvn license:aggregate-add-third-party
>> >
>> > cat target/generated-sources/license/THIRD-PARTY.txt | sort
>> >
>> > (Aduna BSD license) OpenRDF Sesame: HTTP client
>> > (org.openrdf.sesame:sesame-http-client:2.7.0 -
>> > http://www.openrdf.org/sesame-core/sesame-http/sesame-http-client/)
>> > (Aduna BSD license) OpenRDF Sesame: HTTP protocol
>> > (org.openrdf.sesame:sesame-http-protocol:2.7.0 -
>> > http://www.openrdf.org/sesame-core/sesame-http/sesame-http-protocol/)
>> > (..)
>> > (The Apache Software License, Version 2.0) Xerces2-j
>> > (xerces:xercesImpl:2.11.0 - https://xerces.apache.org/xerces2-j/)
>> > (Unknown license) commons-beanutils
>> > (commons-beanutils:commons-beanutils:1.7.0 - no url defined)
>> > (Unknown license) com.springsource.org.jaxen
>> > (org.jaxen:com.springsource.org.jaxen:1.1.1 - no url defined)
>> > (Unknown license) com.springsource.org.jdom
>> > (org.jdom:com.springsource.org.jdom:1.1.0 - no url defined)
>> > (Unknown license) Logging (commons-logging:commons-logging:1.0.3
>> > - http://jakarta.apache.org/commons/logging/)
>> >
>> > (BTW, those last 4 are already checked to be OK, see
>> > http://dev.mygrid.org.uk/wiki/display/developer/Third-party+licenses )
>> >
>> >
>> > > Regarding the build output: Since this is the first time I've done
>> this,
>> > I
>> > > don't know what's okay to ignore. Here is a summary of the warning
>> > messages
>> > > I received when I ran mvn clean install. I sent the output to two
>> > different
>> > > files using the following command (Windows 10/ GitBash): mvn clean
>> > install
>> > >> output1.txt 2> output2.txt. I appreciate any insight.
>> >
>> > Great! I think those should be tracked in JIRA as we want to reduce
>> > warnings.
>> >
>> >
>> >
>> > Generally with Maven, if it finishes with a big SUCCESS, then that's
>> > true. The warnings are more like warnings for the developers doing
>> > bad-practice-stuff than warnings about something going wrong with the
>> > build. Often the fixes are simple, like adding a @Deprecated tag
>> > where you delibately use old APIs, or actually follow the fix
>> > suggested by the warning.
>> >
>> > I think we want to follow Andy's advice and "release early, release
>> > often" - which entails a "good enough" - not "super-perfect".
>> > Obviously each committer votes independenly by their own quality
>> > measures.
>> >
>> > While Apache Software Foundation always says that community is king -
>> > the Apache name is still recognized by the public as a kind of
>> > "quality mark" - if that is deserved or not I won't comment on, but of
>> > course there is also a sense of pride in that we don't want to set the
>> > standard too low. :)
>> >
>> > (E.g. Taverna just cancelled 3 release candidates as they didn't pass
>> > all their tests on Windows - but the community of another Apache
>> > project might not consider Windows important enough to halt a release)
>> >
>> >
>> >
>> >
>> > --
>> > Stian Soiland-Reyes
>> > Apache Taverna (incubating), Apache Commons RDF (incubating)
>> > http://orcid.org/0000-0001-9842-9718
>> >
>>
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Ian Dunlop <ia...@gmail.com>.
Hello,
I think we need to capture all these tricks somewhere. Stian suggested we
propose updating the 'official' apache release page - sounds like a good
idea - but I think we could add it to the taverna pages first and then
maybe send a link to it to the (I don't know) incubator list to gauge
interest.
Cheers,
Ian
On 1 March 2016 at 22:42, Gale Naylor <Ga...@noventussolutions.com> wrote:
> Thank you, Stian! Some of my questions I figured out today, but some I did
> not, so I very much appreciate the hints and instructions.
>
>
> On Tue, Mar 1, 2016 at 2:28 PM Stian Soiland-Reyes <st...@apache.org>
> wrote:
>
> > Thanks for reviewing!
> >
> >
> > > (1) How do I verify that the commit id in the downloaded files matches
> > that
> > > in the VOTE email? (I've looked on the internet, but have yet to find
> > > anything helpful.)
> >
> > I don't think most people check this deeply.. but I guess at least one
> > voter should.
> >
> > Here's what I do:
> >
> > mkdir 1 ; cd 1 # new folder
> > git clone that-repository
> > git checkout that-commit-id-from-the-email-asdfjaskdjfsakjdfksajdf
> > rm -rf *
> > unzip ../the-release-candidate.zip
> > mv apache-taverna-*/* . (one level up)
> > git status
> >
> > Git will then check the checksums of every file and let you know what
> > has 'changed' (as it would believe you have edited it).
> >
> >
> > Here's another way that doesn't require using the 'git' command:
> >
> > Download the git commit corresponding to the email by browsing for it on
> > GitHub:
> >
> >
> >
> https://github.com/apache/incubator-taverna-language/tree/66866a5454ed23262c055f65155d7a195c68a17d
> > Click "Download ZIP"
> >
> > mkdir 1 ; cd 1
> > unzip ../66866a5454ed23262c055f65155d7a195c68a17d.zip
> >
> > cd ../ ; mkdir 2 ; cd 2
> > unzip release-candidate.zip
> >
> > cd ..
> > diff -uR 1 2
> >
> > The files that differ (and their differences!) will be shown.
> >
> > Make sure you don't have any target/ folders before diff-ing (run mvn
> > clean to be sure)
> >
> > If you do the above with a git clone instead - remember that the zip
> > doesn't include the .git/ folder - so you would have to delete the
> > checked out .git folder before diffing. (Don't do this on your
> > regular checkout as you would lose all local branches!)
> >
> >
> >
> > > (2) Are the "binary artifacts" in the target folders? Which files are
> > > considered "binary artifacts?"
> >
> > Well, the target/ files are binary artifacts, but they (should) have
> > been made by your build on your machine - not be part of the source
> > ZIP.
> >
> >
> > One thing to look out for is in the downloaded source ZIP that there
> > are no unexpected binary artifacts in it *before you build* - e.g.
> > there should not be any *.jars in there. (The source distribution
> > should be 'clean'). We do have some *expected* binaries, pictures and
> > test workflows for instance. As those can't have license headers they
> > should be declared in NOTICE/LICENSE if they came from third-parties.
> > (E.g. if we used a Creative Commons-licensed JPEG picture)
> >
> >
> > In terms of release candidate, the binaries would be installers and
> > JARs etc., under
> > https://dist.apache.org/repos/dist/dev/incubator/taverna/binaries/
> > (But there are none for this release candidate)
> >
> > ..in addition to the JARs that have been staged to the Maven repository
> >
> >
> https://repository.apache.org/content/repositories/orgapachetaverna-1011/org/apache/taverna/
> >
> >
> > > (3) How do I verify that the build produces the binaries? By visual
> > > inspection? What am I looking for?
> >
> >
> > As for checking the Maven repository, if you want to do it really
> > proper you should check that all the JARs that are staged can be built
> > from the downloaded release candidate ZIP - e.g. that your target/
> > folder contains all of the same ones. If I do this, I do a recursive
> > wget of the repository, and then compare the result of "find . -name
> > '*jar'" in the wget-tree with */*/target/*.jar. I don't think most
> > people do this.
> >
> > Paranoid-mode would be to download each JAR and check that they only
> > have the same *.class files - but these would differ for every build
> > and so can't be compared any further without lots of clever tooling -
> > so nobody does this. (I think there should be an Apache-hosted tool or
> > Maven plugin that could do this).
> >
> >
> > Practically the best is just to click briefly into the repository in a
> > browser and see there are not any 'additional' folders that shouldn't
> > be there, e.g. we are now voting on taverna-maven-parent, taverna-osgi
> > and taverna-language, and so we should not see
> > org/apache/taverna/engine in there - as that is a group Id from
> > taverna-engine.
> >
> > (We have already changed the groupIDs to correspond to the repository
> > which corresponds to the release name, so at least that correspondance
> > is easy to check on Taverna, but not so on many other projects).
> >
> >
> > As binary releases from Apache Software Foundation are considered
> > "convenience only" they are not crucial for the vote - the source
> > release is the golden thing which everything else should be made from.
> > Practically speaking "everyone" uses the JARs from Maven repository
> > though, so I wouldn't dismiss them totally - at least one person in
> > the vote should do such a check.
> >
> >
> > > (4) How do I check the dependencies?
> >
> > mvn dependency:tree gives a nice list - but what should you check for?
> > Well, it's mainly about licensing -
> > http://www.apache.org/legal/resolved.html lists what is compatible as
> > dependencies of an ASF release. Now you don't need to go through the
> > list - but sometimes there are Well Known forbidden dependencies that
> > People (tm) recognize -e.g. mysql-connector and Hibernate are banned
> > as they are (L)GPL.
> >
> > Luckily there's another Maven plugin that can do the job:
> >
> > mvn license:aggregate-add-third-party
> >
> > cat target/generated-sources/license/THIRD-PARTY.txt | sort
> >
> > (Aduna BSD license) OpenRDF Sesame: HTTP client
> > (org.openrdf.sesame:sesame-http-client:2.7.0 -
> > http://www.openrdf.org/sesame-core/sesame-http/sesame-http-client/)
> > (Aduna BSD license) OpenRDF Sesame: HTTP protocol
> > (org.openrdf.sesame:sesame-http-protocol:2.7.0 -
> > http://www.openrdf.org/sesame-core/sesame-http/sesame-http-protocol/)
> > (..)
> > (The Apache Software License, Version 2.0) Xerces2-j
> > (xerces:xercesImpl:2.11.0 - https://xerces.apache.org/xerces2-j/)
> > (Unknown license) commons-beanutils
> > (commons-beanutils:commons-beanutils:1.7.0 - no url defined)
> > (Unknown license) com.springsource.org.jaxen
> > (org.jaxen:com.springsource.org.jaxen:1.1.1 - no url defined)
> > (Unknown license) com.springsource.org.jdom
> > (org.jdom:com.springsource.org.jdom:1.1.0 - no url defined)
> > (Unknown license) Logging (commons-logging:commons-logging:1.0.3
> > - http://jakarta.apache.org/commons/logging/)
> >
> > (BTW, those last 4 are already checked to be OK, see
> > http://dev.mygrid.org.uk/wiki/display/developer/Third-party+licenses )
> >
> >
> > > Regarding the build output: Since this is the first time I've done
> this,
> > I
> > > don't know what's okay to ignore. Here is a summary of the warning
> > messages
> > > I received when I ran mvn clean install. I sent the output to two
> > different
> > > files using the following command (Windows 10/ GitBash): mvn clean
> > install
> > >> output1.txt 2> output2.txt. I appreciate any insight.
> >
> > Great! I think those should be tracked in JIRA as we want to reduce
> > warnings.
> >
> >
> >
> > Generally with Maven, if it finishes with a big SUCCESS, then that's
> > true. The warnings are more like warnings for the developers doing
> > bad-practice-stuff than warnings about something going wrong with the
> > build. Often the fixes are simple, like adding a @Deprecated tag
> > where you delibately use old APIs, or actually follow the fix
> > suggested by the warning.
> >
> > I think we want to follow Andy's advice and "release early, release
> > often" - which entails a "good enough" - not "super-perfect".
> > Obviously each committer votes independenly by their own quality
> > measures.
> >
> > While Apache Software Foundation always says that community is king -
> > the Apache name is still recognized by the public as a kind of
> > "quality mark" - if that is deserved or not I won't comment on, but of
> > course there is also a sense of pride in that we don't want to set the
> > standard too low. :)
> >
> > (E.g. Taverna just cancelled 3 release candidates as they didn't pass
> > all their tests on Windows - but the community of another Apache
> > project might not consider Windows important enough to halt a release)
> >
> >
> >
> >
> > --
> > Stian Soiland-Reyes
> > Apache Taverna (incubating), Apache Commons RDF (incubating)
> > http://orcid.org/0000-0001-9842-9718
> >
>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Gale Naylor <Ga...@noventussolutions.com>.
Thank you, Stian! Some of my questions I figured out today, but some I did
not, so I very much appreciate the hints and instructions.
On Tue, Mar 1, 2016 at 2:28 PM Stian Soiland-Reyes <st...@apache.org> wrote:
> Thanks for reviewing!
>
>
> > (1) How do I verify that the commit id in the downloaded files matches
> that
> > in the VOTE email? (I've looked on the internet, but have yet to find
> > anything helpful.)
>
> I don't think most people check this deeply.. but I guess at least one
> voter should.
>
> Here's what I do:
>
> mkdir 1 ; cd 1 # new folder
> git clone that-repository
> git checkout that-commit-id-from-the-email-asdfjaskdjfsakjdfksajdf
> rm -rf *
> unzip ../the-release-candidate.zip
> mv apache-taverna-*/* . (one level up)
> git status
>
> Git will then check the checksums of every file and let you know what
> has 'changed' (as it would believe you have edited it).
>
>
> Here's another way that doesn't require using the 'git' command:
>
> Download the git commit corresponding to the email by browsing for it on
> GitHub:
>
>
> https://github.com/apache/incubator-taverna-language/tree/66866a5454ed23262c055f65155d7a195c68a17d
> Click "Download ZIP"
>
> mkdir 1 ; cd 1
> unzip ../66866a5454ed23262c055f65155d7a195c68a17d.zip
>
> cd ../ ; mkdir 2 ; cd 2
> unzip release-candidate.zip
>
> cd ..
> diff -uR 1 2
>
> The files that differ (and their differences!) will be shown.
>
> Make sure you don't have any target/ folders before diff-ing (run mvn
> clean to be sure)
>
> If you do the above with a git clone instead - remember that the zip
> doesn't include the .git/ folder - so you would have to delete the
> checked out .git folder before diffing. (Don't do this on your
> regular checkout as you would lose all local branches!)
>
>
>
> > (2) Are the "binary artifacts" in the target folders? Which files are
> > considered "binary artifacts?"
>
> Well, the target/ files are binary artifacts, but they (should) have
> been made by your build on your machine - not be part of the source
> ZIP.
>
>
> One thing to look out for is in the downloaded source ZIP that there
> are no unexpected binary artifacts in it *before you build* - e.g.
> there should not be any *.jars in there. (The source distribution
> should be 'clean'). We do have some *expected* binaries, pictures and
> test workflows for instance. As those can't have license headers they
> should be declared in NOTICE/LICENSE if they came from third-parties.
> (E.g. if we used a Creative Commons-licensed JPEG picture)
>
>
> In terms of release candidate, the binaries would be installers and
> JARs etc., under
> https://dist.apache.org/repos/dist/dev/incubator/taverna/binaries/
> (But there are none for this release candidate)
>
> ..in addition to the JARs that have been staged to the Maven repository
>
> https://repository.apache.org/content/repositories/orgapachetaverna-1011/org/apache/taverna/
>
>
> > (3) How do I verify that the build produces the binaries? By visual
> > inspection? What am I looking for?
>
>
> As for checking the Maven repository, if you want to do it really
> proper you should check that all the JARs that are staged can be built
> from the downloaded release candidate ZIP - e.g. that your target/
> folder contains all of the same ones. If I do this, I do a recursive
> wget of the repository, and then compare the result of "find . -name
> '*jar'" in the wget-tree with */*/target/*.jar. I don't think most
> people do this.
>
> Paranoid-mode would be to download each JAR and check that they only
> have the same *.class files - but these would differ for every build
> and so can't be compared any further without lots of clever tooling -
> so nobody does this. (I think there should be an Apache-hosted tool or
> Maven plugin that could do this).
>
>
> Practically the best is just to click briefly into the repository in a
> browser and see there are not any 'additional' folders that shouldn't
> be there, e.g. we are now voting on taverna-maven-parent, taverna-osgi
> and taverna-language, and so we should not see
> org/apache/taverna/engine in there - as that is a group Id from
> taverna-engine.
>
> (We have already changed the groupIDs to correspond to the repository
> which corresponds to the release name, so at least that correspondance
> is easy to check on Taverna, but not so on many other projects).
>
>
> As binary releases from Apache Software Foundation are considered
> "convenience only" they are not crucial for the vote - the source
> release is the golden thing which everything else should be made from.
> Practically speaking "everyone" uses the JARs from Maven repository
> though, so I wouldn't dismiss them totally - at least one person in
> the vote should do such a check.
>
>
> > (4) How do I check the dependencies?
>
> mvn dependency:tree gives a nice list - but what should you check for?
> Well, it's mainly about licensing -
> http://www.apache.org/legal/resolved.html lists what is compatible as
> dependencies of an ASF release. Now you don't need to go through the
> list - but sometimes there are Well Known forbidden dependencies that
> People (tm) recognize -e.g. mysql-connector and Hibernate are banned
> as they are (L)GPL.
>
> Luckily there's another Maven plugin that can do the job:
>
> mvn license:aggregate-add-third-party
>
> cat target/generated-sources/license/THIRD-PARTY.txt | sort
>
> (Aduna BSD license) OpenRDF Sesame: HTTP client
> (org.openrdf.sesame:sesame-http-client:2.7.0 -
> http://www.openrdf.org/sesame-core/sesame-http/sesame-http-client/)
> (Aduna BSD license) OpenRDF Sesame: HTTP protocol
> (org.openrdf.sesame:sesame-http-protocol:2.7.0 -
> http://www.openrdf.org/sesame-core/sesame-http/sesame-http-protocol/)
> (..)
> (The Apache Software License, Version 2.0) Xerces2-j
> (xerces:xercesImpl:2.11.0 - https://xerces.apache.org/xerces2-j/)
> (Unknown license) commons-beanutils
> (commons-beanutils:commons-beanutils:1.7.0 - no url defined)
> (Unknown license) com.springsource.org.jaxen
> (org.jaxen:com.springsource.org.jaxen:1.1.1 - no url defined)
> (Unknown license) com.springsource.org.jdom
> (org.jdom:com.springsource.org.jdom:1.1.0 - no url defined)
> (Unknown license) Logging (commons-logging:commons-logging:1.0.3
> - http://jakarta.apache.org/commons/logging/)
>
> (BTW, those last 4 are already checked to be OK, see
> http://dev.mygrid.org.uk/wiki/display/developer/Third-party+licenses )
>
>
> > Regarding the build output: Since this is the first time I've done this,
> I
> > don't know what's okay to ignore. Here is a summary of the warning
> messages
> > I received when I ran mvn clean install. I sent the output to two
> different
> > files using the following command (Windows 10/ GitBash): mvn clean
> install
> >> output1.txt 2> output2.txt. I appreciate any insight.
>
> Great! I think those should be tracked in JIRA as we want to reduce
> warnings.
>
>
>
> Generally with Maven, if it finishes with a big SUCCESS, then that's
> true. The warnings are more like warnings for the developers doing
> bad-practice-stuff than warnings about something going wrong with the
> build. Often the fixes are simple, like adding a @Deprecated tag
> where you delibately use old APIs, or actually follow the fix
> suggested by the warning.
>
> I think we want to follow Andy's advice and "release early, release
> often" - which entails a "good enough" - not "super-perfect".
> Obviously each committer votes independenly by their own quality
> measures.
>
> While Apache Software Foundation always says that community is king -
> the Apache name is still recognized by the public as a kind of
> "quality mark" - if that is deserved or not I won't comment on, but of
> course there is also a sense of pride in that we don't want to set the
> standard too low. :)
>
> (E.g. Taverna just cancelled 3 release candidates as they didn't pass
> all their tests on Windows - but the community of another Apache
> project might not consider Windows important enough to halt a release)
>
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/0000-0001-9842-9718
>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Stian Soiland-Reyes <st...@apache.org>.
Thanks for reviewing!
> (1) How do I verify that the commit id in the downloaded files matches that
> in the VOTE email? (I've looked on the internet, but have yet to find
> anything helpful.)
I don't think most people check this deeply.. but I guess at least one
voter should.
Here's what I do:
mkdir 1 ; cd 1 # new folder
git clone that-repository
git checkout that-commit-id-from-the-email-asdfjaskdjfsakjdfksajdf
rm -rf *
unzip ../the-release-candidate.zip
mv apache-taverna-*/* . (one level up)
git status
Git will then check the checksums of every file and let you know what
has 'changed' (as it would believe you have edited it).
Here's another way that doesn't require using the 'git' command:
Download the git commit corresponding to the email by browsing for it on GitHub:
https://github.com/apache/incubator-taverna-language/tree/66866a5454ed23262c055f65155d7a195c68a17d
Click "Download ZIP"
mkdir 1 ; cd 1
unzip ../66866a5454ed23262c055f65155d7a195c68a17d.zip
cd ../ ; mkdir 2 ; cd 2
unzip release-candidate.zip
cd ..
diff -uR 1 2
The files that differ (and their differences!) will be shown.
Make sure you don't have any target/ folders before diff-ing (run mvn
clean to be sure)
If you do the above with a git clone instead - remember that the zip
doesn't include the .git/ folder - so you would have to delete the
checked out .git folder before diffing. (Don't do this on your
regular checkout as you would lose all local branches!)
> (2) Are the "binary artifacts" in the target folders? Which files are
> considered "binary artifacts?"
Well, the target/ files are binary artifacts, but they (should) have
been made by your build on your machine - not be part of the source
ZIP.
One thing to look out for is in the downloaded source ZIP that there
are no unexpected binary artifacts in it *before you build* - e.g.
there should not be any *.jars in there. (The source distribution
should be 'clean'). We do have some *expected* binaries, pictures and
test workflows for instance. As those can't have license headers they
should be declared in NOTICE/LICENSE if they came from third-parties.
(E.g. if we used a Creative Commons-licensed JPEG picture)
In terms of release candidate, the binaries would be installers and
JARs etc., under
https://dist.apache.org/repos/dist/dev/incubator/taverna/binaries/
(But there are none for this release candidate)
..in addition to the JARs that have been staged to the Maven repository
https://repository.apache.org/content/repositories/orgapachetaverna-1011/org/apache/taverna/
> (3) How do I verify that the build produces the binaries? By visual
> inspection? What am I looking for?
As for checking the Maven repository, if you want to do it really
proper you should check that all the JARs that are staged can be built
from the downloaded release candidate ZIP - e.g. that your target/
folder contains all of the same ones. If I do this, I do a recursive
wget of the repository, and then compare the result of "find . -name
'*jar'" in the wget-tree with */*/target/*.jar. I don't think most
people do this.
Paranoid-mode would be to download each JAR and check that they only
have the same *.class files - but these would differ for every build
and so can't be compared any further without lots of clever tooling -
so nobody does this. (I think there should be an Apache-hosted tool or
Maven plugin that could do this).
Practically the best is just to click briefly into the repository in a
browser and see there are not any 'additional' folders that shouldn't
be there, e.g. we are now voting on taverna-maven-parent, taverna-osgi
and taverna-language, and so we should not see
org/apache/taverna/engine in there - as that is a group Id from
taverna-engine.
(We have already changed the groupIDs to correspond to the repository
which corresponds to the release name, so at least that correspondance
is easy to check on Taverna, but not so on many other projects).
As binary releases from Apache Software Foundation are considered
"convenience only" they are not crucial for the vote - the source
release is the golden thing which everything else should be made from.
Practically speaking "everyone" uses the JARs from Maven repository
though, so I wouldn't dismiss them totally - at least one person in
the vote should do such a check.
> (4) How do I check the dependencies?
mvn dependency:tree gives a nice list - but what should you check for?
Well, it's mainly about licensing -
http://www.apache.org/legal/resolved.html lists what is compatible as
dependencies of an ASF release. Now you don't need to go through the
list - but sometimes there are Well Known forbidden dependencies that
People (tm) recognize -e.g. mysql-connector and Hibernate are banned
as they are (L)GPL.
Luckily there's another Maven plugin that can do the job:
mvn license:aggregate-add-third-party
cat target/generated-sources/license/THIRD-PARTY.txt | sort
(Aduna BSD license) OpenRDF Sesame: HTTP client
(org.openrdf.sesame:sesame-http-client:2.7.0 -
http://www.openrdf.org/sesame-core/sesame-http/sesame-http-client/)
(Aduna BSD license) OpenRDF Sesame: HTTP protocol
(org.openrdf.sesame:sesame-http-protocol:2.7.0 -
http://www.openrdf.org/sesame-core/sesame-http/sesame-http-protocol/)
(..)
(The Apache Software License, Version 2.0) Xerces2-j
(xerces:xercesImpl:2.11.0 - https://xerces.apache.org/xerces2-j/)
(Unknown license) commons-beanutils
(commons-beanutils:commons-beanutils:1.7.0 - no url defined)
(Unknown license) com.springsource.org.jaxen
(org.jaxen:com.springsource.org.jaxen:1.1.1 - no url defined)
(Unknown license) com.springsource.org.jdom
(org.jdom:com.springsource.org.jdom:1.1.0 - no url defined)
(Unknown license) Logging (commons-logging:commons-logging:1.0.3
- http://jakarta.apache.org/commons/logging/)
(BTW, those last 4 are already checked to be OK, see
http://dev.mygrid.org.uk/wiki/display/developer/Third-party+licenses )
> Regarding the build output: Since this is the first time I've done this, I
> don't know what's okay to ignore. Here is a summary of the warning messages
> I received when I ran mvn clean install. I sent the output to two different
> files using the following command (Windows 10/ GitBash): mvn clean install
>> output1.txt 2> output2.txt. I appreciate any insight.
Great! I think those should be tracked in JIRA as we want to reduce warnings.
Generally with Maven, if it finishes with a big SUCCESS, then that's
true. The warnings are more like warnings for the developers doing
bad-practice-stuff than warnings about something going wrong with the
build. Often the fixes are simple, like adding a @Deprecated tag
where you delibately use old APIs, or actually follow the fix
suggested by the warning.
I think we want to follow Andy's advice and "release early, release
often" - which entails a "good enough" - not "super-perfect".
Obviously each committer votes independenly by their own quality
measures.
While Apache Software Foundation always says that community is king -
the Apache name is still recognized by the public as a kind of
"quality mark" - if that is deserved or not I won't comment on, but of
course there is also a sense of pride in that we don't want to set the
standard too low. :)
(E.g. Taverna just cancelled 3 release candidates as they didn't pass
all their tests on Windows - but the community of another Apache
project might not consider Windows important enough to halt a release)
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Gale Naylor <Ga...@noventussolutions.com>.
I have successfully built the files, but I'm not ready to vote because I
have a few questions.
I am following Andy's "quick and not complete summary of what a VOTE
entails":
(1) How do I verify that the commit id in the downloaded files matches that
in the VOTE email? (I've looked on the internet, but have yet to find
anything helpful.)
(2) Are the "binary artifacts" in the target folders? Which files are
considered "binary artifacts?"
(3) How do I verify that the build produces the binaries? By visual
inspection? What am I looking for?
(4) How do I check the dependencies?
Regarding the build output: Since this is the first time I've done this, I
don't know what's okay to ignore. Here is a summary of the warning messages
I received when I ran mvn clean install. I sent the output to two different
files using the following command (Windows 10/ GitBash): mvn clean install
> output1.txt 2> output2.txt. I appreciate any insight.
** taverna-parent-2: Build successful. The errors file was empty and the
console file had one warning about an empty jar.
** taverna language: Build successful. Warnings, some with multiple
occurrences.
---------------------
language output1 file
---------------------
(1) Empty jar warning
(2) Lots of JavaDoc warnings -- @return tag has no arguments, illegal
characters, can't find configurationsFor(Activity,Profile) etc.
(3) Private references -- Export org.apache.taverna.scufl2.ucfpackage, has
1, private references
[org.apache.taverna.scufl2.ucfpackage.impl.odfdom.pkg.manifest],
(4) Program names are deprecated -- e.g., The usage of program name
(workflowmaker) is deprecated. Please use program.id instead.
(5) Private packages -- Unused Private-Package instructions, no such
package(s) on the class path: [!*]
(6) Relative URIs -- Relative URIs are not permitted in RDF: specifically
<ont-policy.rdf>
(7) Overlapping classes -- for example, xpp3_min-1.1.4c.jar,
xmlpull-1.1.3.1.jar define 2 overlapping classes:
- org.xmlpull.v1.XmlPullParserException
- org.xmlpull.v1.XmlPullParser
---------------------
language output2 file
---------------------
(1) Unexpected failure of setLastModifiedTime on root --
java.nio.file.oSuchFileException:
(2) Unexpected exception-- java.nio.file.NoSuchFileException: test.txt
at com.sun.nio.zipfs.ZipFileSystem.newFileChannel
(ZipFileSystem.java:709)
[and about 30 more in list]
(3) log4j - no appenders could be found for logger ... Please initialize
the log4j system properly.
log4j
(4) Expected literal -- Expected literal. not -183cb345:1532e6bc46e:-7ffe
(5) Skipping aggregation -- Skipping aggregation without URI:
266e243ce4d408285e522380c4484af0
(6) Ignoring unsupported PropertyResource -- (from wfbundle 0.2.0 or older)
for Configuration "Hello" [beanshell:script: null]
(7) Could not translate link -- for example, ... More than one link to
non-merged port InputProcessorPort "inputlist"
(8) Unknown T2 activity or dispatch layer --
http://ns.taverna.org.uk/2010/xml/t2flow/raven/undefined/net.sf.taverna.t2.workflowmodel.processor.dispatch.layers.Parallelize,
install supporting T2Parser
(9) Invalid output port binding -- unknown processor port: value->value in
Processor "alternates"
(10) Ambiguous owl:versionInfo -- there is more than one owl:Ontology
element.
** taverna osgi: Build successful. Warnings.
---------------------
osgi output1 file
---------------------
(1) Deprecated @component -- for example, Deprecated @component for project
field in org.apache.taverna.mavenplugin.TavernaProfileDeployMojo.: replace
with @parameter name="${project}" @readonly
(2) Several sets of JavaDoc errors.
---------------------
osgi output2 file
---------------------
(1) log4j warning -- no appenders could be found for logger... Please
initialize the log4j system properly.
log4j
-----------------------------------------------------------------------
Thank you.
On Mon, Feb 29, 2016 at 3:16 AM Stian Soiland-Reyes <st...@apache.org>
wrote:
> Looking back at OASIS license I am not sure now.
>
> I've made
> https://issues.apache.org/jira/browse/TAVERNA-925
> to clarify.
>
> As far as I can see why are fine legally to distribute the ODF spec
> files as we have not modified them, however it would seem to be
> against ASF policy:
>
> _____________ Errors file
> http://www.apache.org/legal/resolved.html#no-modification
>
>
> I believe that as we are legally OK against OASIS, and we are still an
> incubating project with DISCLAIMER, this policy breach should not be a
> blocker for this release - but it would have to be sorted before the
> first proper ASF release of Taverna Language.
>
> Other views? Mentors?
>
> On 29 February 2016 at 01:18, Gale Naylor <Ga...@noventussolutions.com>
> wrote:
> > More on LICENSES
> > Apache includes Creative Commons Attribution licenses in their "weak
> > copyleft" list and (though I don't understand why) Apache suggests
> > attaching "an appropriate and prominent label to the distribution ... for
> > example in a README." (http://www.apache.org/legal/resolved.html).
> Should
> > we have some kind of notice in the scufl2-wfdesc and robundle (etc.)
> README
> > files that flags the embedded CCA licenses?
> >
> > Also, I have yet to independently verify this, but I presume it was
> > determined earlier that the oa.rdf (robundle) W3C CCLA license is okay,
> as
> > well as the Open-document (robundle) OASIS license/notification.
> >
> > Thanks,
> >
> > Gale
> >
> > On Sun, Feb 28, 2016 at 3:02 PM Gale Naylor <GaleN@noventussolutions.com
> >
> > wrote:
> >
> >> RE: LICENSES
> >> Now I've come across this set of statements: "These third party notices
> >> vary from license to license. Apache releases should contain a copy of
> each
> >> license, usually contained in the LICENSE document." (
> >> http://apache.org/legal/resolved.html#required-third-party-notices.)
> But
> >> maybe this is saying: Apache releases should contain a copy of each (3rd
> >> party) license, which is usually contained in the *3rd party* LICENSE
> >> document? (Rather than saying the notice should be in the Apache LICENSE
> >> document, which is what I thought at first. Can anyone shed light on
> this?
> >>
> >> On Sun, Feb 28, 2016 at 2:54 PM Gale Naylor <
> GaleN@noventussolutions.com>
> >> wrote:
> >>
> >>> Thank you very much for the details, Andy. I'm doing my best to come up
> >>> to speed on all this.
> >>>
> >>> A question:
> >>> In looking at the LICENSE files, and the Apache documentation (
> >>> http://www.apache.org/legal/src-headers.html#notice), I'm wondering
> >>> about the Taverna Language License, which contains several copyright
> >>> notices. The documentation I referenced says: "Use the NOTICE file to
> >>> collect copyright notices and required attributions." Am I
> misinterpreting
> >>> this? Should these copyright notices be in the NOTICE file? (Profuse
> >>> apologies if this was already discussed when I was less up-to-speed.)
> >>>
> >>> Gale
> >>>
> >>> On Sun, Feb 28, 2016 at 2:19 AM Andy Seaborne <an...@apache.org> wrote:
> >>>
> >>>> On 27/02/16 23:33, Stian Soiland-Reyes wrote:
> >>>> > Use this thread to discuss any issues with RC5 which is currently
> >>>> > under VOTE. If needed we'll also make Jira issues.
> >>>> >
> >>>> > Under the corresponding [VOTE] thread - only reply with your vote,
> >>>> > e.g. "+1". It is a single vote for releasing all three artifacts at
> >>>> > once.
> >>>> >
> >>>>
> >>>> Releases are the high point a project.
> >>>>
> >>>> PPMC members - feel morally obliged to vote!
> >>>>
> >>>> Everyone else - help out - it's not "devs and users" - it's
> "community".
> >>>>
> >>>> Don't forget what really matters when you vote +1 is that the release
> >>>> meets the Apache requirements and then any additional local community
> >>>> norms.
> >>>>
> >>>> A quick and not complete summary of what a VOTE entails:
> >>>>
> >>>> ** Source
> >>>>
> >>>> The source artifact is the thing being released.
> >>>> Binaries and git are secondary.
> >>>>
> >>>> People voting must download the source artifact and check it.
> >>>>
> >>>> do the signatures on the source archive check out?
> >>>> does the commit id lead to the same sources?
> >>>>
> >>>> ** ASF licensing policy
> >>>>
> >>>> Much of this code being is released for the first time so LICENSE and
> >>>> NOTICE are mostly new.
> >>>>
> >>>> does the NOTICE file contain all necessary attributions?
> >>>> is there a correct LICENSE and NOTICE file in each artifact (both
> source
> >>>> and binary artifacts)?
> >>>>
> >>>> ** Build
> >>>>
> >>>> does the build of the source artifact actually produce the binaries?
> >>>> check the dependencies.
> >>>>
> >>>> ** Process
> >>>>
> >>>> Support the release manager!
> >>>>
> >>>> The minimum is 3 +1 votes with a majority in favour.
> >>>> The RM decides about what to do about comments.
> >>>>
> >>>> Does the quality level meet the group norms?
> >>>> ("can we live with it?" and not "is it perfect?")
> >>>>
> >>>>
> >>>> https://www.apache.org/dev/release.html
> >>>>
> >>>> Andy
> >>>>
> >>>>
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/0000-0001-9842-9718
>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Stian Soiland-Reyes <st...@apache.org>.
Looking back at OASIS license I am not sure now.
I've made
https://issues.apache.org/jira/browse/TAVERNA-925
to clarify.
As far as I can see why are fine legally to distribute the ODF spec
files as we have not modified them, however it would seem to be
against ASF policy:
http://www.apache.org/legal/resolved.html#no-modification
I believe that as we are legally OK against OASIS, and we are still an
incubating project with DISCLAIMER, this policy breach should not be a
blocker for this release - but it would have to be sorted before the
first proper ASF release of Taverna Language.
Other views? Mentors?
On 29 February 2016 at 01:18, Gale Naylor <Ga...@noventussolutions.com> wrote:
> More on LICENSES
> Apache includes Creative Commons Attribution licenses in their "weak
> copyleft" list and (though I don't understand why) Apache suggests
> attaching "an appropriate and prominent label to the distribution ... for
> example in a README." (http://www.apache.org/legal/resolved.html). Should
> we have some kind of notice in the scufl2-wfdesc and robundle (etc.) README
> files that flags the embedded CCA licenses?
>
> Also, I have yet to independently verify this, but I presume it was
> determined earlier that the oa.rdf (robundle) W3C CCLA license is okay, as
> well as the Open-document (robundle) OASIS license/notification.
>
> Thanks,
>
> Gale
>
> On Sun, Feb 28, 2016 at 3:02 PM Gale Naylor <Ga...@noventussolutions.com>
> wrote:
>
>> RE: LICENSES
>> Now I've come across this set of statements: "These third party notices
>> vary from license to license. Apache releases should contain a copy of each
>> license, usually contained in the LICENSE document." (
>> http://apache.org/legal/resolved.html#required-third-party-notices.) But
>> maybe this is saying: Apache releases should contain a copy of each (3rd
>> party) license, which is usually contained in the *3rd party* LICENSE
>> document? (Rather than saying the notice should be in the Apache LICENSE
>> document, which is what I thought at first. Can anyone shed light on this?
>>
>> On Sun, Feb 28, 2016 at 2:54 PM Gale Naylor <Ga...@noventussolutions.com>
>> wrote:
>>
>>> Thank you very much for the details, Andy. I'm doing my best to come up
>>> to speed on all this.
>>>
>>> A question:
>>> In looking at the LICENSE files, and the Apache documentation (
>>> http://www.apache.org/legal/src-headers.html#notice), I'm wondering
>>> about the Taverna Language License, which contains several copyright
>>> notices. The documentation I referenced says: "Use the NOTICE file to
>>> collect copyright notices and required attributions." Am I misinterpreting
>>> this? Should these copyright notices be in the NOTICE file? (Profuse
>>> apologies if this was already discussed when I was less up-to-speed.)
>>>
>>> Gale
>>>
>>> On Sun, Feb 28, 2016 at 2:19 AM Andy Seaborne <an...@apache.org> wrote:
>>>
>>>> On 27/02/16 23:33, Stian Soiland-Reyes wrote:
>>>> > Use this thread to discuss any issues with RC5 which is currently
>>>> > under VOTE. If needed we'll also make Jira issues.
>>>> >
>>>> > Under the corresponding [VOTE] thread - only reply with your vote,
>>>> > e.g. "+1". It is a single vote for releasing all three artifacts at
>>>> > once.
>>>> >
>>>>
>>>> Releases are the high point a project.
>>>>
>>>> PPMC members - feel morally obliged to vote!
>>>>
>>>> Everyone else - help out - it's not "devs and users" - it's "community".
>>>>
>>>> Don't forget what really matters when you vote +1 is that the release
>>>> meets the Apache requirements and then any additional local community
>>>> norms.
>>>>
>>>> A quick and not complete summary of what a VOTE entails:
>>>>
>>>> ** Source
>>>>
>>>> The source artifact is the thing being released.
>>>> Binaries and git are secondary.
>>>>
>>>> People voting must download the source artifact and check it.
>>>>
>>>> do the signatures on the source archive check out?
>>>> does the commit id lead to the same sources?
>>>>
>>>> ** ASF licensing policy
>>>>
>>>> Much of this code being is released for the first time so LICENSE and
>>>> NOTICE are mostly new.
>>>>
>>>> does the NOTICE file contain all necessary attributions?
>>>> is there a correct LICENSE and NOTICE file in each artifact (both source
>>>> and binary artifacts)?
>>>>
>>>> ** Build
>>>>
>>>> does the build of the source artifact actually produce the binaries?
>>>> check the dependencies.
>>>>
>>>> ** Process
>>>>
>>>> Support the release manager!
>>>>
>>>> The minimum is 3 +1 votes with a majority in favour.
>>>> The RM decides about what to do about comments.
>>>>
>>>> Does the quality level meet the group norms?
>>>> ("can we live with it?" and not "is it perfect?")
>>>>
>>>>
>>>> https://www.apache.org/dev/release.html
>>>>
>>>> Andy
>>>>
>>>>
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Stian Soiland-Reyes <st...@apache.org>.
I think CCLA
https://www.w3.org/community/about/agreements/cla/
is OK because it is only an attribution requirement - so it's pretty
much like a BSD 2-clause license. Derivatives are OK.
< 2.1. Copyright Grant. I grant to you a perpetual (for the duration
of the applicable copyright), worldwide, non-exclusive, no-charge,
royalty-free, copyright license, without any obligation for accounting
to me, to reproduce, prepare derivative works of, publicly display,
publicly perform, sublicense, distribute, and implement any
Contribution to the full extent of my copyright interest in the
Contribution.
> 2.2. Attribution. As a condition of the copyright grant, you must include an attribution to the Specification in any derivative work you make based on the Specification. That attribution must include, at minimum, the Specification name and version number.
I now see we forgot to mention the version number in the LICENSE file
for oa.rdf (but I added it now for the future). However the version
number *is* included in our copy of the work:
https://github.com/apache/incubator-taverna-language/blob/master/taverna-robundle/src/main/resources/ontologies/oa.rdf#L50
..and so it should be fine legally as the 2.2 clause does not say HOW
we should include the attribution. (Apache License on the other hand
is more picky, in that what we put in our NOTICE must stay in the
NOTICE file).
While technically just including Creative Commons and BSD-like
license/copyright statements directly in the copied source file is
legally sufficient, we think it's good to also help the downstream
users find such by listing them in LICENSE as we have done. However
there is no requirement from them to list them in NOTICE, and so we
don't.
Perhaps the W3C CCLA should be raised with LEGAL so it gets added to
the list. It's a bit weird license in that it mainly says what the
contributor to a W3C Community Group have granted (to whom?) - but not
necessarily that this license has been granted to anyone downloading
the spec.
On 29 February 2016 at 01:18, Gale Naylor <Ga...@noventussolutions.com> wrote:
> More on LICENSES
> Apache includes Creative Commons Attribution licenses in their "weak
> copyleft" list and (though I don't understand why) Apache suggests
> attaching "an appropriate and prominent label to the distribution ... for
> example in a README." (http://www.apache.org/legal/resolved.html). Should
> we have some kind of notice in the scufl2-wfdesc and robundle (etc.) README
> files that flags the embedded CCA licenses?
>
> Also, I have yet to independently verify this, but I presume it was
> determined earlier that the oa.rdf (robundle) W3C CCLA license is okay, as
> well as the Open-document (robundle) OASIS license/notification.
>
> Thanks,
>
> Gale
>
> On Sun, Feb 28, 2016 at 3:02 PM Gale Naylor <Ga...@noventussolutions.com>
> wrote:
>
>> RE: LICENSES
>> Now I've come across this set of statements: "These third party notices
>> vary from license to license. Apache releases should contain a copy of each
>> license, usually contained in the LICENSE document." (
>> http://apache.org/legal/resolved.html#required-third-party-notices.) But
>> maybe this is saying: Apache releases should contain a copy of each (3rd
>> party) license, which is usually contained in the *3rd party* LICENSE
>> document? (Rather than saying the notice should be in the Apache LICENSE
>> document, which is what I thought at first. Can anyone shed light on this?
>>
>> On Sun, Feb 28, 2016 at 2:54 PM Gale Naylor <Ga...@noventussolutions.com>
>> wrote:
>>
>>> Thank you very much for the details, Andy. I'm doing my best to come up
>>> to speed on all this.
>>>
>>> A question:
>>> In looking at the LICENSE files, and the Apache documentation (
>>> http://www.apache.org/legal/src-headers.html#notice), I'm wondering
>>> about the Taverna Language License, which contains several copyright
>>> notices. The documentation I referenced says: "Use the NOTICE file to
>>> collect copyright notices and required attributions." Am I misinterpreting
>>> this? Should these copyright notices be in the NOTICE file? (Profuse
>>> apologies if this was already discussed when I was less up-to-speed.)
>>>
>>> Gale
>>>
>>> On Sun, Feb 28, 2016 at 2:19 AM Andy Seaborne <an...@apache.org> wrote:
>>>
>>>> On 27/02/16 23:33, Stian Soiland-Reyes wrote:
>>>> > Use this thread to discuss any issues with RC5 which is currently
>>>> > under VOTE. If needed we'll also make Jira issues.
>>>> >
>>>> > Under the corresponding [VOTE] thread - only reply with your vote,
>>>> > e.g. "+1". It is a single vote for releasing all three artifacts at
>>>> > once.
>>>> >
>>>>
>>>> Releases are the high point a project.
>>>>
>>>> PPMC members - feel morally obliged to vote!
>>>>
>>>> Everyone else - help out - it's not "devs and users" - it's "community".
>>>>
>>>> Don't forget what really matters when you vote +1 is that the release
>>>> meets the Apache requirements and then any additional local community
>>>> norms.
>>>>
>>>> A quick and not complete summary of what a VOTE entails:
>>>>
>>>> ** Source
>>>>
>>>> The source artifact is the thing being released.
>>>> Binaries and git are secondary.
>>>>
>>>> People voting must download the source artifact and check it.
>>>>
>>>> do the signatures on the source archive check out?
>>>> does the commit id lead to the same sources?
>>>>
>>>> ** ASF licensing policy
>>>>
>>>> Much of this code being is released for the first time so LICENSE and
>>>> NOTICE are mostly new.
>>>>
>>>> does the NOTICE file contain all necessary attributions?
>>>> is there a correct LICENSE and NOTICE file in each artifact (both source
>>>> and binary artifacts)?
>>>>
>>>> ** Build
>>>>
>>>> does the build of the source artifact actually produce the binaries?
>>>> check the dependencies.
>>>>
>>>> ** Process
>>>>
>>>> Support the release manager!
>>>>
>>>> The minimum is 3 +1 votes with a majority in favour.
>>>> The RM decides about what to do about comments.
>>>>
>>>> Does the quality level meet the group norms?
>>>> ("can we live with it?" and not "is it perfect?")
>>>>
>>>>
>>>> https://www.apache.org/dev/release.html
>>>>
>>>> Andy
>>>>
>>>>
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Gale Naylor <Ga...@noventussolutions.com>.
More on LICENSES
Apache includes Creative Commons Attribution licenses in their "weak
copyleft" list and (though I don't understand why) Apache suggests
attaching "an appropriate and prominent label to the distribution ... for
example in a README." (http://www.apache.org/legal/resolved.html). Should
we have some kind of notice in the scufl2-wfdesc and robundle (etc.) README
files that flags the embedded CCA licenses?
Also, I have yet to independently verify this, but I presume it was
determined earlier that the oa.rdf (robundle) W3C CCLA license is okay, as
well as the Open-document (robundle) OASIS license/notification.
Thanks,
Gale
On Sun, Feb 28, 2016 at 3:02 PM Gale Naylor <Ga...@noventussolutions.com>
wrote:
> RE: LICENSES
> Now I've come across this set of statements: "These third party notices
> vary from license to license. Apache releases should contain a copy of each
> license, usually contained in the LICENSE document." (
> http://apache.org/legal/resolved.html#required-third-party-notices.) But
> maybe this is saying: Apache releases should contain a copy of each (3rd
> party) license, which is usually contained in the *3rd party* LICENSE
> document? (Rather than saying the notice should be in the Apache LICENSE
> document, which is what I thought at first. Can anyone shed light on this?
>
> On Sun, Feb 28, 2016 at 2:54 PM Gale Naylor <Ga...@noventussolutions.com>
> wrote:
>
>> Thank you very much for the details, Andy. I'm doing my best to come up
>> to speed on all this.
>>
>> A question:
>> In looking at the LICENSE files, and the Apache documentation (
>> http://www.apache.org/legal/src-headers.html#notice), I'm wondering
>> about the Taverna Language License, which contains several copyright
>> notices. The documentation I referenced says: "Use the NOTICE file to
>> collect copyright notices and required attributions." Am I misinterpreting
>> this? Should these copyright notices be in the NOTICE file? (Profuse
>> apologies if this was already discussed when I was less up-to-speed.)
>>
>> Gale
>>
>> On Sun, Feb 28, 2016 at 2:19 AM Andy Seaborne <an...@apache.org> wrote:
>>
>>> On 27/02/16 23:33, Stian Soiland-Reyes wrote:
>>> > Use this thread to discuss any issues with RC5 which is currently
>>> > under VOTE. If needed we'll also make Jira issues.
>>> >
>>> > Under the corresponding [VOTE] thread - only reply with your vote,
>>> > e.g. "+1". It is a single vote for releasing all three artifacts at
>>> > once.
>>> >
>>>
>>> Releases are the high point a project.
>>>
>>> PPMC members - feel morally obliged to vote!
>>>
>>> Everyone else - help out - it's not "devs and users" - it's "community".
>>>
>>> Don't forget what really matters when you vote +1 is that the release
>>> meets the Apache requirements and then any additional local community
>>> norms.
>>>
>>> A quick and not complete summary of what a VOTE entails:
>>>
>>> ** Source
>>>
>>> The source artifact is the thing being released.
>>> Binaries and git are secondary.
>>>
>>> People voting must download the source artifact and check it.
>>>
>>> do the signatures on the source archive check out?
>>> does the commit id lead to the same sources?
>>>
>>> ** ASF licensing policy
>>>
>>> Much of this code being is released for the first time so LICENSE and
>>> NOTICE are mostly new.
>>>
>>> does the NOTICE file contain all necessary attributions?
>>> is there a correct LICENSE and NOTICE file in each artifact (both source
>>> and binary artifacts)?
>>>
>>> ** Build
>>>
>>> does the build of the source artifact actually produce the binaries?
>>> check the dependencies.
>>>
>>> ** Process
>>>
>>> Support the release manager!
>>>
>>> The minimum is 3 +1 votes with a majority in favour.
>>> The RM decides about what to do about comments.
>>>
>>> Does the quality level meet the group norms?
>>> ("can we live with it?" and not "is it perfect?")
>>>
>>>
>>> https://www.apache.org/dev/release.html
>>>
>>> Andy
>>>
>>>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Stian Soiland-Reyes <st...@apache.org>.
We interpreted it as it would be sufficient to add (references to) the
other licenses in the existing LICENSE file - and we only add to
NOTICE what requires to be in NOTICE (e.g. it already had a NOTICE
file). We also interpreted copyright statements that are inline in the
source files that they can then remain there and don't need to be
moved to or replicated in NOTICE. So for taverna-language we now
found there was no such third-party licenses left (most of what is at
the end of LICENSE was previously in NOTICE).
This is good because it reduces the NOTICE maintenance load of
down-stream users - but it means muddying the LICENSE which could then
seem like "Apache License and/or/what? something else" rather than
"just the Apache license".
On 28 February 2016 at 23:02, Gale Naylor <Ga...@noventussolutions.com> wrote:
> RE: LICENSES
> Now I've come across this set of statements: "These third party notices
> vary from license to license. Apache releases should contain a copy of each
> license, usually contained in the LICENSE document." (
> http://apache.org/legal/resolved.html#required-third-party-notices.) But
> maybe this is saying: Apache releases should contain a copy of each (3rd
> party) license, which is usually contained in the *3rd party* LICENSE
> document? (Rather than saying the notice should be in the Apache LICENSE
> document, which is what I thought at first. Can anyone shed light on this?
>
> On Sun, Feb 28, 2016 at 2:54 PM Gale Naylor <Ga...@noventussolutions.com>
> wrote:
>
>> Thank you very much for the details, Andy. I'm doing my best to come up to
>> speed on all this.
>>
>> A question:
>> In looking at the LICENSE files, and the Apache documentation (
>> http://www.apache.org/legal/src-headers.html#notice), I'm wondering about
>> the Taverna Language License, which contains several copyright notices. The
>> documentation I referenced says: "Use the NOTICE file to collect copyright
>> notices and required attributions." Am I misinterpreting this? Should these
>> copyright notices be in the NOTICE file? (Profuse apologies if this was
>> already discussed when I was less up-to-speed.)
>>
>> Gale
>>
>> On Sun, Feb 28, 2016 at 2:19 AM Andy Seaborne <an...@apache.org> wrote:
>>
>>> On 27/02/16 23:33, Stian Soiland-Reyes wrote:
>>> > Use this thread to discuss any issues with RC5 which is currently
>>> > under VOTE. If needed we'll also make Jira issues.
>>> >
>>> > Under the corresponding [VOTE] thread - only reply with your vote,
>>> > e.g. "+1". It is a single vote for releasing all three artifacts at
>>> > once.
>>> >
>>>
>>> Releases are the high point a project.
>>>
>>> PPMC members - feel morally obliged to vote!
>>>
>>> Everyone else - help out - it's not "devs and users" - it's "community".
>>>
>>> Don't forget what really matters when you vote +1 is that the release
>>> meets the Apache requirements and then any additional local community
>>> norms.
>>>
>>> A quick and not complete summary of what a VOTE entails:
>>>
>>> ** Source
>>>
>>> The source artifact is the thing being released.
>>> Binaries and git are secondary.
>>>
>>> People voting must download the source artifact and check it.
>>>
>>> do the signatures on the source archive check out?
>>> does the commit id lead to the same sources?
>>>
>>> ** ASF licensing policy
>>>
>>> Much of this code being is released for the first time so LICENSE and
>>> NOTICE are mostly new.
>>>
>>> does the NOTICE file contain all necessary attributions?
>>> is there a correct LICENSE and NOTICE file in each artifact (both source
>>> and binary artifacts)?
>>>
>>> ** Build
>>>
>>> does the build of the source artifact actually produce the binaries?
>>> check the dependencies.
>>>
>>> ** Process
>>>
>>> Support the release manager!
>>>
>>> The minimum is 3 +1 votes with a majority in favour.
>>> The RM decides about what to do about comments.
>>>
>>> Does the quality level meet the group norms?
>>> ("can we live with it?" and not "is it perfect?")
>>>
>>>
>>> https://www.apache.org/dev/release.html
>>>
>>> Andy
>>>
>>>
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Gale Naylor <Ga...@noventussolutions.com>.
RE: LICENSES
Now I've come across this set of statements: "These third party notices
vary from license to license. Apache releases should contain a copy of each
license, usually contained in the LICENSE document." (
http://apache.org/legal/resolved.html#required-third-party-notices.) But
maybe this is saying: Apache releases should contain a copy of each (3rd
party) license, which is usually contained in the *3rd party* LICENSE
document? (Rather than saying the notice should be in the Apache LICENSE
document, which is what I thought at first. Can anyone shed light on this?
On Sun, Feb 28, 2016 at 2:54 PM Gale Naylor <Ga...@noventussolutions.com>
wrote:
> Thank you very much for the details, Andy. I'm doing my best to come up to
> speed on all this.
>
> A question:
> In looking at the LICENSE files, and the Apache documentation (
> http://www.apache.org/legal/src-headers.html#notice), I'm wondering about
> the Taverna Language License, which contains several copyright notices. The
> documentation I referenced says: "Use the NOTICE file to collect copyright
> notices and required attributions." Am I misinterpreting this? Should these
> copyright notices be in the NOTICE file? (Profuse apologies if this was
> already discussed when I was less up-to-speed.)
>
> Gale
>
> On Sun, Feb 28, 2016 at 2:19 AM Andy Seaborne <an...@apache.org> wrote:
>
>> On 27/02/16 23:33, Stian Soiland-Reyes wrote:
>> > Use this thread to discuss any issues with RC5 which is currently
>> > under VOTE. If needed we'll also make Jira issues.
>> >
>> > Under the corresponding [VOTE] thread - only reply with your vote,
>> > e.g. "+1". It is a single vote for releasing all three artifacts at
>> > once.
>> >
>>
>> Releases are the high point a project.
>>
>> PPMC members - feel morally obliged to vote!
>>
>> Everyone else - help out - it's not "devs and users" - it's "community".
>>
>> Don't forget what really matters when you vote +1 is that the release
>> meets the Apache requirements and then any additional local community
>> norms.
>>
>> A quick and not complete summary of what a VOTE entails:
>>
>> ** Source
>>
>> The source artifact is the thing being released.
>> Binaries and git are secondary.
>>
>> People voting must download the source artifact and check it.
>>
>> do the signatures on the source archive check out?
>> does the commit id lead to the same sources?
>>
>> ** ASF licensing policy
>>
>> Much of this code being is released for the first time so LICENSE and
>> NOTICE are mostly new.
>>
>> does the NOTICE file contain all necessary attributions?
>> is there a correct LICENSE and NOTICE file in each artifact (both source
>> and binary artifacts)?
>>
>> ** Build
>>
>> does the build of the source artifact actually produce the binaries?
>> check the dependencies.
>>
>> ** Process
>>
>> Support the release manager!
>>
>> The minimum is 3 +1 votes with a majority in favour.
>> The RM decides about what to do about comments.
>>
>> Does the quality level meet the group norms?
>> ("can we live with it?" and not "is it perfect?")
>>
>>
>> https://www.apache.org/dev/release.html
>>
>> Andy
>>
>>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Gale Naylor <Ga...@noventussolutions.com>.
Thank you very much for the details, Andy. I'm doing my best to come up to
speed on all this.
A question:
In looking at the LICENSE files, and the Apache documentation (
http://www.apache.org/legal/src-headers.html#notice), I'm wondering about
the Taverna Language License, which contains several copyright notices. The
documentation I referenced says: "Use the NOTICE file to collect copyright
notices and required attributions." Am I misinterpreting this? Should these
copyright notices be in the NOTICE file? (Profuse apologies if this was
already discussed when I was less up-to-speed.)
Gale
On Sun, Feb 28, 2016 at 2:19 AM Andy Seaborne <an...@apache.org> wrote:
> On 27/02/16 23:33, Stian Soiland-Reyes wrote:
> > Use this thread to discuss any issues with RC5 which is currently
> > under VOTE. If needed we'll also make Jira issues.
> >
> > Under the corresponding [VOTE] thread - only reply with your vote,
> > e.g. "+1". It is a single vote for releasing all three artifacts at
> > once.
> >
>
> Releases are the high point a project.
>
> PPMC members - feel morally obliged to vote!
>
> Everyone else - help out - it's not "devs and users" - it's "community".
>
> Don't forget what really matters when you vote +1 is that the release
> meets the Apache requirements and then any additional local community
> norms.
>
> A quick and not complete summary of what a VOTE entails:
>
> ** Source
>
> The source artifact is the thing being released.
> Binaries and git are secondary.
>
> People voting must download the source artifact and check it.
>
> do the signatures on the source archive check out?
> does the commit id lead to the same sources?
>
> ** ASF licensing policy
>
> Much of this code being is released for the first time so LICENSE and
> NOTICE are mostly new.
>
> does the NOTICE file contain all necessary attributions?
> is there a correct LICENSE and NOTICE file in each artifact (both source
> and binary artifacts)?
>
> ** Build
>
> does the build of the source artifact actually produce the binaries?
> check the dependencies.
>
> ** Process
>
> Support the release manager!
>
> The minimum is 3 +1 votes with a majority in favour.
> The RM decides about what to do about comments.
>
> Does the quality level meet the group norms?
> ("can we live with it?" and not "is it perfect?")
>
>
> https://www.apache.org/dev/release.html
>
> Andy
>
>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and
taverna-osgi-0.2.1
Posted by Andy Seaborne <an...@apache.org>.
On 27/02/16 23:33, Stian Soiland-Reyes wrote:
> Use this thread to discuss any issues with RC5 which is currently
> under VOTE. If needed we'll also make Jira issues.
>
> Under the corresponding [VOTE] thread - only reply with your vote,
> e.g. "+1". It is a single vote for releasing all three artifacts at
> once.
>
Releases are the high point a project.
PPMC members - feel morally obliged to vote!
Everyone else - help out - it's not "devs and users" - it's "community".
Don't forget what really matters when you vote +1 is that the release
meets the Apache requirements and then any additional local community norms.
A quick and not complete summary of what a VOTE entails:
** Source
The source artifact is the thing being released.
Binaries and git are secondary.
People voting must download the source artifact and check it.
do the signatures on the source archive check out?
does the commit id lead to the same sources?
** ASF licensing policy
Much of this code being is released for the first time so LICENSE and
NOTICE are mostly new.
does the NOTICE file contain all necessary attributions?
is there a correct LICENSE and NOTICE file in each artifact (both source
and binary artifacts)?
** Build
does the build of the source artifact actually produce the binaries?
check the dependencies.
** Process
Support the release manager!
The minimum is 3 +1 votes with a majority in favour.
The RM decides about what to do about comments.
Does the quality level meet the group norms?
("can we live with it?" and not "is it perfect?")
https://www.apache.org/dev/release.html
Andy
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and
taverna-osgi-0.2.1
Posted by Dmitry <re...@list.ru>.
Hello,
apache-taverna-parent RC5 has "2-incubating-SNAPSHOT" version.
on the other hand org.apache.taverna.osgi RC5 depends on "2-incubating"
apache-taverna-parent version.
I get:
The project
org.apache.taverna.osgi:apache-taverna-osgi:0.2.1-incubating
(D:\PROJECTS\APACHE-TAV\incubator-taverna-osgi\pom.xml) has 1 error
Non-resolvable parent POM: Failure to find
org.apache.taverna:apache-taverna-parent:pom:2-incubating in
http://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central
has elapsed or updates are forced and 'parent.relativePath' points at
wrong local POM @ line 21, column 10 -> [Help 2]
:-(
On 2/28/2016 12:56 AM, Stian Soiland-Reyes wrote:
> Thanks! Do you mean the tag 0.15.1-incubating-RC5 (0.15.1-incubating)
> or master (which is 0.15.1-incubating-SNAPSHOT)?
>
> Could you try the RC5 release candidate download? (or verify it
> matches the commit you tested)
>
>
> On 27 February 2016 at 23:47, Dmitry <re...@list.ru> wrote:
>> I was able to compile the fresh taverna-language-0.15.1 from git (with empty
>> local maven repo).
>> Win 7 64x, Java 8u73, Netbeans 8.1.
>>
>> Dmitry
>>
>>
>> On 2/28/2016 12:33 AM, Stian Soiland-Reyes wrote:
>>> Use this thread to discuss any issues with RC5 which is currently
>>> under VOTE. If needed we'll also make Jira issues.
>>>
>>> Under the corresponding [VOTE] thread - only reply with your vote,
>>> e.g. "+1". It is a single vote for releasing all three artifacts at
>>> once.
>>>
>>>
>>>
>>>
>>> Vote thread:
>>> http://apache-taverna-dev.markmail.org/thread/vfwbtfdpie4t24ng
>>>
>>>
>
>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Stian Soiland-Reyes <st...@apache.org>.
Ouch, they are quite long, aren't they..
I'll try to fix it for the general vote email; but it might by truncated by
various email routes as well.
The sha sums are also here in the latest RC5 comment:
https://issues.apache.org/jira/browse/TAVERNA-903
https://issues.apache.org/jira/browse/TAVERNA-904
https://issues.apache.org/jira/browse/TAVERNA-905
(But those are not valid as vote records go as Jira comments can be changed)
Sha512 was an experiment, asked for by Marlon. It is pretty tamperproof but
a bit difficult handling due to its length..
On 28 Feb 2016 00:27, "Gale Naylor" <Ga...@noventussolutions.com> wrote:
> FYI: The sha512sum got cut off for taverna-maven-parent.
>
> On Sat, Feb 27, 2016 at 4:03 PM Dmitry <re...@list.ru> wrote:
>
> > Master.
> >
> > Going to try RC5.
> >
> > Dmitry
> >
> > On 2/28/2016 12:56 AM, Stian Soiland-Reyes wrote:
> > > Thanks! Do you mean the tag 0.15.1-incubating-RC5 (0.15.1-incubating)
> > > or master (which is 0.15.1-incubating-SNAPSHOT)?
> > >
> > > Could you try the RC5 release candidate download? (or verify it
> > > matches the commit you tested)
> > >
> > >
> > > On 27 February 2016 at 23:47, Dmitry <re...@list.ru> wrote:
> > >> I was able to compile the fresh taverna-language-0.15.1 from git (with
> > empty
> > >> local maven repo).
> > >> Win 7 64x, Java 8u73, Netbeans 8.1.
> > >>
> > >> Dmitry
> > >>
> > >>
> > >> On 2/28/2016 12:33 AM, Stian Soiland-Reyes wrote:
> > >>> Use this thread to discuss any issues with RC5 which is currently
> > >>> under VOTE. If needed we'll also make Jira issues.
> > >>>
> > >>> Under the corresponding [VOTE] thread - only reply with your vote,
> > >>> e.g. "+1". It is a single vote for releasing all three artifacts at
> > >>> once.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> Vote thread:
> > >>> http://apache-taverna-dev.markmail.org/thread/vfwbtfdpie4t24ng
> > >>>
> > >>>
> > >
> > >
> >
> >
>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Gale Naylor <Ga...@noventussolutions.com>.
FYI: The sha512sum got cut off for taverna-maven-parent.
On Sat, Feb 27, 2016 at 4:03 PM Dmitry <re...@list.ru> wrote:
> Master.
>
> Going to try RC5.
>
> Dmitry
>
> On 2/28/2016 12:56 AM, Stian Soiland-Reyes wrote:
> > Thanks! Do you mean the tag 0.15.1-incubating-RC5 (0.15.1-incubating)
> > or master (which is 0.15.1-incubating-SNAPSHOT)?
> >
> > Could you try the RC5 release candidate download? (or verify it
> > matches the commit you tested)
> >
> >
> > On 27 February 2016 at 23:47, Dmitry <re...@list.ru> wrote:
> >> I was able to compile the fresh taverna-language-0.15.1 from git (with
> empty
> >> local maven repo).
> >> Win 7 64x, Java 8u73, Netbeans 8.1.
> >>
> >> Dmitry
> >>
> >>
> >> On 2/28/2016 12:33 AM, Stian Soiland-Reyes wrote:
> >>> Use this thread to discuss any issues with RC5 which is currently
> >>> under VOTE. If needed we'll also make Jira issues.
> >>>
> >>> Under the corresponding [VOTE] thread - only reply with your vote,
> >>> e.g. "+1". It is a single vote for releasing all three artifacts at
> >>> once.
> >>>
> >>>
> >>>
> >>>
> >>> Vote thread:
> >>> http://apache-taverna-dev.markmail.org/thread/vfwbtfdpie4t24ng
> >>>
> >>>
> >
> >
>
>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and
taverna-osgi-0.2.1
Posted by Dmitry <re...@list.ru>.
Master.
Going to try RC5.
Dmitry
On 2/28/2016 12:56 AM, Stian Soiland-Reyes wrote:
> Thanks! Do you mean the tag 0.15.1-incubating-RC5 (0.15.1-incubating)
> or master (which is 0.15.1-incubating-SNAPSHOT)?
>
> Could you try the RC5 release candidate download? (or verify it
> matches the commit you tested)
>
>
> On 27 February 2016 at 23:47, Dmitry <re...@list.ru> wrote:
>> I was able to compile the fresh taverna-language-0.15.1 from git (with empty
>> local maven repo).
>> Win 7 64x, Java 8u73, Netbeans 8.1.
>>
>> Dmitry
>>
>>
>> On 2/28/2016 12:33 AM, Stian Soiland-Reyes wrote:
>>> Use this thread to discuss any issues with RC5 which is currently
>>> under VOTE. If needed we'll also make Jira issues.
>>>
>>> Under the corresponding [VOTE] thread - only reply with your vote,
>>> e.g. "+1". It is a single vote for releasing all three artifacts at
>>> once.
>>>
>>>
>>>
>>>
>>> Vote thread:
>>> http://apache-taverna-dev.markmail.org/thread/vfwbtfdpie4t24ng
>>>
>>>
>
>
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and taverna-osgi-0.2.1
Posted by Stian Soiland-Reyes <st...@apache.org>.
Thanks! Do you mean the tag 0.15.1-incubating-RC5 (0.15.1-incubating)
or master (which is 0.15.1-incubating-SNAPSHOT)?
Could you try the RC5 release candidate download? (or verify it
matches the commit you tested)
On 27 February 2016 at 23:47, Dmitry <re...@list.ru> wrote:
> I was able to compile the fresh taverna-language-0.15.1 from git (with empty
> local maven repo).
> Win 7 64x, Java 8u73, Netbeans 8.1.
>
> Dmitry
>
>
> On 2/28/2016 12:33 AM, Stian Soiland-Reyes wrote:
>>
>> Use this thread to discuss any issues with RC5 which is currently
>> under VOTE. If needed we'll also make Jira issues.
>>
>> Under the corresponding [VOTE] thread - only reply with your vote,
>> e.g. "+1". It is a single vote for releasing all three artifacts at
>> once.
>>
>>
>>
>>
>> Vote thread:
>> http://apache-taverna-dev.markmail.org/thread/vfwbtfdpie4t24ng
>>
>>
>
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: [DISCUSS] Release Candidate 5 of taverna-language-0.15.1 and
taverna-osgi-0.2.1
Posted by Dmitry <re...@list.ru>.
I was able to compile the fresh taverna-language-0.15.1 from git (with
empty local maven repo).
Win 7 64x, Java 8u73, Netbeans 8.1.
Dmitry
On 2/28/2016 12:33 AM, Stian Soiland-Reyes wrote:
> Use this thread to discuss any issues with RC5 which is currently
> under VOTE. If needed we'll also make Jira issues.
>
> Under the corresponding [VOTE] thread - only reply with your vote,
> e.g. "+1". It is a single vote for releasing all three artifacts at
> once.
>
>
>
>
> Vote thread:
> http://apache-taverna-dev.markmail.org/thread/vfwbtfdpie4t24ng
>
>