What about using profiles?  Define 3 profiles; one for wsdl only, one for 
javascript only, and one for both.  Then have the war project activate the 
one it needs.

Tim McGinnis
717 720-1962
Web Development
AES/PHEAA



From:
"Shan Syed" <shan...@gmail.com>
To:
"Maven Users List" <users@maven.apache.org>, kalpa...@gmail.com
Date:
05/13/2010 09:54 AM
Subject:
Re: inheriting and reusing the same plugin for different purposes? doesn't 
seem to find the right executions



Thanks, but the problem is that when I do that, both executions occur, 
even
when I specify inheritance=false.

I basically need to use the same plugin for two different purposes, 
without
either of them affecting the other; I tried to specify different versions
for the mvn dep plugin (i.e. in one block, specify 2.0, and 2.1 for the
other), but no dice.

Running mvn help:effective-pom on my WAR projects always shows the second
maven-dependency-plugin configuration from the root POM in the
pluginManagement section
BUT
in the actual plugin block, it shows the following (below)
(note the second execution, with not configuration or anything associated
with it)

What is the exact logic for the merging of plugin configs in a multimodule
project?

thanks

S

 <plugin>
   <artifactId>maven-dependency-plugin</artifactId>
   <version>2.1</version>
   <executions>
     <execution>
       <id>unpack-wsdls</id>
       <phase>generate-resources</phase>
       <goals>
         <goal>unpack</goal>
       </goals>
       <configuration>

<outputDirectory>C:\dev\sk\sk-saml\sk-saml-web\sk-saml-server\target/war/WEB-INF/wsdl</outputDirectory>
       </configuration>
     </execution>
     <execution>
       <id>unpack-javascripts</id>
     </execution>
   </executions>
   <configuration>
     <artifactItems>
       <artifactItem>
         <artifactId>sk-javascript-token</artifactId>
         <groupId>com.securekey.javascript</groupId>
         <version>1.0-SNAPSHOT</version>
         <classifier>javascript</classifier>
         <type>zip</type>
       </artifactItem>
     </artifactItems>
   </configuration>
 </plugin>

On Thu, May 13, 2010 at 4:54 AM, Kalpak Gadre <kalpa...@gmail.com> wrote:

> I have never tried declaring the same plugin twice, but you can simply
> define more executions in the same plugin declaration like,
>
> <executions>
> <execution>
> <id>one</id>
>         .
>         .
> </execution>
> <execution>
> <id>two</id>
>         .
>         .
> </execution>
> </executions>
>
>
> Thanks,
>
> Kalpak
>
>
>  Here's my scenario: I have a large multimodule project whose WARs share
>> certain dependencies, which are packaged as zips by a few simple
>> assemblies
>> I wrote.
>>
>> I am using the maven-dependency-plugin to unpack the contents of these
>> zips
>> into their destination folders in the webapps.
>>
>> However, to reduce clutter and minimize maintenance, the majority of 
the
>> plugin configuration is in the root POM, like so:
>> (note that I am using the same plugin twice for two different reasons - 
is
>> this valid?)
>>
>>      <build>
>>           <pluginManagement>
>>                <plugins>
>>                      ...
>>                     <!-- unpacking of JAVASCRIPT dependencies -->
>>                     <plugin>
>>                          <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-dependency-plugin</artifactId>
>>                          <inherited>true</inherited>
>>                          <executions>
>>                               <execution>
>>                                    <id>unpack-javascripts</id>
>>                                    <goals>
>>                                         <goal>unpack</goal>
>>                                    </goals>
>>                                    <phase>package</phase>
>>                                    <configuration>
>>
>> 
<outputDirectory>${project.build.directory}/war/scripts</outputDirectory>
>>                                    </configuration>
>>                               </execution>
>>                          </executions>
>>                     </plugin>
>>                     <!-- unpacking of WSDL dependencies -->
>>                     <plugin>
>>                          <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-dependency-plugin</artifactId>
>>                          <inherited>true</inherited>
>>                          <executions>
>>                               <execution>
>>                                    <id>unpack-wsdls</id>
>>                                    <goals>
>>                                         <goal>unpack</goal>
>>                                    </goals>
>>                                    <phase>generate-resources</phase>
>>                                    <configuration>
>>
>>
>> 
<outputDirectory>${project.build.directory}/war/WEB-INF/wsdl</outputDirectory>
>>                                    </configuration>
>>                               </execution>
>>                          </executions>
>>                     </plugin>
>>                </plugins>
>>           </pluginManagement>
>>      </build>
>>
>> Some WARs need the WSDLs, some need the javascript files, while others
>> don't
>> need either - it will be up to the developers creating those projects.
>>
>> Here is an example usage in one of the WARs (note the ID of the 
execution,
>> which is expected to be used to merge the whole configuration)
>>
>>      <build>
>>           <plugins>
>>                <plugin>
>>                     <artifactId>maven-dependency-plugin</artifactId>
>>                     <groupId>org.apache.maven.plugins</groupId>
>>                     <inherited>true</inherited>
>>                     <executions>
>>                          <execution>
>>                               <id>unpack-javascripts</id>
>>                          </execution>
>>                     </executions>
>>                     <configuration>
>>                          <artifactItems>
>>                               <artifactItem>
>>
>> <artifactId>sk-javascript-token</artifactId>
>>
>> <groupId>com.securekey.javascript</groupId>
>> <version>${project.version}</version>
>>                                    <classifier>javascript</classifier>
>>                                    <type>zip</type>
>>                               </artifactItem>
>>                          </artifactItems>
>>                     </configuration>
>>                </plugin>
>>           </plugins>
>>      </build>
>>
>> So in general, the plugin configuration in the root POM will enforce 
some
>> common things (destination folder, etc), and the usage will actually 
allow
>> the developer to select what javascripts they need, without worrying 
about
>> other configuration details.
>>
>> But the problem is when building, it's always the 2nd plugin 
configuration
>> in the root POM that gets used, even though I specify the ID in the 
leaf
>> POMs; so when I do an overall build, all the javascript files end up in 
a
>> WSDL directory, even if I don't reference the WSDL execution at all.
>> I inverse the order, and the result is the opposite; the javascripts 
end
>> up
>> in the right place, but all the WARs that have a WSDL dependency end up
>> with
>> a "scripts" directory full of WSDL files.
>>
>> I was under the impression that the ID is used to merge the 
configurations
>> upon building the project, but I'm not seeing this. Is there a way to
>> specify exactly what configuration to bind to?
>> Specify two executions within the same<plugin>  causes the same 
behaviour,
>> except with both folders.
>>
>> To generalize, in a multi-module project, how can I use the same plugin
>> for
>> totally different uses/scenarios?
>>
>> thanks,
>>
>> Shan
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>



==============================================================================
This message contains privileged and confidential information intended for the 
above addressees only.  If you
receive this message in error please delete or destroy this message and/or 
attachments.  

The sender of this message will fully cooperate in the civil and criminal 
prosecution of any individual engaging
in the unauthorized use of this message.
==============================================================================

Reply via email to