Generating web project with java, webapp, and resource folder from archtype goal
Hi, Is there a way in maven to generate a web project with java, resources, and webapp folders running the archtype goal. Maven suggest to create a multi project module with: multi-project |-- pom.xml |-- my-app |-- my-web-app by creating a multi project pom file and then running: mvn archetype:create \ -DgroupId=some-group-id \ -DartifactId=my-app which generates: my-app |-- pom.xml |--src '-- main '-- java and then: mvn archetype:create \ -DarchetypeArtifactId=maven-archetype-webapp \ -DgroupId=some-group-id \ -DartifactId=my-web-app which generates: my-web-app |-- pom.xml |-- src '--main '-- resources '-- webapp But i would like to get this structure web-app |-- pom.xml |-- src '--main '-- java '-- resources '-- webapp from running the archtype goal on. cheers, Piotr
Using settings properties
Is it possible to use properties defined in settings.xml within
repositories / and distributionManagement /?
Other properties seem to get resolved during a build, however when I do a
deploy, maven uses the variable name with the leading ${ and trailing },
instead of the resolved variable value.
Any ideas?
Re: Maven release:perform deploy failed access denied
Hi Mark, I do you think that it might be a permission problem even if the deploy goal does work ? It seems that I'm not the first one encounting that issue.. but I just don't find any workaround.. -- View this message in context: http://maven.40175.n5.nabble.com/Maven-release-perform-deploy-failed-access-denied-tp3339497p3347450.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
Re: Using settings properties
Very bad practice! The repositories defined in the pom MUST be possible for
other people (other projects depending on your artifacts) to resolve. Using
properties defined in settings.xml makes that impossible.
/Anders
On Wed, Jan 19, 2011 at 05:14, mjk mj.kelle...@gmail.com wrote:
Is it possible to use properties defined in settings.xml within
repositories / and distributionManagement /?
Other properties seem to get resolved during a build, however when I do a
deploy, maven uses the variable name with the leading ${ and trailing },
instead of the resolved variable value.
Any ideas?
Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection
I agree that a global relocations.xml would not scale. You can't change the old (5.1.0) pom, so the most obvious place is simply adding this meta-data in the new pom (5.2.0): groupIdorg.drools.guvnor/groupId artifactIdguvnor-repository/artifactId version5.2.0/version legacy-identifications legacy-identification groupIdorg.drools/groupId artifactIddrools-repository/artifactId legacy-identification /legacy-identifications Then maven knows that guvnor-repository conflicts with drools-repository. Exclusions are a mess, in my opinion they are evil (even though I use them myself). Here's why: you add an exclusion today (after getting hurt because you didn't) - because of dependency bar forget to declare X as optional - because you don't want the transitive dependency drools-repository, because you got the newer guvnor-repository but tomorrow, when you upgrade to the next version of bar, you don't touch the exclusions because if you remove one and the build succeeds, it might still be luck (because the classpath order puts guvnor-repository 5.2.0 first on your machine). So you leave the exclusions in there... even though they might not be needed any more. A couple of years down the line and you get a build pom.xml like ours :) Op 18-01-11 18:32, Wayne Fay schreef: There should be some support for changing the GA. Getting it right immediately, forever in the beginning is not realistic. But how would you implement this? The only way I can think off the top of my head is a global relocations.xml that is stored in Central and is somehow used to manage these moves. But that gets ugly very quickly. And no one really wants to manage that file. No, I think the current approach is the most sane one. People using Maven for their builds should be expected to know what their dependencies (including transitives) are, and manage these kinds of changes with exclusions etc. Wayne -- With kind regards, Geoffrey De Smet - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven release:perform deploy failed access denied
YES I found out !!! I tried to add the distributionManagement Tag in each module of my multi-module project.. and it worked !! Still dunno why deploy goal does no need it, and perform goal needs.. but, it works !! Thanks everyone for your help, sincerely Jeremy -- View this message in context: http://maven.40175.n5.nabble.com/Maven-release-perform-deploy-failed-access-denied-tp3339497p3347495.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
Generating web project with java, webapp, and resource folder from archtype goal
Hi, Is there a way in maven to generate a web project with java, resources, and webapp folders running the archtype goal. Maven suggest to create a multi project module with: multi-project |-- pom.xml |-- my-app |-- my-web-app by creating a multi project pom file and then running: mvn archetype:create \ -DgroupId=some-group-id \ -DartifactId=my-app which generates: my-app |-- pom.xml |--src '-- main '-- java and then: mvn archetype:create \ -DarchetypeArtifactId=maven- archetype-webapp \ -DgroupId=some-group-id \ -DartifactId=my-web-app which generates: my-web-app |-- pom.xml |-- src '--main '-- resources '-- webapp But i would like to get this structure web-app |-- pom.xml |-- src '--main '-- java '-- resources '-- webapp from running the archtype goal on. cheers, Piotr
Re: Generating web project with java, webapp, and resource folder from archtype goal
One mail to the list per question is enough. We understand that you're asking because something is blocking you, but there is no need to spam the list. Give people a few days to respond (although you very often get a response quicker than that on this list). If nobody responds, it could be that there is no good answer. /Anders On Wed, Jan 19, 2011 at 10:30, Piotr Skawinski piotr.skawinski.ma...@gmail.com wrote: Hi, Is there a way in maven to generate a web project with java, resources, and webapp folders running the archtype goal. Maven suggest to create a multi project module with: multi-project |-- pom.xml |-- my-app |-- my-web-app by creating a multi project pom file and then running: mvn archetype:create \ -DgroupId=some-group-id \ -DartifactId=my-app which generates: my-app |-- pom.xml |--src '-- main '-- java and then: mvn archetype:create \ -DarchetypeArtifactId=maven- archetype-webapp \ -DgroupId=some-group-id \ -DartifactId=my-web-app which generates: my-web-app |-- pom.xml |-- src '--main '-- resources '-- webapp But i would like to get this structure web-app |-- pom.xml |-- src '--main '-- java '-- resources '-- webapp from running the archtype goal on. cheers, Piotr
Re: Generating web project with java, webapp, and resource folder from archtype goal
It wasnt on purpose. I just couldnt see the first mail reaching the mailing list, so i tried again :) Sorry for that :) On Wed, Jan 19, 2011 at 10:38 AM, Anders Hammar and...@hammar.net wrote: One mail to the list per question is enough. We understand that you're asking because something is blocking you, but there is no need to spam the list. Give people a few days to respond (although you very often get a response quicker than that on this list). If nobody responds, it could be that there is no good answer. /Anders On Wed, Jan 19, 2011 at 10:30, Piotr Skawinski piotr.skawinski.ma...@gmail.com wrote: Hi, Is there a way in maven to generate a web project with java, resources, and webapp folders running the archtype goal. Maven suggest to create a multi project module with: multi-project |-- pom.xml |-- my-app |-- my-web-app by creating a multi project pom file and then running: mvn archetype:create \ -DgroupId=some-group-id \ -DartifactId=my-app which generates: my-app |-- pom.xml |--src '-- main '-- java and then: mvn archetype:create \ -DarchetypeArtifactId=maven- archetype-webapp \ -DgroupId=some-group-id \ -DartifactId=my-web-app which generates: my-web-app |-- pom.xml |-- src '--main '-- resources '-- webapp But i would like to get this structure web-app |-- pom.xml |-- src '--main '-- java '-- resources '-- webapp from running the archtype goal on. cheers, Piotr
Re: Generating web project with java, webapp, and resource folder from archtype goal
The list archives (nabble for example) are great for verifying that. /Anders On Wed, Jan 19, 2011 at 10:47, Piotr Skawinski piotr.skawinski.ma...@gmail.com wrote: It wasnt on purpose. I just couldnt see the first mail reaching the mailing list, so i tried again :) Sorry for that :) On Wed, Jan 19, 2011 at 10:38 AM, Anders Hammar and...@hammar.net wrote: One mail to the list per question is enough. We understand that you're asking because something is blocking you, but there is no need to spam the list. Give people a few days to respond (although you very often get a response quicker than that on this list). If nobody responds, it could be that there is no good answer. /Anders On Wed, Jan 19, 2011 at 10:30, Piotr Skawinski piotr.skawinski.ma...@gmail.com wrote: Hi, Is there a way in maven to generate a web project with java, resources, and webapp folders running the archtype goal. Maven suggest to create a multi project module with: multi-project |-- pom.xml |-- my-app |-- my-web-app by creating a multi project pom file and then running: mvn archetype:create \ -DgroupId=some-group-id \ -DartifactId=my-app which generates: my-app |-- pom.xml |--src '-- main '-- java and then: mvn archetype:create \ -DarchetypeArtifactId=maven- archetype-webapp \ -DgroupId=some-group-id \ -DartifactId=my-web-app which generates: my-web-app |-- pom.xml |-- src '--main '-- resources '-- webapp But i would like to get this structure web-app |-- pom.xml |-- src '--main '-- java '-- resources '-- webapp from running the archtype goal on. cheers, Piotr
Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection
Hi Geoffry, Geoffrey De Smet wrote: I agree that a global relocations.xml would not scale. You can't change the old (5.1.0) pom, so the most obvious place is simply adding this meta-data in the new pom (5.2.0): groupIdorg.drools.guvnor/groupId artifactIdguvnor-repository/artifactId version5.2.0/version legacy-identifications legacy-identification groupIdorg.drools/groupId artifactIddrools-repository/artifactId legacy-identification /legacy-identifications Then maven knows that guvnor-repository conflicts with drools-repository. Exclusions are a mess, in my opinion they are evil (even though I use them myself). Here's why: you add an exclusion today (after getting hurt because you didn't) - because of dependency bar forget to declare X as optional - because you don't want the transitive dependency drools-repository, because you got the newer guvnor-repository but tomorrow, when you upgrade to the next version of bar, you don't touch the exclusions because if you remove one and the build succeeds, it might still be luck (because the classpath order puts guvnor-repository 5.2.0 first on your machine). So you leave the exclusions in there... even though they might not be needed any more. A couple of years down the line and you get a build pom.xml like ours :) Actually I'd like to have a replacements section in the depMgmt to define something like: depMgmt replacements replacement replace groupIdorg.ow2.spec.ee/groupId artifactIdow2-atinject-1.0-spec/artifactId !-- possible classifier -- /replace with groupIdjavax.inject/groupId artifactIdjavax.inject/artifactId !-- possible classifier -- /with /replacement replacement replace groupIdjavax.activation/groupId artifactIdactivation/artifactId /replace with / !-- part of JDK now -- /replacement /replacements /depMgmt Like the dependency definitions, the replacements would also be applied for transitive deps. Especially for someone developing with JSF this would be a life saver looking at the dependency mess in this area. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AW: AW: org.codehaus.modello.ModelloCli fails parsing maven.mdo on OpenVMS
That is what I think as well. In this case I would need to know
Looking at the xml below, its clearly the generate-sources target
which fails and in that the line with java fork=fork ... which
gets executed and fails in turn parsing the model file .mdo.
How does the class org.codehaus.modello.ModelloCli select which parser
to use and how can I check that the proper parser is used?
How can I enforce that this class uses a different parser?
Josef
target name=generate-sources depends=pull description=generates Java
sources from Modello mdo model files
mkdir dir=bootstrap/target/
mkdir dir=bootstrap/target/generated-sources/
macrodef name=modello-single-mode
attribute name=file/
attribute name=mode/
attribute name=version/
sequential
java fork=fork classname=org.codehaus.modello.ModelloCli
failonerror=true
classpath refid=modello.pathid/
arg file=@{file}/ !-- model file --
arg value=@{mode}/ !-- output type --
arg file=bootstrap/target/generated-sources/ !-- output
directory --
arg value=@{version}/ !-- model version --
arg value=false/ !-- package with version --
arg value=true/ !-- use Java 5 --
arg value=UTF-8/ !-- encoding --
/java
/sequential
/macrodef
macrodef name=modello
attribute name=file/
attribute name=version default=1.0.0/
sequential
echo taskname=modello message=Generating sources for @{file}/
modello-single-mode file=@{file} version=@{version} mode=java/
modello-single-mode file=@{file} version=@{version}
mode=xpp3-reader/
modello-single-mode file=@{file} version=@{version}
mode=xpp3-writer/
/sequential
/macrodef
modello file=maven-model/src/main/mdo/maven.mdo version=4.0.0/
modello file=maven-plugin-descriptor/src/main/mdo/lifecycle.mdo/
modello file=maven-plugin-registry/plugin-registry.mdo/
modello
file=maven-plugin-parameter-documenter/src/main/mdo/paramdoc.mdo/
modello file=maven-profile/src/main/mdo/profiles.mdo/
modello file=maven-settings/src/main/mdo/settings.mdo/
modello file=maven-repository-metadata/src/main/mdo/metadata.mdo/
modello file=maven-toolchain/src/main/mdo/toolchains.mdo/
/target
-Ursprüngliche Nachricht-
Von: Kristian Rosenvold [mailto:kristian.rosenv...@gmail.com]
Gesendet: Mittwoch, 19. Januar 2011 08:30
An: Maven Users List
Betreff: Re: AW: org.codehaus.modello.ModelloCli fails parsing maven.mdo on
OpenVMS
Den 18.01.2011 17:16, skrev Stadelmann Josef:
Maybe you have another advise for me.
From the general smell of it I would suspect this is somehow related to
your xml parsers/versions or some kind of inappropriate
version mix. I know this is probably not too helpful
Kristian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Config resources
I usually put my configuration where it works. In a web application, I put my web.xml in the src/main/webapp/WEB-INF folder. In Spring-related apps, my applicationConfig.xml goes in src/main/resources, and I might use Maven Filters to pull in the right parameters to whether I run as a dev build or production. http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html I would recommend putting configuration information into your src/main/resources, especially if you expect that the end .jar, .war, .ear, will need those configuration files at runtime. The src/main/resources get bundled up as part of the build, so the safe bet is to create whatever structure that you can manage your configuration files starting from there. -Nick 2010/12/29 Pazmiño Mazón, Iván Andrés iapm270...@sri.ad Thanks, sure this works, just wanted to know if there is any standard place to put this kind of files. -Original Message- From: Kalle Korhonen kalle.o.korho...@gmail.com Reply-to: Maven Users List users@maven.apache.org To: Maven Users List users@maven.apache.org Subject: Re: Config resources Date: Wed, 29 Dec 2010 11:13:53 -0800 src/main/config ? Kalle 2010/12/29 Pazmiño Mazón, Iván Andrés iapm270...@sri.ad: Hello, I'm building a web project and I have some configuration and descriptor files located inside src/main/resources/config which are used during the source preparation phase. Since this location will be loaded to the classpath I think it should be put in a better place. What's the standard for this better place? Or should I exclude the somehow from the resulting target/classes directory? Thanks, IP - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Clausula de Confidencialidad: La información contenida en el presente mensaje es confidencial, está dirigida exclusivamente a su destinatario y no puede ser vinculante. El Servicio de Rentas Internas no se responsabiliza por su uso y deja expresa constancia que en los registros de la Institución consta la información originalmente enviada. Este mensaje está protegido por la Ley de Propiedad Intelectual, Ley de Comercio Electrónico, Firmas y Mensajes de datos, reglamentos y acuerdos internacionales relacionados. Si usted no es el destinatario de este mensaje, recomendamos su eliminación inmediata. La distribución o copia del mismo, está prohibida y será sancionada de acuerdo al Código Penal y demás normas aplicables. La transmisión de información por correo electrónico, no garantiza que la misma sea segura o esté libre de error, por consiguiente, se recomienda su verificación.Toda solicitud de información requerida de manera oficial al SRI debe ser ingresada por Secretaría General y dirigida a la máxima autoridad de la Institución, conforme a la Ley y demás normas vigentes. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Using settings properties
Thanks for the advice. You could have proposed a solution instead of just a
criticism.
Sent from my iPhone
On Jan 19, 2011, at 4:02 AM, Anders Hammar and...@hammar.net wrote:
Very bad practice! The repositories defined in the pom MUST be possible for
other people (other projects depending on your artifacts) to resolve. Using
properties defined in settings.xml makes that impossible.
/Anders
On Wed, Jan 19, 2011 at 05:14, mjk mj.kelle...@gmail.com wrote:
Is it possible to use properties defined in settings.xml within
repositories / and distributionManagement /?
Other properties seem to get resolved during a build, however when I do a
deploy, maven uses the variable name with the leading ${ and trailing },
instead of the resolved variable value.
Any ideas?
Re: Using settings properties
Hi
At my company we use properties in the global setting.xml which the
build is dependent. This make sense since our build is strictly within
our company and everyone uses the same maven installation
For instance:
(in setting.xml)
profile
idcore/id
properties
adeViewRoot/ade/viper/adeViewRoot
/properties
(in pom.xml)
distributionManagement
repository
idsdp/id
layoutdefault/layout
nameSDP Repository/name
uniqueVersionfalse/uniqueVersion
urlfile://${adeViewRoot}/sdp/maven2-snapshots/url
/repository
I suppose that you could use environment variable, like:
site
idsdp-site/id
nameService Delivery Platform Site/name
urlfile:///net/${env.WEB_SERVER_NAME}${env.WEB_SERVER_BASE_LOCAL_DIR}/${oracle.sdp.release}/${env.ADE_VIEW_LABEL}/reports/url
/site
I think you might want to check the schema for setting.xml to see where
you can add the element properties.
Cheers
Lucas
On 01/19/2011 12:43 PM, Michael Kelleher wrote:
Thanks for the advice. You could have proposed a solution instead of just a
criticism.
Sent from my iPhone
On Jan 19, 2011, at 4:02 AM, Anders Hammarand...@hammar.net wrote:
Very bad practice! The repositories defined in the pom MUST be possible for
other people (other projects depending on your artifacts) to resolve. Using
properties defined in settings.xml makes that impossible.
/Anders
On Wed, Jan 19, 2011 at 05:14, mjkmj.kelle...@gmail.com wrote:
Is it possible to use properties defined in settings.xml within
repositories / anddistributionManagement /?
Other properties seem to get resolved during a build, however when I do a
deploy, maven uses the variable name with the leading ${ and trailing },
instead of the resolved variable value.
Any ideas?
Re: Using settings properties
I would strongly suggest that you move the distMgmt section to a corporate
parent pom instead. So when (if?) you change the urls, you just update the
parent pom (and yes, you do need to update the reference in any project
inheriting from it). Anything in your pom that could change depending on the
environment is most often a bad idea.
Having a look at how things like this is solved within the open source world
(the apache parent or the codehaus parent), would give you good ideas of
best practice.
/Anders
On Wed, Jan 19, 2011 at 13:06, Lucas Persson lucas.pers...@oracle.comwrote:
Hi
At my company we use properties in the global setting.xml which the build
is dependent. This make sense since our build is strictly within our company
and everyone uses the same maven installation
For instance:
(in setting.xml)
profile
idcore/id
properties
adeViewRoot/ade/viper/adeViewRoot
/properties
(in pom.xml)
distributionManagement
repository
idsdp/id
layoutdefault/layout
nameSDP Repository/name
uniqueVersionfalse/uniqueVersion
urlfile://${adeViewRoot}/sdp/maven2-snapshots/url
/repository
I suppose that you could use environment variable, like:
site
idsdp-site/id
nameService Delivery Platform Site/name
urlfile:///net/${env.WEB_SERVER_NAME}${env.WEB_SERVER_BASE_LOCAL_DIR}/${oracle.sdp.release}/${env.ADE_VIEW_LABEL}/reports/url
/site
I think you might want to check the schema for setting.xml to see where you
can add the element properties.
Cheers
Lucas
On 01/19/2011 12:43 PM, Michael Kelleher wrote:
Thanks for the advice. You could have proposed a solution instead of just
a
criticism.
Sent from my iPhone
On Jan 19, 2011, at 4:02 AM, Anders Hammarand...@hammar.net wrote:
Very bad practice! The repositories defined in the pom MUST be possible
for
other people (other projects depending on your artifacts) to resolve.
Using
properties defined in settings.xml makes that impossible.
/Anders
On Wed, Jan 19, 2011 at 05:14, mjkmj.kelle...@gmail.com wrote:
Is it possible to use properties defined in settings.xml within
repositories / anddistributionManagement /?
Other properties seem to get resolved during a build, however when I do a
deploy, maven uses the variable name with the leading ${ and trailing },
instead of the resolved variable value.
Any ideas?
Re: Error while compiling : annotations are not supported in -source 1.3
Wayne Fay wrote: 1. I made some changes in the pom.xml (indicated in Bold). This list strips HTML and RTF so no one can see your bold text. 2. I ran mvn help:effective-pom and this is what I got OK... but what happens (now) when you run mvn compile? I assume you are running all of this from the command line, and not from Eclipse etc, right? Yes .I ran it from the command line .. not IDE. I 'm still getting the same old error when I run mvn compile . http://maven.40175.n5.nabble.com/file/n3347809/compile.jpg I have uploaded my project file here in Rapishare http://rapidshare.com/files/443396415/je.zip http://rapidshare.com/files/443396415/je.zip . If possible , pls Run it from your Computer . May be the error detection will be easier then. I'm seeing stars . I've been in this stage since 2 months now!!! So pls help. -- View this message in context: http://maven.40175.n5.nabble.com/Error-while-compiling-annotations-are-not-supported-in-source-1-3-tp3343153p3347809.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
Re: Changing the groupId/artifactId of an artifact in the next version but keep maven conflict detection
On 19/01/2011 4:14 AM, Geoffrey De Smet wrote: I agree that a global relocations.xml would not scale. You can't change the old (5.1.0) pom, so the most obvious place is simply adding this meta-data in the new pom (5.2.0): groupIdorg.drools.guvnor/groupId artifactIdguvnor-repository/artifactId version5.2.0/version legacy-identifications legacy-identification groupIdorg.drools/groupId artifactIddrools-repository/artifactId legacy-identification /legacy-identifications Then maven knows that guvnor-repository conflicts with drools-repository. Exclusions are a mess, in my opinion they are evil (even though I use them myself). Here's why: you add an exclusion today (after getting hurt because you didn't) - because of dependency bar forget to declare X as optional - because you don't want the transitive dependency drools-repository, because you got the newer guvnor-repository but tomorrow, when you upgrade to the next version of bar, you don't touch the exclusions because if you remove one and the build succeeds, it might still be luck (because the classpath order puts guvnor-repository 5.2.0 first on your machine). So you leave the exclusions in there... even though they might not be needed any more. Solution(for those who have heard this before, ignore the following): 1) Build aggregation POMs for all third party libraries. 2) Projects do not have third party libraries in their dependencies. Simple. Libraries under control and planned in advance. No nasty surprises later. Ron A couple of years down the line and you get a build pom.xml like ours :) Op 18-01-11 18:32, Wayne Fay schreef: There should be some support for changing the GA. Getting it right immediately, forever in the beginning is not realistic. But how would you implement this? The only way I can think off the top of my head is a global relocations.xml that is stored in Central and is somehow used to manage these moves. But that gets ugly very quickly. And no one really wants to manage that file. No, I think the current approach is the most sane one. People using Maven for their builds should be expected to know what their dependencies (including transitives) are, and manage these kinds of changes with exclusions etc. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Error while compiling : annotations are not supported in -source 1.3
I have uploaded my project file here in Rapishare http://rapidshare.com/files/443396415/je.zip . If possible , pls Run it from your Computer . May be the error detection will be easier then. I downloaded your project and ran it. The only failure I encountered was related to a missing dependency that was causing all of your javax.persistence references to fail. I added the following to the chapter02/pom.xml file: dependency groupIdjavax.persistence/groupId artifactIdpersistence-api/artifactId version1.0/version /dependency and poof, everything worked just fine. I don't know what is causing your problems with the compiler etc, but try adding this dependency and see if things work a little better for you. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Swapping in a different logging implementation?
It looks to my naive eyes like the logger that is responsible for printing
out the various [INFO] messages to the command line during a Maven run is
hard coded. Perhaps--hopefully--I'm wrong.
Is there a way to replace this logger as the first action during a build, so
that Maven's logger shunts through java.util.logging, for example? Via
build extensions, maybe?
(For that matter, is there any documentation anywhere on what a build
extension *is*? I understand that a build extension is a piece of code that
is loaded into the Maven classloader, and that it can {handwave handwave}
affect the build, but does it need to implement any interface? Extend from
a class? The documentation on build extensions,
http://maven.apache.org/guides/mini/guide-using-extensions.html, is
comical.)
Thanks,
Laird
downloading resources
Hi, There are several external shared libraries available via http in tar.gz files that I want to include in a jar. I do not want to check these files into my scm. How do I get maven to 1) Check if they are already present, and if not 2) Download the tarball 3) Uncompress it to my projects src/main/resources folder (I'm distributing shared libraries this way because it's an OSGi bundle that uses JNI libraries) Any advice on combinations of plugins to use? -Adam
Dependencies get unpacked over and over again
Has anyone else run into this? I run into it all the time. It appears to be because unpack-dependencies is not updating the timestamp on the marker files like it should. I found this bug which seems to be exactly my problem: http://jira.codehaus.org/browse/MDEP-225 I contacted the developer about it but got no response. What should I do now? Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependencies get unpacked over and over again
Briefly looking through the comments it looks like an integration test is missing for the patch to be accepted. Can you provide one? /Anders On Wed, Jan 19, 2011 at 21:59, Phillip Hellewell ssh...@gmail.com wrote: Has anyone else run into this? I run into it all the time. It appears to be because unpack-dependencies is not updating the timestamp on the marker files like it should. I found this bug which seems to be exactly my problem: http://jira.codehaus.org/browse/MDEP-225 I contacted the developer about it but got no response. What should I do now? Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Create a common/shared task for the maven-antrun-plugin ?
Yeah I like the idea about writing my own maven-plugin, its about time I get around to do that :-) But why add all the complexity of: http://groovy.codehaus.org/Using+Ant+from+Groovy http://code.google.com/p/indoorsdog/source/browse/jacoco/trunk/jacoco-maven-plugin/src/main/groovy/org/indoorsdog/jacoco/maven/plugin/internal/AgentMojo.groovy which was Luke's initial suggestion? I don't want to modify the ant-run-plugin I just want to execute a specific sequence of tasks for the existing implementation of ant-run and encapsulate this in a plugin that can be used during the build phase for a bunch of projects. From this link: http://maven.apache.org/guides/plugin/guide-java-plugin-development.html this basically just boils down to create a pom file with packagingmaven-plugin/packaging and then just add whatever needs to be done. This custom plugin can then be included in another project. Here is an example pom file which defines a few tasks: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; modelVersion4.0.0/modelVersion groupIdcom.test.maven.plugins/groupId artifactIdmy-maven-plugin/artifactId version1.0.0-SNAPSHOT/version packagingmaven-plugin/packaging dependencies dependency groupIdorg.apache.maven/groupId artifactIdmaven-plugin-api/artifactId version2.0/version /dependency /dependencies build plugins plugin artifactIdmaven-antrun-plugin/artifactId version1.6/version executions execution idtest/id phasedeploy/phase goals goalrun/goal /goals configuration tasks !-- run task A, B and C-- /tasks /configuration /execution /executions dependencies dependency groupIdorg.apache.ant/groupId artifactIdant-jsch/artifactId version1.8.1/version /dependency /dependencies /plugin /plugins /build /project Then in another project I just add the above plugin to the build phase: ... build plugins plugin groupIdcom.test.maven.plugins/groupId artifactIdmy-maven-plugin/artifactId version1.0.0-SNAPSHOT/version /plugin /plugins /build Unfortunately the my-maven-plugin never gets executed when the project using the plugin is deployed. Any suggestion why this simple approach does not work? On Tue, Jan 18, 2011 at 11:47 PM, Wayne Fay wayne...@gmail.com wrote: But I need to use this custom task across different projects. Do you suggest that I create a full separate native maven project where one In that case... I like Luke's initial suggestion of turning this into a plugin even more. Wayne - 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
uk.maven.org mirror ip change
AIRN is requiring that Contegix renumber our machines in the UK so tonight one of them will change and tomorrow the other will change. As always, you should address them using http://uk.maven.org to allow failover but I know occasionally people have to poke holes in their firewalls based on ip. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
GWT Widget as JAR
Hi all, Option 1: It's easy to write a POM that creates a JAR for a GWT widget including CSS and other resources. It's also easy to then write a POM that depends on that JAR and creates a WAR for integration testing. So far so good. Problem: Making changes in (e.g.) the CSS requires a full rebuild of both the JAR and the WAR. This is a real productivity issue. Option 2: Put everything in a single WAR project. Integration testing uses this WAR and development can make changes that are reflected after a simple refresh. Problem: We need a JAR, not a WAR for our other GWT projects that want to reuse the widget. The only solution that I can see is to go with option 2 and create a second (JAR) project that depends on the WAR and strips away all its web-app-ness to create the JAR I referred to in option 1. This achieves all my goals but isn't very elegant. Can anyone think of a better way to do this? Cheers, Hilco - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: GWT Widget as JAR
achieves all my goals but isn't very elegant. Can anyone think of a better way to do this? A couple thoughts... 1) You can create a jar out of a war project by binding the jar plugin to your build. 2) You may want to look at the maven-remote-resources-plugin and think about putting the GWT widget in its own bundle. I guess this is pretty much option #1 though. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: downloading resources
1) Check if they are already present, and if not 2) Download the tarball 3) Uncompress it to my projects src/main/resources folder Some plugins you should take a look at: m-dependency-p (probably can do it all) m-assembly-p m-remote-resources-p (probably not an option) m-antrun-p (if you really can't find a good way to do this any other way) make-maven-plugin (part of the codehaus cbuild plugin) [1] [1] http://mojo.codehaus.org/cbuild-parent/cbuild-plugin-parent/make-maven-plugin/unpack-mojo.html Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: downloading resources
3) Uncompress it to my projects src/main/resources folder Oh and btw you should probably not be uncompressing to src/main/resources but rather to /target. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: GWT Widget as JAR
On 19 January 2011 17:49, Wayne Fay wayne...@gmail.com wrote: achieves all my goals but isn't very elegant. Can anyone think of a better way to do this? A couple thoughts... 1) You can create a jar out of a war project by binding the jar plugin to your build. Excellent, with a few excludes and attach-artifact I now have exactly what I need in a single POM. Thanks! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Error while compiling : annotations are not supported in -source 1.3
Wayne Fay wrote: I have uploaded my project file here in Rapishare http://rapidshare.com/files/443396415/je.zip . If possible , pls Run it from your Computer . May be the error detection will be easier then. I downloaded your project and ran it. The only failure I encountered was related to a missing dependency that was causing all of your javax.persistence references to fail. I added the following to the chapter02/pom.xml file: dependency groupIdjavax.persistence/groupId artifactIdpersistence-api/artifactId version1.0/version /dependency and poof, everything worked just fine. I don't know what is causing your problems with the compiler etc, but try adding this dependency and see if things work a little better for you. Wayne Wow .Thats so great of u to do that much..Far too kind!! ,ay I know which Version of Maven r u using ? U know what Wayne . When I removed Maven 2 and used maven 3 .. I met with the same error of missing dependency. Now This is what I'm gonna do : Remove Maven 2 completely and run it with maven 3 and of course apply the change that u suggest. Thanks a lot -- View this message in context: http://maven.40175.n5.nabble.com/Error-while-compiling-annotations-are-not-supported-in-source-1-3-tp3343153p3349080.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
Help referencing profile properties/attributes...
I'm new to Maven and am building a POM with profiles. I want to be able to
set a system property that contains the value of the current profile(s).
Currently I have multiple profiles that each relate to different web app
servers (dev, test, staging, etc.) in our dev/test environment. I want the
profile (via the surefire plugin) to set a system property called config
that can be read during the test goal to change which web app server to
use (via property file).
Currently the value of the config system property is equivalent to the
value of the profile id. Is there a syntax in the POM for referencing the
id of the profile that is in the parent chain of the property being set?
For example, in the profile below, can I reference the profile id in order
to retrieve the value staging? I've tried ${profile.id}, ${id}, but they
don't work.
profiles
profile
*idstaging/id
*...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.7.1/version
configuration
skipfalse/skip
systemPropertyVariables
*config${profile.id}/config
*...
/profile
/profiles
Thanks!!
--
Jeff Vincent
predato...@gmail.com
See my LinkedIn profile at:
http://www.linkedin.com/in/rjeffreyvincent
Determining where a value/property is being changed (POM debugging?)
I'm using Maven v2.2.1 with NetBeans 6.9.1 and this could be a NetBeans issue but thought I'd check here. I have profiles in my POM that when activated, set a system property via the maven-surefire-plugin systemPropertyVariables setting to determine which testing configuration (dev, test, staging, etc.) to load via a properties file. I've been fighting how to get this working because the property was not getting set. I finally figured out that if I explicitly set the value skipfalse/skip in the surefire plugin settings for the active profile, that it works. If I omit the skipfalse/skip line, the configuration seems to be skipped, even though it starts the test class in the debugger. I don't depend explicitly on a parent POM, nor do I override maven.test.skip. The command-line being used by NetBeans is activating the profile using the -P option as expected. Is there a way to determine where the skip property is being change/set? Thanks! -- Jeff Vincent predato...@gmail.com See my LinkedIn profile at: http://www.linkedin.com/in/rjeffreyvincent
Re: downloading resources
What phase should I be doing this in to insure that they make it into the bundle? On Wed, Jan 19, 2011 at 9:52 PM, Wayne Fay wayne...@gmail.com wrote: 3) Uncompress it to my projects src/main/resources folder Oh and btw you should probably not be uncompressing to src/main/resources but rather to /target. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
