[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.
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]
