Re: [maven] Re: Auto building parent and sibling projects as needed
Le 11/09/2011 17:37, Jason Pyeron a écrit : -Original Message- From: Guillaume Polet Sent: Sunday, September 11, 2011 4:07 To: Maven Users List Subject: [maven] Re: Auto building parent and sibling projects as needed The problem is that a child does not know where the sources of its parents are located, Is it not the point ofrelativePath../pom.xml/relativePath? No, this simply indicates where to look relatively to find a pom.xml if it is not installed in your local repository (or a remote one where it could be fetched from). and therefore it is completely unable to trigger its build. You probably have set up one or more parent aggregator projects and you mapped this hierarchy onto the file/directory structure but this is not mandatory at all. You can very well use a parent just to define the default version to use for dependencies, or the default target of the compiler, other properties that are common through all your projects and many more things. You should probably read again the first two paragraphs here: http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project _Inheritance_vs_Project_Aggregation Read that before and again. See the bottom of the email and attachment (the poms). The first one explains the benefits of inheritance while the second explain the aggregation. Hope this helps you clear things out. Still stuck at the same place, but thanks for confirming what I read. Cheers, Guillaume Le 11/09/2011 06:21, Jason Pyeron a écrit : I am trying to understand why maven's reactor would not add a parent and a parent's children to the build when it is detected that the dependency is not in the repository. Is there a use case to NOT auto build? Or is there a technical hurdle to overcome to accomplish this in the reactor design? Could I be missing a concept on maven usage? I have a project which has a very large set of parent/child/sibling dependencies I am migrating from our ant build system. When an engineer needs to make changes on their part it would be best for them to execute mvn from that parts directory. Hard to say why your second build is failing. I just tried a similar setup and it worked in all cases: parent: 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/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdparent/artifactId packagingpom/packaging nameparent/name version1.0.0-SNAPSHOT/version modules moduleB/module moduleA/module /modules /project A: 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/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdA/artifactId nameA/name version1.0.0-SNAPSHOT/version packagingpom/packaging parent groupIdtest/groupId artifactIdparent/artifactId version1.0.0-SNAPSHOT/version relativePath../pom.xml/relativePath /parent /project B: 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/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdB/artifactId nameB/name version1.0.0-SNAPSHOT/version packagingpom/packaging parent groupIdtest/groupId artifactIdparent/artifactId version1.0.0-SNAPSHOT/version relativePath../pom.xml/relativePath /parent dependencies dependency groupIdtest/groupId artifactIdA/artifactId version1.0.0-SNAPSHOT/version /dependency /dependencies /project With the directory hierarchy: * parent * A * B and the results from the build: D:\tmp\parentmvn package [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] parent [INFO] A [INFO] B [INFO] [INFO] [INFO] Building parent 1.0.0-SNAPSHOT [INFO] [INFO] [INFO] [INFO] Building A 1.0.0-SNAPSHOT [INFO] [INFO] [INFO] [INFO] Building B 1.0.0-SNAPSHOT [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] parent SUCCESS [0.003s] [INFO] A . SUCCESS [0.001s] [INFO] B . SUCCESS [0.002s] [INFO]
Re: Should a plugin appear in pluginManagement if it already appears in build/plugins?
Now you're confusing me again. You say - below - that CLI (goal) invocations ignore the build/plugins settings. If so, then surely it's better to define everything in pluginMgmt, and just leave the build/plugins section to reference the plugin? In which case both goal and phase invocations share the settings. Otherwise CLI(goal) invocations might not be fully configured. Well, very often you're not going to execute the plugin goal directly from CLI. I'd say that most often you're not. It's like when coding, to implement stuff you don't currently need. It just makes things more complicated. /Anders The pluginManagement settings will I assume apply to all CLI (i.e. goal) invocations. Yes, if you add the config on the plugin level and not on a specific execution. This is presumably because individual goal invocation is not part of a phase and so ignores what is in build/plugins Right, and this has tricked a lot of new Maven users. /Anders But this is me. Others may very well have a different opinion. /Anders /Anders And some people like defining the version of plugins in the pluginMgmt section but not in build/plugins. Then you define this in a parent and only have one place to change when new versions are released. This is how I do it. Yes, that is mainly how it is being used. /Anders Thanks! On Sat, Sep 10, 2011 at 02:14, sebb seb...@gmail.com wrote: AIUI, both build/plugins and build/pluginManagement are inherited by child projects, the difference being that plugiManagement entries are only used if the child project references the plugin in its build/plugins section. That being the case, if a plugin is defined in build/plugins, is there any point also including it in the build/pluginManagement/plugins section? - 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 - 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 - 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 - 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 - 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
Missing Artifacts
Missing artifact commons-logging:commons-logging:jar:1.0.3:compile Missing artifact org.springframework:spring-webmvc:jar:3.0.5.RELEASE:compile Missing artifact org.springframework:spring-webmvc-portlet:jar:3.0.5.RELEASE:compile Missing artifact javax.servlet:jstl:jar:1.1.2:runtime Missing artifact taglibs:standard:jar:1.1.2:runtime I have all my jar files in the Maven dependencies even though i am getting the above error i have also tried with update dependencies but that too does not work. My pom.xml file: 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/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdspringapp2/groupId artifactIdspringapp2/artifactId packagingwar/packaging namespringapp2/name version1.0-SNAPSHOT/version descriptionstep by step spring/description build finalNamespringapp2/finalName plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.3.2/version configuration source1.5/source target1.5/target /configuration /plugin /plugins /build properties org.springframework.version3.0.5.RELEASE/org.springframework.version servlet.version2.5/servlet.version /properties dependencies dependency groupIdorg.springframework/groupId artifactIdspring-orm/artifactId version3.0.5.RELEASE/version scopecompile/scope /dependency dependency groupIdorg.springframework/groupId artifactIdspring-web/artifactId version3.0.5.RELEASE/version scopecompile/scope /dependency dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version3.0.5.RELEASE/version scopecompile/scope /dependency dependency groupIdorg.springframework/groupId artifactIdspring-webmvc-portlet/artifactId version3.0.5.RELEASE/version scopecompile/scope /dependency dependency groupIdorg.springframework/groupId artifactIdspring-context-support/artifactId version3.0.5.RELEASE/version scopecompile/scope /dependency dependency groupIdorg.springframework/groupId artifactIdspring-jms/artifactId version3.0.5.RELEASE/version scopecompile/scope /dependency dependency groupIdorg.springframework/groupId artifactIdspring-test/artifactId version3.0.5.RELEASE/version scopecompile/scope /dependency dependency groupIdcommons-logging/groupId artifactIdcommons-logging/artifactId version1.0.3/version scopecompile/scope /dependency dependency groupIdjavax.servlet/groupId artifactIdjstl/artifactId version1.1.2/version scoperuntime/scope /dependency dependency groupIdjavax.servlet/groupId artifactIdservlet-api/artifactId version2.5/version /dependency dependency groupIdtaglibs/groupId artifactIdstandard/artifactId version1.1.2/version scoperuntime/scope /dependency /dependencies /project Can any one help me in resolving this issue Thanks in advance -- View this message in context: http://maven.40175.n5.nabble.com/Missing-Artifacts-tp4793474p4793474.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail:
RE: [maven] Re: Auto building parent and sibling projects as needed
-Original Message- From: Guillaume Polet Sent: Monday, September 12, 2011 3:01 To: Maven Users List Subject: Re: [maven] Re: Auto building parent and sibling projects as needed Le 11/09/2011 17:37, Jason Pyeron a écrit : -Original Message- From: Guillaume Polet Sent: Sunday, September 11, 2011 4:07 To: Maven Users List Subject: [maven] Re: Auto building parent and sibling projects as needed The problem is that a child does not know where the sources of its parents are located, Is it not the point ofrelativePath../pom.xml/relativePath? No, this simply indicates where to look relatively to find a pom.xml if it is not installed in your local repository (or a remote one where it could be fetched from). Is this a design or bug of the reactor? and therefore it is completely unable to trigger its build. You probably have set up one or more parent aggregator projects and you mapped this hierarchy onto the file/directory structure but this is not mandatory at all. You can very well use a parent just to define the default version to use for dependencies, or the default target of the compiler, other properties that are common through all your projects and many more things. You should probably read again the first two paragraphs here: http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project snip/ Hard to say why your second build is failing. I just tried a similar setup and it worked in all cases: parent: The difference is that you are saying that the children A B are pom packaged, which does not cause compile to kick off, which inturn does not need the dependency. snip/ B: 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/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdB/artifactId nameB/name version1.0.0-SNAPSHOT/version packagingpom/packaging parent groupIdtest/groupId artifactIdparent/artifactId version1.0.0-SNAPSHOT/version relativePath../pom.xml/relativePath snip/ Your log says the following: -- cannot find the pom.xml from project A (This I don't understand why) -- jar file of project A cannot be found Try 'mvn install' so that the pom and the jar file is deployed locally because it will not find the jar in the target directory. An install would not be appropiate for this part of the development lifecycle. For argument sake, lets assume that not every module passes all unit tests but all compile and we are in a SNAPSHOT versioning. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven] Re: Auto building parent and sibling projects as needed
Le 12/09/2011 15:33, Jason Pyeron a écrit : -Original Message- From: Guillaume Polet Sent: Monday, September 12, 2011 3:01 To: Maven Users List Subject: Re: [maven] Re: Auto building parent and sibling projects as needed Le 11/09/2011 17:37, Jason Pyeron a écrit : -Original Message- From: Guillaume Polet Sent: Sunday, September 11, 2011 4:07 To: Maven Users List Subject: [maven] Re: Auto building parent and sibling projects as needed The problem is that a child does not know where the sources of its parents are located, Is it not the point ofrelativePath../pom.xml/relativePath? No, this simply indicates where to look relatively to find a pom.xml if it is not installed in your local repository (or a remote one where it could be fetched from). Is this a design or bug of the reactor? It is by design. If you want to build a parent, then just go to the parent. If the parent build was triggered, you would not have any possibility to just build a child. and therefore it is completely unable to trigger its build. You probably have set up one or more parent aggregator projects and you mapped this hierarchy onto the file/directory structure but this is not mandatory at all. You can very well use a parent just to define the default version to use for dependencies, or the default target of the compiler, other properties that are common through all your projects and many more things. You should probably read again the first two paragraphs here: http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project snip/ Hard to say why your second build is failing. I just tried a similar setup and it worked in all cases: parent: The difference is that you are saying that the children A B are pom packaged, which does not cause compile to kick off, which inturn does not need the dependency. snip/ You can very well change them into jar's and add a dummy class in A and B project. It still works, I tried it myself. B: 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/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdtest/groupId artifactIdB/artifactId nameB/name version1.0.0-SNAPSHOT/version packagingpom/packaging parent groupIdtest/groupId artifactIdparent/artifactId version1.0.0-SNAPSHOT/version relativePath../pom.xml/relativePath snip/ Your log says the following: -- cannot find the pom.xml from project A (This I don't understand why) -- jar file of project A cannot be found Try 'mvn install' so that the pom and the jar file is deployed locally because it will not find the jar in the target directory. An install would not be appropiate for this part of the development lifecycle. For argument sake, lets assume that not every module passes all unit tests but all compile and we are in a SNAPSHOT versioning. -Jason OK, maybe some expert Maven user knows how to go around such a situation. AFIK (and my knowledge is not very big), you have two options: 1) You build the parent, the children will follow and you should be fine 2) You do an 'mvn install': since you are using SNAPSHOT it should not be a problem to have unstable jars (although using -DskipTest=true is not recommended, but that's another story) and since 'install' deploys the artifacts locally, you do not pollute anyone else's repository. Sorry if I can't help you more than that. Cheers, Guillaume -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - 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
Why does dependency:go-offline -DexcludeGroupIds=xxxx still try to resolve artifacts in the excluded group xxxx?
After reading:
http://maven.apache.org/plugins/maven-dependency-plugin/usage.html and
http://maven.apache.org/plugins/maven-dependency-plugin/go-offline-mojo.html
The go-offline behavior is suspicious to me. See the * lines below for
details.
Suggestions welcome.
mvn -U -X dependency:go-offline -DexcludeGroupIds=us.pdinc.product.cascade
snip/
[DEBUG] ---
[DEBUG] Goal:
org.apache.maven.plugins:maven-dependency-plugin:2.1:go-offline (default-cli)
[DEBUG] Style: Regular
[DEBUG] Configuration: ?xml version=1.0 encoding=UTF-8?
configuration
classifier default-value=${classifier}/classifier
excludeArtifactIds
default-value=${excludeArtifactIds}/excludeArtifactIds
excludeClassifiers
default-value=${excludeClassifiers}/excludeClassifiers
excludeGroupIds default-value=${excludeGroupIds}/excludeGroupIds
excludeScope default-value=${excludeScope}/excludeScope
excludeTransitive
default-value=false${excludeTransitive}/excludeTransitive
excludeTypes default-value=${excludeTypes}/excludeTypes
includeArtifactIds
default-value=${includeArtifactIds}/includeArtifactIds
includeClassifiers
default-value=${includeClassifiers}/includeClassifiers
includeGroupIds default-value=${includeGroupIds}/includeGroupIds
includeScope default-value=${includeScope}/includeScope
includeTypes default-value=${includeTypes}/includeTypes
local${localRepository}/local
markersDirectory
default-value=${project.build.directory}/dependency-maven-plugin-markers${mar
kersDirectory}/markersDirectory
outputAbsoluteArtifactFilename
default-value=false${outputAbsoluteArtifactFilename}/outputAbsoluteArtifactF
ilename
outputFile${outputFile}/outputFile
overWriteIfNewer default-value=true${overWriteIfNewer}/overWriteIfNewer
overWriteReleases
default-value=false${overWriteReleases}/overWriteReleases
overWriteSnapshots
default-value=false${overWriteSnapshots}/overWriteSnapshots
project${project}/project
reactorProjects${reactorProjects}/reactorProjects
remoteRepos${project.remoteArtifactRepositories}/remoteRepos
silent default-value=false${silent}/silent
type default-value=java-source${type}/type
/configuration
[DEBUG] ===
[INFO]
[INFO] maven-dependency-plugin:2.1:go-offline (default-cli) @ core
[INFO]
[INFO] --- maven-dependency-plugin:2.1:resolve-plugins (resolve-plugins) @ core
---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-dependency-plugin:2.1:resolve-plugins from plugin
realm ClassRealm[pluginorg.apache.maven.plugins:maven-dependency-plugin:2.1,
parent: sun.misc.Launcher$AppClassLoader@35a16869]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-dependency-plugin:2.1:resolve-plugins' with
basic configurator --
*
*
*
[DEBUG] (f) excludeGroupIds = us.pdinc.product.cascade
*
*
*
[DEBUG] (f) excludeTransitive = false
[DEBUG] (s) local =id: local
url:
file:///C:/Documents%20and%20Settings/All%20Users/Desktop/projects/cascade/trunk
/var/opt/apache-maven-3.0.4-SNAPSHOT/../../../lib/mvn/
layout: none
[DEBUG] (s) markersDirectory = C:\Documents and Settings\All
Users\Desktop\projects\cascade\trunk\children\core\out\dependency-maven-plugin-m
arkers
[DEBUG] (f) outputAbsoluteArtifactFilename = false
[DEBUG] (f) overWriteIfNewer = true
[DEBUG] (f) overWriteReleases = false
[DEBUG] (f) overWriteSnapshots = false
[DEBUG] (f) project = MavenProject: us.pdinc.product.cascade:core:1.0.0 @
C:\Documents and Settings\All
Users\Desktop\projects\cascade\trunk\children\core\pom.xml
[DEBUG] (f) reactorProjects = [MavenProject:
us.pdinc.product.cascade:parent:1.0.0 @ C:\Documents and Settings\All
Users\Desktop\projects\cascade\trunk\pom.xml, MavenProject:
us.pdinc.product.cascade:children:1.0.0 @ C:\Documents and Settings\All
Users\Desktop\projects\cascade\trunk\children\pom.xml, MavenProject:
us.pdinc.product.cascade:test-db:1.0.0 @ C:\Documents and Settings\All
Users\Desktop\projects\cascade\trunk\children\test-db\pom.xml, MavenProject:
us.pdinc.product.cascade:core:1.0.0 @ C:\Documents and Settings\All
Users\Desktop\projects\cascade\trunk\children\core\pom.xml, MavenProject:
us.pdinc.product.cascade:web:1.0.0 @ C:\Documents and Settings\All
Users\Desktop\projects\cascade\trunk\children\web\pom.xml]
[DEBUG] (f) remotePluginRepositories = [ id: central
url: http://repo1.maven.apache.org/maven2
layout: default
snapshots: [enabled = false, update = daily]
releases: [enabled = true, update = never]
]
[DEBUG] (s) remoteRepos = [ id: central
url: http://repo1.maven.apache.org/maven2
layout: default
snapshots: [enabled = false, update = daily]
releases: [enabled = true, update = daily]
]
[DEBUG] (f) silent = false
Re: Missing Artifacts
Missing artifact commons-logging:commons-logging:jar:1.0.3:compile Missing artifact org.springframework:spring-webmvc:jar:3.0.5.RELEASE:compile Missing artifact org.springframework:spring-webmvc-portlet:jar:3.0.5.RELEASE:compile Missing artifact javax.servlet:jstl:jar:1.1.2:runtime Missing artifact taglibs:standard:jar:1.1.2:runtime Search for your artifacts in the Nexus search engine for Central: http://search.maven.org/#browse Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Preserving whitespace when configuring plugin?
I'm writing a plugin. One of the things I need to do is preserve whitespace
in a particular configuration setting.
So:
configuration
foobar
/foobar!-- I want that line ending to be preserved --
/configuration
The foobar parameter has a default-value set on it.
The net effect I see is that no matter how I protect the whitespace, it is
still being treated as not set, and I'm getting the default value instead.
Here are the things I tried:
foobar![CDATA[
]]/foobar
foobar${line.separator}/foobar
foobar xml:space=preserve
/foobar
foobarx0d;/foobar
Is this a bug in plugin configuration?
Thanks,
Laird
--
http://about.me/lairdnelson
Re: Why does dependency:go-offline -DexcludeGroupIds=xxxx still try to resolve artifacts in the excluded group xxxx?
mvn -U -X dependency:go-offline -DexcludeGroupIds=us.pdinc.product.cascade [INFO] maven-dependency-plugin:2.1:go-offline (default-cli) @ core [DEBUG] (f) excludeGroupIds = us.pdinc.product.cascade Downloading: http://repo1.maven.apache.org/maven2/us/pdinc/product/cascade/test-db/1.0.0/test -db-1.0.0.jar I agree this looks like a bug. But you are using version 2.1 of the plugin while 2.3 is the latest, can you try that version before filing a bug report? It may already be fixed in 2.2 or 2.3. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: [maven] Re: Why does dependency:go-offline -DexcludeGroupIds=xxxx still try to resolve artifacts in the excluded group xxxx?
-Original Message- From: Wayne Fay Sent: Monday, September 12, 2011 11:22 To: Maven Users List Subject: [maven] Re: Why does dependency:go-offline -DexcludeGroupIds= still try to resolve artifacts in the excluded group ? mvn -U -X dependency:go-offline -DexcludeGroupIds=us.pdinc.product.cascade Hmmm, why is 2.1 the default? [INFO] maven-dependency-plugin:2.1:go-offline (default-cli) @ core [DEBUG] (f) excludeGroupIds = us.pdinc.product.cascade Downloading: http://repo1.maven.apache.org/maven2/us/pdinc/product/cascade/test-db/ 1.0.0/test -db-1.0.0.jar I agree this looks like a bug. But you are using version 2.1 of the plugin while 2.3 is the latest, can you try that version before filing a bug report? It may already be fixed in 2.2 or 2.3. mvn org.apache.maven.plugins:maven-dependency-plugin:2.3:go-offline -DexcludeGroupIds=us.pdinc.product.cascade Same issue. To JIRA I go, but which jira system? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven] Re: Why does dependency:go-offline -DexcludeGroupIds=xxxx still try to resolve artifacts in the excluded group xxxx?
Hmmm, why is 2.1 the default? Default versions of plugins depend on the version of Maven you are using as the versions are set in a pom in one of Maven's jars. You should nearly always specify (in pom or CLI) the version of any plugin you are using to be certain the proper one is used, otherwise the behavior can be uncertain. Same issue. To JIRA I go, but which jira system? Go to the m-dep-p site you sent the url to earlier. On the left, click Project Information, then Issue Tracking on that page. This will provide the proper URL to the right JIRA instance. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: [maven] Re: Why does dependency:go-offline -DexcludeGroupIds=xxxx still try to resolve artifacts in the excluded group xxxx?
-Original Message- From: Wayne Fay Sent: Monday, September 12, 2011 11:22 To: Maven Users List Subject: [maven] Re: Why does dependency:go-offline -DexcludeGroupIds= still try to resolve artifacts in the excluded group ? mvn -U -X dependency:go-offline -DexcludeGroupIds=us.pdinc.product.cascade [INFO] maven-dependency-plugin:2.1:go-offline (default-cli) @ core [DEBUG] (f) excludeGroupIds = us.pdinc.product.cascade Downloading: http://repo1.maven.apache.org/maven2/us/pdinc/product/cascade/test-db/ 1.0.0/test -db-1.0.0.jar I agree this looks like a bug. But you are using version 2.1 of the plugin while 2.3 is the latest, can you try that version before filing a bug report? It may already be fixed in 2.2 or 2.3. Thanks. http://jira.codehaus.org/browse/MDEP-323 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Preserving whitespace when configuring plugin?
On Mon, Sep 12, 2011 at 11:01 AM, Laird Nelson ljnel...@gmail.com wrote: I'm writing a plugin. One of the things I need to do is preserve whitespace in a particular configuration setting. Somewhat more alarmingly, it looks like leading and trailing whitespace is trimmed as well. So: someConfigurationElement Hello! /someConfigurationElement ...is trimmed and becomes simply: Hello! ...in my code (no leading or trailing space). The same effect is observed with CDATA: someConfigurationElement![CDATA[ Hello! ]]/someConfigurationElement I'm guessing this is a bug in the internals of some Plexus component somewhere. Where should I file the bug? Thanks, Laird -- http://about.me/lairdnelson
Re: Preserving whitespace when configuring plugin?
On Mon, Sep 12, 2011 at 1:46 PM, Laird Nelson ljnel...@gmail.com wrote: Somewhat more alarmingly, it looks like leading and trailing whitespace is trimmed as well. So: someConfigurationElement Hello! /someConfigurationElement ...is trimmed and becomes simply: Hello! ...in my code (no leading or trailing space). I've filed http://jira.codehaus.org/browse/PLX-461 to track this; it may very well be in the wrong place or the wrong project. The problem shows up as well by simply running mvn help:effective-pom, so no test case is needed. Just put a fragment like this in any plugin stanza: someConfigurationElement Hello! /someConfigurationElement ...and then run mvn help:effective-pom, and you'll see: someConfigurationElementHello!/someConfigurationElement ...in the output. This is true whether you use CDATA, literal values, entities, or the xml:space=preserve attribute. Best, Laird -- http://about.me/lairdnelson
RE: [maven] Re: Preserving whitespace when configuring plugin?
-Original Message- From: Laird Nelson [mailto:ljnel...@gmail.com] Sent: Monday, September 12, 2011 14:11 To: Maven Users List Subject: [maven] Re: Preserving whitespace when configuring plugin? On Mon, Sep 12, 2011 at 1:46 PM, Laird Nelson ljnel...@gmail.com wrote: Somewhat more alarmingly, it looks like leading and trailing whitespace is trimmed as well. So: someConfigurationElement Hello! /someConfigurationElement ...is trimmed and becomes simply: Hello! ...in my code (no leading or trailing space). I've filed http://jira.codehaus.org/browse/PLX-461 to track this; it may very well be in the wrong place or the wrong project. This might be related to the booleans issue I was having too. http://jira.codehaus.org/browse/MNG-5166, it too was a result of stripping away whitespace and tags enmass. The problem shows up as well by simply running mvn help:effective-pom, so no test case is needed. Just put a fragment like this in any plugin stanza: someConfigurationElement Hello! /someConfigurationElement ...and then run mvn help:effective-pom, and you'll see: someConfigurationElementHello!/someConfigurationElement ...in the output. This is true whether you use CDATA, literal values, entities, or the xml:space=preserve attribute. Best, Laird -- http://about.me/lairdnelson -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven] Re: Preserving whitespace when configuring plugin?
On Mon, Sep 12, 2011 at 2:24 PM, Jason Pyeron jpye...@pdinc.us wrote: This might be related to the booleans issue I was having too. http://jira.codehaus.org/browse/MNG-5166, it too was a result of stripping away whitespace and tags en masse. You can test for the presence of this particular bug by just doing mvn help:effective-pom; you can see that leading, trailing and only whitespace contents are removed from plugin configuration elements before, I think, things even get sent off to the underlying configuration machinery. This is straight XML parser abuse, I think. Best, Laird -- http://about.me/lairdnelson
RE: [maven] Re: Preserving whitespace when configuring plugin?
Am 12.09.2011 20:18 schrieb Jason Pyeron jpye...@pdinc.us: -Original Message- From: Laird Nelson [mailto:ljnel...@gmail.com] Sent: Monday, September 12, 2011 14:11 To: Maven Users List Subject: [maven] Re: Preserving whitespace when configuring plugin? On Mon, Sep 12, 2011 at 1:46 PM, Laird Nelson ljnel...@gmail.com wrote: Somewhat more alarmingly, it looks like leading and trailing whitespace is trimmed as well. So: someConfigurationElement Hello! /someConfigurationElement ...is trimmed and becomes simply: Hello! ...in my code (no leading or trailing space). I've filed http://jira.codehaus.org/browse/PLX-461 to track this; it may very well be in the wrong place or the wrong project. This might be related to the booleans issue I was having too. http://jira.codehaus.org/browse/MNG-5166, it too was a result of stripping away whitespace and tags enmass. This hit me too when I was trying to configure the commit message prefix of the release plugin to contain whitespace at the end, so it looks like [some prefix] prepare for next development iteration. Best I could achieve was [some prefix]_prepare for next development iteration, which is a bit ugly in my eyes. Would love to see it fixed. Best regards Ansgar The problem shows up as well by simply running mvn help:effective-pom, so no test case is needed. Just put a fragment like this in any plugin stanza: someConfigurationElement Hello! /someConfigurationElement ...and then run mvn help:effective-pom, and you'll see: someConfigurationElementHello!/someConfigurationElement ...in the output. This is true whether you use CDATA, literal values, entities, or the xml:space=preserve attribute. Best, Laird -- http://about.me/lairdnelson -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: exclude a list of groupId:artifactId using maven-dependency-plugin
Jane Young-2 wrote: Hi, Is there a way to exclude a comma separated list of groupId:artifactId using maven-dependency-plugin:copy-dependencies? The reason I'm asking this is that there are identical artifactIds but with different groupIds in the dependency tree and I want to distinguish the artifactId to exclude. However, I do not want to use excludeGroupIds since there are artifacts in the groupId that I want to copy. Thanks, Jane I need something similar. excludeArtifactIds fails to exclude artifacts containing classifiers, and I don't want to exclude all artifacts with that classifier. A comma-separated groupId:artifactId:version:packaging:classifier would be perfect (where version, packaging, classifier are optional). Any ideas? Thanks, Gili -- View this message in context: http://maven.40175.n5.nabble.com/exclude-a-list-of-groupId-artifactId-using-maven-dependency-plugin-tp4762053p4795458.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: [maven] Re: Preserving whitespace when configuring plugin?
On Mon, Sep 12, 2011 at 2:38 PM, Ansgar Konermann ansgar.konerm...@googlemail.com wrote: This hit me too when I was trying to configure the commit message prefix of the release plugin to contain whitespace at the end, so it looks like [some prefix] prepare for next development iteration. Best I could achieve was [some prefix]_prepare for next development iteration, which is a bit ugly in my eyes. Would love to see it fixed. Please vote for http://jira.codehaus.org/browse/MODELLO-256 and for http://jira.codehaus.org/browse/PLX-461. Best, Laird -- http://about.me/lairdnelson
Re: [maven] Re: Preserving whitespace when configuring plugin?
On Mon, Sep 12, 2011 at 2:57 PM, Laird Nelson ljnel...@gmail.com wrote: Please vote for http://jira.codehaus.org/browse/MODELLO-256 and for http://jira.codehaus.org/browse/PLX-461. It looks to me like the Modello project, which generates the readers that are capable of parsing a pom.xml, is at least capable of seeing if a field can be trimmed. Unfortunately I can't tell how this determination is made. There is a class in Modello somewhere called XmlFieldMetaData that has an isTrim() method, and the reader that is generated does seem to obey this directive. Now how you could possibly influence the pom.xml reader to obey this directive when it's parsing the pom.xml for certain elements is entirely beyond me. Help? Best, Laird -- http://about.me/lairdnelson
Re: [maven] Re: Preserving whitespace when configuring plugin?
Your best option of to use a configuration parameter that references an XML configuration and use decentxml[1] to read in that XML to preserve all whitespace and formatting. I'm not changing the way the trimming behaviour works now would be the wisest thing to do after operating that way for so long, but I would agree that it should respect CDATA blocks if it's not. At any your first option using decentxml will get you to a solution that works faster. [1]: http://code.google.com/p/decentxml/ On Sep 12, 2011, at 3:09 PM, Laird Nelson wrote: On Mon, Sep 12, 2011 at 2:57 PM, Laird Nelson ljnel...@gmail.com wrote: Please vote for http://jira.codehaus.org/browse/MODELLO-256 and for http://jira.codehaus.org/browse/PLX-461. It looks to me like the Modello project, which generates the readers that are capable of parsing a pom.xml, is at least capable of seeing if a field can be trimmed. Unfortunately I can't tell how this determination is made. There is a class in Modello somewhere called XmlFieldMetaData that has an isTrim() method, and the reader that is generated does seem to obey this directive. Now how you could possibly influence the pom.xml reader to obey this directive when it's parsing the pom.xml for certain elements is entirely beyond me. Help? Best, Laird -- http://about.me/lairdnelson Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C.
Re: [maven] Re: Preserving whitespace when configuring plugin?
On Mon, Sep 12, 2011 at 3:19 PM, Jason van Zyl ja...@maven.org wrote: I'm not [sure that] changing the way the trimming behaviour works now would be the wisest thing to do after operating that way for so long I agree, and it's why I'm still a little dopey and confused as to why this problem would need to be addressed in some global fashion. I'm looking for some kind of selective way (don't care what it is) for whitespace to be preserved in pom.xml configuration elements (only). The standards-compliant way to do it without even having to touch CDATA is to honor the (hard-coded) xml:space=preserve attribute. Since Modello never outputs this attribute, or reads it, anywhere, it would seem like honoring this attribute when it is present would be the simplest way to fix this issue without affecting anything about backwards compatibility. Regarding my plugin, I have a workaround; thanks. Best, Laird -- http://about.me/lairdnelson
How can I tell if I'm building the parent or a module?
Hi, I'm using Maven 3.0.3. Within an antrun execution, how can I tell if I'm building a parent or building one of the modules that inherits from the parent? This antrun execution is located within the parent pom.xml file. Thanks, - Dave -- View this message in context: http://maven.40175.n5.nabble.com/How-can-I-tell-if-I-m-building-the-parent-or-a-module-tp4795683p4795683.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: How can I tell if I'm building the parent or a module?
Am 12.09.2011 21:50, schrieb laredotornado-3:
Hi,
I'm using Maven 3.0.3. Within an antrun execution, how can I tell if I'm
building a parent or building one of the modules that inherits from the
parent? This antrun execution is located within the parent pom.xml file.
Put the following task into your antrun plugin configuration:
echoRunning from project ${project.groupId}:${project.artifactId}/echo
Why does this work? Even though the plugin configuration is inherited
from the parent, the properties are resolved in the context of the
actually executing POM, that is: if the plugin runs in the child module,
you'll get the child module's groupId and artifactId printed.
Best regards
Ans
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven] Re: Preserving whitespace when configuring plugin?
On Sep 12, 2011, at 3:31 PM, Laird Nelson wrote: On Mon, Sep 12, 2011 at 3:19 PM, Jason van Zyl ja...@maven.org wrote: I'm not [sure that] changing the way the trimming behaviour works now would be the wisest thing to do after operating that way for so long I agree, and it's why I'm still a little dopey and confused as to why this problem would need to be addressed in some global fashion. I'm looking for some kind of selective way (don't care what it is) for whitespace to be preserved in pom.xml configuration elements (only). Even that may cause problems, the behavior has been there so long you just have no way of telling. The standards-compliant way to do it without even having to touch CDATA is to honor the (hard-coded) xml:space=preserve attribute. Since Modello never outputs this attribute, or reads it, anywhere, it would seem like honoring this attribute when it is present would be the simplest way to fix this issue without affecting anything about backwards compatibility. That would be a good way to do it. Regarding my plugin, I have a workaround; thanks. Good good. Best, Laird -- http://about.me/lairdnelson Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We all have problems. How we deal with them is a measure of our worth. -- Unknown
RE: [maven] Re: Preserving whitespace when configuring plugin?
-Original Message- From: Laird Nelson [mailto:ljnel...@gmail.com] Sent: Monday, September 12, 2011 15:31 To: Maven Users List Subject: Re: [maven] Re: Preserving whitespace when configuring plugin? On Mon, Sep 12, 2011 at 3:19 PM, Jason van Zyl ja...@maven.org wrote: I'm not [sure that] changing the way the trimming behaviour works now would be the wisest thing to do after operating that way for so long I agree, and it's why I'm still a little dopey and confused as to why this problem would need to be addressed in some global fashion. I'm looking for some kind of selective way (don't care what it is) for whitespace to be preserved in pom.xml configuration elements (only). The standards-compliant way to do it without even having to touch CDATA is to honor the (hard-coded) xml:space=preserve attribute. Since Modello never outputs this attribute, or reads it, anywhere, it would seem like honoring this attribute when it is present would be the simplest way to fix this issue without affecting anything about backwards compatibility. I think that supporting the xml:space='preserve' would be best as it would be backwards compatible. But there are other disfunctions in the same parsing logic too. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven] Re: Preserving whitespace when configuring plugin?
Am 12.09.2011 22:11, schrieb Jason Pyeron: I think that supporting the xml:space='preserve' would be best as it would be backwards compatible. But there are other disfunctions in the same parsing logic too. @Jason van Zyl: any chances to clean up these other disfunctions somewhen in the future, maybe under the hood of polyglot maven? What's the current status of polyglot maven actually? Does it make significant progress, can we hope to see a release anytime soon? Best regards Ansgar - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
hyperlinks out of description?
Is there any way to embed hyperlinks in the POM description element? If I put them in plain, the result is an invalid document; if I wrap them in CDATA then the markup comes through. Adding and using the XHTML namespace made no difference with the plain markup. The description seems like the right place to link to e.g. protocol specifications and other standards. Like: BaloneySoft FooPlex implements aour profile/a of aRFC 1149/a. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpxGoyowWWJI.pgp Description: PGP signature
Re: [maven] Re: Preserving whitespace when configuring plugin?
On Sep 12, 2011, at 4:13 PM, Ansgar Konermann wrote: Am 12.09.2011 22:11, schrieb Jason Pyeron: I think that supporting the xml:space='preserve' would be best as it would be backwards compatible. But there are other disfunctions in the same parsing logic too. @Jason van Zyl: any chances to clean up these other disfunctions somewhen in the future, maybe under the hood of polyglot maven? What's the current status of polyglot maven actually? Does it make significant progress, can we hope to see a release anytime soon? This doesn't have anything to do with Polyglot Maven. It's the XML parser generator in Modello. Best regards Ansgar - 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 -
Re: How can I tell if I'm building the parent or a module?
That is a great idea and works perfectly. Thanks, - Dave -- View this message in context: http://maven.40175.n5.nabble.com/How-can-I-tell-if-I-m-building-the-parent-or-a-module-tp4795683p4796010.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: [maven] Re: Preserving whitespace when configuring plugin?
Am 12.09.2011 23:21, schrieb Jason van Zyl: On Sep 12, 2011, at 4:13 PM, Ansgar Konermann wrote: Am 12.09.2011 22:11, schrieb Jason Pyeron: I think that supporting the xml:space='preserve' would be best as it would be backwards compatible. But there are other disfunctions in the same parsing logic too. @Jason van Zyl: any chances to clean up these other disfunctions somewhen in the future, maybe under the hood of polyglot maven? What's the current status of polyglot maven actually? Does it make significant progress, can we hope to see a release anytime soon? This doesn't have anything to do with Polyglot Maven. It's the XML parser generator in Modello. Sure, but as it seems that the existing XML parser should keep certain bugs by intention, I'm thinking of alternative ways to get to a cleaner, more bug-free parser. I thought polyglot maven could be an option. Sorry if that was not expressed so clearly. Best Ansgar - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Exclusions for maven plugin
No such luck. I added the extensions code in the pom, but wagon still insists on writing (and destroying) my known_hosts file. This is what I added to build section of the pom file extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ssh/artifactId version1.0/version /extension extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ssh-common/artifactId version1.0/version /extension /extensions Is there anything else I can try? Regards, Niranjan On 09/11/2011 04:42 PM, Benson Margulies wrote: The quickest solution is to use abuildextensionsextension element in the POM to call out the version of the wagon plugin that you want. On Sun, Sep 11, 2011 at 7:18 PM, Niranjan Raonhr...@gmail.com wrote: Hi there, It looks like I might be getting bitten by the bug as mentioned at http://jira.codehaus.org/browse/WAGON-253. My symptoms were contents of known_hosts file were disappearing except for the one server. As a result all other builds were failing as they could not connect/ssh to source control host - we do use git. mvn clean package cargo:redeploy site:site site:stage-deploy site:deploy Above is the command hudson executes to deploy one war file on qa server and deploy documentation and bunch of other stuff on documentation server. Both cargo and site plugins seem to be wagon plugin and I found multiple versions of wagon plugin in my hudson's local maven repository. If I make known_hosts file readonly, build does fail with the error, can not write to known_hosts file. Direct ssh or scp to remote hosts using hudson as user, does work as expected as password less login is setup correctly. What is the best way to tell maven plugins to use the latest version of wagon plugin. The bug mentioned above is resolved back in 2008/2009. Using maven2, on ubuntu 11.04. Cargo plugin version is 1.1.2 explicitly mentioned in POM, site plugin is not mentioned in POM at all so should be using latest. Last relevant lines from the build log Using private key: /var/lib/hudson/.ssh/id_rsa scp://wiki/var/www/docs/staging/ - Session: Connection refused scp://wiki/var/www/docs/staging/ - Session: Disconnecting scp://wiki/var/www/docs/staging/ - Session: Disconnected [HUDSON] Archiving disabled - not archiving /var/lib/hudson/jobs/FiPort QA deployer/workspace/pom.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Connection aborted - failed to write to known_hosts. Reason: /var/lib/hudson/.ssh/known_hosts (Permission denied) Regards, Niranjan - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: overhead in running maven jetty:run
I know that is how I work with most of my web apps. Unless you need something very specific to the app container that you are working with, I wouldn't think there are much better solutions out there, glassfish/grizzly, jboss etc. On Aug 11, 2011 11:54 AM, Tommy Chheng tommy.chh...@gmail.com wrote: Is there much of an overhead of running a servlet via mvn jetty:run vs an embedded jetty Main class in a production environment? Any other concerns? I typically stick a war into a jetty web-apps directory but i find it easier to run mvn jetty:run. Was curious if there's any negative to running it under maven. -- @tommychheng http://tommy.chheng.com
Re: [maven] Re: Preserving whitespace when configuring plugin?
On Sep 12, 2011, at 5:50 PM, Ansgar Konermann wrote: Am 12.09.2011 23:21, schrieb Jason van Zyl: On Sep 12, 2011, at 4:13 PM, Ansgar Konermann wrote: Am 12.09.2011 22:11, schrieb Jason Pyeron: I think that supporting the xml:space='preserve' would be best as it would be backwards compatible. But there are other disfunctions in the same parsing logic too. @Jason van Zyl: any chances to clean up these other disfunctions somewhen in the future, maybe under the hood of polyglot maven? What's the current status of polyglot maven actually? Does it make significant progress, can we hope to see a release anytime soon? This doesn't have anything to do with Polyglot Maven. It's the XML parser generator in Modello. Sure, but as it seems that the existing XML parser should keep certain bugs by intention, I'm thinking of alternative ways to get to a cleaner, more bug-free parser. I thought polyglot maven could be an option. I think the solution offered was a perfect one. The feature is activated by user acknowledgement, inclusion of xml:space=preserve, and everyone else is left to the standard behavior. That could be integrated pretty easily into the existing modello/xpp3 framework. I'd be happy to help anyone who wanted to take a pass at submitting a pull request. Sorry if that was not expressed so clearly. Polyglot Maven, as an independent project, is not something I'm working on anymore. Nor the Maven Shell for that matter. Best Ansgar - 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 - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language
Re: Missing Artifacts
Thanks a lot it works fine now. -- View this message in context: http://maven.40175.n5.nabble.com/Missing-Artifacts-tp4793474p4797101.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: About transitive dependencies
Why do you declare a test (scope) dependency to B if you call it at runtime? AFIK, B should not be used when you compile C since you declared a test (scope) dependency. -- Guillaume Le 11/09/2011 08:25, JVerstry a écrit : I came across an issue I raised on StackOverflow: http://stackoverflow.com/questions/7373105/noclassdeffounderror-org-junit-afterclass-during-annotation-processing/7375380#7375380 I have a library B having a compile dependency (i.e. scope) on A. I have a library C having a test dependency (i.e. scope) on B. When I compile C, it includes B, but not A. And since C calls B calls A, it crashes at runtime. Apparently, this is how it should work according to the dependency scope (http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope). Yet, why should users of C explicitly declare a compile dependency to A, when we know at compile time that A will be required? Shouldn't the transitivity rule be that if you have such a transitive relationship, A should always be compile dependency of A? Or is there something I am missing? The problem is that the runtime crash is really late to be notified about this issue. It does not fit with the maven philosophy. Thanks, JVerstry - 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
