maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Surefire and non-jar artifacts
Date Tue, 16 Feb 2010 07:53:00 GMT
On 16 February 2010 07:48, Stephen Connolly
<stephen.alan.connolly@gmail.com> wrote:
> Just to clarify what I am suggesting:
>
> Plan 1 - which I have rejected on the basis that I feel it is
> un-Maven-like... if somebody who has a strong opinion on the
> architecture and direction of Maven feels that it actually is a
> Maven-like way, then perhaps we should reconsider:
>
> Add an additional dependencies section to the configuration of surefire, e.g.
>
> <project>
>  ...
>  <dependencies>
>    <!- regular dependencies with test scope are on the surefire classpath
>          at the moment as long as they are on the classpath types,
> e.g. jar, ejb
>          but not ear, rar, war -->
>    ..
>    <dependency>
>      <groupId>junit</groupId>
>      <artifactId>junit</artifactId>
>      <version>4.8</version>
>      <scope>test</scope>
>    </dependency>
>    ...
>  </dependencies>
>
>  <!-- we also have dependency management with which to confuse users -->
>
>  <build>
>    <plugins>
>      <plugin>
>        <artifactId>maven-surefire-plugin</artifactId>
>        <configuration>
>          <!-- here is the Plan 1 proposal -->
>          <dependencies>
>            <dependency>
>              <groupId>localhost</groupId>
>              <artifactId>my-rar</artifactId>
>              <version>${project.version}</version> <!-- needed
to let
> me release -->
>              <type>rar</type>
>              <excludeTransitive>false</excludeTransitive> <!--
need
> some way to pull in / exclude transitives -->
>            </dependency>
>          </dependencies>
>           </configuration>
>           <!-- now if we need some custom surefire extension...
>                  lets confuse users even more: -->
>           <dependencies>
>               <dependency>
>                  ...
>               </dependency>
>            </dependencies>
>            </dependency>
>          </dependencies>
>         </plugin>
>        </plugins>
>  </build>
> </project>
>
> I feel that the above is:
>
> 1. Too confusing... we have enough places for users to put
> <dependency> like tags as it stands:
> /project(/dependencyManagement)?/dependencies/dependency,
> /project/build(/pluginManagement)?/plugins/plugin/dependencies/dependency,
> etc.  This would be adding another, i.e.
> /project/build(/pluginManagement)?/plugins/plugin(/executions/execution)?/configuration/dependencies/dependency.
>
> 2. We need a special type of dependency tag (so it's not the same as
> other dependency sections.  i.e. we really need control over whether
> to pull in transitives or not... I guess we could hijack exclusions
> and add wildcards... but that will just confuse users even more (why
> do wildcards work in surefire dependencies but not in regular
> dependencies)
>
> 3. To open to abuse... it would basically be a hack to handle not
> having additional "special" scopes.
>

oh, I forgot

4. Still does not solve the problem... i.e. if I have a war that
depends on another war, with this solution, to get that indirect war's
dependencies on the classpath for surefire's tests I need to list that
war also... the additionalClasspathTypes solves the issue in a
transparent way...

> On the other hand, #3 could well be something I want ;-)
>
> -Stephen
>
> On 15 February 2010 17:16, Stephen Connolly
> <stephen.alan.connolly@gmail.com> wrote:
>> Hi,
>>
>> So the lovely JCA resource adapters (a.k.a. rar files)...
>>
>> In Maven 2.0.9, these were added to the classpath
>>
>> In Maven 2.2.1, these are no longer added to the classpath...
>>
>> The former made testing resource adapters easy, but causes issues when
>> packaging a resource adapter in an EAR...
>>
>> The later simplifies packaging RAR files inside an EAR (unless
>> possibly you want to try for a skinny RAR) but makes testing the code
>> that depends on the RAR more complex.
>>
>> For example, using the lovely openejb, I now have to do:
>>
>>            <plugin>
>>                <artifactId>maven-dependency-plugin</artifactId>
>>                <executions>
>>                    <execution>
>>                        <phase>generate-test-resources</phase>
>>                        <goals>
>>                            <goal>copy-dependencies</goal>
>>                        </goals>
>>                        <configuration>
>>                            <includeTypes>rar</includeTypes>
>>                            <stripVersion>true</stripVersion>
>>                            <includeScope>test</includeScope>
>>
>> <outputDirectory>${project.build.directory}/test-dependencies</outputDirectory>
>>                        </configuration>
>>                    </execution>
>>                </executions>
>>            </plugin>
>>            <plugin>
>>                <artifactId>maven-surefire-plugin</artifactId>
>>                <configuration>
>>                    <additionalClasspathElements>
>>
>> <additionalClasspathElement>${project.build.directory}/test-dependencies/my-jca-impl.rar</additionalClasspathElement>
>>                    </additionalClasspathElements>
>>                </configuration>
>>            </plugin>
>>
>> Which is just plain ugly...
>>
>> My first thought was to have an
>>
>> <additionalClasspathDependencies>
>>
>> configuration in surefire... but I just know that it would be abused
>> like some mad crazy fool... and because it would not be taking part in
>> depMgmt, it would cause issues with releasing.... so that's not best
>> practice way at all then....
>>
>> My second thought is to have
>>
>> <additionalClasspathTypes>
>>  <additionalClasspathType>
>>    <type>rar</type>
>>    <includeTransitive>true</includeTransitive>
>>  </additionalClasspathType>
>> </additionalClasspathTypes>
>>
>> So what do people think?
>>
>> -Stephen.
>>
>> P.S.
>>  I've rejected my first plan... if Jason to aproves I'll resurect
>> it... otherwise Plan 2 or 3 (TBD)
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message