You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Jian.Wu" <he...@gmail.com> on 2006/03/29 03:21:09 UTC

Re: Should all maven-[x]-plugin have skip parameter like surefire-plugin

Hi,

> I'd suggest you should also be providing a custom packaging
> "my-rar" or something more specific :) In your own words you 
> want to create your "own packaging"

Yes. This is what I want. But, my own packaging will also be 
"rar" since "my-rar" will be a "rar" specific for OC4J as an example.

If I renamed as <packaging>my-rar</package> instead of "rar",
I'll assume that "Ear Plugin" will not consume it since it is not a 
"RarModule". 

Even though I might have to write both Ear Plugin and Rar Plugin 
under my specific requirement. I still think that would be a bad idea 
that I have to write all the J2EE packaging plugins just because
I have to do some specific thing in one type of J2EE Component.

More, in general, it should be configurable or customizable by wiring 
build life cycle phase or packaging type with default plugin executed. 
It is the same that you might want to use your own XML Parser instead 
of the default xml parser from JAXP.

Maven should enforce a rigid build life cycle but not a list of maven 
plugins should be executed.

My two cents:-)

Jian 
 
 



--
View this message in context: http://www.nabble.com/Should-all-maven--x--plugin-have-skip-parameter-like-surefire-plugin--t1358571.html#a3641687
Sent from the Maven - Dev forum at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Should all maven-[x]-plugin have skip parameter like surefire-plugin

Posted by "Jian.Wu" <he...@gmail.com>.
Sorry for the typo. "this is not a bug of Rar Plugin since Par Plugin only
executes 
rar goal at package phase" should be "this is not a bug of Rar Plugin since
Rar Plugin 
only executes rar goal at package phase"


--
View this message in context: http://www.nabble.com/Should-all-maven--x--plugin-have-skip-parameter-like-surefire-plugin--t1358571.html#a3645848
Sent from the Maven - Dev forum at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Should all maven-[x]-plugin have skip parameter like surefire-plugin

Posted by "Jian.Wu" <he...@gmail.com>.
Hi Brat,

> > Would you suggest that I can specify a packaging "my-rar" in my rar
> pom.xml,
> > but in my ear pom.xml, I can specify type as "rar" when I define my  rar
> > project
> > as a dependency project?
>
> Yes, I think so. 

Thanks a lot for the tip! I'll definitely give a try.

> > 2). A rar project for packaging which depends on a separate jar project,
> > assuming one jar would
> >      be packaged into multiple rars with different configurations. this
> will
> > run into problem with
> >      "mvn compile" or " mvn test" since this rar project does not create
> > "target/classes". This
> >      can be worked out by introducing a rar-helper plugin to create an
> empty
> > target/classes
> >      directory at "process-resources" phase.
>
> Seems like a bug in the rar plugin if it chokes when target/classes is
> empty. Not sure if you are including the jar itself, or an unpacked
> version of the jar, but both are possible today. 

No, this is not a bug of Rar Plugin since Par Plugin only executes rar goal
at package phase.
Please see the detail at
http://www.nabble.com/-M2-Maven-Ear-Plugin-did-not-recognize-the-RAR-Sub-Project-t1327696.html#a3545087

Best regards,

Jian
--
View this message in context: http://www.nabble.com/Should-all-maven--x--plugin-have-skip-parameter-like-surefire-plugin--t1358571.html#a3645828
Sent from the Maven - Dev forum at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Should all maven-[x]-plugin have skip parameter like surefire-plugin

Posted by "Jian.Wu" <he...@gmail.com>.
Hi Brett,

> Did you first do mvn install on the first project? Where did it end up? 

No. I don't want to do "mvn install". Both rar and ear are two module
project under
the same parent pom project.

Actually, I end-up create my own "my-rar" package type and since
maven-ear-plugin
could not recognize "my-rar" artifact I also create my own "my-ear" package.

Thanks a lot for the help!

Jian
--
View this message in context: http://www.nabble.com/Should-all-maven--x--plugin-have-skip-parameter-like-surefire-plugin--t1358571.html#a3825872
Sent from the Maven - Dev forum at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Should all maven-[x]-plugin have skip parameter like surefire-plugin

Posted by Brett Porter <br...@apache.org>.
Did you first do mvn install on the first project? Where did it end up?

