You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Mark Brouwer <ma...@cheiron.org> on 2007/01/04 10:13:32 UTC
[PROPOSAL] Source drop and bug database
Hi all,
The first step before we really can get started is the initial source
drop by Sun and Artima. While it feels rude to initiate this by me, I
think it is worth having a discussion about what gets dropped. I hope,
but please correct me if I'm wrong, the fastest way to get this done is
by stating my opinion as a proposal.
Below you will find my proposal as to what I would like to see become
the baseline from where the River project should start following the
roadmap we have to craft.
1) ServiceUI version 1.1a
2) Outstanding issues, if any, against ServiceUI version 1.1a
3) JTSK code version 2.1.1 [1], all parts which Sun can transfer to the
ASF, even the code we will likely remove [2] according to the roadmap
4) Outstanding issues against JTSK version 2.1.1
[1] my main motivation for bringing in the latest public version of the
JTSK and not a newer version is that many people are familiar with 2.1.1
and it will be this version that people have patches against that are
not yet incorporated by Sun. Also I think the integration of the code
modifications between the main/internal version branch of Sun and
version 2.1.1 will be a good exercise for the initial committers and
those interested in becoming one to get acquainted with the process 'in
place'.
[2] I realize 'what to be left out' has been questioned in the Jini
community, but I can't recall there was a conclusion. Therefore to me it
seems to make sense to have that discussion here, in the hope it can be
swift.
--
Mark
Re: [PROPOSAL] Source drop and bug database
Posted by Mark Brouwer <ma...@cheiron.org>.
Gregg Wonderly wrote:
> Dan Creswell wrote:
>> Yer, so I'm not sure but I think Mark might be talking about outstanding
>> RFE's, Bug Reports etc rather than patches etc.
>>
>> However, if I'm wrong and he is talking about patches, I'm with you.
>
> I'm just trying to request which base drop all of that should be added.
> I want all the RFEs and bugs to appear on top of something that all of
> us have in common. Then we can all get back to a common base for future
> updates.
I tried to say what you want Gregg. The initial baseline is the code
that everybody has to its avail at this very moment. Anything else,
bug-fixes, enhancements, etc. should be done against this baseline.
People should be able to check out the latest version from SVN, diff it
against their distribution and should only find the work that has been
committed through the River project.
To me this also implies that changing the com.sun.jini namespace to
something else is something we must do after we created some sort of
stable release. This would allow people to really work with the stuff
from the River project without any problems in their current
environment, get confidence in it and the project, before they have to
turn the world upside down as result of moving over to
org.apache.<river?>. But this is really something for the roadmap.
--
Mark
Re: [PROPOSAL] Source drop and bug database
Posted by Gregg Wonderly <ge...@cox.net>.
Dan Creswell wrote:
> Yer, so I'm not sure but I think Mark might be talking about outstanding
> RFE's, Bug Reports etc rather than patches etc.
>
> However, if I'm wrong and he is talking about patches, I'm with you.
I'm just trying to request which base drop all of that should be added. I want
all the RFEs and bugs to appear on top of something that all of us have in
common. Then we can all get back to a common base for future updates.
Gregg Wonderly
Re: [PROPOSAL] Source drop and bug database
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Gregg Wonderly wrote:
> Mark Brouwer wrote:
>> 3) JTSK code version 2.1.1 [1], all parts which Sun can transfer to the
>> ASF, even the code we will likely remove [2] according to the roadmap
>>
>> 4) Outstanding issues against JTSK version 2.1.1
>
> I would prefer that there be a base revision eqivalent to the last
> public release of the JTSK from the old jini.org drop. Any additional
> changes on top of that should be checked in as revisions to that
> baseline so that everyone with changes to the base can easily extract
> and generate diffs to work on arriving at a common codeline that will
> benefit all of us who have been making bug fixes and other related
> changes that we will need to be able to generate tangible diffs for
> consideration by the committers.
>
Yer, so I'm not sure but I think Mark might be talking about outstanding
RFE's, Bug Reports etc rather than patches etc.
However, if I'm wrong and he is talking about patches, I'm with you.
Dan.
Re: [PROPOSAL] Source drop and bug database
Posted by Gregg Wonderly <gr...@wonderly.org>.
Mark Brouwer wrote:
> 3) JTSK code version 2.1.1 [1], all parts which Sun can transfer to the
> ASF, even the code we will likely remove [2] according to the roadmap
>
> 4) Outstanding issues against JTSK version 2.1.1
I would prefer that there be a base revision eqivalent to the last public
release of the JTSK from the old jini.org drop. Any additional changes on top
of that should be checked in as revisions to that baseline so that everyone with
changes to the base can easily extract and generate diffs to work on arriving at
a common codeline that will benefit all of us who have been making bug fixes and
other related changes that we will need to be able to generate tangible diffs
for consideration by the committers.
Gregg Wonderly
Re: [PROPOSAL] Source drop and bug database
Posted by Jim Hurley <Ji...@Sun.COM>.
On Jan 4, 2007, at 11:59 PM, Nigel Daley wrote:
> On Jan 4, 2007, at 5:49 AM, Jim Hurley wrote:
>> :
:
>>> [2] I realize 'what to be left out' has been questioned in the Jini
>>> community, but I can't recall there was a conclusion. Therefore
>>> to me it
>>> seems to make sense to have that discussion here, in the hope it
>>> can be
>>> swift.
>>
>> There have been various, mixed, and interesting discussions on
>> what should or should not be included from the Starter Kit. To my
>> mind there were never any conclusions (or consensus) reached and
>> our plan was to move over the Starter Kit (sans 3rd party code - only
>> the installer as far as I know)
>
> Jim, there is custom code written as part of the installer -- if
> memory serves me, code that verifies multicast, and other network
> and file system properties. Perhaps this could be useful to the
> River community as well?
Sorry for the confusion -- yes, I meant sans just the 3rd party code.
The other code you mention would of course be useful and we'll
bring it over.
-Jim
Re: [PROPOSAL] Source drop and bug database
Posted by Nigel Daley <nd...@mac.com>.
On Jan 4, 2007, at 5:49 AM, Jim Hurley wrote:
> Hi Mark-
>
> Thanks for getting this discussion going.
>
> On Jan 4, 2007, at 4:13 AM, Mark Brouwer wrote:
>> Hi all,
>>
>> The first step before we really can get started is the initial source
>> drop by Sun and Artima. While it feels rude to initiate this by me, I
>> think it is worth having a discussion about what gets dropped. I
>> hope,
>> but please correct me if I'm wrong, the fastest way to get this
>> done is
>> by stating my opinion as a proposal.
>>
>> Below you will find my proposal as to what I would like to see become
>> the baseline from where the River project should start following the
>> roadmap we have to craft.
>
> We did have to touch on this in our project proposal (see:
> <http://wiki.apache.org/incubator/RiverProposal>, "(2) identify
> the initial source from with the project is to be populated". We
> had identified the Starter Kit (and link to the latest published
> version). Although we did not explicitly state v2.1, it was certainly
> meant to be implied that it would be the latest published version.
>
> We also identified ServiceUI and a link to the latest published
> version (v1.1a).
>
> Finally, we identified the QATests project, which contained the
> tests and harness we used for testing releases of the Starter Kit.
>
>> 1) ServiceUI version 1.1a
>>
>> 2) Outstanding issues, if any, against ServiceUI version 1.1a
>
> Bill - if you have any substantive issues (logged, or just scribbled
> on a notepad), I agree that it would be good to seed the incubator
> project JIRA with them.
>
>> 3) JTSK code version 2.1.1 [1], all parts which Sun can transfer
>> to the
>> ASF, even the code we will likely remove [2] according to the
>> roadmap
>>
>> 4) Outstanding issues against JTSK version 2.1.1
>
> I'm not sure of the logistics for getting issues moved from our
> internal system to JIRA, but it's something we'll need to look
> at relatively soon. We certainly want and expect to get the major
> issues we have logged moved over.
>
>> [1] my main motivation for bringing in the latest public version
>> of the
>> JTSK and not a newer version is that many people are familiar with
>> 2.1.1
>> and it will be this version that people have patches against that are
>> not yet incorporated by Sun. Also I think the integration of the code
>> modifications between the main/internal version branch of Sun and
>> version 2.1.1 will be a good exercise for the initial committers and
>> those interested in becoming one to get acquainted with the
>> process 'in
>> place'.
>
> We're definitely in sync on this one.
>
>> [2] I realize 'what to be left out' has been questioned in the Jini
>> community, but I can't recall there was a conclusion. Therefore to
>> me it
>> seems to make sense to have that discussion here, in the hope it
>> can be
>> swift.
>
> There have been various, mixed, and interesting discussions on
> what should or should not be included from the Starter Kit. To my
> mind there were never any conclusions (or consensus) reached and
> our plan was to move over the Starter Kit (sans 3rd party code - only
> the installer as far as I know)
Jim, there is custom code written as part of the installer -- if
memory serves me, code that verifies multicast, and other network and
file system properties. Perhaps this could be useful to the River
community as well?
nige
> and have the discussion as part of
> incubating at Apache.
>
>> --
>> Mark
>
> -Jim
Re: [PROPOSAL] Source drop and bug database
Posted by Jeff Ramsdale <je...@gmail.com>.
On 1/4/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> I was thinking of removing it, but left it as bait for discussion :)
>
> geir
Heh!
Without bait I'm sure discussion by this community would grind to a halt. ;-)
Jeff
Re: [PROPOSAL] Source drop and bug database
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 4, 2007, at 12:06 PM, Jeff Ramsdale wrote:
> I see on the site that there's a menu section entitled
> "Subcomponents." Is that intended to be a mechanisms for organizing
> sub-projects? Specifically, should the code repository and site
> reflect a separation between the core code and the TCK and (possibly)
> other subcomponents? For instance, is there any benefit in organizing
> the Sun service implementations accordingly as well?
Whatever feels good. It came from what we were doing in Harmony,
where we have the classlibrary, the build/test infrastructure, the
DRL JVM, the other VMs, etc.
I was thinking of removing it, but left it as bait for discussion :)
geir
>
> Jeff
>
> On 1/4/07, Jim Hurley <Ji...@sun.com> wrote:
>> Another piece we should probably consider as part of
>> the initial codebase (or maybe to include down the line)
>> is the "Jini Technology Lookup, Discovery, and Join
>> Compatibility Kit" (LDJ). You can find it under "Associated
>> Downloads" at:
>> <https://starterkit.dev.java.net/downloads/index.html>
>>
>> Way back when :-) under the SCSL, something similar
>> was named the "Technology Compatibility Kit" (TCK) and
>> was a legal measure for helping to ensure compliance for
>> commercial implementations.
>>
>> I think some people have found it generally handy over
>> time to use to test their Jini service, etc -- so it might be
>> good to include.
>>
>> Thoughts?
>>
>> -Jim
>>
Re: [PROPOSAL] Source drop and bug database
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
> At least I can identify ServiceUI and the JTSK as completely independent
While they have been independent, I don't see a good reason to keep them
separate going forward. $.02
- Bob
Re: [PROPOSAL] Source drop and bug database
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Mark Brouwer wrote:
> Hi Dan,
>
> Dan Creswell wrote:
>> Mark Brouwer wrote:
>>> Geir Magnusson Jr. wrote:
>>>> I think that it's something that doesn't need to be decided up front -
>>>> it's something that can evolve as the community does.
>>> While I understand it is quite easy to move things around in the
>>> repository, it is always troubles for those working on the project. So a
>>> little bit of thinking up front won't do any harm.
>>>
>>
>> Agreed but do you not feel like we're still guessing for the most part?
>>
>> Especially as we haven't got much in the way of feedback from the
>> community to give us a hint as to how they might want things done?
>
> Maybe I'm having a non-ASF compliant opinion here, for which no doubt I
> will be keelhauled if so. But we have an initial committer list, that
> means we have enough people willing to work here so we can move forward
> in a way that *we* want, biased of course by each person own supporters
> ;-).
>
:)
> Anybody else can raise his voice and become involved and I think the
> people here have shown in length to listen and discuss any issue brought
> up, so I'm not afraid that we block participation. But I am of the
> opinion we should stop trying and waiting to listen to the silent mass
> (for each of us represents an unknown percentage of the silent Jini
> community).
>
As it happens, so am I but I have to test whether other people feel the
same ;)
> People know the River project has started, based on the number of
> subscribers I think a lot have confidence in this initial committer list
> to make the right decisions till it gets rolling. If that turns out to
> be a bad assumption they are punished for their lack of interest ;-)
> and will likely raise their voice somewhere in the future.
>
Punished indeed!
> But let me add my new disclaimer for this year:
>
> "None of my opinions are as strong in reality as my words might
> indicate, it is just a lack of fine social capabilities.".
Re: [PROPOSAL] Source drop and bug database
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi Dan,
Dan Creswell wrote:
> Mark Brouwer wrote:
>> Geir Magnusson Jr. wrote:
>>> I think that it's something that doesn't need to be decided up front -
>>> it's something that can evolve as the community does.
>> While I understand it is quite easy to move things around in the
>> repository, it is always troubles for those working on the project. So a
>> little bit of thinking up front won't do any harm.
>>
>
> Agreed but do you not feel like we're still guessing for the most part?
>
> Especially as we haven't got much in the way of feedback from the
> community to give us a hint as to how they might want things done?
Maybe I'm having a non-ASF compliant opinion here, for which no doubt I
will be keelhauled if so. But we have an initial committer list, that
means we have enough people willing to work here so we can move forward
in a way that *we* want, biased of course by each person own supporters ;-).
Anybody else can raise his voice and become involved and I think the
people here have shown in length to listen and discuss any issue brought
up, so I'm not afraid that we block participation. But I am of the
opinion we should stop trying and waiting to listen to the silent mass
(for each of us represents an unknown percentage of the silent Jini
community).
People know the River project has started, based on the number of
subscribers I think a lot have confidence in this initial committer list
to make the right decisions till it gets rolling. If that turns out to
be a bad assumption they are punished for their lack of interest ;-)
and will likely raise their voice somewhere in the future.
But let me add my new disclaimer for this year:
"None of my opinions are as strong in reality as my words might
indicate, it is just a lack of fine social capabilities.".
--
Mark
Re: [PROPOSAL] Source drop and bug database
Posted by Nigel Daley <nd...@mac.com>.
On Jan 4, 2007, at 3:33 PM, Dan Creswell wrote:
> Mark Brouwer wrote:
>> Geir Magnusson Jr. wrote:
>>> I think that it's something that doesn't need to be decided up
>>> front -
>>> it's something that can evolve as the community does.
>>
>> While I understand it is quite easy to move things around in the
>> repository, it is always troubles for those working on the
>> project. So a
>> little bit of thinking up front won't do any harm.
>>
>
> Agreed but do you not feel like we're still guessing for the most
> part?
>
> Especially as we haven't got much in the way of feedback from the
> community to give us a hint as to how they might want things done?
>
>> At least I can identify ServiceUI and the JTSK as completely
>> independent
>> and maybe also the QA test framework. We have to make a decision
>> either
>> way so I'm in favor of:
>>
>
> Given that these are well isolated packages anyways, I'm not as yet
> sure
> why giving them all a separate trunk helps us much at this stage. I'd
> want to figure out what the interface dependencies etc are between
> these
> things first at least.
>
>> /river/jtsk/trunk
>> /river/qatest/trunk [a bit less sure about this one]
>> /river/serviceui/trunk
>> /river/site/
+0. Thanks for making a proposal Mark. I guess I don't see a
compelling reason either way. FWIW, the separations you called out
certainly reflect the current separation of these items. Most of my
past experience (before leaving the Jini team at Sun) was with qatest
and the LDJ (formerly the TCK). These are large custom frameworks
that were always considered separate from the starter kit.
nige
Re: [PROPOSAL] Source drop and bug database
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Mark Brouwer wrote:
> Geir Magnusson Jr. wrote:
>> I think that it's something that doesn't need to be decided up front -
>> it's something that can evolve as the community does.
>
> While I understand it is quite easy to move things around in the
> repository, it is always troubles for those working on the project. So a
> little bit of thinking up front won't do any harm.
>
Agreed but do you not feel like we're still guessing for the most part?
Especially as we haven't got much in the way of feedback from the
community to give us a hint as to how they might want things done?
> At least I can identify ServiceUI and the JTSK as completely independent
> and maybe also the QA test framework. We have to make a decision either
> way so I'm in favor of:
>
Given that these are well isolated packages anyways, I'm not as yet sure
why giving them all a separate trunk helps us much at this stage. I'd
want to figure out what the interface dependencies etc are between these
things first at least.
> /river/jtsk/trunk
> /river/qatest/trunk [a bit less sure about this one]
> /river/serviceui/trunk
> /river/site/
Let's see what others think.......I'm just aware that we've not seen
much from anyone else (particularly committers) as yet on this or many
of the other topics we've started in on.
Dan.
Re: [PROPOSAL] Source drop and bug database
Posted by Mark Brouwer <ma...@cheiron.org>.
Geir Magnusson Jr. wrote:
> I think that it's something that doesn't need to be decided up front -
> it's something that can evolve as the community does.
While I understand it is quite easy to move things around in the
repository, it is always troubles for those working on the project. So a
little bit of thinking up front won't do any harm.
At least I can identify ServiceUI and the JTSK as completely independent
and maybe also the QA test framework. We have to make a decision either
way so I'm in favor of:
/river/jtsk/trunk
/river/qatest/trunk [a bit less sure about this one]
/river/serviceui/trunk
/river/site/
--
Mark
Re: [PROPOSAL] Source drop and bug database
Posted by Dan Creswell <da...@dcrdev.demon.co.uk>.
Geir Magnusson Jr. wrote:
> I think that it's something that doesn't need to be decided up front -
> it's something that can evolve as the community does.
>
+1
> geir
>
> On Jan 4, 2007, at 5:06 PM, Mark Brouwer wrote:
>
>> Thanks Craig and Geir for some insight in the branching and
>> possibilities.
>>
>> I think that we should decide soon which strategy to follow.
>> --Mark
>
>
Re: [PROPOSAL] Source drop and bug database
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I think that it's something that doesn't need to be decided up front
- it's something that can evolve as the community does.
geir
On Jan 4, 2007, at 5:06 PM, Mark Brouwer wrote:
> Thanks Craig and Geir for some insight in the branching and
> possibilities.
>
> I think that we should decide soon which strategy to follow.
> --
> Mark
Re: [PROPOSAL] Source drop and bug database
Posted by Mark Brouwer <ma...@cheiron.org>.
Thanks Craig and Geir for some insight in the branching and possibilities.
I think that we should decide soon which strategy to follow.
--
Mark
Re: [PROPOSAL] Source drop and bug database
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 4, 2007, at 2:48 PM, Mark Brouwer wrote:
> Geir Magnusson Jr. wrote:
>
>> We have something similar in harmony - we have the main components
>> distinct because they can be versioned separately
>> harmony/classlib/trunk
>> harmony/drlvm/trunk
>> etc
>> and then a "federated build point" :
>> harmony/trunk
>> which uses the magic of svn to create
>> harmony/trunk
>> /working_classlib
>> /working_vm
>> /working_jdktools
>> /commonresources
>> so from the POV of trunk, you have one big tree, yet each of those
>> subdirs had a svn switch done to them so working in
>> harmony/trunk/working_classlib
>> is the same as working in
>> harmony/classlib/trunk
>> It works very nicely - its very convenient to work in, and means
>> that in the future, other VMs or such can be swapped in w/o
>> disruption of the current subprojects.
>
> Let me try to understand the implications of all this.
>
> Say classlib is getting ready for a release. At that time you
> branch to
> (forgive me the use of perforce conventions)
> harmony/classlib/version/1.5/ , most people keep working on the trunk
> line and a few keep working on stabilizing the version/1.5 line.
> After a
> certain point in time, a decision has been reached and
> harmony/classlib/release/1.5/0 is created to reflect the final
> release.
Sure (although we won't be releasing classlib separately...)
>
> When you are about to branch the harmony/trunk will you alter the
> 'mappings' so the release or version branch of the individual projects
> are mapping to the harmony trunk? In other words will
> harmony/trunk/working_classlib actually be
> harmony/classlib/release/1.5/0, or am I screwing things up?
That's the beauty of it - you can make the "federation" be anything
that you want - makes it easy to work with bits you want to.
>
> Should I see the magic of SVN as a sort of symbolic links to get a
> 'virtual' view on the actual repository. Something that perforce e.g.
> arranges with clientviews that maps various locations of the
> repository
> under a common root in your workspace, but that is not reflected in
> the
> repository itself.
I guess so.
geir
> --
> Mark
Re: [PROPOSAL] Source drop and bug database
Posted by Craig L Russell <Cr...@Sun.COM>.
This is a test to see if I understand the Harmony strategy (I'm not
involved in the Harmony project...)
On Jan 4, 2007, at 11:48 AM, Mark Brouwer wrote:
> Geir Magnusson Jr. wrote:
>
>> We have something similar in harmony - we have the main components
>> distinct because they can be versioned separately
>> harmony/classlib/trunk
>> harmony/drlvm/trunk
>> etc
>> and then a "federated build point" :
>> harmony/trunk
>> which uses the magic of svn to create
>> harmony/trunk
>> /working_classlib
>> /working_vm
>> /working_jdktools
>> /commonresources
>> so from the POV of trunk, you have one big tree, yet each of those
>> subdirs had a svn switch done to them so working in
>> harmony/trunk/working_classlib
>> is the same as working in
>> harmony/classlib/trunk
>> It works very nicely - its very convenient to work in, and means
>> that in the future, other VMs or such can be swapped in w/o
>> disruption of the current subprojects.
>
> Let me try to understand the implications of all this.
>
> Say classlib is getting ready for a release.
Independent of a Harmony release, which isn't quite ready for release
due to non-classpath issues.
> At that time you branch to
> (forgive me the use of perforce conventions)
> harmony/classlib/version/1.5/ , most people keep working on the trunk
> line and a few keep working on stabilizing the version/1.5 line.
Yes.
> After a
> certain point in time, a decision has been reached and
> harmony/classlib/release/1.5/0 is created to reflect the final
> release.
It might be better to just tag the release/1.5 branch by creating yet
another branch that by convention is read-only. That way, after
release you can continue to work in the 1.5 branch for maintenance of
that branch but if you need to check out what you released, you check
out the tag.
>
> When you are about to branch the harmony/trunk will you alter the
> 'mappings' so the release or version branch of the individual projects
> are mapping to the harmony trunk?
When you are getting ready to release Harmony, you create a new
releases/3.0 from the Harmony trunk. You create new classlib/releases/
1.6 from the classlib trunk and so forth for each of the sub
projects. You update the Harmony/releases/3.0 to refer to the
stabilizing branches for each of the sub projects. Harmony trunk
continues to refer to the sub projects' trunks.
> In other words will
> harmony/trunk/working_classlib actually be
> harmony/classlib/release/1.5/0, or am I screwing things up?
I think the working_classlib in the Harmony/releases/3.0 branch will
be changed to refer to the classlib/releases/1.6 branch. So the
stabilizing activities of each sub project will be folded into the
stabilizing Harmony/releases/3.0 branch.
>
> Should I see the magic of SVN as a sort of symbolic links to get a
> 'virtual' view on the actual repository. Something that perforce e.g.
> arranges with clientviews that maps various locations of the
> repository
> under a common root in your workspace, but that is not reflected in
> the
> repository itself.
Don't know perforce well enough to comment. :-(
Craig
> --
> Mark
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: [PROPOSAL] Source drop and bug database
Posted by Mark Brouwer <ma...@cheiron.org>.
Geir Magnusson Jr. wrote:
> We have something similar in harmony - we have the main components
> distinct because they can be versioned separately
>
> harmony/classlib/trunk
> harmony/drlvm/trunk
> etc
>
> and then a "federated build point" :
>
> harmony/trunk
>
> which uses the magic of svn to create
>
>
> harmony/trunk
> /working_classlib
> /working_vm
> /working_jdktools
> /commonresources
>
> so from the POV of trunk, you have one big tree, yet each of those
> subdirs had a svn switch done to them so working in
>
> harmony/trunk/working_classlib
>
> is the same as working in
>
> harmony/classlib/trunk
>
> It works very nicely - its very convenient to work in, and means that in
> the future, other VMs or such can be swapped in w/o disruption of the
> current subprojects.
Let me try to understand the implications of all this.
Say classlib is getting ready for a release. At that time you branch to
(forgive me the use of perforce conventions)
harmony/classlib/version/1.5/ , most people keep working on the trunk
line and a few keep working on stabilizing the version/1.5 line. After a
certain point in time, a decision has been reached and
harmony/classlib/release/1.5/0 is created to reflect the final release.
When you are about to branch the harmony/trunk will you alter the
'mappings' so the release or version branch of the individual projects
are mapping to the harmony trunk? In other words will
harmony/trunk/working_classlib actually be
harmony/classlib/release/1.5/0, or am I screwing things up?
Should I see the magic of SVN as a sort of symbolic links to get a
'virtual' view on the actual repository. Something that perforce e.g.
arranges with clientviews that maps various locations of the repository
under a common root in your workspace, but that is not reflected in the
repository itself.
--
Mark
Re: [PROPOSAL] Source drop and bug database
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 4, 2007, at 1:45 PM, Craig L Russell wrote:
>
> On Jan 4, 2007, at 9:06 AM, Jeff Ramsdale wrote:
>
>> I see on the site that there's a menu section entitled
>> "Subcomponents." Is that intended to be a mechanisms for organizing
>> sub-projects? Specifically, should the code repository and site
>> reflect a separation between the core code and the TCK and (possibly)
>> other subcomponents?
>
> Excellent question. If there are clearly separate components that
> can be shipped or used separately, it makes sense to have separate
> sub-projects to reflect the components, with dependencies documented.
>
> For example, if there exist a common core with bootstrap code, and
> an implementation that depends on the core, the structure of the
> code could look like:
>
> river/
> site/
> trunk/
> core/
> src/
> java/
> org/
> apache/
> river/
> service-file/
> src/
> java/
> org/
> apache/
> river/
> service-print/
> src/
> java/
> org/
> apache/
> river/
>
> Each sub-project under trunk builds its own jar file for distribution.
We have something similar in harmony - we have the main components
distinct because they can be versioned separately
harmony/classlib/trunk
harmony/drlvm/trunk
etc
and then a "federated build point" :
harmony/trunk
which uses the magic of svn to create
harmony/trunk
/working_classlib
/working_vm
/working_jdktools
/commonresources
so from the POV of trunk, you have one big tree, yet each of those
subdirs had a svn switch done to them so working in
harmony/trunk/working_classlib
is the same as working in
harmony/classlib/trunk
It works very nicely - its very convenient to work in, and means that
in the future, other VMs or such can be swapped in w/o disruption of
the current subprojects.
geir
>
> Craig
>
>> For instance, is there any benefit in organizing
>> the Sun service implementations accordingly as well?
>>
>> Jeff
>>
>> On 1/4/07, Jim Hurley <Ji...@sun.com> wrote:
>>> Another piece we should probably consider as part of
>>> the initial codebase (or maybe to include down the line)
>>> is the "Jini Technology Lookup, Discovery, and Join
>>> Compatibility Kit" (LDJ). You can find it under "Associated
>>> Downloads" at:
>>> <https://starterkit.dev.java.net/downloads/index.html>
>>>
>>> Way back when :-) under the SCSL, something similar
>>> was named the "Technology Compatibility Kit" (TCK) and
>>> was a legal measure for helping to ensure compliance for
>>> commercial implementations.
>>>
>>> I think some people have found it generally handy over
>>> time to use to test their Jini service, etc -- so it might be
>>> good to include.
>>>
>>> Thoughts?
>>>
>>> -Jim
>>>
>
> 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: [PROPOSAL] Source drop and bug database
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jan 4, 2007, at 9:06 AM, Jeff Ramsdale wrote:
> I see on the site that there's a menu section entitled
> "Subcomponents." Is that intended to be a mechanisms for organizing
> sub-projects? Specifically, should the code repository and site
> reflect a separation between the core code and the TCK and (possibly)
> other subcomponents?
Excellent question. If there are clearly separate components that can
be shipped or used separately, it makes sense to have separate sub-
projects to reflect the components, with dependencies documented.
For example, if there exist a common core with bootstrap code, and an
implementation that depends on the core, the structure of the code
could look like:
river/
site/
trunk/
core/
src/
java/
org/
apache/
river/
service-file/
src/
java/
org/
apache/
river/
service-print/
src/
java/
org/
apache/
river/
Each sub-project under trunk builds its own jar file for distribution.
Craig
> For instance, is there any benefit in organizing
> the Sun service implementations accordingly as well?
>
> Jeff
>
> On 1/4/07, Jim Hurley <Ji...@sun.com> wrote:
>> Another piece we should probably consider as part of
>> the initial codebase (or maybe to include down the line)
>> is the "Jini Technology Lookup, Discovery, and Join
>> Compatibility Kit" (LDJ). You can find it under "Associated
>> Downloads" at:
>> <https://starterkit.dev.java.net/downloads/index.html>
>>
>> Way back when :-) under the SCSL, something similar
>> was named the "Technology Compatibility Kit" (TCK) and
>> was a legal measure for helping to ensure compliance for
>> commercial implementations.
>>
>> I think some people have found it generally handy over
>> time to use to test their Jini service, etc -- so it might be
>> good to include.
>>
>> Thoughts?
>>
>> -Jim
>>
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: [PROPOSAL] Source drop and bug database
Posted by Jeff Ramsdale <je...@gmail.com>.
I see on the site that there's a menu section entitled
"Subcomponents." Is that intended to be a mechanisms for organizing
sub-projects? Specifically, should the code repository and site
reflect a separation between the core code and the TCK and (possibly)
other subcomponents? For instance, is there any benefit in organizing
the Sun service implementations accordingly as well?
Jeff
On 1/4/07, Jim Hurley <Ji...@sun.com> wrote:
> Another piece we should probably consider as part of
> the initial codebase (or maybe to include down the line)
> is the "Jini Technology Lookup, Discovery, and Join
> Compatibility Kit" (LDJ). You can find it under "Associated
> Downloads" at:
> <https://starterkit.dev.java.net/downloads/index.html>
>
> Way back when :-) under the SCSL, something similar
> was named the "Technology Compatibility Kit" (TCK) and
> was a legal measure for helping to ensure compliance for
> commercial implementations.
>
> I think some people have found it generally handy over
> time to use to test their Jini service, etc -- so it might be
> good to include.
>
> Thoughts?
>
> -Jim
>
Re: [PROPOSAL] Source drop and bug database
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 4, 2007, at 1:23 PM, Mark Brouwer wrote:
> Jim Hurley wrote:
>
>> Way back when :-) under the SCSL, something similar
>> was named the "Technology Compatibility Kit" (TCK) and
>> was a legal measure for helping to ensure compliance for
>> commercial implementations.
>> I think some people have found it generally handy over
>> time to use to test their Jini service, etc -- so it might be
>> good to include.
>> Thoughts?
>
> I don't use it anymore, I rely on the utilities to do their work or
> on a
> container, but I see value in having it. But I think it is better to
> introduce it after the project has started, just to prevent from
> overload.
>
> This also raises a question, how are we going to manage all this. From
> SVN I get the impression the website is a separate branch in the
> repository, but do we have to check-in all 'subprojects' into one
> trunk.
There's no such thing as a "branch" in SVN in the classic version
control sense - branches are just copies into a new directory.
>
> In the end I hope the River project becomes a TLP with various
> subprojects such as core, lus implementation, javaspaces
> implementation,
> etc.. Each with their own release schedule. Dumping everything in one
> trunk doesn't seem very handy to me, but as I already mentioned I'm an
> SVN infant so maybe this works out well. Anyone?
> --
> Mark
Re: [PROPOSAL] Source drop and bug database
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jan 4, 2007, at 10:35 AM, Jeff Ramsdale wrote:
> Generally all work should be done on Trunk--
+1
> I'd even suggest that for
> the website, though if it were an exception it wouldn't bother me as
> much as having subprojects on branches.
I'd suggest keeping site separate from trunk. There's only one site,
after all, and from the site, you want to refer to bits in trunk,
branches, tags, etc.
Craig
>
> http://svnbook.red-bean.com/en/1.0/ch05s04.html#svn-ch-5-sect-6.1
>
> http://devnulled.com/content/2006/10/guide-and-best-practices-for-
> subversion-branching/
>
> Jeff
>
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: [PROPOSAL] Source drop and bug database
Posted by Jeff Ramsdale <je...@gmail.com>.
Generally all work should be done on Trunk--I'd even suggest that for
the website, though if it were an exception it wouldn't bother me as
much as having subprojects on branches.
http://svnbook.red-bean.com/en/1.0/ch05s04.html#svn-ch-5-sect-6.1
http://devnulled.com/content/2006/10/guide-and-best-practices-for-subversion-branching/
Jeff
On 1/4/07, Mark Brouwer <ma...@cheiron.org> wrote:
> Jim Hurley wrote:
>
> > Way back when :-) under the SCSL, something similar
> > was named the "Technology Compatibility Kit" (TCK) and
> > was a legal measure for helping to ensure compliance for
> > commercial implementations.
> >
> > I think some people have found it generally handy over
> > time to use to test their Jini service, etc -- so it might be
> > good to include.
> >
> > Thoughts?
>
> I don't use it anymore, I rely on the utilities to do their work or on a
> container, but I see value in having it. But I think it is better to
> introduce it after the project has started, just to prevent from overload.
>
> This also raises a question, how are we going to manage all this. From
> SVN I get the impression the website is a separate branch in the
> repository, but do we have to check-in all 'subprojects' into one trunk.
>
> In the end I hope the River project becomes a TLP with various
> subprojects such as core, lus implementation, javaspaces implementation,
> etc.. Each with their own release schedule. Dumping everything in one
> trunk doesn't seem very handy to me, but as I already mentioned I'm an
> SVN infant so maybe this works out well. Anyone?
> --
> Mark
>
Re: [PROPOSAL] Source drop and bug database
Posted by Gregg Wonderly <gr...@wonderly.org>.
Mark Brouwer wrote:
> But in time I hope the JTSK is split up in individual pieces that will
> evolve each on their own pace, I really don't have a clue however at
> what time during the project this should happen.
One thing that I've been thinking about is having a core distribution that is
just reggie, norm and mahalo (which could be optional) with jars for the APIs
under net.jini, and then separately releasing everything else. This would
provide a core distibution that includes support for service lookup, and then
allow additional services such as outrigger, phoenix etc to be available for
those that need them.
Gregg Wonderly
Re: [PROPOSAL] Source drop and bug database
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi Graig,
Craig L Russell wrote:
>
> On Jan 4, 2007, at 10:23 AM, Mark Brouwer wrote:
>
>> This also raises a question, how are we going to manage all this. From
>> SVN I get the impression the website is a separate branch in the
>> repository, but do we have to check-in all 'subprojects' into one trunk.
>
> The way I use the term, a branch is a copy of a trunk that has the same
> content structure and much of the same contents, with some changes here
> and there. So if you want to work on a disruptive feature, you can
> branch the trunk, iterate until it all works, leaving the trunk
> buildable, and after the branch is complete, merge it to the trunk. You
> can then delete the branch if you have no further use for it.
>
> You can also branch for a release. Development continues on the trunk
> and changes needed to stabilize the release are checked into the branch.
> Also, artifacts are changed in the branch to reflect the release number
> of the release. After release, both branch and trunk continue to exist.
This sounds very familiar to the way one should work with Perforce so I
think I'm aligned. Way of working is the same, tooling is different.
>> In the end I hope the River project becomes a TLP with various
>> subprojects such as core, lus implementation, javaspaces implementation,
>> etc.. Each with their own release schedule. Dumping everything in one
>> trunk doesn't seem very handy to me, but as I already mentioned I'm an
>> SVN infant so maybe this works out well. Anyone?
>
> I don't think it matters much whether you have a structure like:
I think it really matters, for the reasons you gave yourself :-)
> 1)
> trunk/
> core/
> javaspaces/
> lus
>
> or
>
> 2)
> core/
> trunk/
> javaspaces/
> trunk/
> lus/
> trunk/
>
> If you release a number of related things together, that argues for a
> common trunk, as 1).
This is the current state for the JTSK so that argues for 1), however
ServiceUI is a separate project.
But in time I hope the JTSK is split up in individual pieces that will
evolve each on their own pace, I really don't have a clue however at
what time during the project this should happen.
> If the projects are truly separate in release schedules, that argues for
> separate high level projects, as 2). It's easy to release one project at
> a time but harder to coordinate releasing multiple projects simultaneously.
This is what I'm aiming for.
--
Mark
Re: [PROPOSAL] Source drop and bug database
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jan 4, 2007, at 10:23 AM, Mark Brouwer wrote:
> This also raises a question, how are we going to manage all this. From
> SVN I get the impression the website is a separate branch in the
> repository, but do we have to check-in all 'subprojects' into one
> trunk.
The way I use the term, a branch is a copy of a trunk that has the
same content structure and much of the same contents, with some
changes here and there. So if you want to work on a disruptive
feature, you can branch the trunk, iterate until it all works,
leaving the trunk buildable, and after the branch is complete, merge
it to the trunk. You can then delete the branch if you have no
further use for it.
You can also branch for a release. Development continues on the trunk
and changes needed to stabilize the release are checked into the
branch. Also, artifacts are changed in the branch to reflect the
release number of the release. After release, both branch and trunk
continue to exist.
>
> In the end I hope the River project becomes a TLP with various
> subprojects such as core, lus implementation, javaspaces
> implementation,
> etc.. Each with their own release schedule. Dumping everything in one
> trunk doesn't seem very handy to me, but as I already mentioned I'm an
> SVN infant so maybe this works out well. Anyone?
I don't think it matters much whether you have a structure like:
1)
trunk/
core/
javaspaces/
lus
or
2)
core/
trunk/
javaspaces/
trunk/
lus/
trunk/
If you release a number of related things together, that argues for a
common trunk, as 1).
If the projects are truly separate in release schedules, that argues
for separate high level projects, as 2). It's easy to release one
project at a time but harder to coordinate releasing multiple
projects simultaneously.
Craig
> --
> Mark
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: [PROPOSAL] Source drop and bug database
Posted by Mark Brouwer <ma...@cheiron.org>.
Jim Hurley wrote:
> Way back when :-) under the SCSL, something similar
> was named the "Technology Compatibility Kit" (TCK) and
> was a legal measure for helping to ensure compliance for
> commercial implementations.
>
> I think some people have found it generally handy over
> time to use to test their Jini service, etc -- so it might be
> good to include.
>
> Thoughts?
I don't use it anymore, I rely on the utilities to do their work or on a
container, but I see value in having it. But I think it is better to
introduce it after the project has started, just to prevent from overload.
This also raises a question, how are we going to manage all this. From
SVN I get the impression the website is a separate branch in the
repository, but do we have to check-in all 'subprojects' into one trunk.
In the end I hope the River project becomes a TLP with various
subprojects such as core, lus implementation, javaspaces implementation,
etc.. Each with their own release schedule. Dumping everything in one
trunk doesn't seem very handy to me, but as I already mentioned I'm an
SVN infant so maybe this works out well. Anyone?
--
Mark
Re: [PROPOSAL] Source drop and bug database
Posted by Jim Hurley <Ji...@Sun.COM>.
Another piece we should probably consider as part of
the initial codebase (or maybe to include down the line)
is the "Jini Technology Lookup, Discovery, and Join
Compatibility Kit" (LDJ). You can find it under "Associated
Downloads" at:
<https://starterkit.dev.java.net/downloads/index.html>
Way back when :-) under the SCSL, something similar
was named the "Technology Compatibility Kit" (TCK) and
was a legal measure for helping to ensure compliance for
commercial implementations.
I think some people have found it generally handy over
time to use to test their Jini service, etc -- so it might be
good to include.
Thoughts?
-Jim
Re: [PROPOSAL] Source drop and bug database
Posted by Mark Brouwer <ma...@cheiron.org>.
Jim Hurley wrote:
> We did have to touch on this in our project proposal (see:
> <http://wiki.apache.org/incubator/RiverProposal>, "(2) identify
> the initial source from with the project is to be populated". We
> had identified the Starter Kit (and link to the latest published
> version). Although we did not explicitly state v2.1, it was certainly
> meant to be implied that it would be the latest published version.
>
> We also identified ServiceUI and a link to the latest published
> version (v1.1a).
>
> Finally, we identified the QATests project, which contained the
> tests and harness we used for testing releases of the Starter Kit.
You are right.
>> 4) Outstanding issues against JTSK version 2.1.1
>
> I'm not sure of the logistics for getting issues moved from our
> internal system to JIRA, but it's something we'll need to look
> at relatively soon. We certainly want and expect to get the major
> issues we have logged moved over.
JIRA supports various type of imports see
http://www.atlassian.com/software/jira/docs/v3.7.1/, but the list of
public open issues for Jini is 206 in the Sun bug database. It might be
faster to do it by hand as that will also allow you to assign it to
proper components, and to the type of levels we might decide upon. You
can even play with the text decoration features so you can make
beautiful bugs ;-)
--
Mark
Re: [PROPOSAL] Source drop and bug database
Posted by Bill Venners <bv...@artima.com>.
Hi Jim,
>> 1) ServiceUI version 1.1a
>>
I'll submit it.
>> 2) Outstanding issues, if any, against ServiceUI version 1.1a
>
> Bill - if you have any substantive issues (logged, or just scribbled
> on a notepad), I agree that it would be good to seed the incubator
> project JIRA with them.
>
I don't know of any issues, other than a desire expressed by a few to
do a new version.
Bill
----
Bill Venners
President
Artima, Inc.
http://www.artima.com
Re: [PROPOSAL] Source drop and bug database
Posted by Jim Hurley <Ji...@Sun.COM>.
Hi Mark-
Thanks for getting this discussion going.
On Jan 4, 2007, at 4:13 AM, Mark Brouwer wrote:
> Hi all,
>
> The first step before we really can get started is the initial source
> drop by Sun and Artima. While it feels rude to initiate this by me, I
> think it is worth having a discussion about what gets dropped. I hope,
> but please correct me if I'm wrong, the fastest way to get this
> done is
> by stating my opinion as a proposal.
>
> Below you will find my proposal as to what I would like to see become
> the baseline from where the River project should start following the
> roadmap we have to craft.
We did have to touch on this in our project proposal (see:
<http://wiki.apache.org/incubator/RiverProposal>, "(2) identify
the initial source from with the project is to be populated". We
had identified the Starter Kit (and link to the latest published
version). Although we did not explicitly state v2.1, it was certainly
meant to be implied that it would be the latest published version.
We also identified ServiceUI and a link to the latest published
version (v1.1a).
Finally, we identified the QATests project, which contained the
tests and harness we used for testing releases of the Starter Kit.
> 1) ServiceUI version 1.1a
>
> 2) Outstanding issues, if any, against ServiceUI version 1.1a
Bill - if you have any substantive issues (logged, or just scribbled
on a notepad), I agree that it would be good to seed the incubator
project JIRA with them.
> 3) JTSK code version 2.1.1 [1], all parts which Sun can transfer to
> the
> ASF, even the code we will likely remove [2] according to the
> roadmap
>
> 4) Outstanding issues against JTSK version 2.1.1
I'm not sure of the logistics for getting issues moved from our
internal system to JIRA, but it's something we'll need to look
at relatively soon. We certainly want and expect to get the major
issues we have logged moved over.
> [1] my main motivation for bringing in the latest public version of
> the
> JTSK and not a newer version is that many people are familiar with
> 2.1.1
> and it will be this version that people have patches against that are
> not yet incorporated by Sun. Also I think the integration of the code
> modifications between the main/internal version branch of Sun and
> version 2.1.1 will be a good exercise for the initial committers and
> those interested in becoming one to get acquainted with the process
> 'in
> place'.
We're definitely in sync on this one.
> [2] I realize 'what to be left out' has been questioned in the Jini
> community, but I can't recall there was a conclusion. Therefore to
> me it
> seems to make sense to have that discussion here, in the hope it
> can be
> swift.
There have been various, mixed, and interesting discussions on
what should or should not be included from the Starter Kit. To my
mind there were never any conclusions (or consensus) reached and
our plan was to move over the Starter Kit (sans 3rd party code - only
the installer as far as I know) and have the discussion as part of
incubating at Apache.
> --
> Mark
-Jim