You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/04/27 11:00:22 UTC

[VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

We have all the docs for HARMONY-114 and they are in SVN

Please vote to accept or reject this codebase into the Apache Harmony 
class library :

[ ] + 1 Accept
[ ] -1 Reject  (provide reason below)

Lets let this run 3 days unless a) someone states they need more time or 
b) we get all committer votes before then.

Go...

geir



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Mikhail Loenko <ml...@gmail.com>.
+1

Mikhail

2006/4/27, Geir Magnusson Jr <ge...@pobox.com>:
> We have all the docs for HARMONY-114 and they are in SVN
>
> Please vote to accept or reject this codebase into the Apache Harmony
> class library :
>
> [ ] + 1 Accept
> [ ] -1 Reject  (provide reason below)
>
> Lets let this run 3 days unless a) someone states they need more time or
> b) we get all committer votes before then.
>
> Go...
>
> geir
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Archie Cobbs <ar...@dellroad.org>.
Archie Cobbs wrote:
>> Classpath?  The assumption here is that you don't need to have GNU 
>> Classpath, right?
> 
> Argh, my apologies, for some reason I was thinking completely backwards.
> Ignore most of what I said :-)

OK now I remember why I thought that before: if you're going to be using
JVM X which is designed for Classpath, then most likely you're going to
have Classpath installed if you have JVM X installed. So, you might as
well take advantage of it.

That was the idea anyway. But I agree, it's not worth the added
dependency. The only downside of not doing it that way is that it
becomes slightly harder to maintain compatibility (because e.g.,
the adapater's VMFoo API classes will have to manually track changes in
Classpath's VMFoo API). But the VMFoo API is fairly stable now anyway
so this shouldn't be a huge problem.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Archie Cobbs <ar...@dellroad.org>.
Geir Magnusson Jr wrote:
>> I agree. How about "classlibadapter/trunk" -> "adapter/gnu/trunk"?
> 
> I'd keep it specific to classlib yet simple and mimic the classlib 
> structure with
> 
>    classlibadapter/trunk/module/gnu
> 
> or something.

OK... although I'm not sure what purpose the "module" part serves.
We can of course always insert it later.

>> Now next questions... let's talk about how we want to build and
>> package this. It looks like basically we need to build two things,
>> (a) a ZIP/JAR file containing the adapter classes, and (b) a native
>> libarary for java.io.File.
>>
>> #1. It's possible to get rid of (b) because Classpath already contains
>>     native libraries that implement java.io.File functionality.
> 
> Classpath?  The assumption here is that you don't need to have GNU 
> Classpath, right?

Argh, my apologies, for some reason I was thinking completely backwards.
Ignore most of what I said :-)

We don't need Classpath to build and it won't be available at runtime
of course. We could do that, but then that kindof defeats the whole
purpose... I think I was imagining this on my laptop which has Classpath
but that would be a special case...

We will be providing VMFoo classes that define the same API to the
VM that Classpath does. Essentially we'll have replacements for all of
Classpath's vm/reference classes, plus the glue that goes on top of
that to hook it all up to classlib.

Hope that makes more sense...

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Archie Cobbs wrote:
> Weldon Washburn wrote:
>> Thanks for getting this entered into SVN so quickly.  I did a quick
>> check and it looks like you grabbed the most recent version.  By the
>> way, the directory structure is still somewhat ambiguous.  I keep
>> thinking we may want to put .../gnu.../... in the tree to distinguish
>> this specific adapter.   The reason is that someday someone may want
>> to build an adapter for a non-GNU class library.  It would be nice to
>> get this kind of directory organization sorted out now.  Making mods
>> to the directory structure at a later date probably means hardcoded
>> makefiles will need to be changed.
> 
> I agree. How about "classlibadapter/trunk" -> "adapter/gnu/trunk"?

I'd keep it specific to classlib yet simple and mimic the classlib 
structure with

    classlibadapter/trunk/module/gnu

or something.

> 
> Now next questions... let's talk about how we want to build and
> package this. It looks like basically we need to build two things,
> (a) a ZIP/JAR file containing the adapter classes, and (b) a native
> libarary for java.io.File.
> 
> #1. It's possible to get rid of (b) because Classpath already contains
>     native libraries that implement java.io.File functionality.

