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 culprit is then I can
experiment with the exclusion mechanism. I may have gotten there by
some fluke of a partial build with some modules pulling dependencies
from java.net and others pulling dependencies from elsewhere.
Thanks for the recommendations.
Joe
Prasad Kashyap wrote:
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 applications/console/console-standard has a dependency:
> <dependency>
> <groupId>javax.servlet</groupId>
> <artifactId>jstl</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>
> <groupId>jstl</groupId>
> <artifactId>jstl</artifactId>
> .....................................
> </dependency>
> Hope this is helpful..
Anita,
That is what I was trying to do for both the console and the jsp
samples. However, to download this artifact from java.net it was my
understanding that I also needed to add the java.net repository into the
build and specify the version that I needed to download. To accomplish
that I changed the JSTL dependencyManagement in the root pom to this:
<dependency>
<groupId>jstl</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
And then I added this definition for the repository ...
<repository>
<id>java.net</id>
<url>https://maven-repository.dev.java.net/nonav/repository
</url>
<layout>legacy</layout>
</repository>
However, that is what seems to be causing the build to pick up
javax\servlet\servlet-api\2.4\servlet-api-2.4.jar from java.net rather
than the apache snapshot repo ... which is causing me problems in other
areas of the build.
I didn't follow your earlier post about the JSTL pom being a fake pom ..
but my problem so far isn't with JSTL but rather the servlet-api-2.4 jar.
BTW, I was doing all of this while keeping the references in the Web
Console and the JSP sample just to verify that that the Glassfish JSTL
1.2 would work on JDK 1.4 so long as the newer functions weren't
exploited. My next step would be to remove JSTL from the applications
and instead add it to J2EE assemblies.
Joe
>
> thanks
> Anita
>
>
> */anita kulshreshtha <[EMAIL PROTECTED]>/* wrote:
>
> 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?).
>
> thanks
> Anita
>
> */Joe Bohn <[EMAIL PROTECTED]>/* wrote:
>
> 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) from java.net and check to see if in fact we are picking
> up other
> jars that are not necessary
> (javax\servlet\servlet-api\2.4\servlet-api-2.4.jar in this
case).
>
> Joe
>
>
>
------------------------------------------------------------------------
> Get your email and more, right on the new Yahoo.com
> <http://us.rd.yahoo.com/evt=42973/*http://www.yahoo.com/preview>
>
>
>
------------------------------------------------------------------------
> Yahoo! Messenger with Voice. Make PC-to-Phone Calls
>
<http://us.rd.yahoo.com/mail_us/taglines/postman1/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com>
> to the US (and 30+ countries) for 2ยข/min or less.
