On Mon, 12 Jul 2004, Stephen McConnell <[EMAIL PROTECTED]> wrote: > Stefan Bodewig wrote:
> The issue comes down to the conflict of interest between the two > following scenarios: > > (a) I stack the initial classloader with everything that is > needed (plugins, lib, directories, etc.) in which case > the system should work > > (b) I simulate the real runtime scenario by building classloader > hierarchies and through integration testing validate not only > the build integrity but also the integrity of runtime > descriptors Your "normal" Magic execution would be (b) while Gump should be (a), not? I'm not here to stop you. If you think that a Magic builder should work around build.sysclasspath handling, then do so. I'm pointing out problems we might face this way. > IMO - the real solution is to enable ant with repository based logic > and instead of inhibiting ant classloader logic - focus instead on > liberating ant such that classloaders can be created providing the > jar references are uris to repository artifacts. Repositories and Ant are orthogonal to me, I sure may be wrong, but I haven't been convinced yet. > A plugin to Magic is a project with build, test and runtime > dependencies that exports a definition of itself. The definition > includes the declaration of the classloader in terms of artifact > uris. OK, so Magic is in complete control of them, fine. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
