Ok, thanks, Steve! That was indeed the missing piece to the puzzle.
So, does that mean that I have to always include the
${avalon.home}/runtime/index.xml in my build? Is there not some type of
minimum build that I can use, or is the runtime/index.xml always required?
Thanks!
> -----Original Message-----
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]
> Sent: July 29, 2004 1:31
> To: 'Avalon framework users'; [EMAIL PROTECTED]
> Subject: RE: Broken descriptor
>
>
>
>
> > -----Original Message-----
> > From: David Leangen [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, July 28, 2004 18:15
> > To: [EMAIL PROTECTED]
> > Subject: Broken descriptor
> >
> >
> > I somehow broke everything and can't figure out what I'm doing wrong.
> :-(
> >
> > This is the error I'm getting:
> >
> > Unable to locate a component type descriptor for the component class
> > [com.company.Component] in the classloader. Please verify that the
> > component classname is correct and that a component type descriptor is
> > included in a jar file available within the container classloader.
> >
> >
> > This is the block file generated (which seems ok to me! And everything
> > appears to be built correctly and exists in the repository.):
> >
> > <?xml version="1.0" encoding="ISO-8859-1"?>
> >
> > <container name="expedition-xml">
> >
> > <classloader>
> > <classpath>
> > <artifact>jar:expedition/lib/expedition-lib#0.0.1</artifact>
> > <artifact>jar:commons-logging/commons-logging#1.0.4</artifact>
> >
> <artifact>jar:commons-logging/commons-logging-api#1.0.4</artifact>
> >
> >
> <artifact>jar:avalon/framework/avalon-framework-api#SNAPSHOT</artifact>
> >
> >
> <artifact>jar:avalon/framework/avalon-framework-impl#SNAPSHOT</artifact>
> > <artifact>jar:junit/junit#3.8.1</artifact>
> > <artifact>jar:expedition/xml/expedition-xml#0.0.1</artifact>
> > </classpath>
> > </classloader>
> >
> > <component name="xmlChunkerComponent"
> class="com.company.Component"/>
> >
> > </container>
> >
> >
> >
> > This is the part in my build file that builds the block:
> >
> > <target name="build" depends="standard.build">
> > <x:block name="expedition-xml" embed="MAIN">
> > <x:component name="xmlChunkerComponent"
> > class="com.company.Component"/>
> > </x:block>
> > </target>
> >
> >
> > So, my questions are:
> >
> > 1. Any ideas what I'm doing wrong?
>
> 1.1. Are you generating the meta-info from you javadoc tags? You project
> definition should include a declaration on the Avalon-meta-tools plugin.
> For example:
>
> <project basedir="hello">
> <info>
> <group>avalon/tutorial</group>
> <name>avalon-tutorial-hello</name>
> </info>
> <dependencies>
> <include key="avalon-merlin-unit" runtime="false"/>
> <include key="avalon-framework-api" runtime="false"/>
> </dependencies>
> <plugins>
> <include key="avalon-meta-tools"/> <------------------
> </plugins>
> </project>
>
> The plugin will generate a .xinfo file for each component under the
> target/classes directory. The .xinfo files will also get packaged into
> your jar file. If the .xinfo files are there then you have something
> horribly wrong (such as jar files in directories that don't correspond
> to package names or some such thing). Also just the log when executing
> merlin for any warning messages.
>
> > 2. What does <x:block name="bla" embed="MAIN"> do, anyway? Even when
> I
> > played around with it, I couldn't notice how it affected the build.
>
> In addition to the creation of a standalone block under the
> target/deliverables/blocks directory, the block task can also generate a
> block definition into either the main target/classes directory, or the
> target/test-classes directory.
>
> The embed attribute take one of the following arguments:
>
> MAIN
>
> create the block definition under
> target/classes/BLOCK-INF/block.xml for inclusion within
> the main deliverable jar file - the block definition does
> not include a reference to the project jar because this is
> implied through the embedded status of the block
>
> TEST
>
> create the block definition under
> target/test-classes/BLOCK-INF/block.xml which allows
> for the separation of a test block from a classic embedded
> block
>
> Cheers, Steve.
>
>
> > Thanks!
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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]
