[m2] RE: plugin development - extending simple plugin like jar

[Ruel Loehr <ru...@jboss.com>]

Thanks!
I dorked with it yesterday and had stumbled across the post to which you
refer and got it to work.

All in all it worked out pretty well.  The only hitch that I had was
that then when defining the lifecycle mapping in the components.xml the
documentation didn't seem to match up to what I had to really do to make
it work.   

The documentation from the build lifecycle page shows the components.xml
like this:

<component-set>
  <components>
    <component>
      <role>org.apache.maven.lifecycle.mapping.LifecycleMapping</role>
      <role-hint>plexus-application</role-hint>
 
<implementation>org.apache.maven.lifecycle.mapping.DefaultLifecycleMappi
ng</implementation>
      <configuration>
        <phases>
          <process-resources>resources:resources</process-resources>
          <compile>compiler:compile</compile>
 
<process-test-resources>resources:testResources</process-test-resources>
          <test-compile>compiler:testCompile</test-compile>
          <test>surefire:test</test>
          <package>plexus:app</package>
          <install>install:install</install>
          <deploy>deploy:deploy</deploy>
        </phases>
      </configuration>
    </component>
  </components>
</component-set>


However, in practice I received a number of errors telling me that I
needed to use the groupID:artifact:Id:goal format when defining my
phases.   Changing for example, compiler:compiler to
org.apache.maven.plugins:maven-compiler-plugin:compile cured the issues.

Use case?

I think this is a great example of a real world migration, so I will
describe it in detail.  Maybe other migrators will have similar
experiences.

My overall use case is a migration from an ANT based build to a maven
based build.   Having a large ANT based build == lots of ugliness (bad
practices have crept in over the years).    For the time being, I do
need to reproduce certain aspects of the ant build (the number of
outputs and their contents).  

In this case we had a single source module which created 3 jars,
source.jar, archive-browsing.jar, and logging.jar.    I split the single
source module into separate projects but found there were some
inter-dependencies among the source.   What I ended up with is 4
subprojects. 

1) common-source
2) primary-source
3) archive-browsing
4) logging

A restriction though, is imposed upon me.  I am free to dork with the
filesystem and even add artifacts but I cannot modify source code to
accommodate the build. I need to reproduce the artifacts which ANT was
building (in this case #2, #3 and #4).    Thus, I need to add classes
from #1 into #2,#3,and #4 when building my jar. 

The obvious question is why the restriction?

The reason I am concerned with this is I have to ultimately sell the
idea of a maven conversion.  If the outputs differ for a given project,
the first question asks will be, 

Everyone:  "Why are the outputs different?".

Me:  "Because maven works differently.  It expects a certain file
structure."

Everyone:  "So I can't add additional classes from a different proj to a
jar?  I could do that with ANT.  That must mean Maven isn't as useful"

Ultimately, I realize this isn't a best practice but in a real world
migration scenario it takes a few steps before I can get to my ultimate
goal...


Ruel Loehr
JBoss QA
 
-----------------------------
512-626-2782
Yahoo: ruelloehr
Skype: ruelloehr
AOL: dokoruel
-----Original Message-----
From: Brett Porter [mailto:brett.porter@gmail.com] 
Sent: Thursday, November 10, 2005 10:52 PM
To: Maven Users List
Subject: Re: plugin development - extending simple plugin like jar

To use a custom plugin, you need to use a custom packaging element.
Take a look at the lifecycle guide on the web site (there was a thread
on this list very recently about it too).

However, I'm curious what your use case is for duplicating classes
across multiple jars. Why is this required? It may hinder the ability
to use the multiproject effectively later on.

Cheers,
Brett

On 11/11/05, Ruel Loehr <ru...@jboss.com> wrote:
> I identified a need in our particular build such that many times when
we
> build a jar, we need to include classes from another project.
>
> For example, in a multiproj build I have 2 submodules:
>
> Module1
> Module2
>
> I build module1 and jar it up, then I build module2 and jar it up,
> however, the caveat is that I want to include a few classes from the
> module1 /target/classes to the jar created in module2.
>
> I took a look at the source for the jar plugin and can see that the
> functionality doesn't exist.  No prob.   I wrote my own plugin which
> extends the jar plugin (the plugin dev guide is pretty awesome, I was
up
> and running with the sample in 10 mins).
>
> My question though,
>
> How can I instruct maven to use my custom jar plugin rather than the
> default jar plugin?
>
> Ruel Loehr
> JBoss QA
>
> -----------------------------
> 512-626-2782
> Yahoo: ruelloehr
> Skype: ruelloehr
> AOL: dokoruel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

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


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

Re: [m2] RE: plugin development - extending simple plugin like jar

[Brett Porter <br...@gmail.com>]

On 11/12/05, Ruel Loehr <ru...@jboss.com> wrote:
> However, in practice I received a number of errors telling me that I
> needed to use the groupID:artifact:Id:goal format when defining my
> phases.   Changing for example, compiler:compiler to
> org.apache.maven.plugins:maven-compiler-plugin:compile cured the issues.

Thanks, I'll get that updated.

> The obvious question is why the restriction?

Oh, its not a restriction - you can do it. It's just a recommendation.

Maven is not there to put road blocks up, but because it defaults to
modular patterns for builds, if you find yourself working against it,
its possible there are other questions about the build to be answered.

It's great that you recognise it would make sense to move away from
this eventually. Including a class in 2 different JARs makes me wonder
what happens when both JARs end up in the classloader, and why they
are in both - its probably shared functionality that should be broken
out in a common dependency, and only included this way to avoid a
circular dependency.

- Brett

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