[jira] Created: (ARCHETYPE-167) Archiva : mvn archetype:create without guest user
Archiva : mvn archetype:create without guest user - Key: ARCHETYPE-167 URL: http://jira.codehaus.org/browse/ARCHETYPE-167 Project: Maven Archetype Issue Type: Bug Components: Archetypes Environment: Windows XP / Maven 2.0.9 / Archiva 1.0.2 Reporter: Florian I try to launch mvn archetype:create with an archetype located on an archiva proxy. In archiva, when guest user isn't lock, it works, but when i lock guest user , it's not possible. The command : mvn archetype:create -DgroupId=com.myserver -DartifactId=myserver -DarchetypeGroupId=com.archetypes -DarchetypeArtifactId=server_archetype -DarchetypeVersion=2.0 -DremoteRepositories=http://url/ I try to add -DRepositoryId but it's not ok. it isn't possible to pass username and password to archiva. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-72) Add support for specifying includes/excludes in an external file
[ http://jira.codehaus.org/browse/MCOMPILER-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133645#action_133645 ] Thomas Diesler commented on MCOMPILER-72: - Folks have been reporting [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-compiler-plugin:2.0.2.SP1:compile': Una ble to find the mojo 'org.apache.maven.plugins:maven-compiler-plugin:2.0.2.SP1:compile' in the plugin 'org.apache.maven.plugins:ma ven-compiler-plugin' org/codehaus/plexus/compiler/util/scan/InclusionScanException [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plug ins:maven-compiler-plugin:2.0.2.SP1:compile': Unable to find the mojo 'org.apache.maven.plugins:maven-compiler-plugin:2.0.2.SP1:co mpile' in the plugin 'org.apache.maven.plugins:maven-compiler-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:543) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the mojo 'org.apache.maven.plugins:maven-compiler-plugin :2.0.2.SP1:compile' in the plugin 'org.apache.maven.plugins:maven-compiler-plugin' at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:575) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:425) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Unable to lookup component 'org.apache.mav en.plugin.Mojoorg.apache.maven.plugins:maven-compiler-plugin:2.0.2.SP1:compile', it could not be created at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:335) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:566) ... 18 more Caused by: org.codehaus.plexus.component.factory.ComponentInstantiationException: Could not instanciate component: role: 'null', i mplementation: 'org.apache.maven.plugin.CompilerMojo' at org.codehaus.plexus.component.factory.java.JavaComponentFactory.makeException(JavaComponentFactory.java:77) at org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:62) at org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(DefaultPlexusContainer.java:1464) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:93 ) at org.codehaus.plexus.component.manager.PerLookupComponentManager.getComponent(PerLookupComponentManager.java:48) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) ... 20 more Caused by: java.lang.NoClassDefFoundError: org/codehaus/plexus/compiler/util/scan/InclusionScanException at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357) at java.lang.Class.getConstructor0(Class.java:2671) at java.lang.Class.newInstance0(Class.java:321) at
[jira] Commented: (DOXIA-185) Add encoding support
[ http://jira.codehaus.org/browse/DOXIA-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133653#action_133653 ] Lukas Theussl commented on DOXIA-185: - For xml files this is already done: DOXIA-133. For text files one would have to specify how to indicate an encoding on a per-file basis, eg via some meta-information. But in any case, the file encoding would have to be detected by some peek-ahead, ie outside doxia, to construct the Reader, like it's done by the ReaderFactory.newXmlReader in the xml case. So I don't think it's necessary to modify the Sink API. Add encoding support Key: DOXIA-185 URL: http://jira.codehaus.org/browse/DOXIA-185 Project: Maven Doxia Issue Type: Improvement Components: Sink API Affects Versions: 1.0-alpha-10 Reporter: Vincent Siveton -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTRUN-51) Can't find plugin dependency in multiproject
[
http://jira.codehaus.org/browse/MANTRUN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133654#action_133654
]
bastian kaempfe commented on MANTRUN-51:
My guess is that the problem is caused ANT.
ANT simply can set properties only ONE TIME. if you try to set a named property
severeal times, you succeed only the first time.
every next try does not overwrite the first value, thus when using the
property, you will always get the first value.
the maven-antrun-plugins tries to set several properties, for example:
maven.plugin.classpath.
so the first project wins. every property this antrun-plugin sets will be
available in every other projet, running after this one.
and no other project can overwrite properties, the first project has set.
maybe the solution could be to start the ant-task in an own java-process, like
the fork of the maven-compiler-plugin.
another way could be to define a prefix or suffix for every property that
will be set by maven within a maven-antrun-plugin-block.
could be: prefix=srcgen - maven property : maven.plugin.classpath.srcgen
instead of only maven.plugin.classpath
or one could use the maven-antrun-plugin-id, if one is provided.
so if my execution-id is backend-wsdl2java the maven-set properties could be
maven.plugin.classpath.backend-wsdl2java
i hope, this helps in understanding and solving...
Can't find plugin dependency in multiproject
Key: MANTRUN-51
URL: http://jira.codehaus.org/browse/MANTRUN-51
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.0, 1.1
Environment: maven 2.0.4, antrun 1.0 1.1, jdk 1.5.0_06, windows xp
Reporter: Fredrik Vraalsen
I'm using antrun in my project to create an IzPack installation. The plugin
configuration is below.
When maven is run from the top-level project, the ant taskdef fails because
it cannot find the IzPackTask class. However, when I run maven from the
subproject itself, it works fine. Not sure if this is related to
http://jira.codehaus.org/browse/MANTRUN-49. The error message from maven is
at the bottom.
{noformat}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
configuration
tasks
taskdef name=izpack
classname=com.izforge.izpack.ant.IzPackTask/
izpack
input=${project.build.directory}/classes/izPack.xml
output=${project.build.directory}/CorasTool-${coras.version}-installer.jar
basedir=${project.build.directory}/
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdizpack/groupId
artifactIdstandalone-compiler/artifactId
version3.8.0/version
/dependency
/dependencies
/plugin
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: taskdef class com.izforge.izpack.ant.IzPackTask cannot be
found
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant
tasks
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[jira] Closed: (MAVEN-1857) File manipulation using maven
[ http://jira.codehaus.org/browse/MAVEN-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MAVEN-1857. Resolution: Won't Fix This is an issue tracking system, please send your questions to the maven user list: http://maven.apache.org/mail-lists.html File manipulation using maven - Key: MAVEN-1857 URL: http://jira.codehaus.org/browse/MAVEN-1857 Project: Maven 1 Issue Type: Test Environment: windows Reporter: Amol Bagul Hi How could I use maven script for file manupulation. If I want to pass some parameter and want to replace those in to the file, could I do this using maven. Regards, -Amol B -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTRUN-52) plugin dependencies seem to get lost when using the plugin multiple times
[
http://jira.codehaus.org/browse/MANTRUN-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133657#action_133657
]
bastian kaempfe commented on MANTRUN-52:
i thing, this might basically be ste same problem as described in MANTRUN-51
http://jira.codehaus.org/browse/MANTRUN-51
plugin dependencies seem to get lost when using the plugin multiple times
-
Key: MANTRUN-52
URL: http://jira.codehaus.org/browse/MANTRUN-52
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.1
Reporter: Jorg Heymans
Priority: Critical
say in the same pom you have
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
configuration
tasks
replace dir=${project.build.outputDirectory}
replaceFilterFile=${basedir}/src/main/properties/replaceSchemaNames.properties
/
/tasks
/configuration
/build
and
profiles
profile
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idDatabase recreation/id
configuration
tasks
sql /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdoracle/groupId
artifactIdoracle-jdbc/artifactId
version1.4_g/version
/dependency
/dependencies
/plugin
/plugins
/build
/profile
then the antrun configured in the profile will fail saying that it can't find
the oracle driver. If i move the oracle dependency to the plugin configured
in build then it works.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MANTRUN-52) plugin dependencies seem to get lost when using the plugin multiple times
[
http://jira.codehaus.org/browse/MANTRUN-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133657#action_133657
]
seafoxx edited comment on MANTRUN-52 at 5/6/08 5:11 AM:
i thing, this might basically be ste same problem as described in MANTRUN-51
http://jira.codehaus.org/browse/MANTRUN-51
- When using more than one antrun-blocks, the first one sets all properties
which cannot be overwritten by the other antrun-blocks called afterwards
was (Author: seafoxx):
i thing, this might basically be ste same problem as described in MANTRUN-51
http://jira.codehaus.org/browse/MANTRUN-51
plugin dependencies seem to get lost when using the plugin multiple times
-
Key: MANTRUN-52
URL: http://jira.codehaus.org/browse/MANTRUN-52
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.1
Reporter: Jorg Heymans
Priority: Critical
say in the same pom you have
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
configuration
tasks
replace dir=${project.build.outputDirectory}
replaceFilterFile=${basedir}/src/main/properties/replaceSchemaNames.properties
/
/tasks
/configuration
/build
and
profiles
profile
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idDatabase recreation/id
configuration
tasks
sql /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdoracle/groupId
artifactIdoracle-jdbc/artifactId
version1.4_g/version
/dependency
/dependencies
/plugin
/plugins
/build
/profile
then the antrun configured in the profile will fail saying that it can't find
the oracle driver. If i move the oracle dependency to the plugin configured
in build then it works.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MANTRUN-52) plugin dependencies seem to get lost when using the plugin multiple times
[
http://jira.codehaus.org/browse/MANTRUN-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133657#action_133657
]
seafoxx edited comment on MANTRUN-52 at 5/6/08 5:11 AM:
i thing, this might basically be ste same problem as described in MANTRUN-51
- When using more than one antrun-blocks, the first one sets all properties
which cannot be overwritten by the other antrun-blocks called afterwards
was (Author: seafoxx):
i thing, this might basically be ste same problem as described in MANTRUN-51
http://jira.codehaus.org/browse/MANTRUN-51
- When using more than one antrun-blocks, the first one sets all properties
which cannot be overwritten by the other antrun-blocks called afterwards
plugin dependencies seem to get lost when using the plugin multiple times
-
Key: MANTRUN-52
URL: http://jira.codehaus.org/browse/MANTRUN-52
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.1
Reporter: Jorg Heymans
Priority: Critical
say in the same pom you have
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
configuration
tasks
replace dir=${project.build.outputDirectory}
replaceFilterFile=${basedir}/src/main/properties/replaceSchemaNames.properties
/
/tasks
/configuration
/build
and
profiles
profile
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idDatabase recreation/id
configuration
tasks
sql /
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdoracle/groupId
artifactIdoracle-jdbc/artifactId
version1.4_g/version
/dependency
/dependencies
/plugin
/plugins
/build
/profile
then the antrun configured in the profile will fail saying that it can't find
the oracle driver. If i move the oracle dependency to the plugin configured
in build then it works.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MANTRUN-51) Can't find plugin dependency in multiproject
[
http://jira.codehaus.org/browse/MANTRUN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133654#action_133654
]
seafoxx edited comment on MANTRUN-51 at 5/6/08 5:21 AM:
My guess is that the problem is caused ANT.
description of the ant-property-task:
*Properties are immutable: whoever sets a property first freezes it for the
rest of the build; they are most definitely not variables.*
i think, this might be the root cause of these problems.
ANT simply can set properties only ONE TIME. if you try to set a named property
severeal times, you succeed only the first time.
every next try does not overwrite the first value, thus when using the
property, you will always get the first value.
the {{maven-antrun-plugins}} tries to set several properties, for example:
{{maven.plugin.classpath}}.
so the first project wins. every property this {{maven-antrun-plugin}} sets
will be available in every other projet, running after this one. and no other
project can overwrite properties, the first project has set.
maybe the solution could be to start the ant-task in an own java-process, like
the {{fork}} of the {{maven-compiler-plugin}}.
another way could be to define a prefix or suffix for every property that
will be set by maven within a {{maven-antrun-plugin}}-block.
could be: prefix={{srcgen}} - maven property :
{{maven.plugin.classpath.srcgen}} instead of only {{maven.plugin.classpath}}
or one could use the {{maven-antrun-plugin}}-{{id}}, if one is provided.
so if my execution-id is {{backend-wsdl2java}} the maven-set properties could
be {{maven.plugin.classpath.backend-wsdl2java}}
i hope, this helps in understanding and solving...
was (Author: seafoxx):
My guess is that the problem is caused ANT.
description of the ant-property-task:
Properties are immutable: whoever sets a property first freezes it for the rest
of the build; they are most definitely not variables.
i think, this might be the root cause of these problems.
ANT simply can set properties only ONE TIME. if you try to set a named property
severeal times, you succeed only the first time.
every next try does not overwrite the first value, thus when using the
property, you will always get the first value.
the maven-antrun-plugins tries to set several properties, for example:
maven.plugin.classpath.
so the first project wins. every property this antrun-plugin sets will be
available in every other projet, running after this one.
and no other project can overwrite properties, the first project has set.
maybe the solution could be to start the ant-task in an own java-process, like
the fork of the maven-compiler-plugin.
another way could be to define a prefix or suffix for every property that
will be set by maven within a maven-antrun-plugin-block.
could be: prefix=srcgen - maven property : maven.plugin.classpath.srcgen
instead of only maven.plugin.classpath
or one could use the maven-antrun-plugin-id, if one is provided.
so if my execution-id is backend-wsdl2java the maven-set properties could be
maven.plugin.classpath.backend-wsdl2java
i hope, this helps in understanding and solving...
Can't find plugin dependency in multiproject
Key: MANTRUN-51
URL: http://jira.codehaus.org/browse/MANTRUN-51
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.0, 1.1
Environment: maven 2.0.4, antrun 1.0 1.1, jdk 1.5.0_06, windows xp
Reporter: Fredrik Vraalsen
I'm using antrun in my project to create an IzPack installation. The plugin
configuration is below.
When maven is run from the top-level project, the ant taskdef fails because
it cannot find the IzPackTask class. However, when I run maven from the
subproject itself, it works fine. Not sure if this is related to
http://jira.codehaus.org/browse/MANTRUN-49. The error message from maven is
at the bottom.
{noformat}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
configuration
tasks
taskdef name=izpack
classname=com.izforge.izpack.ant.IzPackTask/
izpack
input=${project.build.directory}/classes/izPack.xml
output=${project.build.directory}/CorasTool-${coras.version}-installer.jar
basedir=${project.build.directory}/
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdizpack/groupId
[jira] Issue Comment Edited: (MANTRUN-51) Can't find plugin dependency in multiproject
[
http://jira.codehaus.org/browse/MANTRUN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133654#action_133654
]
seafoxx edited comment on MANTRUN-51 at 5/6/08 5:17 AM:
My guess is that the problem is caused ANT.
description of the ant-property-task:
Properties are immutable: whoever sets a property first freezes it for the rest
of the build; they are most definitely not variables.
i think, this might be the root cause of these problems.
ANT simply can set properties only ONE TIME. if you try to set a named property
severeal times, you succeed only the first time.
every next try does not overwrite the first value, thus when using the
property, you will always get the first value.
the maven-antrun-plugins tries to set several properties, for example:
maven.plugin.classpath.
so the first project wins. every property this antrun-plugin sets will be
available in every other projet, running after this one.
and no other project can overwrite properties, the first project has set.
maybe the solution could be to start the ant-task in an own java-process, like
the fork of the maven-compiler-plugin.
another way could be to define a prefix or suffix for every property that
will be set by maven within a maven-antrun-plugin-block.
could be: prefix=srcgen - maven property : maven.plugin.classpath.srcgen
instead of only maven.plugin.classpath
or one could use the maven-antrun-plugin-id, if one is provided.
so if my execution-id is backend-wsdl2java the maven-set properties could be
maven.plugin.classpath.backend-wsdl2java
i hope, this helps in understanding and solving...
was (Author: seafoxx):
My guess is that the problem is caused ANT.
ANT simply can set properties only ONE TIME. if you try to set a named property
severeal times, you succeed only the first time.
every next try does not overwrite the first value, thus when using the
property, you will always get the first value.
the maven-antrun-plugins tries to set several properties, for example:
maven.plugin.classpath.
so the first project wins. every property this antrun-plugin sets will be
available in every other projet, running after this one.
and no other project can overwrite properties, the first project has set.
maybe the solution could be to start the ant-task in an own java-process, like
the fork of the maven-compiler-plugin.
another way could be to define a prefix or suffix for every property that
will be set by maven within a maven-antrun-plugin-block.
could be: prefix=srcgen - maven property : maven.plugin.classpath.srcgen
instead of only maven.plugin.classpath
or one could use the maven-antrun-plugin-id, if one is provided.
so if my execution-id is backend-wsdl2java the maven-set properties could be
maven.plugin.classpath.backend-wsdl2java
i hope, this helps in understanding and solving...
Can't find plugin dependency in multiproject
Key: MANTRUN-51
URL: http://jira.codehaus.org/browse/MANTRUN-51
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.0, 1.1
Environment: maven 2.0.4, antrun 1.0 1.1, jdk 1.5.0_06, windows xp
Reporter: Fredrik Vraalsen
I'm using antrun in my project to create an IzPack installation. The plugin
configuration is below.
When maven is run from the top-level project, the ant taskdef fails because
it cannot find the IzPackTask class. However, when I run maven from the
subproject itself, it works fine. Not sure if this is related to
http://jira.codehaus.org/browse/MANTRUN-49. The error message from maven is
at the bottom.
{noformat}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
configuration
tasks
taskdef name=izpack
classname=com.izforge.izpack.ant.IzPackTask/
izpack
input=${project.build.directory}/classes/izPack.xml
output=${project.build.directory}/CorasTool-${coras.version}-installer.jar
basedir=${project.build.directory}/
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdizpack/groupId
artifactIdstandalone-compiler/artifactId
version3.8.0/version
/dependency
/dependencies
/plugin
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO]
[jira] Issue Comment Edited: (MANTRUN-51) Can't find plugin dependency in multiproject
[
http://jira.codehaus.org/browse/MANTRUN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133654#action_133654
]
seafoxx edited comment on MANTRUN-51 at 5/6/08 5:42 AM:
still got the same problem.
was (Author: seafoxx):
My guess is that the problem is caused ANT.
description of the ant-property-task:
*Properties are immutable: whoever sets a property first freezes it for the
rest of the build; they are most definitely not variables.*
i think, this might be the root cause of these problems.
ANT simply can set properties only ONE TIME. if you try to set a named property
severeal times, you succeed only the first time.
every next try does not overwrite the first value, thus when using the
property, you will always get the first value.
the {{maven-antrun-plugins}} tries to set several properties, for example:
{{maven.plugin.classpath}}.
so the first project wins. every property this {{maven-antrun-plugin}} sets
will be available in every other projet, running after this one. and no other
project can overwrite properties, the first project has set.
maybe the solution could be to start the ant-task in an own java-process, like
the {{fork}} of the {{maven-compiler-plugin}}.
another way could be to define a prefix or suffix for every property that
will be set by maven within a {{maven-antrun-plugin}}-block.
could be: prefix={{srcgen}} - maven property :
{{maven.plugin.classpath.srcgen}} instead of only {{maven.plugin.classpath}}
or one could use the {{maven-antrun-plugin}}-{{id}}, if one is provided.
so if my execution-id is {{backend-wsdl2java}} the maven-set properties could
be {{maven.plugin.classpath.backend-wsdl2java}}
i hope, this helps in understanding and solving...
Can't find plugin dependency in multiproject
Key: MANTRUN-51
URL: http://jira.codehaus.org/browse/MANTRUN-51
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.0, 1.1
Environment: maven 2.0.4, antrun 1.0 1.1, jdk 1.5.0_06, windows xp
Reporter: Fredrik Vraalsen
I'm using antrun in my project to create an IzPack installation. The plugin
configuration is below.
When maven is run from the top-level project, the ant taskdef fails because
it cannot find the IzPackTask class. However, when I run maven from the
subproject itself, it works fine. Not sure if this is related to
http://jira.codehaus.org/browse/MANTRUN-49. The error message from maven is
at the bottom.
{noformat}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasepackage/phase
configuration
tasks
taskdef name=izpack
classname=com.izforge.izpack.ant.IzPackTask/
izpack
input=${project.build.directory}/classes/izPack.xml
output=${project.build.directory}/CorasTool-${coras.version}-installer.jar
basedir=${project.build.directory}/
/tasks
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
groupIdizpack/groupId
artifactIdstandalone-compiler/artifactId
version3.8.0/version
/dependency
/dependencies
/plugin
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error executing ant tasks
Embedded error: taskdef class com.izforge.izpack.ant.IzPackTask cannot be
found
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant
tasks
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
[jira] Created: (MSITE-323) Improve site footer
Improve site footer
---
Key: MSITE-323
URL: http://jira.codehaus.org/browse/MSITE-323
Project: Maven 2.x Site Plugin
Issue Type: Improvement
Affects Versions: 2.0-beta-5
Reporter: Michael Osipov
Right now, the footer produces only:
{code}
copy ${inceptionYear} - ${today} ${organization}
{code}
in contrast to that Javadoc produces am much more reasonable output
{code}
Copyright copy ${inceptionYear} - ${today} a
href=${organizationUrl}${organization}/a. All Rights Reserved.
{code}
Site plugin should produce such a more informative footer too if the
appropriate properties are set in the pom.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-380) dependencies in multi-module may projects require a 'mvn install' before using
[ http://jira.codehaus.org/browse/MECLIPSE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133683#action_133683 ] Martin Höller commented on MECLIPSE-380: Alfie Kirkpatrick did some research on this and posted the results [here|http://www.nabble.com/%40requiresDependencyResolution,-multi-project-and-reactor-dependencies---a-bug--to13387970.html#a13388483]. It seems this issue is not related to MNG-2277 as Brian wrote, because MNG-2277 is closed already but this problem still exists with maven 2.0.9 and maven-eclipse-plugin 2.5.1. dependencies in multi-module may projects require a 'mvn install' before using -- Key: MECLIPSE-380 URL: http://jira.codehaus.org/browse/MECLIPSE-380 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: Core : Dependencies resolution and build path, Core : Multi-projects Affects Versions: 2.4, 2.5 Environment: Maven 2.0.8 Reporter: Martin Höller The scenario is as follows: Parent Project P | +-- Project A | `- Project B B has a dependency on A (B requires A). A user with an empty local repository cannot checkout the whole project and run 'mvn eclipse:eclipse' due to unsatisfied dependencies. The build will fail in Project B because Project A is missing from the repository. A 'mvn install' has to be executed before (at least for Project A). But what if the project is in a state where it doesn't compile? It's not possible in this case for a new user to start developing with eclipse. See also http://www.nabble.com/maven-eclipse-plugin-with-multi-module-projects-to15222495s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2277) aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue
[ http://jira.codehaus.org/browse/MNG-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133684#action_133684 ] Martin Höller commented on MNG-2277: Alfie, an issue for your problem exists in JIRA for maven-eclipse-plugin as MECLIPSE-380. Probably it's not just maven-eclipse-plugin related and should be moved to maven, I'm not sure. aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue Key: MNG-2277 URL: http://jira.codehaus.org/browse/MNG-2277 Project: Maven 2 Issue Type: Bug Components: Plugin API, Plugins and Lifecycle, Reactor and workspace Affects Versions: 2.0.4 Reporter: Brett Porter Assignee: Brian Fox Fix For: 2.0.8 Attachments: maven-dependency-bug.zip eg, assembly:attached when this is put in maven-core, and a build is run from the root project with a clean repo, it fails, as the original project sorter doesn't consider the dependencies, building plugin-tools after maven-core. However, hitting the aggregator when building maven-core then tries to resolve all of the projects as dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2049) plexian-1.1
plexian-1.1 --- Key: MAVENUPLOAD-2049 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2049 Project: maven-upload-requests Issue Type: Wish Reporter: Alexander Schwid Attachments: plexian-core-1.1-bundle.jar, plexian-indexator-1.1-bundle.jar http://schwid.com/plexian/plexian-core-1.1-bundle.jar http://schwid.com/plexian/plexian-indexator-1.1-bundle.jar http://plexian.sourceforge.net I'm a developer in plexian, please upload! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2277) aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue
[ http://jira.codehaus.org/browse/MNG-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133691#action_133691 ] Alfie Kirkpatrick commented on MNG-2277: For info I had already raised MNG-3283 for the specific issue we're facing. I'll comment on MECLIPSE-380 now to link to it. aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue Key: MNG-2277 URL: http://jira.codehaus.org/browse/MNG-2277 Project: Maven 2 Issue Type: Bug Components: Plugin API, Plugins and Lifecycle, Reactor and workspace Affects Versions: 2.0.4 Reporter: Brett Porter Assignee: Brian Fox Fix For: 2.0.8 Attachments: maven-dependency-bug.zip eg, assembly:attached when this is put in maven-core, and a build is run from the root project with a clean repo, it fails, as the original project sorter doesn't consider the dependencies, building plugin-tools after maven-core. However, hitting the aggregator when building maven-core then tries to resolve all of the projects as dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-380) dependencies in multi-module may projects require a 'mvn install' before using
[ http://jira.codehaus.org/browse/MECLIPSE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133692#action_133692 ] Alfie Kirkpatrick commented on MECLIPSE-380: I think this issue can be closed as a duplicate of MNG-3283. This issue is not specifically related to the eclipse plugin, although that is the context we found it in. Note that you can work around this issue as siarhei suggested in the maven-users thread by running 'mvn process-classes eclipse:eclipse' because this goes further in the artifact resolution. dependencies in multi-module may projects require a 'mvn install' before using -- Key: MECLIPSE-380 URL: http://jira.codehaus.org/browse/MECLIPSE-380 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: Core : Dependencies resolution and build path, Core : Multi-projects Affects Versions: 2.4, 2.5 Environment: Maven 2.0.8 Reporter: Martin Höller The scenario is as follows: Parent Project P | +-- Project A | `- Project B B has a dependency on A (B requires A). A user with an empty local repository cannot checkout the whole project and run 'mvn eclipse:eclipse' due to unsatisfied dependencies. The build will fail in Project B because Project A is missing from the repository. A 'mvn install' has to be executed before (at least for Project A). But what if the project is in a state where it doesn't compile? It's not possible in this case for a new user to start developing with eclipse. See also http://www.nabble.com/maven-eclipse-plugin-with-multi-module-projects-to15222495s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue
[ http://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133693#action_133693 ] Alfie Kirkpatrick commented on MNG-3283: Note that am pretty sure this issue is seen in m2eclipse which uses maven embedder from the 2.1.x version of maven. This issue may become more apparent as people start using these tools and probably harder to roll out fixes also... Plugins that require dependency resolution in early phases cause dependency resolution issue Key: MNG-3283 URL: http://jira.codehaus.org/browse/MNG-3283 Project: Maven 2 Issue Type: Bug Components: Dependencies, Plugins and Lifecycle, Reactor and workspace Affects Versions: 2.0.7 Reporter: Alfie Kirkpatrick Assignee: Brian Fox Attachments: maven-dependency-bug.zip What we're seeing is that some multi-project configurations succeed on 'mvn package' but fail on 'mvn generate-sources'. They are failing when one project in the reactor references another project in the reactor which is not installed in the local repo. It seems that the referenced project has not quite made it into the reactor this early in the phase lifecycle. But it does work correctly if you target a later phase at the outset which is really confusing. The problem only occurs when a plugin binds itself to the generate-sources phase and has @requiresDependencyResolution, presumably because this is what triggers resolution of the referenced dependency too early in the lifecycle, and hence the error. We are seeing this problem when trying to run 'mvn eclipse:eclipse' because this only executes the generate-sources phase by default and we have other mojos which genuinely do generate source, such as java2wsdl. A workaround we're using is to run 'mvn process-classes eclipse:eclipse'. Attached is a really simple project that exhibits this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-380) dependencies in multi-module may projects require a 'mvn install' before using
[ http://jira.codehaus.org/browse/MECLIPSE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Höller closed MECLIPSE-380. -- Resolution: Duplicate This issue is a duplicate of MNG-3283 dependencies in multi-module may projects require a 'mvn install' before using -- Key: MECLIPSE-380 URL: http://jira.codehaus.org/browse/MECLIPSE-380 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: Core : Dependencies resolution and build path, Core : Multi-projects Affects Versions: 2.4, 2.5 Environment: Maven 2.0.8 Reporter: Martin Höller The scenario is as follows: Parent Project P | +-- Project A | `- Project B B has a dependency on A (B requires A). A user with an empty local repository cannot checkout the whole project and run 'mvn eclipse:eclipse' due to unsatisfied dependencies. The build will fail in Project B because Project A is missing from the repository. A 'mvn install' has to be executed before (at least for Project A). But what if the project is in a state where it doesn't compile? It's not possible in this case for a new user to start developing with eclipse. See also http://www.nabble.com/maven-eclipse-plugin-with-multi-module-projects-to15222495s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3283) Plugins that require dependency resolution in early phases cause dependency resolution issue
[ http://jira.codehaus.org/browse/MNG-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133703#action_133703 ] Brian Fox commented on MNG-3283: This kind of change will require rework that can only occur in 2.1, if at all. Plugins that require dependency resolution in early phases cause dependency resolution issue Key: MNG-3283 URL: http://jira.codehaus.org/browse/MNG-3283 Project: Maven 2 Issue Type: Bug Components: Dependencies, Plugins and Lifecycle, Reactor and workspace Affects Versions: 2.0.7 Reporter: Alfie Kirkpatrick Assignee: Brian Fox Attachments: maven-dependency-bug.zip What we're seeing is that some multi-project configurations succeed on 'mvn package' but fail on 'mvn generate-sources'. They are failing when one project in the reactor references another project in the reactor which is not installed in the local repo. It seems that the referenced project has not quite made it into the reactor this early in the phase lifecycle. But it does work correctly if you target a later phase at the outset which is really confusing. The problem only occurs when a plugin binds itself to the generate-sources phase and has @requiresDependencyResolution, presumably because this is what triggers resolution of the referenced dependency too early in the lifecycle, and hence the error. We are seeing this problem when trying to run 'mvn eclipse:eclipse' because this only executes the generate-sources phase by default and we have other mojos which genuinely do generate source, such as java2wsdl. A workaround we're using is to run 'mvn process-classes eclipse:eclipse'. Attached is a really simple project that exhibits this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRESOURCES-20) Filtering ${foo.file} evaluates to in full path to pom.xml
[
http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133710#action_133710
]
anj747 edited comment on MRESOURCES-20 at 5/6/08 10:51 AM:
I agree, this is an important issue. Thankyou Erik for the patch, it worked a
treat.
However I had to spoof a local maven release of this plugin to allow me to
release my dependent project (~shudder~).
was (Author: anj747):
I agree, this is an important issue. Thankyou Erik for the patch, it worked
a treat.
However I had to spoof a local maven release of this plugin to allow me to
release my dependent project. *shudder*.
Filtering ${foo.file} evaluates to in full path to pom.xml
--
Key: MRESOURCES-20
URL: http://jira.codehaus.org/browse/MRESOURCES-20
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: Windows XP, Maven 2.0.2
Reporter: Martin Onis
Priority: Minor
Attachments: MRESOURCES-20.patch
If an unresolved variable is encountered, the plugin simply does not replace
the variable in the target file.
If this unresolved variable however ends in .file} it will evaluate to a
file object that targets the current pom. This results in the replacement
being the complete path to that pom (in the 2.1 version of the plugin this
results in a ClassCastException).
The workaround is, of course, not to filter the affected files.
Though this will not work if other variables in the affected files do need to
be replaced.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRESOURCES-20) Filtering ${foo.file} evaluates to in full path to pom.xml
[
http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133710#action_133710
]
Anj commented on MRESOURCES-20:
---
I agree, this is an important issue. Thankyou Erik for the patch, it worked a
treat.
However I had to spoof a local maven release of this plugin to allow me to
release my dependent project. *shudder*.
Filtering ${foo.file} evaluates to in full path to pom.xml
--
Key: MRESOURCES-20
URL: http://jira.codehaus.org/browse/MRESOURCES-20
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: Windows XP, Maven 2.0.2
Reporter: Martin Onis
Priority: Minor
Attachments: MRESOURCES-20.patch
If an unresolved variable is encountered, the plugin simply does not replace
the variable in the target file.
If this unresolved variable however ends in .file} it will evaluate to a
file object that targets the current pom. This results in the replacement
being the complete path to that pom (in the 2.1 version of the plugin this
results in a ClassCastException).
The workaround is, of course, not to filter the affected files.
Though this will not work if other variables in the affected files do need to
be replaced.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRESOURCES-20) Filtering ${foo.file} evaluates to in full path to pom.xml
[
http://jira.codehaus.org/browse/MRESOURCES-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133710#action_133710
]
anj747 edited comment on MRESOURCES-20 at 5/6/08 10:51 AM:
I agree, this is an important issue. Thankyou Erik for the patch, it worked a
treat.
However I had to spoof a local maven release of this plugin to allow me to
release my dependent project (~ shudder ~).
was (Author: anj747):
I agree, this is an important issue. Thankyou Erik for the patch, it worked
a treat.
However I had to spoof a local maven release of this plugin to allow me to
release my dependent project (~shudder~).
Filtering ${foo.file} evaluates to in full path to pom.xml
--
Key: MRESOURCES-20
URL: http://jira.codehaus.org/browse/MRESOURCES-20
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: Windows XP, Maven 2.0.2
Reporter: Martin Onis
Priority: Minor
Attachments: MRESOURCES-20.patch
If an unresolved variable is encountered, the plugin simply does not replace
the variable in the target file.
If this unresolved variable however ends in .file} it will evaluate to a
file object that targets the current pom. This results in the replacement
being the complete path to that pom (in the 2.1 version of the plugin this
results in a ClassCastException).
The workaround is, of course, not to filter the affected files.
Though this will not work if other variables in the affected files do need to
be replaced.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-361) eclipse plugin and WTP generating warnings in Europa
[ http://jira.codehaus.org/browse/MECLIPSE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133720#action_133720 ] willcode4beer edited comment on MECLIPSE-361 at 5/6/08 12:41 PM: -- As a workaround, I added a filter to the Problems view. On the little down arrow, select the configure filters option. Click the New button. Name the filter Hide M2_REPO Warnings Have Description Contains (drop down) M2_REPO Make sure the new filter is checked in the list of user filters. Rebuild your project, the warnings should be hidden. You should only see the warnings you care about now. was (Author: willcode4beer): As a workaround, I added a filter to the Problems view. On the little down arrow, select the configure filters option. Click the New button. Name the filter Hide M2_REPO Warnings Have Description Contains (drop down) M2_REPO Make sure the new filter is checked in the list of user filters. Rebuild your project, the warnings should be hidden. eclipse plugin and WTP generating warnings in Europa - Key: MECLIPSE-361 URL: http://jira.codehaus.org/browse/MECLIPSE-361 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: WTP support Affects Versions: 2.5 Environment: Eclipse 3.3.1.1 and WTP 2.0.1 Using Maven 2.0.7 and the last maven-eclipse-plugin 2.5-SNAPSHOT Reporter: Yann Albou Priority: Minor Attachments: wtpTest.zip The issue is regarding warnings in Europa and WTP: Classpath entry M2_REPO/log4j/log4j/1.2.13/log4j-1.2.13.jar will not be exported or published. Runtime ClassNotFoundExceptions may result. 1) If I try to generate with wtpversion=1.5 and maven-eclipse-plugin version 2.5-SNAPSHOT = I get the same behaviour in EUROPA (WARNINGS) 2) If I try to generate with wtpversion=1.5 and maven-eclipse-plugin version 2.4 = I get the same behaviour in EUROPA (WARNINGS) 3) I then try using Eclipse 3.2.2 with WTP 1.5.3 (instead of Eclipse 3.3.1.1 and WTP 2.0.1) with maven-eclipse-plugin version 2.4 or 2.5-SNAPSHOT = Everything is perfect, no more warnings I create a simple test in order to reproduce the issue. This test is a multi module application composed of 1 Ejb module and 1 Ear module. So at the top level Just run mvn install eclipse:eclipse And then in an europa workspace import the projetcs and you should see the warnings on the EJB module. It will behave the same way if it exists other modules. I notice that, in the case you update parameters on the eclipse plugin you will need to remove projects from workspace and import them again. otherwise some old parameter will stay in the eclipse cache... let me know if you need other tests Yann. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-361) eclipse plugin and WTP generating warnings in Europa
[ http://jira.codehaus.org/browse/MECLIPSE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133720#action_133720 ] Paul Davis commented on MECLIPSE-361: - As a workaround, I added a filter to the Problems view. On the little down arrow, select the configure filters option. Click the New button. Name the filter Hide M2_REPO Warnings Have Description Contains (drop down) M2_REPO Make sure the new filter is checked in the list of user filters. Rebuild your project, the warnings should be hidden. eclipse plugin and WTP generating warnings in Europa - Key: MECLIPSE-361 URL: http://jira.codehaus.org/browse/MECLIPSE-361 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: WTP support Affects Versions: 2.5 Environment: Eclipse 3.3.1.1 and WTP 2.0.1 Using Maven 2.0.7 and the last maven-eclipse-plugin 2.5-SNAPSHOT Reporter: Yann Albou Priority: Minor Attachments: wtpTest.zip The issue is regarding warnings in Europa and WTP: Classpath entry M2_REPO/log4j/log4j/1.2.13/log4j-1.2.13.jar will not be exported or published. Runtime ClassNotFoundExceptions may result. 1) If I try to generate with wtpversion=1.5 and maven-eclipse-plugin version 2.5-SNAPSHOT = I get the same behaviour in EUROPA (WARNINGS) 2) If I try to generate with wtpversion=1.5 and maven-eclipse-plugin version 2.4 = I get the same behaviour in EUROPA (WARNINGS) 3) I then try using Eclipse 3.2.2 with WTP 1.5.3 (instead of Eclipse 3.3.1.1 and WTP 2.0.1) with maven-eclipse-plugin version 2.4 or 2.5-SNAPSHOT = Everything is perfect, no more warnings I create a simple test in order to reproduce the issue. This test is a multi module application composed of 1 Ejb module and 1 Ear module. So at the top level Just run mvn install eclipse:eclipse And then in an europa workspace import the projetcs and you should see the warnings on the EJB module. It will behave the same way if it exists other modules. I notice that, in the case you update parameters on the eclipse plugin you will need to remove projects from workspace and import them again. otherwise some old parameter will stay in the eclipse cache... let me know if you need other tests Yann. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-361) eclipse plugin and WTP generating warnings in Europa
[ http://jira.codehaus.org/browse/MECLIPSE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133720#action_133720 ] willcode4beer edited comment on MECLIPSE-361 at 5/6/08 12:50 PM: -- As a workaround, I added a filter to the Problems view. On the little down arrow, select the configure filters option. Click the New button. Name the filter Hide M2_REPO Warnings Have Description doesn't contain (drop down) M2_REPO Select severity, warning Make sure the new filter is checked (and uncheck default) in the list of user filters. You should only see the warnings you care about now. was (Author: willcode4beer): As a workaround, I added a filter to the Problems view. On the little down arrow, select the configure filters option. Click the New button. Name the filter Hide M2_REPO Warnings Have Description Contains (drop down) M2_REPO Make sure the new filter is checked in the list of user filters. Rebuild your project, the warnings should be hidden. You should only see the warnings you care about now. eclipse plugin and WTP generating warnings in Europa - Key: MECLIPSE-361 URL: http://jira.codehaus.org/browse/MECLIPSE-361 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: WTP support Affects Versions: 2.5 Environment: Eclipse 3.3.1.1 and WTP 2.0.1 Using Maven 2.0.7 and the last maven-eclipse-plugin 2.5-SNAPSHOT Reporter: Yann Albou Priority: Minor Attachments: wtpTest.zip The issue is regarding warnings in Europa and WTP: Classpath entry M2_REPO/log4j/log4j/1.2.13/log4j-1.2.13.jar will not be exported or published. Runtime ClassNotFoundExceptions may result. 1) If I try to generate with wtpversion=1.5 and maven-eclipse-plugin version 2.5-SNAPSHOT = I get the same behaviour in EUROPA (WARNINGS) 2) If I try to generate with wtpversion=1.5 and maven-eclipse-plugin version 2.4 = I get the same behaviour in EUROPA (WARNINGS) 3) I then try using Eclipse 3.2.2 with WTP 1.5.3 (instead of Eclipse 3.3.1.1 and WTP 2.0.1) with maven-eclipse-plugin version 2.4 or 2.5-SNAPSHOT = Everything is perfect, no more warnings I create a simple test in order to reproduce the issue. This test is a multi module application composed of 1 Ejb module and 1 Ear module. So at the top level Just run mvn install eclipse:eclipse And then in an europa workspace import the projetcs and you should see the warnings on the EJB module. It will behave the same way if it exists other modules. I notice that, in the case you update parameters on the eclipse plugin you will need to remove projects from workspace and import them again. otherwise some old parameter will stay in the eclipse cache... let me know if you need other tests Yann. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-323) Improve site footer
[
http://jira.codehaus.org/browse/MSITE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSITE-323:
-
Attachment: MSITE-323.patch
This is a patch against
https://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/tags/doxia-sitetools-1.0-alpha-10/doxia-site-renderer/src/main/resources/org/apache/maven/doxia/siterenderer/resources/default-site.vm
Improve site footer
---
Key: MSITE-323
URL: http://jira.codehaus.org/browse/MSITE-323
Project: Maven 2.x Site Plugin
Issue Type: Improvement
Affects Versions: 2.0-beta-5
Reporter: Michael Osipov
Attachments: MSITE-323.patch
Right now, the footer produces only:
{code}
copy ${inceptionYear} - ${today} ${organization}
{code}
in contrast to that Javadoc produces am much more reasonable output
{code}
Copyright copy ${inceptionYear} - ${today} a
href=${organizationUrl}${organization}/a. All Rights Reserved.
{code}
Site plugin should produce such a more informative footer too if the
appropriate properties are set in the pom.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIASITETOOLS-11) Improve site footer
Improve site footer
---
Key: DOXIASITETOOLS-11
URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-11
Project: Maven Doxia Site Tools
Issue Type: Improvement
Components: Site renderer
Affects Versions: 1.0-alpha-10
Reporter: Michael Osipov
Attachments: MSITE-323.patch
Right now, the footer produces only:
{code}
copy ${inceptionYear} - ${today} ${organization}
{code}
in contrast to that Javadoc produces am much more reasonable output
{code}
Copyright copy ${inceptionYear} - ${today} a
href=${organizationUrl}${organization}/a. All Rights Reserved.
{code}
Site plugin should produce such a more informative footer too if the
appropriate properties are set in the pom.
Patch patches against [alpha
10|https://svn.apache.org/repos/asf/maven/doxia/doxia-sitetools/tags/doxia-sitetools-1.0-alpha-10/doxia-site-renderer/src/main/resources/org/apache/maven/doxia/siterenderer/resources/default-site.vm]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-323) Improve site footer
[
http://jira.codehaus.org/browse/MSITE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSITE-323.
Resolution: Duplicate
moved to http://jira.codehaus.org/browse/DOXIASITETOOLS-11
Improve site footer
---
Key: MSITE-323
URL: http://jira.codehaus.org/browse/MSITE-323
Project: Maven 2.x Site Plugin
Issue Type: Improvement
Affects Versions: 2.0-beta-5
Reporter: Michael Osipov
Attachments: MSITE-323.patch
Right now, the footer produces only:
{code}
copy ${inceptionYear} - ${today} ${organization}
{code}
in contrast to that Javadoc produces am much more reasonable output
{code}
Copyright copy ${inceptionYear} - ${today} a
href=${organizationUrl}${organization}/a. All Rights Reserved.
{code}
Site plugin should produce such a more informative footer too if the
appropriate properties are set in the pom.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3366) site generation in 2.1 is totally messed up
[ http://jira.codehaus.org/browse/MNG-3366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133731#action_133731 ] John Casey commented on MNG-3366: - is this still broken? site generation in 2.1 is totally messed up --- Key: MNG-3366 URL: http://jira.codehaus.org/browse/MNG-3366 Project: Maven 2 Issue Type: Bug Components: Sites Reporting Affects Versions: 2.1-alpha-1 Reporter: Brian Fox Fix For: 2.1-alpha-1 I tried generating the enforcer site with 2.1 and i get essentially empty pages after lots of warning. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3567) pluginManagement from parent POM not used in child
pluginManagement from parent POM not used in child -- Key: MNG-3567 URL: http://jira.codehaus.org/browse/MNG-3567 Project: Maven 2 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 2.1-alpha-1 Reporter: John Casey Fix For: 2.1-alpha-1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3567) pluginManagement from parent POM not used in child
[ http://jira.codehaus.org/browse/MNG-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3567: Assignee: John Casey Fix Version/s: 2.1-alpha-1 pluginManagement from parent POM not used in child -- Key: MNG-3567 URL: http://jira.codehaus.org/browse/MNG-3567 Project: Maven 2 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 2.1-alpha-1 Reporter: John Casey Assignee: John Casey Fix For: 2.1-alpha-1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-135) inherited site.xml files are interpolated with the originating project's model values and not the consumer project's values
[
http://jira.codehaus.org/browse/MSITE-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133734#action_133734
]
Brian Jackson commented on MSITE-135:
-
I think I'm experiencing this issue or one related to it. The projects in our
organization defer their versioning to our release system. To do this our
pom.xml files all have their version as ${build.number} which our release
system (TeamCity) passes in as a -D style property. When the pom.xml is
deployed to our repository it still contains ${build.number} instead of the
substituted value. The only thing this currently screws up is the site
generation since the maven-site-plugin attempts to download the parent's
site.xml using this value rather than the correct version number for the
parent, which can be found in the parent element in the originating pom.xml or
if that value is RELEASE, in the parent's maven-metadata.xml. Any chance this
can be fixed to use the value from one of those two locations instead of
directly from the parent's pom.xml?
inherited site.xml files are interpolated with the originating project's
model values and not the consumer project's values
---
Key: MSITE-135
URL: http://jira.codehaus.org/browse/MSITE-135
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: inheritance
Affects Versions: 2.0-beta-5
Environment: 2.0.4
Reporter: John Allen
Fix For: 2.0-beta-7
inherited site.xml files are interpolated with the originating project's
model values and not the consumer project's values
i have a n-deep multiproject env; when a sub-project uses the root project's
site.xml file, any ${project.*} expressions defined in the root site.xml are
replaced with values from the root project and not the project that is being
rendered, ie. title in index.html would be root project and not
sub-sub-sub-project. This applied to all ${project.*} expressions in the
site.xml
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINVOKER-36) Support for non-project based Maven invocations
Support for non-project based Maven invocations
---
Key: MINVOKER-36
URL: http://jira.codehaus.org/browse/MINVOKER-36
Project: Maven 2.x Invoker Plugin
Issue Type: New Feature
Affects Versions: 1.1
Reporter: Benjamin Bentmann
Theoretically, creating an IT for MPLUGIN-92 (requires project) is easy: Find
yourself a directory without a POM, invoke the plugin's help goal and verify
Maven doesn't fail.
Unfortunately, the Invoker Plugin is currently quite POM-centric. For the
future, I could imagine a slightly extended include/exclude concept: Allow the
patterns to select directories, too, rather than only files. For an included
directory, use a {{pom.xml}} if it exists and invoke Maven POM-less if it
doesn't, just like if the Invoker Plugin was some user running Maven on a
command prompt.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3017) Profile activation by file fails when maven is run outside the pom's directory
[
http://jira.codehaus.org/browse/MNG-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133790#action_133790
]
Nathaniel Harward commented on MNG-3017:
I would like to add that using variables does not seem to work inside the
missing/ or exists/ elements. I would like to suggest that variable
interpolation be implemented in these elements to solve this problem and allow
for more flexibility than, for example, just looking for files relative to the
pom directory as a fix.
I tried to get around this problem by using a value of ${basedir}/xxx or
${project.basedir}/xxx with no success. ${basedir} does not work when run
inside the pom's directory either, so I know no interpolation is not being done
with these elements.
Profile activation by file fails when maven is run outside the pom's directory
--
Key: MNG-3017
URL: http://jira.codehaus.org/browse/MNG-3017
Project: Maven 2
Issue Type: Bug
Components: Profiles
Affects Versions: 2.0.6
Environment: Darwin Kernel Version 8.9.1
java version 1.6.0-dp
Java(TM) SE Runtime Environment (build 1.6.0-dp-b88-34)
Java HotSpot(TM) Client VM (build 1.6.0-b88-17-release, mixed mode, sharing)
Reporter: Jean-Luc Wasmer
Fix For: 2.0.x
Attachments: maven-test.tgz
When calling maven outside the pom's directory, the profile activation fails:
macb:~/Development/maven-test/parent jl$ mvn install
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Example parent
[INFO] Example module1
[INFO] Example module2
[INFO]
macb:~/Development/maven-test jl$ mvn -f parent/pom.xml install
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Example parent
[INFO] Example module1
[INFO]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-374) maven-scm-providers-git is missing some testdata
[ http://jira.codehaus.org/browse/SCM-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133804#action_133804 ] Brett Porter commented on SCM-374: -- I've applied the patch - thanks! However, I still got failures in commons and had to comment out the test in there. It looks like that test belongs in gitexe where these resource files were placed? maven-scm-providers-git is missing some testdata Key: SCM-374 URL: http://jira.codehaus.org/browse/SCM-374 Project: Maven SCM Issue Type: Bug Affects Versions: 1.1 Environment: linux fedora-8, git-1.5.3.3., git-1.5.4 Reporter: mark struberg Assignee: Jason van Zyl Attachments: maven-scm-providers-git-testdata.patch It seems that something has gone missing by moving the maven-scm-providers-git plugin from git to SVN. I checked out the SVN version and compared it to my git repo. It seems that the test/resource/git/ ... /*.log files have been ignored. This files contain the testdata for testing the various commandline output consumers for the git executable. The appending patch does contain all missing files plus a small change in the way the base command is constructed. Tests and TCK successfully passed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-374) maven-scm-providers-git is missing some testdata
[ http://jira.codehaus.org/browse/SCM-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated SCM-374: - Fix Version/s: 1.1 maven-scm-providers-git is missing some testdata Key: SCM-374 URL: http://jira.codehaus.org/browse/SCM-374 Project: Maven SCM Issue Type: Bug Affects Versions: 1.1 Environment: linux fedora-8, git-1.5.3.3., git-1.5.4 Reporter: mark struberg Assignee: Jason van Zyl Fix For: 1.1 Attachments: maven-scm-providers-git-testdata.patch It seems that something has gone missing by moving the maven-scm-providers-git plugin from git to SVN. I checked out the SVN version and compared it to my git repo. It seems that the test/resource/git/ ... /*.log files have been ignored. This files contain the testdata for testing the various commandline output consumers for the git executable. The appending patch does contain all missing files plus a small change in the way the base command is constructed. Tests and TCK successfully passed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
