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 even with that I hit problems because the Glassfish JSTL 1.2 requires some of the JSP 2.1 EL classes. Joe anita kulshreshtha wrote: 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 is project modelVersion4.0.0/modelVersion groupIdjstl/groupId artifactIdjstl/artifactId version1.2/version /project This pom is auto generated.. It will not download any other dependencies. The console should work, because it gets its specs from o.a.g.specs. Thanks Anita */Joe Bohn [EMAIL PROTECTED]/* wrote: anita kulshreshtha wrote: 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 groupIdjstl/groupId artifactIdjstl/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 groupIdjstl/groupId artifactIdjstl/artifactId version1.2/version /dependency And then I added this definition for the repository ... repository idjava.net/id urlhttps://maven-repository.dev.java.net/nonav/repository /url layoutlegacy/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] [EMAIL PROTECTED]YY=73006y5beta=yesy5beta=yesorder=downsort=datepos=0view=ahead=b/* 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] [EMAIL PROTECTED]YY=73006y5beta=yesy5beta=yesorder=downsort=datepos=0view=ahead=b/* 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. All-new Yahoo! Mail http://us.rd.yahoo.com/evt=43256/*http://advision.webevents.yahoo.com/mailbeta- Fire up a more powerful email and get things done faster.
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 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 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 groupIdjstl/groupId artifactIdjstl/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 groupIdjstl/groupId artifactIdjstl/artifactId version1.2/version /dependency And then I added this definition for the repository ... repository idjava.net/id urlhttps://maven-repository.dev.java.net/nonav/repository /url layoutlegacy/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.
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 artifactIdjstl/artifactId version1.2/version/project This pom is auto generated.. It will not download any other dependencies. The console should work, because it gets its specs from o.a.g.specs.ThanksAnitaJoe Bohn [EMAIL PROTECTED] wrote:anita kulshreshtha wrote: 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 groupIdjstl/groupId artifactIdjstl/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 groupIdjstl/groupId artifactIdjstl/artifactId version1.2/version /dependencyAnd then I added this definition for the repository ... repository idjava.net/id urlhttps://maven-repository.dev.java.net/nonav/repository /url layoutlegacy/layout /repositoryHowever, 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. All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.
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 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 groupIdjstl/groupId artifactIdjstl/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 groupIdjstl/groupId artifactIdjstl/artifactId version1.2/version /dependency And then I added this definition for the repository ... repository idjava.net/id urlhttps://maven-repository.dev.java.net/nonav/repository /url layoutlegacy/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.
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 breaking me because they are built on 1.5). So, the question is How can I include a new repo but at the end of the search order? There is a comment in the root POM about genesis being the place where the other repos are specified. Do I have to add my repo to Genesis to get it last in the order instead of first? Thanks, Joe
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 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 breaking me because they are built on 1.5). So, the question is How can I include a new repo but at the end of the search order? There is a comment in the root POM about genesis being the place where the other repos are specified. Do I have to add my repo to Genesis to get it last in the order instead of first? Thanks, Joe -- Cheers, Guillaume Nodet
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 use dependency exclusion to prevent picking spec jars you don't need. Cheers Prasad On 10/20/06, Joe Bohn [EMAIL PROTECTED] wrote: 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 breaking me because they are built on 1.5). So, the question is How can I include a new repo but at the end of the search order? There is a comment in the root POM about genesis being the place where the other repos are specified. Do I have to add my repo to Genesis to get it last in the order instead of first? Thanks, Joe
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 Guillaume. That's what I thought I was doing. The trunk pom.xml only includes a reference to the apache snapshot repo (and a comment that other repos are pulled from Gensis). I added java.net after the apache snapshot ... but for some reason it's looking in java.net before the snapshot repo. Next I'll try placing the def for java.net *before* snapshot to see if that results in java.net being searched *after* the snapshot repo. My other question was if I needed to instead add the new repo to Gensis. It's not obvious to me where in Gensis any additional repos are defined since the Genesis root pom doesn't include any repository defs. Thanks for the help, Joe On 10/20/06, Joe Bohn [EMAIL PROTECTED] wrote: 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 breaking me because they are built on 1.5). So, the question is How can I include a new repo but at the end of the search order? There is a comment in the root POM about genesis being the place where the other repos are specified. Do I have to add my repo to Genesis to get it last in the order instead of first? Thanks, Joe
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) 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 Prasad Kashyap wrote: 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 use dependency exclusion to prevent picking spec jars you don't need. Cheers Prasad On 10/20/06, Joe Bohn [EMAIL PROTECTED] wrote: 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 breaking me because they are built on 1.5). So, the question is How can I include a new repo but at the end of the search order? There is a comment in the root POM about genesis being the place where the other repos are specified. Do I have to add my repo to Genesis to get it last in the order instead of first? Thanks, Joe
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 for the response Guillaume. That's what I thought I was doing. The trunk pom.xml only includes a reference to the apache snapshot repo (and a comment that other repos are pulled from Gensis). I added java.net after the apache snapshot ... but for some reason it's looking in java.net before the snapshot repo. Next I'll try placing the def for java.net *before* snapshot to see if that results in java.net being searched *after* the snapshot repo. Well, that didn't seem to change things. No matter which order I specify java.net is always queried prior to the snapshot repo. My other question was if I needed to instead add the new repo to Gensis. It's not obvious to me where in Gensis any additional repos are defined since the Genesis root pom doesn't include any repository defs. Thanks for the help, Joe On 10/20/06, Joe Bohn [EMAIL PROTECTED] wrote: 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 breaking me because they are built on 1.5). So, the question is How can I include a new repo but at the end of the search order? There is a comment in the root POM about genesis being the place where the other repos are specified. Do I have to add my repo to Genesis to get it last in the order instead of first? Thanks, Joe
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 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
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 groupIdjstl/groupId artifactIdjstl/artifactId . /dependency Hope this is helpful..thanksAnitaanita 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?).thanksAnitaJoe 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).JoeGet your email and more, right on the new Yahoo.com Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
