Re: AW: AW: org.codehaus.modello.ModelloCli fails parsing maven.mdo on OpenVMS
Modello uses XPP3 parser from plexus-utils, without any way to use another
parser (see [1])
AFAIK, Maven models are very simple XML documents, without any non-ascii
characters that could make parsing a little bit tricky.
Can you zip maven.mdo taken from your OpenVMS machine and send it to me
please, so I can check if there is any surprising thing in it?
Please add ant -diagnostics output to the zip file, please, so I can have
information on your environment.
I'm very interested in such exotic configuration, since I want to check that
encoding is working properly everywhere.
Regards,
Hervé
[1] http://fisheye.codehaus.org/browse/modello/trunk/modello-
core/src/main/java/org/codehaus/modello/core/io/ModelReader.java?r=1436#l91
Le mercredi 19 janvier 2011, Stadelmann Josef a écrit :
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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Maven gpg plugin stuck while signing
Hi all, I'm using the Maven release plugin (in dryRun mode) to prepare a release but the mvn release:prepare -DdryRun=true command gets stuck while signing the artifacts with gpg-plugin. Here's what I see in normal mode: ... [INFO] [INFO] Building zip: /Users/tommasoteofili/Documents/workspaces/uima/sandbox/BSFAnnotator/target/uimaj-an-bsf-bin.zip [INFO] [INFO] [INFO] [INFO] --- maven-gpg-plugin:1.1:sign (default) @ BSFAnnotator --- ... and this is the output with debug enabled (-X): ... [INFO] [DEBUG] Configuring mojo org.apache.maven.plugins:maven-gpg-plugin:1.1:sign from plugin realm ClassRealm[pluginorg.apache.maven.plugins:maven-gpg-plugin:1.1, parent: ClassRealm[maven.api, parent: null]] [INFO] [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-gpg-plugin:1.1:sign' with basic configurator -- [INFO] [DEBUG] (f) ascDirectory = /Users/tommasoteofili/Documents/workspaces/uima/sandbox/BSFAnnotator/target/gpg [INFO] [DEBUG] (f) interactive = true [INFO] [DEBUG] (f) project = MavenProject: org.apache.uima:BSFAnnotator:2.3.1-SNAPSHOT @ /Users/tommasoteofili/Documents/workspaces/uima/sandbox/BSFAnnotator/pom.xml [INFO] [DEBUG] (f) skip = false [INFO] [DEBUG] (f) useAgent = false [INFO] [DEBUG] -- end configuration -- [INFO] [DEBUG] Extension realms for project org.apache.uima:parent-pom:pom:2: (none) [INFO] [DEBUG] Looking up lifecyle mappings for packaging pom from ClassRealm[plexus.core, parent: null] ... My GPG key is 4096 bit, is that too much? Side note: I am using Maven 3.0 with Java 6 on a Mac 10.6. Thanks in advance for any help. Tommaso
Re: Maven gpg plugin stuck while signing
Ciao Tommy ;)
I already met this problem, It's not a of key-size related issue. Try
setting the mavenExecutorId=forked-path so when releasing maven will
be forked and the gpg-plugin will prompt you insert the gpg
passphrase.
Otherwise you can use the -Dgpg.passphrase=XXX property but its use is
discouraged and you can easily understand why.
HTH
Simo
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.X/version
configuration
mavenExecutorIdforked-path/mavenExecutorId
/configuration
/plugin
{code}
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Jan 23, 2011 at 12:13 PM, Tommaso Teofili
tommaso.teof...@gmail.com wrote:
Hi all,
I'm using the Maven release plugin (in dryRun mode) to prepare a release but
the
mvn release:prepare -DdryRun=true
command gets stuck while signing the artifacts with gpg-plugin.
Here's what I see in normal mode:
...
[INFO] [INFO] Building zip:
/Users/tommasoteofili/Documents/workspaces/uima/sandbox/BSFAnnotator/target/uimaj-an-bsf-bin.zip
[INFO] [INFO]
[INFO] [INFO] --- maven-gpg-plugin:1.1:sign (default) @ BSFAnnotator ---
...
and this is the output with debug enabled (-X):
...
[INFO] [DEBUG] Configuring mojo
org.apache.maven.plugins:maven-gpg-plugin:1.1:sign from plugin realm
ClassRealm[pluginorg.apache.maven.plugins:maven-gpg-plugin:1.1, parent:
ClassRealm[maven.api, parent: null]]
[INFO] [DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-gpg-plugin:1.1:sign' with basic configurator
--
[INFO] [DEBUG] (f) ascDirectory =
/Users/tommasoteofili/Documents/workspaces/uima/sandbox/BSFAnnotator/target/gpg
[INFO] [DEBUG] (f) interactive = true
[INFO] [DEBUG] (f) project = MavenProject:
org.apache.uima:BSFAnnotator:2.3.1-SNAPSHOT @
/Users/tommasoteofili/Documents/workspaces/uima/sandbox/BSFAnnotator/pom.xml
[INFO] [DEBUG] (f) skip = false
[INFO] [DEBUG] (f) useAgent = false
[INFO] [DEBUG] -- end configuration --
[INFO] [DEBUG] Extension realms for project
org.apache.uima:parent-pom:pom:2: (none)
[INFO] [DEBUG] Looking up lifecyle mappings for packaging pom from
ClassRealm[plexus.core, parent: null]
...
My GPG key is 4096 bit, is that too much?
Side note: I am using Maven 3.0 with Java 6 on a Mac 10.6.
Thanks in advance for any help.
Tommaso
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven gpg plugin stuck while signing
Am 23.01.2011 um 18:51 schrieb Simone Tripodi: Ciao Tommy ;) I already met this problem, It's not a of key-size related issue. Try setting the mavenExecutorId=forked-path so when releasing maven will be forked and the gpg-plugin will prompt you insert the gpg passphrase. Otherwise you can use the -Dgpg.passphrase=XXX property but its use is discouraged and you can easily understand why. yes, that's clear. Is it possible to disable the gpg-plugin for the daily build? regards, Oliver - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven gpg plugin stuck while signing
Hi Oliver,
sure you can do it, just move the gpg plugin into a proper 'release'
profile, and configure the release-plugin to activate it when
releasing.
Take a look how I configured the Google Doclava[1] pom to see how it
works, follow below some snippets.
HTH, all the best,
Simo
{code}
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.1/version
configuration
mavenExecutorIdforked-path/mavenExecutorId
arguments-Prelease/arguments
remoteTaggingfalse/remoteTagging
/configuration
/plugin
/plugins
/pluginManagement
profile
idrelease/id
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-gpg-plugin/artifactId
version1.1/version
executions
execution
idsign-artifacts/id
phaseverify/phase
goals
goalsign/goal
/goals
/execution
/executions
/plugin
{code}
[1] http://code.google.com/p/doclava/source/browse/tags/doclava-1.0.2/pom.xml
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Jan 23, 2011 at 7:37 PM, oliver oliver.bo...@gmail.com wrote:
Am 23.01.2011 um 18:51 schrieb Simone Tripodi:
Ciao Tommy ;)
I already met this problem, It's not a of key-size related issue. Try
setting the mavenExecutorId=forked-path so when releasing maven will
be forked and the gpg-plugin will prompt you insert the gpg
passphrase.
Otherwise you can use the -Dgpg.passphrase=XXX property but its use is
discouraged and you can easily understand why.
yes, that's clear. Is it possible to disable the gpg-plugin for the daily
build?
regards,
Oliver
-
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
reactor, plugin dependency, m3
I have a multi-module build. The first module packages up some some checkstyle rules, and the parent POM at the top calls out that artifact as a dependency of the checkstyle plugin. Would it surprise anyone to hear that this won't build the first time, but builds subsequently once the artifact is in the local repo? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Work flow for isolated internal repository
In a commercial software development environment, production code will rely on artifacts which may come from public domain such as maven central repository. For those artifacts from external, would be validated with some process such as checksum/javadoc/sources/license/lawyer, once passed those check, then deployed to internal maven repository to build into product. Internal repository is isolated from external repository for various reason. A typical work flow will be: 1. Developer enable the access to external repository. 2. Developer add new dependencies as artifacts/plugins which available from external repository. 3. Developer test the new pom setup and it works on local machine 4. Developer in some how figure out all (hundreds) new dependencies need added to internal repository 5. Developer/Administrator/Lawyer valid the new dependencies such as javadoc/sources/license 6. Developer/Administrator deploy new dependencies to internal repository 7. Developer check in projects pom and it will works on continuous integration server which only have access to internal repository. Any question on the work flow? Is this work flow could be easily supported? (with open source/commercial repository manager) Thanks! -Guo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
m2eclipse-subversive and Subversive Integration for the M2Eclipse relation
Hello Maven users, Jason van Zyl just announced m2eclipse-subversive http://twitter.com/#!/jvanzyl/status/29312097812750336 Does anyone know how is that project related to Subversive Integration for the M2Eclipse, Subversive plugin integration feature? Regards, Stevo. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: reactor, plugin dependency, m3
On Jan 23, 2011, at 5:09 PM, Benson Margulies bimargul...@gmail.com wrote: I have a multi-module build. The first module packages up some some checkstyle rules, and the parent POM at the top calls out that artifact as a dependency of the checkstyle plugin. Would it surprise anyone to hear that this won't build the first time, but builds subsequently once the artifact is in the local repo? No. This is expected. - 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: Work flow for isolated internal repository
1. Developer enables the access to internal repository(Nexus or other). 2. Developer add new dependencies as artifacts/plugins which available from external repository. 3. Developer test the new pom setup and it works on local machine 4. Maven and Nexus will automatically load new dependencies that need added to internal repository 5. Developer/Administrator/Lawyer valid the new dependencies such as javadoc/sources/license- needs to be done before 2. Why should the developer waste time using invalid libraries. 6. Maven/Nexus deploys new dependencies to internal repository 7. Developer check in projects (pom and sources) and it will work on continuous integration server On 23/01/2011 6:20 PM, Guo Du wrote: In a commercial software development environment, production code will rely on artifacts which may come from public domain such as maven central repository. For those artifacts from external, would be validated with some process such as checksum/javadoc/sources/license/lawyer, once passed those check, then deployed to internal maven repository to build into product. Internal repository is isolated from external repository for various reason. A typical work flow will be: 1. Developer enable the access to external repository. 2. Developer add new dependencies as artifacts/plugins which available from external repository. 3. Developer test the new pom setup and it works on local machine 4. Developer in some how figure out all (hundreds) new dependencies need added to internal repository 5. Developer/Administrator/Lawyer valid the new dependencies such as javadoc/sources/license 6. Developer/Administrator deploy new dependencies to internal repository 7. Developer check in projects pom and it will works on continuous integration server which only have access to internal repository. Any question on the work flow? Is this work flow could be easily supported? (with open source/commercial repository manager) Thanks! -Guo - 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: m2eclipse-subversive and Subversive Integration for the M2Eclipse relation
Use the m2eclipse list. This is not the place to ask m2eclipse questions. On Jan 23, 2011, at 5:21 PM, Stevo Slavić wrote: Hello Maven users, Jason van Zyl just announced m2eclipse-subversive http://twitter.com/#!/jvanzyl/status/29312097812750336 Does anyone know how is that project related to Subversive Integration for the M2Eclipse, Subversive plugin integration feature? Regards, Stevo. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: Work flow for isolated internal repository
You could be somewhat aided by the procurement feature of Nexus Pro (the commercial edition of the Nexus repo manager): http://www.sonatype.com/books/nexus-book/reference/procure.html Also, One thing that you might want to have in mind is two have separate repositories for dependencies and plugins. For Maven to be useful, you will need quite a few plugins. These plugins have lots of dependencies which you simply just must allow. If you use Maven 3, plugins and their dependendencies can have separate repos from your projects' dependencies. This does not work in Maven 2.x. /Anders On Mon, Jan 24, 2011 at 00:20, Guo Du mrdu...@duguo.org wrote: In a commercial software development environment, production code will rely on artifacts which may come from public domain such as maven central repository. For those artifacts from external, would be validated with some process such as checksum/javadoc/sources/license/lawyer, once passed those check, then deployed to internal maven repository to build into product. Internal repository is isolated from external repository for various reason. A typical work flow will be: 1. Developer enable the access to external repository. 2. Developer add new dependencies as artifacts/plugins which available from external repository. 3. Developer test the new pom setup and it works on local machine 4. Developer in some how figure out all (hundreds) new dependencies need added to internal repository 5. Developer/Administrator/Lawyer valid the new dependencies such as javadoc/sources/license 6. Developer/Administrator deploy new dependencies to internal repository 7. Developer check in projects pom and it will works on continuous integration server which only have access to internal repository. Any question on the work flow? Is this work flow could be easily supported? (with open source/commercial repository manager) Thanks! -Guo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven gpg plugin stuck while signing
Many thanks Simo! :-)
I'm going to try this way and let you know.
Cheers,
Tommaso
2011/1/23 Simone Tripodi simonetrip...@apache.org
Hi Oliver,
sure you can do it, just move the gpg plugin into a proper 'release'
profile, and configure the release-plugin to activate it when
releasing.
Take a look how I configured the Google Doclava[1] pom to see how it
works, follow below some snippets.
HTH, all the best,
Simo
{code}
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.1/version
configuration
mavenExecutorIdforked-path/mavenExecutorId
arguments-Prelease/arguments
remoteTaggingfalse/remoteTagging
/configuration
/plugin
/plugins
/pluginManagement
profile
idrelease/id
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-gpg-plugin/artifactId
version1.1/version
executions
execution
idsign-artifacts/id
phaseverify/phase
goals
goalsign/goal
/goals
/execution
/executions
/plugin
{code}
[1]
http://code.google.com/p/doclava/source/browse/tags/doclava-1.0.2/pom.xml
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Jan 23, 2011 at 7:37 PM, oliver oliver.bo...@gmail.com wrote:
Am 23.01.2011 um 18:51 schrieb Simone Tripodi:
Ciao Tommy ;)
I already met this problem, It's not a of key-size related issue. Try
setting the mavenExecutorId=forked-path so when releasing maven will
be forked and the gpg-plugin will prompt you insert the gpg
passphrase.
Otherwise you can use the -Dgpg.passphrase=XXX property but its use is
discouraged and you can easily understand why.
yes, that's clear. Is it possible to disable the gpg-plugin for the daily
build?
regards,
Oliver
-
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
