maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "dan tran" <dant...@gmail.com>
Subject Re: [m2] native plugin conventions?
Date Tue, 07 Mar 2006 16:18:58 GMT
Sorry bad name,   it is "uexe"

will fix the doc.

-D


On 3/7/06, Xavier Toth <txtoth@gmail.com> wrote:
>
> Thanks.
>
> Now when I try and build I'm getting the follwing error related to my use
> of the 'uxe' in packaging. I'm trying to build a Unix executable is this the
> correct package type?
>
> [ERROR] BUILD ERROR
> [INFO]
> ----------------------------------------------------------------------------
> [INFO] Cannot find lifecycle mapping for packaging: 'uxe'.
> Component descriptor cannot be found in the component repository:
> org.apache.maven.lifecycle.mapping.LifecycleMappinguxe.
> [INFO]
> ----------------------------------------------------------------------------
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Cannot find
> lifecycle mapping for packaging: 'uxe'.
>         at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.findMappingsForLifecycle
> (DefaultLifecycleExecutor.java:1033)
>         at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging
> (DefaultLifecycleExecutor.java:960)
>         at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings
> (DefaultLifecycleExecutor.java:943)
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
> (DefaultLifecycleExecutor.java:450)
>         at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures
> (DefaultLifecycleExecutor.java:303)
>         at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
> DefaultLifecycleExecutor.java:270)
>         at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
> DefaultLifecycleExecutor.java:139)
>         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:249)
>         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:585)
>         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.codehaus.plexus.component.repository.exception.ComponentLookupException:
> Component descriptor cannot be found in the component repository:
> org.apache.maven.lifecycle.mapping.LifecycleMappinguxe.
>         at org.codehaus.plexus.DefaultPlexusContainer.lookup(
> DefaultPlexusContainer.java:323)
>         at org.codehaus.plexus.DefaultPlexusContainer.lookup(
> DefaultPlexusContainer.java:440)
>         at org.apache.maven.execution.MavenSession.lookup(
> MavenSession.java:120)
>         at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.findMappingsForLifecycle
> (DefaultLifecycleExecutor.java:1026)
>         ... 17 more
>
>
>
> On 3/7/06, dan tran <dantran@gmail.com> wrote:
> >
> > If you have very simple native build ( single module), use java
> > convention
> > place all your source in src/main/native
> >
> > if you have complex build which supports multiple platforms, it is best
> > to
> > place source under
> > parent directory to provide uniform header and source access from all
> > sub
> > modules
> >
> > check out native-maven-plugin/src/int/jni
> >
> > If you have other sugesstion, please let me know
> >
> > Thanks
> >
> > -D
> >
> >
> > On 3/7/06, Xavier Toth <txtoth@gmail.com> wrote:
> > >
> > > I'm about to include the building of some C/C++ executables and
> > libraries
> > > to my existing Java centric build. I've looked at the docs for the
> > native
> > > plugin but it is unclear to me if it follows conventions (related to
> > > directory structure) similar to those I follow with my Java code? The
> > > example show the specification of the location and names of source
> > files, is
> > > this strictly necessary?
> > >
> > >
> > > Xavier
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message