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 07:12:35 GMT
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. <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
> > - 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 <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
>
>

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