I can see this will probably be a limitation - it may not be able to
associate the built artifact of the first project with the latter in the
reactor, but I'm not sure. Still, it should definitely work if you
install it first and it goes to the right location.

Cheers,
Brett

Jian.Wu wrote:
> Hi Brett,
> 
> Sorry to misspell your name in the previous emails.
> 
>>> Would you suggest that I can specify a packaging "my-rar" in my rar
>> pom.xml,
>>> but in my ear pom.xml, I can specify type as "rar" when I define my  rar
>>> project
>>> as a dependency project?
>> Yes, I think so.
> 
> I did give a try. I don't have problem to introduce new "asw-rar" package
> and build rar out
> of it in my rar project pom.xml as the following:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   <groupId>oracle.ias.messaging.ns</groupId>
>    <artifactId>xmpp-adapter</artifactId>
>    <version>1.0-SNAPSHOT</version>
>    <packaging>asw-rar</packaging>
>    <!-- ... ... -->
> 
>    <plugin>
>         <groupId>oracle.ias.wireless.maven2.plugins</groupId>
>         <artifactId>asw-rar-plugin</artifactId>
>         <extensions>true</extensions>
>         <version>1.0-SNAPSHOT</version>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> But, when I specify this asw-rar project in my ear project pom.xml as:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>      <dependency>
>        <groupId>oracle.ias.messaging.ns</groupId>
>        <artifactId>xmpp-adapter</artifactId>
>        <version>1.0-SNAPSHOT</version>
>        <type>rar</type>
>      </dependency>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~     
> 
> "mvn compile" failed with the following error messages:
> ================================================
> [ERROR] BUILD ERROR
> [INFO]
> ----------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
> 
> required artifacts missing:
>   oracle.ias.messaging.ns:xmpp-adapter:rar:1.0-SNAPSHOT
> 
> for the artifact:
>   oracle.ias.messaging.ns:ns-ear:ear:1.0-SNAPSHOT
> 
> from the specified remote repositories:
>   central (http://repo1.maven.org/maven2),
>   internal-http-repository
> (http://jianwu-pc2.us.oracle.com/maven2repository/rep
> ositoryroot),
>   http-repository
> (http://jianwu-pc2.us.oracle.com/maven2repository/repositoryro
> ot)
> 
> 
> [INFO]
> ----------------------------------------------------------------------------
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: required artifacts
> missi
> ng:
>   oracle.ias.messaging.ns:xmpp-adapter:rar:1.0-SNAPSHOT
> 
> for the artifact:
>   oracle.ias.messaging.ns:ns-ear:ear:1.0-SNAPSHOT
> 
> from the specified remote repositories:
>   central (http://repo1.maven.org/maven2),
>   internal-http-repository
> (http://jianwu-pc2.us.oracle.com/maven2repository/rep
> ositoryroot),
>   http-repository
> (http://jianwu-pc2.us.oracle.com/maven2repository/repositoryro
> ot)
> 
>         at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:548)
>         at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
> fecycle(DefaultLifecycleExecutor.java:472)
>         at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
> ltLifecycleExecutor.java:451)
>         at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
> dleFailures(DefaultLifecycleExecutor.java:303)
>         at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
> ts(DefaultLifecycleExecutor.java:270)
>         at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.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(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         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.artifact.resolver.ArtifactResolutionException:
> requi
> red artifacts missing:
>   oracle.ias.messaging.ns:xmpp-adapter:rar:1.0-SNAPSHOT
> 
> for the artifact:
>   oracle.ias.messaging.ns:ns-ear:ear:1.0-SNAPSHOT
> 
> from the specified remote repositories:
>   central (http://repo1.maven.org/maven2),
>   internal-http-repository
> (http://jianwu-pc2.us.oracle.com/maven2repository/rep
> ositoryroot),
>   http-repository
> (http://jianwu-pc2.us.oracle.com/maven2repository/repositoryro
> ot)
> 
>         at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
> nsitively(DefaultArtifactResolver.java:251)
>         at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
> nsitively(DefaultArtifactResolver.java:211)
>         at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
> nsitively(DefaultArtifactResolver.java:182)
>         at
> org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende
> ncies(DefaultPluginManager.java:1120)
>         at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:369)
>         at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:531)
>         ... 16 more
> [INFO]
> ----------------------------------------------------------------------------
> [INFO] Total time: 3 seconds
> [INFO] Finished at: Wed Mar 29 11:57:50 PST 2006
> [INFO] Final Memory: 3M/7M
> [INFO]
> ----------------------------------------------------------------------------
> ================================================
> 
> Any suggestion to work around this issue?
> 
> Thanks a lot for the help!
> 
> Jian
> 
> 
> 
> --
> View this message in context: http://www.nabble.com/Should-all-maven--x--plugin-have-skip-parameter-like-surefire-plugin--t1358571.html#a3657576
> Sent from the Maven - Dev forum at Nabble.com.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Should all maven-[x]-plugin have skip parameter like surefire-plugin

