I said copy what's in polyglot. I just assumed you would look at delegating model processor.
You create a Mapping, Reader and Writer. The Mapping is discovered and injected into Polyglot. Polyglot walks through the Mappings and if a particular mapping can accept processing the model input the Mapping grabs its associated Reader and builds the Model object. Copy the polyglot-groovy or polyglot-jruby module. Build it, add it to the assembly so it's on the classpath and discovered and it should work. On Oct 14, 2010, at 4:11 PM, Mike Lenner wrote: > It seems that overriding MavenCli.createModelProcessor as shown below > is incorrect. That will change the ModelProcessor used by MavenCli to > *locate* the build file, but not the ModelProcessor used by > DefaultModelBuilder to *read* the build file and generate a Model. > > So, following Polyglot, it actually seems like my own ModelProcessor > needs to be inserted into the plexus container manually to be used by > the DefaultModelBuilder. Is this correct? > > ## From Polygloy: > > // HACK: Wedge our processor in as the default > final ComponentDescriptor<?> source = > container.getComponentDescriptor( > ModelProcessor.class.getName(), "polyglot" ); > final ComponentDescriptor<?> target = > container.getComponentDescriptor( > ModelProcessor.class.getName(), "default" ); > target.setImplementation( source.getImplementation() ); > > On Wed, Oct 6, 2010 at 6:05 PM, Jason van Zyl <[email protected]> wrote: >> Copy what's in Polyglot is what will work for now. At some point in the >> future we can dynamically load those extensions but they won't right now. So >> adding a JAR with your model reader/writer will work. >> >> On Oct 6, 2010, at 5:19 PM, Mike Lenner wrote: >> >>> All - >>> >>> I'm trying to support my company's migration to maven 3.0. In doing >>> so, I'd like for the existing XML build files (our own schema) to >>> continue to work, just with Maven reading them in. Our legacy build >>> files are fairly simple and map very easily to a pom. >>> >>> My plan is to follow the model of pmaven-cli. That is, create a maven >>> binary specific to my company (that I'll distribute) which uses my own >>> ModelReader to process the old, legacy build files. >>> >>> 1. Does this sound like a reasonable approach? >>> >>> 2. Am I on the right track with this: >>> >>> public class MyCompayMavenCli extends MavenCli { >>> >>> @Override >>> protected ModelProcessor createModelProcessor( PlexusContainer >>> container ) throws ComponentLookupException { >>> // create a new ModelProcessor which is just like >>> DefaultModelProcessor except it uses >>> // a custom ModelReader. >>> } >>> } >>> >>> Thanks, >>> Mike >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> believe nothing, no matter where you read it, >> or who has said it, >> not even if i have said it, >> unless it agrees with your own reason >> and your own common sense. >> >> -- Buddha >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------
