On 6 August 2011 08:40, Henri Yandell <bay...@generationjava.com> wrote: > On Mon, Jul 25, 2011 at 1:14 AM, Rony G. Flatscher > <rony.flatsc...@wu-wien.ac.at> wrote: >> >> On 24.07.2011 19:08, Henri Yandell wrote: >>> On Sun, Jul 24, 2011 at 5:08 AM, Rony G. Flatscher >>> <rony.flatsc...@wu-wien.ac.at> wrote: >>> >>>> On 23.07.2011 20:47, sebb wrote: >>>> >>>>>> * BSF: Slow activity; only coder in last two years is Sebb. >>>>>> >>>>>> A difficult one to decide on. I think we should challenge on it going >>>>>> to the Attic, and if not send it to Commons where it will have more >>>>>> chance of activity. >>>>>> >>>>>> >>>>> Now that JSR-223 is part of Java 1.6 there is less need for BSF. >>>>> There are no bugs oustanding against BSF 3.x. >>>>> Not sure it is worth fixing any of the 2.x bugs. >>>>> >>>>> >>>> Please wait a little bit. It has been a long time intent to fix the few >>>> bugs in 2.x and add the enhancements in JIRA to it. Maybe also creating >>>> a JSR-223 bridge to allow BSF 2.x engines to be used in JSR-223 >>>> environments (not sure whether this is worthwhile, but it may be the >>>> case that there are 2.x engines for which no JSR-223 engines >>>> exist).(Just have not been able to push this more to the front of my >>>> table; have a 2.x engine in use that has the bugfixes incorporated and I >>>> would like to apply them to the official 2.x. >>>> >>> Fair enough request. >>> >>> Still leaves the question of what to do with BSF. Do we: >>> >>> * Leave all of Jakarta open just for BSF. >>> * Move BSF elsewhere. Where? Commons? >>> * Move to the Attic. >>> >>> --- >>> >>> How realistic are we talking on the changes? Your last BSF code commit >>> was in 2007. I know I'm being pushy - but I also know how hard it is >>> to say "Game Over". If we move it to the Attic, it can always move out >>> with the only pain being that you have to do the work locally at >>> first, or fork into a Lab/Commons Sandbox/Incubator project. >>> >> Well, I would like to incorporate the changes in August such that an >> updated (bug-fixed, and the enhancements incorportated) BSF 2.x can then >> be put into the attic. Ideally a POM for it would be great, however I >> can not promise as I have no working knowledge of defining Maven POMs >> (however I can read them ;) ). This way older scripting engines for >> which no JSR-223 bindings exist can still be deployed by Java >> applications. It would be important to make the attic version easily >> findable and downloadable. >> >> --- >> >> Also, I would like to stress the following point, which may be easily >> overseen: BSF 3.x needs to stay alive as it implements the JSR-223 specs > > Is it alive though? > > No user email in 2010. One user email in 2011 having trouble building, > but no answer. > 3.1 released by Sebb in 2010. 3.0 in 2009. Which is good stuff, > especially if there is a plan for a 3.2. > >> (javax.script) that Sun introduced with Java 1.6. BSF 3.x runs on Java >> 1.4 and up and such allows creation and deployment of applications with >> scripts starting from Java 1.4. Not sure whether it got incorporated >> into Harmony, but that would be probably a proper place to live on (it >> is the javax.script implementation Harmony needs to be compatible with >> Java 1.6 in that area as well). > > Looking at activity since the turn of the year, I think it's more > likely that Harmony would be heading to the Attic someday. You never > know though - needs to be given time to see if things recover (someone > started committing a few patches in July). > > I'm in favour of a BSF TLP. Assuming yourself, Anthony Elder and > Sebastian Bazley are still interested and willing to form the new PMC.
Not sure I see the point of creating a new PMC just for BSF. Seems to me it would fit quite well in Commons, if Commons would accept it. > Hen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org > For additional commands, e-mail: general-h...@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@jakarta.apache.org For additional commands, e-mail: general-h...@jakarta.apache.org
