jakarta-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rony G. Flatscher" <Rony.Flatsc...@wu-wien.ac.at>
Subject Re: Ad BSF 2.x (Re: Activity of Jakarta subprojects
Date Sat, 06 Aug 2011 20:58:24 GMT

On 06.08.2011 18:41, sebb wrote:
> On 6 August 2011 08:40, Henri Yandell <bayard@generationjava.com> wrote:
>> On Mon, Jul 25, 2011 at 1:14 AM, Rony G. Flatscher
>> <Rony.Flatscher@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.Flatscher@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
>>>>>>> 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
>>>>> 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.


To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

View raw message