Classpath?  The assumption here is that you don't need to have GNU 
Classpath, right?

  However,
>     because classlib has native methods in java.io.File (instead of VMFile
>     adapter classes) this would mean writing our own File implementation,
>     which would involve copying (and tracking changes to) the classlib
>     version, so this is probably not a good option. For now, we'll leave
>     it as is but that's an option that's out there. Perhaps eventually
>     we can get classlib to either add a VMFile class or else implement
>     java.io.File itself... any thoughts from classlib hackers?
> 
> #2. Should the build just produce a distribution subtree in dist/ similar
>     to the way classlib builds, or should it use automake, etc. and
>     support a "make install" target? I'd prefer the latter. That way we
>     can have a standard install location, e.g. we'd install under
>     /usr/local/harmony/adapter/gnu or something. This would faciliate
>     VM's that want to make it easy to use the adapter because it would
>     always be in a known location. If you like this idea then I can add
>     all the configure and automake magic, replacing the "doit.sh" scripts.
>     This will aid portability as well, especially because we can use
>     libtool for #1. The auto* stuff should be simple because we won't
>     be doing anything very unusual.

Whoa.  Does GNU Classpath install into /usr/local/whatever?

I think you don't want to assume an install location...

> 
> #3. I think we'll need to have Classpath installed to do the build.  

GNU Classpath?  Why?

>     It's standard location is /usr/local/classpath. That way we can
>     compile our adapter classes with javac against all the VMFoo classes
>     that they will delegate to. I can add a "--with-classpath=DIR" flag
>     to ./configure to make this location configurable.

I'm missing something - the idea here is that GNU Classpath isn't 
nearby, isn't it?

geir

> 
> Let me know what you think.
> 
> -Archie
> 
> __________________________________________________________________________
> Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Archie Cobbs <ar...@dellroad.org>.
Weldon Washburn wrote:
> Thanks for getting this entered into SVN so quickly.  I did a quick
> check and it looks like you grabbed the most recent version.  By the
> way, the directory structure is still somewhat ambiguous.  I keep
> thinking we may want to put .../gnu.../... in the tree to distinguish
> this specific adapter.   The reason is that someday someone may want
> to build an adapter for a non-GNU class library.  It would be nice to
> get this kind of directory organization sorted out now.  Making mods
> to the directory structure at a later date probably means hardcoded
> makefiles will need to be changed.

I agree. How about "classlibadapter/trunk" -> "adapter/gnu/trunk"?

Now next questions... let's talk about how we want to build and
package this. It looks like basically we need to build two things,
(a) a ZIP/JAR file containing the adapter classes, and (b) a native
libarary for java.io.File.

#1. It's possible to get rid of (b) because Classpath already contains
     native libraries that implement java.io.File functionality. However,
     because classlib has native methods in java.io.File (instead of VMFile
     adapter classes) this would mean writing our own File implementation,
     which would involve copying (and tracking changes to) the classlib
     version, so this is probably not a good option. For now, we'll leave
     it as is but that's an option that's out there. Perhaps eventually
     we can get classlib to either add a VMFile class or else implement
     java.io.File itself... any thoughts from classlib hackers?

#2. Should the build just produce a distribution subtree in dist/ similar
     to the way classlib builds, or should it use automake, etc. and
     support a "make install" target? I'd prefer the latter. That way we
     can have a standard install location, e.g. we'd install under
     /usr/local/harmony/adapter/gnu or something. This would faciliate
     VM's that want to make it easy to use the adapter because it would
     always be in a known location. If you like this idea then I can add
     all the configure and automake magic, replacing the "doit.sh" scripts.
     This will aid portability as well, especially because we can use
     libtool for #1. The auto* stuff should be simple because we won't
     be doing anything very unusual.

#3. I think we'll need to have Classpath installed to do the build.
     It's standard location is /usr/local/classpath. That way we can
     compile our adapter classes with javac against all the VMFoo classes
     that they will delegate to. I can add a "--with-classpath=DIR" flag
     to ./configure to make this location configurable.

