Steve,
First I figured I'd change the subject of the email and switch it over to the dev list
since this is going beyond existing usage.
Ok now it looks to me like we're trying to define the working set of parameters for an
embedding context. Correct me if I'm wrong but Merlin does not care exactly how the
jars are discovered or snarfed down. This will be different for each embedding
scenario. Why not just leave it upto the application to provide the set of operating
parameters for the kernel.
Perhaps these parameters required and optional can be supplied within a special bean
called an EmbeddingContext. Some of these optional parameters will have some defaults
and the bean constructor takes the required values.
I see things like the path to the local merlin repository as being required as well as
an url to a remote repo that is used to snarf down artifacts as they are needed. When
the required and optional parameters for embedding is defined then some very similar
code I think within the kernel-bootstrap project and the kernel-unit areas can be
consolidated. Basically the Merlin.java CLI program is another kernel embedding
scenario like the unit testing one et cetera. How do these ideas sound to you?
Basically leave it upto the descretion of the application to define the embedding
context parameters which are required to bootstrap the kernel.
I need to think about this some more and perhaps I should start writing some example
code and we can discuss it more.
Cheers,
Alex
> Stephen McConnell wrote:
>
> >
> >
> > [EMAIL PROTECTED] wrote:
> >
> >> Steve,
> >>
> >> You said,
> >>
> >>
> >>
> >>> There are two problems - (a) we need to add some code to resolve
> >>> MERLIN_HOME relative to the runtime environment so that we can link
> >>> to a Merlin system installation, and given that the embeddor was
> >>> written in response to a test case requirement ina Maven context -
> >>> well its not done yet - there is some code in the excalibur/event
> >>> util package that
> >>
> >>
> >> Is this similar to the commons discovery functionality? I looked
> >> into the event package and could not find the mentioned code - could
> >> you advise? Here is where I'm looking in the head:
> >>
> >> avalon-excalibur/event/src/java/org/apache/excalibur/event
> >>
> >>
> >
> > Take a look in org/apache/excalibur/util/system - basically a bunch of
> > platform sepecific handlers to do a specific command. In the event
> > example its getting the number of processors - in our case we want to
> > get the MERLIN_HOME value.
>
>
> Actually we need to go a touch more generic and handle arbitary
> environment variables. E.g. we will need to get things like
> MERLIN_HOME, MERLIN_USER_REPOSITORY, MERLIN_SYSTEM_REPOSITORY, etc. (the
> last two a sort of made up and represent environment variables the user
> can declare to override the location of the system and user repositories).
>
> MERLIN_HOME - should default to ${user.dir}/.merlin
> MERLIN_USER_REPOSITORY should default to MERLIN_HOME/repository
> MERLIN_SYSTEM_REPOSITORY should default to MERLIN_HOME/system
>
> Stephen.
>
> >
> >
> >>
> >>
> >>> does this sort of thing - and I figured an almost direct copy would
> >>> resolve the problem - secondly, (b) the reason why jars are not
> >>> being downloaded in the test case example is because I assumed that
> >>> maven.repo.remote is not null - but it seems that it is null -
> >>
> >>
> >> Just trying to understand - did you mean its null because maven makes
> >> it null?
> >>
> >
> > Yes - and I never noticed because my maven repo is always populated.
> > (or I'm requesting the wrong property).
> >
> >>
> >>
> >>> which means that the url[] for the remote hosts is not being setup
> >>> correctly (I just discovered this about 30 mins ago).
> >>>
> >>>
> >>
> >>
> >> BTW as a quick test I switched to using the user maven repo by just
> >> making a call to a new method that is basically the same as the
> >> getMavenRepositoryDirectory method on the AbstractMerlinTestCase
> >> class. It all worked like a champion. I however do see your need to
> >> generalize an approach.
> >
> >
> > Yep - the test case scenario has only validated things relative to a
> > maven context.
> > Generalization pending.
> >
> >>
> >>
> >>
> >>
> >>> Bottom line - a common embeddor/controller whatever should locate
> >>> the merlin system repository and boot from that - if it does not
> >>> exist we should be creating it. This is needed in all of the
> >>> embedded scenarios.
> >>>
> >>>
> >>
> >>
> >> So if I understand correctly a file system directory must exist or
> >> must be created to either access existing Merlin bootstrap jars or
> >> scarf em down from a remote repo. Based on embedding scenarios the
> >> means to get ahold of or 'discover' this existing Merlin repo or
> >> create one changes. We need a simple framework around this to
> >> control embedding behavior. I guess that's what you said but I just
> >> want to use my own words and have you correct me.
> >>
> >
> > You got it!
> >
> > Principal things:
> >
> > 1. the only time the maven repo is the default is in the testcase
> > scenario - all other cases we pull in via the merlin repository so
> > that we maintain a strict seperation between development repo and
> > runtime repo.
> > 2. keep the embeddor really small by only holding the core repository
> > bootstrap classes and api
> >
> > Cheers, Steve.
> >
> >
> >>
> >> Alex
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >
>
> --
>
> Stephen J. McConnell
> mailto:[EMAIL PROTECTED]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
