Re: Where to put context.xml in webapp archetype ?
there is one misconception: the project *is not built with* Maven Webapp Archetype, but it *was generated from* Maven Webapp Archetype Once a project is generated from a Maven Archetype, it is a normal project, you can forget about its inception: the whole generated content is yours, to be maintained as if you wrote everything by hand I don't precisely know what is generated by Maven Webapp Archetype, I suppose it uses maven-war-plugin [1] Regards, Hervé [1] http://maven.apache.org/plugins/maven-war-plugin/usage.html - Mail original - De: Sreyan Chakravarty sreyan.mail...@gmail.com À: Maven Users List users@maven.apache.org Envoyé: Vendredi 7 Août 2015 21:24:25 Objet: Where to put context.xml in webapp archetype ? I am using Maven for building a simple webapp that uses JDBC connection pooling along with Hibernate. I am using the Maven Webapp Archetype to build the project. Where do I put context.xml and persistence.xml that I normally put under META-INF in a normal dynamic web project. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Facing problem whith Maven for Portals-pom 1.4
Hi, are you behind a corporate firewall / proxy ? Furthermore have you correctly configured your nexus? Have you tried to get the pom via browser / curl ? https://repo.maven.apache.org/maven2/org/apache/portals/portals-pom/1.4/portals-pom-1.4.pom Have you tried the following url as central URL: https://repo1.maven.org/maven2/ Kind regards Karl Heinz Marbaise PS.: Please use the users list for such questionsand not dev list... On 8/7/15 8:11 PM, Lalitha Bourishetty wrote: Hi Team, When I tried to build Jetspeed 2.3 source code with maven 3.3.1 , got below error: Downloading: https://repo.maven.apache.org/maven2/org/apache/portals/portals-pom/1.4/portals-pom-1.4.pom [ERROR] [ERROR] Some problems were encountered while processing the POMs: [FATAL] Non-resolvable parent POM for org.apache.portals.jetspeed-2:jetspeed-2:2.3.0: Could not transfer artifact org.apache.portals:portals-pom:pom:1.4 from/to central (https://repo.maven.apache.org/maven2): Connect to repo.maven.apache.org:443 [repo.maven.apache.org/23.235.40.215] failed: Connection timed out: connec t and 'parent.relativePath' points at wrong local POM @ line 28, column 11 @ [ERROR] The build could not read 1 project - [Help 1] org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs: [FATAL] Non-resolvable parent POM for org.apache.portals.jetspeed-2:jetspeed-2:2.3.0: Could not transfer artifact org.apache.portals:portals-pom:pom:1.4 from/to central (https://repo.maven.apache.org/maven2): Connect to repo.maven.apache.org:443 [repo.maven.apache.org/23.235.40.215] failed: Connection timed out: connec t and 'parent.relativePath' points at wrong local POM @ line 28, column 11 I thought it might be problem with proxy and made all required settings in settings.xml (settings like proxy etc.) Even after configuring proxy got same error. I tried to do using Maven repository server I went with Nexus. When Tried with nexus got below exception: When I tried with Nexus, I am facing below error: org.apache.http.conn.ConnectTimeoutException: Connect to repo1.maven.org:443 [repo1.maven.org/23.235.44.209] failed: connect timed out jvm 1| at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:134) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:319) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57) ~[httpclient-4.3.6.jar:4.3.6] jvm 1| at org.sonatype.nexus.plugins.rrb.MavenRepositoryReader.getContent(MavenRepositoryReader.java:231) [nexus-rrb-plugin-2.11.4-01/:na] jvm 1| at org.sonatype.nexus.plugins.rrb.MavenRepositoryReader.extract(MavenRepositoryReader.java:101) [nexus-rrb-plugin-2.11.4-01/:na] jvm 1| at org.sonatype.nexus.plugins.rrb.RemoteBrowserResource.get(RemoteBrowserResource.java:138) [nexus-rrb-plugin-2.11.4-01/:na] jvm 1| at org.sonatype.plexus.rest.resource.RestletResource.represent(RestletResource.java:233) [nexus-restlet1x-plugin-2.11.4-01/:na] jvm 1| at org.sonatype.nexus.rest.NexusRestletResource.represent(NexusRestletResource.java:39) [nexus-restlet1x-plugin-2.11.4-01/:na] jvm 1| at org.restlet.resource.Resource.getRepresentation(Resource.java:302) [nexus-restlet1x-plugin-2.11.4-01/:na] jvm 1| at org.restlet.resource.Resource.handleGet(Resource.java:464) [nexus-restlet1x-plugin-2.11.4-01/:na] jvm 1| at org.restlet.Finder.handle(Finder.java:353) [nexus-restlet1x-plugin-2.11.4-01/:na] jvm 1| at org.restlet.Filter.doHandle(Filter.java:150) [nexus-restlet1x-plugin-2.11.4-01/:na] jvm 1| at
Re: Where to put context.xml in webapp archetype ?
src/main/resources/META-INF/persistence.xml src/main/webapp/WEB-INF/context.xml On Fri, Aug 7, 2015 at 3:24 PM, Sreyan Chakravarty sreyan.mail...@gmail.com wrote: I am using Maven for building a simple webapp that uses JDBC connection pooling along with Hibernate. I am using the Maven Webapp Archetype to build the project. Where do I put context.xml and persistence.xml that I normally put under META-INF in a normal dynamic web project. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Where to put context.xml in webapp archetype ?
Thanks On Sat, Aug 8, 2015 at 4:05 PM, jieryn jie...@gmail.com wrote: src/main/resources/META-INF/persistence.xml src/main/webapp/WEB-INF/context.xml On Fri, Aug 7, 2015 at 3:24 PM, Sreyan Chakravarty sreyan.mail...@gmail.com wrote: I am using Maven for building a simple webapp that uses JDBC connection pooling along with Hibernate. I am using the Maven Webapp Archetype to build the project. Where do I put context.xml and persistence.xml that I normally put under META-INF in a normal dynamic web project. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Where to put context.xml in webapp archetype ?
I personally find this a bit weird, but it's because the JPA persistence.xml needs to end up in war!WEB-INF/classes/META-INF/persistence.xml whereas Tomcat will expect to find context.xml in war!WEB-INF/context.xml. I suppose you could put it in src/main/webapp/WEB-INF/classes/META-INF/persistence.xml but then IDEs will probably not find it easily/at all. Glad it works for you. On Sat, Aug 8, 2015 at 8:47 AM, Sreyan Chakravarty sreyan.mail...@gmail.com wrote: Thanks On Sat, Aug 8, 2015 at 4:05 PM, jieryn jie...@gmail.com wrote: src/main/resources/META-INF/persistence.xml src/main/webapp/WEB-INF/context.xml On Fri, Aug 7, 2015 at 3:24 PM, Sreyan Chakravarty sreyan.mail...@gmail.com wrote: I am using Maven for building a simple webapp that uses JDBC connection pooling along with Hibernate. I am using the Maven Webapp Archetype to build the project. Where do I put context.xml and persistence.xml that I normally put under META-INF in a normal dynamic web project. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Plugin Configuration params take precedence over CLI Arguments?
When you don't specify the value in the POM you are *effectively*[1]
specifying demoName${demoName}/demoName
So what you have done is disabled configuration via the CLI.
[1] I say *effectively* because if you did configure that and the property
was undefined then that explicit configuration would evaluate to the
literal string ${demoName} so this is more of a special case handling where
it is demoName${demoName}/demoName if there is a property called
demoName and demoName / if there isn't
On 7 August 2015 at 19:55, Daniel Johnson (danijoh2) danij...@cisco.com
wrote:
Hi,
I am facing an issue I really did not expect, where a plugins
configuration parameters in the POM take precedence over CLI
–Dparam=value parameter values.
My plugin takes a string parameter:
@Mojo(name = showValue, requiresProject = true, aggregator = true,
defaultPhase = LifecyclePhase.PACKAGE, threadSafe = true)
public class DemoMojo extends AbstractMojo {
/**
* The name of the property to print
*/
@Parameter(property=“demoName”)
private String demoName;
public void execute() throws MojoExecutionException,
MojoFailureException {
if (StringUtils.isEmpty(demoName)) {
getLog().info(demo-plugin: demoName variable was not given.);
} else {
getLog().info(demo-plugin: + demoName);
}
}
}
So far this works as I expect:
project xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd; xmlns=
http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
modelVersion4.0.0/modelVersion
groupIdcom.danijoh2.project/groupId
artifactIdsample/artifactId
version1.0.0-SNAPSHOT/version
build
plugins
plugin
groupIdcom.danijoh2/groupId
artifactIddemo-plugin/artifactId
version1.0.0-SNAPSHOT/version
executions
execution
iddemo/id
goals
goalshowValue/goal
/goals
/execution
/executions
/plugin
/plugins
/build
/project
DANIJOH2-M-V0MA:Desktop danijoh2$ mvn clean install
[INFO]
[INFO] Building sample 1.0.0-SNAPSHOT
...
[INFO] --- demo-plugin:1.0.0-SNAPSHOT:showValue (default-cli) @ sample ---
[INFO] demo-plugin: demoName variable was not given.
And if I pass the parameter I see it is accepted:
DANIJOH2-M-V0MA:Desktop danijoh2$ mvn clean install –DdemoName=cliParam
[INFO]
[INFO] Building sample 1.0.0-SNAPSHOT
...
[INFO] --- demo-plugin:1.0.0-SNAPSHOT:showValue (default-cli) @ sample ---
[INFO] demo-plugin: cliParam
However, if I specify the parameter in the POM, I no longer see the CLI
value being used:
plugin
groupIdcom.danijoh2/groupId
artifactIddemo-plugin/artifactId
version1.0.0-SNAPSHOT/version
configuration
demoNamepomParam/demoName
/configuration
…
/plugin
DANIJOH2-M-V0MA:Desktop danijoh2$ mvn clean install –DdemoName=cliParam
[INFO]
[INFO] Building sample 1.0.0-SNAPSHOT
...
[INFO] --- demo-plugin:1.0.0-SNAPSHOT:showValue (default-cli) @ sample ---
[INFO] demo-plugin: pomParam
Shouldn’t the CLI parameter value override any value in the POM?
Thanks,
Daniel
Automatically appended artifactId in inherited SCM element
Hello. I'm trying to reduce the redundancy of my existing POM files with inheritance. I've run into an issue with the generated sites. The parent pom: http://waste.io7m.com/2015/08/08/jnull.pom A submodule pom: http://waste.io7m.com/2015/08/08/jnull-core.pom The deployed site, note the correct URI for the source repository (not actually uploaded to GitHub yet): http://waste.io7m.com/2015/08/08/staging/source-repository.html Now note the incorrect URI in the submodule, because something is appending the artifactId: http://waste.io7m.com/2015/08/08/staging/io7m-jnull-core/source-repository.html Obviously, noone can clone the latter URI, as that's not how GitHub is arranged. I don't want to have to redefine the SCM element in all of the modules. Any idea what's at fault here? How can I fix it? M - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Automatically appended artifactId in inherited SCM element
Hi,
On 8/8/15 6:04 PM, org.apache.maven.u...@io7m.com wrote:
Hello.
I'm trying to reduce the redundancy of my existing POM files with
inheritance. I've run into an issue with the generated sites.
The parent pom:
http://waste.io7m.com/2015/08/08/jnull.pom
A submodule pom:
http://waste.io7m.com/2015/08/08/jnull-core.pom
The deployed site, note the correct URI for the source repository (not
actually uploaded to GitHub yet):
The first thing which i saw where the wrong SCM connections given:
scm
urlhttp://github.com/io7m/jnull/url
connectionscm:git:git://github.com/io7m/jnull/connection
developerConnectionscm:git:git://github.com/io7m/jnull/developerConnection
/scm
But they should like this:
scm
urlhttp://github.com/io7m/jnull/url
connectionscm:git:git://github.com/io7m/jnull.git/connection
developerConnectionscm:git:git://github.com/io7m/jnull.git/developerConnection
/scm
Apart from that it would be helpfull to know which Maven version you are
using? How have you Maven called to generate the site ?
http://waste.io7m.com/2015/08/08/staging/source-repository.html
I have taken a look at the two pom (parent)...
The first thing i stumbled over was the ssh-extension you are defining?
So are you really trying to deploy via ssh your maven artifacts? Apart
from that why are you using such an old version? There are newer
versions available: http://maven.apache.org/wagon/
Furthermore i have seen that you define plugins in your parent like this:
build
plugins
!-- Plugin versions --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-clean-plugin/artifactId
version2.6.1/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-deploy-plugin/artifactId
version2.8.2/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-install-plugin/artifactId
version2.5.2/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
version2.7/version
/plugin
/plugins
Which should be done like this:
build
pluginManagement
plugins
plugin..
/plugin...
/plugins
/pluginManagement
/build
which brings me to the next point you have defined the
maven-compiler-plugin in your jnull-core module like this:
build
plugins
!-- Require JDK = 1.6 --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version3.3/version
configuration
source1.6/source
target1.6/target
/configuration
/plugin
So this should be done in the parent by this:
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version3.3/version
configuration
source1.6/source
target1.6/target
/configuration
/plugin
/plugins
/pluginManagement
/build
And then you can remove the definition of this in every submodule...
Also the definition of maven-jar-plugin which you did in the submodule
(jnull-core):
!-- Produce custom manifest in jar files --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
version2.6/version
configuration
archive
manifestEntries
Specification-Title${project.name}/Specification-Title
Specification-Version${project.version}/Specification-Version
Specification-Vendorio7m.com/Specification-Vendor
Implementation-Title${project.name}/Implementation-Title
Implementation-Version${project.version}/Implementation-Version
Implementation-Vendorio7m.com/Implementation-Vendor
Implementation-Vendor-Id${project.groupId}/Implementation-Vendor-Id
Built-Byio7m/Built-By
Sealedtrue/Sealed
/manifestEntries
/archive
/configuration
/plugin
Should be done only in the parent only once within the pluginManagement
block...Furthermore if i correctly see you define the manifiest with
default entries which can be simplyfied by using this:
!-- Produce custom manifest in jar files --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
version2.6/version
configuration
archive
addDefaultImplementationEntriestrue/addDefaultImplementationEntries
addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries
/archive
/configuration
/plugin
See the docs of the archiver:
http://maven.apache.org/shared/maven-archiver/index.html which is
referenced from the doc site of the maven-jar-plugin:
Re: Automatically appended artifactId in inherited SCM element
On 2015-08-08T20:20:25 +0200 Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, Hello! The first thing which i saw where the wrong SCM connections given: Corrected. I've actually switched to the https URIs, as those allow anonymous cloning and authenticated pushes. Apart from that it would be helpfull to know which Maven version you are using? How have you Maven called to generate the site ? Apache Maven 3.3.3 (NON-CANONICAL_2015-07-27T12:38:38_root; 2015-07-27T09:38:38+00:00) Maven home: /opt/maven Java version: 1.8.0_45, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-openjdk/jre Default locale: en_GB, platform encoding: UTF-8 OS name: linux, version: 4.0.7-2-arch, arch: amd64, family: unix According to rfscholte in the Freenode IRC channel, I'm running into this known issue: https://issues.apache.org/jira/browse/MPIR-234 I've applied the workaround until it's fixed. The first thing i stumbled over was the ssh-extension you are defining? So are you really trying to deploy via ssh your maven artifacts? Apart from that why are you using such an old version? There are newer versions available: http://maven.apache.org/wagon/ Right. I'm actually now just updating this project, which hasn't had any kind of build updates since early 2012. I am deploying maven artifacts to a privately hosted server over ssh, in addition to deploying to Maven Central. I've not found a way to avoid including that extension in the POM file without having to edit the Maven super POM (changes to which will obviously be wiped out every time I upgrade the OS package). I'm using an old version simply because I haven't yet updated, and nothing told me it was out of date. Furthermore i have seen that you define plugins in your parent like this: ... Which should be done like this: Fixed, thanks. which brings me to the next point you have defined the maven-compiler-plugin in your jnull-core module like this: ... OK. And then you can remove the definition of this in every submodule... Also the definition of maven-jar-plugin which you did in the submodule (jnull-core): ... Should be done only in the parent only once within the pluginManagement block... OK. See the docs of the archiver: http://maven.apache.org/shared/maven-archiver/index.html which is referenced from the doc site of the maven-jar-plugin: https://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html I have seen also that you define the maven-sources-plugin in your core module like this: Apart from the manifest part as mentioned for the maven-jar-plugin you have defined explicit executions with binding to life cycle which is not neccessary cause maven-sources-plugin is already bound to the life cycleAnd you should prevent using the goal 'jar' cause it will fork the life cycle...Are you sure making source packages of your test code ? I'm not sure what you mean here. I agree about the forking and didn't actually realize I was still using those goals here (I switched to the non-forking variants on my other projects and apparently missed this one). I'm not sure what you mean by Are you sure making source packages of your test code?. I have always distributed four jars per module in each of my projects: The sources jar, the compiled code jar, the javadoc jar, and the test-sources jar. So i can give you a hint to read this: http://blog.soebes.de/blog/2015/04/04/maven-prerequisites/ Right, I had no idea it was deprecated. I think it originally went in because the versions plugin nagged me if I didn't use one. M - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Automatically appended artifactId in inherited SCM element
On 2015-08-08T20:20:25 +0200 Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, Hello! The first thing which i saw where the wrong SCM connections given: Corrected. I've actually switched to the https URIs, as those allow anonymous cloning and authenticated pushes. Apart from that it would be helpfull to know which Maven version you are using? How have you Maven called to generate the site ? Apache Maven 3.3.3 (NON-CANONICAL_2015-07-27T12:38:38_root; 2015-07-27T09:38:38+00:00) Maven home: /opt/maven Java version: 1.8.0_45, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-openjdk/jre Default locale: en_GB, platform encoding: UTF-8 OS name: linux, version: 4.0.7-2-arch, arch: amd64, family: unix According to rfscholte in the Freenode IRC channel, I'm running into this known issue: https://issues.apache.org/jira/browse/MPIR-234 I've applied the workaround until it's fixed. The first thing i stumbled over was the ssh-extension you are defining? So are you really trying to deploy via ssh your maven artifacts? Apart from that why are you using such an old version? There are newer versions available: http://maven.apache.org/wagon/ Right. I'm actually now just updating this project, which hasn't had any kind of build updates since early 2012. I am deploying maven artifacts to a privately hosted server over ssh, in addition to deploying to Maven Central. I've not found a way to avoid including that extension in the POM file without having to edit the Maven super POM (changes to which will obviously be wiped out every time I upgrade the OS package). I'm using an old version simply because I haven't yet updated, and nothing told me it was out of date. Furthermore i have seen that you define plugins in your parent like this: ... Which should be done like this: Fixed, thanks. which brings me to the next point you have defined the maven-compiler-plugin in your jnull-core module like this: ... OK. And then you can remove the definition of this in every submodule... Also the definition of maven-jar-plugin which you did in the submodule (jnull-core): ... Should be done only in the parent only once within the pluginManagement block... OK. See the docs of the archiver: http://maven.apache.org/shared/maven-archiver/index.html which is referenced from the doc site of the maven-jar-plugin: https://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html I have seen also that you define the maven-sources-plugin in your core module like this: Apart from the manifest part as mentioned for the maven-jar-plugin you have defined explicit executions with binding to life cycle which is not neccessary cause maven-sources-plugin is already bound to the life cycleAnd you should prevent using the goal 'jar' cause it will fork the life cycle...Are you sure making source packages of your test code ? I'm not sure what you mean here. I agree about the forking and didn't actually realize I was still using those goals here (I switched to the non-forking variants on my other projects and apparently missed this one). I'm not sure what you mean by Are you sure making source packages of your test code?. I have always distributed four jars per module in each of my projects: The sources jar, the compiled code jar, the javadoc jar, and the test-sources jar. So i can give you a hint to read this: http://blog.soebes.de/blog/2015/04/04/maven-prerequisites/ Right, I had no idea it was deprecated. I think it originally went in because the versions plugin nagged me if I didn't use one. M - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