Let me know what you think.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Weldon Washburn <we...@gmail.com>.
Archie,
Thanks for getting this entered into SVN so quickly.  I did a quick
check and it looks like you grabbed the most recent version.  By the
way, the directory structure is still somewhat ambiguous.  I keep
thinking we may want to put .../gnu.../... in the tree to distinguish
this specific adapter.   The reason is that someday someone may want
to build an adapter for a non-GNU class library.  It would be nice to
get this kind of directory organization sorted out now.  Making mods
to the directory structure at a later date probably means hardcoded
makefiles will need to be changed.

On 5/1/06, Archie Cobbs <ar...@dellroad.org> wrote:
> Geir Magnusson Jr wrote:
> > We have 9 votes in favor, none against, and one reasonable question
> > about destination.
> >
> > I think that we should let Archie bring it into SVN. :)  It was
> > suggested as
> >
> >          enhanced/gnuclasspathadapter/trunk/
> >
> > but I'd suggest
> >
> >          enhanced/classlibadapter/trunk/
> >
> > to make it generic, because ya never know - there could be other VMs out
> > there for which we might make an adapter to the Apache Harmony clsaslib ;)
> >
> > So far, we work with IBMs VM directly, soon any GNU Classpath capable
> > VM, and maybe......
> >
> > Archie, please do "as is" in the zip file and then cleanup from there
> > for traceable accountability.  Thx
>
> Done.. r398726.
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


--
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Archie Cobbs <ar...@dellroad.org>.
Geir Magnusson Jr wrote:
> We have 9 votes in favor, none against, and one reasonable question 
> about destination.
> 
> I think that we should let Archie bring it into SVN. :)  It was 
> suggested as
> 
>          enhanced/gnuclasspathadapter/trunk/
> 
> but I'd suggest
> 
>          enhanced/classlibadapter/trunk/
> 
> to make it generic, because ya never know - there could be other VMs out 
> there for which we might make an adapter to the Apache Harmony clsaslib ;)
> 
> So far, we work with IBMs VM directly, soon any GNU Classpath capable 
> VM, and maybe......
> 
> Archie, please do "as is" in the zip file and then cleanup from there 
> for traceable accountability.  Thx

Done.. r398726.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Weldon Washburn wrote:

> Since all the old JIRA bug reports are closed, I will open a new bug
> report as I develop the code.  Should each new update be a seperate
> JIRA bug report or should all up dates be posted to one, single bug
> report?

Separate.

geir

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Weldon Washburn <we...@gmail.com>.
On 5/3/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Weldon Washburn wrote:
> > Geir,
> >
> > Two things:
> >
> > 1)
> > We forgot one more JIRA bug report --- 192.  Please also close 192.
> > Sorry for not catching this earlier
>
> Is there code there that needs to come into SVN.

It looks like Archie took the correct zip file from JIRA and checked
it into svn.  There is no additional JIRA code at this time that needs
to be put in svn.

>
>
> >
> > 2)
> > The current path sorta, kinda looks like I continue filing new JIRA
> > bug reports as I make progress on gnuclasspath.  I don't have svn
> > checkin permission.
>
> Yes, we know :)

Since all the old JIRA bug reports are closed, I will open a new bug
report as I develop the code.  Should each new update be a seperate
JIRA bug report or should all up dates be posted to one, single bug
report?


