harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy,Jing Lv" <firep...@gmail.com>
Subject Re: [general] Add a new target for Harmony-Select in the build script
Date Tue, 13 Apr 2010 08:01:53 GMT
Hi Mark,

     I like your idea that changing the exclude property file. In my mind,
anything to make it clear and easy will be great.

     In my original plan, I was just trying to fix the classlib build.xml,
add some new target in that. Yes if we only require some excluded jars we
can use the exclude list.

     To use a new folder deploy_select is try to avoid some confliction,
e.g, if someone build full harmony, and then build harmony-select again, he
still has extra jars in the deploy folder.

     Both Java5 or Java6 is OK if we make it no side-effect with other build

     Will try the exclude list now.

2010/4/12 Mark Hindess <mark.hindess@googlemail.com>

> In message <t2x5c8e69f1004090121t70353ef6xe8c8851c9a3f2559@mail.gmail.com
> >,
> "Jimmy,Jing Lv" writes:
> >
> > Hello Everyone,
> >
> >     I'd like to raise the topic of "Harmony-Select"
> > again. Harmony-select, as we discussed, is aimed to create a
> > customized build without graphic components. The select build will
> > then be smaller in the footprint. It is specially useful for the
> > customer applications which does not require awt/swing (as many j2ee
> > apps, java DBs, and applications like eclipse, Hadoop etc)
> >
> >     Thanks to Harmony modularization, it is quite easy to create this
> > select build. And currently there is no special requirement on the
> > source, we can make a select build without forking a new branch. My
> > plan is:
> >
> > 1. add a new target in the \classlib\build.xml, say, build-select,
> > including build-select-java, build-select-native and build-select-test
> In general I'd be against adding new targets.  The name of an invoked
> target is not propagated by ant.  Think about the consequences of what
> you are suggesting, we'd need to add:
>  a) a similar number of new targets to federated/build.xml
>  b) bundle-select-hdk and a number of related targets to
> federated/build.xml
>  c) bundle-select-src and a number of related targets to
> federated/build.xml
>  d) possibly a number of targets to federated/classlib/make/build-*.xml
> I'd much rather add a -Dhy.select=true option as this can be:
>  a) propagated down from federated build to classlib (and potentially other
>    components if we want/need to - do we want all the jdktools in select?)
>  b) saved/restored from a properties file
> > 2. build-select targets will operate like normal ones, just exclude
> > graphic components:
> >  ACCESSIBILITY      APPLET              AWT
> >  IMAGEIO            ORB                 PRINT
> >  RMI                SOUND               SWING      X_MGT
> Why couldn't -Dhy.select=true just modify the default value for
> exclude.module?
> > 3. Then deploy the necessary materials including jars, property files
> > and binary under deploy-select/. A small problem here is that we
> > have define the output directory (deploy/jdk/jre/lib/boot) in every
> > module. I don't have a perfect solution now to modify that, but only
> > to copy them from deploy/ to deploy-select/
> I'm not sure why we need to do copying?  Why would deploy/ contain more
> than deploy-select?  (Aside: I am somewhat slowly trying to remove
> unnecessary copying from the ant files.  I did quite a bit of work on
> the build-native steps in classlib and this resulted in significant
> improvements to build times.)
> >      I'd like to start in harmony6 level, and change directly with
> > the build scripts. It seems it does no harm to any other normal
> > build. After that, we can simply invoke:
> > \> ant build-select
> >      to get a select build under deploy-select/
> We normally do new work in trunk and merge to java6 and not the other
> way around?  Do you have a reason to do the work in java6 rather than
> java5/trunk?
> >      Any comments/suggestions? I'll commit a patch to the build
> > scripts if there is objection.
> "commit" if _no_ objections I assume? ;-)
> Regards,
> -Mark.


Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

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