[jira] Commented: (MSHARED-121) FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the drive letter.
[
http://jira.codehaus.org/browse/MSHARED-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=194941#action_194941
]
Kathy Hale commented on MSHARED-121:
It's funny you say that because I have the opposite problem. I'm using this bug
to disable the auto trigger because I couldn't find any way to disable it. So
if I need a path to remain unescaped (single backslashes, not doubled), I've
been breaking up the filter param like ${drive}${path}, such that ${drive} is
{{C:}} and {{${path}}} is {{\path\}}.
FilteringUtils.escapeWindowsPath doesn't handle paths that leave out the
drive letter.
--
Key: MSHARED-121
URL: http://jira.codehaus.org/browse/MSHARED-121
Project: Maven Shared Components
Issue Type: Bug
Components: maven-filtering
Affects Versions: maven-filtering-1.0-beta-3
Reporter: John Casey
Fix For: maven-filtering-1.0-beta-4
Attachments:
0001-MSHARED-121-Don-t-require-a-drive-letter-to-escape-a.patch,
FilteringUtilsTest.java
FilteringUtils.escapeWindowsPath requires a drive letter to be present in the
path, or at least the string {noformat}:\\{noformat} to be present in order
to trigger escaping the value as a windows path.
In cases where the path is an absolute reference to a file on the current
drive (no drive letter is included), or when the path starts with an
unresolved expression (in cases where n+1 level interpolation will eventually
resolve the expression), escaping doesn't happen at all.
--
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-597) Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a different version from that in dependency management)
[
http://jira.codehaus.org/browse/MECLIPSE-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=194102#action_194102
]
Kathy Hale commented on MECLIPSE-597:
-
I'm not sure if I'm having the same problem or not, but I'll comment in case.
Project A and Project B are both being migrated to Maven. I migrated A, except
for the dependency of Project B. Then migrated Project B, installed a snapshot
from B, and then added the coordinates as a dependency to Project A. While both
projects are open, Project A will not resolve the dependency (the files are
red in Navigator). But if I close Project B, you can see the snapshot jar
show up in the Maven library. As soon as I open the Project B again, the
snapshot is removed and is not being replaced with the open project (which is
what usually happened before).
In my other projects, I've seen this feature work sometimes, but not always.
Usually when I had problems, it was just out of sync for some reason, but this
is the first time where I've seen it completely fail. It's odd because calling
Update Maven dependencies is not having problems, I can do a mvn compile
while its in the broken state, but I cannot resolve that red without closing
the child project.
Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a
different version from that in dependency management)
---
Key: MECLIPSE-597
URL: http://jira.codehaus.org/browse/MECLIPSE-597
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath)
Affects Versions: 2.7
Environment: Nexus 1.3.6, Eclipse 3.4, Windows XP
Reporter: Michal Galet
Priority: Critical
Attachments: maven-eclipse-plugin-2.7.patch
When generating eclipse project with mvn eclipse:eclipse
-Declipse.workspace=d:/eclipse-ws the SNAPSHOT dependencies are not resolved
from workspace correctly. See console output below. This is probably caused
by the way how Nexus handles the SNAPSHOTs. The artifact is resolved by
ArtifactResolver and the version is changed from 1.1.0-SNAPSHOT to
1.1.0-20090819.145009-4.
The comparison should be performed against {{artifact.getBaseVersion()}}
instead of {{artifact.getVersion()}}. A simple fix is attached as a patch.
Console output:
[INFO] Artifact com.test:sample:jar:4.0.0.B02-SNAPSHOT already available a
s a workspace project, but with different version. Expected:
4.0.0.B02-20090819.145009-4, found
: 4.0.0.B02-SNAPSHOT
--
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-86) Cannot handle multiple tasks elements
[
http://jira.codehaus.org/browse/MANTRUN-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=192776#action_192776
]
Kathy Hale commented on MANTRUN-86:
---
To give you some context, I was trying import 3 targets: start web server, stop
web server, and start webserver as debug. They really aren't related to the
lifecycle as I see it, but they're still a nice developer tool to have scripted
to avoid using services and shell scripts.
So these seem like my only options unless the plugin was improved/fixed, none
of which sound very appealing:
# Mash 3 targets into one maven target, and use if/else's to control which is
called
# Leave these 3 targets in ANT and don't migrate to maven
# Bind the targets to arbitrary lifecycle phases (which doesn't really make
sense) so I can use {{execute}}
Cannot handle multiple tasks elements
-
Key: MANTRUN-86
URL: http://jira.codehaus.org/browse/MANTRUN-86
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.1
Reporter: Thomas Diesler
{code:xml}
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phaseinstall/phase
goals
goalrun/goal
/goals
configuration
tasks if=jboss.local.repository
property name=version.id value=${project.version}/
property name=jboss.local.repository
value=${jboss.local.repository}/
ant antfile=ant/build-install.xml target=install/
/tasks
tasks unless=jboss.local.repository
echo message=Cannot install to
jboss.local.repository=${jboss.local.repository}/
/tasks
/configuration
/execution
/executions
/plugin
{code}
Always executes the last tasks element although 'jboss.local.repository' is
set
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[echo] Cannot install to
jboss.local.repository=/home/tdiesler/svn/jboss.local.repository
[INFO] Executed tasks
--
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
