Hi,
Some users of the maven-clover2-plugin are complaining that when they
run their build with clover, it fails because some transitive
dependencies which have been excluded in the definition
are being added to the compile time classpath.
The offending code is on line #367 here:
http://
>Milos, you can say that's eclipse's problem. But is't a majority of
>users, whether it's good or bad, we need to respect that use case.
I think it should be allowed. Just because Eclipse can't do it doesn't mean
maven shouldn't. It just means if you want to use eclipse and maven, then you
can
As Daniel is in a different time zone, I take the frivolity to elaborate
these.
His project - SAT4J - is the engine behind both P2 and Maven Mercury
dependency conflict resolution, and as such must adhere to Eclipse
platform requirements.
Hope this explains the motivation.
Eugene Kuleshov w
MNG-3203 is what I was thinking of. My use case at the time was to use jdk 1.5
for running the tests only. We needed 1.4 for the actual code but I wanted 1.5
in testing so I could use testng properly to get cobertura output.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Daniel Le Berre wrote:
>
> I develop a library that needs to run on a 1.4 JVM (Eclipse requirements).
>
Can you please elaborate on this? As far as I know Eclipse runs perfectly on
1.5 and despite Eclipse Platform being compatible with 1.4, more and more
Eclipse projects actually require 1.5 t
MCOMPILER-15
MNG-3203 is for a workaround in Maven
Cheers,
Brett
On 20/10/2008, at 10:13 AM, Brian E. Fox wrote:
There's already a jira for this since I originally suggested it a
long time ago. IIRC John and I looked at it and found some problems
with it but I'd have to dig up the jira to
There's already a jira for this since I originally suggested it a long time
ago. IIRC John and I looked at it and found some problems with it but I'd have
to dig up the jira to remember.
-Original Message-
From: Oleg Gusakov [mailto:[EMAIL PROTECTED]
Sent: Sunday, October 19, 2008 4:51
I think the use case is valid - I have seen it a number of times
before. At runtime they are already separate (you can run surefire
with whatever JVM you want, regardless of what you target for
compilation).
The other parameter that needs to be changed is the ability to fork
your own java
Dear all,
I am the one that asked for such feature :) Let me explain why.
I develop a library that needs to run on a 1.4 JVM (Eclipse requirements).
Since I like Java 5+ features, the code is written in 1.5 type and I use
the compiler jsr14 target to produce 1.4 bytecode.
The project being a fe
This could be arranged, but Eugene has a very valid question - Eclipse
sets all those on the project level and might misbehave as soon as
somebody starts debugging such a project.
Milos, you can say that's eclipse's problem. But is't a majority of
users, whether it's good or bad, we need to re
Yes Milos, it was my question.
In fact, it's nice to can specify specific configuration for both source and
test.
For instance, we want to be able to define the source and target level but
also some other configuration such as compilerArgument and so on
Rémy
well, I suppose the question was if configuring just the testCompile
execution doesn't work.
I suppose having a general config at sourcelevel 1.4 and then specific
one for testCompile execution shall work.
...maven-compiler-plugin...
xxx
testCompile
This exactly the proposal - use test-specific settings to enable
source/target, different from compile mojo. So that if nothing is
configured - it's all the same, if testSource/testTarget is set - use
them for testCompile only.
� wrote:
Hi,
We are also interesting for a such feature.
I just
Hi,
We are also interesting for a such feature.
I just wonder if it is not possible to use the testCompile goal for that ?
Thanks,
Rémy
just FYI, it should work fine in NetBeans. (after adding code to
recognize the new parameters)
But I'm not sure if the setting itself is enough to be truly useful.
Since the sourcelevel is to be set to 1.5+ jdk javac only (as the 1.4
javac would spill on the 1.5 source level value), the maven build
This won't work very well in the IDEs. For example, Eclipse does not allow
to specify different compiler settings per-source folder (i.e. main code vs.
tests). So, I would advise against encouraging such feature. Besides users
can still use older junit versions that work on 1.4, or they could m
One of the users requested a separate source/target configuration for
test compiler for the reason of running junit4 tests and yet being java
1.4 in the main classes.
It's a trivial change in the compiler plugin, but I decided to ask here
before changing it.
The proposed change - add two con
17 matches
Mail list logo
