After talking to folks on IRC, I tried SUN JDK and it works!
When I switch back to IBM JDK, then it fails with the same error. It seems
that the assembly plugin has some references to "com.sun.*" which are only
shipped with SUN JDK.
Here's the stacktrace: (Caused by: java.lang.NoClassDefFoundError:
org.codehaus.plexus.archiver.Archiver, Exception at
java.lang.J9VMInternals.verifyImpl(Native Method)...)
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in
the pl
ugin manager executing goal
'org.apache.maven.plugins:maven-assembly-plugin:2.2-
SNAPSHOT:single': Unable to find the mojo
'org.apache.maven.plugins:maven-assemb
ly-plugin:2.2-SNAPSHOT:single' in the plugin
'org.apache.maven.plugins:maven-ass
embly-plugin'
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:538)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.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:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
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: org.apache.maven.plugin.PluginManagerException: Unable to find
the mo
jo 'org.apache.maven.plugins:maven-assembly-plugin:2.2-SNAPSHOT:single' in
the p
lugin 'org.apache.maven.plugins:maven-assembly-plugin'
at
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(Defaul
tPluginManager.java:533)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:390)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:534)
... 16 more
Caused by:
org.codehaus.plexus.component.repository.exception.ComponentLookupExc
eption: Unable to lookup component
'org.apache.maven.plugin.Mojoorg.apache.maven
.plugins:maven-assembly-plugin:2.2-SNAPSHOT:single', it could not be created
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContai
ner.java:335)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContai
ner.java:440)
at
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(Defaul
tPluginManager.java:524)
... 18 more
Caused by:
org.codehaus.plexus.component.factory.ComponentInstantiationException
: Could not instanciate component: role: 'null', implementation:
'org.apache.mav
en.plugin.assembly.SingleAssemblyMojo'
at
org.codehaus.plexus.component.factory.java.JavaComponentFactory.makeE
xception(JavaComponentFactory.java:77)
at
org.codehaus.plexus.component.factory.java.JavaComponentFactory.newIn
stance(JavaComponentFactory.java:62)
at
org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(De
faultPlexusContainer.java:1464)
at
org.codehaus.plexus.component.manager.AbstractComponentManager.create
ComponentInstance(AbstractComponentManager.java:93)
at
org.codehaus.plexus.component.manager.PerLookupComponentManager.getCo
mponent(PerLookupComponentManager.java:48)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContai
ner.java:331)
... 20 more
Caused by: java.lang.NoClassDefFoundError:
org.codehaus.plexus.archiver.Archiver
Exception
at java.lang.J9VMInternals.verifyImpl(Native Method)
at java.lang.J9VMInternals.verify(J9VMInternals.java:55)
at java.lang.J9VMInternals.verify(J9VMInternals.java:53)
at java.lang.J9VMInternals.verify(J9VMInternals.java:53)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:124)
at java.lang.Class.newInstanceImpl(Native Method)
at java.lang.Class.newInstance(Class.java:1263)
at
org.codehaus.plexus.component.factory.java.JavaComponentFactory.newIn
stance(JavaComponentFactory.java:44)
... 24 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8 seconds
[INFO] Finished at: Tue Jul 11 13:29:34 PDT 2006
[INFO] Final Memory: 7M/23M
[INFO] ------------------------------------------------------------------------
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, July 11, 2006 12:11 PM
Subject: Re: Build problems
On Jul 11, 2006, at 11:18 AM, Raymond Feng wrote:
Hi,
Now I can build all the projects except "runtime/standalone" (same
problem as I reported before).
Unfortunately, it worked for me with a clean repo (rm ~/.m2/repository).
Can you remove either the whole repo or the maven-assembly-plugin
directory and try again.
The databinding-sdo project already has everthing from sdo project so
the sdo folder can be safely removed. With the databinding-sdo
referencing the incubating-M1 version of SDO, I can build it
successfully as well (as expected, I need to have the SDO jars in local
maven repo).
Now it seems that we fetch SDO projects (except the spec one) into the
sandbox, but they are not in the main build. What's the intension here?
My problem with sdo was that I didn't have a copy locally so it
downloaded the M1 version from the repo. That didn't have the recent
changes in it.
When we release something, we need to modify the version in the trunk to
be a SNAPSHOT of the /next/ version so that locally built stuff does not
conflict with what is in the online repo. We now have TUSCANY-537 to make
that change in the sdo trunk.
I have added an external reference to it from the sandbox code so when
you update sandbox/jboynes you will get a live copy of the sdo tree. Once
we've fixed the version numbers we can include that in the sandbox build
just like it is included in trunk. At that point we can re-enable the
databinding code.
--
Jeremy
---------------------------------------------------------------------
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]
