[arquillian-issues] [JBoss JIRA] (ARQ-576) The build script bits that downloads and configures 1 or more managed containers should be extracted to a maven plugin, so we don't need to copy paste that logic

Davide D'Alto (JIRA) jira-events at lists.jboss.org
Tue Jun 12 11:39:05 EDT 2012


    [ https://issues.jboss.org/browse/ARQ-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700818#comment-12700818 ] 

Davide D'Alto commented on ARQ-576:
-----------------------------------

@Dan I personally would love a maven plugin for this operations but I'm not sure what you are suggesting.

I would like to start to develop a prototype. This is something that I always miss when I use arquillian.

Initially, I was thinking something like this:

{code:xml}
...
<plugin>
    <groupId>org.jboss.arquillian.maven</groupId>
    <artifactId>arquillian-maven-plugin</artifactId>
    <version>${project.version}</version>
    <executions>
        <execution>
            <id>download-containers</id>
            <phase>initialize</phase>
            <goals>
                <goal>download</goal>
            </goals>
            <containers>
                <container>
		    <id>jbossas-managed</id>
		    <version>7.1.1.Final</version>
		    <addDependencies>true</addDependencies>
		    <downloadContainer>true</downloadContainer>
                    <targetDir><targetDir>
		    <downloadUrl></downloadUrl>
	        </container>
            </containers>
       </execution>
</plugin>
...
{code}

id: e.g. jbossas-managed, jetty-embedded, glassfish-remote, ...
addDependencies:  if true will add the dependencies required to use arquillian
downloadContainer: if you want to download the corresponding container.
targetDir: location where to unpack the downloaded container
downloadUrl: url where the compress container is located (only if you don't want to use the default one in the containers.json file)

They could use some sensible default. For example if you specify the url anything else could be optional unless you need to add the dependencies on the classpath.

Let me know what do you think.
                
> The build script bits that downloads and configures 1 or more managed containers should be extracted to a maven plugin, so we don't need to copy paste that logic
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ARQ-576
>                 URL: https://issues.jboss.org/browse/ARQ-576
>             Project: Arquillian
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Maven Plugin
>            Reporter: Geoffrey De Smet
>            Assignee: Davide D'Alto
>            Priority: Minor
>
> See ARQ-574.
> Now we have to copy paste something like this, per managed container:
> {code}
>   <properties>
>     <managed-appserver.download.dir>${project.basedir}/local/managed-appserver</managed-appserver.download.dir>
>     <managed-appserver.tomcat6.version>6.0.33</managed-appserver.tomcat6.version>
>     <managed-appserver.tomcat6.home>${project.build.directory}/apache-tomcat-${managed-appserver.tomcat6.version}</managed-appserver.tomcat6.home>
>   </properties>
> ...
>       <plugin>
>         <artifactId>maven-antrun-plugin</artifactId>
>         <inherited>false</inherited>
>         <executions>
>           <execution><!-- For managed tomcat -->
>             <phase>generate-test-resources</phase>
>             <configuration>
>               <target>
>                 <mkdir dir="${managed-appserver.download.dir}"/>
>                 <get
>                     src="http://archive.apache.org/dist/tomcat/tomcat-6/v${managed-appserver.tomcat6.version}/bin/apache-tomcat-${managed-appserver.tomcat6.version}.zip"
>                     dest="${managed-appserver.download.dir}" verbose="true" skipexisting="true"/>
>                 <unzip src="${managed-appserver.download.dir}/apache-tomcat-${managed-appserver.tomcat6.version}.zip"
>                        dest="${project.build.directory}"/>
>               </target>
>             </configuration>
>             <goals>
>               <goal>run</goal>
>             </goals>
>           </execution>
>         </executions>
>       </plugin>
>       <plugin>
>         <artifactId>maven-resources-plugin</artifactId>
>         <executions>
>           <execution>
>             <id>copy-resources</id>
>             <phase>process-test-resources</phase>
>             <goals>
>               <goal>copy-resources</goal>
>             </goals>
>             <configuration>
>               <outputDirectory>${managed-appserver.tomcat6.home}/conf</outputDirectory>
>               <overwrite>true</overwrite>
>               <resources>
>                 <resource>
>                   <directory>${basedir}/src/test/conf/tomcat6</directory>
>                 </resource>
>               </resources>
>             </configuration>
>           </execution>
>         </executions>
>       </plugin>
>       <plugin>
>         <artifactId>maven-surefire-plugin</artifactId>
>         <configuration>
>           <environmentVariables>
>             <CATALINA_HOME>${managed-appserver.tomcat6.home}</CATALINA_HOME>
>           </environmentVariables>
>         </configuration>
>       </plugin>
> {code}
> But this changes over time, and since we copy-paste it to our user projects, our copy becomes stale.
> If this could be extracted somehow (aslak is not in favor of adding this to the managed container runtimes, so probably a maven plugin),
> that would be nice.
> Extra optional requirements:
> - It should be easy to ask for multiple managed appservers (say jboss 7, tomcat 6, jetty 6 and jboss 6)
> - Prefer zips from the maven repo over "download" url's. At least if the maven repo is down we know that a clean build doesn't work.
> - What if multiple hudson jobs are testing with arq on the same hudson slave? They can't use the same port!
> - I prefer downloading to /local instead of /target, because the latter gets deleted during "mvn clean". Then again, if it comes from ~/.m2/repository, neither is needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the arquillian-issues mailing list