(CC-ing Simone Tripodi, who was the champion of the proposed Beanshell incubator. Simone, we're Apache Taverna, an incubating project for a workflow system. Taverna relies a lot on Beanshell - but as we understood it's official release to be under LGPL we are facing the requirement to keep that functionality as a non-Apache plugin)
Agree that loosing Beanshell by default would be a bit of a challenge - specially for the Taverna Server which won't have an easy "Install Taverna Extras" button. I went through again the archives at https://wiki.apache.org/incubator/BeanShellProposal https://mail-archives.apache.org/mod_mbox/incubator-general/201305.mbox/%3ccajo+ubunm7ahmov_4tvt6j8nojmcmmpddh1xonfw5b00ty6...@mail.gmail.com%3E it seems the Apache Beanshell incubator didn't really get accepted - but supposedly could go directly into Apache Commons anyway? I am unable to find any further trace of it - so apparently nothing happened :( Perhaps Simone has some historical details? Are we able to kickstart this back again? The source at http://svn.codespot.com/a/apache-extras.org/beanshell/ (2.05b5) is however granted under Apache license. https://code.google.com/a/apache-extras.org/p/beanshell/ Perhaps we could use that? Question is - how to get it into JAR-form. It is even "Licensed to the Apache Software Foundation (ASF)" and so should be importable even in source-code form - although that might be better towards Apache Commons BSF than under Apache Taverna - https://commons.apache.org/proper/commons-bsf/ https://code.google.com/p/beanshell2/ is a fork which seems to be more active (but remains LGPL :-( ). Apache OpenOffice seems to also have Beanshell support (using 2.0b1) - but they only includes it if the build has "ENABLE_CATEGORY_B==YES". They even copied the source here under the svn branch: http://svn.apache.org/repos/asf/!svn/bc/1336449/incubator/ooo/trunk/ext_sources/ea570af93c284aa9e5621cd563f54f4d-bsh-2.0b1-src.tar.gz Actually now I see that the Beanshell 2.0b4 (which we use) is dual-licensed and also available as "Sun Public License" - which could somewhat be OK under Apache: http://beanshell.org/license.html https://www.apache.org/legal/resolved.html#category-b So.. given this - what should we do? It seems we don't need to move Beanshell ACtivity out of Apache Taverna after all. (yay!) On 8 January 2015 at 11:27, Donal K. Fellows <donal.k.fell...@manchester.ac.uk> wrote: > On 06/01/2015 08:37, Stian Soiland-Reyes wrote: >> >> I can however see that there is a danger that the >> some-repositories/some-releases approach can also lead to "Need to >> release A so I can release B so I can release C" problem when you are >> propagating changes downstream, and then there's the danger of the >> proposed repositories being wrong (we won't know that before doing >> several releases). Other Taverna developers with experience of the 2.x >> releases might want to have a say on this. > > > I think you've about covered everything. One point of interest is that > we've maintained Taverna Server in the separate repository model for a > few years now, and that seemed to work fairly well. What I'd do for the > cases where we had a feature of the server that depended on a specific > change elsewhere (such as a change in how some command line option was > processed) was to do a feature branch for that specific thing, so that > we could avoid breaking things elsewhere until that feature hit an > identifiable version (even if a SNAPSHOT one) and could do the merge then. > > The (equivalent to) master branch was kept in a state where it would be > buildable, testable and near releasable at any time. (Doing a release > was a matter of adjusting version numbers for various things and setting > a tag, which is pretty lightweight.) This, which was possible because > the server was only loosely coupled to the engine, made most development > easy. (The odd times when releases happened which Stian disapproved of > ;-) were when there was a project in desperate need of a fix and the > time to the next engine release was huge.) > > I should note that the Beanshell activity stuff being LGPL causing > problems is a particular problem, as removing it is extremely disruptive > to existing users. To be clear, it pushes the chance of having an > existing workflow that will function with the new system to about 0%; > virtually all Taverna workflows out there in the wild use Beanshells. > The chance of getting all that wild code ported to something else is > also pretty small. (Unless someone's got a nicely-licensed library for > transforming Beanshell code into some other language. :-D) > > Donal. -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
