RE: Renaming resulting directory from war:exploded
I think what I missed until I got into the source was that "The directory where the webapp is built," as the documentation refers to , is actually the output for war:exploded, even though it's just a working directory for war:war. So, I guess I didn't make the connection between it and what I wanted without seeing that war:exploded is implemented in the abstract superclass Mojo and actually called as a precursor to the main war:war goal, using that string as an argument. Is it a standard thing for plugins' goals to consitute their own little mini-lifecycles this way? -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 12:38 PM To: Maven Users List Subject: Re: Renaming resulting directory from war:exploded Good point, Daniel. I hadn't considered that parameter. This parameter is covered in the docs, but it may be that an example should be created for future people looking for this specific use case, to make it more obvious: http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html Wayne On 2/6/08, Allen, Daniel <[EMAIL PROTECTED]> wrote: > To answer my own question (for the archives and those searching them), > once I got into the source, it turned out that there were set/get > methods for a property called webappDirectory. I didn't see it in the > documentation, but all the other set/get methods corresponded to > parameters you could put in the POM's plugin config, so I tried it, and > it works! > > So, adding > ${project.build.directory}\desiredName > to the will solve this problem. It will rename the > intermediary directory from which the WAR is created "desiredName" and > have it in the target directory with the rest of the results. (Omitting > "${project\build\directory}" has it default to the base directory where > your main POM is.) This applies to both war:war and war:exploded (for > the latter, the directory in question is just the final product instead > of an intermediary). It may apply to other goals in the plugin, but I > didn't try it. > > ~Dan Allen > > -Original Message- > From: Wayne Fay [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 05, 2008 6:05 PM > To: Maven Users List > Subject: Re: Renaming resulting directory from war:exploded > > Not sure why your Ant script isn't working. Are you sure it works if > you execute it in Ant? I'm not sure when exploded is bound -- check -X > to make sure your Ant happens after exploded etc. > > You could also patch the war plugin to support an additional parameter > (or just use warName) when war:exploded is executed. > > Donate your patch back via JIRA and we can all benefit. > > Wayne > > On 2/5/08, Allen, Daniel <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > I've been using the war plugin to package up a web app. However, to > save > > time, it would be great if the result had a consistent name so that we > > could copy it directly into the Tomcat/webapps directory and have it > > startup with the proper context path. > > > > In the call to the war plugin, I used the tag, and that > works > > just fine for my live build, which uses war:war. However, my dev build > > profile uses war:exploded instead, and the doesn't seem to > > have any effect. I tried using antrun, as below, but that doesn't seem > > to have any effect either. When I run mvn -P dev clean package, the > > output does claim to be executing this task (referred to by the ID > > element, so I know it's not another antrun I've used), but the result > is > > still just an exploded war that has the standard maven name scheme of > > artifactId-version. > > > > > > maven-antrun-plugin > > > > > > RenameFinalDirectory > > package > > > > run > > > > > > > > > dir="${project.build.directory}\${project.name}"/> > > > todir="${project.build.directory}\${project.name}"> > > > > dir="${project.build.directory}\${project.artifactId}-${project.version} > > "/> > > > > > > > > > > > > > > > > Any suggestions on why this doesn't work, or what I might use inste
Re: Renaming resulting directory from war:exploded
Good point, Daniel. I hadn't considered that parameter. This parameter is covered in the docs, but it may be that an example should be created for future people looking for this specific use case, to make it more obvious: http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html Wayne On 2/6/08, Allen, Daniel <[EMAIL PROTECTED]> wrote: > To answer my own question (for the archives and those searching them), > once I got into the source, it turned out that there were set/get > methods for a property called webappDirectory. I didn't see it in the > documentation, but all the other set/get methods corresponded to > parameters you could put in the POM's plugin config, so I tried it, and > it works! > > So, adding > ${project.build.directory}\desiredName > to the will solve this problem. It will rename the > intermediary directory from which the WAR is created "desiredName" and > have it in the target directory with the rest of the results. (Omitting > "${project\build\directory}" has it default to the base directory where > your main POM is.) This applies to both war:war and war:exploded (for > the latter, the directory in question is just the final product instead > of an intermediary). It may apply to other goals in the plugin, but I > didn't try it. > > ~Dan Allen > > -Original Message- > From: Wayne Fay [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 05, 2008 6:05 PM > To: Maven Users List > Subject: Re: Renaming resulting directory from war:exploded > > Not sure why your Ant script isn't working. Are you sure it works if > you execute it in Ant? I'm not sure when exploded is bound -- check -X > to make sure your Ant happens after exploded etc. > > You could also patch the war plugin to support an additional parameter > (or just use warName) when war:exploded is executed. > > Donate your patch back via JIRA and we can all benefit. > > Wayne > > On 2/5/08, Allen, Daniel <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > I've been using the war plugin to package up a web app. However, to > save > > time, it would be great if the result had a consistent name so that we > > could copy it directly into the Tomcat/webapps directory and have it > > startup with the proper context path. > > > > In the call to the war plugin, I used the tag, and that > works > > just fine for my live build, which uses war:war. However, my dev build > > profile uses war:exploded instead, and the doesn't seem to > > have any effect. I tried using antrun, as below, but that doesn't seem > > to have any effect either. When I run mvn -P dev clean package, the > > output does claim to be executing this task (referred to by the ID > > element, so I know it's not another antrun I've used), but the result > is > > still just an exploded war that has the standard maven name scheme of > > artifactId-version. > > > > > > maven-antrun-plugin > > > > > > RenameFinalDirectory > > package > > > > run > > > > > > > > > dir="${project.build.directory}\${project.name}"/> > > > todir="${project.build.directory}\${project.name}"> > > > > dir="${project.build.directory}\${project.artifactId}-${project.version} > > "/> > > > > > > > > > > > > > > > > Any suggestions on why this doesn't work, or what I might use instead? > > > > -- > > This message may contain confidential, proprietary, or legally > privileged > > information. No confidentiality or privilege is waived by any > transmission > > to an unintended recipient. If you are not an intended recipient, > please > > notify the sender and delete this message immediately. Any views > expressed > > in this message are those of the sender, not those of any entity > within the > > KBC Financial Products group of companies (together referred to as > "KBC > > FP"). > > > > This message does not create any obligation, contractual or otherwise, > on > > the part of KB
RE: Renaming resulting directory from war:exploded
To answer my own question (for the archives and those searching them), once I got into the source, it turned out that there were set/get methods for a property called webappDirectory. I didn't see it in the documentation, but all the other set/get methods corresponded to parameters you could put in the POM's plugin config, so I tried it, and it works! So, adding ${project.build.directory}\desiredName to the will solve this problem. It will rename the intermediary directory from which the WAR is created "desiredName" and have it in the target directory with the rest of the results. (Omitting "${project\build\directory}" has it default to the base directory where your main POM is.) This applies to both war:war and war:exploded (for the latter, the directory in question is just the final product instead of an intermediary). It may apply to other goals in the plugin, but I didn't try it. ~Dan Allen -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 05, 2008 6:05 PM To: Maven Users List Subject: Re: Renaming resulting directory from war:exploded Not sure why your Ant script isn't working. Are you sure it works if you execute it in Ant? I'm not sure when exploded is bound -- check -X to make sure your Ant happens after exploded etc. You could also patch the war plugin to support an additional parameter (or just use warName) when war:exploded is executed. Donate your patch back via JIRA and we can all benefit. Wayne On 2/5/08, Allen, Daniel <[EMAIL PROTECTED]> wrote: > Hi all, > > I've been using the war plugin to package up a web app. However, to save > time, it would be great if the result had a consistent name so that we > could copy it directly into the Tomcat/webapps directory and have it > startup with the proper context path. > > In the call to the war plugin, I used the tag, and that works > just fine for my live build, which uses war:war. However, my dev build > profile uses war:exploded instead, and the doesn't seem to > have any effect. I tried using antrun, as below, but that doesn't seem > to have any effect either. When I run mvn -P dev clean package, the > output does claim to be executing this task (referred to by the ID > element, so I know it's not another antrun I've used), but the result is > still just an exploded war that has the standard maven name scheme of > artifactId-version. > > > maven-antrun-plugin > > > RenameFinalDirectory > package > > run > > > >dir="${project.build.directory}\${project.name}"/> >todir="${project.build.directory}\${project.name}"> > dir="${project.build.directory}\${project.artifactId}-${project.version} > "/> > > > > > > > > Any suggestions on why this doesn't work, or what I might use instead? > > -- > This message may contain confidential, proprietary, or legally privileged > information. No confidentiality or privilege is waived by any transmission > to an unintended recipient. If you are not an intended recipient, please > notify the sender and delete this message immediately. Any views expressed > in this message are those of the sender, not those of any entity within the > KBC Financial Products group of companies (together referred to as "KBC > FP"). > > This message does not create any obligation, contractual or otherwise, on > the part of KBC FP. It is not an offer (or solicitation of an offer) of, or > a recommendation to buy or sell, any financial product. Any prices or other > values included in this message are indicative only, and do not necessarily > represent current market prices, prices at which KBC FP would enter into a > transaction, or prices at which similar transactions may be carried on KBC > FP's own books. The information contained in this message is provided "as > is", without representations or warranties, express or implied, of any kind. > Past performance is not indicative of future returns. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail
Re: Renaming resulting directory from war:exploded
Not sure why your Ant script isn't working. Are you sure it works if you execute it in Ant? I'm not sure when exploded is bound -- check -X to make sure your Ant happens after exploded etc. You could also patch the war plugin to support an additional parameter (or just use warName) when war:exploded is executed. Donate your patch back via JIRA and we can all benefit. Wayne On 2/5/08, Allen, Daniel <[EMAIL PROTECTED]> wrote: > Hi all, > > I've been using the war plugin to package up a web app. However, to save > time, it would be great if the result had a consistent name so that we > could copy it directly into the Tomcat/webapps directory and have it > startup with the proper context path. > > In the call to the war plugin, I used the tag, and that works > just fine for my live build, which uses war:war. However, my dev build > profile uses war:exploded instead, and the doesn't seem to > have any effect. I tried using antrun, as below, but that doesn't seem > to have any effect either. When I run mvn -P dev clean package, the > output does claim to be executing this task (referred to by the ID > element, so I know it's not another antrun I've used), but the result is > still just an exploded war that has the standard maven name scheme of > artifactId-version. > > > maven-antrun-plugin > > > RenameFinalDirectory > package > > run > > > >dir="${project.build.directory}\${project.name}"/> >todir="${project.build.directory}\${project.name}"> >dir="${project.build.directory}\${project.artifactId}-${project.version} > "/> > > > > > > > > Any suggestions on why this doesn't work, or what I might use instead? > > -- > This message may contain confidential, proprietary, or legally privileged > information. No confidentiality or privilege is waived by any transmission > to an unintended recipient. If you are not an intended recipient, please > notify the sender and delete this message immediately. Any views expressed > in this message are those of the sender, not those of any entity within the > KBC Financial Products group of companies (together referred to as "KBC > FP"). > > This message does not create any obligation, contractual or otherwise, on > the part of KBC FP. It is not an offer (or solicitation of an offer) of, or > a recommendation to buy or sell, any financial product. Any prices or other > values included in this message are indicative only, and do not necessarily > represent current market prices, prices at which KBC FP would enter into a > transaction, or prices at which similar transactions may be carried on KBC > FP's own books. The information contained in this message is provided "as > is", without representations or warranties, express or implied, of any kind. > Past performance is not indicative of future returns. > > > - > 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]