Well, in practice, it's not possible to include no dependencies in a
build that is going to first create a module (JAR/WAR/etc) and then
build a CAR out of it. The CAR module always needs the dependency on
the original module. So it's hard to create the "no changes to
environment" scenario. Perhaps we could configure the plan processing
mojo to ignore dependencies with scope=provided or something?
Thanks,
Aaron
On 7/26/06, David Jencks <[EMAIL PROTECTED]> wrote:
You should be able to include a complete environment element in your
plan and if you don't include any dependencies in your pom the plan
processing mojo should do nothing. If this is not what happens
please file a jira with details.
thanks
david jencks
On Jul 25, 2006, at 4:49 PM, 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:
>
> [ERROR] BUILD ERROR
> [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