>
> geir
>
> >
> >    Weldon
> >
> >
> > On 5/2/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >> I believe that this is sufficient.   Thanks.
> >>
> >> If this is acceptable to others, we should then note this in 114 and
> >> 318, and close them both.
> >>
> >> geir
> >>
> >>
> >> Weldon Washburn wrote:
> >> > Sorry.  Its all my fault.  I was distracted by the JIRA user interface
> >> > and entered a new bug report (318) when I should have updated my old
> >> > bug report (114).  All my updates are posted to 318.
> >> >
> >> > Would it help if I closed 114?  Or put a note that follow-on is
> >> > actually posted to 318?
> >> >
> >> > On 5/2/06, Tim Ellison <t....@gmail.com> wrote:
> >> >> Geir Magnusson Jr wrote:
> >> >> >
> >> >> >
> >> >> > Tim Ellison wrote:
> >> >> >
> >> >> >>
> >> >> >> I'm confused, we voted on HARMONY-114 and committed
> >> HARMONY-318?  If
> >> >> >> nothing else that is not very traceable.
> >> >> >>
> >> >> >> Does the BCC that applies to HARMONY-114 also apply to -318?
> >> >> >
> >> >> > Excellent catch. (Many eyes...)  Also, the JIRA status were not
> >> changed
> >> >> > either.
> >> >> >
> >> >> > I guess there's a question here - can we consider HARMONY-318 a
> >> >> > derivative work of -114?  If so, I'm satisfied wrt process docs...
> >> >>
> >> >> That's for Weldon to say of course.  If he can make that assurance
> >> then
> >> >> I would consider the difference between 318 and 114 as simply work
> >> >> conduced as part of the project.
> >> >>
> >> >> Regards,
> >> >> Tim
> >> >>
> >> >> --
> >> >>
> >> >> Tim Ellison (t.p.ellison@gmail.com)
> >> >> IBM Java technology centre, UK.
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Weldon Washburn
> >> > Intel Middleware Products Division
> >> >
> >> > ---------------------------------------------------------------------
> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> >
> > --
> > Weldon Washburn
> > Intel Middleware Products Division
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


--
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Weldon Washburn wrote:
> Geir,
> 
> Two things:
> 
> 1)
> We forgot one more JIRA bug report --- 192.  Please also close 192. 
> Sorry for not catching this earlier

Is there code there that needs to come into SVN.


> 
> 2)
> The current path sorta, kinda looks like I continue filing new JIRA
> bug reports as I make progress on gnuclasspath.  I don't have svn
> checkin permission.

Yes, we know :)

geir

> 
>    Weldon
> 
> 
> On 5/2/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> I believe that this is sufficient.   Thanks.
>>
>> If this is acceptable to others, we should then note this in 114 and
>> 318, and close them both.
>>
>> geir
>>
>>
>> Weldon Washburn wrote:
>> > Sorry.  Its all my fault.  I was distracted by the JIRA user interface
>> > and entered a new bug report (318) when I should have updated my old
>> > bug report (114).  All my updates are posted to 318.
>> >
>> > Would it help if I closed 114?  Or put a note that follow-on is
>> > actually posted to 318?
>> >
>> > On 5/2/06, Tim Ellison <t....@gmail.com> wrote:
>> >> Geir Magnusson Jr wrote:
>> >> >
>> >> >
>> >> > Tim Ellison wrote:
>> >> >
>> >> >>
>> >> >> I'm confused, we voted on HARMONY-114 and committed 
>> HARMONY-318?  If
>> >> >> nothing else that is not very traceable.
>> >> >>
>> >> >> Does the BCC that applies to HARMONY-114 also apply to -318?
>> >> >
>> >> > Excellent catch. (Many eyes...)  Also, the JIRA status were not 
>> changed
>> >> > either.
>> >> >
>> >> > I guess there's a question here - can we consider HARMONY-318 a
>> >> > derivative work of -114?  If so, I'm satisfied wrt process docs...
>> >>
>> >> That's for Weldon to say of course.  If he can make that assurance 
>> then
>> >> I would consider the difference between 318 and 114 as simply work
>> >> conduced as part of the project.
>> >>
>> >> Regards,
>> >> Tim
>> >>
>> >> --
>> >>
>> >> Tim Ellison (t.p.ellison@gmail.com)
>> >> IBM Java technology centre, UK.
>> >>
>> >> ---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Weldon Washburn
>> > Intel Middleware Products Division
>> >
>> > ---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 
> 
> -- 
> Weldon Washburn
> Intel Middleware Products Division
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Weldon Washburn <we...@gmail.com>.
Geir,

Two things:

1)
We forgot one more JIRA bug report --- 192.  Please also close 192. 
Sorry for not catching this earlier

2)
The current path sorta, kinda looks like I continue filing new JIRA
bug reports as I make progress on gnuclasspath.  I don't have svn
checkin permission.

    Weldon


