Re: Setting up a new jre to maven
Yes, to compile 1.5 classes, you must use a 1.5 (or greater) JRE. But you also must set the 1.5 configuration, otherwise it defaults to 1.4 classes with the 1.5 JRE. Wayne On 11/11/06, jiangshachina [EMAIL PROTECTED] wrote: Hello, configuration source1.5/source target1.5/target /configuration If that's true, I'm confused by the settings. Why Maven(or javac) can compile sources to 1.5-compatible classes at 1.4.2JRE(or 1.4.2 javac)? In order to fulfil the requirement, I think must install JDK1.5 firstly. Then use the real jre1.5.0 and configuration quoted above. a cup of Java, cheers! Sha Jiang Julio S. G. wrote: Hi Allan, Add these lines to you pom.xml: project build plugins plugin artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration /plugin /plugins /build /project Julio On 11/10/06, Allan Valeriano [EMAIL PROTECTED] wrote: Hi all, I'm having problems setting up a new jre to run mvn install. My default java version is 1.4.2_11, but I need maven to use jre 5 for it. I've read the FAQ, but I must say the example for it is not really helpful. Could somebody give me a hand on this sending a complete example? thanks in advance Allan Valeriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Setting-up-a-new-jre-to-maven-tf2610500s177.html#a7299977 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: Setting up a new jre to maven
Hi, otherwise it defaults to 1.4 classes with the 1.5 JRE. I'm using JDK1.5.0_08, but Maven uses 1.3, but 1.4, as default. a cup of Java, cheers! Sha Jiang Wayne Fay wrote: Yes, to compile 1.5 classes, you must use a 1.5 (or greater) JRE. But you also must set the 1.5 configuration, otherwise it defaults to 1.4 classes with the 1.5 JRE. Wayne On 11/11/06, jiangshachina [EMAIL PROTECTED] wrote: Hello, configuration source1.5/source target1.5/target /configuration If that's true, I'm confused by the settings. Why Maven(or javac) can compile sources to 1.5-compatible classes at 1.4.2JRE(or 1.4.2 javac)? In order to fulfil the requirement, I think must install JDK1.5 firstly. Then use the real jre1.5.0 and configuration quoted above. a cup of Java, cheers! Sha Jiang Julio S. G. wrote: Hi Allan, Add these lines to you pom.xml: project build plugins plugin artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration /plugin /plugins /build /project Julio On 11/10/06, Allan Valeriano [EMAIL PROTECTED] wrote: Hi all, I'm having problems setting up a new jre to run mvn install. My default java version is 1.4.2_11, but I need maven to use jre 5 for it. I've read the FAQ, but I must say the example for it is not really helpful. Could somebody give me a hand on this sending a complete example? thanks in advance Allan Valeriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Setting-up-a-new-jre-to-maven-tf2610500s177.html#a7299977 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/Setting-up-a-new-jre-to-maven-tf2610500s177.html#a7300964 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test : preventing expected stack trace in the console
I already posted the same question a few days ago, but no answer yet. Maybe we should file a bug on this? It is annoying when converting to Maven 2,you don't get the same functionality. regards, Wim 2006/11/11, Olivier Catteau [EMAIL PROTECTED]: Hi, I have a lot of unit tests in my app. When the tests runs, I see numerous expected stack traces logged in the console and at the end I get a normal Build Successful (but the first impression is that it failed). I would like that these expected stack traces don't appear in the console (in maven1, these traces wasn't logged). Is it possible ? Thanks. Olivier
Current state of play with maven 2 junit 4.1
I hope someone can spare me some time to clear up my investigations.
I am porting from maven 1 to maven 2, and we had begun using junit 4.1
by using the JUnit4TestAdapter like so:
/**
* Wrap the new junit4 testcase in a 3.x style suite
* to be recognized by eclipse runner and maven surefire.
* @return
*/
public static junit.framework.Test suite() {
return new JUnit4TestAdapter(MyTest.class);
}
This worked fine for maven 1 and since I didn't know any better, was
ported over to maven 2, where it *MOSTLY* works.
I say mostly, because there are 2 out of about 80 classes don't get any
tests detected in them i.e.
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 13.595 sec
even though they look almost identical to other classes that do have
tests detected run.
From reading around, it looks like I am between a rock a hard place
because http://jira.codehaus.org/browse/MSUREFIRE-131 would imply the
approach above shouldn't work (well it doesn't seem to all the time) but
http://jira.codehaus.org/browse/MSUREFIRE-84 would imply that native
junit 4 support is not baked properly either.
I'd rather not go to a temporary solution like
http://www.unto.net/wiki/Maven_JUnit4_plugin if I don't have to.
Any insights, work-arounds of corrections would be greatly appreciated
Matthew
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Ignore CVS-directories in Eclipse builds of a Maven 2 project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks! I have the following problem with a Maven 2 project: My project is in a CVS repository and the target-dir is excluded from CVS via .cvsignore. As long as I build with Maven everything is fine. When I generate a Eclipse project out of this and import it in my workspace I run into the problem that Eclipse builds the sources to the target target. Sadly the CVS -directories from src are not excluded from target. After the build the target directories contain CVS directories and confuse the CVS syncronization of Eclipse. Now Eclipse thinks that it wants to add the target-directories CVS although I specified them in the .cvsignore. When I add an exclusion pattern (CVS) for each source-directory in the project properties of Eclipse manually then Eclipse behaves fine while syncronization with CVS. My question is if it is possible to define those exclusion patterns in POM that is reflected in a generated Eclipse project. I attached the pom.xml for this project. Best Regards, Robin ?xml version=1.0 encoding=UTF-8?project modelVersion4.0.0/modelVersion groupIdxxx/groupId artifactIdxxx/artifactId packagingwar/packaging version0.0.1/version descriptionxxx/description build plugins plugin artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration /plugin /plugins /build dependencies dependency groupIdportlet-api/groupId artifactIdportlet-api/artifactId version1.0/version scopeprovided/scope /dependency dependency groupIdorg.hibernate/groupId artifactIdhibernate/artifactId version3.1/version scopeprovided/scope /dependency dependency groupIdjavax.mail/groupId artifactIdmail/artifactId version1.4/version scopeprovided/scope /dependency dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.0/version scopeprovided/scope /dependency dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.4/version scopeprovided/scope /dependency /dependencies /project - -- Robin de Silva Jayasinghe [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFVyPMJWhj7CIqBXkRAvWSAKCyQJcSEWZ6FAM3CvIV+2x1iw7E0gCgkw/4 tt2J7MyuXbaZafsUbzPhRyQ= =PvoF -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Puzzles on Standard Directory Structure?
On 11/9/06, jiangshachina [EMAIL PROTECTED] wrote: I may have known the goal of src/main/assembly(assembly descriptor files used by maven-assembly-plugin). Now I want to ask what files should be put at src/main/conf? It seems that the folder would include configuration files, but which configuration files? ... Now, how do Maven to deal with src/main/conf? Maven would copy the files under the directory to somewhere? ... I find nothing is interesting :( I haven't seen it used, and I don't think Maven does anything with it by default right now. Use it if it makes sense for your build, perhaps in combination with a custom plugin. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source code examples for Better Builds with Maven?
Got 'em. Thanks for the heads up!! Ed On 11/11/06, jiangshachina [EMAIL PROTECTED] wrote: Hi Ed, I tried the download site just now http://www.mergere.com/m2book_code.jsp but all is OK. You can try again. Good luck! a cup of Java, cheers! Sha Jiang Ed Young wrote: The links have been down all week, but I didn't email or call them until Friday. Oh, well. Anyone have them somewhere I can get them? I have a little time this weekend to work through the examples. Thanks, Ed On 11/11/06, Vincent Massol [EMAIL PROTECTED] wrote: Hi Ed, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Young Sent: samedi 11 novembre 2006 20:38 To: users@maven.apache.org Subject: Source code examples for Better Builds with Maven? I went to the mergere site and the source code examples for the Better Builds book are zip file of size 0. I've emailed mergere, called (twice) and have gotten no answers. Is this source freely available, and if so, can someone point me to it? Yes it's freely available from the mergere web site but they seem to have an issue with their links... It's the weekend which is probably why you're not getting an answer. Let's hope it's fixed on Monday. Thanks -Vincent ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Source-code-examples-for-Better-Builds-with-Maven--tf2614093s177.html#a7299848 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javadoc plugin failures and recent behaviour change
Hmmm, thank you for looking, I'll take another look. Regards, Kelvin. On 10/11/06, Vincent Siveton [EMAIL PROTECTED] wrote: Hi Kelvin, I did mvn javadoc:javadoc (with 2.1) on tuscany trunk: https://svn.apache.org/repos/asf/incubator/tuscany/java No error here. Are you sure that commonj is correctly included as dependency? Cheers, Vincent 2006/11/9, kelvin goodson [EMAIL PROTECTED]: I have a build failure that's happening when creating javadoc and it seems to be due to a change in the javadoc plugin behaviour. Here is a mvn execution log that exhibits the problem https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/kgoodson/javadocProblems/fresh.log Here are the logic steps that lead me to the conclusion that this is a plugin behaviour change 1) Building in my trunk started failing like this a few days ago 2) so I tried buiding an old unaltered release source tree which used to build fine, against my local repo and it failed in the same way 3) so I tried an offline build of the same release source on a different machine which had an old repository state, and it succeeded 4) so I zipped up the old repository from the 2nd machine and transferred it to the machine where the failures had started and did offline builds of both the release and of the trunk, which both succeeded --- at which point I could assert that it was the repository state that was at fault (see https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/kgoodson/javadocProblems/dt_used_on_lt.log ) 5) so I completely removed my repository and did and online build of the trunk from fresh, which failed in the same way that I had seen in step 1 -- at which point I could assert that the problems were introduced by an artifact which had been freshly downloaded to my repository I see from the difference in the logs, that right at the start of the javadoc:javadoc phase there is behaviour difference, the one that succeeds begins in this way === [INFO] [javadoc:javadoc] Loading source files for package org.apache.tuscany.sdo... Loading source files for package org.apache.tuscany.sdo.codegen... Loading source files for package org.apache.tuscany.sdo.helper... Loading source files for package org.apache.tuscany.sdo.impl... Loading source files for package org.apache.tuscany.sdo.model... Loading source files for package org.apache.tuscany.sdo.model.impl... Loading source files for package org.apache.tuscany.sdo.model.java.impl... Loading source files for package org.apache.tuscany.sdo.model.java... Loading source files for package org.apache.tuscany.sdo.util... Loading source files for package org.apache.tuscany.sdo.util.metadata.impl.. . Loading source files for package org.apache.tuscany.sdo.util.metadata... Loading source files for package org.apache.tuscany.sdo.util.resource... Loading source files for package org.apache.tuscany.sdo.generate.adapter... Loading source files for package org.apache.tuscany.sdo.generate... Loading source files for package org.apache.tuscany.sdo.generate.templates.model... Loading source files for package org.apache.tuscany.sdo.generate.util... Loading source files for package org.eclipse.jdt.core.formatter... Loading source files for package org.apache.tuscany.sdo.plugin... whereas the one that fails begins in this way ... [INFO] [javadoc:javadoc] Loading source file C:/Development/Tortoise/distroTest3/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/AnyTypeDataObject.java... Loading source file C:/Development/Tortoise/distroTest3/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/codegen/BytecodeInterfaceGenerator.java... Loading source file C:/Development/Tortoise/distroTest3/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/codegen/GenerationException.java... Loading source file C:/Development/Tortoise/distroTest3/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/codegen/JavaInterfaceGenerator.java... Loading source file C:/Development/Tortoise/distroTest3/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/codegen/NoJavaImplementationException.java... Loading source file C:/Development/Tortoise/distroTest3/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/helper/CopyHelperImpl.java... Loading source file C:/Development/Tortoise/distroTest3/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/helper/CrossScopeCopyHelperImpl.java... Loading source file C:/Development/Tortoise/distroTest3/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/helper/DataFactoryImpl.java... Loading source file C:/Development/Tortoise/distroTest3/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/helper/DataHelperImpl.java... Loading source file C:/Development/Tortoise/distroTest3/java/sdo/impl/src/main/java/org/apache/tuscany/sdo/helper/EqualityHelperImpl.java... Loading source file
[m2] Repository plugin not found?
Hi *, Trying to prepare an upload bundle... C:\project\qalab\maven2-qalab-pluginmvn repository:create-bundle [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'repository'. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-repository-plugin' does not exist or no valid version could be found It seems the repository plugin is not downloaded by default with 2.0.4. I have added this to my POM: dependencies dependency groupIdorg.apache.maven.plugins/groupId artifactIdmaven-repository-plugin/artifactId version2.0/version /dependency And mvn install downloaded it. Unfortunately, the exception is still there... mvn repository:create-bundle ... The plugin 'org.apache.maven.plugins:maven-repository-plugin' does not exist or no valid version could be found What am I doing wrong? I'm trying to follow: http://maven.apache.org/guides/mini/guide-central-repository-upload.html Many thanks Benoit -- View this message in context: http://www.nabble.com/-m2--Repository-plugin-not-found--tf2617344s177.html#a7304362 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Repository plugin not found?
On 11/12/06, Benoitx [EMAIL PROTECTED] wrote: C:\project\qalab\maven2-qalab-pluginmvn repository:create-bundle It's repository:bundle-create (not create-bundle) and you shouldn't need to add it to your pom. mvn repository:create-bundle ... The plugin 'org.apache.maven.plugins:maven-repository-plugin' does not exist or no valid version could be found What am I doing wrong? I'm trying to follow: http://maven.apache.org/guides/mini/guide-central-repository-upload.html That's odd, it downloads and executes just fine for me with 2.0.4. Try it with -U (and the correct goal) and see if that works. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Repository plugin not found?
Thanks Wendy, I saw both and had the feeling that I had tried both... obviously not. Thanks for your reply Benoit Wendy Smoak-3 wrote: On 11/12/06, Benoitx [EMAIL PROTECTED] wrote: C:\project\qalab\maven2-qalab-pluginmvn repository:create-bundle It's repository:bundle-create (not create-bundle) and you shouldn't need to add it to your pom. mvn repository:create-bundle ... The plugin 'org.apache.maven.plugins:maven-repository-plugin' does not exist or no valid version could be found What am I doing wrong? I'm trying to follow: http://maven.apache.org/guides/mini/guide-central-repository-upload.html That's odd, it downloads and executes just fine for me with 2.0.4. Try it with -U (and the correct goal) and see if that works. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-m2--Repository-plugin-not-found--tf2617344s177.html#a7304782 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Unknown file status: 'S' in line Skipped '.'.
I am running : mvn 2.0.4 JDK 1.5 subversion Multiple project structure! *Why does this build has a SUCCESSFUL status? It did not do an update?* *Is there something wrong with my pom.xml? This did work back in July 2006!* ** ** Parent pom.xml | | Child pom.xml If am trying to do a scm:update mvn scm:update -DconnectionUrl=scm:svn:svn://csspap/CSS_JAVA_DEVELOPMENT/trunk [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] CSS JAVA APPLICATIONS *-- Parent* [INFO] OPER_MET*--- Child* [INFO] Searching repository for plugin with prefix: 'scm'. [INFO] [INFO] Building CSS JAVA APPLICATIONS [INFO]task-segment: [scm:update] (aggregator-style) [INFO] [INFO] [scm:update] [INFO] Executing: svn --non-interactive update [INFO] Working directory: /usr2/local/builds/CSS_JAVA_DEV/projects [INFO] Unknown file status: 'S' in line Skipped'.'. *--- This is the issue I believe* [INFO] Storing revision in 'scm.revision' project property. [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 5 seconds [INFO] Finished at: Fri Nov 10 16:27:38 CST 2006 [INFO] Final Memory: 6M/225M [INFO] *But this does not update the any of the src directories!* *PARENT POM.XML* ** ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdcom.weenergies.development/groupId artifactIdJavaDev/artifactId version1.0-SNAPSHOT/version packagingpom/packaging nameCSS JAVA APPLICATIONS/name description This is our main pom.xml. This file ^M will control the sub-modules for builds, ^M test and deploy. This main project will provide the basic values that will be passed to sub-modules. /description pluginRepositories pluginRepository idibiblio.net/id urlhttp://www.ibiblio.net/pub/packages/maven2/url /pluginRepository /pluginRepositories properties war.deploy/usr2/local/jboss-4.0.3SP1 /server/JTEST/deploy//war.deploy /properties modules moduleOPER_MET/module /modules dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.13/version scopecompile/scope /dependency /dependencies build plugins /plugins /build distributionManagement site idwebsite/id urlfile:///usr2/local/jboss-4.0.3SP1/server/JSTAGE/deploy/Reports.war/ /url /site /distributionManagement /project *CHILD POM.XML* ?xml version=1.0 encoding=UTF-8? project parent groupIdcom.weenergies.development/groupId artifactIdJavaDev/artifactId version1.0-SNAPSHOT/version /parent modelVersion4.0.0/modelVersion groupIdcom.weenergies.development.tools/groupId artifactIdOPER_MET/artifactId packagingwar/packaging version1.0-SNAPSHOT/version nameOPER_MET/name descriptionThis will configure the Operating Metrics Web Application!/description pluginRepositories /pluginRepositories build sourceDirectorysrc//sourceDirectory testSourceDirectorytest//testSourceDirectory finalNameOPER_MET/finalName pluginManagement plugins plugin artifactIdmaven-release-plugin/artifactId configuration tagBasesvn://csspap/CSS_JAVA_DEVELOPMENT/tags/tagBase tagRB_TAG/tag generateReleasePomsfalse/generateReleasePoms /configuration /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId version2.0/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration /plugin /plugins /pluginManagement /build dependencies dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version4.0.3/version /dependency dependency groupIdsybase.jbdcx/groupId artifactIdsybase-jbdc/artifactId version5.0/version /dependencies /project THanks
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: Current state of play with maven 2 junit 4.1
On Sun, Nov 12, 2006 at 11:08:21PM +1100, J. Matthew Pryor spake thus: *snip* I am porting from maven 1 to maven 2, and we had begun using junit 4.1 by using the JUnit4TestAdapter like so: *snip* This worked fine for maven 1 and since I didn't know any better, was ported over to maven 2, where it *MOSTLY* works. I say mostly, because there are 2 out of about 80 classes don't get any tests detected in them i.e. *snip* From reading around, it looks like I am between a rock a hard place because http://jira.codehaus.org/browse/MSUREFIRE-131 would imply the approach above shouldn't work (well it doesn't seem to all the time) but http://jira.codehaus.org/browse/MSUREFIRE-84 would imply that native junit 4 support is not baked properly either. I'd rather not go to a temporary solution like http://www.unto.net/wiki/Maven_JUnit4_plugin if I don't have to. Any insights, work-arounds of corrections would be greatly appreciated We've had good results using a slightly modified version of the patches attached to SUREFIRE-31 by Karl M. Davis: http://jira.codehaus.org/browse/SUREFIRE-31#action_76833 We basically made an internal version of the surefire plugin (based on a patched version of the svn code from 2006-10-11) for projects that use JUnit-4.x. As for your 2 out of 80 classes not having their JUnit-4.x tests detected, this may be due to the behavior of the default surefire plugin: it attempts to run as tests anything that looks like a junit-3.x test, a TestNG test, or a non-framework-related unit test (methods named test*()). It may be that your unit tests are not being run by the provider you think they are. A simple way to test this would be to add (to one of your classes where no unit tests are detected) methods that print something recognizable to stderr: * a JUnit-4.x style @Before method * a JUnit-4.x style @Test annotated method named doFoo() [that is, /not/ named testFoo()] * a method named testJunk() I suspect that you'll see the output from testJunk() only. More to the point, using a patched version of the surefire plugin is the only solution I've seen that supports JUnit-4.x completely. In this case, completely means completely for my purposes as I've not tested every JUnit-4.x feature using our patched version, but I have tested these behaviors: * Exceptions in @BeforeClass, @Before, @AfterClass, and @After methods are detected and reported (they fail the tests) * Methods annotated with @Test, and /only/ those methods, are treated as unit test methods (regardless of the method name) HTH, -Al -- :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: Alan D. Salewski Software Developer Health Market Science, Inc. :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Repository documentation obsolete?
Hi From http://maven.apache.org/plugins/index.html there is no link to the Repository Plugin, however, there is a page: http://maven.apache.org/plugins/maven-repository-plugin/index.html But the FAQ and usage pages are missing... What is happening with this plugin? Is there a replacement? Is it supported? thanks Benoit -- View this message in context: http://www.nabble.com/-m2--Repository-documentation-obsolete--tf2618613s177.html#a7307838 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Repository documentation obsolete?
On 11/12/06, Benoitx [EMAIL PROTECTED] wrote: From http://maven.apache.org/plugins/index.html there is no link to the Repository Plugin, however, there is a page: http://maven.apache.org/plugins/maven-repository-plugin/index.html But the FAQ and usage pages are missing... What is happening with this plugin? Is there a replacement? Is it supported? It looks like no one has written FAQ and Usage pages for it yet, but you can refer to the 'guide to uploading': http://maven.apache.org/guides/mini/guide-ibiblio-upload.html (The link on the plugin index is already fixed in svn, the page just needs to be published.) Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting up a new jre to maven
Yes, you naturally need to use a compiler at least as high as the code you wish to compile in. If your Maven is running on JDK 1.4, and you wish to compile code as 1.5, you will need a 1.5 compiler. You can point to a 1.5compiler in the following way: http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html Eric On 11/10/06, Allan Valeriano [EMAIL PROTECTED] wrote: Hi all, I'm having problems setting up a new jre to run mvn install. My default java version is 1.4.2_11, but I need maven to use jre 5 for it. I've read the FAQ, but I must say the example for it is not really helpful. Could somebody give me a hand on this sending a complete example? thanks in advance Allan Valeriano -- Eric Redmond http://codehaus.org/~eredmond
Re: Unknown file status: 'S' in line Skipped '.'.
I don't know why your build failed, but this table of file/dir statii from the Subversion Book may help you figure it out: http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.tour.cycle.examine.status Maybe the svn repo specified on the maven command line does not match the repo (in a precise, I'm a computer, and I demand precision kind of way) that was used to check out the working directories? It isn't clear to me how that would switch your working dirs, but the fact that you have to specify the repo when running the command raises a red flag to me in terms of it's consistent use over time. You might try 'svn stat' to see what the subversion status of your working directory tree is. -Max On Sun, 2006-11-12 at 14:40 -0600, [EMAIL PROTECTED] wrote: I am running : mvn 2.0.4 JDK 1.5 subversion Multiple project structure! *Why does this build has a SUCCESSFUL status? It did not do an update?* *Is there something wrong with my pom.xml? This did work back in July 2006!* ** ** Parent pom.xml | | Child pom.xml If am trying to do a scm:update mvn scm:update -DconnectionUrl=scm:svn:svn://csspap/CSS_JAVA_DEVELOPMENT/trunk [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] CSS JAVA APPLICATIONS *-- Parent* [INFO] OPER_MET*--- Child* [INFO] Searching repository for plugin with prefix: 'scm'. [INFO] [INFO] Building CSS JAVA APPLICATIONS [INFO]task-segment: [scm:update] (aggregator-style) [INFO] [INFO] [scm:update] [INFO] Executing: svn --non-interactive update [INFO] Working directory: /usr2/local/builds/CSS_JAVA_DEV/projects [INFO] Unknown file status: 'S' in line Skipped'.'. *--- This is the issue I believe* [INFO] Storing revision in 'scm.revision' project property. [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 5 seconds [INFO] Finished at: Fri Nov 10 16:27:38 CST 2006 [INFO] Final Memory: 6M/225M [INFO] *But this does not update the any of the src directories!* *PARENT POM.XML* ** ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdcom.weenergies.development/groupId artifactIdJavaDev/artifactId version1.0-SNAPSHOT/version packagingpom/packaging nameCSS JAVA APPLICATIONS/name description This is our main pom.xml. This file ^M will control the sub-modules for builds, ^M test and deploy. This main project will provide the basic values that will be passed to sub-modules. /description pluginRepositories pluginRepository idibiblio.net/id urlhttp://www.ibiblio.net/pub/packages/maven2/url /pluginRepository /pluginRepositories properties war.deploy/usr2/local/jboss-4.0.3SP1 /server/JTEST/deploy//war.deploy /properties modules moduleOPER_MET/module /modules dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.13/version scopecompile/scope /dependency /dependencies build plugins /plugins /build distributionManagement site idwebsite/id urlfile:///usr2/local/jboss-4.0.3SP1/server/JSTAGE/deploy/Reports.war/ /url /site /distributionManagement /project *CHILD POM.XML* ?xml version=1.0 encoding=UTF-8? project parent groupIdcom.weenergies.development/groupId artifactIdJavaDev/artifactId version1.0-SNAPSHOT/version /parent modelVersion4.0.0/modelVersion groupIdcom.weenergies.development.tools/groupId artifactIdOPER_MET/artifactId packagingwar/packaging version1.0-SNAPSHOT/version nameOPER_MET/name descriptionThis will configure the Operating Metrics Web Application!/description pluginRepositories /pluginRepositories build sourceDirectorysrc//sourceDirectory testSourceDirectorytest//testSourceDirectory finalNameOPER_MET/finalName pluginManagement plugins plugin artifactIdmaven-release-plugin/artifactId configuration tagBasesvn://csspap/CSS_JAVA_DEVELOPMENT/tags/tagBase tagRB_TAG/tag generateReleasePomsfalse/generateReleasePoms /configuration /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdcobertura-maven-plugin/artifactId version2.0/version /plugin
Re: Puzzles on Standard Directory Structure?
Hello Wendy, I haven't seen it used, and I don't think Maven does anything with it by default right now. Oh, that's means that the directories just are recommended by Maven, but Maven does nothing for it as default. Then I have to deal with the directories by manual. What's a better way to add the directories(and files under them) to archive files? I'm using maven-antrun-plugin now. But I don't think it's the best way. Use it if it makes sense for your build, perhaps in combination with a custom plugin. I'll consider the solution. a cup of Java, cheers! Sha Jiang Wendy Smoak-3 wrote: On 11/9/06, jiangshachina [EMAIL PROTECTED] wrote: I may have known the goal of src/main/assembly(assembly descriptor files used by maven-assembly-plugin). Now I want to ask what files should be put at src/main/conf? It seems that the folder would include configuration files, but which configuration files? ... Now, how do Maven to deal with src/main/conf? Maven would copy the files under the directory to somewhere? ... I find nothing is interesting :( I haven't seen it used, and I don't think Maven does anything with it by default right now. Use it if it makes sense for your build, perhaps in combination with a custom plugin. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Puzzles-on-Standard-Directory-Structure--tf2519880s177.html#a7310071 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Puzzles on Standard Directory Structure?
On 11/12/06, jiangshachina [EMAIL PROTECTED] wrote: Oh, that's means that the directories just are recommended by Maven, but Maven does nothing for it as default. It probably means that during the design discussions, someone thought a 'conf' directory would be useful. I haven't seen it mentioned, maybe there's already a plan for it, maybe not. Maven isn't finished yet. :) Then I have to deal with the directories by manual. What's a better way to add the directories(and files under them) to archive files? I'm using maven-antrun-plugin now. But I don't think it's the best way. If you want a file to be in the archive, then put it under src/main/resources (or src/main/webapp, as the case may be.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Error with WebDAV URL
I'm running Archiva from a svn checkout, with the Jetty plugin. (mvn jetty:run) I've created the admin user and a managed repo, and given the 'admin' user the repository observer role for that repo. From the Administration page, if I click on the WebDAV URL: http://localhost:9091/repository/MyRepo I get the error below. A quick Google search turns up a few things that imply Jetty might not support DAV. I'm not entirely sure whether that's true (or what, exactly, DAV is, for that matter.) Any ideas? Error 404 Not Found Resource in error: http://localhost:9091/repository/myrepo/MyRepo Exception details: it.could.webdav.DAVException: Not found at it.could.webdav.methods.HEAD.process(HEAD.java:52) at it.could.webdav.methods.GET.process(GET.java:58) at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) at org.apache.maven.archiva.web.servlet.repository.RepositoryAccess.servletRequest(RepositoryAccess.java:223) at org.apache.maven.archiva.web.servlet.PlexusComponentServlet.service(PlexusComponentServlet.java:126) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1049) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1040) at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1040) at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1040) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:352) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:230) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141) at org.mortbay.jetty.Server.handle(Server.java:286) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:444) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:701) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:203) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:340) at org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java:270) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) Thanks, -- Wendy
Re: Error with WebDAV URL
Does the directory you configured already exist? I don't think Archiva creates it at present. This isn't anything to do with Jetty - we use the could.it webdav library (as you can see through the trace, it comes from a RepositoryAccess servlet in our code). - Brett On 13/11/2006, at 12:38 PM, Wendy Smoak wrote: I'm running Archiva from a svn checkout, with the Jetty plugin. (mvn jetty:run) I've created the admin user and a managed repo, and given the 'admin' user the repository observer role for that repo. From the Administration page, if I click on the WebDAV URL: http://localhost:9091/repository/MyRepo I get the error below. A quick Google search turns up a few things that imply Jetty might not support DAV. I'm not entirely sure whether that's true (or what, exactly, DAV is, for that matter.) Any ideas? Error 404 Not Found Resource in error: http://localhost:9091/repository/myrepo/MyRepo Exception details: it.could.webdav.DAVException: Not found at it.could.webdav.methods.HEAD.process(HEAD.java:52) at it.could.webdav.methods.GET.process(GET.java:58) at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) at org.apache.maven.archiva.web.servlet.repository.RepositoryAccess.servl etRequest(RepositoryAccess.java:223) at org.apache.maven.archiva.web.servlet.PlexusComponentServlet.service (PlexusComponentServlet.java:126) at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:445) at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1049) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter (FilterDispatcher.java:189) at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1040) at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage (PageFilter.java:118) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter (PageFilter.java:52) at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1040) at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter (ActionContextCleanUp.java:88) at org.mortbay.jetty.servlet.ServletHandler $CachedChain.doFilter(ServletHandler.java:1040) at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:352) at org.mortbay.jetty.servlet.SessionHandler.handle (SessionHandler.java:230) at org.mortbay.jetty.handler.ContextHandler.handle (ContextHandler.java:627) at org.mortbay.jetty.handler.ContextHandlerCollection.handle (ContextHandlerCollection.java:149) at org.mortbay.jetty.handler.HandlerCollection.handle (HandlerCollection.java:123) at org.mortbay.jetty.handler.HandlerWrapper.handle (HandlerWrapper.java:141) at org.mortbay.jetty.Server.handle(Server.java:286) at org.mortbay.jetty.HttpConnection.handleRequest (HttpConnection.java:444) at org.mortbay.jetty.HttpConnection $RequestHandler.headerComplete(HttpConnection.java:701) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500) at org.mortbay.jetty.HttpParser.parseAvailable (HttpParser.java:203) at org.mortbay.jetty.HttpConnection.handle (HttpConnection.java:340) at org.mortbay.jetty.nio.HttpChannelEndPoint.run (HttpChannelEndPoint.java:270) at org.mortbay.thread.BoundedThreadPool$PoolThread.run (BoundedThreadPool.java:475) Thanks, -- Wendy
Re: Release Rollback
I don't think this is available as a Maven Mojo yet. But it would really cool to have. I hit similar situation at work where I needed to revert a release. The other alternate is to delete the release tag (referring to CVS, but not sure about other SCMs). Any one else has any ideas? May be someone from maven-release-plugin team can comment if this is feasible or not :-) Cheers, Rahul Daniel Murley wrote: Hi All, Is it at all possible to rollback a release after calling release:perform? Thanks Daniel - 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: Unknown file status: 'S' in line Skipped '.'.
The problem is that the build passes, because the src code is not being updated. So, I ran the command from manually, and I narrowed it down to this command. Thanks, On 11/12/06, Max Cooper [EMAIL PROTECTED] wrote: I don't know why your build failed, but this table of file/dir statii from the Subversion Book may help you figure it out: http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.tour.cycle.examine.status Maybe the svn repo specified on the maven command line does not match the repo (in a precise, I'm a computer, and I demand precision kind of way) that was used to check out the working directories? It isn't clear to me how that would switch your working dirs, but the fact that you have to specify the repo when running the command raises a red flag to me in terms of it's consistent use over time. You might try 'svn stat' to see what the subversion status of your working directory tree is. -Max On Sun, 2006-11-12 at 14:40 -0600, [EMAIL PROTECTED] wrote: I am running : mvn 2.0.4 JDK 1.5 subversion Multiple project structure! *Why does this build has a SUCCESSFUL status? It did not do an update?* *Is there something wrong with my pom.xml? This did work back in July 2006!* ** ** Parent pom.xml | | Child pom.xml If am trying to do a scm:update mvn scm:update -DconnectionUrl=scm:svn:svn://csspap/CSS_JAVA_DEVELOPMENT/trunk [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] CSS JAVA APPLICATIONS *-- Parent* [INFO] OPER_MET*--- Child* [INFO] Searching repository for plugin with prefix: 'scm'. [INFO] [INFO] Building CSS JAVA APPLICATIONS [INFO]task-segment: [scm:update] (aggregator-style) [INFO] [INFO] [scm:update] [INFO] Executing: svn --non-interactive update [INFO] Working directory: /usr2/local/builds/CSS_JAVA_DEV/projects [INFO] Unknown file status: 'S' in line Skipped'.'. *--- This is the issue I believe* [INFO] Storing revision in 'scm.revision' project property. [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 5 seconds [INFO] Finished at: Fri Nov 10 16:27:38 CST 2006 [INFO] Final Memory: 6M/225M [INFO] *But this does not update the any of the src directories!* *PARENT POM.XML* ** ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdcom.weenergies.development/groupId artifactIdJavaDev/artifactId version1.0-SNAPSHOT/version packagingpom/packaging nameCSS JAVA APPLICATIONS/name description This is our main pom.xml. This file ^M will control the sub-modules for builds, ^M test and deploy. This main project will provide the basic values that will be passed to sub-modules. /description pluginRepositories pluginRepository idibiblio.net/id urlhttp://www.ibiblio.net/pub/packages/maven2/url /pluginRepository /pluginRepositories properties war.deploy/usr2/local/jboss-4.0.3SP1 /server/JTEST/deploy//war.deploy /properties modules moduleOPER_MET/module /modules dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.13/version scopecompile/scope /dependency /dependencies build plugins /plugins /build distributionManagement site idwebsite/id url file:///usr2/local/jboss-4.0.3SP1/server/JSTAGE/deploy/Reports.war/ /url /site /distributionManagement /project *CHILD POM.XML* ?xml version=1.0 encoding=UTF-8? project parent groupIdcom.weenergies.development/groupId artifactIdJavaDev/artifactId version1.0-SNAPSHOT/version /parent modelVersion4.0.0/modelVersion groupIdcom.weenergies.development.tools/groupId artifactIdOPER_MET/artifactId packagingwar/packaging version1.0-SNAPSHOT/version nameOPER_MET/name descriptionThis will configure the Operating Metrics Web Application!/description pluginRepositories /pluginRepositories build sourceDirectorysrc//sourceDirectory testSourceDirectorytest//testSourceDirectory finalNameOPER_MET/finalName pluginManagement plugins plugin artifactIdmaven-release-plugin/artifactId configuration tagBasesvn://csspap/CSS_JAVA_DEVELOPMENT/tags/tagBase tagRB_TAG/tag
Re: Puzzles on Standard Directory Structure?
Hi Wendy, If you want a file to be in the archive, then put it under src/main/resources (or src/main/webapp, as the case may be.) The two approaches I have used. I just want to know whether there are other ways. But the two approaches above are most direct and easy :D a cup of Java, cheers! Sha Jiang Wendy Smoak-3 wrote: On 11/12/06, jiangshachina [EMAIL PROTECTED] wrote: Oh, that's means that the directories just are recommended by Maven, but Maven does nothing for it as default. It probably means that during the design discussions, someone thought a 'conf' directory would be useful. I haven't seen it mentioned, maybe there's already a plan for it, maybe not. Maven isn't finished yet. :) Then I have to deal with the directories by manual. What's a better way to add the directories(and files under them) to archive files? I'm using maven-antrun-plugin now. But I don't think it's the best way. If you want a file to be in the archive, then put it under src/main/resources (or src/main/webapp, as the case may be.) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Puzzles-on-Standard-Directory-Structure--tf2519880s177.html#a7310644 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Example POM for Weblogic servicegen needed
Thanks for the replies guys. Even i first thought of having a seperate project for servicegen and appc, but didn't build on the thought. Looks like i should try it out. As of now i've appc defined in an execution and in the package phase. I hope the servicegen mojo in the plugin will solve a lot of problems :) Scott Ryan-2 wrote: 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
Re: Test : preventing expected stack trace in the console
Hi Olivier and Wim, Try using the --quiet option. It will change the logging level to ERROR. Hope this helps. Dawn Wim Deblauwe wrote: I already posted the same question a few days ago, but no answer yet. Maybe we should file a bug on this? It is annoying when converting to Maven 2,you don't get the same functionality. regards, Wim 2006/11/11, Olivier Catteau [EMAIL PROTECTED]: Hi, I have a lot of unit tests in my app. When the tests runs, I see numerous expected stack traces logged in the console and at the end I get a normal Build Successful (but the first impression is that it failed). I would like that these expected stack traces don't appear in the console (in maven1, these traces wasn't logged). Is it possible ? Thanks. Olivier -- View this message in context: http://www.nabble.com/Test-%3A-preventing-expected-stack-trace-in-the-console-tf2614478s177.html#a7311768 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release plugin : same version of modules
Hi Olivier,
In your parent POM, use:
dependencyManagement
dependencies
dependency
groupIdcom.mycompany.app/groupId
artifactIdmy-subapp/artifactId
version${project.version}/version
/dependency
/dependencies
/dependencyManagement
${project.version} basically means getProject().getVersion(). This is the
version of your parent project. However, you can specify here the version
number that you want your modules to have.
Hope this helps.
Dawn
Olivier Catteau wrote:
Hi,
I've got a multi-modules application. I'd like that the different modules
have the same version so I have fixed the same version in every pom.xml.
But when I use the release plugin, I need to enter the version of every
modules. Is it possible to enter a single version for every modules ? or
do
I need to customize my own release plugin ?
Thanks.
Olivier
--
View this message in context:
http://www.nabble.com/Release-plugin-%3A-same-version-of-modules-tf2614543s177.html#a7312017
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ZQ: Generate a report to show source changes
Hi, Is there a way to have a report that shows the changes between the sources of two releases? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] eclipse:eclipse and checkstyle nature
Ok then, in the maven eclipse plugin i found the following that could be of use? parameter nameadditionalConfig/name typeorg.apache.maven.plugin.eclipse.EclipseConfigFile/type requiredfalse/required editabletrue/editable descriptionAllow to configure additional generic configuration files for eclipse that will be written out to disk when running eclipse:eclipse. FOr each file you can specify the name and the text content. additionalConfig file name.checkstyle/name content ![CDATA[fileset-config file-format-version=1.2.0 simple-config=true fileset name=all enabled=true check-config-name=acme corporate style local=false file-match-pattern match-pattern=. include-pattern=true/ /fileset filter name=NonSrcDirs enabled=true/ /fileset-config]] /content /file /additionalConfig /description Basically make use of the Additional config param of the eclipse-plugin On 11/10/06, Barrie Treloar [EMAIL PROTECTED] wrote: On 11/9/06, Rolf Strijdhorst [EMAIL PROTECTED] wrote: what do you need the .checkstyle file for. I mean eclipse finds it on its own. as soon as you include de builder and the nature. The .checkstyle file does not exist. It is automatically created when you go into the preference pages and turn on checkstyle. I am attempting to get eclipse:eclipse to automatically turn on checkstyle for me, I can get the natures and builders but the .checkstyle file also needs to be created by the eclipse:eclipse plugin or checkstyle does not work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
