avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Merlin Component Service for Turbine
Date Mon, 03 Nov 2003 01:35:17 GMT

Eric Pugh wrote:

>Hi all,
>I have committed the first cut of the MerlinComponentService [1] by Peter
>Courcoux and added in a working unit test [2].  Here are my issues at this
>point with understanding Merlin.
>1) If you look at the unit test, I can run the HelloComponent from the Maven
>tutorial fine.  In fact, by adding it to the Turbine repo, Merlin nicely
>downloads and installs the jar!  Very handy.
>However...  I want to master all my jar dependencies in my project.xml file.
>That way, run I build the maven war task to build my WAR file to deploy, all
>my dependencies are included, versus this dynamic downloading from the
>block.xml files.  However, there doesn't seem to be built in any way to load
>all my jars from the WEB-INF/lib directory.  The DefaultFileRepository could
>be pointed at a web-inf/lib directory, but it wants to load things as
>WEB-INF/lib/{groupId}/jar/{artifactId}.  However, I could replace it with
>one that resolved them directly.

If you want to have local copies of jar files (merlin system and app) then
we should be populating the WEB-INF/ with both a system repository and an
application repository. Resolving against a flat /lib is not recommended
as jar names are scoped relative to a group and you quickly end up with
name conflicts in a flat structure.

>But, the other problem is that I can't seem to pass in my own classloader.
>I do most of my development in Eclipse, and one of the things I am used to
>with ECM is just including my jar in my classpath and having everything
>work.  But, because Merlin is using it's own classloader, it doesn't pick up
>the Eclipse classpath, therefore it has to download and install it someplace
>to use it.  (I think...)

In Merlin there is a strict isolation between container classes and 
classes.  ECM does not have this notion.  I don't know what would be 
to deal with this in Eclipse - but there are others here who use Eclipse and
Merlin who can probably help.

>2) If you look in the MerlinCompoenentServiceTest the second unit test won't
>run.  I am not sure how to load the TestComponent when it is part of the
>same code.  Or, does it have to be a seperate project?  I am used to writing
>components that are just part of my application classpath and source tree,
>not loaded from seperate jars.

I took a quick look at the build but was unable to run maven.  Looks 
like your assuming RC1 and I'm using beta-10 (RC1 has bugs related to 
doc generation) - so the following comments are related to just looking. 

First off - I strongly recommend - in fact I *very* *very* strongly 
recommend - that you do *not* include all the merlin system jar files in 
you project.xml.  An embedded merlin jar such as merlin-unit-3.2.2 
handles all of this automatically - you simply do not need to expose of 
this stuff - and in fact - your asking for problems within the maven 
classloader. What you should be doing is including just one application 
embeddor jar (e.g. turbine-merlin-1.x.jar).  That jar would contain the 
kernel bootstrap which in turn builds a classloader heirachy that is 
seperate and independent of the maven classloader. 

Once you have that in place - you simply provide component deployment 
dirtectives to the kernel it establishes.  Those directives can be 
directories, jar files, url to remotely located deployment descriptors.  
It is in the deployment descriptor that you reference something like 

Concerning the test case failure - can you post the error report?

>3) Integrating ECM components.  I am looking at the various changes, and to
>use a component that was compatible with ECM in Merlin requires some
>signficant changes.  I guess the big issue is the need for the .xinfo file.
>If I have an existing jarred up ECM component that I want to use in Merlin.
>Can I just write by hand the .xinfo file?  


>How do I get it to load?  Just
>add into my /classes directory the full path to the class name and put the
>.xinfo there?  

Yes - if - and only if - the directory containing the xinfo file is 
included in the classpath declaration for a container in you deployment 
descriptor (block.xml).

>So, the .class file is loaded from the jar, but the .xinfo
>loads form the /classes directory?

Yep - its possible - providing your container classpath contains both.

>4) Running unit tests inside of Eclipse.  I discovered one issue, which is
>that the AbstractMerlinTestCase expects a System property like this in the
>getBaseDirectory method.  I'm guessing because it is oriented towards Maven:
>	String basedir = System.getProperty( "basedir" );
>However, in Eclipse this isn't provided, therefore it fails with an NPE.
>Now, I think the AbstractMerlinTestCase could do something like:
>	if(basedir==null){
>		basedir = new File(".").toString()
>	}
>   I think it is crucial to be able to run unit tests via the IDE debugger.

It should be possible to update the abstract unit test form this sort of 

>Overall, I can definitly see the niceness of having a single Merlin
>repository on a machine for multiple applications.  However, I think for
>many of the Turbine users, they are going to want to instead have all their
>jars included in the war file, or at least, have the option.  I like the
>repository as it'll make my WAR files much smaller and look forward to when
>I can set up a single repo to load from.

Suggestion for now is to leverage the shared repository - get things 
working and validated (it is simply simpler).  Next step is to build a 
war file and aggregating the jar files into system and application 
repositories in the war file - and that can be done with a bit of jelly 
in the maven.xml.

Last comment - we are in the process of improving the kernel embedding 
side of things and will be refactoring all of the embedded scenarios to 
use a common defaults and parameterization model.  This will make things 
a lot simpler - in fact the TurbineMerlinComponentService will probably 
shrink down to only a few lines of code - and as a result - the stuff 
such classloader establishment will be taken care of automatically.

Cheers, Steve.

>Eric Pugh
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org


Stephen J. McConnell

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message