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:48:10 GMT
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.

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