Well, this is a common bad practice to import packages like sun.* or com.sun.*. PMD has even a standard rule to check this pattern. This can particularly be a problem when deploying on other JVM than sun's.
But if you really really must have a dependency against this jar, then I would proceed with standard dependency management : * deploy the right rt.jar in your repository manager * add the dependency against it The thing is I'm unsure it will work fine since I seem to remember that some classes are handled specifically by the classloading system. This one could be one of those. HTH Cheers. 2009/5/6, Charles McCallum <[email protected]>: > > I need to reference WSBindingProvider, a class in the standard rt.jar: > > package edu.upenn.library.itadd.dla.fedora; > ... > import com.sun.xml.internal.ws.developer.WSBindingProvider; > ... > WSBindingProvider bp = (WSBindingProvider)port; > ... > > This builds fine in Eclipse (without maven), but when I try to build from > the commandline I get this: > > ... > [INFO] > ------------------------------------------------------------------------ > [ERROR] BUILD FAILURE > [INFO] > ------------------------------------------------------------------------ > [INFO] Compilation failure > > > /usr/local/dla-input/lib/java/FedoraPost/src/main/java/edu/upenn/library/itadd/dla/fedora/Post.java:[16,40] > package com.sun.xml.internal.ws.developer does not exist > > > /usr/local/dla-input/lib/java/FedoraPost/src/main/java/edu/upenn/library/itadd/dla/fedora/Post.java:[101,5] > cannot find symbol > symbol : class WSBindingProvider > location: class edu.upenn.library.itadd.dla.fedora.Post > ... > > I've tried several different things in the POM, but they make no > difference. Here's one permutation: > > <dependency> > <groupId>dummy</groupId> > <artifactId>dummy</artifactId> > <version>1</version> > <scope>system</scope> > <systemPath>/usr/lib/jvm/newest/jdk/jre/lib/rt.jar</systemPath> > </dependency> > > -- As I understand it, this is an appropriate use of system scope: This > class should just be available through the JDK on any installation. > > -- If I could get it to work, I'd certainly use a property reference in the > systemPath, but here I'm specifying the path explicitly so there's one less > variable. > > -- For system scope, my understanding is that the groupId, artifactId, and > version can be arbitrary. For example, > http://mail-archives.apache.org/mod_mbox/maven-users/200710.mbox/%[email protected]%3e > > > I have a work-around: that is to strip the rt.jar down to just the > subpackage we need, and put it in our local repository, but that really > doesn't seem like the right thing to do. Any suggestions? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