On 5/2/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> I believe that this is sufficient.   Thanks.
>
> If this is acceptable to others, we should then note this in 114 and
> 318, and close them both.
>
> geir
>
>
> Weldon Washburn wrote:
> > Sorry.  Its all my fault.  I was distracted by the JIRA user interface
> > and entered a new bug report (318) when I should have updated my old
> > bug report (114).  All my updates are posted to 318.
> >
> > Would it help if I closed 114?  Or put a note that follow-on is
> > actually posted to 318?
> >
> > On 5/2/06, Tim Ellison <t....@gmail.com> wrote:
> >> Geir Magnusson Jr wrote:
> >> >
> >> >
> >> > Tim Ellison wrote:
> >> >
> >> >>
> >> >> I'm confused, we voted on HARMONY-114 and committed HARMONY-318?  If
> >> >> nothing else that is not very traceable.
> >> >>
> >> >> Does the BCC that applies to HARMONY-114 also apply to -318?
> >> >
> >> > Excellent catch. (Many eyes...)  Also, the JIRA status were not changed
> >> > either.
> >> >
> >> > I guess there's a question here - can we consider HARMONY-318 a
> >> > derivative work of -114?  If so, I'm satisfied wrt process docs...
> >>
> >> That's for Weldon to say of course.  If he can make that assurance then
> >> I would consider the difference between 318 and 114 as simply work
> >> conduced as part of the project.
> >>
> >> Regards,
> >> Tim
> >>
> >> --
> >>
> >> Tim Ellison (t.p.ellison@gmail.com)
> >> IBM Java technology centre, UK.
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> >
> > --
> > Weldon Washburn
> > Intel Middleware Products Division
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


--
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Geir Magnusson Jr <ge...@pobox.com>.
I believe that this is sufficient.   Thanks.

If this is acceptable to others, we should then note this in 114 and 
318, and close them both.

geir


Weldon Washburn wrote:
> Sorry.  Its all my fault.  I was distracted by the JIRA user interface
> and entered a new bug report (318) when I should have updated my old
> bug report (114).  All my updates are posted to 318.
> 
> Would it help if I closed 114?  Or put a note that follow-on is
> actually posted to 318?
> 
> On 5/2/06, Tim Ellison <t....@gmail.com> wrote:
>> Geir Magnusson Jr wrote:
>> >
>> >
>> > Tim Ellison wrote:
>> >
>> >>
>> >> I'm confused, we voted on HARMONY-114 and committed HARMONY-318?  If
>> >> nothing else that is not very traceable.
>> >>
>> >> Does the BCC that applies to HARMONY-114 also apply to -318?
>> >
>> > Excellent catch. (Many eyes...)  Also, the JIRA status were not changed
>> > either.
>> >
>> > I guess there's a question here - can we consider HARMONY-318 a
>> > derivative work of -114?  If so, I'm satisfied wrt process docs...
>>
>> That's for Weldon to say of course.  If he can make that assurance then
>> I would consider the difference between 318 and 114 as simply work
>> conduced as part of the project.
>>
>> Regards,
>> Tim
>>
>> -- 
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 
> 
> -- 
> Weldon Washburn
> Intel Middleware Products Division
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Weldon Washburn <we...@gmail.com>.
Sorry.  Its all my fault.  I was distracted by the JIRA user interface
and entered a new bug report (318) when I should have updated my old
bug report (114).  All my updates are posted to 318.

 Would it help if I closed 114?  Or put a note that follow-on is
actually posted to 318?

On 5/2/06, Tim Ellison <t....@gmail.com> wrote:
> Geir Magnusson Jr wrote:
> >
> >
> > Tim Ellison wrote:
> >
> >>
> >> I'm confused, we voted on HARMONY-114 and committed HARMONY-318?  If
> >> nothing else that is not very traceable.
> >>
> >> Does the BCC that applies to HARMONY-114 also apply to -318?
> >
> > Excellent catch. (Many eyes...)  Also, the JIRA status were not changed
> > either.
> >
> > I guess there's a question here - can we consider HARMONY-318 a
> > derivative work of -114?  If so, I'm satisfied wrt process docs...
>
> That's for Weldon to say of course.  If he can make that assurance then
> I would consider the difference between 318 and 114 as simply work
> conduced as part of the project.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


