Re: #1, a bit ugly but doesn't surprise me the problem exists. It would
be tricky for maven to understand that cache-core 2.1.0.CR4-JBossAS came
from cache-core's JBossAS profile and know to use that profile's
dependencies.
Re #2, I'll let Jason comment on what's up with the aop plugin, but the
idea of using properties to specify versions doesn't seem so bad. I've
seen the same done in ejb3 and hibernate.
Thanks for sorting this!
Galder Zamarreno wrote:
Hi,
Re:
http://jira.jboss.com/jira/browse/PCACHE-60
I've been playing around with this JIRA and there's a couple of things
I've noted:
1.- When we build cache-core with JBossAS profile, the generated pom
file still points to the original dependencies, which means that in the
cache-pojo's pom.xml, we have to repeat the cache-core dependencies for
JBossAS profile.
If a project depends on library A-1.0.0.GA and the profile specifies
dependency on A-1.0.0.SP1, you'd expect that any build artifacts
generated, i.e. pom.xml, would have main dependency switched to
A-1.0.0.SP1 but it doesn't. So, you have built a new jar with profile
dependencies but when it's used by another project, it still downloads
original dependencies.... useless. I'm gonna follow this up with Maven
users and see what I can find.
For the time being, until I've found a better solution, dependencies in
JBossAS profile in cache-core will be repeated in cache-pojo.
2.- As cache-pojo's pom.xml says about the maven jbossaop plugin, "
<!-- HACK: AOP project and plugin has broken deps -->", the dependencies
for jbossaop are broken, so we have to repeat them. This has a direct
effect on creating a brand new profile for JBossAS.
Even though I've updated JBossAS dependencies, I need to add similar
dependencies to the maven-jbossaop-plugin in order for aopc to happen
with the desired dependencies.
Now, in a profile, you can't override the following section of the main
pom.xml:
<build>
<plugins>
...
This means that I need to define all JBoss AOP dependencies for
maven-jbossaop-plugin that we might want to override in JBossAS profile.
For example jboss-javaee, microcontainer...etc using properties and
define the versions at the top of the pom.xml and then define these same
properties for JBossAS profile. For example:
<properties>
<jbosscache-pojo-version>2.1.0.CR4</jbosscache-pojo-version>
<jbosscache-core-version>2.1.0.CR4</jbosscache-core-version>
<jboss.aop.version>2.0.0.CR3</jboss.aop.version>
<jboss.microcontainer.version>2.0.0.Beta6</jboss.microcontainer.version>
</properties>
...
<groupId>org.jboss.maven.plugins</groupId>
<artifactId>maven-jbossaop-plugin</artifactId>
<version>2.0.0.beta1</version>
...
<dependency>
<groupId>org.jboss.microcontainer</groupId>
<artifactId>jboss-container</artifactId>
<version>${jboss.microcontainer.version}</version>
</dependency>
...
<profiles>
<profile>
<id>JBossAS</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<properties>
<jbosscache-pojo-version>2.1.0.CR4-JBossAS</jbosscache-pojo-version>
<jbosscache-core-version>2.1.0-SNAPSHOT-JBossAS</jbosscache-core-version>
<jboss.aop.version>2.0.0.CR7</jboss.aop.version>
<jboss.microcontainer.version>2.0.0.Beta10</jboss.microcontainer.version>
...
Having to do this is a royal pain in the butt and can lead to incorrect
version definitions. Thoughts? Has anyone looked into fixing the broken
maven aop plugin?
Cheers,
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com