Ok, I did some digging... It appears that the Artifact dependencies are
resolved and think they are on the classpath (with the correct jar file
references); however, the RealClassLoader does not appear to have one of the
dependencies listed... As a test, I passed the "-classpath" arguments to the
xjc2TaskAdapter, but that didn't seem to make any difference.
I thought maybe it was on the classpath but that something was wrong with my
plugin... so, I tried Kohsuke's plugin by adding:
<args>-Xinject-code</args>
to my pom.xml... I already had the jaxb-xjc on the classpath, so that should
have worked...
[INFO] failure in the XJC task. Use the Ant -verbose switch for more details
[INFO]
------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO]
------------------------------------------------------------------------
[INFO] unrecognized parameter -Xinject-code
[INFO]
------------------------------------------------------------------------
[INFO] Trace
unrecognized parameter -Xinject-code
at com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:409)
at com.sun.tools.xjc.XJC2Task.doXJC(XJC2Task.java:397)
at com.sun.tools.xjc.XJC2Task.execute(XJC2Task.java:332)
at com.sun.tools.xjc.maven2.XJCMojo.execute(XJCMojo.java:383)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(
DefaultPluginManager.java:412)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(
DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle
(DefaultLifecycleExecutor.java:475)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(
DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures
(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
DefaultLifecycleExecutor.java:273)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:589)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java
:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java
:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: com.sun.tools.xjc.BadCommandLineException: unrecognized parameter
-Xinject-code
at com.sun.tools.xjc.Options.parseArguments(Options.java:664)
at com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:407)
... 21 more
--- Nested Exception ---
com.sun.tools.xjc.BadCommandLineException: unrecognized parameter
-Xinject-code
at com.sun.tools.xjc.Options.parseArguments(Options.java:664)
at com.sun.tools.xjc.XJC2Task._doXJC(XJC2Task.java:407)
at com.sun.tools.xjc.XJC2Task.doXJC(XJC2Task.java:397)
at com.sun.tools.xjc.XJC2Task.execute(XJC2Task.java:332)
at com.sun.tools.xjc.maven2.XJCMojo.execute(XJCMojo.java:383)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(
DefaultPluginManager.java:412)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(
DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle
(DefaultLifecycleExecutor.java:475)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(
DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures
(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
DefaultLifecycleExecutor.java:273)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:589)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java
:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java
:430)
On 7/27/06, Malachi de Ælfweald <malachid_at_gmail.com> wrote:
>
> Regarding the includeSchemas problem....
> After much finagling around with repositories on the plugin pom.xml, I
> finally got it to build. Using it, it correctly found the schema
> directory... so sounds like the binary download version just needs rebuilt.
>
> Although there does seem to be a discrepency with the verbose flag...
>
> [INFO] verbose: true
> [INFO] Schema dependency:
> C:\devel\MimirDB\trunk\src\main\resources\org\eoti\spec\mimirdb\mimirdb-
> 1.0.xsd
> [INFO] pom dependency: C:\devel\MimirDB\trunk\pom.xml
> [INFO] XJC compile using schema:
> C:\devel\MimirDB\trunk\src\main\resources\org\eoti\spec\mimirdb\mimirdb-
> 1.0.xsd
> [INFO] build id of XJC is 2.0-04/28/2006 12:05 AM(kohsuke)-fcs
> [INFO] failure in the XJC task. Use the Ant -verbose switch for more
> details
>
> Secondary problem seems to be that it is not accepting the classpath
> provided my maven. IE: When compiling, maven sees my dependency; but when
> trying to link in my plugin (via the <args></args>) it isn't in the
> classpath (verified with temporary hack to the plugin code). Looking into
> it.
>
>
> Malachi
>
>
> On 7/25/06, Malachi de Ælfweald <malachid_at_gmail.com> wrote:
> >
> > Sorry it took so long to reply to this. I haven't had a chance to do any
> > development in awhile.
> > But, before continuing with the comments, I should point out some
> > changes I did today...
> > 1. newest mustang release
> > 2. newest jaxb release
> > 3. newest maven release
> > 4. newest subversion, intellij, tortoisesvn, etc
> > 5. newest maven-jaxb -plugin from this link on the main page:
> > In the meantime you can download the lastest plugin version from this
> > link<https://jaxb.dev.java.net/jaxb-maven2-plugin/maven-jaxb-plugin-1.0.zip>and expand the .zip contents into your local %HOMEPATH%/.m2/repository
> > directory.
> >
> > I've decided to move away from using reactor and making all my modules
> > completely seperate projects... As such, some slight changes to the
> > pom.xml files,etc... I've also changed my directory layout to match the
> > suggested layout per the Maven documentation and per the Maven-JAXB-
> > Plugin documentation. I'm trying to move to less "modified"
> > configurations.
> >
> > Ok, onto the comments...
> >
> > On 5/18/06, Malachi de Ælfweald < malachid_at_gmail.com> wrote:
> >
> > > On 5/17/06, Jonathan Johnson < jonjohnson_at_mail.com> wrote:
> > >
> > > > >> 1. it says that " includeSchemas" was not set, but I set it as
> > > > per
> > > > >> instructions (but told it to recurse subdirectories)
> > > >
> > > > You indeed found a problem (it was missing an important @parameter
> > > > tag).
> > > > The plugin has been fixed and reposted.
> > > > Instructions are here: http://jaxb.dev.java.net/jaxb-maven2-plugin/
> > >
> > >
> > > Kewl. I'll grab the new one.
> > >
> >
> > The new one seems to have the same problem... Specifically, per the
> > documentation:
> >
> > <includeSchemas>
> > <includeSchema>**/*.xsd</includeSchema>
> > </includeSchemas>
> > And the resulting output:
> > [INFO] includeSchemas: [*.xsd]
> >
> > Now to clarify here a second... My schema is:
> > C:\devel\MimirDB\trunk\src\main\resources\org\eoti\spec\mimirdb\mimirdb-
> > 1.0.xsd
> >
> > If I move it directly under main\resources, it works... In addition to
> > the output not showing "**/", it leads me to think the recursion is not
> > working.
> >
> >
> >
> > >> 2. instead of running under reactor, it tried to run on the outside
> > > > >> pom which has no source code -- and thus hard crashed the build
> > > >
> > > > I'm not clear on what you are describing here. I'm not sure of the
> > > > steps to
> > > > follow to reproduce this. Can you provide more details?
> > >
> > >
> > > Instructions are here: http://maven.apache.org/guides/getting-started/index.html#How%20do%20I%20build%20more%20than%20one%20project%20at%20once
> > > ?
> > >
> > > Generally, it follows like this.... the root project directory
> > > contains a pom.xml that contains a "<modules>" section. Each module
> > > specified a subproject directory, which contains it's own pom.xml
> > >
> > > In my case specifically, all my build setup is on the outside pom.xml,
> > > which has no source code itself. Then each child pom.xml has the very
> > > minimal settings (usually, which other subproject it depends on -- in order
> > > to allow maven to determine the correct order to build them).
> > >
> >
> > I'm no longer doing this, so that issue is moot.
> >
> > >> how do I enable an external jaxb plugin
> > > >
> > > > This was a feature for the next version. I would image a section in
> > > > the
> > > > configuration section like this...
> > > >
> > > > <classpaths>
> > > > <classpath>/path/to/jaxb-xjc.jar</classpath>
> > > > <classpath>/path/to/ plugin.jar</classpath>
> > > > </classpaths >
> > > >
> > > > Which in turn would call XJC2Task.setClasspath(...)
> > > >
> > > > But I'm not sure how to invoke the plugin methods as you can do in
> > > > an Ant
> > > > command
> > > >
> > > > <xjc ...>
> > > > <arg value="-Xinject-code" />
> > > > ... other nested elements ...
> > > > </xjc>
> > > >
> > > > Perhaps you or Kohsuke can advise me.
> > > >
> > > >
> > > > - Jonathan
> > >
> > >
> > > As I see it, there are two primary things we have to do. One, make
> > > sure that it is on the classpath (which is counter-intuitive for maven,
> > > since we got away from specifying classpaths); Two, to specify the -Xoption
> > > to actually get it called...
> > >
> > > Does the -Xoption require that vendor extensions are turned on?
> > > If so, then perhaps we change <extension>true</extension>
> > > to
> > > <extensions enabled="true">
> > > <extension>Xlocator</extension>
> > > </extensions>
> > >
> > > then, we just have to deal with it being on the classpath...
> > >
> >
> > I will be trying the -X <args> once I get the earlier problem fixed to
> > actually compile the schema.
> >
> >
> >
> >
> > Malachi
> >
> >
>