You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Jim Hurley <Ji...@Sun.COM> on 2007/08/22 07:31:42 UTC
a potential "AR1" release
If we do pursue a first short term incubator release (just
temporarily labeling it "AR1" for now), here's a few of the
things (questions, tasks) we'll need to tackle.
Please add to/comment on/correct.
thanks -Jim
------------------------------------------------------------------------
-----
Apache Incubator River Project - "AR1" Release
* Goal: release from River project, integrating the starter kit
and serviceui contributions
* Name, Version, release bundle, top-level installation directory: ?
* Should we go with the current starter kit release bundle structure?
* Bundle starterkit and serviceui in the release bundle?
(assuming yes) How should serviceui fit in?
* Should API docs (specs) and docs be available separately?
* Documentation (install, release, build, api) will need to be updated
(minimally for name, version updates)
* What kind of testing do we need?
* What kind of development process do we need? JIRA issues for
all changes? code reviews?
* Some (build) issues around outrigger sources to work
* Update:
River project area
<http://incubator.apache.org/river/>
River Incubator Project Status page
<http://incubator.apache.org/projects/river.html>
* Apache incubator release process (export, PPMC approval,
general approval, etc)
------------------------------------------------------------------------
-----
Re: a potential "AR1" release
Posted by Nigel Daley <nd...@mac.com>.
+1 on the plan.
On Aug 24, 2007, at 9:39 AM, Iain Shigeoka wrote:
> +1 on the plan.
>
> IMO the lack of response is due to the lack of a release... :)
>
> I don't think we'll see a lot of activity from the community until
> the project starts regular, visible code pushes and releases.
>
> -iain
>
> On Aug 23, 2007, at 1:16 PM, Jim Hurley wrote:
>
>> Thanks Bob.
>>
>> I was just pausing to see if people would voice opinions
>> (+1's (thanks Sam), 0s, or -1s with alternative directions
>> related to the "shifting up a gear..." mail). I'd really
>> appreciate some response (the silence is deafening)
>> to know if there's support, apathy, or disagreement.
>>
>> If we're good with the AR1 path -- I'd like to start discussing
>> the items and/or have someone take the lead on proposing
>> answers/solutions to them. Ready to start the discussion on
>> them immediately.
>>
>> In the meantime, I've started working on some updates
>> to the incubator.apache.org/river project page (not visible
>> yet).
>>
>> -Jim
>>
>>
>> On Aug 23, 2007, at 2:49 PM, Bob Scheifler wrote:
>>> Jim Hurley wrote:
>>>> If we do pursue a first short term incubator release (just
>>>> temporarily labeling it "AR1" for now), here's a few of the
>>>> things (questions, tasks) we'll need to tackle.
>>>
>>> A good start list. How do you want to go about answering the
>>> questions?
>>>
>>> - Bob
>>
>
Re: a potential "AR1" release
Posted by Sean Landis <se...@gmail.com>.
+1
On 8/24/07, Iain Shigeoka <ia...@messaginglogic.com> wrote:
> +1 on the plan.
>
> IMO the lack of response is due to the lack of a release... :)
>
> I don't think we'll see a lot of activity from the community until
> the project starts regular, visible code pushes and releases.
>
> -iain
>
> On Aug 23, 2007, at 1:16 PM, Jim Hurley wrote:
>
> > Thanks Bob.
> >
> > I was just pausing to see if people would voice opinions
> > (+1's (thanks Sam), 0s, or -1s with alternative directions
> > related to the "shifting up a gear..." mail). I'd really
> > appreciate some response (the silence is deafening)
> > to know if there's support, apathy, or disagreement.
> >
> > If we're good with the AR1 path -- I'd like to start discussing
> > the items and/or have someone take the lead on proposing
> > answers/solutions to them. Ready to start the discussion on
> > them immediately.
> >
> > In the meantime, I've started working on some updates
> > to the incubator.apache.org/river project page (not visible
> > yet).
> >
> > -Jim
> >
> >
> > On Aug 23, 2007, at 2:49 PM, Bob Scheifler wrote:
> >> Jim Hurley wrote:
> >>> If we do pursue a first short term incubator release (just
> >>> temporarily labeling it "AR1" for now), here's a few of the
> >>> things (questions, tasks) we'll need to tackle.
> >>
> >> A good start list. How do you want to go about answering the
> >> questions?
> >>
> >> - Bob
> >
>
>
>
Re: a potential "AR1" release
Posted by Iain Shigeoka <ia...@messaginglogic.com>.
+1 on the plan.
IMO the lack of response is due to the lack of a release... :)
I don't think we'll see a lot of activity from the community until
the project starts regular, visible code pushes and releases.
-iain
On Aug 23, 2007, at 1:16 PM, Jim Hurley wrote:
> Thanks Bob.
>
> I was just pausing to see if people would voice opinions
> (+1's (thanks Sam), 0s, or -1s with alternative directions
> related to the "shifting up a gear..." mail). I'd really
> appreciate some response (the silence is deafening)
> to know if there's support, apathy, or disagreement.
>
> If we're good with the AR1 path -- I'd like to start discussing
> the items and/or have someone take the lead on proposing
> answers/solutions to them. Ready to start the discussion on
> them immediately.
>
> In the meantime, I've started working on some updates
> to the incubator.apache.org/river project page (not visible
> yet).
>
> -Jim
>
>
> On Aug 23, 2007, at 2:49 PM, Bob Scheifler wrote:
>> Jim Hurley wrote:
>>> If we do pursue a first short term incubator release (just
>>> temporarily labeling it "AR1" for now), here's a few of the
>>> things (questions, tasks) we'll need to tackle.
>>
>> A good start list. How do you want to go about answering the
>> questions?
>>
>> - Bob
>
Re: a potential "AR1" release
Posted by Jim Hurley <Ji...@Sun.COM>.
Thanks Bob.
I was just pausing to see if people would voice opinions
(+1's (thanks Sam), 0s, or -1s with alternative directions
related to the "shifting up a gear..." mail). I'd really
appreciate some response (the silence is deafening)
to know if there's support, apathy, or disagreement.
If we're good with the AR1 path -- I'd like to start discussing
the items and/or have someone take the lead on proposing
answers/solutions to them. Ready to start the discussion on
them immediately.
In the meantime, I've started working on some updates
to the incubator.apache.org/river project page (not visible
yet).
-Jim
On Aug 23, 2007, at 2:49 PM, Bob Scheifler wrote:
> Jim Hurley wrote:
>> If we do pursue a first short term incubator release (just
>> temporarily labeling it "AR1" for now), here's a few of the
>> things (questions, tasks) we'll need to tackle.
>
> A good start list. How do you want to go about answering the
> questions?
>
> - Bob
Re: a potential "AR1" release
Posted by Bob Scheifler <Bo...@Sun.COM>.
Jim Hurley wrote:
> If we do pursue a first short term incubator release (just
> temporarily labeling it "AR1" for now), here's a few of the
> things (questions, tasks) we'll need to tackle.
A good start list. How do you want to go about answering the questions?
- Bob
Re: a potential "AR1" release
Posted by Sam Chance <sg...@gmail.com>.
A non-technical input from an enthusiastic supporter/observer: Jini (er
River) is hard enough to learn; please do all you can to *not* break
existing apps or other implementations relying on it.
I'm seeing increasing traction for Jini and I want to maintain and grow it.
Thank you, and sorry to interrupt. :-)
Sam
On 8/30/07, Bob Scheifler <Bo...@sun.com> wrote:
>
> Gregg Wonderly wrote:
> > Perhaps in view that jar layouts may change further, there might be an
> > official directory of deprecated jars so that documentation and
> > discussions can focus on the nature of those jars?
>
> Moving the existing deprecated jars (jini-core.jar, jini-ext.jar,
> sdm-dl.jar, sun-util.jar) could break existing scripts/etc that
> reference them, so if the desire is for AR1 to maintain maximum
> compatibility, it would seem preferable to leave them where they are.
>
> - Bob
>
Re: a potential "AR1" release
Posted by Craig L Russell <Cr...@Sun.COM>.
On Sep 5, 2007, at 7:48 PM, John Sarman wrote:
>> Dan Creswell wrote:
>>> John Sarman wrote:
>>>
>>> I know that most would like to see River have a release, but has
>>> anybody
>>> discussed making the minimum required JRE 1.5.
>>> Jini alway craved the need for templates and Generics and the
>>> move to
> River
>>> would allow for just that.
>>>
>
>> That's been discussed over on Jini-Users a few times don't think
>> there's
>> an agreed view (be worth checking through the archives). I also
>> think
>> this is probably to big of an issue to be considering for AR1
>> (which to
>> a reasonable degree is about us committers figuring out how to
>> drive).
>
> A requirement of River to use a minimum JRE of 1.5 could be applied
> to AR1
> because Java is upwards compatible.
> AR1 could be compatible with 1.4 (based off jini2_1). However, by
> requiring
> 1.5, committers could generify some classes in the core
> architecture for
> type safety additions to River in later releases.
>
> I am asking for the community to choose a minimum version of Java
> greater
> than 1.4.x to sail up the River .
>
>> Might also be worth organizing some kind of canvas to find out
>> what JDK
>> is in production around commercial Jini-user land.......
>
> I personally would like to see 1.6 as the minimum (GPL'ed Java) .
IIUC (someone with better information please correct me) the GPL
version of Java, available as OpenJDK, is Java 7 not Java 6.
Craig
>
> --
> John
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: a potential "AR1" release
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi John, Dan,
John Sarman wrote:
>> Dan Creswell wrote:
>
>> That's been discussed over on Jini-Users a few times don't think there's
>> an agreed view (be worth checking through the archives). I also think
When you check the jini-user and even river-dev mailing list you won't
find an agreed view. And I guess that is rather logical given the fact
the answer is very much subject to the abundance of a particular JVM
level people experience in their own controlled environment and/or
installed base at customer site for those who embed Jini in their products.
>> this is probably to big of an issue to be considering for AR1 (which to
>> a reasonable degree is about us committers figuring out how to drive).
>
> A requirement of River to use a minimum JRE of 1.5 could be applied to AR1
> because Java is upwards compatible.
AR1 is meant to be compatible, although that might mean a lot of
different things for different people I don't believe that changing the
minimum J2SE Platform is one of them.
> AR1 could be compatible with 1.4 (based off jini2_1). However, by requiring
> 1.5, committers could generify some classes in the core architecture for
> type safety additions to River in later releases.
>
> I am asking for the community to choose a minimum version of Java greater
> than 1.4.x to sail up the River.
>
>> Might also be worth organizing some kind of canvas to find out what JDK
>> is in production around commercial Jini-user land.......
While interesting I doubt it is really that essential. I bet there are
working Jini 1.x systems on JDK 1.2.2 and some people/companies might
even have contractual obligations to support that and still Jini 2.x has
as a minimum J2SE 1.4.
I think it is more relevant to find out whether the penetration of J2SE
5.0 is high enough to warrant a move to that level. I've been against a
move to 5.0 in the past due to the fact a lot of Jini clients were
(mostly WebSphere) application servers that came with 1.4.2. Lately I
see a strong move that these are upgraded which for *me* allows 5.0 as
the minimum Platform given the time frame I expect for releases for River.
Therefore I'm comfortable with moving to 5.0 for releases after AR1 (and
after patches lingering around have been integrated) although I have no
opinion yet about taking 'advantage' of some of the language features in
5.0. But if we do I expect them to be binary compatible at least.
> I personally would like to see 1.6 as the minimum (GPL'ed Java) .
To me a bridge too far :-) I also don't understand what is that relevant
for Jini to warrant that level as the minimum, I can understand why
people deploy on Java SE 6 though.
--
Mark
Re: a potential "AR1" release
Posted by John Sarman <jo...@gmail.com>.
>Dan Creswell wrote:
>>John Sarman wrote:
>>
>> I know that most would like to see River have a release, but has anybody
>> discussed making the minimum required JRE 1.5.
>> Jini alway craved the need for templates and Generics and the move to
River
>> would allow for just that.
>>
>That's been discussed over on Jini-Users a few times don't think there's
>an agreed view (be worth checking through the archives). I also think
>this is probably to big of an issue to be considering for AR1 (which to
>a reasonable degree is about us committers figuring out how to drive).
A requirement of River to use a minimum JRE of 1.5 could be applied to AR1
because Java is upwards compatible.
AR1 could be compatible with 1.4 (based off jini2_1). However, by requiring
1.5, committers could generify some classes in the core architecture for
type safety additions to River in later releases.
I am asking for the community to choose a minimum version of Java greater
than 1.4.x to sail up the River .
>Might also be worth organizing some kind of canvas to find out what JDK
>is in production around commercial Jini-user land.......
I personally would like to see 1.6 as the minimum (GPL'ed Java) .
--
John
> Just Curious about this,
>
> Curiosity is good (on the flip side, it's been known to kill the odd cat
> :)
>
> Cheers,
>
> Dan.
>
> > John Sarman
> >
> > On 9/5/07, Sean Landis <se...@gmail.com> wrote:
> >> Ok, this may be heretic to some...Given a choice, I'd much rather
> >> prefer progress over backward compatibility.
> >>
> >> Sean
> >>
> >> On 9/4/07, Jim Hurley <Ji...@sun.com> wrote:
> >>> On Sep 4, 2007, at 3:47 AM, Dan Creswell wrote:
> >>>> Gregg Wonderly wrote:
> >>>>> Bob Scheifler wrote:
> >>>>>> Gregg Wonderly wrote:
> >>>>>>
> >>>>>>> Perhaps in view that jar layouts may change further, there might
> be
> >>>>>>> an official directory of deprecated jars so that documentation and
> >>>>>>> discussions can focus on the nature of those jars?
> >>>>>> Moving the existing deprecated jars (jini-core.jar, jini-ext.jar,
> >>>>>> sdm-dl.jar, sun-util.jar) could break existing scripts/etc that
> >>>>>> reference them, so if the desire is for AR1 to maintain maximum
> >>>>>> compatibility, it would seem preferable to leave them where they
> >>>>>> are.
> >>>>> Your call, but my thoughts are that there will already be some
> >>>>> changes
> >>>>> involved in testing and integrating AR1, for many. So, having to
> >>>>> change
> >>>>> some referred to directory structures, etc, may not be a big impact
> >>>>> overall.
> >>>> What do the rest of the user-base think about this? ^^^
> >>>>
> >>>> How much backward compatibility does everybody expect in this first
> >>>> release?
> >>>>
> >>>> Anybody out there?
> >>> Hey Dan-
> >>>
> >>> My guess is that we haven't made enough substantive progress in this
> >>> (River) project yet to attract Jini users to these mailing lists. We
> >>> certainly
> >>> have some (who seem to be generally lurking), but it will not be
> >>> (IMHO) until
> >>> we get out a release or two before 'users' will start to be very
> >>> vocal on this
> >>> list.
> >>>
> >>> It might be better to ask this at jini/javaspaces-users right now.
> >>>
> >>> My 2c.
> >>>
> >>> -Jim
> >>>
> >
>
>
Re: a potential "AR1" release
Posted by Gregg Wonderly <gr...@wonderly.org>.
Dan Creswell wrote:
> John Sarman wrote:
>
>>I know that most would like to see River have a release, but has anybody
>>discussed making the minimum required JRE 1.5.
>>Jini alway craved the need for templates and Generics and the move to River
>>would allow for just that.
>
> That's been discussed over on Jini-Users a few times don't think there's
> an agreed view (be worth checking through the archives). I also think
> this is probably to big of an issue to be considering for AR1 (which to
> a reasonable degree is about us committers figuring out how to drive).
>
> Might also be worth organizing some kind of canvas to find out what JDK
> is in production around commercial Jini-user land.......
We are definately committed to JDK1.6 at this point due to several features
there. So even JDK1.5 as a base is okay with me. I think that given the
limited remaining life of JDK1.4 vs the time frame of a first "River" release,
that stipulating JDK1.5 as a base, regardless of whether generics are used or
some other JDK1.5 feature would be a safety net worth casting to aid all of us
in being able to more fully utilize some of the language features, such as
generics, which some consider to help in the use of the Jini toolkit, rather
than enhance it in some performance or stability way.
Gregg Wonderly
Re: a potential "AR1" release
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
John Sarman wrote:
> I know that most would like to see River have a release, but has anybody
> discussed making the minimum required JRE 1.5.
> Jini alway craved the need for templates and Generics and the move to River
> would allow for just that.
>
That's been discussed over on Jini-Users a few times don't think there's
an agreed view (be worth checking through the archives). I also think
this is probably to big of an issue to be considering for AR1 (which to
a reasonable degree is about us committers figuring out how to drive).
Might also be worth organizing some kind of canvas to find out what JDK
is in production around commercial Jini-user land.......
> Just Curious about this,
Curiosity is good (on the flip side, it's been known to kill the odd cat :)
Cheers,
Dan.
> John Sarman
>
> On 9/5/07, Sean Landis <se...@gmail.com> wrote:
>> Ok, this may be heretic to some...Given a choice, I'd much rather
>> prefer progress over backward compatibility.
>>
>> Sean
>>
>> On 9/4/07, Jim Hurley <Ji...@sun.com> wrote:
>>> On Sep 4, 2007, at 3:47 AM, Dan Creswell wrote:
>>>> Gregg Wonderly wrote:
>>>>> Bob Scheifler wrote:
>>>>>> Gregg Wonderly wrote:
>>>>>>
>>>>>>> Perhaps in view that jar layouts may change further, there might be
>>>>>>> an official directory of deprecated jars so that documentation and
>>>>>>> discussions can focus on the nature of those jars?
>>>>>> Moving the existing deprecated jars (jini-core.jar, jini-ext.jar,
>>>>>> sdm-dl.jar, sun-util.jar) could break existing scripts/etc that
>>>>>> reference them, so if the desire is for AR1 to maintain maximum
>>>>>> compatibility, it would seem preferable to leave them where they
>>>>>> are.
>>>>> Your call, but my thoughts are that there will already be some
>>>>> changes
>>>>> involved in testing and integrating AR1, for many. So, having to
>>>>> change
>>>>> some referred to directory structures, etc, may not be a big impact
>>>>> overall.
>>>> What do the rest of the user-base think about this? ^^^
>>>>
>>>> How much backward compatibility does everybody expect in this first
>>>> release?
>>>>
>>>> Anybody out there?
>>> Hey Dan-
>>>
>>> My guess is that we haven't made enough substantive progress in this
>>> (River) project yet to attract Jini users to these mailing lists. We
>>> certainly
>>> have some (who seem to be generally lurking), but it will not be
>>> (IMHO) until
>>> we get out a release or two before 'users' will start to be very
>>> vocal on this
>>> list.
>>>
>>> It might be better to ask this at jini/javaspaces-users right now.
>>>
>>> My 2c.
>>>
>>> -Jim
>>>
>
Re: a potential "AR1" release
Posted by John Sarman <jo...@gmail.com>.
I know that most would like to see River have a release, but has anybody
discussed making the minimum required JRE 1.5.
Jini alway craved the need for templates and Generics and the move to River
would allow for just that.
Just Curious about this,
John Sarman
On 9/5/07, Sean Landis <se...@gmail.com> wrote:
>
> Ok, this may be heretic to some...Given a choice, I'd much rather
> prefer progress over backward compatibility.
>
> Sean
>
> On 9/4/07, Jim Hurley <Ji...@sun.com> wrote:
> > On Sep 4, 2007, at 3:47 AM, Dan Creswell wrote:
> > > Gregg Wonderly wrote:
> > >> Bob Scheifler wrote:
> > >>> Gregg Wonderly wrote:
> > >>>
> > >>>> Perhaps in view that jar layouts may change further, there might be
> > >>>> an official directory of deprecated jars so that documentation and
> > >>>> discussions can focus on the nature of those jars?
> > >>>
> > >>> Moving the existing deprecated jars (jini-core.jar, jini-ext.jar,
> > >>> sdm-dl.jar, sun-util.jar) could break existing scripts/etc that
> > >>> reference them, so if the desire is for AR1 to maintain maximum
> > >>> compatibility, it would seem preferable to leave them where they
> > >>> are.
> > >>
> > >> Your call, but my thoughts are that there will already be some
> > >> changes
> > >> involved in testing and integrating AR1, for many. So, having to
> > >> change
> > >> some referred to directory structures, etc, may not be a big impact
> > >> overall.
> > >
> > > What do the rest of the user-base think about this? ^^^
> > >
> > > How much backward compatibility does everybody expect in this first
> > > release?
> > >
> > > Anybody out there?
> >
> > Hey Dan-
> >
> > My guess is that we haven't made enough substantive progress in this
> > (River) project yet to attract Jini users to these mailing lists. We
> > certainly
> > have some (who seem to be generally lurking), but it will not be
> > (IMHO) until
> > we get out a release or two before 'users' will start to be very
> > vocal on this
> > list.
> >
> > It might be better to ask this at jini/javaspaces-users right now.
> >
> > My 2c.
> >
> > -Jim
> >
>
Re: a potential "AR1" release
Posted by Sean Landis <se...@gmail.com>.
Ok, this may be heretic to some...Given a choice, I'd much rather
prefer progress over backward compatibility.
Sean
On 9/4/07, Jim Hurley <Ji...@sun.com> wrote:
> On Sep 4, 2007, at 3:47 AM, Dan Creswell wrote:
> > Gregg Wonderly wrote:
> >> Bob Scheifler wrote:
> >>> Gregg Wonderly wrote:
> >>>
> >>>> Perhaps in view that jar layouts may change further, there might be
> >>>> an official directory of deprecated jars so that documentation and
> >>>> discussions can focus on the nature of those jars?
> >>>
> >>> Moving the existing deprecated jars (jini-core.jar, jini-ext.jar,
> >>> sdm-dl.jar, sun-util.jar) could break existing scripts/etc that
> >>> reference them, so if the desire is for AR1 to maintain maximum
> >>> compatibility, it would seem preferable to leave them where they
> >>> are.
> >>
> >> Your call, but my thoughts are that there will already be some
> >> changes
> >> involved in testing and integrating AR1, for many. So, having to
> >> change
> >> some referred to directory structures, etc, may not be a big impact
> >> overall.
> >
> > What do the rest of the user-base think about this? ^^^
> >
> > How much backward compatibility does everybody expect in this first
> > release?
> >
> > Anybody out there?
>
> Hey Dan-
>
> My guess is that we haven't made enough substantive progress in this
> (River) project yet to attract Jini users to these mailing lists. We
> certainly
> have some (who seem to be generally lurking), but it will not be
> (IMHO) until
> we get out a release or two before 'users' will start to be very
> vocal on this
> list.
>
> It might be better to ask this at jini/javaspaces-users right now.
>
> My 2c.
>
> -Jim
>
Re: a potential "AR1" release
Posted by Jim Hurley <Ji...@Sun.COM>.
On Sep 4, 2007, at 3:47 AM, Dan Creswell wrote:
> Gregg Wonderly wrote:
>> Bob Scheifler wrote:
>>> Gregg Wonderly wrote:
>>>
>>>> Perhaps in view that jar layouts may change further, there might be
>>>> an official directory of deprecated jars so that documentation and
>>>> discussions can focus on the nature of those jars?
>>>
>>> Moving the existing deprecated jars (jini-core.jar, jini-ext.jar,
>>> sdm-dl.jar, sun-util.jar) could break existing scripts/etc that
>>> reference them, so if the desire is for AR1 to maintain maximum
>>> compatibility, it would seem preferable to leave them where they
>>> are.
>>
>> Your call, but my thoughts are that there will already be some
>> changes
>> involved in testing and integrating AR1, for many. So, having to
>> change
>> some referred to directory structures, etc, may not be a big impact
>> overall.
>
> What do the rest of the user-base think about this? ^^^
>
> How much backward compatibility does everybody expect in this first
> release?
>
> Anybody out there?
Hey Dan-
My guess is that we haven't made enough substantive progress in this
(River) project yet to attract Jini users to these mailing lists. We
certainly
have some (who seem to be generally lurking), but it will not be
(IMHO) until
we get out a release or two before 'users' will start to be very
vocal on this
list.
It might be better to ask this at jini/javaspaces-users right now.
My 2c.
-Jim
Re: a potential "AR1" release
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Gregg Wonderly wrote:
> Bob Scheifler wrote:
>> Gregg Wonderly wrote:
>>
>>> Perhaps in view that jar layouts may change further, there might be
>>> an official directory of deprecated jars so that documentation and
>>> discussions can focus on the nature of those jars?
>>
>> Moving the existing deprecated jars (jini-core.jar, jini-ext.jar,
>> sdm-dl.jar, sun-util.jar) could break existing scripts/etc that
>> reference them, so if the desire is for AR1 to maintain maximum
>> compatibility, it would seem preferable to leave them where they are.
>
> Your call, but my thoughts are that there will already be some changes
> involved in testing and integrating AR1, for many. So, having to change
> some referred to directory structures, etc, may not be a big impact
> overall.
>
What do the rest of the user-base think about this? ^^^
How much backward compatibility does everybody expect in this first release?
Anybody out there?
> I still use jini-core, jini-ext and sun-util myself. I copy these files
Can you explain more about why you use these?
> out of the distribution into a secondary, versioned structure (because I
> have made many edits on my copy of the 2.1 source tree). The source of
> those jars is abstracted by this fact.
>
> Gregg Wonderly
>
Dan.
Re: a potential "AR1" release
Posted by Gregg Wonderly <ge...@cox.net>.
Bob Scheifler wrote:
> Gregg Wonderly wrote:
>
>> Perhaps in view that jar layouts may change further, there might be an
>> official directory of deprecated jars so that documentation and
>> discussions can focus on the nature of those jars?
>
> Moving the existing deprecated jars (jini-core.jar, jini-ext.jar,
> sdm-dl.jar, sun-util.jar) could break existing scripts/etc that
> reference them, so if the desire is for AR1 to maintain maximum
> compatibility, it would seem preferable to leave them where they are.
Your call, but my thoughts are that there will already be some changes involved
in testing and integrating AR1, for many. So, having to change some referred to
directory structures, etc, may not be a big impact overall.
I still use jini-core, jini-ext and sun-util myself. I copy these files out of
the distribution into a secondary, versioned structure (because I have made many
edits on my copy of the 2.1 source tree). The source of those jars is
abstracted by this fact.
Gregg Wonderly
Re: a potential "AR1" release
Posted by Bob Scheifler <Bo...@Sun.COM>.
Gregg Wonderly wrote:
> Perhaps in view that jar layouts may change further, there might be an
> official directory of deprecated jars so that documentation and
> discussions can focus on the nature of those jars?
Moving the existing deprecated jars (jini-core.jar, jini-ext.jar,
sdm-dl.jar, sun-util.jar) could break existing scripts/etc that
reference them, so if the desire is for AR1 to maintain maximum
compatibility, it would seem preferable to leave them where they are.
- Bob
Re: a potential "AR1" release
Posted by Gregg Wonderly <ge...@cox.net>.
Bob Scheifler wrote:
> Dan Creswell wrote:
>
>> I'd like to see us provide a little transition period here.....
>>
>> Say in the first release keep a serviceui.jar around (marked as "going
>> away") and maybe remove it in the next release or the one after
>> (assuming we follow Jim's basic plan).
Perhaps in view that jar layouts may change further, there might be an official
directory of deprecated jars so that documentation and discussions can focus on
the nature of those jars?
Gregg Wonderly
Re: a potential "AR1" release
Posted by Bob Scheifler <Bo...@Sun.COM>.
Dan Creswell wrote:
> I'd like to see us provide a little transition period here.....
>
> Say in the first release keep a serviceui.jar around (marked as "going
> away") and maybe remove it in the next release or the one after
> (assuming we follow Jim's basic plan).
OK.
- Bob
Re: a potential "AR1" release
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Bob Scheifler wrote:
> Jim Hurley wrote:
>> let's say that we bundle together
>> serviceui and starter kit into the same release bundle and
>> we go with the current starter kit structure.
>
> Sure, move the ServiceUI classes directly into the starter kit tree,
> include them in both jsk-lib.jar and jsk-dl.jar, and eliminate
> serviceui.jar as an artifact.
>
I'd like to see us provide a little transition period here.....
Say in the first release keep a serviceui.jar around (marked as "going
away") and maybe remove it in the next release or the one after
(assuming we follow Jim's basic plan).
> - Bob
>
>
Two cents,
Dan.
Re: a potential "AR1" release
Posted by Bob Scheifler <Bo...@Sun.COM>.
Jim Hurley wrote:
> let's say that we bundle together
> serviceui and starter kit into the same release bundle and
> we go with the current starter kit structure.
Sure, move the ServiceUI classes directly into the starter kit tree,
include them in both jsk-lib.jar and jsk-dl.jar, and eliminate
serviceui.jar as an artifact.
- Bob
Re: a potential "AR1" release
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
John McClain - Sun Microsystems, Inc. wrote:
> Jim Hurley wrote:
>> On Aug 28, 2007, at 3:43 PM, Frank Barnaby wrote:
>>> I've done a test build with the serviceui sources moved into the jtsk
>>> source tree (namespaces unchanged) and have found no obvious problems.
>>
>> Thanks Frank.
>>
>>> One other question comes to mind... How should we handle the logstore
>>> portion of the outrigger build? Should we leave it as is, disable it
>>> in the build, or remove the sources completely? If we leave it as is,
>>> we would need to consider including the prebuilt-outrigger-logstore.jar
>>> in the source distribution, as Phil suggested, to allow builds without
>>> the need for a Jini installation. Disabling the logstore jar'ing
>>> target, on the other hand, removes the dependency on the Jini binary
>>> installation but leaves the logstore sources in a unaltered state.
>>> In all cases, logstore cannot be used without pro.zip (the PSEpro
>>> runtime library), but persistence is still attainable through the use
>>> of the snaplogstore implementation.
>>
>> I'd lean towards what's expedient to get out "AR1" in short order -- but
>> I do think we're going to have to bite the bullet and probably remove
>> logstore from the build going forward. It doesn't seem to have long
>> term viability.
>
> My vote is to remove logstore altogether and do it for AR1.
>
+1
Re: a potential "AR1" release
Posted by Mark Brouwer <ma...@cheiron.org>.
Mark Brouwer wrote:
> the principals contained in the ALv2 or what is written as the guiding
> principles here: http://people.apache.org/~rubys/3party.html.
Reading further it is even explicitly mentioned the Sleepycat license is
not allowed for inclusion in an ASF product, see
http://people.apache.org/~rubys/3party.html#category-x
--
Mark
Re: a potential "AR1" release
Posted by "John McClain - Sun Microsystems, Inc." <Jo...@Sun.COM>.
Mark Brouwer wrote:
> I see no problem though in e.g. providing the interface to Berkeley DB
> in the same way as it was/is done for PSE but I would be against
> shipping Berkely DB (assuming it was/is possible), but there are also
> other decent performing routes possible based on compatible licenses.
and
> Mark Brouwer wrote:
>
>> the principals contained in the ALv2 or what is written as the guiding
>> principles here: http://people.apache.org/~rubys/3party.html.
>
> Reading further it is even explicitly mentioned the Sleepycat license is
> not allowed for inclusion in an ASF product, see
> http://people.apache.org/~rubys/3party.html#category-x
Thanks for the leg work, I guess Sleepycat isn't an option.
FWIW, left to my own judgment I would make the performance improvements
to snapstore first (http://issues.apache.org/jira/browse/RIVER-128 and
http://issues.apache.org/jira/browse/RIVER-171, they are against
logstore, but apply to snapstore too). This would give us a performance
base line that we could measure new store designs against.
The easiest way to address RIVER-128 is to break the log format, given
that changing all the package names is also going to break the log
format doing RIVER-128 before the first real release has some appeal.
--
John McClain john.mcclain@sun.com
Sun Microsystems, Inc.
Burlington, MA
And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.
- David Brooks
Re: a potential "AR1" release
Posted by Mark Brouwer <ma...@cheiron.org>.
John McClain - Sun Microsystems, Inc. wrote:
> Berkeley DB Java Edition : seems to be a good fit with what
> Outrigger needs, not sure about licensing, it is available
> under an "OSI-certified" open source license but I don't
> know which license it is and if there are any license
> compatibility issues with Apache.
The license is here
http://www.oracle.com/technology/software/products/berkeley-db/htdocs/jeoslicense.html
and while the license itself qualifies as OSI I don't really think it is
compatible due to its viral term 3. Although inclusion of the Berkeley
DB Java Edition libraries in SVN seems to be no problems as the ASF
itself complies to the terms. Downstream users are however severely
impacted by the (viral) license term 3 and this seems to conflict with
the principals contained in the ALv2 or what is written as the guiding
principles here: http://people.apache.org/~rubys/3party.html.
I'm not speaking a moral judgment about whether or not I like the
Berkeley DB Java Edition license, let us say it is maybe an
understandable license, but I consider it a kind of booby trap in this
case. Assuming we could include Berkeley DB with the River distribution
and the whole is licensed under the ALv2 and an ISV wants to ship its
product using Outrigger as closed source it must remove Berkeley DB from
the distributions, this I think sucks for an ASF distribution. Although
one hopes everybody respects each other licensing terms I've seen a lot
of non-compliance with regard to the MySQL JDBC drivers that have a
similar license.
I see no problem though in e.g. providing the interface to Berkeley DB
in the same way as it was/is done for PSE but I would be against
shipping Berkely DB (assuming it was/is possible), but there are also
other decent performing routes possible based on compatible licenses.
--
Mark
Re: a potential "AR1" release
Posted by "John McClain - Sun Microsystems, Inc." <Jo...@Sun.COM>.
Sean Landis wrote:
> I'm not an expert on NIO but might a memory mapped file work if all
> you are saving is blobs?
If we re-whack Outrigger's store(s) we definitely want to see how NIO
can be leveraged.
--
John McClain john.mcclain@sun.com
Sun Microsystems, Inc.
Burlington, MA
And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.
- David Brooks
Re: a potential "AR1" release
Posted by Sean Landis <se...@gmail.com>.
I'm not an expert on NIO but might a memory mapped file work if all
you are saving is blobs?
Sean
On 8/31/07, John McClain - Sun Microsystems, Inc. <Jo...@sun.com> wrote:
> Mike Morris wrote:
> > John McClain - Sun Microsystems, Inc. wrote:
> >
> >> The problem with logstore is that it depends on Progress Software's
> >> ObjectStore PSE Pro.
> >
> > Thanks for the clarification, John.
> >
> >> Because of this I don't see having a dependency on PSE Pro was being
> >> an option for River.
> >
> > (I probably should have peeked at the code before commenting.) In my
> > mind was the option of replacing PSE Pro with some other
> > (licence-compatible) OODB (not that I have the cycles, energy or
> > knowledge to try, right now :-)
>
> As it turns out for the way Outrigger uses the store OODBs aren't really
> a good fit. It really just needs a bunch of independent blobs so in lots
> of ways an OODB (and even a RDB) is overkill for Outrigger - so if we
> decided snapstore wasn't enough I would probably go in some other
> direction. For the record the option the options we have considered in
> the past are :
>
> A JDBC based store : In the past one issue here was being able
> to provide a complete integrated package so it works out of the
> box without having to bring your own RDBMS. Now that Apache
> Derby is around (and its in the JDK!) an embedded Derby could be
> the default, and integration of others could be left to the user
>
> Keeping all the state in the log files snapstore (and logstore)
> produce, deleting/compacting logs as entries go away. Probably
> the most of work of all the options we have considered, but
> minimizes external dependencies and gives us the most options
> for optimization (not that it would necessarily lead to the
> fastest Outrigger...)
>
> Berkeley DB Java Edition : seems to be a good fit with what
> Outrigger needs, not sure about licensing, it is available
> under an "OSI-certified" open source license but I don't
> know which license it is and if there are any license
> compatibility issues with Apache.
>
> A "commit to memory" based scheme where Outrigger commits
> transactions to memory in one or more back end processes running
> on other machines. Has the potential to be very fast, but
> isn't as general as the other options.
>
> I could see ending up with multiple stores to satisfy different sets of
> requirements.
>
>
> --
> John McClain john.mcclain@sun.com
> Sun Microsystems, Inc.
> Burlington, MA
>
> And it is that way today. We are tricked by hope into starting
> companies, beginning books, immigrating to this country and investing
> in telecom networks. The challenges turn out to be tougher than we
> imagined. Our excessive optimism is exposed. New skills are demanded.
> But nothing important was ever begun in a prudential frame of mind.
>
> - David Brooks
>
>
>
Re: a potential "AR1" release
Posted by "John McClain - Sun Microsystems, Inc." <Jo...@Sun.COM>.
Mike Morris wrote:
> John McClain - Sun Microsystems, Inc. wrote:
>
>> The problem with logstore is that it depends on Progress Software's
>> ObjectStore PSE Pro.
>
> Thanks for the clarification, John.
>
>> Because of this I don't see having a dependency on PSE Pro was being
>> an option for River.
>
> (I probably should have peeked at the code before commenting.) In my
> mind was the option of replacing PSE Pro with some other
> (licence-compatible) OODB (not that I have the cycles, energy or
> knowledge to try, right now :-)
As it turns out for the way Outrigger uses the store OODBs aren't really
a good fit. It really just needs a bunch of independent blobs so in lots
of ways an OODB (and even a RDB) is overkill for Outrigger - so if we
decided snapstore wasn't enough I would probably go in some other
direction. For the record the option the options we have considered in
the past are :
A JDBC based store : In the past one issue here was being able
to provide a complete integrated package so it works out of the
box without having to bring your own RDBMS. Now that Apache
Derby is around (and its in the JDK!) an embedded Derby could be
the default, and integration of others could be left to the user
Keeping all the state in the log files snapstore (and logstore)
produce, deleting/compacting logs as entries go away. Probably
the most of work of all the options we have considered, but
minimizes external dependencies and gives us the most options
for optimization (not that it would necessarily lead to the
fastest Outrigger...)
Berkeley DB Java Edition : seems to be a good fit with what
Outrigger needs, not sure about licensing, it is available
under an "OSI-certified" open source license but I don't
know which license it is and if there are any license
compatibility issues with Apache.
A "commit to memory" based scheme where Outrigger commits
transactions to memory in one or more back end processes running
on other machines. Has the potential to be very fast, but
isn't as general as the other options.
I could see ending up with multiple stores to satisfy different sets of
requirements.
--
John McClain john.mcclain@sun.com
Sun Microsystems, Inc.
Burlington, MA
And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.
- David Brooks
Re: a potential "AR1" release
Posted by Mike Morris <mi...@gmail.com>.
John McClain - Sun Microsystems, Inc. wrote:
> The problem with logstore is that it depends on Progress Software's
> ObjectStore PSE Pro.
Thanks for the clarification, John.
> Because of this I don't see having a dependency on PSE Pro was being an
> option for River.
(I probably should have peeked at the code before commenting.) In my
mind was the option of replacing PSE Pro with some other
(licence-compatible) OODB (not that I have the cycles, energy or
knowledge to try, right now :-)
--
mike morris :: mikro2nd (at) gmail (dot) com
http://mikro2nd.net/
http://mikro2nd.net/blog/planb/
http://mikro2nd.net/blog/mike/
-- A day without chillies is a day wasted --
Re: a potential "AR1" release
Posted by "John McClain - Sun Microsystems, Inc." <Jo...@Sun.COM>.
Mike Morris wrote:
> John McClain - Sun Microsystems, Inc. wrote:
>
>> My vote is to remove logstore altogether and do it for AR1.
>
> +1 -- good candidate for re-inclusion in a later release.
Probably should have been a bit more explicit before, but at the time I
didn't have quite enough energy to write a longer message....
In my mind this would be a one way trip for logstore, it wouldn't be be
coming back.
The problem with logstore is that it depends on Progress Software's
ObjectStore PSE Pro. At build time you need a post processor that comes
with PSE Pro (though there might be alternatives here), and at runtime
you need their library, pro.zip. Getting access to either requires a
license from Progress Software, which in turn generally requires $$$.
Because of this I don't see having a dependency on PSE Pro was being an
option for River.
Since 2.0, Outrigger's store has been plugable, and there is a second
store implementation in the starter kit, "snapstore". Snapstore does not
depend on any external libraries. Snapstore doesn't scale as well as
logstore as the number of entries in the space goes up, but storing lots
and lots of entries has never been Outrigger's design center, so in
context this may not be a big limitation.
It is worth noting that because Outrigger caches the entire data set in
memory (hence the note that "storing lots and lots of entries has never
been Outrigger's design center" above) writing a new store isn't that
hard. If snapstore turns out not to be acceptable I can think at least
of 3 other options for new stores that we could pursue. There are also
some improvements we should make to snapstore that while they wouldn't
make it scale better in the total number of entries, they would
substantially improve its multi-threaded performance and cut the latency
of commits dramatically.
Don't know if this changes anyones mind.
--
John McClain john.mcclain@sun.com
Sun Microsystems, Inc.
Burlington, MA
And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.
- David Brooks
Re: a potential "AR1" release
Posted by Mike Morris <mi...@gmail.com>.
John McClain - Sun Microsystems, Inc. wrote:
> My vote is to remove logstore altogether and do it for AR1.
+1 -- good candidate for re-inclusion in a later release.
--
mike morris :: mikro2nd@gmail.com
cOcO technologies :: http://mikro2nd.net/
http://mikro2nd.net/
http://mikro2nd.net/blog/mike/
http://mikro2nd.net/blog/planb/
----- A day without chillies is a day wasted ------
Re: a potential "AR1" release
Posted by Jim Hurley <Ji...@Sun.COM>.
Thanks for everyone voicing their opinions on this one. Based
on all the +1s, it looks like we have an agreed upon direction
(remove logstore altogether as part of the AR1 release).
If anyone has an issue with that -- please post a -1 with
rationale soon. Thanks.
-Jim
On Aug 29, 2007, at 6:38 PM, Dan Creswell wrote:
>>>> One other question comes to mind... How should we handle the
>>>> logstore
>>>> portion of the outrigger build? Should we leave it as is,
>>>> disable it
>>>> in the build, or remove the sources completely? If we leave it
>>>> as is,
>>>> we would need to consider including the prebuilt-outrigger-
>>>> logstore.jar
>>>> in the source distribution, as Phil suggested, to allow builds
>>>> without
>>>> the need for a Jini installation. Disabling the logstore jar'ing
>>>> target, on the other hand, removes the dependency on the Jini
>>>> binary
>>>> installation but leaves the logstore sources in a unaltered state.
>>>> In all cases, logstore cannot be used without pro.zip (the PSEpro
>>>> runtime library), but persistence is still attainable through
>>>> the use
>>>> of the snaplogstore implementation.
>>>
>>> I'd lean towards what's expedient to get out "AR1" in short order
>>> -- but
>>> I do think we're going to have to bite the bullet and probably
>>> remove
>>> logstore from the build going forward. It doesn't seem to have long
>>> term viability.
>>
>> My vote is to remove logstore altogether and do it for AR1.
>>
>
> +1
>
Re: a potential "AR1" release
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
John McClain - Sun Microsystems, Inc. wrote:
> Jim Hurley wrote:
>> On Aug 28, 2007, at 3:43 PM, Frank Barnaby wrote:
>>> I've done a test build with the serviceui sources moved into the jtsk
>>> source tree (namespaces unchanged) and have found no obvious problems.
>>
>> Thanks Frank.
>>
>>> One other question comes to mind... How should we handle the logstore
>>> portion of the outrigger build? Should we leave it as is, disable it
>>> in the build, or remove the sources completely? If we leave it as is,
>>> we would need to consider including the prebuilt-outrigger-logstore.jar
>>> in the source distribution, as Phil suggested, to allow builds without
>>> the need for a Jini installation. Disabling the logstore jar'ing
>>> target, on the other hand, removes the dependency on the Jini binary
>>> installation but leaves the logstore sources in a unaltered state.
>>> In all cases, logstore cannot be used without pro.zip (the PSEpro
>>> runtime library), but persistence is still attainable through the use
>>> of the snaplogstore implementation.
>>
>> I'd lean towards what's expedient to get out "AR1" in short order -- but
>> I do think we're going to have to bite the bullet and probably remove
>> logstore from the build going forward. It doesn't seem to have long
>> term viability.
>
> My vote is to remove logstore altogether and do it for AR1.
>
+1
Re: a potential "AR1" release
Posted by Frank Barnaby <Fr...@Sun.COM>.
On Aug 29, 2007, at 10:41 AM, John McClain - Sun Microsystems, Inc.
wrote:
>
> My vote is to remove logstore altogether and do it for AR1.
>
+1
Re: a potential "AR1" release
Posted by Jim Waldo <Ji...@sun.com>.
> John McClain - Sun Microsystems, Inc. wrote:
>> My vote is to remove logstore altogether and do it for AR1.
+1
Waldo
Re: a potential "AR1" release
Posted by Bob Scheifler <Bo...@Sun.COM>.
John McClain - Sun Microsystems, Inc. wrote:
> My vote is to remove logstore altogether and do it for AR1.
+1
- Bob
Re: a potential "AR1" release
Posted by "John McClain - Sun Microsystems, Inc." <Jo...@Sun.COM>.
Jim Hurley wrote:
> On Aug 28, 2007, at 3:43 PM, Frank Barnaby wrote:
>> I've done a test build with the serviceui sources moved into the jtsk
>> source tree (namespaces unchanged) and have found no obvious problems.
>
> Thanks Frank.
>
>> One other question comes to mind... How should we handle the logstore
>> portion of the outrigger build? Should we leave it as is, disable it
>> in the build, or remove the sources completely? If we leave it as is,
>> we would need to consider including the prebuilt-outrigger-logstore.jar
>> in the source distribution, as Phil suggested, to allow builds without
>> the need for a Jini installation. Disabling the logstore jar'ing
>> target, on the other hand, removes the dependency on the Jini binary
>> installation but leaves the logstore sources in a unaltered state.
>> In all cases, logstore cannot be used without pro.zip (the PSEpro
>> runtime library), but persistence is still attainable through the use
>> of the snaplogstore implementation.
>
> I'd lean towards what's expedient to get out "AR1" in short order -- but
> I do think we're going to have to bite the bullet and probably remove
> logstore from the build going forward. It doesn't seem to have long term
> viability.
My vote is to remove logstore altogether and do it for AR1.
--
John McClain john.mcclain@sun.com
Sun Microsystems, Inc.
Burlington, MA
And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.
- David Brooks
Re: a potential "AR1" release
Posted by Jim Hurley <Ji...@Sun.COM>.
On Aug 28, 2007, at 3:43 PM, Frank Barnaby wrote:
> I've done a test build with the serviceui sources moved into the jtsk
> source tree (namespaces unchanged) and have found no obvious problems.
Thanks Frank.
> One other question comes to mind... How should we handle the logstore
> portion of the outrigger build? Should we leave it as is, disable it
> in the build, or remove the sources completely? If we leave it as is,
> we would need to consider including the prebuilt-outrigger-
> logstore.jar
> in the source distribution, as Phil suggested, to allow builds without
> the need for a Jini installation. Disabling the logstore jar'ing
> target, on the other hand, removes the dependency on the Jini binary
> installation but leaves the logstore sources in a unaltered state.
> In all cases, logstore cannot be used without pro.zip (the PSEpro
> runtime library), but persistence is still attainable through the use
> of the snaplogstore implementation.
I'd lean towards what's expedient to get out "AR1" in short order -- but
I do think we're going to have to bite the bullet and probably remove
logstore from the build going forward. It doesn't seem to have long
term viability.
Other opinions?
-Jim
Re: a potential "AR1" release
Posted by Frank Barnaby <Fr...@Sun.COM>.
Please ignore the second question regarding the serviceui.jar since
it's been discussed over the past couple days...
Frank
On Aug 28, 2007, at 3:43 PM, Frank Barnaby wrote:
>
> I've done a test build with the serviceui sources moved into the jtsk
> source tree (namespaces unchanged) and have found no obvious problems.
>
> This does raise the question of whether we need to add a jar'ing
> target
> for serviceui.
>
> One other question comes to mind... How should we handle the logstore
> portion of the outrigger build? Should we leave it as is, disable it
> in the build, or remove the sources completely? If we leave it as is,
> we would need to consider including the prebuilt-outrigger-
> logstore.jar
> in the source distribution, as Phil suggested, to allow builds without
> the need for a Jini installation. Disabling the logstore jar'ing
> target, on the other hand, removes the dependency on the Jini binary
> installation but leaves the logstore sources in a unaltered state.
> In all cases, logstore cannot be used without pro.zip (the PSEpro
> runtime library), but persistence is still attainable through the use
> of the snaplogstore implementation.
>
>
>
> Frank
>
>
>
> On Aug 24, 2007, at 2:52 PM, Jim Hurley wrote:
>
>> Not sure if these are the first/best questions to start with,
>> but I think having a better understanding of how serviceui
>> and the starterkit will fit/be bundled together would help.
>>
>> Since I view them as coming together (at least initially) as
>> part of the River project (not staying as separate entities)...
>> I wonder what it would take to move the serviceui sources
>> under the jtsk root. As an opening position (to get the
>> discussion started)... let's say that we bundle together
>> serviceui and starter kit into the same release bundle and
>> we go with the current starter kit structure.
>>
>> Thoughts? Issues? Alternatives?
>>
>> thanks -Jim
>>
>>
>>> * Should we go with the current starter kit release bundle
>>> structure?
>>>
>>> * Bundle starterkit and serviceui in the release bundle?
>>> (assuming yes) How should serviceui fit in?
>>
>
Re: a potential "AR1" release
Posted by Frank Barnaby <Fr...@Sun.COM>.
I've done a test build with the serviceui sources moved into the jtsk
source tree (namespaces unchanged) and have found no obvious problems.
This does raise the question of whether we need to add a jar'ing target
for serviceui.
One other question comes to mind... How should we handle the logstore
portion of the outrigger build? Should we leave it as is, disable it
in the build, or remove the sources completely? If we leave it as is,
we would need to consider including the prebuilt-outrigger-logstore.jar
in the source distribution, as Phil suggested, to allow builds without
the need for a Jini installation. Disabling the logstore jar'ing
target, on the other hand, removes the dependency on the Jini binary
installation but leaves the logstore sources in a unaltered state.
In all cases, logstore cannot be used without pro.zip (the PSEpro
runtime library), but persistence is still attainable through the use
of the snaplogstore implementation.
Frank
On Aug 24, 2007, at 2:52 PM, Jim Hurley wrote:
> Not sure if these are the first/best questions to start with,
> but I think having a better understanding of how serviceui
> and the starterkit will fit/be bundled together would help.
>
> Since I view them as coming together (at least initially) as
> part of the River project (not staying as separate entities)...
> I wonder what it would take to move the serviceui sources
> under the jtsk root. As an opening position (to get the
> discussion started)... let's say that we bundle together
> serviceui and starter kit into the same release bundle and
> we go with the current starter kit structure.
>
> Thoughts? Issues? Alternatives?
>
> thanks -Jim
>
>
>> * Should we go with the current starter kit release bundle structure?
>>
>> * Bundle starterkit and serviceui in the release bundle?
>> (assuming yes) How should serviceui fit in?
>
Re: a potential "AR1" release
Posted by Gregg Wonderly <gr...@wonderly.org>.
Jim Hurley wrote:
> Not sure if these are the first/best questions to start with,
> but I think having a better understanding of how serviceui
> and the starterkit will fit/be bundled together would help.
>
> Since I view them as coming together (at least initially) as
> part of the River project (not staying as separate entities)...
> I wonder what it would take to move the serviceui sources
> under the jtsk root. As an opening position (to get the
> discussion started)... let's say that we bundle together
> serviceui and starter kit into the same release bundle and
> we go with the current starter kit structure.
Give the current packaging that Bill (and the community) chose to use for
ServiceUI, it naturally fits into the tree from my perspective. I think it's
fine to just drop it in and go.
We might consider creating a serviceui.jar with the same content as before.
However, I think that this might create some problems down the road. I think
that just including the serviceui.jar content into jsk-dl.jar would be the best
choice, since we are all downloading both, most likely (or merging them into
another jar altogether), already.
Gregg Wonderly
Re: a potential "AR1" release
Posted by Jim Hurley <Ji...@Sun.COM>.
Not sure if these are the first/best questions to start with,
but I think having a better understanding of how serviceui
and the starterkit will fit/be bundled together would help.
Since I view them as coming together (at least initially) as
part of the River project (not staying as separate entities)...
I wonder what it would take to move the serviceui sources
under the jtsk root. As an opening position (to get the
discussion started)... let's say that we bundle together
serviceui and starter kit into the same release bundle and
we go with the current starter kit structure.
Thoughts? Issues? Alternatives?
thanks -Jim
> * Should we go with the current starter kit release bundle structure?
>
> * Bundle starterkit and serviceui in the release bundle?
> (assuming yes) How should serviceui fit in?