--
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> 
> 
> Tim Ellison wrote:
> 
>>
>> I'm confused, we voted on HARMONY-114 and committed HARMONY-318?  If
>> nothing else that is not very traceable.
>>
>> Does the BCC that applies to HARMONY-114 also apply to -318?
> 
> Excellent catch. (Many eyes...)  Also, the JIRA status were not changed
> either.
> 
> I guess there's a question here - can we consider HARMONY-318 a
> derivative work of -114?  If so, I'm satisfied wrt process docs...

That's for Weldon to say of course.  If he can make that assurance then
I would consider the difference between 318 and 114 as simply work
conduced as part of the project.

Regards,
Tim

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Tim Ellison wrote:

> 
> I'm confused, we voted on HARMONY-114 and committed HARMONY-318?  If
> nothing else that is not very traceable.
> 
> Does the BCC that applies to HARMONY-114 also apply to -318?

Excellent catch. (Many eyes...)  Also, the JIRA status were not changed 
either.

I guess there's a question here - can we consider HARMONY-318 a 
derivative work of -114?  If so, I'm satisfied wrt process docs...

?

geir


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> We have 9 votes in favor, none against, and one reasonable question
>> about destination.
>>
>> I think that we should let Archie bring it into SVN. :)  It was
>> suggested as
>>
>>          enhanced/gnuclasspathadapter/trunk/
>>
>> but I'd suggest
>>
>>          enhanced/classlibadapter/trunk/
>>
>> to make it generic, because ya never know - there could be other VMs out
>> there for which we might make an adapter to the Apache Harmony clsaslib ;)
> 
> Just for the record, I believe we should aim to minimize the creation of
> more 'VM to class library' interfaces.  The GNU Classpath interface is
> important because historically that has been the only one meaningful to
> open source VMs.  The Harmony VMI is arguably a compatible superset of
> that; we don't want to encourage a third and fourth interface that are
> different again.

What about helio-centric legacy interfaces?  :D

geir

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> We have 9 votes in favor, none against, and one reasonable question
> about destination.
> 
> I think that we should let Archie bring it into SVN. :)  It was
> suggested as
> 
>          enhanced/gnuclasspathadapter/trunk/
> 
> but I'd suggest
> 
>          enhanced/classlibadapter/trunk/
> 
> to make it generic, because ya never know - there could be other VMs out
> there for which we might make an adapter to the Apache Harmony clsaslib ;)

Just for the record, I believe we should aim to minimize the creation of
more 'VM to class library' interfaces.  The GNU Classpath interface is
important because historically that has been the only one meaningful to
open source VMs.  The Harmony VMI is arguably a compatible superset of
that; we don't want to encourage a third and fourth interface that are
different again.

> So far, we work with IBMs VM directly, soon any GNU Classpath capable
> VM, and maybe......
> 
> Archie, please do "as is" in the zip file and then cleanup from there
> for traceable accountability.  Thx

I'm confused, we voted on HARMONY-114 and committed HARMONY-318?  If
nothing else that is not very traceable.

Does the BCC that applies to HARMONY-114 also apply to -318?

Regards,
Tim

> geir
> 
> 
> Geir Magnusson Jr wrote:
>> We have all the docs for HARMONY-114 and they are in SVN
>>
>> Please vote to accept or reject this codebase into the Apache Harmony
>> class library :
>>
>> [ ] + 1 Accept
>> [ ] -1 Reject  (provide reason below)
>>
>> Lets let this run 3 days unless a) someone states they need more time
>> or b) we get all committer votes before then.
>>
>> Go...
>>
>> geir
>>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


[RESULT] Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Geir Magnusson Jr <ge...@pobox.com>.
We have 9 votes in favor, none against, and one reasonable question 
about destination.

I think that we should let Archie bring it into SVN. :)  It was 
suggested as

          enhanced/gnuclasspathadapter/trunk/

