On 16 February 2010 07:48, Stephen Connolly <[email protected]> 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 > <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