Posted by "Jian.Wu" <he...@gmail.com>.
Hi Brett,

Sorry to misspell your name in the previous emails.

> > Would you suggest that I can specify a packaging "my-rar" in my rar
> pom.xml,
> > but in my ear pom.xml, I can specify type as "rar" when I define my  rar
> > project
> > as a dependency project?
>
> Yes, I think so.

I did give a try. I don't have problem to introduce new "asw-rar" package
and build rar out
of it in my rar project pom.xml as the following:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  <groupId>oracle.ias.messaging.ns</groupId>
   <artifactId>xmpp-adapter</artifactId>
   <version>1.0-SNAPSHOT</version>
   <packaging>asw-rar</packaging>
   <!-- ... ... -->

   <plugin>
        <groupId>oracle.ias.wireless.maven2.plugins</groupId>
        <artifactId>asw-rar-plugin</artifactId>
        <extensions>true</extensions>
        <version>1.0-SNAPSHOT</version>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

But, when I specify this asw-rar project in my ear project pom.xml as:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     <dependency>
       <groupId>oracle.ias.messaging.ns</groupId>
       <artifactId>xmpp-adapter</artifactId>
       <version>1.0-SNAPSHOT</version>
       <type>rar</type>
     </dependency>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~     

"mvn compile" failed with the following error messages:
================================================
[ERROR] BUILD ERROR
[INFO]
----------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

required artifacts missing:
  oracle.ias.messaging.ns:xmpp-adapter:rar:1.0-SNAPSHOT

for the artifact:
  oracle.ias.messaging.ns:ns-ear:ear:1.0-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  internal-http-repository
(http://jianwu-pc2.us.oracle.com/maven2repository/rep
ositoryroot),
  http-repository
(http://jianwu-pc2.us.oracle.com/maven2repository/repositoryro
ot)


[INFO]
----------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: required artifacts
missi
ng:
  oracle.ias.messaging.ns:xmpp-adapter:rar:1.0-SNAPSHOT

for the artifact:
  oracle.ias.messaging.ns:ns-ear:ear:1.0-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  internal-http-repository
(http://jianwu-pc2.us.oracle.com/maven2repository/rep
ositoryroot),
  http-repository
(http://jianwu-pc2.us.oracle.com/maven2repository/repositoryro
ot)

        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:548)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:472)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:451)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:303)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:270)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.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(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        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.artifact.resolver.ArtifactResolutionException:
requi
red artifacts missing:
  oracle.ias.messaging.ns:xmpp-adapter:rar:1.0-SNAPSHOT

for the artifact:
  oracle.ias.messaging.ns:ns-ear:ear:1.0-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  internal-http-repository
(http://jianwu-pc2.us.oracle.com/maven2repository/rep
ositoryroot),
  http-repository
(http://jianwu-pc2.us.oracle.com/maven2repository/repositoryro
ot)

        at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
nsitively(DefaultArtifactResolver.java:251)
        at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
nsitively(DefaultArtifactResolver.java:211)
        at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
nsitively(DefaultArtifactResolver.java:182)
        at
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende
ncies(DefaultPluginManager.java:1120)
        at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:369)
        at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:531)
        ... 16 more
[INFO]
----------------------------------------------------------------------------
[INFO] Total time: 3 seconds
[INFO] Finished at: Wed Mar 29 11:57:50 PST 2006
[INFO] Final Memory: 3M/7M
[INFO]
----------------------------------------------------------------------------
================================================

Any suggestion to work around this issue?

Thanks a lot for the help!

Jian



