On 9 January 2008 at 19:07, "Alexey Varlamov" <[EMAIL PROTECTED]> wrote: > Folks, > > We did a few iterations refactoring the subject - let's have one more access > ;). > Why? There was a desire to have the following: > 1) More fine-grained control over dependencies to empower modularity; > 2) Unified approach and shared scripts across Harmony modules - VMs, > classlib, jdktools; > 3) Reduce duplication of resources (traffic, space, etc) between > modules within the same workspace; > I'd also add 4) If possible, reuse resources in different workspaces. > This would be quite handy for committing purposes and for > multi-platform development.
I like all of the above but would add Tim's suggestion from a few weeks back which I think was something like: 5) Move binary dependencies - like all the icu libs - from the enhanced to the standard tree in svn and download them via http as we do other dependencies during the fetch-depends stage. A nice-to-have but not necessarily essential for a first approximation: 6) Ability to re-use system installed versions of dependencies - both at build time and ideally at run time if the dependencies are stable. For instance, my machine already has the 8 megs of dejavu fonts installed (because openoffice uses them). I fool the build in to using them to avoid the download but this should be made easier. At build time they [a subset actually] are copied into the runtime and it might be nice to avoid this if possible - although this part is easier to workaround during debian/rpm packaging. > Geir once introduced "common_resources" module, which IMO was a step > in the right direction, but it was not fully adapted thus not used > properly. Now the new build for DRLVM is a good stimulus and > opportunity to accomplish the task. > > I suggest this time we deprive the classlib of it's state of Harmony > umbilicus and make the "common_resources" a "primordial" module ;) Does this mean the: svn co http://svn.../classlib/trunk classlib cd classlib ant fetch-depends ant use case will cease to work? It would be nice if we didn't have to break this. Perhaps we can have a classlib/trunk/common_resources placeholder and if a h(armon)y.common.resources properties is not defined then svn switch this placeholder to the correct copy (in a similar manner to the way the federation build works). Users will multiple work spaces (or the federation build.xml) could set the hy.common.resources property to a shared copy? > The idea is to move all shared properties, definitions, tasks and > files to the single location. Besides, the same module should be used > as a central repository for downloading and storing external files. > So, each module would "request" needed resources via standard > facilities (ant tasks), automatically reusing duplicates. And the same > "common_resources" instance can be imported to several workspaces and > even shared between developers. > > How? > 1) Roughly, the following files need to be moved from classlib to > common_resources: > make/properties.xml > make/depends.properties # ? move only shared items to > simplify maintenance > depends/** except depends/files/ # ? there are several libs/zips + > make definitions being shared As I mentioned above, I think the platform specific files should be moved to the standard (not enhanced tree) for download with fetch-depends or whatever replaces it. And we should create the bcprov-noidea.jar in the standard tree rather than downloading it from bouncycastle to comply with their request to reduce load on their servers. > Closer comparison of other make/build-*.xml ant scripts in classlib > and jdktools may give more candidates. > 2) Implement tasks or macros for fetching resources, storing them and > providing uniform access: common_resources/download.xml svn.xml etc > 3) Refactor make/depends.xml in respective modules to resolve bullet #1. > > Surely the plan is very sketchy, we need to agree on general direction first. > Waiting for your comments/objections impatiently :) Thanks very much for kicking off this discussion. -Mark.
