[jira] Updated: (MECLIPSE-629) Eclipse doesn't accept absolute path in output property of the .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent ASTRUC updated MECLIPSE-629: Attachment: patch.txt A proposal of patch Eclipse doesn't accept absolute path in output property of the .classpath - Key: MECLIPSE-629 URL: http://jira.codehaus.org/browse/MECLIPSE-629 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : .project, Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.7 Reporter: Vincent ASTRUC Attachments: patch.txt When the outputDirectory of the pom.xml is an absolute path, meclispe would have generate linked resource in .projet and use this link in .classpath. -- 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-629) Eclipse doesn't accept absolute path in output property of the .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203655#action_203655 ] Vincent ASTRUC commented on MECLIPSE-629: - The linked resources for output directories in the class EclipseProjectWritter isn't managed Eclipse doesn't accept absolute path in output property of the .classpath - Key: MECLIPSE-629 URL: http://jira.codehaus.org/browse/MECLIPSE-629 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : .project, Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.7 Reporter: Vincent ASTRUC When the outputDirectory of the pom.xml is an absolute path, meclispe would have generate linked resource in .projet and use this link in .classpath. -- 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: (MECLIPSE-629) Eclipse doesn't accept absolute path in output property of the .classpath
Eclipse doesn't accept absolute path in output property of the .classpath - Key: MECLIPSE-629 URL: http://jira.codehaus.org/browse/MECLIPSE-629 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : .project, Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.7 Reporter: Vincent ASTRUC When the outputDirectory of the pom.xml is an absolute path, meclispe would have generate linked resource in .projet and use this link in .classpath. -- 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: (MANTTASKS-162) java.lang.ClassCastException: org.codehaus.plexus.component.configurator.BasicComponentConfigurator cannot be cast to org.codehaus.plexus.component.configurator.Compone
java.lang.ClassCastException: org.codehaus.plexus.component.configurator.BasicComponentConfigurator cannot be cast to org.codehaus.plexus.component.configurator.ComponentConfigurator -- Key: MANTTASKS-162 URL: http://jira.codehaus.org/browse/MANTTASKS-162 Project: Maven 2.x Ant Tasks Issue Type: Bug Affects Versions: 2.0.10 Environment: Windows / Maven 2.2.1 Reporter: Vincent ASTRUC When we have the following declaration, a classcastexception occured plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-antrun-plugin/artifactId executions execution idkodo/id phasepackage/phase configuration tasks ant target=xxx inheritrefs=true antfile=/build.xml/ /tasks /configuration goals goalrun/goal /goals /execution /executions dependencies dependency groupIdorg.apache.maven/groupId artifactIdmaven-ant-tasks/artifactId version2.0.10/version /dependency /dependencies /plugin -- 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: (MDEP-50) dependency:unpack doesn't seem to handle version ranges
[
http://jira.codehaus.org/browse/MDEP-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115345
]
Vincent ASTRUC commented on MDEP-50:
I have the same problem
Does a version fix this problem?
dependency:unpack doesn't seem to handle version ranges
---
Key: MDEP-50
URL: http://jira.codehaus.org/browse/MDEP-50
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: copy, unpack
Affects Versions: 1.0
Environment: Java 1.5
Reporter: Martin Goldhahn
Assignee: Brian Fox
When I use the dependency unpack goal and a version range as shown below,
Maven cannot download the artifact from the repository. There is a version
1.4.1 in the repository. If I use the specific version number 1.4.1. It works.
build
plugin
groupIdorg.codehaus.mojo/groupId
artifactIddependency-maven-plugin/artifactId
executions
execution
idunpack/id
phasecompile/phase
goals
goalunpack/goal
/goals
configuration
artifactItems
artifactItem
groupIdmy.package/groupId
artifactIdconcept/artifactId
version[1.4,1.5)/version
classifierres/classifier
outputDirectory${project.build.sourceDirectory}/../webapp/res/outputDirectory
/artifactItem
/artifactItems
/configuration
/execution
/executions
/plugin
--
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: (MRELEASE-145) release:prepare requires all modules to be SNAPSHOTS
[
http://jira.codehaus.org/browse/MRELEASE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_89837
]
Vincent ASTRUC commented on MRELEASE-145:
-
The solution is to removed the code below in
org.apache.maven.shared.release.phase.CheckPomPhase
for ( Iterator it = reactorProjects.iterator(); it.hasNext(); )
{
MavenProject project = (MavenProject) it.next();
String projectId = ArtifactUtils.versionlessKey(
project.getGroupId(), project.getArtifactId() );
if ( !ArtifactUtils.isSnapshot( project.getVersion() ) )
{
throw new ReleaseFailureException(
The project + projectId + isn't a snapshot ( +
project.getVersion() + ). );
}
}
release:prepare requires all modules to be SNAPSHOTS
Key: MRELEASE-145
URL: http://jira.codehaus.org/browse/MRELEASE-145
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Affects Versions: 2.0-beta-4
Reporter: Jörg Hohwiller
The biggest need for the maven-release-plugin is in complex projects with a
lot of modules (that may again have modules). If I do not get it wrong, the
current released version forces all modules to be snapshots and releases them
individually. This is completely useless in my situation because in the end
this forces me to release alle modules together for every change that is to
be released and more or less causes that all modules have the same version
number. When I call mvn replease:prepare on my toplevel project this is no
snapshot, it fails with this error:
The project groupId:artifactId isn't a snapshot (version).
I would expect release:prepare to leave non SNAPSHOT modules untouched (and
only verify that they do not have SNAPSHOT dependencies, what should never be
the case if the version is no snapshot).
All reactor projects that have a -SNAPHSOT version should be released and
theier project-internal dependencies should also be set to the acording
released version (and later be set to the new SNAPSHOT).
Additionally I want to have the complete project to be tagged as a whole
instead of each module. This could potentially be configureable (especially
which directory is actually tagged, e.g. if the toplevel project is not in
trunk/ but somewhere deeper say trunk/develop because other directories in
trunk are huge but do not need to be checked out by every developer but need
to be tagged).
I personally think that the best flexibility and final freedom would be to
split off the release:prepare goal into 3 goals:
-create release version(s)
-create tag(s)
-update to snapshot version(s)
These goals could be used individually and one could add some custom steps or
replace one with something else.
For creating the snapshot versions there is also the problem, that you do not
know right away which project will be modified when in the future. The
coolest thing would be if this would happen automatically when the first
change is commited to the module. But this is of cause not praticable in
reality (maybe if all commits would be done with maven).
--
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
