-
1. Re: maven.opts for building thirdparty module
Trunk is using Maven directly instead of through Ant, so you can just pass the properties directly. From the root directory (not the build dir)
./build.sh -Dskip-download-sources -D...
-
2. Re: maven.opts for building thirdparty module
I had tried passing the properties directly but from the build folder.
"pgier" wrote:
From the root directory (not the build dir)
That was the only thing that i hadn't tried :) Let me see how it goes. Thanks.
So is the build.sh in the build folder no longer being used in the build process? -
3. Re: maven.opts for building thirdparty module
"jaikiran" wrote:
So is the build.sh in the build folder no longer being used in the build process?
Right, the build.sh in the build dir is not used anymore. I will switch that one to call the maven build like how the modules are set up. The project should be built from the root directory now, and the build directory only packages the distribution instead of doing the full build. -
4. Re: maven.opts for building thirdparty module
That partially helped me solve the issue. Using
./build.sh -Dmaven.opts="-Dskip-download-sources -Dversion.org.jboss.ejb3=1.1.7 -Dversion.org.jboss.ejb3.common.client=1.0.0 -Dversion.org.jboss.ejb3.core.client=1.1.7 -Dversion.org.jboss.ejb3.proxy.client=1.0.1 -Dversion.org.jboss.ejb3.proxy.clustered.client=1.0.1 -Dversion.org.jboss.ejb3.security.client=1.0.0"
from the root of trunk does let these properties be visible to the thirdparty task which generates the correct component-info.xml in the thirdparty/jboss/jboss-ejb3-core:<?xml version="1.0" encoding="UTF-8"?> <project name=""> <component id="jboss/jboss-ejb3-core" licenseType="" version="1.1.7" description="" > <artifact id="jboss-ejb3-core.jar"/> <artifact id="jboss-ejb3-core-client.jar"/> <export> <include input="jboss-ejb3-core-client.jar"/> <include input="jboss-ejb3-core.jar"/> </export> </component> </project>
However when the AS is being bundled through "jboss-as-build", internally the maven:dependencies task is triggered:<target name="init-thirdparty-dependencies" depends="init" description="Initialize thirdparty dependency configuration"> <!-- - Initialize properties for each dependency in the thirdparty pom - The properties take the form "groupId:artifactId:packaging" --> <maven:dependencies filesetId="pom.dependencies" versionsId="pom.dependencies.versions" scopes="compile, runtime" type="pom, jar, zip, war" addArtifactFileSetRefs="true"> <pom file="../thirdparty/pom.xml"/> </maven:dependencies> ...
which does not seem to honour the system properties being passed. Internally the maven:dependencies ant task creates a dependency set for the pom, based on what is specified in the component-matrix pom.xml (i.e. a different version 1.1.6 of org.jboss.ejb3:jboss-ejb3-core). This ultimately leads in the AS distribution containing 1.1.6 version of ejb3-core in the common/lib.
Just pinged on #maven to get some info on the maven ant-tasks project's DependenciesTask, related to system properties handling:(02:29:01 IST) Jaikiran: anyone here knows about maven ant-tasks project? (02:29:18 IST) Jaikiran: specifically the DependenciesTask http://svn.apache.org/repos/asf/maven/ant-tasks/tags/maven-ant-tasks-2.0.10/src/main/java/org/apache/maven/artifact/ant/DependenciesTask.java (02:30:05 IST) ***brett does, but is stepping out (02:30:08 IST) brett: just ask and try your luck (02:31:16 IST) Jaikiran: actually i have trying to get that task working by specifying system properties like -Dversion.groupid.artifactid=123 (02:33:20 IST) Jaikiran: the pom.xml contains: (02:33:21 IST) Jaikiran: <properties> (02:33:21 IST) Jaikiran: <version.groupid.artifactid>122</version.groupid.artifactid> (02:33:21 IST) Jaikiran: </properties> (02:33:21 IST) Jaikiran: <dependency> (02:33:21 IST) Jaikiran: <version>${version.groupid.artifactid}</version> (02:33:21 IST) Jaikiran: </dependency> (02:33:45 IST) Jaikiran: the dependenciestask always keeps using 122 instead of the 123 version passed as system property (02:34:16 IST) Jaikiran: was looking for information on whether the dependenciestask is expected to consider the system properties during version resolution (02:39:25 IST) i386 left the room (quit: i386). (02:43:55 IST) tobrien left the room (quit: tobrien). (02:44:04 IST) b0fh left the room (quit: "leaving"). (02:45:24 IST) mkleint: jaikiran: i doubt resolving from the repository takes System props into account.. (02:46:39 IST) Jaikiran: mkleint: hmm, that's a bummer :(
Paul, do you see any different way we can handle this? -
5. Re: maven.opts for building thirdparty module
"jaikiran" wrote:
That partially helped me solve the issue. Using./build.sh -Dmaven.opts="-Dskip-download-sources -Dversion.org.jboss.ejb3=1.1.7 -Dversion.org.jboss.ejb3.common.client=1.0.0 -Dversion.org.jboss.ejb3.core.client=1.1.7 -Dversion.org.jboss.ejb3.proxy.client=1.0.1 -Dversion.org.jboss.ejb3.proxy.clustered.client=1.0.1 -Dversion.org.jboss.ejb3.security.client=1.0.0"
You shouldn't be using -Dmaven.opts anymore. Did you try./build.sh -Dskip-download-sources -Dversion.org.jboss.ejb3=1.1.7 -Dversion.org.jboss.ejb3.common.client=1.0.0 -Dversion.org.jboss.ejb3.core.client=1.1.7 -Dversion.org.jboss.ejb3.proxy.client=1.0.1 -Dversion.org.jboss.ejb3.proxy.clustered.client=1.0.1 -Dversion.org.jboss.ejb3.security.client=1.0.0
You're right about the issue in the Ant tasks, they probably aren't passing all the properties correctly. I will look into that today. -
6. Re: maven.opts for building thirdparty module
"pgier" wrote:
You shouldn't be using -Dmaven.opts anymore.
Sorry that was a typo in my post. I did indeed try (from the root of the trunk):./build.sh -Dskip-download-sources -Dversion.org.jboss.ejb3=1.1.7 -Dversion.org.jboss.ejb3.common.client=1.0.0 -Dversion.org.jboss.ejb3.core.client=1.1.7 -Dversion.org.jboss.ejb3.proxy.client=1.0.1 -Dversion.org.jboss.ejb3.proxy.clustered.client=1.0.1 -Dversion.org.jboss.ejb3.security.client=1.0.0
and the behaviour i saw, is explained in my previous reply. -
7. Re: maven.opts for building thirdparty module
"jaikiran" wrote:
"pgier" wrote:
You shouldn't be using -Dmaven.opts anymore.
Sorry that was a typo in my post. I did indeed try (from the root of the trunk):
Ok, just wanted to make sure. I created JBBUILD-532 to track working on this. -