RE: Determining top-level parent pom directory
Wayne or anyone elsesuggestions? Tim -Original Message- From: Tim Foster [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 18, 2007 4:18 PM To: Maven Users List Subject: RE: Determining top-level parent pom directory Okay. I'm trying to dynamically create a properties file, e.g., my.properties, into which I can define properties that can be referenced at all levels of the hierarchy. This file would live in a location relative to the top-level pom file. The default definitions of the properties are determined by reading a default.properties file, but the values can be overridden by environment variables. So, I'm using the maven-antrun-plugin to create this properties file, but I don't know how to reference it from the lower-level poms. Thanks, Tim -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 18, 2007 3:58 PM To: Maven Users List Subject: Re: Determining top-level parent pom directory Tell us more about what you're trying to do. Wayne On 9/18/07, Tim Foster [EMAIL PROTECTED] wrote: In a multi-module pom hierarchy, what is the best way to determine/reference the top-level pom directory? Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Determining top-level parent pom directory
Thanks for your reply. I want the properties to be available both at build time (e.g., to be used in packaging) and runtime (e.g., to be used to locate other resources that are relative to directory property values). Tim -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 9:36 AM To: Maven Users List Subject: Re: Determining top-level parent pom directory On 9/18/07, Tim Foster [EMAIL PROTECTED] wrote: Okay. I'm trying to dynamically create a properties file, e.g., my.properties, into which I can define properties that can be referenced at all levels of the hierarchy. This file would live in a location relative to the top-level pom file. The default definitions of the properties are determined by reading a default.properties file, but the values can be overridden by environment variables. So, I'm using the maven-antrun-plugin to create this properties file, but I don't know how to reference it from the lower-level poms. Is this properties file a build-time thing, or something that you need to package up to deliver with your project? IOW, what problem are you trying to solve? You're still describing an implementation. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Determining top-level parent pom directory
In a multi-module pom hierarchy, what is the best way to determine/reference the top-level pom directory? Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Determining top-level parent pom directory
Okay. I'm trying to dynamically create a properties file, e.g., my.properties, into which I can define properties that can be referenced at all levels of the hierarchy. This file would live in a location relative to the top-level pom file. The default definitions of the properties are determined by reading a default.properties file, but the values can be overridden by environment variables. So, I'm using the maven-antrun-plugin to create this properties file, but I don't know how to reference it from the lower-level poms. Thanks, Tim -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 18, 2007 3:58 PM To: Maven Users List Subject: Re: Determining top-level parent pom directory Tell us more about what you're trying to do. Wayne On 9/18/07, Tim Foster [EMAIL PROTECTED] wrote: In a multi-module pom hierarchy, what is the best way to determine/reference the top-level pom directory? Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
looking for users of AccuRev and/or QuickBuild
I'm looking for any Maven users who use AccuRev for source control and/or QuickBuild for build management who would like to compare notes. Please reply directly to me. Tim mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Question regarding multi-modules setup
Hi Julien, Regarding the site links not working, I found that the relative paths were not correct until I ran the site:stage goal as follows: mvn site:stage -DstagingDirectory=path_to_your_staging_area Then open the index.html at the top level of the staging area. I think the same thing can be accomplished with site:deploy, but I haven't gotten that far yet. Tim -Original Message- From: Julien Stern [mailto:[EMAIL PROTECTED] Sent: Monday, June 18, 2007 8:10 AM Hi list, Using Maven 2.0.6 and Continuum 1.1-alpha-2. I have the following problem with multi-modules setup: I tried the two following approaches (both with modules and aggregation) A) parent pom in the top-level dir - pom.xml (parent) - module 1 - pom.xml - module 2 - pom.xml B) parent pom at the same level as modules - parent - pom.xml - module 1 - pom.xml - module 2 - pom.xml Approach A causes problem with continuum: each change in ANY module is detected by the parent project which is rebuilt, leading to the recompilation of every module. Approach B causes problem with site generation: the modules links in the parent site are incorrect (they point one level higher than they should). Multi-module setup seems to be a fairly common setting, so I'm sure that I have missed something. Is there any way to have a multimodule setup that works both for site generation and for Continuum ? Regards, -- Julien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: trouble building a multi-module project with cross-module dependencies
Wayne, thanks for the reply. It is interesting to know that Maven determines the proper build ordering of the modules itself. As you may have surmised, the example I described is a simplified version of my real-life scenario, as I thought it would be easier to understand if I took out all of the extraneous data. The real-life pom file that parallels the mod1 pom does, indeed, have the sub-modules declared. This is what allows the install of those sub-modules to succeed when, as I said, I change directory into mod1 and run the same 'mvn install' command. It also has the parent pom defined, as it inherits configuration settings made only in the top-level pom file. I'm not sure what dependency would be missing, as it is the unresolved declared dependency on mod1B that makes the install of mod2 to fail. Anything else you or anyone else can think of that I might should look for? Tim -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Thursday, May 24, 2007 12:16 AM To: Maven Users List Subject: Re: trouble building a multi-module project with cross-module dependencies As I understand it, ordering of modules in the pom.xml file has nearly nothing to do with the way the pom is processed by Maven, so that assumption is incorrect. Maven should automatically find all your poms (assuming modules are declared) and resolve the proper graph that will allow it to successfully build your artifacts using the dependencies, modules, etc you have declared. It sounds like you are missing either a dependency or more likely a module/parent declaration in one of your poms, most likely the mod1 pom.xml file. Without seeing all the poms etc I can't be certain, but that's just what it sounds like. Wayne On 5/23/07, Tim Foster [EMAIL PROTECTED] wrote: I'm having trouble building a multi-module project structured as below: top |-- pom.xml |-- mod1 ||-- pom.xml ||-- mod1A || |-- pom.xml || `-- src ||-- mod1B ||-- pom.xml |`-- src |-- mod2 | |-- pom.xml | `-- src `src... Additionally, mod1 is listed ahead of mod2 in the top-level pom.xml file, so I expect mod1 (and thus also its sub-modules) to be processed first. Also, mod2 has a dependency on mod1B. I run 'mvn install' from the top level, expecting it to a) include all of the phases in the lifecycle up to install as described in the documentation (http://maven.apache.org/guides/introduction/introduction-to-the-lifecyc le.html) and b) to do this recursively. With that assumption, I think that mod1B should be installed before mod2 is processed. But that is not the case, as the build of mod2 fails because mod1B is not found in the local repository. What seems to be happening is that the sub-modules of mod1 are not being processed, as evidenced by the following message: [INFO] No goals needed for project - skipping Rather, the only thing that gets done when processing mod1 when the command is invoked from the top-level project directory is that the pom file is installed (i.e., as a result of package type of pom for the module). Now if I change directory into mod1 and run the same 'mvn install' command, the mod1A and mod1B modules are installed. Then, I can run 'mvn install' from the top level and the dependency on mod1B is satisfied when processing mod2. Obviously I don't want to have this take multiple invocations of mvn to build my project. Are my assumptions correct about how recursion is supposed to work and, if so, is there something extra I need to do in order to have the sub-modules down the hierarchy to be processed? Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
trouble building a multi-module project with cross-module dependencies
I'm having trouble building a multi-module project structured as below: top |-- pom.xml |-- mod1 ||-- pom.xml ||-- mod1A || |-- pom.xml || `-- src ||-- mod1B ||-- pom.xml |`-- src |-- mod2 | |-- pom.xml | `-- src `src... Additionally, mod1 is listed ahead of mod2 in the top-level pom.xml file, so I expect mod1 (and thus also its sub-modules) to be processed first. Also, mod2 has a dependency on mod1B. I run 'mvn install' from the top level, expecting it to a) include all of the phases in the lifecycle up to install as described in the documentation (http://maven.apache.org/guides/introduction/introduction-to-the-lifecyc le.html) and b) to do this recursively. With that assumption, I think that mod1B should be installed before mod2 is processed. But that is not the case, as the build of mod2 fails because mod1B is not found in the local repository. What seems to be happening is that the sub-modules of mod1 are not being processed, as evidenced by the following message: [INFO] No goals needed for project - skipping Rather, the only thing that gets done when processing mod1 when the command is invoked from the top-level project directory is that the pom file is installed (i.e., as a result of package type of pom for the module). Now if I change directory into mod1 and run the same 'mvn install' command, the mod1A and mod1B modules are installed. Then, I can run 'mvn install' from the top level and the dependency on mod1B is satisfied when processing mod2. Obviously I don't want to have this take multiple invocations of mvn to build my project. Are my assumptions correct about how recursion is supposed to work and, if so, is there something extra I need to do in order to have the sub-modules down the hierarchy to be processed? Tim
RE: How to share a common checkstyle config across modules?
Thanks, Gerald. This is exactly what I wanted and it worked just as you described. This mechanism will be useful for many other applications. Tim -Original Message- From: Nunn, Gerald [mailto:[EMAIL PROTECTED] Sent: Thursday, May 17, 2007 1:52 PM To: Maven Users List Subject: RE: How to share a common checkstyle config across modules? I jar my checkstyle configuration and then store it in an intranet Maven repository. Projects can then declare a dependency on this jar using the extensions tag in the build section of pom.xml. For example: build extensions extension groupIdcom./groupId artifactId-checkstyle/artifactId version1.0.0/version /extension /extensions /build reporting plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-checkstyle-plugin/artifactId configuration configLocationconfig/cibc_checks.xml/configLocation /configuration /plugin /plugins /reporting The configLocation is the classpath location in the -checkstyle.jar. Hope this helps. Gerald - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to share a common checkstyle config across modules?
Newbie here. We have a checkstyle config file that we would like for
all modules within the project hierarchy to use. Our plan was to store
the config file in a 'buildtools' subdirectory at the top of the project
hierarchy and reference it from the top-level pom.xml file as such:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
configuration
configLocation./buildtools/checkstyle.xml/configLocation
/configuration
/plugin
The problem is that I don't know how to specify the path so that it is
always computed correctly for the current level of the hierarchy. That
is, this setup only works for the top-level POM, while the
configLocation path is wrong for the lower-level ones. I tried using
the ${basedir} variable, but the value of it changes depending upon the
level of the hierarchy. What I would like is a variable with a value of
the relative path to the top-level directory.
The only way we've been able to get this to work is to store the file in
our internal repository and reference by an absolute url as such:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
configuration
configLocationhttp://mavenrepo:8080/internal/checkstyle/checkstyle.xml
/configLocation
/configuration
/plugin
But, I would rather manage this config file in the source control
system. Of course this problem is not unique to checkstyle as the same
issue exists for any file that needs to be shared across the hierarchy.
Is there a way compute a variable to contain the value of the path
relative to the top-level pom directory? Or is there a better way to
achieve what I'm trying to do?
Thanks,
Tim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
