On 29 September 2006 at 15:26, "Geir Magnusson Jr." <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> >>
> >> Good point. +1 from me.
> >>
> >> SY, Alexey
> >>
> >> 2006/9/27, Alexei Zakharov <[EMAIL PROTECTED]>:
> >> > 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 <[EMAIL PROTECTED]>:
> >> > > On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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-
> >> > > > >> >> [EMAIL PROTECTED]
> >> > > > >> >> >> For additional commands, e-mail: harmony-dev-
> >> > > > >> >> >> [EMAIL PROTECTED]
> >> > > > >> >> >>
> >> > > > >> >> >>
> >> > > > >> >>
> >> > > > >> >>
> >> > > > >> >>
> >> > > > >>
> >> ---------------------------------------------------------------------
> >> > > > >> >> Terms of use :
> >> http://incubator.apache.org/harmony/mailing.html
> >> > > > >> >> To unsubscribe, e-mail: harmony-dev-
> >> > > > >> [EMAIL PROTECTED]
> >> > > > >> >> For additional commands, e-mail: harmony-dev-
> >> > > > >> >> [EMAIL PROTECTED]
> >> > > > >> >>
> >> > > > >> >>
> >> > > > >>
> >> > > > >>
> >> > > > >>
> >> ---------------------------------------------------------------------
> >> > > > >> Terms of use : http://incubator.apache.org/harmony/
> >> mailing.html
> >> > > > >> To unsubscribe, e-mail:
> >> [EMAIL PROTECTED]
> >> > > > >> For additional commands, e-mail: harmony-dev-
> >> > > > >> [EMAIL PROTECTED]
> >> > > > >>
> >> > > > >>
> >> > > >
> >> > > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> > > > To unsubscribe, e-mail: harmony-dev-
> >> [EMAIL PROTECTED]
> >> > > > For additional commands, e-mail:
> >> [EMAIL PROTECTED]
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Alexei Zakharov,
> >> > Intel Middleware Product Division
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> > To unsubscribe, e-mail: harmony-dev-
> >> [EMAIL PROTECTED]
> >> > For additional commands, e-mail: harmony-dev-
> >> [EMAIL PROTECTED]
> >> >
> >> >
> >>
> >>
> >> --
> >> Alexey A. Petrenko
> >> Intel Middleware Products Division
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: harmony-dev-
> >> [EMAIL PROTECTED]
> >>
> >>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
