Re: Surefire and non-jar artifacts
On 16 February 2010 07:48, Stephen Connolly
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.
>
>
> ...
>
> at the moment as long as they are on the classpath types,
> e.g. jar, ejb
> but not ear, rar, war -->
> ..
>
> junit
> junit
> 4.8
> test
>
> ...
>
>
>
>
>
>
>
> maven-surefire-plugin
>
>
>
>
> localhost
> my-rar
> ${project.version}
> rar
> false
>
>
>
>
>
>
> ...
>
>
>
>
>
>
>
>
>
> I feel that the above is:
>
> 1. Too confusing... we have enough places for users to put
> 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
> 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:
>>
>>
>> maven-dependency-plugin
>>
>>
>> generate-test-resources
>>
>> copy-dependencies
>>
>>
>> rar
>> true
>> test
>>
>> ${project.build.directory}/test-dependencies
>>
>>
>>
>>
>>
>> maven-surefire-plugin
>>
>>
>>
>> ${project.build.directory}/test-dependencies/my-jca-impl.rar
>>
>>
>>
>>
>> Which is just plain ugly...
>>
>> My first thought was to have an
>>
>>
>>
>> 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
>>
>>
>>
>> rar
>> true
>>
>>
>>
>> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Surefire and non-jar artifacts
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.
...
..
junit
junit
4.8
test
...
maven-surefire-plugin
localhost
my-rar
${project.version}
rar
false
...
I feel that the above is:
1. Too confusing... we have enough places for users to put
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
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:
>
>
> maven-dependency-plugin
>
>
> generate-test-resources
>
> copy-dependencies
>
>
> rar
> true
> test
>
> ${project.build.directory}/test-dependencies
>
>
>
>
>
> maven-surefire-plugin
>
>
>
> ${project.build.directory}/test-dependencies/my-jca-impl.rar
>
>
>
>
> Which is just plain ugly...
>
> My first thought was to have an
>
>
>
> 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
>
>
>
> rar
> true
>
>
>
> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Surefire and non-jar artifacts
Sent from my [rhymes with tryPod] ;-)
On 15 Feb 2010, at 19:23, David Jencks wrote:
Recall that a conformant rar file has all its classes in embedded
jar files, so putting the "outside" actual rar file on the classpath
doesn't give you access to any classes. If you put classes "loose"
inside a rar then a compliant j2ca container will probably ignore
them.
On Feb 15, 2010, at 9:16 AM, Stephen Connolly wrote:
Hi,
So the lovely JCA resource adapters (a.k.a. rar files)...
In Maven 2.0.9, these were added to the classpath
What exactly was added to the classpath?
the Rar and all its dependencies (so the rar gives you the ra.XML on
the classpath, the dependencies gives you all the jars inside the rar
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:
maven-dependency-plugin
generate-test-resources
copy-dependencies
rar
true
test
${project.build.directory}/test-dependenciesoutputDirectory>
maven-surefire-plugin
${project.build.directory}/test-
dependencies/my-jca-impl.rar
This looks to me as if its putting the rar on the classpath, not the
jars inside that contain the classes.
it's putting the ra.XML on the classpath, all the other classes are on
the classpath in my case
Which is just plain ugly...
My first thought was to have an
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
rar
true
So what do people think?
So are you proposing that if you have a rar, war, or ear, including
it as a dependency will figure out all the jars inside, compute the
actual internal classpath, and add all these to the maven
classpath? I have not problem with this but it's unclear to me if
that's what you are asking for.
if you define a type, eg rar as additional, then it will be added to
the classpath, if you also say include transitive, then all that
dependency's dependencies will be also added to the classpath, so for
a rar you would want includeTransitive... other types you might not
want transitives ... if you have a third party rar with a minimal pom,
tough luck
thanks
david jencks
-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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Surefire and non-jar artifacts
Recall that a conformant rar file has all its classes in embedded jar
files, so putting the "outside" actual rar file on the classpath
doesn't give you access to any classes. If you put classes "loose"
inside a rar then a compliant j2ca container will probably ignore them.
On Feb 15, 2010, at 9:16 AM, Stephen Connolly wrote:
Hi,
So the lovely JCA resource adapters (a.k.a. rar files)...
In Maven 2.0.9, these were added to the classpath
What exactly was 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:
maven-dependency-plugin
generate-test-resources
copy-dependencies
rar
true
test
${project.build.directory}/test-dependenciesoutputDirectory>
maven-surefire-plugin
${project.build.directory}/test-
dependencies/my-jca-impl.rar
This looks to me as if its putting the rar on the classpath, not the
jars inside that contain the classes.
Which is just plain ugly...
My first thought was to have an
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
rar
true
So what do people think?
So are you proposing that if you have a rar, war, or ear, including it
as a dependency will figure out all the jars inside, compute the
actual internal classpath, and add all these to the maven classpath?
I have not problem with this but it's unclear to me if that's what you
are asking for.
thanks
david jencks
-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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Surefire and non-jar artifacts
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:
maven-dependency-plugin
generate-test-resources
copy-dependencies
rar
true
test
${project.build.directory}/test-dependencies
maven-surefire-plugin
${project.build.directory}/test-dependencies/my-jca-impl.rar
Which is just plain ugly...
My first thought was to have an
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
rar
true
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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
