geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <>
Subject Re: Geronimo 1.1 JARs but not CARs on ibiblio; car-maven-plugin change
Date Tue, 25 Jul 2006 21:08:52 GMT
I'll read and reply in detail in a while. But for now, here's a quick
answer to your last question -

In the, introduce the variable (foo) you desire
as a field. Annotate that field as follows

 * @parameter
private String foo;

Use the variable directly in your code in that class. (No getters or
setters needed)

Pass the value to that new variable as a config option in the pom.xml.
<foo>value of the new variable</foo>


On 7/25/06, Aaron Mulder <> wrote:
> So I can use Maven 2 against Geronimo 1.1 since the G 1.1 JARs have
> been pushed to Maven 2.
> However, I can't use the car-maven-plugin to build a CAR in a script
> the way we do in Geronimo because it appears that you're supposed to
> list your parent module as a dependency, and none of the Geronimo 1.1
> CARs are in the Maven 2 repo.  So you can list e.g.
> geronimo/rmi-naming/1.1/car as a dependency if you want that to be
> your parent, and the build dies with:
> [INFO] ------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
> Missing:
> ----------
> 1) geronimo:rmi-naming:car:1.1
> I tried telling it to use version 1.0 just for grins, and it
> downloaded an unbelievable amount of stuff -- and eventually died
> here:
> Path to dependency:
>         1) gplugins:quartz-scheduler-plugin:car:0.2.1
>         2) geronimo:rmi-naming:car:1.0
>         3) geronimo:geronimo-jetty:jar:1.0
>         4) org.springframework:spring:jar:1.2.5
>         5) org.springframework:spring-support:jar:1.2.5
>         6) javax.resource:connector:jar:1.0
> This is pretty ridiculous, since the dependency is not actually needed
> to build, we just want its name to write it into a plan file.  I
> originally was going to ask for the CARs to be posted, but not if is
> has this side effect if pulling in an unholy amout of crap.
> I'd rather manually specify the <environment> in my plan and suppress
> the "feature" that writes a modified <environment> into the target
> plan.
> It looks like the offending code is in PlanProcessorMojo, so I'd like
> to add a config option to that file to suppress the auto-generated
> environment.  But I don't know a whole lot about Maven plugins.  Can
> someone walk me through adding a config option to the car-maven-plugin
> that will eventually be set into a variable on the PlanProcessorMojo
> instance?
> Thanks,
>     Aaron

View raw message