Re: Adding a new repo for artifacts

Thanks Anita. I decided that I couldn't pursue this much more without first getting the JSP 2.1 implementation included that JSTL 1.2 depends upon and building Geronimo with a 1.5 JDK. I did experiment with just slamming the JSTL jar with the Glassfish JAR and running under a 1.5 JVM but

Re: Adding a new repo for artifacts

Thanks Prasad, I couldn't get my local build back to the position that I was in earlier where it was failing because it was pulling in the wrong servlet-api so I didn't get to determine who was pulling in these transitive dependencies. If I get back to that point and determine who the

Re: Adding a new repo for artifacts

John, The jsp example is probably using javax.servlet specs. What I suggested will work only for console. The pom at jstl groupId at java.net at https://maven-repository.dev.java.net/nonav/repository/jstl/poms/jstl-1.2.pom isproject modelVersion4.0.0/modelVersion groupIdjstl/groupId

Re: Adding a new repo for artifacts

Joe, I still think the specs from javax are being picked up as a transitive dependency. Our specs should be from o.a.g.specs groupId. Did you try the exclusion mechanism at all ? Cheers Prasad On 10/20/06, Joe Bohn [EMAIL PROTECTED] wrote: anita kulshreshtha wrote: The

Adding a new repo for artifacts

On my local image I added a new repo to the root pom.xml so that I could pick up the Glassfish JSTL jar. What I discovered is that this resulted in java.net getting placed before the apache repo in the search order and therefore I'm picking up different jars (specs) from java.net (which is

Re: Adding a new repo for artifacts

You just need to put the standard repo in front of the new repo. However, if there are conflicting jars, this is a real problem, and it may be better to create a geronimo private repo, or ask for jstl to be published on ibiblio (if released). On 10/20/06, Joe Bohn [EMAIL PROTECTED] wrote: On

Re: Adding a new repo for artifacts

I don't think the search order will solve your problem because the different spec jars are being picked up as transitive dependencies. So no matter what the search order, those aritfacts will be picked up since they are listed explicitly as dependencies of your dependencies. I believe you should

Re: Adding a new repo for artifacts

Guillaume Nodet wrote: You just need to put the standard repo in front of the new repo. However, if there are conflicting jars, this is a real problem, and it may be better to create a geronimo private repo, or ask for jstl to be published on ibiblio (if released). Thanks for the response

Re: Adding a new repo for artifacts

Thanks Prasad. I'm not yet sure if we are picking up *unnecessary jars* (but it does look suspicious). It appears that we pick these up in our current build. It's just a matter of where we get them from. I'd like to first get things working by picking up just the jar that I need (JSTL)

Re: Adding a new repo for artifacts

Joe Bohn wrote: Guillaume Nodet wrote: You just need to put the standard repo in front of the new repo. However, if there are conflicting jars, this is a real problem, and it may be better to create a geronimo private repo, or ask for jstl to be published on ibiblio (if released). Thanks

Re: Adding a new repo for artifacts

The spec jars for G are picked up from o.a.g.specs groupId. The JSTL pom is a fake pom. Hence it should not download anything else. The best thing to do will be to move this jar to a different location (private repo?).thanksAnitaJoe Bohn [EMAIL PROTECTED] wrote:It appears that we pick these up in

Re: Adding a new repo for artifacts

The applications/console/console-standard has a dependency: dependency groupIdjavax.servlet/groupId artifactIdjstl/artifactId /dependency The pom for this at javax.servlet groupId is a real one. It is not necessary to download the other specs. You could try replacing this with : dependency