--
View this message in context: http://www.nabble.com/Should-all-maven--x--plugin-have-skip-parameter-like-surefire-plugin--t1358571.html#a3657576
Sent from the Maven - Dev forum at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Should all maven-[x]-plugin have skip parameter like surefire-plugin

Posted by Brett Porter <br...@apache.org>.
Jian.Wu wrote:
> Hi Brat,
> 
> Thanks a lot for your quick reply!
> 
>> I'm pretty sure that the rars generated can still have a dependency type
>> of rar - the type != packaging.
> 
> Would you suggest that I can specify a packaging "my-rar" in my rar pom.xml,
> but in my ear pom.xml, I can specify type as "rar" when I define my  rar
> project 
> as a dependency project? 

Yes, I think so.

> 
>> What exactly is it that you need to do that it can't?
> 
> Generally, we want to create a list of ArcheTypes defining a list of
> standard project structures.
> For rar, we need two types of rar projects: 

Creating archetypes doesn't require a custom plugin, so its just whether
1 & 2 are possible now.

> 
> 1). A rar project which contains the source code and will generate both jar
> and rar file at the 
>     end. This actually can be done by a RAR+Jar Plugin

This should be possible with the current RAR plugin?

> 
> 2). A rar project for packaging which depends on a separate jar project,
> assuming one jar would 
>      be packaged into multiple rars with different configurations. this will
> run into problem with 
>      "mvn compile" or " mvn test" since this rar project does not create
> "target/classes". This 
>      can be worked out by introducing a rar-helper plugin to create an empty
> target/classes 
>      directory at "process-resources" phase.

Seems like a bug in the rar plugin if it chokes when target/classes is
empty. Not sure if you are including the jar itself, or an unpacked
version of the jar, but both are possible today.

Cheers,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Should all maven-[x]-plugin have skip parameter like surefire-plugin

Posted by "Jian.Wu" <he...@gmail.com>.
Hi Brat,

Thanks a lot for your quick reply!

> I'm pretty sure that the rars generated can still have a dependency type
> of rar - the type != packaging.

Would you suggest that I can specify a packaging "my-rar" in my rar pom.xml,
but in my ear pom.xml, I can specify type as "rar" when I define my  rar
project 
as a dependency project? 

> What exactly is it that you need to do that it can't?

Generally, we want to create a list of ArcheTypes defining a list of
standard project structures.
For rar, we need two types of rar projects: 

1). A rar project which contains the source code and will generate both jar
and rar file at the 
    end. This actually can be done by a RAR+Jar Plugin

2). A rar project for packaging which depends on a separate jar project,
assuming one jar would 
     be packaged into multiple rars with different configurations. this will
run into problem with 
     "mvn compile" or " mvn test" since this rar project does not create
"target/classes". This 
     can be worked out by introducing a rar-helper plugin to create an empty
target/classes 
     directory at "process-resources" phase.

Obviously, it would be very nice that there will be one Rar Plugin doing all
of these things.

Hope these information are helpful. 

Best regards,

Jian




--
View this message in context: http://www.nabble.com/Should-all-maven--x--plugin-have-skip-parameter-like-surefire-plugin--t1358571.html#a3642125
Sent from the Maven - Dev forum at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Should all maven-[x]-plugin have skip parameter like surefire-plugin

Posted by Brett Porter <br...@apache.org>.
Jian.Wu wrote:
> Yes. This is what I want. But, my own packaging will also be 
> "rar" since "my-rar" will be a "rar" specific for OC4J as an example.
> 
> If I renamed as <packaging>my-rar</package> instead of "rar",
> I'll assume that "Ear Plugin" will not consume it since it is not a 
> "RarModule". 

I'm pretty sure that the rars generated can still have a dependency type
of rar - the type != packaging.

> Even though I might have to write both Ear Plugin and Rar Plugin 
> under my specific requirement. I still think that would be a bad idea 
> that I have to write all the J2EE packaging plugins just because
> I have to do some specific thing in one type of J2EE Component.

I agree - the RAR plugin should be extensible enough to do what you
want, rather than be replaced. What exactly is it that you need to do
that it can't?

> Maven should enforce a rigid build life cycle but not a list of maven 
> plugins should be executed.

That's why you can specify alternate packagings. We can consider some
sort of replacement mechanism in 2.1 as we are taking another look at
how the lifecycle is specified.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org