harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [general] Using the HDK ( was Re: [general] jre and hdk snapshots posted to general snapshot site )
Date Mon, 02 Oct 2006 08:03:48 GMT

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.

> > - 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 <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
View raw message