harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ivanov" <ivavladi...@gmail.com>
Subject Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Date Mon, 02 Oct 2006 09:28:01 GMT
On 10/2/06, Mark Hindess <mark.hindess@googlemail.com> wrote:

>
> On 29 September 2006 at 15:26, "Geir Magnusson Jr." <geir@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 <alexey.a.petrenko@gmail.com> wrote:
> > >>
> > >> Good point. +1 from me.
> > >>
> > >> SY, Alexey
> > >>
> > >> 2006/9/27, Alexei Zakharov <alexei.zakharov@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 <ivavladimir@gmail.com>:
> > >> > > On 9/27/06, Geir Magnusson Jr. <geir@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 <geir@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message