native cmds and libs in the module library
Alan.Bateman at oracle.com
Tue Jan 24 06:15:56 PST 2012
On 20/01/2012 17:56, Chris Hegarty wrote:
> Thanks Mandy,
> You are correct. I was storing absolute paths.
> Updated webrev:
> - Paths to 'jmod create -L lib -natlib <dir> ...' are resolved
> relative to the current working dir, as you would expect.
> - natlib, natcmd, config, paths are stored relative to the module
> library root, in the libraries metadata.
> - The per module 'files' contains paths relative to the modules
> install directory.
> - I made most of the specific code suggestions you said, with the
> exception that natlibs, natcmds, and configs can still be null
> in SimpleLibrary. I use this to differentiate between a passed
> path and a per module path.
I think this quite good.
Can you briefly summarize how one would use this on Windows? I assume it
requires specifying the --natcmd and --natlib to be the same directory.
In the simple library layout I added a flags word some time ago and it
has many spare bits. Rather than storing 0 or 1 before each path then an
alternative would be to use some of the spare bits.
A minor nit but the code style with if-then-else is a bit inconsistent.
Librarian.Create.go are just a couple of examples that jump out (there
are many more).
A general comment is that we'll need to go over this again once we get
to clean-up the implementation, improve performance, make library
operations atomic, etc. I mention this because what we have now is a bit
inefficient and there's also quite a bit of hopping between new and old
APIs. It will need a major clean-up at some point.
On the tests then I think an important test to include is a test that
attempts to install a library or binary outside of the bin and lib
trees. I think the validation code that you've added will catch this but
I think a test is important.
More information about the jigsaw-dev