Bug in POM since 5.14.3

[Owen Farrell]

[WARNING] The POM for org.testng:testng:jar:5.14.5 is invalid,
transitive dependencies (if any) will not be available: 1 problem was
encountered while building the effective model for org.testng:testng:
5.14.5
[ERROR]'dependencies.dependency.systemPath' for
org.testng:guice:jar must specify an absolute path but is /Users/
cbeust/java/testng/target/checkout/lib-supplied/guice-2.0.jar @

The failure to resolve dependencies is causing the following error to
occur in my Maven 3.0.1 runtime:

java.lang.NoClassDefFoundError: com/beust/jcommander/
ParameterException

I originally tried updating my dependency from 5.14.2 to 5.14.5 with
no luck. I incrementally worked my way back down and found this to be
an issue back through 5.14.3. It looks like this goes back to the
GitHub commit 4e69e13 on 9-Dec-2010.

Regards,
~Owen

[Cédric Beust ♔]

Hi Owen,

That's a puzzling error message, first because the path is absolute, despite the message saying otherwise.

Second, I'm using ${basedir}/..., which should resolve locally for you, but instead, it looks like Maven baked in the path of my home directory.

Finally, what I'm seeing on my end when trying to build something that depends on TestNG 5.14.5 with Maven 3 is different from you:

Missing:

----------

1) org.testng:guice:jar:2.0

  Try downloading the file manually from the project website.

  Then, install it using the command: 

      mvn install:install-file -DgroupId=org.testng -DartifactId=guice -Dversion=2.0 -Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 

      mvn deploy:deploy-file -DgroupId=org.testng -DartifactId=guice -Dversion=2.0 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

So there is definitely something wrong here, I'm going to seek the assistance of the Maven gurus.

-- 

Cédric

--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To post to this group, send email to testn...@googlegroups.com.
To unsubscribe from this group, send email to testng-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en.

--
Cédric

[Owen Farrell]

Cédric,

If you take a look at the POM published in central, it already has the path evaluated.:

