maven-eclipse-plugin: pde support and OSGiManifest writer
Does anyone actually use pde mode in maven-eclipse-plugin? The support looks pretty basic and there are other better options like tycho and felix for doing this stuff. EclipseOSGiManifestWriter has been deprecated in favour of felix and I wonder whether its worth keeping the other stuff around. I realise that not every use of the plugin is going to be on the user list - but it can give a gauge of sentiment. Opinions welcome. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: APT: Issue with adding xml code snippets as Verbatim
Try to only escape the '$' character, see
http://velocity.apache.org/engine/devel/user-guide.html#escapinginvalidvtlreferences
HTH,
-Lukas
On 09/23/2011 12:12 AM, Params wrote:
Thanks Robert, I tried couple of combinations and found this to work:
value#set($varline = '${wf:errorCode(wordcount)}') ${varline}/value
However, the display text I now get as html is:
value ${wf:errorCode(wordcount)}/value
Is there a way, I can get the wordcount inside single quotes?
Following three combinations don't work:
value#set($varline = '${wf:errorCode(\'wordcount\')}') ${varline}/value
value#set($varline = ${wf:errorCode('wordcount')}) ${varline}/value
value#set($varline = ${wf:errorCode(\'wordcount\')}) ${varline}/value
--
Thanks,
Params
--
View this message in context:
http://maven.40175.n5.nabble.com/APT-Issue-with-adding-xml-code-snippets-as-Verbatim-tp4831524p4831674.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Incremet SNAPSHOT dependency when release
Hello, my question is about how SNAPSHOT dependencies between submodules in multi module projects can be automatically incremented when performing a release. Let's give an example: I've a multi module project P with two sub modules A and B. Current version is 1.0-SNAPSHOT. The version number is only declared in P. A and B inherit P's version. A is dependent on B 1.0-SNAPSHOT: A - B (1.0-SNAPSHOT). Now I prepare a release of P by calling mvn release:prepare in the root directory of P. The release preparation is done and the dependency from A to B is changed to 1.0 in the tagged version. On my local machine the version of P is incremented to 1.1-SNAPSHOT, same is done with the parent version declaration in A and B (incremented to 1.1-SNAPSHOT). But, on my local machine the dependency from A to B is still of version 1.0-SNAPSHOT. Is there a way to configure that also the dependencies between modules in a multi-module project is to be incremented after a release? Regards, Abid -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Incremet SNAPSHOT dependency when release
I thought that the release plugin handled this. But I have never
tried, as I always use the ${project.version} property for specifying
version within a multi-module project. That would solve your problem.
/Anders
On Fri, Sep 23, 2011 at 12:08, Abid Hussain hussain.d...@gmx.de wrote:
Hello,
my question is about how SNAPSHOT dependencies between submodules in multi
module projects can be automatically incremented when performing a release.
Let's give an example: I've a multi module project P with two sub modules A
and B. Current version is 1.0-SNAPSHOT. The version number is only declared
in P. A and B inherit P's version.
A is dependent on B 1.0-SNAPSHOT: A - B (1.0-SNAPSHOT).
Now I prepare a release of P by calling mvn release:prepare in the root
directory of P. The release preparation is done and the dependency from A to
B is changed to 1.0 in the tagged version. On my local machine the version of
P is incremented to 1.1-SNAPSHOT, same is done with the parent version
declaration in A and B (incremented to 1.1-SNAPSHOT).
But, on my local machine the dependency from A to B is still of version
1.0-SNAPSHOT. Is there a way to configure that also the dependencies between
modules in a multi-module project is to be incremented after a release?
Regards,
Abid
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
-
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: Incremet SNAPSHOT dependency when release
Hi Abid, Abid Hussain wrote: Hello, my question is about how SNAPSHOT dependencies between submodules in multi module projects can be automatically incremented when performing a release. Let's give an example: I've a multi module project P with two sub modules A and B. Current version is 1.0-SNAPSHOT. The version number is only declared in P. A and B inherit P's version. A is dependent on B 1.0-SNAPSHOT: A - B (1.0-SNAPSHOT). Now I prepare a release of P by calling mvn release:prepare in the root directory of P. The release preparation is done and the dependency from A to B is changed to 1.0 in the tagged version. On my local machine the version of P is incremented to 1.1-SNAPSHOT, same is done with the parent version declaration in A and B (incremented to 1.1-SNAPSHOT). But, on my local machine the dependency from A to B is still of version 1.0-SNAPSHOT. Is there a way to configure that also the dependencies between modules in a multi-module project is to be incremented after a release? Use a depMgmt section in P to declare the version of A and B and do omit the version in the dependency list of A. That way the release plugin will also update the version in the depMgmt section of P. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: eclipse plugin does not generate org.eclipse.jdt.core.prefs file
Thanks Barrie!
That modification made the trick.
I also don't actually know if configuring the plugin using the command
line properties is a best practice.
But seeing the source code of the eclipse plugin, I traced it to the
IdeUtils.java [1], and it seems that the properties are not tacked
into account.
[1]
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin/src/main/java/org/apache/maven/plugin/ide/IdeUtils.java
2011/9/22 Barrie Treloar baerr...@gmail.com:
On Fri, Sep 23, 2011 at 3:51 AM, Gabriel Belingueres
belingue...@gmail.com wrote:
Hi,
I'm using Maven 3.0.3.
My current project pom.xml file uses a parent pom where is defined the
maven-compiler-plugin configuration:
properties
maven.compiler.source1.6/maven.compiler.source
maven.compiler.target1.6/maven.compiler.target
maven.compiler.showWarningstrue/maven.compiler.showWarnings
maven.compiler.showDeprecationtrue/maven.compiler.showDeprecation
maven.compiler.debuglevellines,vars,source/maven.compiler.debuglevel
maven.compiler.verbosetrue/maven.compiler.verbose
/properties
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.3.2/version
configuration
compilerArgument-Xlint:all/compilerArgument
/configuration
/plugin
...
/plugins
/pluginManagement
plugins
!-- all projects inherites the compiler configuration --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
/plugin
/plugins
If in the actual project pom.xml I do not declare the compiler plugin,
or if I declare it like this:
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
/plugin
/plugins
or with the version number:
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.3.2/version
/plugin
/plugins
then the .settings/org.eclipse.jdt.core.prefs file is NOT generated.
However, it is generated if I redeclare it fully like this:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.3.2/version
configuration
source1.6/source
target1.6/target
compilerArgument-Xlint:all/compilerArgument
showWarningstrue/showWarnings
showDeprecationtrue/showDeprecation
debuglevellines,vars,source/debuglevel
verbosetrue/verbose
/configuration
/plugin
is there a bug with the eclipse plugin? or am I doing something wrong?
The answer is kind of.
There is no standard way (that I'm aware of) for a mojo to ask for the
metadata of another mojo.
That is, the maven-eclipse-plugin can't ask maven-compiler-plugin what
its configuration is.
So what we do is to scan the pom model file that Maven builds up
looking in both the build/plugins and pluginManagement sections for
the maven compiler.
Then look for the specific option of interest (i.e. the source property).
What you are doing is setting the source value by indirection.
You are setting the equivalent of -Dmaven.compiler.source on the
command line, which is not showing up in the model representation.
(This may be where the bug is)
I'm not sure what best practice is, but I think using properties to
set values in plugins indirectly is probably not the way to go.
Use the property definitions but then configure the plugin with that property.
You already have a pluginManagement section, so I would specify the
configuration values there:
properties
maven.compiler.source1.6/maven.compiler.source
maven.compiler.target1.6/maven.compiler.target
maven.compiler.showWarningstrue/maven.compiler.showWarnings
maven.compiler.showDeprecationtrue/maven.compiler.showDeprecation
maven.compiler.debuglevellines,vars,source/maven.compiler.debuglevel
maven.compiler.verbosetrue/maven.compiler.verbose
/properties
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.3.2/version
configuration
compilerArgument-Xlint:all/compilerArgument
source${maven.compiler.source}/source
target${maven.compiler.target}/target
etc...
/configuration
/plugin
-
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
release transitive SNAPSHOT dependency
Hello, e.g. there is a project A (e.g. 1.0-SNAPSHOT) which has a dependency to another non-released project B (e.g. 2.3-SNAPSHOT). AFAIK performing a release which has SNAPSHOT versions is not possible. Is there a way to tell maven that when a release of project A should be performed to automatically - perform a release of B (e.g. 2.3) - update the dependency from A to B (so that A is dependent to B 2.3) - and then actually perform the release of A (resulting in A 1.0)? Regards, Abid -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: release transitive SNAPSHOT dependency
I hope not! Sounds like a really bad thing to do. How does maven know that B is release quality? Ron On 23/09/2011 11:58 AM, Abid Hussain wrote: Hello, e.g. there is a project A (e.g. 1.0-SNAPSHOT) which has a dependency to another non-released project B (e.g. 2.3-SNAPSHOT). AFAIK performing a release which has SNAPSHOT versions is not possible. Is there a way to tell maven that when a release of project A should be performed to automatically - perform a release of B (e.g. 2.3) - update the dependency from A to B (so that A is dependent to B 2.3) - and then actually perform the release of A (resulting in A 1.0)? Regards, Abid -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Exec-Maven-Plugin 1.2.1 Released
Hi, The Mojo team is pleased to announce the release of the Exec-Maven-Plugin version 1.2.1. This plugin provides 2 goals to help execute system and Java programs. http://mojo.codehaus.org/exec-maven-plugin/ To get this update, simply specify the version in your project's plugin configuration: plugin groupIdorg.codehaus.mojo/groupId artifactIdexec-maven-plugin/artifactId version1.2.1/version /plugin Additional information: This will probably be the last version based on JDK1.4 Release Notes - Maven 2.x Exec Plugin - Version 1.2.1 Bug [MEXEC-80] - exec:java squelches the first AWT exception [MEXEC-88] - ExecMojo: SuccessCodes config seems not to be recognized by commons exec framework [MEXEC-89] - Exceptions are not reported until program termination [MEXEC-92] - The plugin behaves unexpected when a file or a directory exist in the top level directory that has the same name as the given executable [MEXEC-98] - object is not an instance of declaring class error [MEXEC-100] - Plugin breaks arguments containing quotes Improvement [MEXEC-99] - Use int[] instead of java.util.List for successCodes Enjoy, The Mojo team. Robert Scholte
Maven Compiler Plugin - Incremental compile problem -- because of directory structure.
All, 1. I have following directory for java source code --lion --com test1 -- contains pom.xml and java source code with package com.test1 test2 - contains pom.cml and java source code with pakage com.test2 when compiler plugin compiles it does directory scanning and compiles only java code that are modified from previous build. But In above directory structure case it is recompiles the all source code in subsequent builds. How to overcome this ? I found that it is because of basedirectory do not follow maven standard direcotry layout. Please advise. Thanks, Narendra Gupta
Re: eclipse plugin does not generate org.eclipse.jdt.core.prefs file
On Sat, Sep 24, 2011 at 12:43 AM, Gabriel Belingueres belingue...@gmail.com wrote: Thanks Barrie! That modification made the trick. I also don't actually know if configuring the plugin using the command line properties is a best practice. But seeing the source code of the eclipse plugin, I traced it to the IdeUtils.java [1], and it seems that the properties are not tacked into account. [1] http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-eclipse-plugin/src/main/java/org/apache/maven/plugin/ide/IdeUtils.java Yup. I guess we could take the properties into account, we hard code the configuration setting already... It would mean that we'd need to look up the property settings for each plugin/configuration combination to include the property as well. Your the first person I'm aware of that has noticed this as a problem. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Compiler Plugin - Incremental compile problem -- because of directory structure.
Fri, 23 Sep 2011 14:12:00 -0400, /Gupta, Narendra/: 1. I have following directory for java source code --lion --com test1 -- contains pom.xml and java source code with package com.test1 test2 - contains pom.cml and java source code with pakage com.test2 when compiler plugin compiles it does directory scanning and compiles only java code that are modified from previous build. But In above directory structure case it is recompiles the all source code in subsequent builds. How to overcome this ? I found that it is because of basedirectory do not follow maven standard direcotry layout. Please advise. It is not a recommended practice but we use it as workaround for one of our core modules which has multiple source directories and we haven't yet retrofitted to a standard Maven layout. Set the source directory to test1 and then add test2 using the Build Helper Maven Plugin: http://mojo.codehaus.org/build-helper-maven-plugin/ http://mojo.codehaus.org/build-helper-maven-plugin/usage.html -- Stanimir - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven release from Git branch
On 17/09/2011, at 12:37 AM, Stuart Sierra wrote: I use Git, maven-release-plugin, Hudson, and the Hudson M2 Release Plugin. Can I perform a release from a Git branch other than master? On Mon, Sep 19, 2011 at 4:17 AM, Brett Porter br...@apache.org wrote: I believe so. You may need to set the tag element in the scm section of the POM on the branch. In my experience, the release plugin correctly releases in that situation (I'm not using Hudson for that, however). Thanks for the advice, Brett. As it turned out, I didn't need to change anything in Maven. I just changed the Hudson configuration to checkout a different branch. I use Hudson post-build actions to push release tags instead of the Maven Release plugin, so that I can prevent it from pushing tags if the build fails. -Stuart Sierra clojure.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
