Re: mvn-weblogic-plugin Couldn't find a version in [8.1]...
You are using the wrong version of the plugin if you are wanting to use weblogic 8.1 you will need to use plugin version 2.8.x Scott Ryan President/CTO Soaring Eagle L.L.C. www.soaringeagleco.com sc...@theryansplace.com (303) 263-3044 www.mymonavie.com/soaringeagle www.thegreatproduct.com/soaringeagle On May 29, 2009, at 1:18 PM, Jesfre wrote: Hi senseis! I have a problem when I'm trying to execute the mvn weblogic:listapps... The console show me these errors: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Couldn't find a version in [8.1] to match range [9.0,11.0) weblogic:weblogic:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2), codehaus.org (http://repository.codehaus.org), snapshots (http://snapshots.repository.codehaus.org) Path to dependency: 1) org.codehaus.mojo:weblogic-maven-plugin:maven-plugin:2.9.1 I don't understand why... the snapshots repository exists There is my pom.xml configuration... plugin groupIdorg.codehaus.mojo/groupId artifactIdweblogic-maven-plugin/artifactId version2.8.0-SNAPSHOT/version configuration adminServerHostName localhost /adminServerHostName adminServerPort7001/adminServerPort adminServerProtocolhttp/adminServerProtocol userIdweblogic/userId passwordweblogic/password uploadfalse/upload remotefalse/remote verbosefalse/verbose debugfalse/debug targetNamesmyserver/targetNames /configuration /plugin dependencies... dependency groupIdorg.codehaus.mojo/groupId artifactIdweblogic-maven-plugin/artifactId version2.8.0-SNAPSHOT/version /dependency Can somebody helps??? I'm trying to deploy an application to WL 8.1 (SP3)... -- View this message in context: http://www.nabble.com/mvn-weblogic-plugin-Couldn%27t-find-a-version-in--8.1-...-tp23785666p23785666.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: weblogic-maven-plugin + WL 8.1 (SP3) ?
Some of the functions work on SP4. SP4 offers many fixes that are very important so I would suggest that you upgrade ASAP. If my mind serves me correctly they made significant changes to the way remote deployment works but if you are just doing normal deployment it should work fine. Scott Ryan President/CTO Soaring Eagle L.L.C. www.soaringeagleco.com sc...@theryansplace.com (303) 263-3044 www.mymonavie.com/soaringeagle www.thegreatproduct.com/soaringeagle On May 28, 2009, at 5:57 PM, Mick Knutson wrote: We are using wls 8, 9 and 10 at my project. I have resorted to using the ant tasks to deploy to 8. --- Thank You… Mick Knutson, President BASE Logic, Inc. Enterprise Architecture, Design, Mentoring Agile Consulting p. (866) BLiNC-411: (254-6241-1) f. (415) 685-4233 Website: http://baselogic.com Linked IN: http://linkedin.com/in/mickknutson Vacation Rental: http://tahoe.baselogic.com --- On Thu, May 28, 2009 at 4:41 PM, Jesfre jesfre...@gmail.com wrote: Hi everybody... I'm currently migrating an ancient enterprise project with Java 1.4, and Weblogic 1.8 (SP3) built with Ant to be build with Maven2. The entire structure is completed, but now is time to make the deploy task... People talk about weblogic-maven-plugin but in the http://mojo.codehaus.org/weblogic-maven-plugin/deploy-mojo.html site says that ...provides support for Weblogic 8.1(sp4+) and 9.0 deployment capabilities... So, it can't deploy applications on WL 1.8 (SP3)? Any suggest about how can I do this? Thanks in advance... -- View this message in context: http://www.nabble.com/weblogic-maven-plugin-%2B-WL-8.1-%28SP3%29---tp23772049p23772049.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: AW: Please Unsubscribe me
Make sure you check you spam folder. Sometimes the unsubscribes go there and if you don't confirm the unsubscribe it does not fully unsubscribe you. Scott Ryan President/CTO Soaring Eagle L.L.C. www.soaringeagleco.com sc...@theryansplace.com (303) 263-3044 On Dec 12, 2008, at 3:14 AM, Baeriswyl Kuno - Extern (IT-BA-MV) wrote: well, that's what I have done yesterday and today for a couple of times...I really need to get out of the list, otherwise my account will be fluded .. Kuno -Ursprüngliche Nachricht- Von: Stelios Philippou [mailto:stevo...@gmail.com] Gesendet: Freitag, 12. Dezember 2008 09:08 An: Maven Users List Betreff: Re: Please Unsubscribe me send here and wait users-unsubscr...@maven.apache.org Robert Orben - Older people shouldn't eat health food, they need all the preservatives they can get. On Fri, Dec 12, 2008 at 9:59 AM, Baeriswyl Kuno - Extern (IT-BA-MV) kuno.baeris...@sbb.ch wrote: I'd like to unsubscribe from this list. Apparently, the unsubscribtion procedure doens't work, since I've tried a few times and never got any confirmation. But the message are still coming in. Can anybody help? Thanks - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Good weblogic plugin?
We have been maintaining the weblogic plugin on codehaus and it works fine for all versions 8 -10. Are there some problems you are having? Scott Ryan President/CTO Soaring Eagle L.L.C. www.soaringeagleco.com [EMAIL PROTECTED] (303) 263-3044 On Dec 4, 2008, at 12:20 PM, [EMAIL PROTECTED] wrote: Hi! Have to deploy (generate stubs - deployment descriptos) for both WLS 9.2 and 10.x. Anybody know of any good plugins? The one at mojo seems a little abandoned and mainly for 8.2 usage - and barely 9.0 - and I haven't had great success with it yet? I see cargo has had some weblogic activity lately - anybody tried it? -- David J. M. Karlsen - +47 90 68 22 43 http://www.davidkarlsen.com http://mp3.davidkarlsen.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven/OS X Development Question
I have exactly that configuration and it has been working fine for over a year. You might try to see if Appfuse works on it. Appfuse has an Archetype that will build a totally new self contained running application for you. Anything I can do to help let me know. Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Fri, Sep 5, 2008 at 10:20 AM, John [EMAIL PROTECTED] wrote: Hi, Is anyone developing using Maven and Java 5 on OS X Leopard with a first generation Macbook Pro (MBP) Core Duo? I am experiencing an odd issue that only seems present on a Core Duo and I've tried it on a Core 2 Duo (MBP/OS X Leopard), Windows XP and RHEL Linux and only the first gen Core Duo has the issue. Just curious if anyone else is using a MBP Core Duo for development... Thanks, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jboss ESB and Maven
We have used the plugin with great success and can send you our layout but basically use the standard maven 2 structure as follows src/main/java src/main/resources put the jbm-queue-service.xml file in the resources directory and the following files in the resource/META-INF directory deployment.xml jboss-esb.xml Let me know if i can help in any way. Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Thu, Sep 4, 2008 at 1:07 PM, Lam Hayward [EMAIL PROTECTED]wrote: I have a Jboss ESB example project with ant build script to convert to maven. Maven usually prefers certain directory structure. There is a plugin for jboss esb packaging. Is there somewhere I can find the directory structure and pom.xml? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jboss ESB and Maven
Here are some relevant sections of my pom packagingjboss-esb/packaging build resources resource directorysrc/main/resources/directory filteringtrue/filtering /resource /resources plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packaging-maven-plugin/artifactId extensionstrue/extensions /plugin /plugins /build Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Thu, Sep 4, 2008 at 2:23 PM, Lam Hayward [EMAIL PROTECTED]wrote: I figured the directory structure would be similar to regular maven project. So, I have the following: src/main/java src/main/resources src/test/java src/test/resources I followed your suggestion to move the deployment.xml and jboss-esb.xml to src/main/resources/META-INF directory. In the pom.xml file, I specified packagingjboss-esb/packaging and build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packaging-maven-plugin/artifactId !-- Enable packaging types and lifecycle bindings. -- extensionstrue/extensions /plugin /plugins /build When I run mvn install, it complains: $ mvn install [INFO] Scanning for projects... [INFO] [INFO] Building esb [INFO]task-segment: [install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot find lifecycle mapping for packaging: 'esb'. Component descriptor cannot be found in the component repository: org.apache.mav en.lifecycle.mapping.LifecycleMappingesb. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Sep 04 16:16:44 EDT 2008 [INFO] Final Memory: 2M/4M [INFO] It didn't seem to compile the code. The target directory has empty lib directory and empty META-INF directory. Is there something missing? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ryan Sent: September 4, 2008 3:50 PM To: Maven Users List Subject: Re: Jboss ESB and Maven We have used the plugin with great success and can send you our layout but basically use the standard maven 2 structure as follows src/main/java src/main/resources put the jbm-queue-service.xml file in the resources directory and the following files in the resource/META-INF directory deployment.xml jboss-esb.xml Let me know if i can help in any way. Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Thu, Sep 4, 2008 at 1:07 PM, Lam Hayward [EMAIL PROTECTED]wrote: I have a Jboss ESB example project with ant build script to convert to maven. Maven usually prefers certain directory structure. There is a plugin for jboss esb packaging. Is there somewhere I can find the directory structure and pom.xml? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jboss ESB and Maven
Are you sure the packaging is jboss-esb rather than just esb as the error message states? I got the same error you did when i changed my packaging to just esb. Make sure you only have one packaging entry. Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Thu, Sep 4, 2008 at 2:23 PM, Lam Hayward [EMAIL PROTECTED]wrote: I figured the directory structure would be similar to regular maven project. So, I have the following: src/main/java src/main/resources src/test/java src/test/resources I followed your suggestion to move the deployment.xml and jboss-esb.xml to src/main/resources/META-INF directory. In the pom.xml file, I specified packagingjboss-esb/packaging and build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packaging-maven-plugin/artifactId !-- Enable packaging types and lifecycle bindings. -- extensionstrue/extensions /plugin /plugins /build When I run mvn install, it complains: $ mvn install [INFO] Scanning for projects... [INFO] [INFO] Building esb [INFO]task-segment: [install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot find lifecycle mapping for packaging: 'esb'. Component descriptor cannot be found in the component repository: org.apache.mav en.lifecycle.mapping.LifecycleMappingesb. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Sep 04 16:16:44 EDT 2008 [INFO] Final Memory: 2M/4M [INFO] It didn't seem to compile the code. The target directory has empty lib directory and empty META-INF directory. Is there something missing? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ryan Sent: September 4, 2008 3:50 PM To: Maven Users List Subject: Re: Jboss ESB and Maven We have used the plugin with great success and can send you our layout but basically use the standard maven 2 structure as follows src/main/java src/main/resources put the jbm-queue-service.xml file in the resources directory and the following files in the resource/META-INF directory deployment.xml jboss-esb.xml Let me know if i can help in any way. Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Thu, Sep 4, 2008 at 1:07 PM, Lam Hayward [EMAIL PROTECTED]wrote: I have a Jboss ESB example project with ant build script to convert to maven. Maven usually prefers certain directory structure. There is a plugin for jboss esb packaging. Is there somewhere I can find the directory structure and pom.xml? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jboss ESB and Maven
Are you sure esb does not appear anywhere else in your pom or any parent pom? Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Thu, Sep 4, 2008 at 2:45 PM, Lam Hayward [EMAIL PROTECTED]wrote: I have exactly the same packaging and plugin as yours. modelVersion4.0.0/modelVersion groupIdmyCompany/groupId artifactIdmyEsb/artifactId packagingjboss-esb/packaging version1.0-SNAPSHOT/version namemyEsb/name I use jboss-esb for packaging. The codehause plugin jar was downloaded to my local repository. Everything seems to be there. Even if I run mvn compile, I get the same error. $ mvn compile [INFO] Scanning for projects... [INFO] [INFO] Building esb [INFO]task-segment: [compile] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot find lifecycle mapping for packaging: 'esb'. Component descriptor cannot be found in the component repository: org.apache.mav en.lifecycle.mapping.LifecycleMappingesb. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Sep 04 16:44:04 EDT 2008 [INFO] Final Memory: 2M/4M [INFO] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ryan Sent: September 4, 2008 4:33 PM To: Maven Users List Subject: Re: Jboss ESB and Maven Here are some relevant sections of my pom packagingjboss-esb/packaging build resources resource directorysrc/main/resources/directory filteringtrue/filtering /resource /resources plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packaging-maven-plugin/artifactId extensionstrue/extensions /plugin /plugins /build Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Thu, Sep 4, 2008 at 2:23 PM, Lam Hayward [EMAIL PROTECTED]wrote: I figured the directory structure would be similar to regular maven project. So, I have the following: src/main/java src/main/resources src/test/java src/test/resources I followed your suggestion to move the deployment.xml and jboss-esb.xml to src/main/resources/META-INF directory. In the pom.xml file, I specified packagingjboss-esb/packaging and build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packaging-maven-plugin/artifactId !-- Enable packaging types and lifecycle bindings. -- extensionstrue/extensions /plugin /plugins /build When I run mvn install, it complains: $ mvn install [INFO] Scanning for projects... [INFO] -- -- [INFO] Building esb [INFO]task-segment: [install] [INFO] -- -- [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Cannot find lifecycle mapping for packaging: 'esb'. Component descriptor cannot be found in the component repository: org.apache.mav en.lifecycle.mapping.LifecycleMappingesb. [INFO] -- -- [INFO] For more information, run Maven with the -e switch [INFO] -- -- [INFO] Total time: 1 second [INFO] Finished at: Thu Sep 04 16:16:44 EDT 2008 [INFO] Final Memory: 2M/4M [INFO] -- -- It didn't seem to compile the code. The target directory has empty lib directory and empty META-INF directory. Is there something missing? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ryan Sent: September 4, 2008 3:50 PM To: Maven Users List Subject: Re: Jboss ESB and Maven We have used the plugin with great success and can send you our layout but basically use the standard maven 2 structure as follows src/main/java src/main/resources put the jbm-queue-service.xml file in the resources directory
Re: Jboss ESB and Maven
try changing the packaging to war and see if you get a warning about web.xml when you do mvn install. Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Thu, Sep 4, 2008 at 3:04 PM, Scott Ryan [EMAIL PROTECTED] wrote: Are you sure esb does not appear anywhere else in your pom or any parent pom? Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Thu, Sep 4, 2008 at 2:45 PM, Lam Hayward [EMAIL PROTECTED]wrote: I have exactly the same packaging and plugin as yours. modelVersion4.0.0/modelVersion groupIdmyCompany/groupId artifactIdmyEsb/artifactId packagingjboss-esb/packaging version1.0-SNAPSHOT/version namemyEsb/name I use jboss-esb for packaging. The codehause plugin jar was downloaded to my local repository. Everything seems to be there. Even if I run mvn compile, I get the same error. $ mvn compile [INFO] Scanning for projects... [INFO] [INFO] Building esb [INFO]task-segment: [compile] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Cannot find lifecycle mapping for packaging: 'esb'. Component descriptor cannot be found in the component repository: org.apache.mav en.lifecycle.mapping.LifecycleMappingesb. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Thu Sep 04 16:44:04 EDT 2008 [INFO] Final Memory: 2M/4M [INFO] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ryan Sent: September 4, 2008 4:33 PM To: Maven Users List Subject: Re: Jboss ESB and Maven Here are some relevant sections of my pom packagingjboss-esb/packaging build resources resource directorysrc/main/resources/directory filteringtrue/filtering /resource /resources plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packaging-maven-plugin/artifactId extensionstrue/extensions /plugin /plugins /build Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Thu, Sep 4, 2008 at 2:23 PM, Lam Hayward [EMAIL PROTECTED]wrote: I figured the directory structure would be similar to regular maven project. So, I have the following: src/main/java src/main/resources src/test/java src/test/resources I followed your suggestion to move the deployment.xml and jboss-esb.xml to src/main/resources/META-INF directory. In the pom.xml file, I specified packagingjboss-esb/packaging and build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packaging-maven-plugin/artifactId !-- Enable packaging types and lifecycle bindings. -- extensionstrue/extensions /plugin /plugins /build When I run mvn install, it complains: $ mvn install [INFO] Scanning for projects... [INFO] -- -- [INFO] Building esb [INFO]task-segment: [install] [INFO] -- -- [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Cannot find lifecycle mapping for packaging: 'esb'. Component descriptor cannot be found in the component repository: org.apache.mav en.lifecycle.mapping.LifecycleMappingesb. [INFO] -- -- [INFO] For more information, run Maven with the -e switch [INFO] -- -- [INFO] Total time: 1 second [INFO] Finished at: Thu Sep 04 16:16:44 EDT 2008 [INFO] Final Memory: 2M/4M [INFO] -- -- It didn't seem to compile the code. The target directory has empty lib directory and empty META-INF directory. Is there something missing? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ryan Sent: September 4, 2008 3
Re: Jboss ESB and Maven - success!!
http://repository.jboss.com/maven2 should have all the jboss stuff Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Thu, Sep 4, 2008 at 3:05 PM, Lam Hayward [EMAIL PROTECTED]wrote: I created a brand new Java project from eclipse and all the maven directory from scratch. It works now!! It produced the .esb file. Thanks. In terms of jar dependency, a lot of the jboss esb jars can't be found in maven repo. Do you simply add them to your local repository? Or is there a repository out there I should reference? -Original Message- From: Lam Hayward [mailto:[EMAIL PROTECTED] Sent: September 4, 2008 4:47 PM To: Maven Users List Subject: RE: Jboss ESB and Maven Only one packaging element is in the pom.xml. That should be ok. The error shows esb is a very strange. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ryan Sent: September 4, 2008 4:36 PM To: Maven Users List Subject: Re: Jboss ESB and Maven Are you sure the packaging is jboss-esb rather than just esb as the error message states? I got the same error you did when i changed my packaging to just esb. Make sure you only have one packaging entry. Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Thu, Sep 4, 2008 at 2:23 PM, Lam Hayward [EMAIL PROTECTED]wrote: I figured the directory structure would be similar to regular maven project. So, I have the following: src/main/java src/main/resources src/test/java src/test/resources I followed your suggestion to move the deployment.xml and jboss-esb.xml to src/main/resources/META-INF directory. In the pom.xml file, I specified packagingjboss-esb/packaging and build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjboss-packaging-maven-plugin/artifactId !-- Enable packaging types and lifecycle bindings. -- extensionstrue/extensions /plugin /plugins /build When I run mvn install, it complains: $ mvn install [INFO] Scanning for projects... [INFO] -- -- [INFO] Building esb [INFO]task-segment: [install] [INFO] -- -- [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Cannot find lifecycle mapping for packaging: 'esb'. Component descriptor cannot be found in the component repository: org.apache.mav en.lifecycle.mapping.LifecycleMappingesb. [INFO] -- -- [INFO] For more information, run Maven with the -e switch [INFO] -- -- [INFO] Total time: 1 second [INFO] Finished at: Thu Sep 04 16:16:44 EDT 2008 [INFO] Final Memory: 2M/4M [INFO] -- -- It didn't seem to compile the code. The target directory has empty lib directory and empty META-INF directory. Is there something missing? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ryan Sent: September 4, 2008 3:50 PM To: Maven Users List Subject: Re: Jboss ESB and Maven We have used the plugin with great success and can send you our layout but basically use the standard maven 2 structure as follows src/main/java src/main/resources put the jbm-queue-service.xml file in the resources directory and the following files in the resource/META-INF directory deployment.xml jboss-esb.xml Let me know if i can help in any way. Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Thu, Sep 4, 2008 at 1:07 PM, Lam Hayward [EMAIL PROTECTED]wrote: I have a Jboss ESB example project with ant build script to convert to maven. Maven usually prefers certain directory structure. There is a plugin for jboss esb packaging. Is there somewhere I can find the directory structure and pom.xml? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: Sonar
WE are using it during our autobuild process in Cruise Control and Maven 2. We are running Sonar as a seperate website and process so we use both site and sonar as both provide great information. Sonar is database based so you can get history which is awesome and we use mysql. Site is file based more like an http website. hope this helps. Scott Ryan President/CTO Soaring Eagle L.L.C. Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com On Fri, Jul 25, 2008 at 10:07 AM, Yanko, Curtis [EMAIL PROTECTED] wrote: Anybody using Sonar? It's not clear to me how it works in conjunction with something like Site or does it replace it? == Curtis Yanko Application Developer Infrastructure Services Source-Build-Deploy This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
3 things not working in the maven Ear plugin 2.3.1 with maven 2.0.9
I have discovered some issues with the latest ear plugin and was wondering if anyone was having similar issues or had a fix. It looks like the last release of the plugin was some time ago. 1. Context root does not seem to be getting set in the application xml 2. BundleFileName does not appear to be working 3. Module definitions are placed in a random order within the application XML. Here is a sample of my pom for the ear definition build plugins plugin artifactIdmaven-ear-plugin/artifactId configuration finalNameedsweb/finalName defaultLibBundleDir/lib/defaultLibBundleDir webModule artifactIdedsweb-war/artifactId contextRoot/edsweb/contextRoot /webModule ejb3Module artifactIdjboss-seam/artifactId bundleFileNamejboss-seam.jar/bundleFileName /ejb3Module ejb3Module artifactIdedsweb-ejb/artifactId bundleFileNameedsweb-ejb.jar/bundleFileName /ejb3Module ejb3Module artifactIdedsrpt-ejb/artifactId bundleFileNameedsrpt-ejb.jar/bundleFileName /ejb3Module ejb3Module artifactIdedsdata-ejb/artifactId bundleFileNameedsdata-ejb.jar/bundleFileName /ejb3Module ejb3Module artifactIdedsbusiness-ejb/artifactId bundleFileNameedsbusiness-ejb.jar/bundleFileName /ejb3Module jarModule artifactIdjboss-el/artifactId /jarModule /configuration /plugin /plugins /build When I run the mvn ear command the artifacts in the directory still have the version number appended to them as is the case in the application xml despite the bundleFileName parameter. The context root is set to the default (edsweb-war) rather that what I set. Also the ordering of the modules in the application.xml seems rather random and it is very important that I am able to control the loading order of these modules. If they are not loaded in the proper order they will not work. Any input would be appreciated. Scott Ryan Consultant/Java Developer Cell: 303 263-3044
Do you do .Net development on the Mac
This is pretty cool for Mac and Visual Studio funtionality. http://www.monodevelop.com/Main_Page Scott Ryan President/CTO Soaring Eagle L.L.C. 9742 S. Whitecliff Place Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] www.soaringeagleco.com
RE: Hook ivy repository to Maven
You are correct. We use both Ivy and Maven to access our Archiva proxy repository as well as several external Maven repositories. The configuration is very straightforward and you can turn on and off the transitive dependency feature of Maven within Ivy if you like. Scott D. Ryan President and CTO Soaring Eagle, L.L.C. 9742 S.Whitecliff Place Highlands Ranch, Co. 80129 (303) 263-3044 [EMAIL PROTECTED] -Original Message- From: Wei Tan [mailto:[EMAIL PROTECTED] Sent: Friday, April 25, 2008 5:47 AM To: users@maven.apache.org Cc: [EMAIL PROTECTED] Subject: Hook ivy repository to Maven Dear all, We have a project which needs to use jars in a ivy repository, but our project is managed by Maven. Can Maven access ivy repo. and fetch the dependencies (jars)? I was told that ivy can acess Maven repo. Thanks. Wei - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Substitute One Plugin for Another?
You could try to use an include and exclude policy for both plugins based on some pattern. You could also try a lifecycle approach and sort the lifecycle steps properly.Also we are adding that capability to the Weblogic plugin at codehaus but just trying to get it checked in and into the next release. Scott Ryan [EMAIL PROTECTED] (303) 263-3044 On Tue, Mar 11, 2008 at 1:37 PM, SingleShot [EMAIL PROTECTED] wrote: I am writing a custom Maven plugin that wraps a code generation tool (BEA's Java Web Service Compiler for Weblogic Server). The tool takes in java source files and generates java class files (i.e. it is a compiler). The class files are different from what the normal Java compiler generates. I have attached it to the compile phase of the normal build lifecycle. One issue I have is that the java class files get generated twice: once by the maven-compiler-plugin, and once by my custom plugin. I end up with two sets of class files that are different (they are generated to different locations by default). There are a couple of hacks I can do to solve this, but what I really want is for my plugin to be used in place of the maven-compiler-plugin, and only for a particular module within my hierarchy of modules. Is there a way to configure a project and/or its plugins to say normally you should use the maven-compiler-plugin to compile, but in this one particular case, use my custom plugin instead? Any suggestions would be appreciated. Thanks, Mike -- View this message in context: http://www.nabble.com/Substitute-One-Plugin-for-Another--tp15988286s177p15988286.html Sent from the Maven - Users mailing list archive at Nabble.comhttp://nabble.com/ . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Count line of code
You can also try the NCSS plugin at: http://mojo.codehaus.org/javancss-maven-plugin/index.html Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED] On Feb 1, 2008, at 1:30 AM, [EMAIL PROTECTED] wrote: Yes, there is. Take a look at the StatSCM Maven Plugin [1]. Hth, Nick Stolwijk [1] http://stat-scm.sourceforge.net/ -Original Message- From: Thomas Tardy [mailto:[EMAIL PROTECTED] Sent: Fri 2/1/2008 9:24 AM To: Maven Users List Subject: Count line of code Hi all, is there a convenient way to count the line of codes during the maven build? Kind Regards, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WAR confusion
Does it deploy manually by hand with the Weblogic Console? What
platform are you running on (Unix, Windows, Linux, etc)
Scott Ryan
CTO Soaring Eagle L.L.C.
Denver, Co. 80129
www.soaringeagleco.com
www.theryansplace.com
(303) 263-3044
[EMAIL PROTECTED]
On Jan 23, 2008, at 7:29 AM, [EMAIL PROTECTED] wrote:
I seem to be getting more files than I would like in my WAR. Here is
the
configuration (as generated with -X)
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-war-plugin:2.0.2:war' --
[DEBUG] (s) addMavenDescriptor = false
[DEBUG] (f) manifestEntries = {...}
[DEBUG] (f) archive =
[EMAIL PROTECTED]
[DEBUG] (f) archiveClasses = false
[DEBUG] (s) classesDirectory =
D:\framework\apps\forminstaller-ear\modules\forminstaller-war\build
\classes
[DEBUG] (f) filters = []
[DEBUG] (f) outputDirectory =
D:\framework\apps\forminstaller-ear\modules\forminstaller-war\build
[DEBUG] (f) primaryArtifact = true
[DEBUG] (s) project = [EMAIL PROTECTED]
[DEBUG] (f) warName = forminstaller
[DEBUG] (s) warSourceDirectory =
D:\framework\apps\forminstaller-ear\modules\forminstaller-war\src\web
[DEBUG] (s) directory = src/web
[DEBUG] (s) includes = [**/*.jsp, **/*.jsf, WEB-INF/]
[DEBUG] (s) excludes = [**/test/, WEB-INF/lib/]
[DEBUG] (f) webResources =
[Lorg.apache.maven.model.Resource;@1cfa60a4
[DEBUG] (s) webappDirectory =
D:\framework\apps\forminstaller-ear\modules\forminstaller-war\build
\forminstaller
[DEBUG] (f) workDirectory =
D:\framework\apps\forminstaller-ear\modules\forminstaller-war\build
\war\work
[DEBUG] -- end configuration --
The warSourceDirectory contains the following two files, which do
not seem
to match the includes filter
D:\framework\apps\forminstaller-ear\modules\forminstaller-war\src\web
\jsse.jar
D:\framework\apps\forminstaller-ear\modules\forminstaller-war\src\web
\upload.jar
but are nonetheless appearing in the generated war, as indicated
below...
[INFO] Building war:
D:\framework\apps\forminstaller-ear\modules\forminstaller-war\build
\forminstaller.war
[DEBUG] adding directory META-INF/
[DEBUG] adding entry META-INF/MANIFEST.MF
[DEBUG] adding directory WEB-INF/
[DEBUG] adding entry jsse.jar
[DEBUG] adding entry upload.jar
[DEBUG] adding entry upload.jsp
[DEBUG] adding entry WEB-INF/ibm-web-bnd.xmi
[DEBUG] adding entry WEB-INF/ibm-web-ext.xmi
[DEBUG] adding entry WEB-INF/web.xml
For additional insight, here is the relevant pom.xml section
plugin
artifactIdmaven-war-plugin/artifactId
configuration
warSourceDirectorysrc/web/warSourceDirectory
archive
addMavenDescriptorfalse/addMavenDescriptor
manifestEntries/
/archive
webResources
resource
directorysrc/web/directory
includes
include**/*.jsp/include
include**/*.jsf/include
includeWEB-INF//include
/includes
excludes
exclude**/test//exclude
excludeWEB-INF/lib//exclude
/excludes
/resource
/webResources
/configuration
/plugin
Robert Egan
This email message and any attachments may contain confidential,
proprietary or non-public information. The information is intended
solely
for the designated recipient(s). If an addressing or transmission
error
has misdirected this email, please notify the sender immediately and
destroy this email. Any review, dissemination, use or reliance upon
this
information by unintended recipients is prohibited. Any opinions
expressed in this email are those of the author personally.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: xdoclet plugin and weblogic-ejb-jar.xml descriptor
You could always try ejbgen. I was going to build that into the Weblogic plugin but most people have gone to JPA instead so there was not much demand. Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED] On Sep 4, 2007, at 9:30 AM, Brian Smith wrote: I'm using Weblogic 9.2. I think you're correct in that the weblogic plugin only works for versions 8.x and earlier. I haven't found any great solutions for this hurdle yet. On 8/31/07, Scott Ryan [EMAIL PROTECTED] wrote: What version of Weblogic are you using? You can use the weblogic tag to generate the XML files but as far as I know xdoclet can only generate xml files for 8.x and prior. 9.x and 10.x are not supported but then maybe you should be using JPA, EJB 3.0 or Hibernate by then. Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED] On Aug 31, 2007, at 9:34 AM, Brian Smith wrote: I'm working on a simple HelloWorldEJB stateless session bean that I want to run in Weblogic. I'm using the xdoclet plugin and xdoclet is able to generate the home/remote classes. Should xdoclet be able to generate the weblogic-ejb-jar.xml descriptor? If so, how do I do this? Is there a special tag in the EJB source code or is there something in the pom I need to specify? I'm guessing this a task of xdoclet instead of maven but I'm not sure. Any input would be appreciated. Thanks, Brian
Re: xdoclet plugin and weblogic-ejb-jar.xml descriptor
What version of Weblogic are you using? You can use the weblogic tag to generate the XML files but as far as I know xdoclet can only generate xml files for 8.x and prior. 9.x and 10.x are not supported but then maybe you should be using JPA, EJB 3.0 or Hibernate by then. Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED] On Aug 31, 2007, at 9:34 AM, Brian Smith wrote: I'm working on a simple HelloWorldEJB stateless session bean that I want to run in Weblogic. I'm using the xdoclet plugin and xdoclet is able to generate the home/remote classes. Should xdoclet be able to generate the weblogic-ejb-jar.xml descriptor? If so, how do I do this? Is there a special tag in the EJB source code or is there something in the pom I need to specify? I'm guessing this a task of xdoclet instead of maven but I'm not sure. Any input would be appreciated. Thanks, Brian
Re: WebLogic Deployment ok from child, fails from parent ?
You have to run the deploy command from the war directory if you
want to deploy the war. This is because the project type and object
location are dynamically determined from the pom.xml of the directory
you are running in. You cannot run the command from the parent
directory because it will then try to deploy all artifacts in all
projects which is not what you want. What is it you are trying to do
exactly? The plugin will work with the deployment information
defined anywhere in any parent pom but you must run the command from
the proper project. I suppose I could include code to ignore
deployments made from directories that are not supported but that
breaks complex projects. For example if you have a parent and a war
child and jar child and ear child. You only want the ear to deploy
but how does the plugin know not to deploy the war as well.
You will have to describe the scenario that you want to occur so that
I can understand what you are expecting to happen. Use a complex
project containing a parent pom of project type pom and 3 child
projects one jar, one ear, and one war. What would you like to
happen in this case?
Scott Ryan
On Aug 6, 2007, at 6:25 PM, [EMAIL PROTECTED] wrote:
Scott,
I have the same problem here, I have the plugin defined in parent pom
(under pluginManagement).
When I run mvn weblogic:deploy from the parent, it assumes that the
parent pom is a war project and then tries to deploy the war
artifact of
the parent at the parent level. This immediately fails because the
parent
pom is simply an aggregate of sub modules and the war artifacts of the
parent does not exists.
Is this supported? If so I'd love to get it going too.
Cheers,
rOnn c.
Scott Ryan [EMAIL PROTECTED]
Sent by: Scott Ryan [EMAIL PROTECTED]
08/03/2007 11:53 PM
Please respond to
Maven Users List users@maven.apache.org
To
Maven Users List users@maven.apache.org
cc
Subject
Re: WebLogic Deployment ok from child, fails from parent ?
Why is the plugin definition not in your parent? If you run the
command in the parent directory then the plugin definition needs to
be there as well.
Scott Ryan
On Aug 3, 2007, at 1:04 AM, Anton Schoultz wrote:
Hi,
I have an prototype setup with three modules, 2 Jars and a WEB app.
I have set up the WebLogic plugins in the web project.
When I CD to the web project and mvn weblogic:deploy the web app is
deployed as expected.
However, if I go to the root/parent dir and try mvn
weblogic:deploy I
get this error
[INFO] Reactor build order:
[INFO] Unnamed - com.mergere.mvnbook:build-all-aggregator:pom:1
[INFO] console
[INFO] helloworld
[INFO] helloWeb
[INFO] Searching repository for plugin with prefix: 'weblogic'.
[INFO]
-
-
--
[ERROR] BUILD ERROR
[INFO]
-
-
--
[INFO] The plugin 'org.apache.maven.plugins:maven-weblogic-plugin'
does
not exist or no valid version could be found
in this setup I'm ONLY looking at deployment issues.
Here's the parent pom
project
modelVersion4.0.0/modelVersion
groupIdcom.mergere.mvnbook/groupId
artifactIdbuild-all-aggregator/artifactId
version1/version
packagingpom/packaging
modules
moduleconsole/module
modulehelloworld/module
modulehelloWeb/module
/modules
/project
And here's the web-app (child) pom
project
parent
artifactIdbuild-all-aggregator/artifactId
groupIdcom.mergere.mvnbook/groupId
version1/version
/parent
modelVersion4.0.0/modelVersion
groupIdanton/groupId
artifactIdhelloWeb/artifactId
namehelloWeb/name
descriptiontestWeb/description
packagingwar/packaging
version1.0-SNAPSHOT/version
urlhttp://maven.apache.org/url
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
/dependencies
build
plugins
plugin!-- WebLogic Plugin for
deploy
== WebLogic --
groupIdorg.codehaus.mojo/groupId
artifactIdweblogic-maven-plugin/artifactId
version2.9.0-SNAPSHOT/version
configuration
adminServerHostName${weblogicServerHostName}/
adminServerHostName!--
localhost --
adminServerPort${weblogicServerPort}/adminServerPort
adminServerProtocolhttp/adminServerProtocol
userId${weblogicUserId}/userId
password${weblogicPassword}/password
uploadtrue/
upload
remotetrue/
remote
verbosetrue/
verbose
debugfalse/debug
Re: Maven-Weblogic: NoClassDefFoundError for JAR in an EAR
This is really more of a J2EE, WebLogic and Classloader issue rather than Maven. If placing the jar in the APP-INF/lib directory does not help you will have to decompose your classloader structure and fix the manifests. If the problem is in the EJB access you can just place the jar in the proper location in the EAR. If it is with the War then you will need to update the maven build command to include that jar in the classpath manifest but don't package it in the War. Typically when this happens you have loaded a class in the classloader at too high a level to reach the classes it needs. The APP-INF/iib is a hack to get around this issue for WebLogic Only so I would try to fix it the J2EE way. I would also never never put application libraries in the system classpath. Hope you get this one figured out. If I can help let me know but we should probably take this off the Maven list since it is not Maven related. You might try one of the BEA mailing lists. Scott Ryan [EMAIL PROTECTED] On Aug 6, 2007, at 1:10 PM, Vaidya, Supriya A (US - Chicago) wrote: This is strange indeed. I've been reading up, and find that a lot of people have faced this problem, but no solutions have been posted... I've even tried using the includeInApplicationXml tag for the EAR-plugin, but this is not working either (isn't this to be used for client JARs only?). My problem seems to be: dependency on a 3rd party jar that is not in the weblogic classpath. Could someone please help?! :o( -Original Message- From: Vaidya, Supriya A (US - Chicago) Sent: Monday, August 06, 2007 12:11 PM To: 'Maven Users List' Subject: RE: Maven-Weblogic: NoClassDefFoundError for JAR in an EAR Hmm. I got around THAT one by putting the jar explicitly in the classpath of weblogic (modified the startWebLogic.cmd file)... And the deployment was successful - thru the weblogic console and the weblogic:deploy command. Now.. How would I go about achieving this with the weblogic:deploy command without modifying the .cmd file? -Original Message- From: Vaidya, Supriya A (US - Chicago) Sent: Monday, August 06, 2007 11:28 AM To: 'Maven Users List' Subject: RE: Maven-Weblogic: NoClassDefFoundError for JAR in an EAR Ok... I just tried deploying the same EAR in the weblogic console - and it failed there too withteh same NoClassDefFoundError... WHY!?!??!?!? :o( The required class is packaged in a .jar. The jar is in the EAR's lib folder. The application.xml does not have mention to it tho (I don't see why it should) Where else am I missing its mention?? -Original Message- From: Vaidya, Supriya A (US - Chicago) Sent: Monday, August 06, 2007 11:00 AM To: 'Maven Users List' Subject: RE: Maven-Weblogic: NoClassDefFoundError for JAR in an EAR HI Scott - sorry I took so long to respond, got pulled into a few other things. Here is the stack trace on the maven console - below it is that on the weblogic server console: C:\CreditelseContinuance\creditelseEARmvn weblogic:deploy -X + Error stacktraces are turned on. Maven version: 2.0.7 Java version: 1.5.0_04 OS name: windows xp version: 5.1 arch: x86 [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and Settin gs\ch1svai1\.m2\plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: 'C:\Maven\maven-2.0.7\ conf\plugin-registry.xml' [INFO] Scanning for projects... [DEBUG] Searching for parent-POM: com.something.credit:creditelse::2.0 of p roject: com.something.credit.else:creditelseEAR:ear:2.0 in relative pat h: ../pom.xml [DEBUG] Using parent-POM from the project hierarchy at: '../ pom.xml' for project : com.something.credit.else:creditelseEAR:ear:2.0 [INFO] Searching repository for plugin with prefix: 'weblogic'. [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins [DEBUG] Skipping disabled repository Codehaus Snapshots [DEBUG] Skipping disabled repository Maven Snapshots [DEBUG] Loading plugin prefixes from group: org.codehaus.mojo [DEBUG] Skipping disabled repository Codehaus Snapshots [DEBUG] Skipping disabled repository Maven Snapshots [DEBUG] Skipping disabled repository Codehaus Snapshots [DEBUG] Skipping disabled repository Maven Snapshots [DEBUG] maven-compiler-plugin: resolved to version 2.0.2 from repository central [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven- plugins::8 for pro ject: null:maven-compiler-plugin:maven-plugin:2.0.2 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::5 for project: org .apache.maven.plugins:maven-plugins:pom:8 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache::3 for project: org.apache.mave n:maven-parent:pom:5 from the repository. [DEBUG] Skipping disabled repository central [DEBUG] Skipping disabled repository central [DEBUG] weblogic-maven-plugin: resolved to version 2.9.0-20070211.224419-10 from repository Maven Snapshots [DEBUG] Retrieving parent-POM
Re: WebLogic Deployment ok from child, fails from parent ?
Why is the plugin definition not in your parent? If you run the
command in the parent directory then the plugin definition needs to
be there as well.
Scott Ryan
On Aug 3, 2007, at 1:04 AM, Anton Schoultz wrote:
Hi,
I have an prototype setup with three modules, 2 Jars and a WEB app.
I have set up the WebLogic plugins in the web project.
When I CD to the web project and mvn weblogic:deploy the web app is
deployed as expected.
However, if I go to the root/parent dir and try mvn
weblogic:deploy I
get this error
[INFO] Reactor build order:
[INFO] Unnamed - com.mergere.mvnbook:build-all-aggregator:pom:1
[INFO] console
[INFO] helloworld
[INFO] helloWeb
[INFO] Searching repository for plugin with prefix: 'weblogic'.
[INFO]
--
--
[ERROR] BUILD ERROR
[INFO]
--
--
[INFO] The plugin 'org.apache.maven.plugins:maven-weblogic-plugin'
does
not exist or no valid version could be found
in this setup I'm ONLY looking at deployment issues.
Here's the parent pom
project
modelVersion4.0.0/modelVersion
groupIdcom.mergere.mvnbook/groupId
artifactIdbuild-all-aggregator/artifactId
version1/version
packagingpom/packaging
modules
moduleconsole/module
modulehelloworld/module
modulehelloWeb/module
/modules
/project
And here's the web-app (child) pom
project
parent
artifactIdbuild-all-aggregator/artifactId
groupIdcom.mergere.mvnbook/groupId
version1/version
/parent
modelVersion4.0.0/modelVersion
groupIdanton/groupId
artifactIdhelloWeb/artifactId
namehelloWeb/name
descriptiontestWeb/description
packagingwar/packaging
version1.0-SNAPSHOT/version
urlhttp://maven.apache.org/url
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
/dependencies
build
plugins
plugin!-- WebLogic Plugin for deploy
== WebLogic --
groupIdorg.codehaus.mojo/groupId
artifactIdweblogic-maven-plugin/artifactId
version2.9.0-SNAPSHOT/version
configuration
adminServerHostName${weblogicServerHostName}/
adminServerHostName!--
localhost --
adminServerPort${weblogicServerPort}/adminServerPort
adminServerProtocolhttp/adminServerProtocol
userId${weblogicUserId}/userId
password${weblogicPassword}/password
uploadtrue/upload
remotetrue/remote
verbosetrue/verbose
debugfalse/debug
targetNames${weblogicTargetNames}/targetNames
artifactPathD:\build\helloWeb\target\helloWeb-1.0-SNAPSHOT.war/
artifa
ctPath
namehelloWeb/name!-- app name on the
server --
projectPackagingwar/projectPackaging
/configuration
/plugin
/plugins
/build
/project
Any ideas? How should I be approaching this?
In our situataion we have 50 odd projects, most of which are
deployable
(ear / war),
with only a handfull being jar projects. We'd like to be able to
deploy
all of them in one cmd.
I figure each deployable project will have it's own weblogic plugin
and
config - with more
generic handling of the artifactPath obviously.
TestBox: WinXp; WebLogic:9.2x; Maven:2.0.6; Jdk:1.5.0_06
Anton Schoultz
Senior Java developer
Life Systems - Servicing
Discovery Life
Direct: +27 11 529 1636
Mobile: +27 83 651 7191
Email: [EMAIL PROTECTED]
Discovery Holdings Limited
Registration number: 1999/007789/06
This message and any attachments are confidential and intended
solely for the addressee. If you have received this message in
error, please notify Discovery immediately, telephone number +27 11
529 2888. Any unauthorised use; alteration or dissemination of the
contents of this email is strictly prohibited. In no event will
Discovery or the sender be liable in any manner whatsoever to any
person for any loss or any direct, indirect, special or
consequential damages arising from use of this email or any linked
website, including, without limitation, from any lost profits,
business interruption, loss of programmes or other data that may be
stored on any information handling system or otherwise from any
assurance that this email is virus free even if Discovery is
expressly advised of the possibility of such damages. Discovery is
an Authorised Financial Services Provider. A full list of directors
is available on our website at
https://www.discovery.co.za/index_login.jhtml?p_content=/
investor_relations/directorate.jhtml
Re: WebLogic Deployment - class not found error
I would crack open the weblogic.jar to make sure that class is in the jar that you have labeled weblogic-9.2.jar in your repository. Since the system is not complaining about not being able to find the jar it must be there but I have seen many people mislabeling the jars or sending empty jars to the repository. Scott Ryan On Aug 1, 2007, at 3:03 AM, Anton Schoultz wrote: Hi all, I am trying to get deployment to a WebLogic Server (9.2.x) working. Deployment will be to local box (win xp) or to a remote server so I am trying to do this as a remote deployment - with the local box as the target (if that makes sense?) so retargeting the deployment should be simple (just change adminServerHostName etc. (probably with profiles). I have a war file on my box at D:\build\child\target\child.war Within the child project I have the following pom (some bits omitted here) ?xml version=1.0? project dependencies ... /dependencies build plugins plugin!-- Plugin for deploy to weblogic 9.2.x -- groupIdorg.codehaus.mojo/groupId artifactIdweblogic-maven-plugin/artifactId version2.9.0-SNAPSHOT/version configuration adminServerHostNamelocalhost/adminServerHostName adminServerPort7001/adminServerPort adminServerProtocolhttp/adminServerProtocol userIduserid/userId passwordpassword/password uploadtrue/upload remotetrue/remote verbosetrue/verbose debugfalse/debug targetNamesservicingserver/targetNames artifactPathD:\build\child\target\child.war/artifactPath nameDeployName/name projectPackagingwar/projectPackaging /configuration /plugin /plugins /build /project I have the following in my repository and repository is configured ok. ...repository\org\codehaus\mojo\weblogic-maven-plugin\2.9.0-SNAPSHOT ...repository\weblogic\weblogic\9.2 ...repository\weblogic\webservices\9.2 (these folders have both the jar and the pom) Running from within the child project, I kick off with mvn weblogic:deploy I get the following trace which indicates a NoClassDefFoundError :- [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'weblogic'. Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/mojo/13/mojo-13.pom 8K downloaded [INFO] -- -- [INFO] Building child [INFO]task-segment: [weblogic:deploy] [INFO] -- -- [INFO] [weblogic:deploy] [INFO] Weblogic Deployment beginning with parameters DeployMojoBase[adminServerHostName = localhost, adminServerProtocol = http, adminServerPort = 7001, userId = userid, password = password, artifactPath = D:\build\child\target\child.war, projectPackaging = war, name = DeployName, targetNames = servicingserver, remote = true] [INFO] -- -- [ERROR] FATAL ERROR [INFO] -- -- [INFO] weblogic/Deployer [INFO] -- -- [INFO] Trace java.lang.NoClassDefFoundError: weblogic/Deployer at org.codehaus.mojo.weblogic.DeployMojo.execute(DeployMojo.java:56) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginMa nager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Default LifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneG oa l(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultL ifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHand le Failures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegment s( DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifec ycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java: 125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode
Re: Maven-Weblogic: NoClassDefFoundError for JAR in an EAR
Does the same ear deploy using the console manually? Please send me the detailed log from the mvn -X weblogic:deploy so I can debug with you. It is not clear what the error is indicating. It looks like the ear is looking for one of your classes and not finding it but help me understand. Scott On Aug 1, 2007, at 1:27 PM, Vaidya, Supriya A ((US - Chicago)) wrote: Hi: I have been able to successfully run a mvn weblogic:appc on my EAR file which contains: 1. the EJB-JAR.jar 2. the web .war file 3. and a lib/genericPOJO.jar file - that is used by boththe EJB-JAR and the Web files. However, on executing the mvn weblogic:deploy command, I immediately get a NoClassDefFoundError: com/something/credit/else/application/MyException. This class is contained in the POJO.jar, and I can clearly see the POJO being included in teh lib/ directory of the EAR, and I can see that the class file is contained in this jar. What am I doing wrong? Shoudl I be setting the path somewhere? Supriya A Vaidya Technology Integration Deloitte Consulting LLP Tel: +1 312 486 4835 Fax: +1 312 247 4835 Mobile: + 1 414 736 8157 www.deloitte.com http://www.deloitte.com/ This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1] Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED]
Re: Deploying EAR project to Weblogic
Try running the deploy mojo from the ear directory. It is reading the project type to figure out what to deploy and it is confused since your pom.xml seems to have project type of pom rather than ear. You can also set the parameters manually and it will not try to guess but it will need help in determining the project type and location of the deployable. Scott On Jul 31, 2007, at 10:21 AM, Vaidya, Supriya A ((US - Chicago)) wrote: Sorry - wrong POMs were attached previously - here are the right ones, that generate the error From: Vaidya, Supriya A (US - Chicago) Sent: Tuesday, July 31, 2007 11:11 AM To: 'Maven Users List' Subject: Deploying EAR project to Weblogic Hi: I have a project structure such that an EAR is created containing a WAR, and an EJB JAR. Thus, each module has its own directory and its own pom. THe parent directory (say projectOverAll) has a pom with packaging = pom. Now, the project packages successfully - mvn clean install works fine. I get my .ear file. I now want to deploy this to weblogic. I understand that I have to use the maven-weblogic plugin. I tried adding/installing all the dependencies into the parent POM as required for teh plugin. and then did a mvn weblogic:appc on the parent directory. However, this throws teh following error - Downloading: http://repo1.maven.org/maven2/web-maven/web-maven/1.0/ web-maven-1.0 .pom [INFO] [weblogic:appc] [INFO] -- -- [ERROR] FATAL ERROR [INFO] -- -- [INFO] Unsupported project packaging pom [INFO] -- -- [INFO] Trace java.lang.IllegalArgumentException: Unsupported project packaging pom at org.codehaus.mojo.weblogic.util.WeblogicMojoUtilities.updateArtifactN ame(WeblogicMojoUtilities.java:109) at org.codehaus.mojo.weblogic.AppcMojo.execute (AppcMojo.java:144) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPlugi nManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:493) Is the expectation different for deployment? How do I deploy this on my webogic 9.2 server? Attached for reference is the parent POM and EAR pom with all the dependencies (modified to hide some details). Thanks and regards, Supriya This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1] pom for EAR.xml pom for project.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED]
Re: Question - weblogic-maven-plugin - Urgent
Appc has been repackaged and has become very difficult to support. I am working on getting support built into the plugin however it requires a host of additional libraries that would make the other goals a real pain to use. I will probably post a set of instructions on the mojo website on how to set up the proper libraries to run appc and then it is really unpredictable. Since I get no support for this plugin from BEA it is some guesswork on my end. There are a number of posts on the mojo list that describe how to get appc working. If you want to work with me to get it working I will be more than happy to put it in the plugin. Sorry, Scott Ryan On Jul 27, 2007, at 7:57 PM, Dmitry wrote: Eric, Probably you did not set correct configuration for maven..it's one point. Actually its interesting about maven plagin for Workshop. Can you sene the link to that plugin i also try to use it. thanks, dt www.ejinz.com Search Engine News - Original Message - From: Eric YH WONG To: 'Maven Users List' Sent: Friday, July 27, 2007 8:52 PM Subject: Question - weblogic-maven-plugin - Urgent Hi All, Here is my env setting: JDK v1.4.2, WebLogic Platform v8.1.6, Windows XP SP2. I use WebLogic Workshop (accompany with the WebLogic Platform installer) v8.1.6 to create a new Application and a portal project. Attached the Directory Layout. And I want to use Maven2 to build an EAR, so I created a pom.xml and using weblogic-maven-plugin v2.8.0.. When I execute mvn weblogic:appc I got errors (see the attached files Debug.txt and Error.txt). Does anyone can help to resolve it ??? Thanks, Eric -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED]
Re: Maven-weblogic plugin: Unable to understand error
You installed the wrong groupid for the webservices jar. It should be weblogic not webservices. no poms needed if you uploaded using the instructions in the website. Scott On Jul 20, 2007, at 6:56 AM, Dennis Lundberg wrote: There doesn't seem to be be any pom for weblogic available in the central repository (or your local repository). You probably need to install that yourself, when you install the weblogic.jar. Intructions on how to do this can be found here: http://maven.apache.org/plugins/maven-install-plugin/examples/ generic-pom-generation.html Vaidya, Supriya A (US - Chicago) wrote: Hi: I am trying to use the weblogic-maven plugin to deploy my application to weblogic. Here are the steps that I followed: 1. I installed the external jars that my application uses. 2. installed the weblogic jars mvn install:install-file -Dfile=C:\bea\weblogic92\server\lib \weblogic.jar -DgroupId=weblogic -DartifactId=weblogic - Dversion=9.0 -Dpackaging=jar mvn install:install-file -Dfile=C:\bea\weblogic92\server\lib \webservices.jar -DgroupId=webservices -DartifactId=webservices - Dversion=9.0 -Dpackaging=jar 3. installed the weblogic-maven jar mvn install:install-file -Dfile=maven-weblogic-plugin-1.0.0.jar - DgroupId=web-maven -DartifactId=web-maven -Dversion=1.0 - Dpackaging=jar 4. ran the clean and compile commands: mvn clean, mvn compile - these ran without any errors 5. then ran the mvn weblogic:deploy command, but get teh following error - [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'weblogic'. [INFO] - --- [INFO] Building creditdecision [INFO]task-segment: [weblogic:deploy] [INFO] - --- Downloading: http://repository.codehaus.org/weblogic/weblogic/9.0/ weblogic-9.0.p om Downloading: http://repo1.maven.org/maven2/weblogic/weblogic/9.0/ weblogic-9.0.po m Downloading: http://repo1.maven.org/maven2/weblogic/weblogic/9.0/ weblogic-9.0.po m [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Failed to resolve artifact. No versions are present in the repository for the artifact with a range [9.0,) weblogic:webservices:jar:null from the specified remote repositories: codehaus.org (http://repository.codehaus.org http:// repository.codehaus.org/), central (http://repo1.maven.org/maven2), snapshots (http://snapshots.repository.codehaus.org http:// snapshots.repository.codehaus.org/) [INFO] - --- [INFO] For more information, run Maven with the -e switch [INFO] - --- [INFO] Total time: 1 second [INFO] Finished at: Thu Jul 19 13:59:46 CDT 2007 [INFO] Final Memory: 2M/4M [INFO] - --- I tried with 9.1, 9.2... what am I doing wrong? I even tried adding the following in my pom.xml - repositories repository idCodehaus Snapshots/id urlhttp://snapshots.repository.codehaus.org//url snapshots enabledtrue/enabled /snapshots releases enabledfalse/enabled /releases /repository /repositories pluginRepositories pluginRepository idCodehaus Snapshots/id urlhttp://snapshots.repository.codehaus.org//url snapshots enabledtrue/enabled /snapshots releases enabledfalse/enabled /releases /pluginRepository /pluginRepositories the error persists however... Attached is the POM that I am using, modified to remove certain sensitive information... could someone please help?! This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1] - --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED]
Re: Creating a Repository in weblogic server
You can create a lightweight web application with just a web.xml and weblogic.xml. In the weblogic.xml you can specify the context root your wish to use and the location on the filesystem relative to the server that you wish to store the repository files. Scott Ryan [EMAIL PROTECTED] On 5/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, I want to create my own repository in my weblogic server like http://localhost:7001/maven/repository Can some one suggest how to get this?Do I need to define a web application to get this done Regards Jaish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build error with weblogic-maven-plugin
Yes that is a bug I am working on. I have some free days over then next week or so and hope to have a solution. There are many jars that need to be included in the APPC and I am trying to find a good way to include them all without forcing you to load all the jars to your repository. I am also testing with 10 as well. I hope to have some good news later this week. Let me know if there is anything else you need. Scott On Apr 12, 2007, at 7:36 AM, Doug Tanner wrote: I am using the 2.9.0-SNAPSHOT. After building my war, I wish to precompile all my JSPs for faster response times. As I understand it, the weblogic-maven-plugin goal weblogic:appc is what I need to use to do this. However, I am getting a no class def found error. From the output of my build I get the following lines, edited to remove non-essential information: [INFO] Weblogic APPC processing beginning for artifact c:\projects\trunk\4x\webapps\broker/../../jar/broker.war [INFO] Detailed Appc settings information AppcMojo[ basicClientJar = false forceGeneration = true keepGenerated = true lineNumbers = false inputArtifactPath = c:\projects\trunk\4x\webapps\broker/../../jar/broker.war outputArtifactPath = null artifacts = [..., bf.webapps:common:jar:SNAPSHOT:compile,...] project Packaging = war verbose = true] [INFO] Using Classpath ...;\maven\localRepository\bf\webapps\common\SNAPSHOT\common- SNAPSHOT.ja r;... Created working directory: c:\DOCUME~1\dtanner\LOCALS~1\Temp\appcgen_broker.war [ERROR] Exception encountered during APPC processing weblogic.utils.compiler.ToolFailureException: com/bea/xml/XmlException This error does not show which file is causing the problem, so I ran java weblogic.appc broker.war from the command line and received this error: There are 1 nested errors: weblogic.servlet.internal.dd.compliance.ComplianceException: The class bf.web.c ommon.ApplicationContextListener referred by the descriptor element listener is not found. Please ensure that it is present in the classpath. However this class is in the common-SNAPSHOT.jar which is inside the Broker.war in WEB-INF/lib. Am I seeing 2 different errors due to the 2 different commands? How can I know from the mvn error which file is causing the problem? Thanks, Doug Tanner ** ** BENEFITFOCUS.COM CONFIDENTIALITY NOTICE: This electronic message is intended only for the individual or entity to which it is addressed and may contain information that is confidential and protected by law. Unauthorized review, use, disclosure, or dissemination of this communication or its contents in any way is prohibited and may be unlawful. If you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please notify the original sender immediately by e-mail or telephone, return the original message to the original sender or to [EMAIL PROTECTED], and destroy all copies or derivations of the original message. Thank you. (BFeComNote Rev. 08/01/2005) ** * Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED]
Re: Build error with weblogic-maven-plugin
Inside the weblogic.jar is a manifest that describes all the jars required to support the weblogic.jar. I am still going through to get the minimal combination that will work. Let me know if you have any ideas or make any progress. Scott On Apr 12, 2007, at 9:15 AM, Doug Tanner wrote: Do you have a list of these jars? I'm looking forward to a fix for this, but in the mean time I need to continue working. Thanks, Doug Tanner -Original Message- From: Scott Ryan [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ryan Sent: Thursday, April 12, 2007 10:03 AM To: Maven Users List Subject: Re: Build error with weblogic-maven-plugin Yes that is a bug I am working on. I have some free days over then next week or so and hope to have a solution. There are many jars that need to be included in the APPC and I am trying to find a good way to include them all without forcing you to load all the jars to your repository. I am also testing with 10 as well. I hope to have some good news later this week. Let me know if there is anything else you need. Scott On Apr 12, 2007, at 7:36 AM, Doug Tanner wrote: I am using the 2.9.0-SNAPSHOT. After building my war, I wish to precompile all my JSPs for faster response times. As I understand it, the weblogic-maven-plugin goal weblogic:appc is what I need to use to do this. However, I am getting a no class def found error. From the output of my build I get the following lines, edited to remove non-essential information: [INFO] Weblogic APPC processing beginning for artifact c:\projects\trunk\4x\webapps\broker/../../jar/broker.war [INFO] Detailed Appc settings information AppcMojo[ basicClientJar = false forceGeneration = true keepGenerated = true lineNumbers = false inputArtifactPath = c:\projects\trunk\4x\webapps\broker/../../jar/broker.war outputArtifactPath = null artifacts = [..., bf.webapps:common:jar:SNAPSHOT:compile,...] project Packaging = war verbose = true] [INFO] Using Classpath ...;\maven\localRepository\bf\webapps\common\SNAPSHOT\common- SNAPSHOT.ja r;... Created working directory: c:\DOCUME~1\dtanner\LOCALS~1\Temp\appcgen_broker.war [ERROR] Exception encountered during APPC processing weblogic.utils.compiler.ToolFailureException: com/bea/xml/XmlException This error does not show which file is causing the problem, so I ran java weblogic.appc broker.war from the command line and received this error: There are 1 nested errors: weblogic.servlet.internal.dd.compliance.ComplianceException: The class bf.web.c ommon.ApplicationContextListener referred by the descriptor element listener is not found. Please ensure that it is present in the classpath. However this class is in the common-SNAPSHOT.jar which is inside the Broker.war in WEB-INF/lib. Am I seeing 2 different errors due to the 2 different commands? How can I know from the mvn error which file is causing the problem? Thanks, Doug Tanner ** ** BENEFITFOCUS.COM CONFIDENTIALITY NOTICE: This electronic message is intended only for the individual or entity to which it is addressed and may contain information that is confidential and protected by law. Unauthorized review, use, disclosure, or dissemination of this communication or its contents in any way is prohibited and may be unlawful. If you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please notify the original sender immediately by e-mail or telephone, return the original message to the original sender or to [EMAIL PROTECTED], and destroy all copies or derivations of the original message. Thank you. (BFeComNote Rev. 08/01/2005) ** * Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED] ** ** BENEFITFOCUS.COM CONFIDENTIALITY NOTICE: This electronic message is intended only for the individual or entity to which it is addressed and may contain information that is confidential and protected by law. Unauthorized review, use, disclosure, or dissemination of this communication or its contents in any way is prohibited and may be unlawful. If you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please notify the original sender immediately by e-mail or telephone, return the original message to the original sender or to [EMAIL PROTECTED], and destroy all copies or derivations of the original message. Thank you. (BFeComNote Rev. 08/01/2005
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Yes I have over a hundred hard versions listed in my parent pom and it is ignoring them all during resolution except for internally refereced dependencies which is kind of what I expected. The one thing it does guarantee is that if all my users just put in the groupId and artifactId without the version then it gets the version from the parent. That allows me to control the versions we use internally of all the open source software we use. It seems to have no effect on the dependency resolution of artifacts that are brought in as a result of other dependencies. I do not use any of the ( or [ just the hard version number. Scott On Mar 2, 2007, at 8:26 AM, Jason van Zyl wrote: On 1 Mar 07, at 11:57 PM 1 Mar 07, Scott Ryan wrote: Yes I did make entries in my master parent for all the versions of software that we use but it is ignoring that as well. You have hard versions and it's ignoring them? Jason. Scott On Mar 1, 2007, at 9:36 PM, Wayne Fay wrote: Have you tried using dependencyManagement/ node in your parent pom to lock down the versions you will accept ie: dependencyManagement dependencies dependency groupIdnet.sf.saxon/groupId artifactIdsaxon/artifactId version[8.7]/version /dependency /dependencies /dependencyManagement Of course, this requires that you list all your dependencies (even the transitive ones) in this node and update versions etc here, but at least it centralizes things a bit... Wayne On 3/1/07, Scott Ryan [EMAIL PROTECTED] wrote: I am working with Maven on some fairly complex projects and I now understand that the dependency resolution is done via a nearness process rather than based on the highest compatible version. I have recently upgraded from Maven 2.04. to 2.0.5 which did not fix my issue but did change the behavior a little. Here is my problem: I have a number of framework libraries I am using including Spring, Hibernate, etc. I have an artifact that uses Hibernate at the latest version which in turn uses Commons-Collections 3.1. In that same project I use some new methods out of Commons-Collections 3.2 so I have that referenced in my pom.xml as well. The issue comes when i try to use that artifact and another artifact that uses Hibernate. Depending on the order that I include those dependencies I sometimes get 3.1 and sometimes 3.2. If I get 3.1 my code breaks at run time. Now this evening I included another artifact that is using a framework that apparently used Commons-Collections 2.1 and now my War includes Commons-Collections 2.1 and that breaks everything. I can see the resolution of the libraries in the -X output of the mvn command but no idea how to fix it or why it is happening. I know I can fix the issue by including every artifact that is used by every other artifact in my pom.xml at the version I want but that seems to defeat the whole purpose of transitive dependencies. There are also cases where a dependency may read 1.7) and 1.6 and I get null pointers during my builds even though 1.7 should be upwardly compatible with 1.6. So here are my questions: Why was the nearness process chosen and what does it buy me over using the most current compatible version out of my entire dependency list? How can I insure that I don't get my dependencies randomly downgraded so that I get runtime errors with no indication until I use the application? Is there a report or process I can use to locate these downgrades so I can deal with them during build time and not runtime? Am I missing something or doing something wrong that is causing this behavior? Thanks for all the support and a great open source offering. I hope you can educate me so I can deal with this issue and teach others. Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED]
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Ah now I get it I need to include [ ] around my dependencies. I will try that and see if it makes a difference. I thought that as a general rule that versions numbers were fairly well defined. If a project decides not to play by the generally accepted standards then it seems that would be the exception not the rule. I would assume that downgrading from 3.2 to 2.1 would not be an expected outcome. I do see that many of the apache projects use the 2nd position as a compatible version and only use 2 rather than 3 numbers. I would assume that most projects follow the rule that changes in the 2 or 3 position represent changes that are upwardly compatible for example 1.6.2 can be use in place of 1.6.1 and 1.7 can be used in place of 1.6. However even if projects are not following the standard I would expect the system to be more stable if you replace 2.1 with 3.2 and deal with those issues rather than replacing 3.2 with 2.1 and knowing it will break. Maybe a simple report we can run on the system that would indicate any downgrades that are being done by Maven with a red star so that we are aware the change is taking place and can resolve them manually. I personally would expect the system to always upgrade my dependencies and never downgrade them. Upgrading will seldom yield an issue and if it can be identified and dealt with then that is even better. Downgrading will always yield an issue and mean that you will always have issues that you must deal with. Why won't a simple version match work when resolving dependencies. 1.6 replaces 1.7 , 3.2 replaces 2.1 and then warn the user via a report or message that they need to check the dependencies and allow them to override the change. SInce most of the time we cannot control the nearness without putting all the dependencies in our local project it seems to be we are back to the Maven 1 approach of including all dependencies including transitive ones in our project otherwise we run the risk of introducing runtime errors. Any way that is my 2 cents. I still think you guys built an awesome system and I just need to work out the quirks with very large and complex projects. As I learn more about what the system does I can make changes to adapt. It is important to get the information out so that people realize what can happen and what to look for. We can develop reports to help people find and address situations like I have encountered. Thanks for the help and I will test the change to hard dependencies on Monday and see what that yields us. At least i can fix the issue in one location rather than having to include a bunch of bogus dependencies in all of our projects. Thanks again for the information and suggestions. Scott Ryan On Mar 2, 2007, at 8:26 AM, Jason van Zyl wrote: On 1 Mar 07, at 10:11 PM 1 Mar 07, Scott Ryan wrote: I am working with Maven on some fairly complex projects and I now understand that the dependency resolution is done via a nearness process rather than based on the highest compatible version. I have recently upgraded from Maven 2.04. to 2.0.5 which did not fix my issue but did change the behavior a little. Here is my problem: I have a number of framework libraries I am using including Spring, Hibernate, etc. I have an artifact that uses Hibernate at the latest version which in turn uses Commons-Collections 3.1. In that same project I use some new methods out of Commons- Collections 3.2 so I have that referenced in my pom.xml as well. The issue comes when i try to use that artifact and another artifact that uses Hibernate. Depending on the order that I include those dependencies I sometimes get 3.1 and sometimes 3.2. If I get 3.1 my code breaks at run time. Now this evening I included another artifact that is using a framework that apparently used Commons-Collections 2.1 and now my War includes Commons-Collections 2.1 and that breaks everything. I can see the resolution of the libraries in the -X output of the mvn command but no idea how to fix it or why it is happening. I know I can fix the issue by including every artifact that is used by every other artifact in my pom.xml at the version I want but that seems to defeat the whole purpose of transitive dependencies. There are also cases where a dependency may read 1.7) and 1.6 and I get null pointers during my builds even though 1.7 should be upwardly compatible with 1.6. So here are my questions: Why was the nearness process chosen and what does it buy me over using the most current compatible version out of my entire dependency list? It is impossible for us to know what the most current compatible version is. A lot of groups are careless with API changes and for a first take we decided that you know what you need to use so any specification closest to your project wins. Almost no work has been done on the artifact
Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
I actually thought that version1.0/version meant that I was getting 1.0 of the artifact but if something else needed a newer version then I would get that. The problem with nearness is that you have to understand every dependency tree for every dependency you use. It could be as in our case that 7 layers deep into the tree far far from our code there is an issue that is causing this downgrading. The issue we have is that we are using Jasper Reports as well as an open source persistence frameworks and somewhere down in the guts of those dependencies they are walking on each other. The fix is for me to go into all those projects and figure out what is going on and fix them in my pom.xml. This is ok however I don't see the problem until run time when I access those frameworks and they die. We ran for several days until someone actually produced a chart and the system died. I actually think that frameworks should not be using the [ notation cause that is what is causing the null pointer when we include Jasper and there is no way to override it without mucking in their pom. I guess bottom line is we need a best practices document for frameworks developers like apache commons and users like me so that there is a predictable system in place with no mystery as to what we are getting. Scott On Mar 3, 2007, at 8:29 AM, Wendy Smoak wrote: On 3/2/07, Jason van Zyl [EMAIL PROTECTED] wrote: Before reading that what did you think something like: version1.0/version meant? I'm actually interested in what general user opinion is here. I suppose I've never reconciled how I thought it ought to work, with the actual behavior of nearest in the directed graph (which I like) coupled with the unpredictable things that would happen with dependencyManagement + transitivity. (Fixed in 2.0.5?) But how does this change things? If I declare a dependency on 1.0 and something two levels out declares [2.0], what do I get in my webapp? Does [...] syntax allow transitive dependencies to override my choices? If everyone switches to [...] then are we back where we started with nearest ? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED]
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
When I did that I got all sorts of null pointer exceptions trying te resolve things like 1.6 to 1.7 . I will try again today with various combinations and see what I can get to work. It seems like a pain to have to double check the transitive dependencies of every artifact that I use plus every artifact that they use etc. That was one of the pains of Maven 1 we had hoped to avoid. I will try to use the [] notation and see how that works for me. Thanks for all the suggestions. Scott On Mar 1, 2007, at 10:02 PM, Wayne Fay wrote: Did you use the [...] notation in your versions? Wayne On 3/1/07, Scott Ryan [EMAIL PROTECTED] wrote: Yes I did make entries in my master parent for all the versions of software that we use but it is ignoring that as well. Scott On Mar 1, 2007, at 9:36 PM, Wayne Fay wrote: Have you tried using dependencyManagement/ node in your parent pom to lock down the versions you will accept ie: dependencyManagement dependencies dependency groupIdnet.sf.saxon/groupId artifactIdsaxon/artifactId version[8.7]/version /dependency /dependencies /dependencyManagement Of course, this requires that you list all your dependencies (even the transitive ones) in this node and update versions etc here, but at least it centralizes things a bit... Wayne On 3/1/07, Scott Ryan [EMAIL PROTECTED] wrote: I am working with Maven on some fairly complex projects and I now understand that the dependency resolution is done via a nearness process rather than based on the highest compatible version. I have recently upgraded from Maven 2.04. to 2.0.5 which did not fix my issue but did change the behavior a little. Here is my problem: I have a number of framework libraries I am using including Spring, Hibernate, etc. I have an artifact that uses Hibernate at the latest version which in turn uses Commons-Collections 3.1. In that same project I use some new methods out of Commons-Collections 3.2 so I have that referenced in my pom.xml as well. The issue comes when i try to use that artifact and another artifact that uses Hibernate. Depending on the order that I include those dependencies I sometimes get 3.1 and sometimes 3.2. If I get 3.1 my code breaks at run time. Now this evening I included another artifact that is using a framework that apparently used Commons-Collections 2.1 and now my War includes Commons-Collections 2.1 and that breaks everything. I can see the resolution of the libraries in the -X output of the mvn command but no idea how to fix it or why it is happening. I know I can fix the issue by including every artifact that is used by every other artifact in my pom.xml at the version I want but that seems to defeat the whole purpose of transitive dependencies. There are also cases where a dependency may read 1.7) and 1.6 and I get null pointers during my builds even though 1.7 should be upwardly compatible with 1.6. So here are my questions: Why was the nearness process chosen and what does it buy me over using the most current compatible version out of my entire dependency list? How can I insure that I don't get my dependencies randomly downgraded so that I get runtime errors with no indication until I use the application? Is there a report or process I can use to locate these downgrades so I can deal with them during build time and not runtime? Am I missing something or doing something wrong that is causing this behavior? Thanks for all the support and a great open source offering. I hope you can educate me so I can deal with this issue and teach others. Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED]
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Thanks for the informative reply. I thought I was missing something on the nearness thing and was hoping for a revelation that made me excited but alas not. I am glad to see there is action on resolving this as it could be a pretty major issue with adoption of Maven as dependencies come and go and randomly downgrade with out a clear indication that it has happened. We sometimes run for a day or two before hitting the run time error. I have voted and watched the two incidents that you pointed me to and in the meantime I will just have to be more diligent with my dependencies. I think it might be valuable to include it in the depedency resolution report that is generated when running reports. Maybe with a red flag that indicates that the dependency was downgraded. Today that report is pretty useless for us cause we use a lot of snapshots before our final release and the report just reports that we are using snapshots and does nothing else beyond that. Again thanks for the input and I have my finger crossed it will be addressed soon. Scott On Mar 2, 2007, at 2:56 AM, Mark Hobson wrote: Hi Scott, On 02/03/07, Scott Ryan [EMAIL PROTECTED] wrote: Why was the nearness process chosen and what does it buy me over using the most current compatible version out of my entire dependency list? Yep, nearness has never made much sense to me either. The proper fix for the more natural highest-wins strategy is covered in http://jira.codehaus.org/browse/MNG-612. I hope to allocate some time to implement this in the not-to-distant future. How can I insure that I don't get my dependencies randomly downgraded so that I get runtime errors with no indication until I use the application? Dependency management would help you here, although it's broke for transitive dependencies ;) See http://jira.codehaus.org/browse/MNG-1577. Is there a report or process I can use to locate these downgrades so I can deal with them during build time and not runtime? Unfortunately, only mvn -X compile currently shows these conflicts. I've got plans to incorporate this very useful conflict information into the help:dependencies dependency tree via an optional flag. Alternatively, a separate dependency:conflicts goal could make more sense, but nothing is implemented as yet. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED]
Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
I am working with Maven on some fairly complex projects and I now understand that the dependency resolution is done via a nearness process rather than based on the highest compatible version. I have recently upgraded from Maven 2.04. to 2.0.5 which did not fix my issue but did change the behavior a little. Here is my problem: I have a number of framework libraries I am using including Spring, Hibernate, etc. I have an artifact that uses Hibernate at the latest version which in turn uses Commons-Collections 3.1. In that same project I use some new methods out of Commons-Collections 3.2 so I have that referenced in my pom.xml as well. The issue comes when i try to use that artifact and another artifact that uses Hibernate. Depending on the order that I include those dependencies I sometimes get 3.1 and sometimes 3.2. If I get 3.1 my code breaks at run time. Now this evening I included another artifact that is using a framework that apparently used Commons-Collections 2.1 and now my War includes Commons-Collections 2.1 and that breaks everything. I can see the resolution of the libraries in the -X output of the mvn command but no idea how to fix it or why it is happening. I know I can fix the issue by including every artifact that is used by every other artifact in my pom.xml at the version I want but that seems to defeat the whole purpose of transitive dependencies. There are also cases where a dependency may read 1.7) and 1.6 and I get null pointers during my builds even though 1.7 should be upwardly compatible with 1.6. So here are my questions: Why was the nearness process chosen and what does it buy me over using the most current compatible version out of my entire dependency list? How can I insure that I don't get my dependencies randomly downgraded so that I get runtime errors with no indication until I use the application? Is there a report or process I can use to locate these downgrades so I can deal with them during build time and not runtime? Am I missing something or doing something wrong that is causing this behavior? Thanks for all the support and a great open source offering. I hope you can educate me so I can deal with this issue and teach others. Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED]
Re: Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)
Yes I did make entries in my master parent for all the versions of software that we use but it is ignoring that as well. Scott On Mar 1, 2007, at 9:36 PM, Wayne Fay wrote: Have you tried using dependencyManagement/ node in your parent pom to lock down the versions you will accept ie: dependencyManagement dependencies dependency groupIdnet.sf.saxon/groupId artifactIdsaxon/artifactId version[8.7]/version /dependency /dependencies /dependencyManagement Of course, this requires that you list all your dependencies (even the transitive ones) in this node and update versions etc here, but at least it centralizes things a bit... Wayne On 3/1/07, Scott Ryan [EMAIL PROTECTED] wrote: I am working with Maven on some fairly complex projects and I now understand that the dependency resolution is done via a nearness process rather than based on the highest compatible version. I have recently upgraded from Maven 2.04. to 2.0.5 which did not fix my issue but did change the behavior a little. Here is my problem: I have a number of framework libraries I am using including Spring, Hibernate, etc. I have an artifact that uses Hibernate at the latest version which in turn uses Commons-Collections 3.1. In that same project I use some new methods out of Commons-Collections 3.2 so I have that referenced in my pom.xml as well. The issue comes when i try to use that artifact and another artifact that uses Hibernate. Depending on the order that I include those dependencies I sometimes get 3.1 and sometimes 3.2. If I get 3.1 my code breaks at run time. Now this evening I included another artifact that is using a framework that apparently used Commons-Collections 2.1 and now my War includes Commons-Collections 2.1 and that breaks everything. I can see the resolution of the libraries in the -X output of the mvn command but no idea how to fix it or why it is happening. I know I can fix the issue by including every artifact that is used by every other artifact in my pom.xml at the version I want but that seems to defeat the whole purpose of transitive dependencies. There are also cases where a dependency may read 1.7) and 1.6 and I get null pointers during my builds even though 1.7 should be upwardly compatible with 1.6. So here are my questions: Why was the nearness process chosen and what does it buy me over using the most current compatible version out of my entire dependency list? How can I insure that I don't get my dependencies randomly downgraded so that I get runtime errors with no indication until I use the application? Is there a report or process I can use to locate these downgrades so I can deal with them during build time and not runtime? Am I missing something or doing something wrong that is causing this behavior? Thanks for all the support and a great open source offering. I hope you can educate me so I can deal with this issue and teach others. Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Scott Ryan CTO Soaring Eagle L.L.C. Denver, Co. 80129 www.soaringeagleco.com www.theryansplace.com (303) 263-3044 [EMAIL PROTECTED]
Re: must enter 20 times same password during deploy
If you add a servers section with userid and password to your settings.xml it will not prompt any longer. On Feb 19, 2007, at 7:00 AM, eckobar wrote: hi everybody! i am new to maven and have a little problem i have a distribution repository which uses scp, server infos username + password is set in settings.xml, but when i make mvn deploy i must enter password for each aktion, but at the end everything is OK. problem is that for a simple deploy i must enter 20 times the same password ... whats wrong? -- View this message in context: http://www.nabble.com/must-enter-20- times-same-password-during-deploy-tf3252968s177.html#a9042647 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Terracotta Maven plugin(s), anyone?
I would love to work with you on developing the plugin. I heard about their presentation at the Denver Java User's Group and would love to look at their technology deeper. I have developed some plugins already for weblogic and appfuse. Scott Ryan [EMAIL PROTECTED] On Feb 18, 2007, at 1:08 PM, Jim Bethancourt wrote: Hi all, I was wondering if anyone would be interested in developing a Maven 2 plugin / plugins that would allow for developers to apply Terracotta bytecode enhancement to their Java code through Maven. I've only worked through the Terracotta DSO tutorial, but it seems like a Maven plugin would make a lot of sense to automate the bytecode enhancement through the Maven build life cycle. I can email the Terracotta folks and ask them if they would be able to post the Terracotta files on Ibiblio since Maven 2.0.5 now supports different licenses. I've dabbled in plugin authoring before as well, but I don't know exactly what all it would entail in this case. Please write back and let me know 1) If you would find the plugin useful and/or 2) If you would be interested in helping develop such a plugin Thanks, Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Accessing the POM classpath from within an Ant based mojo
I am trying to write a very simple Ant based script mojo. I need to define some taskdefs from within the build.xml based on the current classpath defined in the plugin pom. I have seen reference to using the maven.plugin.classpath but when I reference that I get an error that it is not present. I also tried passing the path in as a parameter to the mojo but that did not work either. The basic idea is that I have an Ant based mojo and I want to define a taskdef in my build.xml based on the classpath defined in the pom.xml of the plugin. Any ideas or suggestions would be appreciated. Scott Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing the POM classpath from within an Ant based mojo
Thanks for the quick answer. I am not not 2.0.5 yet but I assume you mean any version of 2.0.x will not work. So that means there is no way to do a taskdef in an ant based mojo? I could have sworn I had it working a few months ago. Seems that an ant mojo is pretty hampered if I cannot define any taskdefs. I guess I will have to see about using a Java mojo to front end the ant tasks and then use the java mojo facilities to create the task def. I was hoping someone had come up with a cute trick to allow tasks defs in ant based mojos. Too bad as it would have made it an easy task to implement the ant tasks I need and to front them with mojos for ease of configuration. I will keep my fingers crossed for a solution soon but in the mean time I guess it is slog in the code again time. Scott Ryan On Feb 17, 2007, at 7:42 PM, Jason van Zyl wrote: On 17 Feb 07, at 4:54 PM 17 Feb 07, Scott Ryan wrote: I am trying to write a very simple Ant based script mojo. I need to define some taskdefs from within the build.xml based on the current classpath defined in the plugin pom. I have seen reference to using the maven.plugin.classpath but when I reference that I get an error that it is not present. I also tried passing the path in as a parameter to the mojo but that did not work either. The basic idea is that I have an Ant based mojo and I want to define a taskdef in my build.xml based on the classpath defined in the pom.xml of the plugin. Any ideas or suggestions would be appreciated. This will not work with 2.0.5. I have made changes to 2.1.x that allow using file references and the classpath information (just like the ant-run-plugin) but I currently have not merged it back to 2.0.x. Jason. Scott Ryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Q: Weblogic Plugin
Did you try the plugin and point the artifactPath parameter at the proper location. It works for us but if you are having problems let me know and I can debug with you and fix it in the plugin. Scott Ryan On Feb 1, 2007, at 3:26 PM, lemon dumpling wrote: Hi Everyone, Is there a way to deploy and redeploy exploded war file into weblogic 9.2using maven2? Thanks. Cheers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Execute phase in weblogic:appc
Another fix might be to use weblogic:appc rather than ear:ear and that would trigger the ear build automatically. Are you using the one of the default commands like mvn install or mvn package rather than directly the ear:ear command. Id you rn ear:ear it will run twice but if you use something like package or another lifecycle command it should work fine. There may be something I missed in understanding how the lifecycle works so if I did I hope someone on this list can clarify my understanding and set me straight. Like you I am still learning the nuances of Maven 2.0 Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Dmystery [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 11:47 PM To: users@maven.apache.org Subject: RE: Execute phase in weblogic:appc That was my belief too that appc should add on the additional goals. But it is certainly the goals in packaging twice. As i said, i'm using appc in a pom with 'ear' packaging which runs ear:ear in the package phase. When the packaging is over appc prepares itself and run ear:ear again. See http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.ht ml 'Forking a parallel life cycle' May be if you can try using appc in a ear pom and do a 'mvn install' Scott Ryan-2 wrote: It certainly should not run twice. It should run all the goals in the packaging mojo and then add on the additional goals after packaging but not run them again. I am not seeing that behavour so i will have to investigate the scenario you are describing. I have a number of mojos that run during the packaging phase and i am not seeing it run multple times. I will try to look into it but if you have suggestions i am more than happy to make changes to the mojo. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Dmystery [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 4:13 AM To: users@maven.apache.org Subject: Execute phase in weblogic:appc I've doubts in weblogic-maven-plugin's appc mojo. The executePhase in the plugin.xml is 'package' which means that it will bounded to the pom along with other goals with 'package' phase. According to the write up at http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.ht ml, when the appc mojo will execute the tasks already executed in the package phase and the preceding phases will rerun. I've appc in an pom with 'ear' packaging. The ear plugin has the following life-cycle, http://cvs.peopleware.be/training/maven/maven2/buildLifecyclePhases.html#ear So when appc is executed it will again generate the application.xml and the ear . Also i've a antrun plugin defined to in the 'package' phase that generates webservices using the generated ear. The whole life cycle executing twice is adding a considerable amount of time to the build process. Is there a way to avoid this? Moving the appc to install phase will install the ear to the repository first and run appc on the ear in the build directory. Which is not desirable. Any thoughts??? -- View this message in context: http://www.nabble.com/Execute-phase-in-weblogic%3Aappc-tf2642288s177.html#a7 375755 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Execute-phase-in-weblogic%3Aappc-tf2642288s177.html#a7 394684 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Execute phase in weblogic:appc
It certainly should not run twice. It should run all the goals in the packaging mojo and then add on the additional goals after packaging but not run them again. I am not seeing that behavour so i will have to investigate the scenario you are describing. I have a number of mojos that run during the packaging phase and i am not seeing it run multple times. I will try to look into it but if you have suggestions i am more than happy to make changes to the mojo. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Dmystery [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 4:13 AM To: users@maven.apache.org Subject: Execute phase in weblogic:appc I've doubts in weblogic-maven-plugin's appc mojo. The executePhase in the plugin.xml is 'package' which means that it will bounded to the pom along with other goals with 'package' phase. According to the write up at http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.ht ml, when the appc mojo will execute the tasks already executed in the package phase and the preceding phases will rerun. I've appc in an pom with 'ear' packaging. The ear plugin has the following life-cycle, http://cvs.peopleware.be/training/maven/maven2/buildLifecyclePhases.html#ear So when appc is executed it will again generate the application.xml and the ear . Also i've a antrun plugin defined to in the 'package' phase that generates webservices using the generated ear. The whole life cycle executing twice is adding a considerable amount of time to the build process. Is there a way to avoid this? Moving the appc to install phase will install the ear to the repository first and run appc on the ear in the build directory. Which is not desirable. Any thoughts??? -- View this message in context: http://www.nabble.com/Execute-phase-in-weblogic%3Aappc-tf2642288s177.html#a7 375755 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Example POM for Weblogic servicegen needed
Thanks for pointing out the issue with the basicClientJar. I fixed the code this morning along with the forceGeneration and lineNumbers flags. I pushed a new snapshot up to the codehaus repository as well. Let me know if you have any other issues. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Jeff Bailey [mailto:[EMAIL PROTECTED] Sent: Saturday, November 11, 2006 5:08 PM To: users@maven.apache.org Subject: RE: Example POM for WebLogic servicegen needed That would be great to have servicegen available in the plugin! BTW, I'm using the 2.8 version since I'm stuck on WebLogic 8.1.4. I noticed that version currently accepts the -basicClientJar flag to appc but doesn't actually pass it into the appc command. Thanks! Jeff Scott Ryan-2 wrote: That is actually the way we build all of our projects and it makes it easier for development, unit testing and our SCM processes. We really don't need the ear for dev and unit testing but it is our required packaging to get through audit and SCM process. WE actually check them into our source code control in a consolidated project and use the master pom of the project to control the versions so that all the artifacts within that group use the same versions of related artifacts and the resolution within the project is consistent. I hope to have the servicegen mojo done this weekend and will push up the snapshot of both plugins once it is ready providing the snow does not call me out skiing. The servicegen mojo will construct the classpath from the depenency path of the pom.xml so you will only have to include the ejb artifact in order for servicegen to find it. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Jeff Bailey [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 6:43 PM To: users@maven.apache.org Subject: Re: Example POM for WebLogic servicegen needed Thanks for the example. That saved me a lot of time! Re: phase for appc, I'm trying to take the approach having one project create the ejb-jar and a separate project create the web services using servicegen. Currently I run appc in the package phase. I thought it might be better to decompose things that way instead of trying to do to much in one project. In fact, I'm starting look into actually having a another project to create the ear. In a nutshell I'd have the following projects: EJB Project - contains my session beans. WebService Project - uses servicegen to create webservices for my sessions beans Web Project - contains my web app EAR Project - Packages the artifacts of the other three packages into the ear for my application. My goal is to separate out the assembly of the EAR and to keep each project relatively simple. I have a few challenges that I need to overcome: 1) servicegen needs to reference the ejb jar as a parameter. I currently have a relative path hardcoded to my ejb project, but what I'd really like to do is reference the ejb artifact. I'm sure this can be done but I need to dig into how to refernce it. Maybe declare the ejb jar as a dependency and somehow reference that in the servicegen call? 2) The WebService project uses servicegen to generate an EAR. I'm really only interested in the war file that's generated by servicegen so it can be packaged into the EAR by my EAR project. I have servicegen configured to generate an exploded ear, but I need to figure out how to make the war that servicegen generates the artifact of my WebService project so that it will be installed in the repository and can be picked up by my EAR project. Hopefully this makes sense. I'd be curious to know if others think by breakdown of maven projects is good pattern or an anti-pattern and if you have any suggestions on how to solve the remaining issues. Thanks, Jeff Dmystery wrote: On a different note, what execution phase are you executing the weblogic:appc? I'm doing it in a pom which first generate sources using XMLbeans, compiles some aspects, create ejb-jar, ejb-client-jar and then run weblogic:appc which is in the package phase. The problem is, when appc is started, it does the whole thing again, XMLBeans to ejb-client-jar. Just wanna know what phase you have weblogic:appc? Thanks. -- View this message in context: http://www.nabble.com/Example-POM-for-WebLogic-servicegen-needed-tf2604105s1 77.html#a7288485 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
RE: Example POM for WebLogic servicegen needed
That is actually the way we build all of our projects and it makes it easier for development, unit testing and our SCM processes. We really don't need the ear for dev and unit testing but it is our required packaging to get through audit and SCM process. WE actually check them into our source code control in a consolidated project and use the master pom of the project to control the versions so that all the artifacts within that group use the same versions of related artifacts and the resolution within the project is consistent. I hope to have the servicegen mojo done this weekend and will push up the snapshot of both plugins once it is ready providing the snow does not call me out skiing. The servicegen mojo will construct the classpath from the depenency path of the pom.xml so you will only have to include the ejb artifact in order for servicegen to find it. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Jeff Bailey [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 6:43 PM To: users@maven.apache.org Subject: Re: Example POM for WebLogic servicegen needed Thanks for the example. That saved me a lot of time! Re: phase for appc, I'm trying to take the approach having one project create the ejb-jar and a separate project create the web services using servicegen. Currently I run appc in the package phase. I thought it might be better to decompose things that way instead of trying to do to much in one project. In fact, I'm starting look into actually having a another project to create the ear. In a nutshell I'd have the following projects: EJB Project - contains my session beans. WebService Project - uses servicegen to create webservices for my sessions beans Web Project - contains my web app EAR Project - Packages the artifacts of the other three packages into the ear for my application. My goal is to separate out the assembly of the EAR and to keep each project relatively simple. I have a few challenges that I need to overcome: 1) servicegen needs to reference the ejb jar as a parameter. I currently have a relative path hardcoded to my ejb project, but what I'd really like to do is reference the ejb artifact. I'm sure this can be done but I need to dig into how to refernce it. Maybe declare the ejb jar as a dependency and somehow reference that in the servicegen call? 2) The WebService project uses servicegen to generate an EAR. I'm really only interested in the war file that's generated by servicegen so it can be packaged into the EAR by my EAR project. I have servicegen configured to generate an exploded ear, but I need to figure out how to make the war that servicegen generates the artifact of my WebService project so that it will be installed in the repository and can be picked up by my EAR project. Hopefully this makes sense. I'd be curious to know if others think by breakdown of maven projects is good pattern or an anti-pattern and if you have any suggestions on how to solve the remaining issues. Thanks, Jeff Dmystery wrote: On a different note, what execution phase are you executing the weblogic:appc? I'm doing it in a pom which first generate sources using XMLbeans, compiles some aspects, create ejb-jar, ejb-client-jar and then run weblogic:appc which is in the package phase. The problem is, when appc is started, it does the whole thing again, XMLBeans to ejb-client-jar. Just wanna know what phase you have weblogic:appc? Thanks. -- View this message in context: http://www.nabble.com/Example-POM-for-WebLogic-servicegen-needed-tf2604105s1 77.html#a7288485 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Example POM for WebLogic servicegen needed
You can view the source here
https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/weblogic-maven-plugin/
but it is defined to run during the package phase. Do you have it defined
in an execution? How are you executing the command to run the entire
process?
Scott Ryan
Chief Technology Officer
Soaring Eagle L.L.C.
[EMAIL PROTECTED]
www.soaringeagleco.com
(303) 263-3044
-Original Message-
From: Dmystery [mailto:[EMAIL PROTECTED]
Sent: Friday, November 10, 2006 3:21 AM
To: users@maven.apache.org
Subject: Re: Example POM for WebLogic servicegen needed
On a different note, what execution phase are you executing the
weblogic:appc? I'm doing it in a pom which first generate sources using
XMLbeans, compiles some aspects, create ejb-jar, ejb-client-jar and then run
weblogic:appc which is in the package phase. The problem is, when appc is
started, it does the whole thing again, XMLBeans to ejb-client-jar. Just
wanna know what phase you have weblogic:appc?
Thanks.
Dmystery wrote:
Hope this helps,
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.0/version
executions
execution
phasepackage/phase
configuration
tasks
taskdef name=servicegen
classname=weblogic.ant.taskdefs.webservices.servicegen.ServiceGenTask
classpath refid=maven.dependency.classpath /
/taskdef
servicegen
destEar=${project.build.directory}/${project.artifactId}-${project.version}
.ear
warName=castle-server-web-${project.parent.version}.war
contextURI=castle
mergeWithExistingWS=True
classpath refid=maven.dependency.classpath /
service targetNamespace=http://my.company.com;
ejbJar=${basedir}/path-to-ejb-jar/your-ejb.jar
includeEJBs=service name serviceName=service name
serviceURI=/jndi/name generateTypes=True
style=documentwrapped expandMethods=True
typeMappingFile=auto-types mapping file
/service
/servicegen
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdsun.jdk/groupId
artifactIdtools/artifactId
version1.5.1/version
scopesystem/scope
systemPath${java.home}/../lib/tools.jar/systemPath
/dependency
/dependencies
/plugin
Jeff Bailey wrote:
I need to create a WebService from a session bean using the WebLogic
8.1.4 servicegen ant task. Can anyone provide me a good example of a
clean way to accomplish this in the POM?
I'm successfully using the weblogic-maven-plugin to run appc, but the
plugin does not yet support servicegen.
Thanks,
Jeff
--
View this message in context:
http://www.nabble.com/Example-POM-for-WebLogic-servicegen-needed-tf2604105s1
77.html#a7274411
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: weblogic-maven-plugin:using properties file
You just need to configure the plugin in your different profiles. You can have a different set of configurations in each profile definition. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Dmystery [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 4:35 AM To: users@maven.apache.org Subject: weblogic-maven-plugin:using properties file How can i use a properties file in weblogic-maven-plugin. I've to deploy an ear on different enviroments and the adminServerHostName,adminServerPort etc will hold values based on the environment. At the pom level i can access the appropriate properties file using profiles, but the same properties are not available in the plugin. Any solution??? -- View this message in context: http://www.nabble.com/weblogic-maven-plugin%3Ausing-properties-file-tf259470 5s177.html#a7236919 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [M2]weblogic:appc classpath issue
I am glad that it is working now. I am anxious to push it up onto the snapshot server. Feel free to let me know what else I can add to help you out. You can enter JIRA tickets in the mojo section so I can track what you need. If you can clarify what you mean by autotypes I will look into that. I hope this weekend to add service gen and jwsc support. Also specify which version of Weblogic you are running. The code it different for 9.0 and 8.1 so that helps me know where to start. Keep the bug reports and feature requests coming and I will work on them as I have time. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Dmystery [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 8:55 PM To: users@maven.apache.org Subject: RE: [M2]weblogic:appc classpath issue I downloaded the code from codehaus SNV and it working fine now. Thanks again! Any plans to include autotypes and servicegen goals in the plugin? :) Currently i'm using maven-antrun-plugin to use weblogic servicegen task. Scott Ryan-2 wrote: I would love to push it but I only have access to SVN at codehaus. I do not have the authority to push up a snapshot any longer and the people who can don't seem to have access to the Weblogic jars required to build the code. I hope I can get this worked out this week. Until then you can just download the code from SVN and run mvn install to place it in your local repository to test. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Dmystery [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 9:06 PM To: users@maven.apache.org Subject: RE: [M2]weblogic:appc classpath issue Thanks Scott. It would be great if you can push the latest snapshot to the repository now. Scott Ryan-2 wrote: I have refactored the 2.8.0 plugin to fix that problem. I have changed some of the parameters and since the website can only support one version of the plugin I need to add a page to describe the new settings for the 2.8.0 plugin. I will be pushing the latest snapshot up to the repository once I have completed that documentation. This fixes the classpath issue both in appc and the client gen mojos. I have not updated the 2.9.0 version as the 9.2 release broke all the apis I was using so i need to refactor to use the new API's. Let me know if you would prefer I push up the 2.8.0 version now and just post the changes on a note to the user list. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Manu [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 12:07 PM To: Maven Users List Subject: Re: [M2]weblogic:appc classpath issue Hi, I have the same problem. I need to explicitly set the entire classpath by hand to have it worked. In other words, I'm defining another time all the dependencies that already are in the pom. The plugin does not seem to take into account the dependencies. By the way, i'm using version 2.8.0-SNAPSHOT Thxs Manu 2006/10/31, Dmystery [EMAIL PROTECTED]: Alos, looking at AppcMojo.class file, i dont see any default classpath being set. Here is the stack trace when i try to run the plugin. [INFO] Detailed Appc settings information AppcMojo[basicClientJar = false classpath = null compiler = null debugging = true deprecation = false forceGeneration = false idl = false idlDirectory = null idlFactrories = false idlMethodSignatures = null idlNoAbstractInterfaces = true idlNoValueTypes = true idlOrbix = false idlOverwrite = false idlVerbose = false idlVisiBroker = false iiop = false iiopDirectory = null javaOptions = null keepGenerated = true lineNumbers = true nowarnings = false objectPath = D:\Castle-maven\castle\server\server-ejb\target/castle-server-ejb- 1.0.jar optimization = false outputFile = null verbose = true version = false] [INFO] Argument List for Appc settings [-lineNumbers, -keepgenerated, -g, -verb ose, D:\Castle-maven\castle\server\server-ejb\target/castle-server-ejb-1.0.jar] [appc] Created working directory: C:\DOCUME~1\DEEP_M~1.INF\LOCALS~1\Temp\appcgen [J2EE:160119]Appc is unable to process the file 'D:\Castle-maven\castle\server\s erver-ejb\target\castle-server-ejb-1.0.jar'. The following error occurred: java.lang.NoClassDefFoundError: cadvf2/server/AbstractEJB This is a compile dependency in the POM at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:502) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(Generic ClassLoader.java:480
RE: [M2]weblogic:appc classpath issue
I would love to push it but I only have access to SVN at codehaus. I do not have the authority to push up a snapshot any longer and the people who can don't seem to have access to the Weblogic jars required to build the code. I hope I can get this worked out this week. Until then you can just download the code from SVN and run mvn install to place it in your local repository to test. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Dmystery [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 9:06 PM To: users@maven.apache.org Subject: RE: [M2]weblogic:appc classpath issue Thanks Scott. It would be great if you can push the latest snapshot to the repository now. Scott Ryan-2 wrote: I have refactored the 2.8.0 plugin to fix that problem. I have changed some of the parameters and since the website can only support one version of the plugin I need to add a page to describe the new settings for the 2.8.0 plugin. I will be pushing the latest snapshot up to the repository once I have completed that documentation. This fixes the classpath issue both in appc and the client gen mojos. I have not updated the 2.9.0 version as the 9.2 release broke all the apis I was using so i need to refactor to use the new API's. Let me know if you would prefer I push up the 2.8.0 version now and just post the changes on a note to the user list. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Manu [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 12:07 PM To: Maven Users List Subject: Re: [M2]weblogic:appc classpath issue Hi, I have the same problem. I need to explicitly set the entire classpath by hand to have it worked. In other words, I'm defining another time all the dependencies that already are in the pom. The plugin does not seem to take into account the dependencies. By the way, i'm using version 2.8.0-SNAPSHOT Thxs Manu 2006/10/31, Dmystery [EMAIL PROTECTED]: Alos, looking at AppcMojo.class file, i dont see any default classpath being set. Here is the stack trace when i try to run the plugin. [INFO] Detailed Appc settings information AppcMojo[basicClientJar = false classpath = null compiler = null debugging = true deprecation = false forceGeneration = false idl = false idlDirectory = null idlFactrories = false idlMethodSignatures = null idlNoAbstractInterfaces = true idlNoValueTypes = true idlOrbix = false idlOverwrite = false idlVerbose = false idlVisiBroker = false iiop = false iiopDirectory = null javaOptions = null keepGenerated = true lineNumbers = true nowarnings = false objectPath = D:\Castle-maven\castle\server\server-ejb\target/castle-server-ejb- 1.0.jar optimization = false outputFile = null verbose = true version = false] [INFO] Argument List for Appc settings [-lineNumbers, -keepgenerated, -g, -verb ose, D:\Castle-maven\castle\server\server-ejb\target/castle-server-ejb-1.0.jar] [appc] Created working directory: C:\DOCUME~1\DEEP_M~1.INF\LOCALS~1\Temp\appcgen [J2EE:160119]Appc is unable to process the file 'D:\Castle-maven\castle\server\s erver-ejb\target\castle-server-ejb-1.0.jar'. The following error occurred: java.lang.NoClassDefFoundError: cadvf2/server/AbstractEJB This is a compile dependency in the POM at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:502) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(Generic ClassLoader.java:480) at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClass Loader.java:182) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:292) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClass Loader.java:224) at weblogic.ejb20.deployer.BeanInfoImpl.loadClass(BeanInfoImpl.java:343) at weblogic.ejb20.deployer.BeanInfoImpl.init(BeanInfoImpl.java:192) at weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.init(ClientDrivenB eanInfoImpl.java:179) at weblogic.ejb20.deployer.SessionBeanInfoImpl.init(SessionBeanInfoImp l.java:74) at weblogic.ejb20.deployer.BeanInfoImpl.createBeanInfoImpl(BeanInfoImpl. java:367) at weblogic.ejb20.deployer.MBeanDeploymentInfoImpl.initializeBeanInfos(M BeanDeploymentInfoImpl.java:548) at weblogic.ejb20.deployer.MBeanDeploymentInfoImpl.init(MBeanDeploymen tInfoImpl.java:232) at weblogic.ejb20.ejbc.EJBCompiler.setupEJB(EJBCompiler.java:155) at weblogic.ejb20
RE: [M2]weblogic:appc classpath issue
The 2.8.0 version of the plugin is for 8.1.4 and above. It will work for 8.1.3 and below for all but remote deployments. If you need it I can retro fit the remote deployment back to 8.1.3 2.8.0-SNAPSHOT supports the 8.1 version of Weblogic for all versions except remote deployment which requires sp4 and above 2.9.0-SNAPSHOT supports 9.0 with all patch levels The 2.9.0 code is on the trunk and the 2.8.0 code is on the branch. Let me know if you need more information. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Jonas Olsson [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 2:41 AM To: Maven Users List Subject: SV: [M2]weblogic:appc classpath issue Also, you mention the 9.2 release. As we're using WLS 8.1.3 will we miss out on this fix? /jonas -Ursprungligt meddelande- Från: Manu [mailto:[EMAIL PROTECTED] Skickat: den 2 november 2006 10:27 Till: Maven Users List Ämne: Re: [M2]weblogic:appc classpath issue Can you also tell to WHICH maven repository you will publish it ? Thank you very much for your efforts. 2006/11/2, Dmystery [EMAIL PROTECTED]: Thanks Scott. It would be great if you can push the latest snapshot to the repository now. Scott Ryan-2 wrote: I have refactored the 2.8.0 plugin to fix that problem. I have changed some of the parameters and since the website can only support one version of the plugin I need to add a page to describe the new settings for the 2.8.0 plugin. I will be pushing the latest snapshot up to the repository once I have completed that documentation. This fixes the classpath issue both in appc and the client gen mojos. I have not updated the 2.9.0 version as the 9.2 release broke all the apis I was using so i need to refactor to use the new API's. Let me know if you would prefer I push up the 2.8.0 version now and just post the changes on a note to the user list. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Manu [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 12:07 PM To: Maven Users List Subject: Re: [M2]weblogic:appc classpath issue Hi, I have the same problem. I need to explicitly set the entire classpath by hand to have it worked. In other words, I'm defining another time all the dependencies that already are in the pom. The plugin does not seem to take into account the dependencies. By the way, i'm using version 2.8.0-SNAPSHOT Thxs Manu 2006/10/31, Dmystery [EMAIL PROTECTED]: Alos, looking at AppcMojo.class file, i dont see any default classpath being set. Here is the stack trace when i try to run the plugin. [INFO] Detailed Appc settings information AppcMojo[basicClientJar = false classpath = null compiler = null debugging = true deprecation = false forceGeneration = false idl = false idlDirectory = null idlFactrories = false idlMethodSignatures = null idlNoAbstractInterfaces = true idlNoValueTypes = true idlOrbix = false idlOverwrite = false idlVerbose = false idlVisiBroker = false iiop = false iiopDirectory = null javaOptions = null keepGenerated = true lineNumbers = true nowarnings = false objectPath = D:\Castle-maven\castle\server\server-ejb\target/castle-server-ejb- 1.0.jar optimization = false outputFile = null verbose = true version = false] [INFO] Argument List for Appc settings [-lineNumbers, -keepgenerated, -g, -verb ose, D:\Castle-maven\castle\server\server-ejb\target/castle- server-ejb-1.0.jar] [appc] Created working directory: C:\DOCUME~1\DEEP_M~1.INF\LOCALS~1\Temp\appcgen [J2EE:160119]Appc is unable to process the file 'D:\Castle-maven\castle\server\s erver-ejb\target\castle-server-ejb-1.0.jar'. The following error occurred: java.lang.NoClassDefFoundError: cadvf2/server/AbstractEJB This is a compile dependency in the POM at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:502) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(Generic ClassLoader.java:480) at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClass Loader.java:182) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:292) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClass Loader.java:224) at weblogic.ejb20.deployer.BeanInfoImpl.loadClass(BeanInfoImpl.java:343) at weblogic.ejb20.deployer.BeanInfoImpl.init(BeanInfoImpl.java:192
RE: [M2]weblogic:appc classpath issue
I have refactored the 2.8.0 plugin to fix that problem. I have changed some of the parameters and since the website can only support one version of the plugin I need to add a page to describe the new settings for the 2.8.0 plugin. I will be pushing the latest snapshot up to the repository once I have completed that documentation. This fixes the classpath issue both in appc and the client gen mojos. I have not updated the 2.9.0 version as the 9.2 release broke all the apis I was using so i need to refactor to use the new API's. Let me know if you would prefer I push up the 2.8.0 version now and just post the changes on a note to the user list. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Manu [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 12:07 PM To: Maven Users List Subject: Re: [M2]weblogic:appc classpath issue Hi, I have the same problem. I need to explicitly set the entire classpath by hand to have it worked. In other words, I'm defining another time all the dependencies that already are in the pom. The plugin does not seem to take into account the dependencies. By the way, i'm using version 2.8.0-SNAPSHOT Thxs Manu 2006/10/31, Dmystery [EMAIL PROTECTED]: Alos, looking at AppcMojo.class file, i dont see any default classpath being set. Here is the stack trace when i try to run the plugin. [INFO] Detailed Appc settings information AppcMojo[basicClientJar = false classpath = null compiler = null debugging = true deprecation = false forceGeneration = false idl = false idlDirectory = null idlFactrories = false idlMethodSignatures = null idlNoAbstractInterfaces = true idlNoValueTypes = true idlOrbix = false idlOverwrite = false idlVerbose = false idlVisiBroker = false iiop = false iiopDirectory = null javaOptions = null keepGenerated = true lineNumbers = true nowarnings = false objectPath = D:\Castle-maven\castle\server\server-ejb\target/castle-server-ejb- 1.0.jar optimization = false outputFile = null verbose = true version = false] [INFO] Argument List for Appc settings [-lineNumbers, -keepgenerated, -g, -verb ose, D:\Castle-maven\castle\server\server-ejb\target/castle-server-ejb-1.0.jar] [appc] Created working directory: C:\DOCUME~1\DEEP_M~1.INF\LOCALS~1\Temp\appcgen [J2EE:160119]Appc is unable to process the file 'D:\Castle-maven\castle\server\s erver-ejb\target\castle-server-ejb-1.0.jar'. The following error occurred: java.lang.NoClassDefFoundError: cadvf2/server/AbstractEJB This is a compile dependency in the POM at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:502) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(Generic ClassLoader.java:480) at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClass Loader.java:182) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:292) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClass Loader.java:224) at weblogic.ejb20.deployer.BeanInfoImpl.loadClass(BeanInfoImpl.java:343) at weblogic.ejb20.deployer.BeanInfoImpl.init(BeanInfoImpl.java:192) at weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.init(ClientDrivenB eanInfoImpl.java:179) at weblogic.ejb20.deployer.SessionBeanInfoImpl.init(SessionBeanInfoImp l.java:74) at weblogic.ejb20.deployer.BeanInfoImpl.createBeanInfoImpl(BeanInfoImpl. java:367) at weblogic.ejb20.deployer.MBeanDeploymentInfoImpl.initializeBeanInfos(M BeanDeploymentInfoImpl.java:548) at weblogic.ejb20.deployer.MBeanDeploymentInfoImpl.init(MBeanDeploymen tInfoImpl.java:232) at weblogic.ejb20.ejbc.EJBCompiler.setupEJB(EJBCompiler.java:155) at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java :415) at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java :387) at weblogic.appc.compileEJB(appc.java:802) at weblogic.appc.compileEJB(appc.java:776) at weblogic.appc.compileInput(appc.java:463) at weblogic.appc.runBody(appc.java:184) at weblogic.utils.compiler.Tool.run(Tool.java:192) at weblogic.utils.compiler.Tool.run(Tool.java:147) at weblogic.appc.main(appc.java:1030) at org.codehaus.mojo.weblogic.AppcMojo.execute(AppcMojo.java:276) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534
RE: [M2]weblogic:appc classpath issue
The fix is in the code on the branch 2.8.0. i am trying to publish the fixes if I can get authorization. You can pull down the code and build it and that should fix your classpath issues. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Manu [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 12:07 PM To: Maven Users List Subject: Re: [M2]weblogic:appc classpath issue Hi, I have the same problem. I need to explicitly set the entire classpath by hand to have it worked. In other words, I'm defining another time all the dependencies that already are in the pom. The plugin does not seem to take into account the dependencies. By the way, i'm using version 2.8.0-SNAPSHOT Thxs Manu 2006/10/31, Dmystery [EMAIL PROTECTED]: Alos, looking at AppcMojo.class file, i dont see any default classpath being set. Here is the stack trace when i try to run the plugin. [INFO] Detailed Appc settings information AppcMojo[basicClientJar = false classpath = null compiler = null debugging = true deprecation = false forceGeneration = false idl = false idlDirectory = null idlFactrories = false idlMethodSignatures = null idlNoAbstractInterfaces = true idlNoValueTypes = true idlOrbix = false idlOverwrite = false idlVerbose = false idlVisiBroker = false iiop = false iiopDirectory = null javaOptions = null keepGenerated = true lineNumbers = true nowarnings = false objectPath = D:\Castle-maven\castle\server\server-ejb\target/castle-server-ejb- 1.0.jar optimization = false outputFile = null verbose = true version = false] [INFO] Argument List for Appc settings [-lineNumbers, -keepgenerated, -g, -verb ose, D:\Castle-maven\castle\server\server-ejb\target/castle-server-ejb-1.0.jar] [appc] Created working directory: C:\DOCUME~1\DEEP_M~1.INF\LOCALS~1\Temp\appcgen [J2EE:160119]Appc is unable to process the file 'D:\Castle-maven\castle\server\s erver-ejb\target\castle-server-ejb-1.0.jar'. The following error occurred: java.lang.NoClassDefFoundError: cadvf2/server/AbstractEJB This is a compile dependency in the POM at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:502) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(Generic ClassLoader.java:480) at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClass Loader.java:182) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:292) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClass Loader.java:224) at weblogic.ejb20.deployer.BeanInfoImpl.loadClass(BeanInfoImpl.java:343) at weblogic.ejb20.deployer.BeanInfoImpl.init(BeanInfoImpl.java:192) at weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.init(ClientDrivenB eanInfoImpl.java:179) at weblogic.ejb20.deployer.SessionBeanInfoImpl.init(SessionBeanInfoImp l.java:74) at weblogic.ejb20.deployer.BeanInfoImpl.createBeanInfoImpl(BeanInfoImpl. java:367) at weblogic.ejb20.deployer.MBeanDeploymentInfoImpl.initializeBeanInfos(M BeanDeploymentInfoImpl.java:548) at weblogic.ejb20.deployer.MBeanDeploymentInfoImpl.init(MBeanDeploymen tInfoImpl.java:232) at weblogic.ejb20.ejbc.EJBCompiler.setupEJB(EJBCompiler.java:155) at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java :415) at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java :387) at weblogic.appc.compileEJB(appc.java:802) at weblogic.appc.compileEJB(appc.java:776) at weblogic.appc.compileInput(appc.java:463) at weblogic.appc.runBody(appc.java:184) at weblogic.utils.compiler.Tool.run(Tool.java:192) at weblogic.utils.compiler.Tool.run(Tool.java:147) at weblogic.appc.main(appc.java:1030) at org.codehaus.mojo.weblogic.AppcMojo.execute(AppcMojo.java:276) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273
RE: [M2]weblogic:appc classpath issue
The code is checked in to SVN to fix this. I will try to push a new snapshot as soon as i can get authorization Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Dmystery [mailto:[EMAIL PROTECTED] Sent: Monday, October 30, 2006 11:47 PM To: users@maven.apache.org Subject: RE: [M2]weblogic:appc classpath issue Alos, looking at AppcMojo.class file, i dont see any default classpath being set. Here is the stack trace when i try to run the plugin. [INFO] Detailed Appc settings information AppcMojo[basicClientJar = false classpath = null compiler = null debugging = true deprecation = false forceGeneration = false idl = false idlDirectory = null idlFactrories = false idlMethodSignatures = null idlNoAbstractInterfaces = true idlNoValueTypes = true idlOrbix = false idlOverwrite = false idlVerbose = false idlVisiBroker = false iiop = false iiopDirectory = null javaOptions = null keepGenerated = true lineNumbers = true nowarnings = false objectPath = D:\Castle-maven\castle\server\server-ejb\target/castle-server-ejb- 1.0.jar optimization = false outputFile = null verbose = true version = false] [INFO] Argument List for Appc settings [-lineNumbers, -keepgenerated, -g, -verb ose, D:\Castle-maven\castle\server\server-ejb\target/castle-server-ejb-1.0.jar] [appc] Created working directory: C:\DOCUME~1\DEEP_M~1.INF\LOCALS~1\Temp\appcgen [J2EE:160119]Appc is unable to process the file 'D:\Castle-maven\castle\server\s erver-ejb\target\castle-server-ejb-1.0.jar'. The following error occurred: java.lang.NoClassDefFoundError: cadvf2/server/AbstractEJB This is a compile dependency in the POM at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:502) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(Generic ClassLoader.java:480) at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClass Loader.java:182) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:292) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClass Loader.java:224) at weblogic.ejb20.deployer.BeanInfoImpl.loadClass(BeanInfoImpl.java:343) at weblogic.ejb20.deployer.BeanInfoImpl.init(BeanInfoImpl.java:192) at weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.init(ClientDrivenB eanInfoImpl.java:179) at weblogic.ejb20.deployer.SessionBeanInfoImpl.init(SessionBeanInfoImp l.java:74) at weblogic.ejb20.deployer.BeanInfoImpl.createBeanInfoImpl(BeanInfoImpl. java:367) at weblogic.ejb20.deployer.MBeanDeploymentInfoImpl.initializeBeanInfos(M BeanDeploymentInfoImpl.java:548) at weblogic.ejb20.deployer.MBeanDeploymentInfoImpl.init(MBeanDeploymen tInfoImpl.java:232) at weblogic.ejb20.ejbc.EJBCompiler.setupEJB(EJBCompiler.java:155) at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java:415) at weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java:387) at weblogic.appc.compileEJB(appc.java:802) at weblogic.appc.compileEJB(appc.java:776) at weblogic.appc.compileInput(appc.java:463) at weblogic.appc.runBody(appc.java:184) at weblogic.utils.compiler.Tool.run(Tool.java:192) at weblogic.utils.compiler.Tool.run(Tool.java:147) at weblogic.appc.main(appc.java:1030) at org.codehaus.mojo.weblogic.AppcMojo.execute(AppcMojo.java:276) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke
New Weblogic 2.8.0 and 2.9.0 snapshot code in SVN
I have checked in the code for new snapshots for both versions of the plugins. This code fixes a number of issues but mainly; Classpath incorrect with APPC and Clientgen Remote deployment does not work on 9.0 I have also removed or renamed some of the configuration parameters to make them more clear and have removed some unused parameters. At this time I am not able to push up the snapshot due to some authentication issues. You can find the 2.9.0 code in the sandbox trunk and the 2.8.0 code is in the branch if you want to build it until I can push up the snapshot. I would appreciate any input on problems, fixes or additional features you would like. I will be porting this new code over to the Cargo plugin next week. I will be converting the 2.9.0 plugin over to use JSR-88 deployment over the next few weeks as well. Let me know how I can help. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] how to debug a plugin
Look in the mvn.bat or mvn.sh file and there are details on how to debug maven plugins @REM MAVEN_OPTS - parameters passed to the Java VM when running Maven @REM e.g. to debug Maven itself, use @REM set MAVEN_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_soc ket,server=y,suspend=y,address=8000 Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 3:29 AM To: users@maven.apache.org Subject: [m2] how to debug a plugin hi, how can i debug the release plugin? i'm using eclipse. thanks fredy Kabel Deutschland bietet Ihnen Internet, Telefonieren und Fernsehen aus einer Hand. Informieren Sie sich über unsere Produkte unter www.kabeldeutschland.de Diese E-Mail und etwaige Anhänge enthalten vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind, benachrichtigen Sie bitte den Absender und vernichten Sie anschließend diese Mail und die Anlagen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JWSC ant task for BeaWeblogic
If you can wait till over the weekend I am adding that task to the Maven plugin and then you can just include it in your build process. I am in the midst of a major refactoring of the plugin and in the process adding clientgen and jwsc support. I will post to the list when I am complete. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Boeckli, Dominique [mailto:[EMAIL PROTECTED] Sent: Friday, October 27, 2006 6:03 AM To: Maven Users List Subject: JWSC ant task for BeaWeblogic We have an ant build process to generate Webservices. Our target container is BEA Weblogic 9.2. That's why we use BEA specific ant tasks to do this job of generating the webservices. We now want to migrate our ant build process into maven2. Theoretically it is possible to call ant tasks from maven. That works for 'simple' tasks. Tested it. all fine! But i do not manage to get the JWSC ant task of BEA to work. In the end it might boil down to just having to know which JAR files to include in the dependencies of the maven pom?! My current dependencies look like this: dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency dependency groupIdapache.ant.lib/groupId artifactIdant-launcher/artifactId version1.7alpha/version /dependency dependency groupIdbea.weblogic.server.lib/groupId artifactIdweblogic/artifactId version9.2/version /dependency dependency groupIdbea.weblogic.server.lib/groupId artifactIdwebservices/artifactId version9.2/version /dependency dependency groupIdbea.weblogic/groupId artifactIdwlw-system/artifactId version9.2/version /dependency dependency groupIdbea.weblogic.server.lib/groupId artifactIdxbean/artifactId version9.2/version /dependency dependency groupIdcom.sun.java.lib/groupId artifactIdtools/artifactId version1.5.0_07/version /dependency dependency groupIdmaven.xmlbeans.jars/groupId artifactIdxbean/artifactId version2.2.0/version /dependency /dependencies But maven still results in following error: Embedded error: weblogic.wsee.tools.jws.build.CompileException: Error compiling web service: D:\JAVA_Projects\SOA_testcases\webservice\src\main\java\com\eds\soa\ws\h ello\JwscTestImpl.java failed to find root element corresponding to weblogic.j2ee.descriptor.JavaWsdlMappingBeanImpl By any chance would anybody have an idea how to get this JWSC task to work? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs.apache.org connection problems
I am having the same issues with my maven 2 repository. I saw a posting last night that some of the apache servers (people and cvs) had gone down but no information on when they were expected back up or any alternative on how to get around the issue. It looks like these servers are embedded in the maven parent pom and I have not been able to find any mirrors to get snapshots off of. I am trying to get the latest commons-vfs so that i can compile the latest copy of Cargo but no luck so far. Any suggestions on mirrors or any idea on when the servers might be back up. Seems like we need a disaster recovery plan for times like these. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Gareth Tilley [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 1:49 AM To: users@maven.apache.org Subject: cvs.apache.org connection problems Hi All, I'm trying to compile a plugin I've written, and am having some trouble with Maven attempting to download the required dependencies. The build just hangs when it tries to get things like: Downloading: http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/maven-error -diagnostics/2.0.4/maven-error-diagnostics-2.0.4.jar Downloading: http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/maven-monit or/2.0.4/maven-monitor-2.0.4.jar I've been working with Maven for a little while, and have made many changes to this plugin, all of which have been totally successful. I've never had any issues like this before. Does anyone have any ideas? Is there something wrong with that server? Regards Gareth Tilley -- View this message in context: http://www.nabble.com/cvs.apache.org-connection-problems-tf2499791.html#a696 8451 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [M2]weblogic:appc classpath issue
How did you make out with the appc mojo? I am updating the plugin to
simplify it this weekend and will update the code with some code that was
posted in JIRA. Let me know your status and I will send out a note on the
weekend when the new code is available.
Scott Ryan
Chief Technology Officer
Soaring Eagle L.L.C.
[EMAIL PROTECTED]
www.soaringeagleco.com
(303) 263-3044
-Original Message-
From: Dmystery [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 18, 2006 2:39 AM
To: users@maven.apache.org
Subject: [M2]weblogic:appc classpath issue
I'm using weblogic-maven-plugin to compile my ejb.jar. Here is the plugin
definition.
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdweblogic-maven-plugin/artifactId
version2.8.0-SNAPSHOT/version
configuration
objectPath${project.build.directory}/${project.artifactId}-${project.versi
on}.jar/objectPath
verbosetrue/verbose
debuggingtrue/debugging
nowarningsfalse/nowarnings
lineNumberstrue/lineNumbers
keepGeneratedtrue/keepGenerated
classpath${project.runtimeClasspathElements}/classpath
/configuration
executions
execution
phasepackage/phase
goals
goalappc/goal
/goals
/execution
/executions
/plugin
The ${project.runtimeClasspathElements} is a string like [somedir\jar1,
somedir\jar2]. Because of this the plugin throws a
org.codehaus.plexus.component.configurator.ComponentConfigurationException :
Invalid parameter supplied while setting '[somedir\jar1, somedir\jar2]'
Are we supposed to provide classpath/classpath in the first place? or
will it consider ${project.runtimeClasspathElements} as the default
classpath? (I guess not).
If i remove the classpath/classpath from the plugin definition (as it is
optional), it fails to find some of the classes that it needs to compile the
ejb.jar even though they are defined as dependencies in the project.
Let me know if i'm doing something wrong.
--
View this message in context:
http://www.nabble.com/-M2-weblogic%3Aappc-classpath-issue-tf2465090.html#a68
71847
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [M2]weblogic:appc classpath issue
You should not need a classpath as that is included for the clientgen part
of the plugin. The mojo should recognize the proper classpath from the
plugin dependencies. Are all your dependencies set to the default scope or
are some set to some other scope like provided etc? Let me try the latest
plugin against my test suite tonight and give you some more feedback. Just
to clarify you have an ejb jar file you are trying to appc? I have had
success with that. if you could send me a snippet of the issues you see
when you try with out the classpath that would help a lot. i will try to
get you an answer back this evening unless someone else on the list has an
answer before that.
Scott Ryan
Chief Technology Officer
Soaring Eagle L.L.C.
[EMAIL PROTECTED]
www.soaringeagleco.com
(303) 263-3044
-Original Message-
From: Dmystery [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 18, 2006 2:39 AM
To: users@maven.apache.org
Subject: [M2]weblogic:appc classpath issue
I'm using weblogic-maven-plugin to compile my ejb.jar. Here is the plugin
definition.
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdweblogic-maven-plugin/artifactId
version2.8.0-SNAPSHOT/version
configuration
objectPath${project.build.directory}/${project.artifactId}-${project.versi
on}.jar/objectPath
verbosetrue/verbose
debuggingtrue/debugging
nowarningsfalse/nowarnings
lineNumberstrue/lineNumbers
keepGeneratedtrue/keepGenerated
classpath${project.runtimeClasspathElements}/classpath
/configuration
executions
execution
phasepackage/phase
goals
goalappc/goal
/goals
/execution
/executions
/plugin
The ${project.runtimeClasspathElements} is a string like [somedir\jar1,
somedir\jar2]. Because of this the plugin throws a
org.codehaus.plexus.component.configurator.ComponentConfigurationException :
Invalid parameter supplied while setting '[somedir\jar1, somedir\jar2]'
Are we supposed to provide classpath/classpath in the first place? or
will it consider ${project.runtimeClasspathElements} as the default
classpath? (I guess not).
If i remove the classpath/classpath from the plugin definition (as it is
optional), it fails to find some of the classes that it needs to compile the
ejb.jar even though they are defined as dependencies in the project.
Let me know if i'm doing something wrong.
--
View this message in context:
http://www.nabble.com/-M2-weblogic%3Aappc-classpath-issue-tf2465090.html#a68
71847
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Weblogic plugin
Do the other goals work for you? It looks like you might have a snapshot from the old repository. I am headed to Apachecon but will try to look at the code Tuesday after I arrive at the conference. You could also try the 2.9.0 snapshot and just override the weblogic jars to use 8.1 as they should both work with an 8.1 installation providing maven will let you do the override. I have not been in that part of the code for a while so am not sure exactly what the issues is but it is clear that the mojo did not get packaged in to the plugin. Also make sure that your version matches the one in http://snapshots.repository.codehaus.org/org/codehaus/mojo/weblogic-maven-pl ugin/2.8.0-SNAPSHOT/ I have been trying to push up the latest code but am having issues with permissions. If that does not work I can send you a local copy tomorrow. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Morgovsky, Alexander (US - Glen Mills) [mailto:[EMAIL PROTECTED] Sent: Saturday, October 07, 2006 12:27 AM To: users@maven.apache.org Subject: Weblogic plugin Hi, I am having a problem with using the stop goal of the Weblogic plugin. Here is my error. [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.codehaus.mojo:weblogic-maven-plugin:2.8.0-SNAPSHOT:stop': Unable to find the mojo 'org.codehaus.mojo:weblogic-maven-plugin:2.8.0-SNAPSHOT:stop' in the plugin 'org.codehaus.mojo:weblogic-maven-plugin' weblogic/utils/compiler/Tool [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.codehaus.mojo:weblogic-maven-plugin:2.8.0-SNAPSHOT:stop': Unable to find the mojo 'org.codehaus.mojo:weblogic-maven-plugin:2.8.0-SNAPSHOT:stop' in the plugin 'org.codehaus.mojo:weblogic-m aven-plugin' Here is my pom.xml. plugin groupIdorg.codehaus.mojo/groupId artifactIdweblogic-maven-plugin/artifactId version2.8.0-SNAPSHOT/version executions execution goals goalstop/goal /goals configuration adminServerHostNamex/adminServerHostName adminServerPortx/adminServerPort adminServerProtocolhttp/adminServerProtocol userIdx/userId passwordx/password uploadfalse/upload remotetrue/remote verbosetrue/verbose debugtrue/debug targetNamesx/targetNames /configuration /execution /executions /plugin I've been trying to solve this for more than 7 hours, I am stuck here. Please help. This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: j2ee deploy with maven?
You can use the Cargo plugin in maven to ge the functionality that you need. They support deployment to a number of containers. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Francisco Treacy [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 5:49 AM To: users@maven.apache.org Subject: j2ee deploy with maven? Hi there! I'm new to Maven and I'm having some trouble with deployment-oriented tasks... I recently discovered that Maven doesn't support J2EE-server deployment out-of-the-box, and I'm trying to build up this part for our application. I have some questions cause I couldn't find the right answers on the web. 1. What do you suggest me to do in case of having a JBoss server and want to copy/deploy files to it? (Not only jars+wars but lots of xmls, too) Conceptually, where does this task belong to? Should I extend the default lifecycle to be able to execute, e.g.: mvn -e jboss-deploy? What have you guys done? 2. Regarding these issues, we've created a new type of artifact that packages everything that should be deployed, although we ignore if it's the good way to do so. We would like to use Maven (through a plugin) to handle this special artifact by resolving* its path to the actual network/disk resource, and decompress it into our J2EE server folders. (*) So there is our problem: what's the mechanism to resolve an artifact/dependency programmatically in our plugin? Thanks in advance for your replies, Francisco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Better to use variables or hard-coded paths?
property
name=hibernate.connection.usernameSAMPLEUSERNAME/property
property
name=hibernate.connection.passwordSAMPLEPASSWORD/property
property
name=hibernate.connection.urljdbc:db2://SAMPLEMACHINENAME:SAMPLEPORT/SAMPLEDATABASENAME/property
property
name=hibernate.connection.driver_classcom.ibm.db2.jcc.DB2Driver/property
property name=hibernate.connection.isolation1/property
property
name=hibernate.dialectorg.hibernate.dialect.DB2Dialect/property
!-- We use the old parser to get around an issue with weblogic
and ANTLR --
property
name=hibernate.query.factory_classorg.hibernate.hql.classic.ClassicQueryTranslatorFactory/property
property name=hibernate.generate_statisticstrue/property
/session-factory
/hibernate-configuration
pom.xml build section for both runtime and test
build
sourceDirectory${basedir}/src/main/java/sourceDirectory
testResources
!-- This grabs any test specific properties for the test run
--
testResource
directory${basedir}/src/test/resources/properties/directory
includes
include**/*.*/include
/includes
filteringfalse/filtering
/testResource
!-- This grabs any environment specific test specific files
(build env could be dev,test,stage,prod) Should be using profiles here. --
testResource
directory${basedir}/src/test/resources/${maven.build.environment}/directory
includes
include**/*.*/include
/includes
filteringfalse/filtering
/testResource
/testResources
resources
!-- This grabs environment specific properties and should be
replaced with profiles. --
resource
directory${basedir}/src/main/resources/${maven.build.environment}/directory
includes
include**/*.*/include
/includes
filteringfalse/filtering
/resource
!-- This grabs non environment specific properties including
the applicationContext xml files. --
resource
directory${basedir}/src/main/resources/properties/directory
includes
include**/*.*/include
/includes
filteringfalse/filtering
/resource
!-- This makes sure all the hbm.xml files are included in
the jar. The applicationContext xml files are in resources. --
resource
directory${basedir}/src/main/java/directory
includes
include**/*.hbm.xml/include
/includes
filteringfalse/filtering
/resource
/resources
/build
Scott Ryan
Chief Technology Officer
Soaring Eagle L.L.C.
[EMAIL PROTECTED]
www.soaringeagleco.com
(303) 263-3044
-Original Message-
From: Daniel Serodio [mailto:[EMAIL PROTECTED]
Sent: Friday, August 25, 2006 7:33 AM
To: Maven Users List
Subject: Re: Better to use variables or hard-coded paths?
Scott Ryan wrote:
We actually use the same application context but use the test resources
construct to pull it out of the main build path for use during testing. You
just need to include the xml files from the main tree in your resources
during testing and it works very nice. We use a different hibernate
configuration since in one case we are using a JNDI lookup in production and
during testing just a direct jdbc connection. The xml is configured to build
the session factory from the data source we define in the properties file.
If you like I can send you the maven 1 or 2 config we are using.
Can you please send me the m2 config? I don't understand what you mean
by pull it out of the main build path.
Scott Ryan
Chief Technology Officer
Soaring Eagle L.L.C.
[EMAIL PROTECTED]
www.soaringeagleco.com
(303) 263-3044
-Original Message-
From: Matt Raible [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 23, 2006 10:58 AM
To: Maven Users List
Subject: Re: Better to use variables or hard-coded paths?
On 8/23/06, Daniel Serodio [EMAIL
RE: Converting AppFuse to a Maven 2 Project
Matt, Check out the project attached to the jira ticket http://jira.codehaus.org/browse/MOJO-315 . It has a zip with a project structure similar to what you are looking at and that should build and you can use as a template. It has been a while since I posted it but it may be something you can modify to work. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: mraible [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 10:24 AM To: users@maven.apache.org Subject: Re: Converting AppFuse to a Maven 2 Project I started working on the Maven 2 conversion last night. I'm currently using Carlos's nested recommendation. Here's a screenshot of the current structure: http://raibledesigns.com/repository/images/appfuse2-structure.png Using this structure, I get errors stating that the data and web parent projects should have a packaging type of pom. However, I want these projects to create their own JAR artifacts. Should these be moved into common projects instead of having them in the root of data and web? Thanks, Matt -- View this message in context: http://www.nabble.com/Converting-AppFuse-to-a-Maven-2-Project-tf1964609.html #a5729055 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Converting AppFuse to a Maven 2 Project
I posted a sample project on Jira and copied it to the appfuse group that had a similar structure and had the poms set up to build correctly. The structure was close to what you are proposing. I will see if i can dig it up and you can just modify it to your liking. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: mraible [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 10:24 AM To: users@maven.apache.org Subject: Re: Converting AppFuse to a Maven 2 Project I started working on the Maven 2 conversion last night. I'm currently using Carlos's nested recommendation. Here's a screenshot of the current structure: http://raibledesigns.com/repository/images/appfuse2-structure.png Using this structure, I get errors stating that the data and web parent projects should have a packaging type of pom. However, I want these projects to create their own JAR artifacts. Should these be moved into common projects instead of having them in the root of data and web? Thanks, Matt -- View this message in context: http://www.nabble.com/Converting-AppFuse-to-a-Maven-2-Project-tf1964609.html #a5729055 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: RE: Weblogic plugin?
http://svn.mojo.codehaus.org/browse/mojo/trunk/mojo/mojo-sandbox/weblogic-ma ven-plugin/ give this a shot and look in the src tree. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Christofer Jennings [mailto:[EMAIL PROTECTED] Sent: Friday, August 04, 2006 9:03 AM To: Maven Users List Subject: Re: Re: RE: Weblogic plugin? Scott, btw: I noticed the fisheye link to the source didn't work. http://svn.mojo.codehaus.org/trunk/mojo/mojo-sandbox/weblogic-maven-plugin ,chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Weblogic plugin?
The plugin that I wrote does not support either of those but if it would be valuable for you then let me know. You can feel free to submit a jira ticket to the sandbox for improvement of the existing plugin or submit code that you think we should include. In general since 9.1 is java 5 compatible most of my colleagues are using xfire or jsr-181 through beehive to generate their services or clients in a more generic J2EE way without ties into the Weblogic architecture. I would suggest you check out those two alternatives. The axis plugin is a good alternative as well. If you still think the code should be added to the existing plugin submit a jira ticket and I will put it on my list. In case you don't know where to find the existing plugin here is the link http://mojo.codehaus.org/weblogic-maven-plugin/ Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Christofer Jennings [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 6:37 PM To: users@maven.apache.org Subject: weblogic plugin? Is there a weblogic plugin that supports WL 9.1 sevicegen, clientgen etc.? I found this in the mail archives, butit's pretty old. http://www.mail-archive.com/users@maven.apache.org/msg03059.html Thanks, chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Weblogic Deployment
Try adding the following to your pom.xml
repositories
repository
idMaven Snapshots/id
urlhttp://snapshots.maven.codehaus.org/maven2//url
snapshots
enabledtrue/enabled
/snapshots
releases
enabledfalse/enabled
/releases
/repository
/repositories
pluginRepositories
pluginRepository
idMaven Snapshots/id
urlhttp://snapshots.maven.codehaus.org/maven2//url
snapshots
enabledtrue/enabled
/snapshots
releases
enabledfalse/enabled
/releases
/pluginRepository
/pluginRepositories
or the following to your settings.xml in the .m2 directory
profiles
profile
idSnapshots/id
repositories
repository
idMaven Snapshots/id
urlhttp://snapshots.maven.codehaus.org/maven2//url
snapshots
enabledtrue/enabled
/snapshots
releases
enabledfalse/enabled
/releases
/repository
/repositories
pluginRepositories
pluginRepository
idMaven Snapshots/id
urlhttp://snapshots.maven.codehaus.org/maven2//url
snapshots
enabledtrue/enabled
/snapshots
releases
enabledfalse/enabled
/releases
/pluginRepository
/pluginRepositories
/profile
/profiles
activeProfiles
activeProfileSnapshots/activeProfile
/activeProfiles
Let me know if you are still having issues.
Scott Ryan
Chief Technology Officer
Soaring Eagle L.L.C.
[EMAIL PROTECTED]
www.soaringeagleco.com
(303) 263-3044
-Original Message-
From: Pauquette, Bryan [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 18, 2006 1:01 PM
To: Maven Users List
Subject: Weblogic Deployment
I have a maven 2.0.4 build creating an ear file that I would like to
deploy to a weblogic 8.1.x container via a mvn command line.
Where do I start?
I have tried getting the maven-weblogic-plugin installed but this
doesn't seem to be working for me. I have tried the following...
mvn install:install-file -Dfile=maven-weblogic-plugin-2.8.0.jar
-DgroupId=org.codehaus.mojo -DartifactId=maven-weblogic-plugin
-Dversion=2.8.0 -Dpackaging=plugin
mvn install:install-file -Dfile=maven-weblogic-plugin-2.8.0.jar
-DgroupId=org.codehaus.mojo -DartifactId=maven-weblogic-plugin
-Dversion=2.8.0 -Dpackaging=jar
These both succeed in that I get the message Build Successful
however
When I attempt to use the plugin via adding the plugin into the ear
pom.xml
Like so
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdmaven-weblogic-plugin/artifactId
configuration
adminServerHostNamemyhostname/adminServerHostName
adminServerPort8081/adminServerPort
userIdweblogic/userId
objectPath${project.build.outputDirectory}/../${project.artifactId}.${
project.packaging}/objectPath
passwordweblogic/password
name${project.artifactId}/name
stagingnostage/staging
targetNames
targetNameopus-frontend-server/targetName
/targetNames
/configuration
/plugin
I get the following
What am I doing wrong?
[EMAIL PROTECTED]:ear]$ mvn -e -X deploy
+ Error stacktraces are turned on.
Maven version: 2.0.4
[DEBUG] Building Maven user-level plugin registry from:
'/opt/app/devtp/bp6048/.m2/plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from:
'/opt/app/devtp/opusbuild/.gnu/maven-2.0.4/conf/plugin-registry.xml'
[INFO] Scanning for projects...
[DEBUG] Searching for parent-POM: net.cingular.dsc:dsc::1.0 of project:
null:dsc-ear:ear:null in relative path: ../pom.xml
[DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for
project: null:dsc-ear:ear:null
[INFO]
[INFO] Building Device Support Center:: Enterprise Application
[INFO]task-segment: [deploy]
[INFO]
[DEBUG] maven-ear-plugin: resolved to version 2.0 from repository
central
[DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugin-parent::2.0 for project:
null:maven-ear-plugin:maven-plugin:2.0 from the repository.
[DEBUG] maven-resources-plugin: resolved to version 2.1 from repository
central
[DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugin-parent::2.0 for project:
null:maven-resources-plugin:maven-plugin:2.1 from the repository.
[DEBUG] maven-install-plugin: resolved to version 2.0 from repository
central
[DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugin-parent::2.0 for project:
null:maven-install-plugin:maven-plugin:2.0 from the repository.
[DEBUG] maven-deploy-plugin: resolved to version 2.0 from repository
central
[DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugin-parent::2.0 for project:
null:maven-deploy-plugin:maven-plugin:2.0 from the repository.
[DEBUG] maven-weblogic-plugin: using locally installed snapshot
[DEBUG] Artifact not found - using stub model
RE: [mojo-user] Unable to use the weblogic-8.1 plugin to deploy a simple ejb jar
THe packaging attribute is used to determine what type of object you are trying to deploy. In weblogic the only types of objects that can actually be deployed are ears and wars so I am not sure why you are running deploy in an ejb project since it will not deploy without being contained inside an EAR. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Pauquette, Bryan [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 3:11 PM To: user@mojo.codehaus.org; Maven Users List Subject: RE: [mojo-user] Unable to use the weblogic-8.1 plugin to deploy a simple ejb jar The only place I specify ejb is in the packagingejb/packaging element of the projects pom. I can not change this and get maven 2.0.4 to generate the ejb-client jars. Why would the weblogic deployer assume a .ejb extension unless maven was somehow passing this to the deployer? -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 4:32 PM To: user@mojo.codehaus.org Subject: Re: [mojo-user] Unable to use the weblogic-8.1 plugin to deploy a simple ejb jar If you grok the entire log, you'll find: [INFO] Building ejb dsc-ejb-1.0 [INFO] Building jar: /opt/app/devbox/username/builds/myapp_ssk_dsc_1.0.1/vobs/pos_dev/dsc-pro file-services/target/dsc-ejb-1.0.jar ... [INFO] Building ejb client dsc-ejb-1.0-client [INFO] Building jar: /opt/app/devbox/username/builds/myapp_ssk_dsc_1.0.1/vobs/pos_dev/dsc-pro file-services/target/dsc-ejb-1.0-client.jar ... [INFO] Weblogic Deployment parameters [-deploy, -adminurl, http://devbox.wdc.myco.net:32030, -username, guido, -password, something, -name, dsc-ejb, -targets, myapp-frontend-server, -remote, -nostage, -sourcerootforupload, /opt/app/devbox/username/builds/myapp_ssk_dsc_1.0.1/vobs/pos_dev/dsc-pro file-services/target/dsc-ejb.ejb] weblogic.Deployer$DeployerException: The source file /opt/app/devbox/username/builds/myapp_ssk_dsc_1.0.1/vobs/pos_dev/dsc-pro file-services/target/dsc-ejb.ejb does not exist and cannot be deployed. So basically you are building a .jar file and then the Weblogic deployer is looking for a .ejb file. Change one or the other and its bound to work, I'd expect. Wayne On 7/21/06, Pauquette, Bryan [EMAIL PROTECTED] wrote: To: 'user@mojo.codehaus.org' Trying to deploy a simple ejb-jar using the weblogic 8.1 plugin. I think I followed all of the instructions correctly but alas I am getting the following. (Sensitive information has been changed in the post). It seems the name of the artifact is not correctly updated to .jar a .ejb extension is being used. I already posted on the maven users list regarding a similar issue a few days ago. Is this a bug? Thanks mvn -e -X weblogic:deploy + Error stacktraces are turned on. Maven version: 2.0.4 [DEBUG] Building Maven user-level plugin registry from: '/opt/app/devbox/username/.m2/plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: '/opt/app/devbox/myappbuild/.gnu/maven-2.0.4/conf/plugin-registry.xml' [INFO] Scanning for projects... [DEBUG] Searching for parent-POM: net.myco.dsc:dsc::1.0 of project: null:dsc-ejb:ejb:null in relative path: ../pom.xml [DEBUG] Parent-POM: net.myco.dsc:dsc::1.0 not found in relative path: ../pom.xml [DEBUG] Retrieving parent-POM: net.myco.dsc:dsc::1.0 for project: null:dsc-ejb:ejb:null from the repository. [INFO] Searching repository for plugin with prefix: 'weblogic'. [DEBUG] Skipping disabled repository Maven Snapshots [DEBUG] Skipping disabled repository Maven Snapshots [DEBUG] Skipping disabled repository Maven Snapshots [DEBUG] maven-ejb-plugin: resolved to version 2.0 from repository central [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugin-parent::2.0 for project: null:maven-ejb-plugin:maven-plugin:2.0 from the repository. [DEBUG] Skipping disabled repository central [DEBUG] Skipping disabled repository central [DEBUG] weblogic-maven-plugin: resolved to version 2.8.0-20060304.202223-1 from repository Maven Snapshots [DEBUG] Retrieving parent-POM: org.codehaus.mojo:mojo-sandbox::2-SNAPSHOT for project: null:weblogic-maven-plugin:maven-plugin:2.8.0-20060304.202223-1 from the repository. [DEBUG] Skipping disabled repository central [DEBUG] Skipping disabled repository central [DEBUG] mojo-sandbox: resolved to version 2-20060213.034901-2 from repository Maven Snapshots [DEBUG] Retrieving parent-POM: org.codehaus.mojo:mojo::7 for project: null:mojo-sandbox:pom:2-SNAPSHOT from the repository. [DEBUG] weblogic-maven-plugin: resolved to version 2.8.0-20060304.202223-1 from repository Maven Snapshots [DEBUG] Retrieving parent-POM: org.codehaus.cargo:cargo-extensions::0.8 for project: null:cargo-maven2-plugin:maven-plugin:0.2 from the repository. [DEBUG] Retrieving parent-POM: org.codehaus.cargo:cargo::0.8 for project: null:cargo-extensions:pom:null from the repository
RE: M2-Cargo Plugin Question
Probably best to ask on the Cargo email list however there is a Maven-2 plugin that supports Weblogic 8.1 and 9.0 on the sandbox at Mojo. I plan on releasing the final version next week as it has gotten pretty good testing. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Matilda Robert [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 2:15 PM To: users@maven.apache.org Subject: M2-Cargo Plugin Question Hi all maven 2.0 users, I am still fairly new to maven 2.0 and I have to questions for anyone that can provide feedback. I wanted to know if or when will local or remote deployer support for weblogic8x be added to the Maven 2 plugin for Cargo in the near future? Second, are there any SNAPSHOTs with this support? I built the configuration settings for the cargo plugin in the super pom with the dependicies and noticed that maven doesn't support the weblogic8.1 features yet. Can anyone please help me with this? Thank all of you in advanced, Matilda - Attention: Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] Weblogic J2EE Plugin
I just returned from overseas so as soon as I catch up on some sleep I will update this issue. There are samples posted on the Codehaus website but let me try and understand more of what you are trying to do and see if I can come up with a sample. It looks like you are needing more of the base maven plugins rather than the weblogic plugin. The weblogic plugin is to be used after you have assembled each artifact and want to compile and deploy those artifacts. The base maven plugins (jar, ear, war, etc) should be used first to assemble your artifacts. More after a few hours shuteye. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Konstantin Polyzois [mailto:[EMAIL PROTECTED] Sent: Saturday, April 08, 2006 4:14 AM To: Maven Users List Subject: Re: [m2] Weblogic J2EE Plugin Are you sure the plugin is for maven 2? /Konstantin On 4/6/06, mjohnsonaz74 [EMAIL PROTECTED] wrote: I am trying to convert an existing and convoluted project at work to Maven 2 from an existing Ant build script. I'm starting to get the hang of breaking one large project into multiple small projects (i.e. one artifact per project), but I'm running into the following issue. I create three projects (we'll call them jar, war, ear) and then I call them in order from a parent POM. Each module depends on the one before it (war depends on jar, and ear depends on war). What I'm trying to do is build one ear file from the three projects. I'm a bit confused, however, since the ant script uses wlcompile, wlappc, etc. to build the script and pre-compile the jsp code. Finally, my question...Can someobody please provide me a sample POM that uses the weblogic plugin and calls these tasks so that I can see how it's used? The documentation on the plugin is less then enlightening and I'm running in circles over what, I hope, is a trivial issue. If I could see a working POM file that uses this plugin that would help me out a lot. Thank you in advance! --MJ -- View this message in context: http://www.nabble.com/-m2-Weblogic-J2EE-Plugin-t1408033.html#a3791766 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Weblogic help
Is this a file that you can truly generate or is it a fixed file that you can just place in your resources directory like the web.xml and weblogic.xml. The application.xml is easy to generate since it is predictable what is needed however I am not sure the Weblogic version is that easy to generate. On our side we just hand code it an include it with the project using the resources directory in both Maven 1 and 2. From your example it looks like you are mainly using it to change the class loader hierarchy and there is really no way to automate that since the generated one would just generate the standard J2EE hierarchy which is the default so no weblogic-application.xml is actually required. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Paul Li [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 4:02 AM To: Maven Users List Subject: weblogic help hi guys, I am using maven to package my ear file at the moment. And it automatically generates application.xml (great!) However I need to deploy to weblogic app server, which looks for weblogic-application.xml. Is there a way I could configure the maven-ear plug in to generate this file the same way as application.xml? What I am also looking for is to figure out a way to specify the classloader resources tag. I believe these will be the jar/war files that gets loaded during application start up. a bit like this in the application.xml classloader-structure module-ref module-uriejb1.jar/module-uri /module-ref module-ref module-uriweb3.war/module-uri /module-ref classloader-structure module-ref module-uriweb1.war/module-uri /module-ref /classloader-structure classloader-structure module-ref module-uriejb3.jar/module-uri /module-ref module-ref module-uriweb2.war/module-uri /module-ref classloader-structure module-ref module-uriweb4.war/module-uri /module-ref /classloader-structure classloader-structure module-ref module-uriejb2.jar/module-uri /module-ref /classloader-structure /classloader-structure /classloader-structure thanks in advance! paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A cycle was detected while running the maven multiproject:clean goal
Yes that means that every project depends on the every other project and the system cannot figure out which to build first and maintain the proper relationships. We have seen that behavior with 1.1-beta2 and it is the correct behavior. This is similar to a circular dependency when building java projects. You just need one project that can be built first that does not have a relationship to a project that points back to itself. Scott Ryan Chief Technology Officer Soaring Eagle L.L.C. [EMAIL PROTECTED] www.soaringeagleco.com (303) 263-3044 -Original Message- From: Manisha Sur [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 15, 2006 2:34 AM To: users@maven.apache.org Subject: A cycle was detected while running the maven multiproject:clean goal Hi, I get the 'A cycle was detected' error for the multiproject:goal -Dgoal=3Dclean . The master project.xml contains dependencies on its subprojects, is this the reason its giving this error. when i comment the dependencies part of the master project.xml , everything works fine. how to tackle this problem . I am using maven 1.1 beta2 . i also have a copy of maven 1.0.2 -- Warm Regards Manisha Sur - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