(from http://repo1.maven.org/maven2/org/testng/testng/5.14.5/testng-5.14.5.pom)

    <dependency>
      <groupId>org.testng</groupId>

      <artifactId>guice</artifactId>

      <version>2.0</version>
      <scope>system</scope>
      <systemPath>/Users/cbeust/java/testng/target/checkout/lib-supplied/guice-2.0.jar</systemPath>

    </dependency>

My guess is that Maven's complaint is that the system path specified doesn't exist on my system. That would also explain the differing behaviors.

Is there any reason you can use the following dependency instead?

    <dependency>
      <groupId>com.google.inject</groupId>
      <artifactId>guice</artifactId>

      <version>2.0</version>
    </dependency>

~Owen

2010/12/21 Cédric Beust ♔ <ced...@beust.com>

[Cédric Beust ♔]

On Tue, Dec 21, 2010 at 3:41 PM, Owen Farrell <owen.f...@gmail.com> wrote:

Cédric,

If you take a look at the POM published in central, it already has the path evaluated.:

(from http://repo1.maven.org/maven2/org/testng/testng/5.14.5/testng-5.14.5.pom)

    <dependency>
      <groupId>org.testng</groupId>

      <artifactId>guice</artifactId>

      <version>2.0</version>
      <scope>system</scope>
      <systemPath>/Users/cbeust/java/testng/target/checkout/lib-supplied/guice-2.0.jar</systemPath>



    </dependency>

My guess is that Maven's complaint is that the system path specified doesn't exist on my system. That would also explain the differing behaviors.

Yup, the error message is wrong, it's not that the path is not absolute, it's because it can't find it, as you point out.

 

Is there any reason you can use the following dependency instead?

    <dependency>
      <groupId>com.google.inject</groupId>
      <artifactId>guice</artifactId>

      <version>2.0</version>
    </dependency>

That's what I used to do but this caused problems with Guice 3 users, so the only way out (I think) is to repackage all the Guice classes inside testng.jar.

Which I'm having a hard time doing with Maven.

--
Cédric

[Ansgar Konermann]

On 22.12.2010 00:45, Cédric Beust ♔ wrote:
>
> That's what I used to do but this caused problems with Guice 3 users,
> so the only way out (I think) is to repackage all the Guice classes
> inside testng.jar.
>

Is TestNG compatible with Guice 3.0, i. e. if you *did* switch the guice
version to 3.0 in the pom dependency, would it still work (compile, pass
tests)?

If so, it might be possible to instruct maven to use "any version
between 2.0 (including) and 3.1 (excluding)" as follows:

<version>[2.0,3.0)</version>

For details of the version specification syntax, see [1].

This way, the TestNG users could define a specific guice version in
their project's pom (let's say they specify 2.0), and maven would
satisfy the TestNG dependency with the same version (since the maven
coordinates only differ in version numbers, maven knows that its the
same artifact, and will select *one* version of it)

Kind regards

Ansgar

[1]
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-version-ranges.html

[Ansgar Konermann]

On 22.12.2010 00:45, Cédric Beust ♔ wrote:
>

> That's what I used to do but this caused problems with Guice 3 users,
> so the only way out (I think) is to repackage all the Guice classes
> inside testng.jar.
>

BTW it could also help users who don't want guice as a transitive
dependency to declare guice an optional dependency like so:

<dependency>
<groupId>com.google.inject</groupId>
<artifactId>guice</artifactId>

<version>[2.0,3.1)</version>
<optional>true</optional>
</dependency>

Users wishing to use guice would have to declare an explicit dependency
on guice in their project's pom. If they don't, they won't have guice in
the classpath (neither will TestNG), and cannot use any of the guice
features of TestNG.

Kind regards

Ansgar

[Mark Derricutt]

Wait - so this means that TestNG will use Guice 2 regardless of if I tell my project to include Guice 3?

--
"Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree

2010/12/22 Cédric Beust ♔ <ced...@beust.com>

[Cédric Beust ♔]

On Tue, Dec 21, 2010 at 4:10 PM, Mark Derricutt <ma...@talios.com> wrote:

Wait - so this means that TestNG will use Guice 2 regardless of if I tell my project to include Guice 3?

Assuming I manage to get this to work with both ant and Maven, yes.

Repackaging like this is pretty standard for "fundamental" libraries (Guice itself does that with its own dependencies).

Is this a problem for you?

--
Cédric

[Mark Derricutt]

Not yet no - we're currently "discussing" which DI framework to use in our current project, Im pushing for Guice but want to wait for Guice 3 as it supports the javax based @Inject annotation which Guice 2 doesn't (afaik) which would be a problem.

Using the new annotation means one -could- swap injection frameworks, which appeases arguments of the other team members than any real technical impediment.

--
"Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree

2010/12/22 Cédric Beust ♔ <ced...@beust.com>

--
Cédric

[Owen Farrell]

I agree with Ansgar's point from about flagging the dependency as optional. That could be the immediate fix to resolve Maven's complaint about the POM. Resolving the issue through declaring dependency ranges sounds like it could be more difficult.

If the dependency is flagged as optional, users would simply have to fulfill one of two scenarios:

1) Declare Guice 2.0 as a Test-scoped dependency
2) Declare Guice >= 2.0 with a scope higher than test (e.g. if you're code explicitly uses Guice 3.0)

There is precedent for this sort of behavior, though not in a test framework. Hibernate uses javassist for bytecode manipulation, yet still flags that transitive dependency as optional.

~Owen

[Cédric Beust ♔]

Yes, there are various ways to fix this with Maven, but that's not the problem.

The problem is having a build that works for both ant *and* Maven while not exposing any com.google.inject classes in the testng.jar file created by ant. This turns out to be quite challenging, although I think I have a solution that might work and which I'll try to implement soon.

-- 

Cédric

Cédric

[Cédric Beust ♔]

Hi Hanasaki,

For your information, this is now moot since as of 5.14.6, TestNG no longer uses Guice internally (but provides externl Guice support with @Guice).

-- 

Cédric

On Thu, Jan 6, 2011 at 4:35 PM, hanasaki testng <hana...@gmail.com> wrote:

What is the driving reason behind the change from 5.14.2 to 5.14.3?
Specifically, the guice dependency changing from guice 2.0 transitive (5.14.2) to no dependency and the resulting failure of any testng run with

org.apache.maven.surefire.booter.SurefireExecutionException: org/testng/guice/Module; nested exception is java.lang.NoClassDefFoundError: org/testng/guice/Module
java.lang.NoClassDefFoundError: org/testng/guice/Module

--
You received this message because you are subscribed to the Google Groups "testng-dev" group.
To post to this group, send email to testn...@googlegroups.com.
To unsubscribe from this group, send email to testng-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/testng-dev?hl=en.

--
Cédric