You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/07/11 20:00:57 UTC
Re: Build problems
This should be fixed now. I have still commented out the databinding
and sdo stuff.
The tree builds for me after I remove the local m2 repository. It
does take a couple of goes due to problems with downloads and plugins.
Please let me know if there are still issues.
--
Jeremy
On Jul 11, 2006, at 10:51 AM, Raymond Feng wrote:
> Hi,
>
> We have the following dependency in jboynes/sca/pom.xml
>
> <dependency>
> <groupId>org.apache.geronimo.specs</groupId>
> <artifactId>geronimo-commonj_1.1_spec</artifactId>
> <version>1.0.1-SNAPSHOT</version>
> <scope>provided</scope>
> </dependency>
>
> I found that http://people.apache.org/repository/
> org.apache.geronimo.specs/poms/geronimo-commonj_1.1_spec-1.0.1-
> SNAPSHOT.pom has the following section:
>
> <parent>
> <artifactId>specs</artifactId>
> <groupId>org.apache.geronimo.specs</groupId>
> <version>1.2-SNAPSHOT</version>
> </parent>
>
> And http://people.apache.org/repository/org.apache.geronimo.specs/
> poms/specs-1.2-SNAPSHOT.pom does NOT exist.
>
> I tried org.apache.geronimo.specs:geronimo-commonj_1.1_spec:1.0.-
> SNAPSHOT and it works.
>
> Thanks,
> Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Build problems
Posted by Raymond Feng <en...@gmail.com>.
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" <jb...@apache.org>
To: <tu...@ws.apache.org>
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Build problems
Posted by Jeremy Boynes <jb...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Build problems
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Now I can build all the projects except "runtime/standalone" (same problem
as I reported before).
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?
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, July 11, 2006 11:00 AM
Subject: Re: Build problems
> This should be fixed now. I have still commented out the databinding and
> sdo stuff.
>
> The tree builds for me after I remove the local m2 repository. It does
> take a couple of goes due to problems with downloads and plugins.
> Please let me know if there are still issues.
>
> --
> Jeremy
>
> On Jul 11, 2006, at 10:51 AM, Raymond Feng wrote:
>
>> Hi,
>>
>> We have the following dependency in jboynes/sca/pom.xml
>>
>> <dependency>
>> <groupId>org.apache.geronimo.specs</groupId>
>> <artifactId>geronimo-commonj_1.1_spec</artifactId>
>> <version>1.0.1-SNAPSHOT</version>
>> <scope>provided</scope>
>> </dependency>
>>
>> I found that http://people.apache.org/repository/
>> org.apache.geronimo.specs/poms/geronimo-commonj_1.1_spec-1.0.1-
>> SNAPSHOT.pom has the following section:
>>
>> <parent>
>> <artifactId>specs</artifactId>
>> <groupId>org.apache.geronimo.specs</groupId>
>> <version>1.2-SNAPSHOT</version>
>> </parent>
>>
>> And http://people.apache.org/repository/org.apache.geronimo.specs/
>> poms/specs-1.2-SNAPSHOT.pom does NOT exist.
>>
>> I tried org.apache.geronimo.specs:geronimo-commonj_1.1_spec:1.0.-
>> SNAPSHOT and it works.
>>
>> Thanks,
>> Raymond
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org