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
targets.
Will try the exclude list now.
2010/4/12 Mark Hindess <mark.hind...@googlemail.com>
>
> In message <t2x5c8e69f1004090121t70353ef6xe8c8851c9a3f2...@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