but I'd suggest

          enhanced/classlibadapter/trunk/

to make it generic, because ya never know - there could be other VMs out 
there for which we might make an adapter to the Apache Harmony clsaslib ;)

So far, we work with IBMs VM directly, soon any GNU Classpath capable 
VM, and maybe......

Archie, please do "as is" in the zip file and then cleanup from there 
for traceable accountability.  Thx

geir


Geir Magnusson Jr wrote:
> We have all the docs for HARMONY-114 and they are in SVN
> 
> Please vote to accept or reject this codebase into the Apache Harmony 
> class library :
> 
> [ ] + 1 Accept
> [ ] -1 Reject  (provide reason below)
> 
> Lets let this run 3 days unless a) someone states they need more time or 
> b) we get all committer votes before then.
> 
> Go...
> 
> geir
> 
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by George Harley <ge...@googlemail.com>.
+1

George


Geir Magnusson Jr wrote:
> We have all the docs for HARMONY-114 and they are in SVN
>
> Please vote to accept or reject this codebase into the Apache Harmony 
> class library :
>
> [ ] + 1 Accept
> [ ] -1 Reject  (provide reason below)
>
> Lets let this run 3 days unless a) someone states they need more time 
> or b) we get all committer votes before then.
>
> Go...
>
> geir
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Geir Magnusson Jr <ge...@pobox.com>.
+1 from me

Geir Magnusson Jr wrote:
> We have all the docs for HARMONY-114 and they are in SVN
> 
> Please vote to accept or reject this codebase into the Apache Harmony 
> class library :
> 
> [ ] + 1 Accept
> [ ] -1 Reject  (provide reason below)
> 
> Lets let this run 3 days unless a) someone states they need more time or 
> b) we get all committer votes before then.
> 
> Go...
> 
> geir
> 
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Stepan Mishura <st...@gmail.com>.
+1

-Stepan.


On 4/27/06, Geir Magnusson Jr wrote:
>
> We have all the docs for HARMONY-114 and they are in SVN
>
> Please vote to accept or reject this codebase into the Apache Harmony
> class library :
>
> [ ] + 1 Accept
> [ ] -1 Reject  (provide reason below)
>
> Lets let this run 3 days unless a) someone states they need more time or
> b) we get all committer votes before then.
>
> Go...
>
> geir
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


--
Thanks,
Stepan Mishura
Intel Middleware Products Division

------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Archie Cobbs <ar...@dellroad.org>.
Geir Magnusson Jr wrote:
> We have all the docs for HARMONY-114 and they are in SVN
> 
> Please vote to accept or reject this codebase into the Apache Harmony 
> class library :

+1 from me. I think it should probably be a separate (peer) project
from JCHEVM and classlib, e.g., under harmony/enhanced.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Tim Ellison <t....@gmail.com>.
+1

Tim

Geir Magnusson Jr wrote:
> We have all the docs for HARMONY-114 and they are in SVN
> 
> Please vote to accept or reject this codebase into the Apache Harmony
> class library :
> 
> [ ] + 1 Accept
> [ ] -1 Reject  (provide reason below)
> 
> Lets let this run 3 days unless a) someone states they need more time or
> b) we get all committer votes before then.
> 
> Go...
> 
> geir
> 
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


RE: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue Harmony Class Lib to JCHEVM native methods

Posted by Nathan Beyer <nb...@kc.rr.com>.
+1

> -----Original Message-----
> From: Geir Magnusson Jr [mailto:geir@pobox.com]
> Sent: Thursday, April 27, 2006 3:00 AM
> To: harmony-dev@incubator.apache.org
> Subject: [VOTE] Acceptance of HARMONY-114 : rough draft of files that glue
> Harmony Class Lib to JCHEVM native methods
> 
> We have all the docs for HARMONY-114 and they are in SVN
> 
> Please vote to accept or reject this codebase into the Apache Harmony
> class library :
> 
> [ ] + 1 Accept
> [ ] -1 Reject  (provide reason below)
> 
> Lets let this run 3 days unless a) someone states they need more time or
> b) we get all committer votes before then.
> 
> Go...
> 
> geir
> 
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org