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/09/29 21:26:06 UTC
[general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Just renaming the thread....
On Sep 29, 2006, at 9:17 AM, Vladimir Ivanov wrote:
> today I tries to build and test one module with HDK. It almost works
> :). Small instruction to reproduce:
>
> 1) checkout trunk -N, make and modules/<beans> dirs. Note, <beans>/
> build.xml
> refers to some staff in the make dir. Also, the luni-kernel and
> security-kernel modules should be checkout to hide errors:
> trunk\modules\beans\build.xml:80: Excludesfile
> trunk\deploy\build\patternsets\luni-kernel.txt not found.
> and
> C:\tmp\tmp30\trunk\modules\beans\build.xml:80: Excludesfile
> trunk\deploy\build\patternsets\security-kernel.txt not found.
>
> 2) run something like "ant -Dhy.jdk=C:\harmony\hdk\jdk -
> Dbuild.module=beans"
> from the 'trunk' directory to copy patternsets to the deploy dir.
> Note, this
> command will be failed on the check-dependency task.
>
> 3) set CLASSPATH=junit.jar;hdk\build\test\support.jar
>
> 4) go to the module dir (modules/beans in my case). That's all:
> module ready
> to use. You can press: ant -Dhy.jdk=hdk\jdk clean/build/test. Note,
> actually, the beans.jar in the HDK will be updated. It is OK?
>
> To do in the build system:
> - remove dependency on the luni-kernel and security-kernel modules
> - add mode to rebuild module without HDK update (?)
> - add mode to run tests with build html-report for each module.
> - add mode to run all tests from tests.jar over HDK+ updated classes.
> - ?
>
> thanks, Vladimir
>
> On 9/28/06, Alexey Petrenko <al...@gmail.com> wrote:
>>
>> Good point. +1 from me.
>>
>> SY, Alexey
>>
>> 2006/9/27, Alexei Zakharov <al...@gmail.com>:
>> > If we plan to use HDK for supporting developers who work on single
>> > module (that is a good idea IMHO) then we definitely need to supply
>> > jar with tests. We may also supply the build file with placeholders
>> > for user classes & tests dirs that will be prepended to
>> > classpath/bootclasspath.
>> >
>> > Regards,
>> >
>> > 2006/9/27, Vladimir Ivanov <iv...@gmail.com>:
>> > > On 9/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > > >
>> > > >
>> > > >
>> > > > If I recall, the point of the test.jar was to have a pre-
>> built jar
>> of
>> > > > tests in the HDK so that someone could setup the build-test
>> infra
>> > > > using the HDK so they could run tests on their platform w/o
>> having
>> to
>> > > > build everything. Good idea.
>> > >
>> > >
>> > > Yes, you are correct. This idea implemented in the jira 964.
>> > >
>> > > If that's so, then something would
>> > > > have to be configured to have the classlib "test" target use
>> that
>> > > > jar. All I'm saying is that how we do this is important, as we
>> don't
>> > > > want to cause pain for classlib developers who use the HDK for
>> > > > development support.
>> > >
>> > >
>> > >
>> > > Seems, we think about different use cases.
>> > >
>> > > In my case, user can download the HDK for own platform (if we
>> have
>> one) run
>> > > tests and look on results (also, may be upload it to the harmony
>> site). Also
>> > > it can be used for application run to check 'enable' status.
>> But if
>> this
>> > > user interested in Harmony development he should checkout ws
>> and use
>> > > built-in ant targets to build and test updated ws.
>> > >
>> > >
>> > >
>> > > How you plan to use HDK? It looks like initial
>> miscommunication :)
>> > > thanks, Vladimir
>> > >
>> > >
>> > >
>> > > > geir
>> > > >
>> > > > >
>> > > > > Thanks, Vladimir
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >> > Thanks, Vladimir
>> > > > >> >
>> > > > >> > geir
>> > > > >> >>
>> > > > >> >> >
>> > > > >> >> >
>> > > > >> >> >
>> > > > >> >> > Thanks, Vladimir
>> > > > >> >> >
>> > > > >> >> >
>> > > > >> >> >
>> > > > >> >> > On 7/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> > > > >> >> >>
>> > > > >> >> >> They are at the regular place
>> > > > >> >> >>
>> > > > >> >> >> http://people.apache.org/dist/incubator/harmony/
>> snapshots
>> > > > >> >> >>
>> > > > >> >> >> I moved all the old classlib snapshots into /old
>> and I'll
>> > > > >> >> update the
>> > > > >> >> >> website accordingly. I'll be automating this.
>> Also, lets
>> not
>> > > > >> >> >> make much
>> > > > >> >> >> noise about this for a little while so we can test
>> to make
>> sure
>> > > > >> >> >> there's
>> > > > >> >> >> no major errors. Things seem good. I have a list
>> of more
>> > > > >> >> things to
>> > > > >> >> >> fix, but I realized today that I was obsessing over
>> the
>> > > > >> snapshot
>> > > > >> >> >> contents - it's not a release, and it's "good enough".
>> > > > >> >> >>
>> > > > >> >> >> I'd like to ditch both /old and the remaining classlib
>> > > > >> >> snapshots, as
>> > > > >> >> >>
>> > > > >> >> >> 1) they are snapshots - history doesn't matter
>> > > > >> >> >>
>> > > > >> >> >> 2) the classlib is now in the HDK, so we just need to
>> adjust
>> > > > >> the
>> > > > >> >> >> docs to
>> > > > >> >> >> match.
>> > > > >> >> >>
>> > > > >> >> >> I'll do the latter, but wanted to see if anyone has a
>> problem
>> > > > >> >> w/ me
>> > > > >> >> >> removing /old and the last classlib snapshot. I'll
>> do this
>> > > > >> if I
>> > > > >> >> >> don't
>> > > > >> >> >> hear any protest, so either positively acknowledge
>> this
>> action
>> > > > >> >> if you
>> > > > >> >> >> support it, dont' do a thing if you support or
>> dont' care,
>> > > > >> or say
>> > > > >> >> >> why we
>> > > > >> >> >> shouldn't :)
>> > > > >> >> >>
>> > > > >> >> >> 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
>> > > > >> >>
>> > > > >> >>
>> > > > >>
>> > > > >>
>> > > > >>
>> ---------------------------------------------------------------------
>> > > > >> 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
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> > --
>> > Alexei Zakharov,
>> > Intel Middleware Product 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
>> >
>> >
>>
>>
>> --
>> Alexey A. Petrenko
>> 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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Posted by Alexei Zakharov <al...@gmail.com>.
Egor,
HARMONY-1673 is filed. I've tried both "-Xem:opt" & "-Xem:jet".
Regards,
03 Oct 2006 00:06:16 +0700, Egor Pasko <eg...@gmail.com>:
> On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote:
> > The same result with the "-Xem:opt".
>
> Could you file a JIRA for that, please? With steps to
> reproduce. Please, also check with -Xem:jet.
>
> Thanks for pointing out failures like that.
>
> > The exact command in my
> > environment was (WinXP SP2):
> >
> > <==
> > C:\mydoc\projects\tests\beans2>echo %JAVA_HOME%
> > C:\Java\harmony-hdk-r450941\jdk\jre
> >
> > C:\mydoc\projects\tests\beans2>%JAVA_HOME%\bin\java
> > -Xbootclasspath/p:.\build\classes;.\build\tests;C:\Java\harmony\enhanced\classlib\trunk\depends\jars\junit_3.8.2\junit.jar
> > -Xem:opt junit.textui.TestRunner
> > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
> > ...
> > An unhandled error (4) has occurred.
> > HyGeneric_Signal_Number=00000004
> > ExceptionCode=c0000005
> > ExceptionAddress=0052A340
> > ContextFlags=0001003f
> > Handler1=00401010
> > Handler2=11105CE0
> > InaccessibleAddress=00000000
> > EDI=00000000
> > ESI=00000000
> > EAX=0013F1AC
> > EBX=00000000
> > ECX=007129FC
> > EDX=00000000
> > EIP=0052A340
> > ESP=0013F17C
> > EBP=00000000
> > Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll
> > Module_base_address=00510000
> > Offset_in_DLL=0001a340
> >
> > This application has requested the Runtime to terminate it in an unusual way.
> > Please contact the application's support team for more information.
> > <==
> >
> > Regards,
> >
> > 02 Oct 2006 20:14:11 +0700, Egor Pasko <eg...@gmail.com>:
> > > On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote:
> > > > Agree. In case somebody is interested:
> > > > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
> > > > (from bootclasspath), harmony-hdk-r450941, WinXP.
> > >
> > > Is that reproducible on Linux? how does it run on pure OPT (-Xem:opt),
> > > JET?
> > >
> > > > Crash info:
> > > >
> > > > <==
> > > > [junit] An unhandled error (4) has occurred.
> > > > [junit] HyGeneric_Signal_Number=00000004
> > > > [junit] ExceptionCode=c0000005
> > > > [junit] ExceptionAddress=0052A340
> > > > [junit] ContextFlags=0001003f
> > > > [junit] Handler1=00401010
> > > > [junit] Handler2=11105CE0
> > > > [junit] InaccessibleAddress=00000000
> > > > [junit] EDI=00000000
> > > > [junit] ESI=00000000
> > > > [junit] EAX=0013D69C
> > > > [junit] EBX=00000000
> > > > [junit] ECX=007129FC
> > > > [junit] EDX=00000000
> > > > [junit] EIP=0052A340
> > > > [junit] ESP=0013D66C
> > > > [junit] EBP=00000000
> > > > [junit] Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll
> > > > [junit] Module_base_address=00510000
> > > > [junit] Offset_in_DLL=0001a340
> > > > [junit] This application has requested the Runtime to terminate it
> > > > in an unusual way.
> > > > [junit] Please contact the application's support team for more information.
> > > > [junit] Test
> > > > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
> > > > FAILED
> > > > <==
> > > >
> > > > Thanks,
> > > >
> > > > 2006/10/2, Vladimir Ivanov <iv...@gmail.com>:
> > > > > On 10/2/06, Alexei Zakharov <al...@gmail.com> wrote:
> > > > > >
> > > > > >
> > > > > > Juist my two cents. Some test even from such a high-level module as
> > > > > > beans fail if they run from bootclasspath (BeansTest for example).
> > > > > > Moreover, they crash DRLVM :)
> > > > >
> > > > >
> > > > > Seems, it is should be evaluated by VM peoples. The vm crash is not good
> > > > > reaction for test failure.
> > > > > thanks, Vladimir
> > > > >
> > > > > BTW, personally I use custom-made build file to develop with HDK and
> > > > > > single-module checkout.
> >
> > --
> > Alexei Zakharov,
> > Intel Middleware Product 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
> >
> >
>
> --
> Egor Pasko, Intel Managed Runtime 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
>
>
--
Alexei Zakharov,
Intel Middleware Product 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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Posted by Alexei Zakharov <al...@gmail.com>.
> Wouldn't this be something nice to show people? :)
Well, it does not aligned with the current build system somehow, it
was just for my personal convenience. Build sources, build tests, run
all tests for the module (bootclasspath & classpath), run the single
test of your choice, run tests with TestNG, convert TestNG test
results with JUnitConverter and even preprocess sources with the
Velocity compiler in order to remove unnecessary logging. :-)
Of course I can share it, if somebody is interested. No problem.
Thanks,
2006/10/2, Geir Magnusson Jr. <ge...@pobox.com>:
>
>
> Alexei Zakharov wrote:
> > Hi,
> >
> > 2006/10/2, Vladimir Ivanov <iv...@gmail.com>:
> >> On 10/2/06, Mark Hindess <ma...@googlemail.com> wrote:
> >
> >> > I think we need more than one tests.jar. In fact, I think we need
> >> > more than one tests.jar per module since some tests need to be on the
> >> > bootclasspath while others do not (and should not). At the moment
> >> > it might be necessary to have more since there isn't really a way to
> >> > distinguish api/internal tests (this might change if/when we move to
> >> > testng).
> >>
> >> Almost all API tests can be run through the bootclasspath. May be we just
> >> waiting for something like TestNG (or other solution) and will create one
> >> test.jar for each module?
> >
> > Juist my two cents. Some test even from such a high-level module as
> > beans fail if they run from bootclasspath (BeansTest for example).
> > Moreover, they crash DRLVM :)
> >
> > BTW, personally I use custom-made build file to develop with HDK and
> > single-module checkout.
>
> Wouldn't this be something nice to show people? :)
--
Alexei Zakharov,
Intel Middleware Product 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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote:
> The same result with the "-Xem:opt".
Could you file a JIRA for that, please? With steps to
reproduce. Please, also check with -Xem:jet.
Thanks for pointing out failures like that.
> The exact command in my
> environment was (WinXP SP2):
>
> <==
> C:\mydoc\projects\tests\beans2>echo %JAVA_HOME%
> C:\Java\harmony-hdk-r450941\jdk\jre
>
> C:\mydoc\projects\tests\beans2>%JAVA_HOME%\bin\java
> -Xbootclasspath/p:.\build\classes;.\build\tests;C:\Java\harmony\enhanced\classlib\trunk\depends\jars\junit_3.8.2\junit.jar
> -Xem:opt junit.textui.TestRunner
> org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
> ...
> An unhandled error (4) has occurred.
> HyGeneric_Signal_Number=00000004
> ExceptionCode=c0000005
> ExceptionAddress=0052A340
> ContextFlags=0001003f
> Handler1=00401010
> Handler2=11105CE0
> InaccessibleAddress=00000000
> EDI=00000000
> ESI=00000000
> EAX=0013F1AC
> EBX=00000000
> ECX=007129FC
> EDX=00000000
> EIP=0052A340
> ESP=0013F17C
> EBP=00000000
> Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll
> Module_base_address=00510000
> Offset_in_DLL=0001a340
>
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
> <==
>
> Regards,
>
> 02 Oct 2006 20:14:11 +0700, Egor Pasko <eg...@gmail.com>:
> > On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote:
> > > Agree. In case somebody is interested:
> > > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
> > > (from bootclasspath), harmony-hdk-r450941, WinXP.
> >
> > Is that reproducible on Linux? how does it run on pure OPT (-Xem:opt),
> > JET?
> >
> > > Crash info:
> > >
> > > <==
> > > [junit] An unhandled error (4) has occurred.
> > > [junit] HyGeneric_Signal_Number=00000004
> > > [junit] ExceptionCode=c0000005
> > > [junit] ExceptionAddress=0052A340
> > > [junit] ContextFlags=0001003f
> > > [junit] Handler1=00401010
> > > [junit] Handler2=11105CE0
> > > [junit] InaccessibleAddress=00000000
> > > [junit] EDI=00000000
> > > [junit] ESI=00000000
> > > [junit] EAX=0013D69C
> > > [junit] EBX=00000000
> > > [junit] ECX=007129FC
> > > [junit] EDX=00000000
> > > [junit] EIP=0052A340
> > > [junit] ESP=0013D66C
> > > [junit] EBP=00000000
> > > [junit] Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll
> > > [junit] Module_base_address=00510000
> > > [junit] Offset_in_DLL=0001a340
> > > [junit] This application has requested the Runtime to terminate it
> > > in an unusual way.
> > > [junit] Please contact the application's support team for more information.
> > > [junit] Test
> > > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
> > > FAILED
> > > <==
> > >
> > > Thanks,
> > >
> > > 2006/10/2, Vladimir Ivanov <iv...@gmail.com>:
> > > > On 10/2/06, Alexei Zakharov <al...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > Juist my two cents. Some test even from such a high-level module as
> > > > > beans fail if they run from bootclasspath (BeansTest for example).
> > > > > Moreover, they crash DRLVM :)
> > > >
> > > >
> > > > Seems, it is should be evaluated by VM peoples. The vm crash is not good
> > > > reaction for test failure.
> > > > thanks, Vladimir
> > > >
> > > > BTW, personally I use custom-made build file to develop with HDK and
> > > > > single-module checkout.
>
> --
> Alexei Zakharov,
> Intel Middleware Product 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
>
>
--
Egor Pasko, Intel Managed Runtime 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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Posted by Alexei Zakharov <al...@gmail.com>.
The same result with the "-Xem:opt". The exact command in my
environment was (WinXP SP2):
<==
C:\mydoc\projects\tests\beans2>echo %JAVA_HOME%
C:\Java\harmony-hdk-r450941\jdk\jre
C:\mydoc\projects\tests\beans2>%JAVA_HOME%\bin\java
-Xbootclasspath/p:.\build\classes;.\build\tests;C:\Java\harmony\enhanced\classlib\trunk\depends\jars\junit_3.8.2\junit.jar
-Xem:opt junit.textui.TestRunner
org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
...
An unhandled error (4) has occurred.
HyGeneric_Signal_Number=00000004
ExceptionCode=c0000005
ExceptionAddress=0052A340
ContextFlags=0001003f
Handler1=00401010
Handler2=11105CE0
InaccessibleAddress=00000000
EDI=00000000
ESI=00000000
EAX=0013F1AC
EBX=00000000
ECX=007129FC
EDX=00000000
EIP=0052A340
ESP=0013F17C
EBP=00000000
Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll
Module_base_address=00510000
Offset_in_DLL=0001a340
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
<==
Regards,
02 Oct 2006 20:14:11 +0700, Egor Pasko <eg...@gmail.com>:
> On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote:
> > Agree. In case somebody is interested:
> > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
> > (from bootclasspath), harmony-hdk-r450941, WinXP.
>
> Is that reproducible on Linux? how does it run on pure OPT (-Xem:opt),
> JET?
>
> > Crash info:
> >
> > <==
> > [junit] An unhandled error (4) has occurred.
> > [junit] HyGeneric_Signal_Number=00000004
> > [junit] ExceptionCode=c0000005
> > [junit] ExceptionAddress=0052A340
> > [junit] ContextFlags=0001003f
> > [junit] Handler1=00401010
> > [junit] Handler2=11105CE0
> > [junit] InaccessibleAddress=00000000
> > [junit] EDI=00000000
> > [junit] ESI=00000000
> > [junit] EAX=0013D69C
> > [junit] EBX=00000000
> > [junit] ECX=007129FC
> > [junit] EDX=00000000
> > [junit] EIP=0052A340
> > [junit] ESP=0013D66C
> > [junit] EBP=00000000
> > [junit] Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll
> > [junit] Module_base_address=00510000
> > [junit] Offset_in_DLL=0001a340
> > [junit] This application has requested the Runtime to terminate it
> > in an unusual way.
> > [junit] Please contact the application's support team for more information.
> > [junit] Test
> > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
> > FAILED
> > <==
> >
> > Thanks,
> >
> > 2006/10/2, Vladimir Ivanov <iv...@gmail.com>:
> > > On 10/2/06, Alexei Zakharov <al...@gmail.com> wrote:
> > > >
> > > >
> > > > Juist my two cents. Some test even from such a high-level module as
> > > > beans fail if they run from bootclasspath (BeansTest for example).
> > > > Moreover, they crash DRLVM :)
> > >
> > >
> > > Seems, it is should be evaluated by VM peoples. The vm crash is not good
> > > reaction for test failure.
> > > thanks, Vladimir
> > >
> > > BTW, personally I use custom-made build file to develop with HDK and
> > > > single-module checkout.
--
Alexei Zakharov,
Intel Middleware Product 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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Posted by Alexei Zakharov <al...@gmail.com>.
> Is that reproducible on Linux? how does it run on pure OPT (-Xem:opt),
> JET?
I will check...
Regards,
02 Oct 2006 20:14:11 +0700, Egor Pasko <eg...@gmail.com>:
> On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote:
> > Agree. In case somebody is interested:
> > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
> > (from bootclasspath), harmony-hdk-r450941, WinXP.
>
> Is that reproducible on Linux? how does it run on pure OPT (-Xem:opt),
> JET?
>
> > Crash info:
> >
> > <==
> > [junit] An unhandled error (4) has occurred.
> > [junit] HyGeneric_Signal_Number=00000004
> > [junit] ExceptionCode=c0000005
> > [junit] ExceptionAddress=0052A340
> > [junit] ContextFlags=0001003f
> > [junit] Handler1=00401010
> > [junit] Handler2=11105CE0
> > [junit] InaccessibleAddress=00000000
> > [junit] EDI=00000000
> > [junit] ESI=00000000
> > [junit] EAX=0013D69C
> > [junit] EBX=00000000
> > [junit] ECX=007129FC
> > [junit] EDX=00000000
> > [junit] EIP=0052A340
> > [junit] ESP=0013D66C
> > [junit] EBP=00000000
> > [junit] Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll
> > [junit] Module_base_address=00510000
> > [junit] Offset_in_DLL=0001a340
> > [junit] This application has requested the Runtime to terminate it
> > in an unusual way.
> > [junit] Please contact the application's support team for more information.
> > [junit] Test
> > org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
> > FAILED
> > <==
> >
> > Thanks,
> >
> > 2006/10/2, Vladimir Ivanov <iv...@gmail.com>:
> > > On 10/2/06, Alexei Zakharov <al...@gmail.com> wrote:
> > > >
> > > >
> > > > Juist my two cents. Some test even from such a high-level module as
> > > > beans fail if they run from bootclasspath (BeansTest for example).
> > > > Moreover, they crash DRLVM :)
> > >
> > >
> > > Seems, it is should be evaluated by VM peoples. The vm crash is not good
> > > reaction for test failure.
> > > thanks, Vladimir
> > >
> > > BTW, personally I use custom-made build file to develop with HDK and
> > > > single-module checkout.
--
Alexei Zakharov,
Intel Middleware Product 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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x1F6 day of Apache Harmony Alexei Zakharov wrote:
> Agree. In case somebody is interested:
> org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
> (from bootclasspath), harmony-hdk-r450941, WinXP.
Is that reproducible on Linux? how does it run on pure OPT (-Xem:opt),
JET?
> Crash info:
>
> <==
> [junit] An unhandled error (4) has occurred.
> [junit] HyGeneric_Signal_Number=00000004
> [junit] ExceptionCode=c0000005
> [junit] ExceptionAddress=0052A340
> [junit] ContextFlags=0001003f
> [junit] Handler1=00401010
> [junit] Handler2=11105CE0
> [junit] InaccessibleAddress=00000000
> [junit] EDI=00000000
> [junit] ESI=00000000
> [junit] EAX=0013D69C
> [junit] EBX=00000000
> [junit] ECX=007129FC
> [junit] EDX=00000000
> [junit] EIP=0052A340
> [junit] ESP=0013D66C
> [junit] EBP=00000000
> [junit] Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll
> [junit] Module_base_address=00510000
> [junit] Offset_in_DLL=0001a340
> [junit] This application has requested the Runtime to terminate it
> in an unusual way.
> [junit] Please contact the application's support team for more information.
> [junit] Test
> org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
> FAILED
> <==
>
> Thanks,
>
> 2006/10/2, Vladimir Ivanov <iv...@gmail.com>:
> > On 10/2/06, Alexei Zakharov <al...@gmail.com> wrote:
> > >
> > >
> > > Juist my two cents. Some test even from such a high-level module as
> > > beans fail if they run from bootclasspath (BeansTest for example).
> > > Moreover, they crash DRLVM :)
> >
> >
> > Seems, it is should be evaluated by VM peoples. The vm crash is not good
> > reaction for test failure.
> > thanks, Vladimir
> >
> > BTW, personally I use custom-made build file to develop with HDK and
> > > single-module checkout.
>
>
>
> --
> Alexei Zakharov,
> Intel Middleware Product 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
>
>
--
Egor Pasko, Intel Managed Runtime 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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Posted by Alexei Zakharov <al...@gmail.com>.
Agree. In case somebody is interested:
org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
(from bootclasspath), harmony-hdk-r450941, WinXP.
Crash info:
<==
[junit] An unhandled error (4) has occurred.
[junit] HyGeneric_Signal_Number=00000004
[junit] ExceptionCode=c0000005
[junit] ExceptionAddress=0052A340
[junit] ContextFlags=0001003f
[junit] Handler1=00401010
[junit] Handler2=11105CE0
[junit] InaccessibleAddress=00000000
[junit] EDI=00000000
[junit] ESI=00000000
[junit] EAX=0013D69C
[junit] EBX=00000000
[junit] ECX=007129FC
[junit] EDX=00000000
[junit] EIP=0052A340
[junit] ESP=0013D66C
[junit] EBP=00000000
[junit] Module=C:\Java\harmony-hdk-r450941\jdk\jre\bin\default\harmonyvm.dll
[junit] Module_base_address=00510000
[junit] Offset_in_DLL=0001a340
[junit] This application has requested the Runtime to terminate it
in an unusual way.
[junit] Please contact the application's support team for more information.
[junit] Test
org.apache.harmony.beans.tests.java.beans.IntrospectionExceptionTest
FAILED
<==
Thanks,
2006/10/2, Vladimir Ivanov <iv...@gmail.com>:
> On 10/2/06, Alexei Zakharov <al...@gmail.com> wrote:
> >
> >
> > Juist my two cents. Some test even from such a high-level module as
> > beans fail if they run from bootclasspath (BeansTest for example).
> > Moreover, they crash DRLVM :)
>
>
> Seems, it is should be evaluated by VM peoples. The vm crash is not good
> reaction for test failure.
> thanks, Vladimir
>
> BTW, personally I use custom-made build file to develop with HDK and
> > single-module checkout.
--
Alexei Zakharov,
Intel Middleware Product 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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots
posted to general snapshot site )
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Alexei Zakharov wrote:
> Hi,
>
> 2006/10/2, Vladimir Ivanov <iv...@gmail.com>:
>> On 10/2/06, Mark Hindess <ma...@googlemail.com> wrote:
>
>> > I think we need more than one tests.jar. In fact, I think we need
>> > more than one tests.jar per module since some tests need to be on the
>> > bootclasspath while others do not (and should not). At the moment
>> > it might be necessary to have more since there isn't really a way to
>> > distinguish api/internal tests (this might change if/when we move to
>> > testng).
>>
>> Almost all API tests can be run through the bootclasspath. May be we just
>> waiting for something like TestNG (or other solution) and will create one
>> test.jar for each module?
>
> Juist my two cents. Some test even from such a high-level module as
> beans fail if they run from bootclasspath (BeansTest for example).
> Moreover, they crash DRLVM :)
>
> BTW, personally I use custom-made build file to develop with HDK and
> single-module checkout.
Wouldn't this be something nice to show people? :)
geir
>
> Regards,
>
---------------------------------------------------------------------
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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 10/2/06, Alexei Zakharov <al...@gmail.com> wrote:
>
>
> Juist my two cents. Some test even from such a high-level module as
> beans fail if they run from bootclasspath (BeansTest for example).
> Moreover, they crash DRLVM :)
Seems, it is should be evaluated by VM peoples. The vm crash is not good
reaction for test failure.
thanks, Vladimir
BTW, personally I use custom-made build file to develop with HDK and
> single-module checkout.
>
> Regards,
>
> --
> Alexei Zakharov,
> Intel Middleware Product 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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Posted by Alexei Zakharov <al...@gmail.com>.
Hi,
2006/10/2, Vladimir Ivanov <iv...@gmail.com>:
> On 10/2/06, Mark Hindess <ma...@googlemail.com> wrote:
> > I think we need more than one tests.jar. In fact, I think we need
> > more than one tests.jar per module since some tests need to be on the
> > bootclasspath while others do not (and should not). At the moment
> > it might be necessary to have more since there isn't really a way to
> > distinguish api/internal tests (this might change if/when we move to
> > testng).
>
> Almost all API tests can be run through the bootclasspath. May be we just
> waiting for something like TestNG (or other solution) and will create one
> test.jar for each module?
Juist my two cents. Some test even from such a high-level module as
beans fail if they run from bootclasspath (BeansTest for example).
Moreover, they crash DRLVM :)
BTW, personally I use custom-made build file to develop with HDK and
single-module checkout.
Regards,
--
Alexei Zakharov,
Intel Middleware Product 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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Posted by Vladimir Ivanov <iv...@gmail.com>.
One minor question before suggest a patch: should we update HDK files on
each files changes or should not?
Both cases have pro and contra:
- if we update HDK files (module.jar and tests.jar) - we have ready-to-use
runtime that can be used to run some application without additional options
but to restore 'original' HDK ws should be synchronized with SVN and
rebuild;
- and vs: the HDK is stable but to run something over updated classes we
should specified additional options to runtime.
So, the first case provides 'easy-to-use' capability but the second case
gives more stability. What is preferred?
And of cause, any solution should be documented :)
thanks, Vladimir
On 9/30/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> Just renaming the thread....
>
> On Sep 29, 2006, at 9:17 AM, Vladimir Ivanov wrote:
>
> > today I tries to build and test one module with HDK. It almost works
> > :). Small instruction to reproduce:
> >
> > 1) checkout trunk -N, make and modules/<beans> dirs. Note, <beans>/
> > build.xml
> > refers to some staff in the make dir. Also, the luni-kernel and
> > security-kernel modules should be checkout to hide errors:
> > trunk\modules\beans\build.xml:80: Excludesfile
> > trunk\deploy\build\patternsets\luni-kernel.txt not found.
> > and
> > C:\tmp\tmp30\trunk\modules\beans\build.xml:80: Excludesfile
> > trunk\deploy\build\patternsets\security-kernel.txt not found.
> >
> > 2) run something like "ant -Dhy.jdk=C:\harmony\hdk\jdk -
> > Dbuild.module=beans"
> > from the 'trunk' directory to copy patternsets to the deploy dir.
> > Note, this
> > command will be failed on the check-dependency task.
> >
> > 3) set CLASSPATH=junit.jar;hdk\build\test\support.jar
> >
> > 4) go to the module dir (modules/beans in my case). That's all:
> > module ready
> > to use. You can press: ant -Dhy.jdk=hdk\jdk clean/build/test. Note,
> > actually, the beans.jar in the HDK will be updated. It is OK?
> >
> > To do in the build system:
> > - remove dependency on the luni-kernel and security-kernel modules
> > - add mode to rebuild module without HDK update (?)
> > - add mode to run tests with build html-report for each module.
> > - add mode to run all tests from tests.jar over HDK+ updated classes.
> > - ?
> >
> > thanks, Vladimir
> >
> > On 9/28/06, Alexey Petrenko <al...@gmail.com> wrote:
> >>
> >> Good point. +1 from me.
> >>
> >> SY, Alexey
> >>
> >> 2006/9/27, Alexei Zakharov <al...@gmail.com>:
> >> > If we plan to use HDK for supporting developers who work on single
> >> > module (that is a good idea IMHO) then we definitely need to supply
> >> > jar with tests. We may also supply the build file with placeholders
> >> > for user classes & tests dirs that will be prepended to
> >> > classpath/bootclasspath.
> >> >
> >> > Regards,
> >> >
> >> > 2006/9/27, Vladimir Ivanov <iv...@gmail.com>:
> >> > > On 9/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> > > >
> >> > > >
> >> > > >
> >> > > > If I recall, the point of the test.jar was to have a pre-
> >> built jar
> >> of
> >> > > > tests in the HDK so that someone could setup the build-test
> >> infra
> >> > > > using the HDK so they could run tests on their platform w/o
> >> having
> >> to
> >> > > > build everything. Good idea.
> >> > >
> >> > >
> >> > > Yes, you are correct. This idea implemented in the jira 964.
> >> > >
> >> > > If that's so, then something would
> >> > > > have to be configured to have the classlib "test" target use
> >> that
> >> > > > jar. All I'm saying is that how we do this is important, as we
> >> don't
> >> > > > want to cause pain for classlib developers who use the HDK for
> >> > > > development support.
> >> > >
> >> > >
> >> > >
> >> > > Seems, we think about different use cases.
> >> > >
> >> > > In my case, user can download the HDK for own platform (if we
> >> have
> >> one) run
> >> > > tests and look on results (also, may be upload it to the harmony
> >> site). Also
> >> > > it can be used for application run to check 'enable' status.
> >> But if
> >> this
> >> > > user interested in Harmony development he should checkout ws
> >> and use
> >> > > built-in ant targets to build and test updated ws.
> >> > >
> >> > >
> >> > >
> >> > > How you plan to use HDK? It looks like initial
> >> miscommunication :)
> >> > > thanks, Vladimir
> >> > >
> >> > >
> >> > >
> >> > > > geir
> >> > > >
> >> > > > >
> >> > > > > Thanks, Vladimir
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >> > Thanks, Vladimir
> >> > > > >> >
> >> > > > >> > geir
> >> > > > >> >>
> >> > > > >> >> >
> >> > > > >> >> >
> >> > > > >> >> >
> >> > > > >> >> > Thanks, Vladimir
> >> > > > >> >> >
> >> > > > >> >> >
> >> > > > >> >> >
> >> > > > >> >> > On 7/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >> > > > >> >> >>
> >> > > > >> >> >> They are at the regular place
> >> > > > >> >> >>
> >> > > > >> >> >> http://people.apache.org/dist/incubator/harmony/
> >> snapshots
> >> > > > >> >> >>
> >> > > > >> >> >> I moved all the old classlib snapshots into /old
> >> and I'll
> >> > > > >> >> update the
> >> > > > >> >> >> website accordingly. I'll be automating this.
> >> Also, lets
> >> not
> >> > > > >> >> >> make much
> >> > > > >> >> >> noise about this for a little while so we can test
> >> to make
> >> sure
> >> > > > >> >> >> there's
> >> > > > >> >> >> no major errors. Things seem good. I have a list
> >> of more
> >> > > > >> >> things to
> >> > > > >> >> >> fix, but I realized today that I was obsessing over
> >> the
> >> > > > >> snapshot
> >> > > > >> >> >> contents - it's not a release, and it's "good enough".
> >> > > > >> >> >>
> >> > > > >> >> >> I'd like to ditch both /old and the remaining classlib
> >> > > > >> >> snapshots, as
> >> > > > >> >> >>
> >> > > > >> >> >> 1) they are snapshots - history doesn't matter
> >> > > > >> >> >>
> >> > > > >> >> >> 2) the classlib is now in the HDK, so we just need to
> >> adjust
> >> > > > >> the
> >> > > > >> >> >> docs to
> >> > > > >> >> >> match.
> >> > > > >> >> >>
> >> > > > >> >> >> I'll do the latter, but wanted to see if anyone has a
> >> problem
> >> > > > >> >> w/ me
> >> > > > >> >> >> removing /old and the last classlib snapshot. I'll
> >> do this
> >> > > > >> if I
> >> > > > >> >> >> don't
> >> > > > >> >> >> hear any protest, so either positively acknowledge
> >> this
> >> action
> >> > > > >> >> if you
> >> > > > >> >> >> support it, dont' do a thing if you support or
> >> dont' care,
> >> > > > >> or say
> >> > > > >> >> >> why we
> >> > > > >> >> >> shouldn't :)
> >> > > > >> >> >>
> >> > > > >> >> >> 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
> >> > > > >> >>
> >> > > > >> >>
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> ---------------------------------------------------------------------
> >> > > > >> 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
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Alexei Zakharov,
> >> > Intel Middleware Product 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
> >> >
> >> >
> >>
> >>
> >> --
> >> Alexey A. Petrenko
> >> 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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 10/2/06, Mark Hindess <ma...@googlemail.com> wrote:
>
> <...>
>
> I think we need more than one tests.jar. In fact, I think we need
> more than one tests.jar per module since some tests need to be on the
> bootclasspath while others do not (and should not). At the moment
> it might be necessary to have more since there isn't really a way to
> distinguish api/internal tests (this might change if/when we move to
> testng).
Mark, could you please look on the
*HARMONY-984*<http://issues.apache.org/jira/browse/HARMONY-984>?
If accessibility.build.patch<http://issues.apache.org/jira/secure/attachment/12342238/accessibility.build.patch>is
OK I'll prepare similar updates for other modules.
Thanks, Vladimir
<...>Regards,
> Mark.
>
> [0] Start of build would need to do:
>
> if ${hy.jdk} != ${hy.hdk}/jdk then copy ${hy.hdk}/jdk to ${hy.jdk}
>
> and only deploy jdk files in to ${hy.jdk} - I think/hope this is
> true already.
>
>
>
Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 10/2/06, Mark Hindess <ma...@googlemail.com> wrote:
>
> On 29 September 2006 at 15:26, "Geir Magnusson Jr." <ge...@pobox.com>
> wrote:
> > Just renaming the thread....
> >
> > On Sep 29, 2006, at 9:17 AM, Vladimir Ivanov wrote:
> >
> > > today I tries to build and test one module with HDK. It almost works
> > > :). Small instruction to reproduce:
> > >
> > > 1) checkout trunk -N, make and modules/<beans> dirs. Note, <beans>/
> > > build.xml
> > > refers to some staff in the make dir. Also, the luni-kernel and
> > > security-kernel modules should be checkout to hide errors:
> > > trunk\modules\beans\build.xml:80: Excludesfile
> > > trunk\deploy\build\patternsets\luni-kernel.txt not found.
> > > and
> > > C:\tmp\tmp30\trunk\modules\beans\build.xml:80: Excludesfile
> > > trunk\deploy\build\patternsets\security-kernel.txt not found.
> > >
> > > 2) run something like "ant -Dhy.jdk=C:\harmony\hdk\jdk -
> > > Dbuild.module=beans"
> > > from the 'trunk' directory to copy patternsets to the deploy dir.
> > > Note, this
> > > command will be failed on the check-dependency task.
> > >
> > > 3) set CLASSPATH=junit.jar;hdk\build\test\support.jar
> > >
> > > 4) go to the module dir (modules/beans in my case). That's all:
> > > module ready
> > > to use. You can press: ant -Dhy.jdk=hdk\jdk clean/build/test. Note,
> > > actually, the beans.jar in the HDK will be updated. It is OK?
> > >
> > > To do in the build system:
> > > - remove dependency on the luni-kernel and security-kernel modules
>
> I assumed that the dependency was on the patternsets (which could
> be removed see thread "[classlib] Trying to catch patternset errors
> earlier") and the stub jars. These should just be part of the HDK.
Yes. According to 'error message' it is patterns.
> > > - add mode to rebuild module without HDK update (?)
>
> "add mode to rebuild without JDK update" might be simpler[0]? would it
> be sufficient? if not, why not? (Some modules do update the hdk but
> these are generally files that would not change often - such as C
> header files that define an API which should be fairly stable.)
the run 'ant build' from module's dir leads to the message like:
trunk\modules\beans\build.xml:80: Problem creating jar:
trunk\deploy\jdk\jre\lib\boot\beans.jar (The system cannot find the path
specified) (and the archive is probably corrupt but I could not delete it)
If you run "ant build -Dhy.hdk=hdk/jdk" than modules.jar will be updated
into HDK.
Agree, coping all files from HDK to deploy dir should works fine.
> > > - add mode to run tests with build html-report for each module.
>
> Definitely +1.
>
> > > - add mode to run all tests from tests.jar over HDK+ updated classes.
> > > - ?
>
> I think we need more than one tests.jar. In fact, I think we need
> more than one tests.jar per module since some tests need to be on the
> bootclasspath while others do not (and should not). At the moment
> it might be necessary to have more since there isn't really a way to
> distinguish api/internal tests (this might change if/when we move to
> testng).
Almost all API tests can be run through the bootclasspath. May be we just
waiting for something like TestNG (or other solution) and will create one
test.jar for each module?
> We also need to ensure that properties.xml is available in the hdk -
> for access to the properties and the make macro. (This is already
> on my todo list.) I think we should probably create other macros
> to simplify the module build.xml files. (For example, share the
> compile-tests/run-tests macros that are already defined in crypto, luni,
> rmi, security and x-net.) This is also on my todo list.
The 'make' module is not big so it can be checkout together with module. But
it will be more convenient if to work with HDK user will need only HDK +
module.
> Also, since we've stated that when a module is change tests should
> be run on the module itself and it's immediate dependent modules, we
> really need a way to run other modules tests from a module. This will
> be interesting due to the complexity of the test setup but might be
> slightly easier if the define common macros.
As the first step we can run all tests through the bootclasspath. Seems,
that 4 test.jar for each module are too many.
> This is probably something
> to keep in the back of our minds - I wouldn't let it stop us making
> progress.
If you need a help in the test of your changes - I'm a volunteer :)
thanks, Vladimir
Regards,
> Mark.
>
> [0] Start of build would need to do:
>
> if ${hy.jdk} != ${hy.hdk}/jdk then copy ${hy.hdk}/jdk to ${hy.jdk}
>
> and only deploy jdk files in to ${hy.jdk} - I think/hope this is
> true already.
>
> > > thanks, Vladimir
> > >
> > > On 9/28/06, Alexey Petrenko <al...@gmail.com> wrote:
> > >>
> > >> Good point. +1 from me.
> > >>
> > >> SY, Alexey
> > >>
> > >> 2006/9/27, Alexei Zakharov <al...@gmail.com>:
> > >> > If we plan to use HDK for supporting developers who work on single
> > >> > module (that is a good idea IMHO) then we definitely need to supply
> > >> > jar with tests. We may also supply the build file with placeholders
> > >> > for user classes & tests dirs that will be prepended to
> > >> > classpath/bootclasspath.
> > >> >
> > >> > Regards,
> > >> >
> > >> > 2006/9/27, Vladimir Ivanov <iv...@gmail.com>:
> > >> > > On 9/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > If I recall, the point of the test.jar was to have a pre-
> > >> built jar
> > >> of
> > >> > > > tests in the HDK so that someone could setup the build-test
> > >> infra
> > >> > > > using the HDK so they could run tests on their platform w/o
> > >> having
> > >> to
> > >> > > > build everything. Good idea.
> > >> > >
> > >> > >
> > >> > > Yes, you are correct. This idea implemented in the jira 964.
> > >> > >
> > >> > > If that's so, then something would
> > >> > > > have to be configured to have the classlib "test" target use
> > >> that
> > >> > > > jar. All I'm saying is that how we do this is important, as we
> > >> don't
> > >> > > > want to cause pain for classlib developers who use the HDK for
> > >> > > > development support.
> > >> > >
> > >> > >
> > >> > >
> > >> > > Seems, we think about different use cases.
> > >> > >
> > >> > > In my case, user can download the HDK for own platform (if we
> > >> have
> > >> one) run
> > >> > > tests and look on results (also, may be upload it to the harmony
> > >> site). Also
> > >> > > it can be used for application run to check 'enable' status.
> > >> But if
> > >> this
> > >> > > user interested in Harmony development he should checkout ws
> > >> and use
> > >> > > built-in ant targets to build and test updated ws.
> > >> > >
> > >> > >
> > >> > >
> > >> > > How you plan to use HDK? It looks like initial
> > >> miscommunication :)
> > >> > > thanks, Vladimir
> > >> > >
> > >> > >
> > >> > >
> > >> > > > geir
> > >> > > >
> > >> > > > >
> > >> > > > > Thanks, Vladimir
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >> > Thanks, Vladimir
> > >> > > > >> >
> > >> > > > >> > geir
> > >> > > > >> >>
> > >> > > > >> >> >
> > >> > > > >> >> >
> > >> > > > >> >> >
> > >> > > > >> >> > Thanks, Vladimir
> > >> > > > >> >> >
> > >> > > > >> >> >
> > >> > > > >> >> >
> > >> > > > >> >> > On 7/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> > >> > > > >> >> >>
> > >> > > > >> >> >> They are at the regular place
> > >> > > > >> >> >>
> > >> > > > >> >> >> http://people.apache.org/dist/incubator/harmony/
> > >> snapshots
> > >> > > > >> >> >>
> > >> > > > >> >> >> I moved all the old classlib snapshots into /old
> > >> and I'll
> > >> > > > >> >> update the
> > >> > > > >> >> >> website accordingly. I'll be automating this.
> > >> Also, lets
> > >> not
> > >> > > > >> >> >> make much
> > >> > > > >> >> >> noise about this for a little while so we can test
> > >> to make
> > >> sure
> > >> > > > >> >> >> there's
> > >> > > > >> >> >> no major errors. Things seem good. I have a list
> > >> of more
> > >> > > > >> >> things to
> > >> > > > >> >> >> fix, but I realized today that I was obsessing over
> > >> the
> > >> > > > >> snapshot
> > >> > > > >> >> >> contents - it's not a release, and it's "good enough".
> > >> > > > >> >> >>
> > >> > > > >> >> >> I'd like to ditch both /old and the remaining classlib
> > >> > > > >> >> snapshots, as
> > >> > > > >> >> >>
> > >> > > > >> >> >> 1) they are snapshots - history doesn't matter
> > >> > > > >> >> >>
> > >> > > > >> >> >> 2) the classlib is now in the HDK, so we just need to
> > >> adjust
> > >> > > > >> the
> > >> > > > >> >> >> docs to
> > >> > > > >> >> >> match.
> > >> > > > >> >> >>
> > >> > > > >> >> >> I'll do the latter, but wanted to see if anyone has a
> > >> problem
> > >> > > > >> >> w/ me
> > >> > > > >> >> >> removing /old and the last classlib snapshot. I'll
> > >> do this
> > >> > > > >> if I
> > >> > > > >> >> >> don't
> > >> > > > >> >> >> hear any protest, so either positively acknowledge
> > >> this
> > >> action
> > >> > > > >> >> if you
> > >> > > > >> >> >> support it, dont' do a thing if you support or
> > >> dont' care,
> > >> > > > >> or say
> > >> > > > >> >> >> why we
> > >> > > > >> >> >> shouldn't :)
> > >> > > > >> >> >>
> > >> > > > >> >> >> 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
> > >> > > > >> >>
> > >> > > > >> >>
> > >> > > > >>
> > >> > > > >>
> > >> > > > >>
> > >> ---------------------------------------------------------------------
> > >> > > > >> 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
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > Alexei Zakharov,
> > >> > Intel Middleware Product 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
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> Alexey A. Petrenko
> > >> 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
> >
>
>
>
> ---------------------------------------------------------------------
> 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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots
posted to general snapshot site )
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Mark Hindess wrote:
> On 2 October 2006 at 8:52, "Geir Magnusson Jr." <ge...@pobox.com> wrote:
>>
>> I wonder if we can generate some kind of dependency graph as part of the
>> build, so that if testing in a module, it can figure out the set of
>> modules to test that are "n-away" dependent. (IOW, test module + 1-away
>> because it's quick, then before checkin test module + 2-away [or all])
>
> I wondered about this for a different reason...
>
> I think it might be interesting to be able to automate this even in
> a fairy rough way since I'm interested to see what dependencies we
> are adding between our modules over time. Since my impression (based
> on no real evidence) is that we perhaps aren't really giving it much
> thought.
I suspect you're right. We need a Dependency Czar :)
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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Posted by Mark Hindess <ma...@googlemail.com>.
On 2 October 2006 at 8:52, "Geir Magnusson Jr." <ge...@pobox.com> wrote:
>
>
> I wonder if we can generate some kind of dependency graph as part of the
> build, so that if testing in a module, it can figure out the set of
> modules to test that are "n-away" dependent. (IOW, test module + 1-away
> because it's quick, then before checkin test module + 2-away [or all])
I wondered about this for a different reason...
I think it might be interesting to be able to automate this even in
a fairy rough way since I'm interested to see what dependencies we
are adding between our modules over time. Since my impression (based
on no real evidence) is that we perhaps aren't really giving it much
thought.
-Mark.
---------------------------------------------------------------------
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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots
posted to general snapshot site )
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Mark Hindess wrote:
>
> I think we need more than one tests.jar. In fact, I think we need
> more than one tests.jar per module since some tests need to be on the
> bootclasspath while others do not (and should not). At the moment
> it might be necessary to have more since there isn't really a way to
> distinguish api/internal tests (this might change if/when we move to
> testng).
Yes, I think you are right, and I think that this points to one of the
[predicted] challenges with using only annotations for test organization.
>
> We also need to ensure that properties.xml is available in the hdk -
> for access to the properties and the make macro. (This is already
> on my todo list.) I think we should probably create other macros
> to simplify the module build.xml files. (For example, share the
> compile-tests/run-tests macros that are already defined in crypto, luni,
> rmi, security and x-net.) This is also on my todo list.
>
> Also, since we've stated that when a module is change tests should
> be run on the module itself and it's immediate dependent modules, we
> really need a way to run other modules tests from a module. This will
> be interesting due to the complexity of the test setup but might be
> slightly easier if the define common macros. This is probably something
> to keep in the back of our minds - I wouldn't let it stop us making
> progress.
I wonder if we can generate some kind of dependency graph as part of the
build, so that if testing in a module, it can figure out the set of
modules to test that are "n-away" dependent. (IOW, test module + 1-away
because it's quick, then before checkin test module + 2-away [or all])
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: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Posted by Mark Hindess <ma...@googlemail.com>.
On 29 September 2006 at 15:26, "Geir Magnusson Jr." <ge...@pobox.com> wrote:
> Just renaming the thread....
>
> On Sep 29, 2006, at 9:17 AM, Vladimir Ivanov wrote:
>
> > today I tries to build and test one module with HDK. It almost works
> > :). Small instruction to reproduce:
> >
> > 1) checkout trunk -N, make and modules/<beans> dirs. Note, <beans>/
> > build.xml
> > refers to some staff in the make dir. Also, the luni-kernel and
> > security-kernel modules should be checkout to hide errors:
> > trunk\modules\beans\build.xml:80: Excludesfile
> > trunk\deploy\build\patternsets\luni-kernel.txt not found.
> > and
> > C:\tmp\tmp30\trunk\modules\beans\build.xml:80: Excludesfile
> > trunk\deploy\build\patternsets\security-kernel.txt not found.
> >
> > 2) run something like "ant -Dhy.jdk=C:\harmony\hdk\jdk -
> > Dbuild.module=beans"
> > from the 'trunk' directory to copy patternsets to the deploy dir.
> > Note, this
> > command will be failed on the check-dependency task.
> >
> > 3) set CLASSPATH=junit.jar;hdk\build\test\support.jar
> >
> > 4) go to the module dir (modules/beans in my case). That's all:
> > module ready
> > to use. You can press: ant -Dhy.jdk=hdk\jdk clean/build/test. Note,
> > actually, the beans.jar in the HDK will be updated. It is OK?
> >
> > To do in the build system:
> > - remove dependency on the luni-kernel and security-kernel modules
I assumed that the dependency was on the patternsets (which could
be removed see thread "[classlib] Trying to catch patternset errors
earlier") and the stub jars. These should just be part of the HDK.
> > - add mode to rebuild module without HDK update (?)
"add mode to rebuild without JDK update" might be simpler[0]? would it
be sufficient? if not, why not? (Some modules do update the hdk but
these are generally files that would not change often - such as C
header files that define an API which should be fairly stable.)
> > - add mode to run tests with build html-report for each module.
Definitely +1.
> > - add mode to run all tests from tests.jar over HDK+ updated classes.
> > - ?
I think we need more than one tests.jar. In fact, I think we need
more than one tests.jar per module since some tests need to be on the
bootclasspath while others do not (and should not). At the moment
it might be necessary to have more since there isn't really a way to
distinguish api/internal tests (this might change if/when we move to
testng).
We also need to ensure that properties.xml is available in the hdk -
for access to the properties and the make macro. (This is already
on my todo list.) I think we should probably create other macros
to simplify the module build.xml files. (For example, share the
compile-tests/run-tests macros that are already defined in crypto, luni,
rmi, security and x-net.) This is also on my todo list.
Also, since we've stated that when a module is change tests should
be run on the module itself and it's immediate dependent modules, we
really need a way to run other modules tests from a module. This will
be interesting due to the complexity of the test setup but might be
slightly easier if the define common macros. This is probably something
to keep in the back of our minds - I wouldn't let it stop us making
progress.
Regards,
Mark.
[0] Start of build would need to do:
if ${hy.jdk} != ${hy.hdk}/jdk then copy ${hy.hdk}/jdk to ${hy.jdk}
and only deploy jdk files in to ${hy.jdk} - I think/hope this is
true already.
> > thanks, Vladimir
> >
> > On 9/28/06, Alexey Petrenko <al...@gmail.com> wrote:
> >>
> >> Good point. +1 from me.
> >>
> >> SY, Alexey
> >>
> >> 2006/9/27, Alexei Zakharov <al...@gmail.com>:
> >> > If we plan to use HDK for supporting developers who work on single
> >> > module (that is a good idea IMHO) then we definitely need to supply
> >> > jar with tests. We may also supply the build file with placeholders
> >> > for user classes & tests dirs that will be prepended to
> >> > classpath/bootclasspath.
> >> >
> >> > Regards,
> >> >
> >> > 2006/9/27, Vladimir Ivanov <iv...@gmail.com>:
> >> > > On 9/27/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >> > > >
> >> > > >
> >> > > >
> >> > > > If I recall, the point of the test.jar was to have a pre-
> >> built jar
> >> of
> >> > > > tests in the HDK so that someone could setup the build-test
> >> infra
> >> > > > using the HDK so they could run tests on their platform w/o
> >> having
> >> to
> >> > > > build everything. Good idea.
> >> > >
> >> > >
> >> > > Yes, you are correct. This idea implemented in the jira 964.
> >> > >
> >> > > If that's so, then something would
> >> > > > have to be configured to have the classlib "test" target use
> >> that
> >> > > > jar. All I'm saying is that how we do this is important, as we
> >> don't
> >> > > > want to cause pain for classlib developers who use the HDK for
> >> > > > development support.
> >> > >
> >> > >
> >> > >
> >> > > Seems, we think about different use cases.
> >> > >
> >> > > In my case, user can download the HDK for own platform (if we
> >> have
> >> one) run
> >> > > tests and look on results (also, may be upload it to the harmony
> >> site). Also
> >> > > it can be used for application run to check 'enable' status.
> >> But if
> >> this
> >> > > user interested in Harmony development he should checkout ws
> >> and use
> >> > > built-in ant targets to build and test updated ws.
> >> > >
> >> > >
> >> > >
> >> > > How you plan to use HDK? It looks like initial
> >> miscommunication :)
> >> > > thanks, Vladimir
> >> > >
> >> > >
> >> > >
> >> > > > geir
> >> > > >
> >> > > > >
> >> > > > > Thanks, Vladimir
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >> > Thanks, Vladimir
> >> > > > >> >
> >> > > > >> > geir
> >> > > > >> >>
> >> > > > >> >> >
> >> > > > >> >> >
> >> > > > >> >> >
> >> > > > >> >> > Thanks, Vladimir
> >> > > > >> >> >
> >> > > > >> >> >
> >> > > > >> >> >
> >> > > > >> >> > On 7/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> >> > > > >> >> >>
> >> > > > >> >> >> They are at the regular place
> >> > > > >> >> >>
> >> > > > >> >> >> http://people.apache.org/dist/incubator/harmony/
> >> snapshots
> >> > > > >> >> >>
> >> > > > >> >> >> I moved all the old classlib snapshots into /old
> >> and I'll
> >> > > > >> >> update the
> >> > > > >> >> >> website accordingly. I'll be automating this.
> >> Also, lets
> >> not
> >> > > > >> >> >> make much
> >> > > > >> >> >> noise about this for a little while so we can test
> >> to make
> >> sure
> >> > > > >> >> >> there's
> >> > > > >> >> >> no major errors. Things seem good. I have a list
> >> of more
> >> > > > >> >> things to
> >> > > > >> >> >> fix, but I realized today that I was obsessing over
> >> the
> >> > > > >> snapshot
> >> > > > >> >> >> contents - it's not a release, and it's "good enough".
> >> > > > >> >> >>
> >> > > > >> >> >> I'd like to ditch both /old and the remaining classlib
> >> > > > >> >> snapshots, as
> >> > > > >> >> >>
> >> > > > >> >> >> 1) they are snapshots - history doesn't matter
> >> > > > >> >> >>
> >> > > > >> >> >> 2) the classlib is now in the HDK, so we just need to
> >> adjust
> >> > > > >> the
> >> > > > >> >> >> docs to
> >> > > > >> >> >> match.
> >> > > > >> >> >>
> >> > > > >> >> >> I'll do the latter, but wanted to see if anyone has a
> >> problem
> >> > > > >> >> w/ me
> >> > > > >> >> >> removing /old and the last classlib snapshot. I'll
> >> do this
> >> > > > >> if I
> >> > > > >> >> >> don't
> >> > > > >> >> >> hear any protest, so either positively acknowledge
> >> this
> >> action
> >> > > > >> >> if you
> >> > > > >> >> >> support it, dont' do a thing if you support or
> >> dont' care,
> >> > > > >> or say
> >> > > > >> >> >> why we
> >> > > > >> >> >> shouldn't :)
> >> > > > >> >> >>
> >> > > > >> >> >> 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
> >> > > > >> >>
> >> > > > >> >>
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> ---------------------------------------------------------------------
> >> > > > >> 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
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Alexei Zakharov,
> >> > Intel Middleware Product 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
> >> >
> >> >
> >>
> >>
> >> --
> >> Alexey A. Petrenko
> >> 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
>
---------------------------------------------------------------------
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