Re: Multi-module goal execution order
Barrie Treloar wrote:
If module B depends upon A,
have you made sure that in module B's pom you declare the dependency
on the artifcats of A?
I suspect that you aren't.
Maven will calculate your dependncy graphy between modules and ensure
that they are built in the correct order.
So you randomly order your modules, like
moduleZ/module
moduleA/module
moduleG/module
moduleB/module
And if Z - G - B - A (where - indicate the project depends on the
on the one to the right) then the build order will be A, B, G, Z.
Hi Barry,
Yes my inter-module dependencies are correctly setup in my different POMs.
I did however discover that mvn clean install runs correctly but that only
when adding the site-deploy goal do things start going awry. Here is my
output:
---
D:\dev\eclipsews\x01\hid-parentmvn clean install site-deploy
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] hid-parent
[INFO] hid-core
[INFO] hid-test
[INFO] hid-user
[INFO] hid-activity
[INFO] hid-product
[INFO] hid-recording
[INFO] hid-web
[INFO]
[INFO] Building hid-parent
[INFO]task-segment: [clean, install, site-deploy]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] [cobertura:clean {execution: default}]
[INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
[INFO] Preparing cobertura:check
[WARNING] Removing: check from forked lifecycle, to prevent recursive
invocation.
[INFO] [cobertura:instrument {execution: default}]
[INFO] Not executing cobertura:instrument as the project is not a Java
classpath-capable package
[INFO] [cobertura:check {execution: default}]
[INFO] Not executing cobertura:instrument as the project is not a Java
classpath-capable package
[INFO] [install:install {execution: default-install}]
[INFO] Installing D:\dev\eclipsews\x01\hid-parent\pom.xml to
d:\m2-repo\com\x01\hid-parent\1.0-SNAPSHOT\hid-parent-1.0-SNAPSHOT.pom
[INFO] Preparing javadoc:test-javadoc
[INFO] No goals needed for project - skipping
[INFO] Preparing javadoc:test-aggregate
[INFO]
[INFO] Building hid-parent
[INFO]
[INFO] No goals needed for project - skipping
[INFO]
[INFO] Building hid-core
[INFO]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
D:\dev\eclipsews\x01\hid-core\src\main\resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] Building hid-test
[INFO]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 4 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] Building hid-user
[INFO]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
D:\dev\eclipsews\x01\hid-user\src\main\resources
[INFO] snapshot com.x01:hid-core:1.0-SNAPSHOT: checking for updates from
repo1.maven.org
[INFO] snapshot com.x01:hid-core:1.0-SNAPSHOT: checking for updates from
maven2-repository.dev.java.net
[INFO] snapshot com.x01:hid-core:1.0-SNAPSHOT: checking for updates from
jboss
Downloading:
http://repo1.maven.org/maven2/com/x01/hid-core/1.0-SNAPSHOT/hid-core-1.0-SNAPSHOT.jar
[INFO] Unable to find resource 'com.x01:hid-core:jar:1.0-SNAPSHOT' in
repository repo1.maven.org (http://repo1.maven.org/maven2)
Downloading:
http://download.java.net/maven/2//com/x01/hid-core/1.0-SNAPSHOT/hid-core-1.0-SNAPSHOT.jar
[INFO] Unable to find resource 'com.x01:hid-core:jar:1.0-SNAPSHOT' in
repository maven2-repository.dev.java.net
(http://download.java.net/maven/2/)
Downloading:
https://repository.jboss.org/nexus/content/groups/public//com/x01/hid-core/1.0-SNAPSHOT/hid-core-1.0-SNAPSHOT.jar
[INFO] Unable to find resource 'com.x01:hid-core:jar:1.0-SNAPSHOT' in
repository jboss (https://repository.jboss.org/nexus/content/groups/public/)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve
Re: Multi-module goal execution order
I seem to have run into http://jira.codehaus.org/browse/MJAVADOC-275 . I doubt the problem has been fixed contrary to what is specified in the ticket, I am running version 2.7 of the plugin. For now, the workaround seems to be to run mvn clean install javadoc:aggregate site-deploy instead of mvn clean install site-deploy. Thank you all! GB -- View this message in context: http://maven.40175.n5.nabble.com/Multi-module-goal-execution-order-tp2846098p2846574.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
Multi-module goal execution order
Hi guys, I'm sure this has been discussed before, but I can't seem to find anything related to this subject. I've been working for a while with Maven 2 now, but only with single-module projects. I am now working on a multi-module project with a flat structure and have stumbled on some interesting behaviour that I can't explain. Basically, running mvn clean install on the parent POM seems to be running the clean goal on every module, then the install goal on every module. This causes problems when building the project, since artifacts are not installed in the repository in an order that allows module changes to be visible to other dependent modules. Is this normal and how should I deal with this behaviour? I'm using Maven 2.2.1. Thanks, GB -- View this message in context: http://maven.40175.n5.nabble.com/Multi-module-goal-execution-order-tp2846098p2846098.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
Excluding JARs in WEB-INF/lib but not dependencies
Hi all, For our portlet projects, we are keeping JAR files in src/main/webapp/WEB-INF/lib under source control to ease up getting a new project to a workspace. In our Maven2 build, we want to be able to exclude these JARs from the final WAR artifact, but not the JAR dependencies. We've tried the warSourceExcludes approach but the final WAR file contains no JARs at all. Is there another way to do this? Thanks! GB -- View this message in context: http://www.nabble.com/Excluding-JARs-in-WEB-INF-lib-but-not-dependencies-tp15725520s177p15725520.html 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: RAD7 / Portal6 hot redeploy fails with Maven2 layout
Olivier Dehon-2 wrote: On Tue, 2008-02-12 at 11:35 -0800, Guillaume Bilodeau wrote: This question is mostly for the Eclipse plugin guys - sorry if this isn't the right place. We are developing a portal application using RAD7 and deploying it on IBM WebSphere Portal 6. It seems that after switching a project's directory structure to the Maven2 layout, hot deployment stopped working. I had the same issue. I had to upgrade to RAD 7.0.0.5, and move src/main/webapp to WebContent (with corresponding pom configuration) to keep RAD happy. -Olivier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'm already running 7.0.0.5. I've worked on this problem a little more: . I created a new portlet project using the RAD wizard and with the default project structure (src and WebContent). I deployed it and tested hot redeploy on both JSPs and classes: everything works. . I converted the structure piece by piece to the Maven2 structure. Once again, hot redeploy on both JSPs and classes works. . I tried converting an existing project to the Maven2 structure. Hot redeploy fails for both JSPs and class files with this project. A few interesting things: . Hot redeploy can work with a Maven2 directory structure. . The project created with the RAD wizard isn't deployed by copying files to the WPS profile or to a org.eclipse.wst.server.core temp directory. I'll post my further findings later. Cheers, GB -- View this message in context: http://www.nabble.com/RAD7---Portal6-hot-redeploy-fails-with-Maven2-layout-tp15441108s177p15481214.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RAD7 / Portal6 hot redeploy fails with Maven2 layout
Hi all, This question is mostly for the Eclipse plugin guys - sorry if this isn't the right place. We are developing a portal application using RAD7 and deploying it on IBM WebSphere Portal 6. It seems that after switching a project's directory structure to the Maven2 layout, hot deployment stopped working. Our RAD project configuration has been modified to use the Maven2 layout as follows: . the project's build path has 4 source folders, one each for src/main/java, src/main/resources, src/test/java, src/test/resources . each source folder has the proper output folder (target/classes for src/main/*, target/test-classes for src/test/*) . the .settings/org.eclipse.wst.common.component file has been updated so that the wb-resource elements' deploy-path attribute equals /WEB-INF/classes for the 4 source folders and / for src/main/webapp This works perfectly fine when working with classic web applications (not portlets). Are we missing something so that deployment works with this layout? Thanks a bunch, GB -- View this message in context: http://www.nabble.com/RAD7---Portal6-hot-redeploy-fails-with-Maven2-layout-tp15441108s177p15441108.html 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: 5 minute quickstart: The plugin 'org.apache.maven.plugins:maven-archetype-plugin' does not exist or no valid version could be found
Guillaume Bilodeau wrote: Wendy Smoak-3 wrote: On 8/17/07, Guillaume Bilodeau [EMAIL PROTECTED] wrote: I am behind no firewall, I have setup no mirrors - this is a clean install. It's obviously a network error as the SocketException shows. Actually, ibiblio.org has a hard time redirecting to mirrors.ibiblio.org - takes 1 or 2 minutes to do so in a web browser. Could this be the problem? If it's a completely clean install, it shouldn't be talking to ibiblio at all... the central repo is at repo1.maven.org/maven2 . Can you clarify whether this happens with an empty local repository? (I'm not sure if this is a fresh install of Maven, or a completely clean new machine.) Try deleting the local repository and/or adding -U to the command line. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] It's a fresh, clean install and the repository is empty. This was already executed with the -U -X options. Strange isn't it? Even stranger: running mvn -U install on a project with new dependencies works ONCE per day. After this successful run, the above message comes up again. Changing the system date has no effect whatsoever. Surely this must be a firewall issue - I should have mentioned that I am behind a firewall, but not behind a proxy. Is this possible? -- View this message in context: http://www.nabble.com/5-minute-quickstart%3A-The-plugin-%27org.apache.maven.plugins%3Amaven-archetype-plugin%27-does-not-exist-or-no-valid-version-could-be-found-tf4045296s177.html#a12313790 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: 5 minute quickstart: The plugin 'org.apache.maven.plugins:maven-archetype-plugin' does not exist or no valid version could be found
I'm getting a similar error while trying to setup Maven in a new environment: * + Error stacktraces are turned on. Maven version: 2.0.7 Java version: 1.6.0_02 OS name: windows xp version: 5.1 arch: x86 [DEBUG] Building Maven user-level plugin registry from: 'D:\Documents and Settings\T071543\.m2\plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: 'D:\maven-2.0.7\conf\plugin-registry.xml' [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins [INFO] org.apache.maven.plugins: checking for updates from central [WARNING] repository metadata for: 'org.apache.maven.plugins' could not be retrieved from repository: central due to an error: Error transferring file [INFO] Repository 'central' will be blacklisted [DEBUG] Exception org.apache.maven.wagon.TransferFailedException: Error transferring file at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:104) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:462) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:363) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolveAlways(DefaultRepositoryMetadataManager.java:364) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:97) at org.apache.maven.plugin.DefaultPluginMappingManager.loadPluginMappings(DefaultPluginMappingManager.java:103) at org.apache.maven.plugin.DefaultPluginMappingManager.loadPluginMappings(DefaultPluginMappingManager.java:87) at org.apache.maven.plugin.DefaultPluginMappingManager.getByPrefix(DefaultPluginMappingManager.java:61) at org.apache.maven.plugin.DefaultPluginManager.getPluginDefinitionForPrefix(DefaultPluginManager.java:149) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:386) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:138) 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:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read1(BufferedInputStream.java:258) at java.io.BufferedInputStream.read(BufferedInputStream.java:317) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:666) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:611) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:631) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1000) at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:83) ... 23 more [DEBUG] Loading plugin prefixes from group: org.codehaus.mojo [DEBUG] Skipping blacklisted repository central [DEBUG] Skipping blacklisted repository central [DEBUG] maven-archetype-plugin: using locally installed snapshot [DEBUG] Artifact not found - using stub model: Unable to determine the latest version org.apache.maven.plugins:maven-archetype-plugin:pom:LATEST [DEBUG] Using defaults for missing POM org.apache.maven.plugins:maven-archetype-plugin:pom:LATEST [DEBUG] maven-archetype-plugin: using locally installed snapshot [DEBUG] Artifact not found - using stub model: Unable to determine the release version org.apache.maven.plugins:maven-archetype-plugin:pom:RELEASE [DEBUG] Using defaults for missing POM org.apache.maven.plugins:maven-archetype-plugin:pom:RELEASE [INFO] [ERROR] BUILD ERROR [INFO]
Re: 5 minute quickstart: The plugin 'org.apache.maven.plugins:maven-archetype-plugin' does not exist or no valid version could be found
Wendy Smoak-3 wrote: On 8/17/07, Guillaume Bilodeau [EMAIL PROTECTED] wrote: I am behind no firewall, I have setup no mirrors - this is a clean install. It's obviously a network error as the SocketException shows. Actually, ibiblio.org has a hard time redirecting to mirrors.ibiblio.org - takes 1 or 2 minutes to do so in a web browser. Could this be the problem? If it's a completely clean install, it shouldn't be talking to ibiblio at all... the central repo is at repo1.maven.org/maven2 . Can you clarify whether this happens with an empty local repository? (I'm not sure if this is a fresh install of Maven, or a completely clean new machine.) Try deleting the local repository and/or adding -U to the command line. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] It's a fresh, clean install and the repository is empty. This was already executed with the -U -X options. Strange isn't it? -- View this message in context: http://www.nabble.com/5-minute-quickstart%3A-The-plugin-%27org.apache.maven.plugins%3Amaven-archetype-plugin%27-does-not-exist-or-no-valid-version-could-be-found-tf4045296s177.html#a12201808 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PMD error count?
Hi all, Sorry if this is a FAQ, but I honestly couldn't find any documentation on the subject. I was wondering if there was any way to include the total number of errors found by the PMD plugin in the generated report? The report itself is nice, and adding this information would make it easier to follow the progression in correcting errors. Thanks, GB -- View this message in context: http://www.nabble.com/PMD-error-count--tf2450289.html#a6829432 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: surefire and hibernate+spring
Problem solved. Solution is described here:
http://jroller.com/page/gbilodeau/?anchor=of_running_jpa_unit_tests1.
Guillaume Bilodeau wrote:
I am experiencing a similar problem when using entity beans in the form of
annotated classes: the tests run fine under Eclipse but fail under Maven
with the same Unknown entity message. A quick look at the Hibernate
logs shows that the entities are recognized under Eclipse but not under
Maven. Similarly, the problem seems to stem from the separation of main
classes and test classes in two distinct directories, which somehow
impacts Hibernate's class location algorithm.
Is there any way this can be avoided or, even better, solved?
Thanks,
GB
Jurgen Lust wrote:
Hi,
I'm having a problem run the unit tests for a hibernate and spring-based
application with the surefire plugin.
I'm using the xdoclet plugin to generate the hibernate mapping files,
and a spring LocalSessionFactoryBean to load
the mappings, like so:
The surefire plugin:
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.0/version !-- tried version 2.1.2 as well, to no
avail --
configuration
testFailureIgnoretrue/testFailureIgnore
forkModeonce/forkMode
includes
include**/*TestSuite.java/include
/includes
reportFormatxml/reportFormat
/configuration
/plugin
The xdoclet plugin:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdxdoclet-maven-plugin/artifactId
version1.0-alpha-2/version
executions
execution
phasegenerate-sources/phase
goals
goalxdoclet/goal
/goals
configuration
tasks
hibernatedoclet
excludedtags=@version,@author,@see,@todo
destDir=${project.build.outputDirectory}
fileset dir=${basedir}/src/main/java
include name=**/model/*.java/include
/fileset
hibernate destinationFile={0}.hbm.xml version=3.0
prefixWithPackageStructure=true/hibernate
/hibernatedoclet
/tasks
/configuration
/execution
/executions
/plugin
The resulting mapping files are in target/classes.
The spring.xml looks like this:
bean id=sessionFactory
class=org.springframework.orm.hibernate3.LocalSessionFactoryBean
property name=dataSource
ref bean=dataSource /
/property
property name=hibernateProperties
props
prop key=hibernate.dialect
${hibernate.dialect}
/prop
prop key=hibernate.connection.autocommit
${hibernate.connection.autocommit}
/prop
prop key=hibernate.hbm2ddl.auto
${hibernate.hbm2ddl.auto}
/prop
prop key=hibernate.show_sql
${hibernate.show_sql}
/prop
/props
/property
property name=mappingDirectoryLocations
list
valueclasspath:/value
/list
/property
/bean
So the LocalSessionFactoryBean searches the classpath for hbm.xml files.
Now my unit tests create a ClassPathXmlApplicationContext in the setUp()
method, using the above spring.xml file.
But when the unit tests try to access one of the persistent beans, I get
the error org.hibernate.MappingException: Unknown entity, which means
the hibernate mapping files could not be found in the classpath.
Looking at the classpath for the maven surefire plugin, I noticed that
both the target/classes and target/testClasses directories are in it
twice, which is strange but I doubt that this could be the cause...
After copying the generated hbm.xml files to src/test/resources, the
tests did not throw that Exception anymore.
I have also tried running the tests from an ant buildfile, and that
works as well.
Does anyone have an idea what could be going wrong here?
Kind regards,
Jurgen
--
Among flowers, the cherry blossom.
Among men, me.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/surefire-and-hibernate%2Bspring-tf1154206.html#a6320539
Sent from the Maven - Users forum at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: surefire and hibernate+spring
I am experiencing a similar problem when using entity beans in the form of
annotated classes: the tests run fine under Eclipse but fail under Maven
with the same Unknown entity message. A quick look at the Hibernate logs
shows that the entities are recognized under Eclipse but not under Maven.
Similarly, the problem seems to stem from the separation of main classes and
test classes in two distinct directories, which somehow impacts Hibernate's
class location algorithm.
Is there any way this can be avoided or, even better, solved?
Thanks,
GB
Jurgen Lust wrote:
Hi,
I'm having a problem run the unit tests for a hibernate and spring-based
application with the surefire plugin.
I'm using the xdoclet plugin to generate the hibernate mapping files,
and a spring LocalSessionFactoryBean to load
the mappings, like so:
The surefire plugin:
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.0/version !-- tried version 2.1.2 as well, to no
avail --
configuration
testFailureIgnoretrue/testFailureIgnore
forkModeonce/forkMode
includes
include**/*TestSuite.java/include
/includes
reportFormatxml/reportFormat
/configuration
/plugin
The xdoclet plugin:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdxdoclet-maven-plugin/artifactId
version1.0-alpha-2/version
executions
execution
phasegenerate-sources/phase
goals
goalxdoclet/goal
/goals
configuration
tasks
hibernatedoclet
excludedtags=@version,@author,@see,@todo
destDir=${project.build.outputDirectory}
fileset dir=${basedir}/src/main/java
include name=**/model/*.java/include
/fileset
hibernate destinationFile={0}.hbm.xml version=3.0
prefixWithPackageStructure=true/hibernate
/hibernatedoclet
/tasks
/configuration
/execution
/executions
/plugin
The resulting mapping files are in target/classes.
The spring.xml looks like this:
bean id=sessionFactory
class=org.springframework.orm.hibernate3.LocalSessionFactoryBean
property name=dataSource
ref bean=dataSource /
/property
property name=hibernateProperties
props
prop key=hibernate.dialect
${hibernate.dialect}
/prop
prop key=hibernate.connection.autocommit
${hibernate.connection.autocommit}
/prop
prop key=hibernate.hbm2ddl.auto
${hibernate.hbm2ddl.auto}
/prop
prop key=hibernate.show_sql
${hibernate.show_sql}
/prop
/props
/property
property name=mappingDirectoryLocations
list
valueclasspath:/value
/list
/property
/bean
So the LocalSessionFactoryBean searches the classpath for hbm.xml files.
Now my unit tests create a ClassPathXmlApplicationContext in the setUp()
method, using the above spring.xml file.
But when the unit tests try to access one of the persistent beans, I get
the error org.hibernate.MappingException: Unknown entity, which means
the hibernate mapping files could not be found in the classpath.
Looking at the classpath for the maven surefire plugin, I noticed that
both the target/classes and target/testClasses directories are in it
twice, which is strange but I doubt that this could be the cause...
After copying the generated hbm.xml files to src/test/resources, the
tests did not throw that Exception anymore.
I have also tried running the tests from an ant buildfile, and that
works as well.
Does anyone have an idea what could be going wrong here?
Kind regards,
Jurgen
--
Among flowers, the cherry blossom.
Among men, me.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/surefire-and-hibernate%2Bspring-tf1154206.html#a6285590
Sent from the Maven - Users forum at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-cobertura-plugin upgraded to cobertura 1.8 - (Was: Re: Cobertu
This is great news, thanks for the update! Any idea when version 2.1 will be available through iBiblio? I can't seem to find the snapshot release. Cheers, GB Joakim Erdfelt-2 wrote: Funny that this should come up. I just committed MCOBERTURA-46 (Upgrade to cobertura 1.8) just a minute ago. There is a bug in the datafile location setting ability in cobertura 1.8 I have arranged a patch on the cobertura side, but need help from other interested parties to get it commited into the cobertura codebase. See: https://sourceforge.net/tracker/index.php?func=detailaid=1543280group_id=130558atid=720017 - Joakim Erdfelt Wayne Fay wrote: This can only happen with a new cobertura-maven-plugin release, which is up to the owners of the c-m-p plugin. You will probably need to speak with them directly to find out when they plan a new release of this plugin, etc. Wayne On 8/22/06, Guillaume Bilodeau [EMAIL PROTECTED] wrote: Jimisola Laursen wrote: Hi! Not sure who is responsible, but I've been trying to make cobertura-maven-plugin use cobertura 1.8 instead of 1.7 due to problems with AspectJ. In the process of this I get the error below and it looks as if the deployed cobertura 1.8 contains errors. Not sure of who can fix this I post this here. Regardsm Jimisola [WARNING] POM for 'cobertura:cobertura:pom:1.8:runtime' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: expected START_TA G or END_TAG not TEXT (position: TEXT seen .../version\r\n urlhttp://asm.objectweb.org/... @12:38) [DEBUG] Reason: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen .../version\r\n urlhttp://asm.objectweb.org/... @12 :38) About the fact that the cobertura-maven-plugin still uses Cobertura 1.7 and not 1.8: will this be fixed eventually? I'm running into the same problems with AspectJ here. Of course I could just update our local POM files, but I would prefer the cleaner solution :) Cheers, GB -- View this message in context: http://www.nabble.com/Cobertura-1.8-pom-%28on-ibiblio%29-contains-errors-and-is-invalid-tf2058878.html#a5921143 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Cobertura-1.8-pom-%28on-ibiblio%29-contains-errors-and-is-invalid-tf2058878.html#a5941527 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cobertura 1.8 pom (on ibiblio) contains errors and is invalid
Jimisola Laursen wrote: Hi! Not sure who is responsible, but I've been trying to make cobertura-maven-plugin use cobertura 1.8 instead of 1.7 due to problems with AspectJ. In the process of this I get the error below and it looks as if the deployed cobertura 1.8 contains errors. Not sure of who can fix this I post this here. Regardsm Jimisola [WARNING] POM for 'cobertura:cobertura:pom:1.8:runtime' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: expected START_TA G or END_TAG not TEXT (position: TEXT seen .../version\r\n urlhttp://asm.objectweb.org/... @12:38) [DEBUG] Reason: Parse error reading POM. Reason: expected START_TAG or END_TAG not TEXT (position: TEXT seen .../version\r\n urlhttp://asm.objectweb.org/... @12 :38) About the fact that the cobertura-maven-plugin still uses Cobertura 1.7 and not 1.8: will this be fixed eventually? I'm running into the same problems with AspectJ here. Of course I could just update our local POM files, but I would prefer the cleaner solution :) Cheers, GB -- View this message in context: http://www.nabble.com/Cobertura-1.8-pom-%28on-ibiblio%29-contains-errors-and-is-invalid-tf2058878.html#a5921143 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cobertura plugin using version 1.7
Hi all, It seems to me that the current M2 Cobertura plugin is still using the 1.7 runtime, when a 1.8 runtime was released back in April. Are there any plans to switch to the latest version any time soon? Thanks, GB
AspectJ compiler with Java 1.3
Hi all, I'm asking for your help once again. Our projects are currently compiled using Java 1.3 through a Maven 2.0.4 build. We want to add some aspects (through the new Spring 2.0 tags) and we need to switch to the AspectJ compiler, while still using the Java 1.3 classes as a reference (to avoid using APIs introduced in 1.4+). I've read the plugin documentation and it seems like the only thing we can do is to use the source and target configuration options, which is not sufficient. Did anyone do anything similar? Thanks, GB
Re: AspectJ compiler with Java 1.3
Yes, this is exactly what I want, but with the AspectJ compiler. The original pom.xml was using the configuration described in this page and was working great - but now we need (want?) to add aspects to the mix. Can this be done? Thanks, GB - Original Message From: Carlos Sanchez [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Wednesday, June 28, 2006 3:28:25 PM Subject: Re: AspectJ compiler with Java 1.3 I think he's talking about compiling to a different tools.jar, http://maven.apache.org/plugins/maven-compiler-plugin/howto.html On 6/28/06, Kaare Nilsen [EMAIL PROTECTED] wrote: On 28/06/06, Guillaume Bilodeau [EMAIL PROTECTED] wrote: Hi all, I'm asking for your help once again. Our projects are currently compiled using Java 1.3 through a Maven 2.0.4 build. We want to add some aspects (through the new Spring 2.0 tags) and we need to switch to the AspectJ compiler, while still using the Java 1.3 classes as a reference (to avoid using APIs introduced in 1.4+). I've read the plugin documentation and it seems like the only thing we can do is to use the source and target configuration options, which is not sufficient. Why is that ? When setting the source and the target to 1.3 or the complianceLevel option to 1.3 (shorthand which sets -source to 1.3 and -target 1.1). This should do the trick, and if it does not, it is a bug. Could you then please send me a testproject that will trigger it ? Did anyone do anything similar? Thanks, GB - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AspectJ compiler with Java 1.3
For example, one class in our project implements java.sql.Connection. A method was added to this interface in Java 1.4 (or 5.0?) and so compiling this class with -source 1.3 and -target 1.3 gives the following error: D:\dev\workspace\promo-head\server\src\main\java\promo\util\xsql\XConnection.java:[19,7] promo.util.xsql.XConnection is not abstract and does not override abstract method prepareStatement(java.lang.String,java.lang.String[]) in java.sql.Connection There are similar errors, all related to the java.sql and javax.sql interfaces. I've read that it's a question of changing the boot classpath, but I could be mistaken. Thanks, GB - Original Message From: Kaare Nilsen [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Wednesday, June 28, 2006 3:11:33 PM Subject: Re: AspectJ compiler with Java 1.3 On 28/06/06, Guillaume Bilodeau [EMAIL PROTECTED] wrote: Hi all, I'm asking for your help once again. Our projects are currently compiled using Java 1.3 through a Maven 2.0.4 build. We want to add some aspects (through the new Spring 2.0 tags) and we need to switch to the AspectJ compiler, while still using the Java 1.3 classes as a reference (to avoid using APIs introduced in 1.4+). I've read the plugin documentation and it seems like the only thing we can do is to use the source and target configuration options, which is not sufficient. Why is that ? When setting the source and the target to 1.3 or the complianceLevel option to 1.3 (shorthand which sets -source to 1.3 and -target 1.1). This should do the trick, and if it does not, it is a bug. Could you then please send me a testproject that will trigger it ? Did anyone do anything similar? Thanks, GB
Re: AspectJ compiler with Java 1.3
Well, it's not the tools.jar that needs to be replaced, it's more the rt.jar.
If I'm correct, tools.jar contains Sun-specific classes (not available in other
JVMs) and rt.jar contains the official JDK classes.
I've seen that the ajc compiler can use a bootclasspath parameter in its
standalone form. Can this parameter be sent through the plugin?
Thanks again for your answers,
GB
- Original Message
From: Kaare Nilsen [EMAIL PROTECTED]
To: Maven Users List users@maven.apache.org
Sent: Wednesday, June 28, 2006 4:50:08 PM
Subject: Re: AspectJ compiler with Java 1.3
On 28/06/06, Guillaume Bilodeau [EMAIL PROTECTED] wrote:
Yes, this is exactly what I want, but with the AspectJ compiler. The
original pom.xml was using the configuration described in this page and was
working great - but now we need (want?) to add aspects to the mix. Can this
be done?
Thanks,
GB
the tools.jar dependency is defined as this in the plugin. so I would
suspect that is not easy to change the tools. jar used by the ajc
compiler without cutting a new release of the plugin.
But correct me if I am wrong.
[from aspectj plugin pom.xml]
...
dependencies
dependency
groupIdcom.sun/groupId
artifactIdtools/artifactId
version1.4.2/version
scopesystem/scope
systemPath${java.home}/../lib/tools.jar/systemPath
/dependency
/dependencies
...
[end]
- Original Message
From: Carlos Sanchez [EMAIL PROTECTED]
To: Maven Users List users@maven.apache.org
Sent: Wednesday, June 28, 2006 3:28:25 PM
Subject: Re: AspectJ compiler with Java 1.3
I think he's talking about compiling to a different tools.jar,
http://maven.apache.org/plugins/maven-compiler-plugin/howto.html
On 6/28/06, Kaare Nilsen [EMAIL PROTECTED] wrote:
On 28/06/06, Guillaume Bilodeau [EMAIL PROTECTED] wrote:
Hi all,
I'm asking for your help once again. Our projects are currently compiled
using Java 1.3 through a Maven 2.0.4 build. We want to add some aspects
(through the new Spring 2.0 tags) and we need to switch to the AspectJ
compiler, while still using the Java 1.3 classes as a reference (to avoid
using APIs introduced in 1.4+). I've read the plugin documentation and
it seems like the only thing we can do is to use the source and target
configuration options, which is not sufficient.
Why is that ?
When setting the source and the target to 1.3 or the complianceLevel
option to 1.3 (shorthand which sets -source to 1.3 and -target 1.1).
This should do the trick, and if it does not, it is a bug. Could you
then please send me a testproject that will trigger it ?
Did anyone do anything similar?
Thanks,
GB
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
-
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]
Running unit tests using a different JDK?
Hi all, I'm running Maven 2.0.4 on JDK 5.0. The project we're building is targeted for JDK 1.3 so we configured Maven to compile using the JDK 1.3 compiler. However, we still haven't found how to run the unit tests using the same 1.3 JDK. Is there any way to do this? Thanks, GB - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[M2] Date + time in snapshot version number?
Hi all, We're using Luntbuild as the continuous integration system for my projects and Maven 2.0.4 as the build system. We have 3 projects: p1, p2 and core, with p1 and p2 both depending on core. All 3 are currently in development and so are labeled as snapshots, with p1 and p2 declaring core-2.0.0-SNAPSHOT as a dependency. As everything is configured right now, the generated artifacts are named [projectName]-[versionNumber]-SNAPSHOT.jar and then installed to our local repository. We would like the artifacts to be named [projectName]-[versionNumber]-SNAPSHOT-[deployDateAndTime].jar. Is there a way to do this, without having to mess too much with the dependencies? Thanks again, GB
Re: [M2] Identifying projects and modules
I tried using the generateClient configuration parameter but I'm not getting the results I expected. The build generated a huge JAR file (system2-ejb-1.0-client.jar) which contains pretty much every class that's already in the system2-ejb-1.0.jar, not only the interfaces. Am I missing something here? Ideally I would like to have a simple JAR file with only the EJB home and remote interfaces. Thanks, GB - Original Message From: John Casey [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Tuesday, June 6, 2006 7:09:46 PM Subject: Re: [M2] Identifying projects and modules Actually, I believe you could simply turn system2 into a single project, and specify it's packaging as 'ejb'. The ejb plugin has an option for generating an ejb-client jar file, which you could then use in the dependency set of the system1 project. You might want to take a peek at http://maven.apache.org/plugins/maven-ejb-plugin/ejb-mojo.html for more information. I think you'd be looking for the 'generateClient' configuration parameter for that mojo. Other than that, and with what little information I have about the system, it seems like a sane design. HTH, -john On 6/6/06, Guillaume Bilodeau [EMAIL PROTECTED] wrote: Hi all, I have inherited two projects which I will be managing using Maven 2.0. Both are Java EE-based, the first one sometimes talking to the second one using stateless session beans. Both also should be sharing a large code base but currently are not, so there's a lot of duplication. I'm wondering how I should distribute these projects into M2 projects and modules. Right now I'm leaning towards having 4 projects: system1, system2, system2-api and core. The first two are self-explanatory, system2-api would contain the EJB interfaces required by system1 and implemented by system2, and core would eventually contain the result of refactoring the duplicated code. The first two projects would depend on the last two, and system2-api would depend on core. Is this a correct approach or is there a better approach that I'm not seeing? Cheers, GB PS: To the person who answered me last time: thanks! My problem was solved, but I couldn't find back the original message to confirm that and thank you.
[M2] Identifying projects and modules
Hi all, I have inherited two projects which I will be managing using Maven 2.0. Both are Java EE-based, the first one sometimes talking to the second one using stateless session beans. Both also should be sharing a large code base but currently are not, so there's a lot of duplication. I'm wondering how I should distribute these projects into M2 projects and modules. Right now I'm leaning towards having 4 projects: system1, system2, system2-api and core. The first two are self-explanatory, system2-api would contain the EJB interfaces required by system1 and implemented by system2, and core would eventually contain the result of refactoring the duplicated code. The first two projects would depend on the last two, and system2-api would depend on core. Is this a correct approach or is there a better approach that I'm not seeing? Cheers, GB PS: To the person who answered me last time: thanks! My problem was solved, but I couldn't find back the original message to confirm that and thank you.
Re: POM file in Repository
Add the -DgeneratePom=true to your command and a local POM will be generated. This should stop the systematic lookup on new builds. Cheers, GB Guillaume Bilodeau [EMAIL PROTECTED] Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. - Albert Einstein - Original Message From: cristal [EMAIL PROTECTED] To: users@maven.apache.org Sent: Monday, June 5, 2006 7:11:54 PM Subject: POM file in Repository We have a few 3rd-party jar files that are not in central repository, e.g. ibiblio.org. So we had to manually install them to our local repository using the following command. mvn install:install-file -Dfile=path-to-file -DgroupId=group-id \ -DartifactId=artifact-id -Dversion=version -Dpackaging=packaging However, this command only installs the jar file into the local repository. So what happens is - whenever I started my maven build, it always tries to retrieve the corresponding pom file for each of the 3rd-party jar files from central repository, which of course are not there. So the warning message always displayed like this: [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) It's quite annoying. It's annoying not because of the message itself, it's because it slows down my build process. I don't want it to go to central repository to retrieve something that I know is not there. I only need the jar file and it's already in my local repository. why it always tries to retrieve the pom file from central? Is there a way to disable this??? Please advise. Thanks. -- View this message in context: http://www.nabble.com/POM-file-in-Repository-t1735732.html#a4716428 Sent from the Maven - Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
M2 - Including custom application.xml in EAR file
Hi all, Since Maven 2.0 doesn't support application.xml generation for the J2EE 1.2 specification (I understand, this is 2006 after all), I'm trying to include a custom-built application.xml file in my EAR but with no success. I'm using a project with multiple modules following a flat directory structure. The EAR module contains both pom.xml file and application.xml (custom-built) files. Executing mvn package produces the following error message: [INFO] Including custom application.xml[application.xml] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error copying EAR sources Embedded error: File application.xml does not exist My pom.xml in the EAR project contains the following configuration: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId configuration applicationXmlapplication.xml/applicationXml /configuration /plugin /plugins /build What am I doing wrong? Where should I place my application.xml file, and using what path should I reference it in the pom.xml? Is this at all necessary - is there support for the 1.2 spec now? Thanks a bunch, GB
