[jira] Commented: (DOXIA-431) Doxia creates illegal URLs from local paths
[ http://jira.codehaus.org/browse/DOXIA-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268412#action_268412 ] Lukas Theussl commented on DOXIA-431: - I generally agree with your comments. The sanitize methods in URIPathDescriptor (I guess that's what you are referring to) were necessary for some backward issues I encountered when re-writing the deprecated PathDescriptor class. Note also the [comment in the relativizeLink|http://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/xref/org/apache/maven/doxia/site/decoration/inheritance/DefaultDecorationModelInheritanceAssembler.html#375] method of DefaultDecorationModelInheritanceAssembler. One thing I can point out is the javadoc in the Sink API for [figureGraphics|http://maven.apache.org/doxia/doxia/doxia-sink-api/apidocs/org/apache/maven/doxia/sink/Sink.html#figureGraphics(java.lang.String, org.apache.maven.doxia.sink.SinkEventAttributes)], which states that the image src parameter has to be a valid URL before being emitted into the Sink. So that's consistent with your remark that data should be validated at the input side, ie by the Parser. Otherwise, I think a concrete test example would help me to work on this, as I still don't know where your figure is referenced from. > Doxia creates illegal URLs from local paths > --- > > Key: DOXIA-431 > URL: http://jira.codehaus.org/browse/DOXIA-431 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.2 >Reporter: Aaron Digulla > > If a local resource contains characters which are illegal in a URL, Doxia > creates illegal code or crashes. -- 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: (MCHANGES-251) Tolerate novel issue types
Tolerate novel issue types --- Key: MCHANGES-251 URL: http://jira.codehaus.org/browse/MCHANGES-251 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: announcement Affects Versions: 2.5 Reporter: Benson Margulies Attachments: types.patch If the plugin encounters an issue with a type it's never met, the issue gets dropped on the ground. Calling such issues 'fix' results in something useful in the announcement, even if it's not ideal. -- 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: (MCHANGES-250) ccAddresses and bccAddresses should not be 'required'
[ http://jira.codehaus.org/browse/MCHANGES-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MCHANGES-250: -- Attachment: MCHANGES-250.patch > ccAddresses and bccAddresses should not be 'required' > - > > Key: MCHANGES-250 > URL: http://jira.codehaus.org/browse/MCHANGES-250 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: announcement >Affects Versions: 2.5 >Reporter: Benson Margulies > Attachments: MCHANGES-250.patch > > > It seems unkind and unnecessary to require the cc and bcc. If one doesn't > need them, why require them? -- 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-5104) Enforcing build order...
[
http://jira.codehaus.org/browse/MNG-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268373#action_268373
]
Wendy Smoak commented on MNG-5104:
--
It sounds like you want help enforcing your architecture. You might look at
tools like http://www.coverity.com/html/architecture-analyzer-for-java.html .
Meanwhile, bring this up on the mailing list to see if anyone else thinks this
would be useful. Figuring out the build order by using transitive dependencies
is part of the Maven magic and I'm not sure there'd be much support for turning
it off.
> Enforcing build order...
>
>
> Key: MNG-5104
> URL: http://jira.codehaus.org/browse/MNG-5104
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Bootstrap & Build, Reactor and workspace
>Affects Versions: 2.2.1
> Environment: Linux AMD64
>Reporter: Ancoron Luciferis
>
> Currently, building multi-module aka. reactor projects is working, but does
> not help the developers to ensure a certain level of isolation of their
> modules.
> E.g. imagine the following project tree:
> *
> ** Component A
> *** A.api
> *** A.jpa
> *** A.ejb (depends on A.api, A.jpa)
> ** Component B
> *** B.api
> *** B.jpa
> *** B.ejb (depends on B.api, B.jpa, A.api)
> ** Component C
> *** C.api
> *** C.jpa
> *** C.ejb (depends on C.api, C.jpa, A.api)
> ...and all things are just fine.
> Now, some developer comes in, not fully aware of the "big picture", producing
> something like this:
> *
> ** Component A
> *** A.api
> *** A.jpa (depends on B.jpa)
> *** A.ejb (depends on A.api, A.jpa)
> ** Component B
> *** B.api
> *** B.jpa
> *** B.ejb (depends on B.api, B.jpa, A.api, C.ejb)
> ** Component C
> *** C.api
> *** C.jpa
> *** C.ejb (depends on C.api, C.jpa, A.api)
> ...so in an old-school build with tools like Ant this would fail to build as
> the build order is clear and strict, according to best-practices. Not so with
> Maven. In the first case Maven might (although unlikely and yet to be seen)
> come up with a clear build order like this:
> #
> # Component A
> # A.api
> # A.jpa
> # A.ejb
> # Component B
> # B.api
> # B.jpa
> # B.ejb
> # Component C
> # C.api
> # C.jpa
> # C.ejb
> ...however, in the second case Maven will not fail to build and instead come
> up with something like this:
> #
> # Component A
> # A.api
> # Component B
> # B.jpa
> # A.jpa
> # A.ejb
> # B.api
> # Component C
> # C.api
> # C.jpa
> # C.ejb
> # B.ejb
> All artifacts are build correctly, but it is no longer guaranteed that e.g.
> "Component A" could be used without "Component B", therefore introducing a
> requirement and eventually a lot of changes to the build-/tool-/test-chain.
> So we would like to have an option to disable the Maven "magic" here and just
> stupidly build according to the {{}} tags we've carefully written.
--
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: (MNG-5104) Enforcing build order...
[
http://jira.codehaus.org/browse/MNG-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268373#action_268373
]
Wendy Smoak edited comment on MNG-5104 at 5/24/11 8:06 PM:
---
It sounds like you want help enforcing your architecture. You might look at
tools like http://www.coverity.com/html/architecture-analyzer-for-java.html .
Meanwhile, bring this up on the mailing list to see if anyone else thinks this
would be useful. Figuring out the build order by using the dependencies is part
of the Maven magic and I'm not sure there'd be much support for turning it off.
was (Author: wsmoak):
It sounds like you want help enforcing your architecture. You might look
at tools like http://www.coverity.com/html/architecture-analyzer-for-java.html .
Meanwhile, bring this up on the mailing list to see if anyone else thinks this
would be useful. Figuring out the build order by using transitive dependencies
is part of the Maven magic and I'm not sure there'd be much support for turning
it off.
> Enforcing build order...
>
>
> Key: MNG-5104
> URL: http://jira.codehaus.org/browse/MNG-5104
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Bootstrap & Build, Reactor and workspace
>Affects Versions: 2.2.1
> Environment: Linux AMD64
>Reporter: Ancoron Luciferis
>
> Currently, building multi-module aka. reactor projects is working, but does
> not help the developers to ensure a certain level of isolation of their
> modules.
> E.g. imagine the following project tree:
> *
> ** Component A
> *** A.api
> *** A.jpa
> *** A.ejb (depends on A.api, A.jpa)
> ** Component B
> *** B.api
> *** B.jpa
> *** B.ejb (depends on B.api, B.jpa, A.api)
> ** Component C
> *** C.api
> *** C.jpa
> *** C.ejb (depends on C.api, C.jpa, A.api)
> ...and all things are just fine.
> Now, some developer comes in, not fully aware of the "big picture", producing
> something like this:
> *
> ** Component A
> *** A.api
> *** A.jpa (depends on B.jpa)
> *** A.ejb (depends on A.api, A.jpa)
> ** Component B
> *** B.api
> *** B.jpa
> *** B.ejb (depends on B.api, B.jpa, A.api, C.ejb)
> ** Component C
> *** C.api
> *** C.jpa
> *** C.ejb (depends on C.api, C.jpa, A.api)
> ...so in an old-school build with tools like Ant this would fail to build as
> the build order is clear and strict, according to best-practices. Not so with
> Maven. In the first case Maven might (although unlikely and yet to be seen)
> come up with a clear build order like this:
> #
> # Component A
> # A.api
> # A.jpa
> # A.ejb
> # Component B
> # B.api
> # B.jpa
> # B.ejb
> # Component C
> # C.api
> # C.jpa
> # C.ejb
> ...however, in the second case Maven will not fail to build and instead come
> up with something like this:
> #
> # Component A
> # A.api
> # Component B
> # B.jpa
> # A.jpa
> # A.ejb
> # B.api
> # Component C
> # C.api
> # C.jpa
> # C.ejb
> # B.ejb
> All artifacts are build correctly, but it is no longer guaranteed that e.g.
> "Component A" could be used without "Component B", therefore introducing a
> requirement and eventually a lot of changes to the build-/tool-/test-chain.
> So we would like to have an option to disable the Maven "magic" here and just
> stupidly build according to the {{}} tags we've carefully written.
--
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: (MCHANGES-250) ccAddresses and bccAddresses should not be 'required'
ccAddresses and bccAddresses should not be 'required' - Key: MCHANGES-250 URL: http://jira.codehaus.org/browse/MCHANGES-250 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: announcement Affects Versions: 2.5 Reporter: Benson Margulies It seems unkind and unnecessary to require the cc and bcc. If one doesn't need them, why require them? -- 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: (MCHANGES-248) Support custom jira status ids, please
[ http://jira.codehaus.org/browse/MCHANGES-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MCHANGES-248: -- Attachment: MCHANGES-248.patch This patch allows numeric statusId values. > Support custom jira status ids, please > -- > > Key: MCHANGES-248 > URL: http://jira.codehaus.org/browse/MCHANGES-248 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: jira >Affects Versions: 2.5 >Reporter: Benson Margulies > Attachments: MCHANGES-248.patch > > > It is possible to add status IDs to JIRA. e.g., Verified. There is currently > no way to make these work with the changes 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] Updated: (MCHANGES-249) The jira downloaded used for announcements only supports 'closed'
[ http://jira.codehaus.org/browse/MCHANGES-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MCHANGES-249: -- Attachment: MCHANGES-249.patch Remove the extra JiraDownloader that has no effect except to prevent announcements of unclosed issues. > The jira downloaded used for announcements only supports 'closed' > - > > Key: MCHANGES-249 > URL: http://jira.codehaus.org/browse/MCHANGES-249 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: announcement >Affects Versions: 2.5 >Reporter: Benson Margulies > Attachments: MCHANGES-249.patch > > > org.apache.maven.plugin.announcement.JiraDownloader only puts 'Closed' in the > statusMap, so it's not possible to specify, say, Resolved,Closed. > Why are there two of these, anyhow? -- 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: (MCHANGES-249) The jira downloaded used for announcements only supports 'closed'
The jira downloaded used for announcements only supports 'closed' - Key: MCHANGES-249 URL: http://jira.codehaus.org/browse/MCHANGES-249 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: announcement Affects Versions: 2.5 Reporter: Benson Margulies org.apache.maven.plugin.announcement.JiraDownloader only puts 'Closed' in the statusMap, so it's not possible to specify, say, Resolved,Closed. Why are there two of these, anyhow? -- 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: (MCHANGES-248) Support custom jira status ids, please
Support custom jira status ids, please -- Key: MCHANGES-248 URL: http://jira.codehaus.org/browse/MCHANGES-248 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: jira Affects Versions: 2.5 Reporter: Benson Margulies It is possible to add status IDs to JIRA. e.g., Verified. There is currently no way to make these work with the changes 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] Created: (MCHANGES-247) StatusIds don't end up in the URL
StatusIds don't end up in the URL
-
Key: MCHANGES-247
URL: http://jira.codehaus.org/browse/MCHANGES-247
Project: Maven 2.x Changes Plugin
Issue Type: Bug
Components: jira
Affects Versions: 2.5
Reporter: Benson Margulies
Running announcement-generate. Note from the -X output blob here that I have
selected more statusIds than 'Closed'. But then see the URL from a little
further down the trace, where statusIds=6.
{noformat}
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-changes-plugin:2.5:announcement-generate' -->
[DEBUG] (s) artifactId = basis-parent
[DEBUG] (f) basedir = /Users/benson/x/maven-support/basis-parent/trunk
[DEBUG] (s) developmentTeam = Common Parent for Basis Maven Projects team
[DEBUG] (s) finalName = basis-parent-26-SNAPSHOT
[DEBUG] (f) generateJiraAnnouncement = false
[DEBUG] (s) groupId = com.basistech
[DEBUG] (f) issueManagementSystems = [JIRA]
[DEBUG] (f) jiraMerge = false
[DEBUG] (f) jiraPassword = xx
[DEBUG] (f) jiraUser = maven-reporting
[DEBUG] (f) jiraXML =
/Users/benson/x/maven-support/basis-parent/trunk/target/jira-announcement.xml
[DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@4e3e97cd
[DEBUG] (f) maxEntries = 25
[DEBUG] (s) outputDirectory =
/Users/benson/x/maven-support/basis-parent/trunk/target/announcement
[DEBUG] (s) packaging = pom
[DEBUG] (f) project = MavenProject: com.basistech:basis-parent:26-SNAPSHOT @
/Users/benson/x/maven-support/basis-parent/trunk/pom.xml
[DEBUG] (f) resolutionIds = Fixed
[DEBUG] (f) runOnlyAtExecutionRoot = false
[DEBUG] (f) settings = org.apache.maven.settings.Settings@7fb6a1c4
[DEBUG] (f) statusIds = Resolved,Closed
[DEBUG] (f) template = announcement.vm
[DEBUG] (f) templateDirectory = org/apache/maven/plugin/announcement
[DEBUG] (f) tracQuery = order=id
[DEBUG] (s) url = http://hudson.basistech.net:8280/projects/basis-parent
[DEBUG] (s) version = 26-SNAPSHOT
[DEBUG] (s) xmlPath =
/Users/benson/x/maven-support/basis-parent/trunk/src/changes/changes.xml
...
[DEBUG] Found the pid 10300 at
http://jira.basistech.net:8080/browse/MAVEN/component/10784
[ERROR] maven-changes-plugin: None of the configured sortColumnNames 'null' are
correct.
[DEBUG] download jira issues from url
http://jira.basistech.net:8080/secure/IssueNavigator.jspa?view=rss&pid=10300&statusIds=6&resolutionIds=1&tempMax=25&reset=true&decorator=none
[INFO] Downloading from JIRA at:
http://jira.basistech.net:8080/secure/IssueNavigator.jspa?view=rss&pid=10300&statusIds=6&resolutionIds=1&tempMax=25&reset=true&decorator=none
{noformat}
--
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-5104) Enforcing build order...
Enforcing build order...
Key: MNG-5104
URL: http://jira.codehaus.org/browse/MNG-5104
Project: Maven 2 & 3
Issue Type: Improvement
Components: Bootstrap & Build, Reactor and workspace
Affects Versions: 2.2.1
Environment: Linux AMD64
Reporter: Ancoron Luciferis
Currently, building multi-module aka. reactor projects is working, but does not
help the developers to ensure a certain level of isolation of their modules.
E.g. imagine the following project tree:
*
** Component A
*** A.api
*** A.jpa
*** A.ejb (depends on A.api, A.jpa)
** Component B
*** B.api
*** B.jpa
*** B.ejb (depends on B.api, B.jpa, A.api)
** Component C
*** C.api
*** C.jpa
*** C.ejb (depends on C.api, C.jpa, A.api)
...and all things are just fine.
Now, some developer comes in, not fully aware of the "big picture", producing
something like this:
*
** Component A
*** A.api
*** A.jpa (depends on B.jpa)
*** A.ejb (depends on A.api, A.jpa)
** Component B
*** B.api
*** B.jpa
*** B.ejb (depends on B.api, B.jpa, A.api, C.ejb)
** Component C
*** C.api
*** C.jpa
*** C.ejb (depends on C.api, C.jpa, A.api)
...so in an old-school build with tools like Ant this would fail to build as
the build order is clear and strict, according to best-practices. Not so with
Maven. In the first case Maven might (although unlikely and yet to be seen)
come up with a clear build order like this:
#
# Component A
# A.api
# A.jpa
# A.ejb
# Component B
# B.api
# B.jpa
# B.ejb
# Component C
# C.api
# C.jpa
# C.ejb
...however, in the second case Maven will not fail to build and instead come up
with something like this:
#
# Component A
# A.api
# Component B
# B.jpa
# A.jpa
# A.ejb
# B.api
# Component C
# C.api
# C.jpa
# C.ejb
# B.ejb
All artifacts are build correctly, but it is no longer guaranteed that e.g.
"Component A" could be used without "Component B", therefore introducing a
requirement and eventually a lot of changes to the build-/tool-/test-chain.
So we would like to have an option to disable the Maven "magic" here and just
stupidly build according to the {{}} tags we've carefully written.
--
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-5103) NPE thrown when DefaultArtifact.getSelectedVersion is called
[
http://jira.codehaus.org/browse/MNG-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268362#action_268362
]
Jared Roberts commented on MNG-5103:
I'm resurrecting this from MNG-4887 because I also ran into the same issue. For
certain artifacts, it seems that the versionRange does not get initialized and
will throw an NPE when
[{{DefaultArtifact.getSelectedVersion()}}|http://maven.apache.org/ref/2.2.1/maven-artifact/xref/org/apache/maven/artifact/DefaultArtifact.html#618]
is called. I encountered it while using Maven 2.1.0 and 2.2.1. Switching to
3.0.1 resolved my specific issue, so I assume something changed in the way the
Artifact gets created. The original poster referenced using
{{DefaultArtifact.getVersionRange()}} where there is a relevant
[comment|http://maven.apache.org/ref/2.2.1/maven-artifact/xref/org/apache/maven/artifact/DefaultArtifact.html#513]
hinting that further investigation was probably needed.
I worked around the issue by using the following code block
{code:title=Before.java}
Artifact dep = ...;
ArtifactVersion selectedVersion = dep.getSelectedVersion();
{code}
{code:title=After.java}
Artifact dep = ...;
ArtifactVersion selectedVersion = dep.getVersionRange().getSelectedVersion(dep);
{code}
> NPE thrown when DefaultArtifact.getSelectedVersion is called
>
>
> Key: MNG-5103
> URL: http://jira.codehaus.org/browse/MNG-5103
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0
> Environment: not env dependent
>Reporter: Jared Roberts
>
> getSelectedVersion() uses the versionRange variable directly instead of using
> getVersionRange() which creates the version range from version if its null.
> This bug when using the appfuse warpath plugin when doing a double war overlay
--
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-5103) NPE thrown when DefaultArtifact.getSelectedVersion is called
NPE thrown when DefaultArtifact.getSelectedVersion is called Key: MNG-5103 URL: http://jira.codehaus.org/browse/MNG-5103 Project: Maven 2 & 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0 Environment: not env dependent Reporter: Jared Roberts Assignee: Benjamin Bentmann getSelectedVersion() uses the versionRange variable directly instead of using getVersionRange() which creates the version range from version if its null. This bug when using the appfuse warpath plugin when doing a double war overlay -- 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: (WAGON-331) Upgrade Wagon to use Java5 compatible libraries and finally drop old dependencies
[ http://jira.codehaus.org/browse/WAGON-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated WAGON-331: -- Affects Version/s: (was: 2.0) Fix Version/s: 2.0 > Upgrade Wagon to use Java5 compatible libraries and finally drop old > dependencies > - > > Key: WAGON-331 > URL: http://jira.codehaus.org/browse/WAGON-331 > Project: Maven Wagon > Issue Type: Improvement >Reporter: Mark Struberg > Fix For: 2.0 > > > I created a wagon-1.x branch for being able to maintain maven-2.0.x features > (even if its unlikely that this will ever happen). > Wagon-2.x is requiring java >= 5 and thus we can (should!) drop old > dependencies (e.g. avalon framework deps) and upgrade to the latest and > greatest versions. > See WAGON-329 for an initial patch (starting point only). -- 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-199) Getting SVN error "not working copy" during release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268331#action_268331 ] Antony Wilkins commented on MRELEASE-199: - This issue seems related and may offer a path to a solution if so: http://forum.springsource.org/showthread.php?105191-Weird-problem-with-STS-Eclipse-and-SVN-entries-file > Getting SVN error "not working copy" during release:prepare > --- > > Key: MRELEASE-199 > URL: http://jira.codehaus.org/browse/MRELEASE-199 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-4, 2.0-beta-5 > Environment: PC XP Pro >Reporter: Brian Ely >Priority: Critical > Attachments: testc.txt > > > I've search around the web finding problems similar but not exactly like > mine. Hopefully someone out there can help me. I'm trying to build a tagged > release and code versioning using maven (2.0.4 & 2.0.5) with subversion > (win32-1.4.2). According to documentation, all I would need to do is do the > release:prepare dryrun first and the full prepare second using the files from > the dryrun. This succeeds in a successful build but no tags. > The next step, release:perform, complains of no tag release during checkout. > I saw a bulletin board conversation indicating that a "release:clean" was > required between the dryrun and full prepare in order to get the tags. This > results in the error "not a working copy" from SVN - see attachment (from the > run of the full prepare with -e -X options). Any run of the release:perform > results in the complaint that the tags does not exist. The exact commands > are as follows: > mvn -DdryRun=true release:prepare > mvn release:clean > mvn -e -X release:prepare > It appears the "working copy" directory was not built out correctly (from the > error log in attachment): > svn: 'C:\Builds\multipgm\Latest\src' is not a working copy > svn: Can't open file 'C:\Builds\multipgm\Latest\src\.svn\entries': The system > cannot find the path specified. > I believe the path is not built out correctly and is missing paths between > the src and .svn. > I appreciate any help here, since this is a showstopper and from what I can > tell should work according to Maven documentation. -- 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-2199) Version ranges not supported for parent artifacts
[
http://jira.codehaus.org/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268326#action_268326
]
Dmitry Katsubo commented on MNG-2199:
-
This is a feature I would like to have as well. In my case I would like to see
the ["imported"
dependencies|http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies]
to work with version ranges.
> Version ranges not supported for parent artifacts
> -
>
> Key: MNG-2199
> URL: http://jira.codehaus.org/browse/MNG-2199
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation, POM, Reactor and workspace
>Affects Versions: 2.0.3
>Reporter: Christian Schulte
> Fix For: Issues to be reviewed for 3.x
>
>
> It would be great if Maven supports version ranges when specifying parent
> artifacts in a multi-module build. Currently this does not work.
>
> artifactId
> groupId
> [2.0, 2.0.1]
>
> [INFO] Scanning for projects...
> Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
> 2.0.1]/artifactId-[2.0, 2.0.1].pom
> Additionally it would be great if this
>
> artifactId
> groupId
> [2.0, ${pom.version}]
>
> [INFO] Scanning for projects...
> Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
> ${pom.version}]/artifactId-[2.0, ${pom.version}].pom
> would also work, if the version is specified in the same pom.xml which
> defines this parent definition.
--
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: (DOXIA-431) Doxia creates illegal URLs from local paths
[ http://jira.codehaus.org/browse/DOXIA-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268325#action_268325 ] Aaron Digulla commented on DOXIA-431: - I have no idea. But from my experience, I'd say that those URLs should already be encoded. I mean "Image[1].png" is a valid Unix filename. If you want to use that as a caption, you need escaping. So maybe the solution is to reject strings which contain invalid characters close to the input side. But I saw that you have sanitize methods in some URL helper class in Doxia. That led me to think that you want to do it there and I don't believe this will work. Data must be sanitized and validated in the outside interface, not deep in the code. > Doxia creates illegal URLs from local paths > --- > > Key: DOXIA-431 > URL: http://jira.codehaus.org/browse/DOXIA-431 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.2 >Reporter: Aaron Digulla > > If a local resource contains characters which are illegal in a URL, Doxia > creates illegal code or crashes. -- 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: (WAGON-331) Upgrade Wagon to use Java5 compatible libraries and finally drop old dependencies
Upgrade Wagon to use Java5 compatible libraries and finally drop old dependencies - Key: WAGON-331 URL: http://jira.codehaus.org/browse/WAGON-331 Project: Maven Wagon Issue Type: Improvement Affects Versions: 2.0 Reporter: Mark Struberg I created a wagon-1.x branch for being able to maintain maven-2.0.x features (even if its unlikely that this will ever happen). Wagon-2.x is requiring java >= 5 and thus we can (should!) drop old dependencies (e.g. avalon framework deps) and upgrade to the latest and greatest versions. See WAGON-329 for an initial patch (starting point only). -- 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-539) Reporting plugin version references in new configuration example are wrong and misleading
[ http://jira.codehaus.org/browse/MSITE-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268324#action_268324 ] Lukas Theussl commented on MSITE-539: - Is this still related to the original topic of a wrong documentation example? If not, please create a new issue, and if yes, please also create a new issue :) > Reporting plugin version references in new configuration example are wrong > and misleading > - > > Key: MSITE-539 > URL: http://jira.codehaus.org/browse/MSITE-539 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: Maven 3 >Affects Versions: 3.0-beta-3 >Reporter: Stevo Slavic >Assignee: Lukas Theussl >Priority: Minor > Attachments: MSITE-539.zip > > > [New configuration > example|http://maven.apache.org/plugins/maven-site-plugin-3.0-beta-3/maven-3.html#New_Configuration] > shows invalid reference to maven-javadoc-plugin version - version info there > won't break a build but it is simply not used by Maven 3 or site plugin > (maven reports that version info is not available for such reporting plugin). > Such wrong example might mislead users that this is expected way of > specifying version of reporting plugin used within maven site plugin > configuration. Example following new configuration example, related to > version resolution, is valid, it specifies reporting plugin version info in > pluginManagement section. -- 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: (ARCHETYPE-372) Wrong pom.xml encoding in archetypes with modules
Wrong pom.xml encoding in archetypes with modules -- Key: ARCHETYPE-372 URL: http://jira.codehaus.org/browse/ARCHETYPE-372 Project: Maven Archetype Issue Type: Bug Components: Generator Affects Versions: 2.0 Reporter: Emilio Jose Mena Cebrian In archetypes with modules, the parent pom.xml is written in the system default encoding instead of UTF-8 (encoding for poms according to DefaultFilesetArchetypeGenerator.java) The problem is located at method DefaultPomManager.addModule(), at line 86: 86 SAXReader reader = new SAXReader(); 87 Document document = reader.read( fileReader ); Encoding property of SAXReader object is not set and according to org.dom4j.io.SAXReader API public void setEncoding(String encoding) Sets encoding used for InputSource (null means system default encoding) the default encoding is used for reading the pom.xml when adding a module, but UTF-8 was used to generate that file. -- 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: (MPIR-182) Make order of reports shown in "Project Reports" configurable
[
http://jira.codehaus.org/browse/MPIR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268321#action_268321
]
Lukas Theussl commented on MPIR-182:
Running the IT with site plugin 2.3 does not order the reports alphabetically
anymore (due to MSHARED-172). However, the order of reports is also not the
same as specified in the pom. I checked that the order is already arbitrary in
the plexus @parameter expression="${reports}" that gets injected in
AbstractSiteRenderingMojo, so this seems to come from maven core.
> Make order of reports shown in "Project Reports" configurable
> -
>
> Key: MPIR-182
> URL: http://jira.codehaus.org/browse/MPIR-182
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Improvement
>Affects Versions: 2.1.2
>Reporter: Andreas Sewe
>Assignee: Lukas Theussl
>Priority: Minor
>
> As far as I can tell the plugin's reports are presented in alphabetical order
> in the "Project Reports" menu. While having "About" come first seems natural,
> some of the other menu items (in particular, "Source Repository") are placed
> less than optimally. Why not make this configurable, e.g., by making the
> order significant in which the {{report}} elements occur in the plugin's
> configuration?
--
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-539) Reporting plugin version references in new configuration example are wrong and misleading
[
http://jira.codehaus.org/browse/MSITE-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268320#action_268320
]
Stevo Slavic commented on MSITE-539:
I managed to reproduce this one. When releasing corporate Maven parent project,
release:perform goal checkouts tag created with release:prepare, runs a build
with specified goals (-Dgoals=deploy) and for that inner build Maven prints out
warnings that version is not set for maven-javadoc-plugin plugin although it is
set, maven-site-plugin has reportPlugins and within it, along with other
reporting plugins is maven-javadoc-plugin with version 2.8 set.
Environment:
- Maven 3.0.3,
- Java 1.6 update 24 x64,
- Windows 7 x64,
- maven-release-plugin 2.1
- maven-site-plugin 3.0-beta-3
Build output follows:
{noformat}
D:\foo\foo.bar.maven.parent>mvn release:perform -s settings.xml -Dgoals=deploy
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Foo Maven Parent 14-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-release-plugin:2.1:perform (default-cli) @
foo.bar.maven.parent ---
[INFO] Checking out the project to perform the release ...
[INFO] Executing: cmd.exe /X /C "svn --non-interactive checkout
https://svn.foo.bar/foo-repo/parent
/tags/releases/foo.bar.maven.parent-13
D:\foo\foo.bar.maven.parent\target\checkout"
[INFO] Working directory: D:\foo\foo.bar.maven.parent\target
[INFO] Executing goals 'deploy'...
[WARNING] Maven will be executed in interactive mode, but no input stream has
been configured for this MavenInvoker inst
ance.
[INFO] [INFO] Scanning for projects...
[INFO] [WARNING]
[INFO] [WARNING] Some problems were encountered while building the effective
model for foo.bar.maven:foo.bar.maven.p
arent:pom:13
[INFO] [WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-javadoc-plugin is missing.
[INFO] [WARNING]
[INFO] [WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[INFO] [WARNING]
[INFO] [WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[INFO] [WARNING]
[INFO] [INFO]
[INFO] [INFO]
[INFO] [INFO] Building Foo Maven Parent 13
[INFO] [INFO]
[INFO] [INFO]
[INFO] [INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-versions) @
foo.bar.maven.parent ---
[INFO] [INFO]
[INFO] [INFO] >>> maven-source-plugin:2.1.2:jar (attach-sources) @
foo.bar.maven.parent >>>
[INFO] [INFO]
[INFO] [INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-versions) @
foo.bar.maven.parent ---
[INFO] [INFO]
[INFO] [INFO] <<< maven-source-plugin:2.1.2:jar (attach-sources) @
foo.bar.maven.parent <<<
[INFO] [INFO]
[INFO] [INFO] --- maven-source-plugin:2.1.2:jar (attach-sources) @
foo.bar.maven.parent ---
[INFO] [INFO]
[INFO] [INFO] --- maven-javadoc-plugin:2.8:jar (attach-javadocs) @
foo.bar.maven.parent ---
[INFO] [INFO] Not executing Javadoc as the project is not a Java
classpath-capable package
[INFO] [INFO]
[INFO] [INFO] --- maven-site-plugin:3.0-beta-3:attach-descriptor
(attach-descriptor) @ foo.bar.maven.parent ---
[INFO] [INFO]
[INFO] [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
foo.bar.maven.parent ---
[INFO] [INFO] Installing D:\foo\foo.bar.maven.parent\target\checkout\pom.xml to
C:\Users\s.slavic\
.m2\repository\foo\bar\maven\foo.bar.maven.parent\13\foo.bar.maven.parent-13.pom
[INFO] [INFO] Installing
D:\foo\foo.bar.maven.parent\target\checkout\target\foo.bar.maven.parent
-13-site.xml to
C:\Users\s.slavic\.m2\repository\foo\bar\maven\foo.bar.maven.parent\13\foo.bar.maven.parent-13-sit
e.xml
[INFO] [INFO]
[INFO] [INFO] --- maven-deploy-plugin:2.6:deploy (default-deploy) @
foo.bar.maven.parent ---
[INFO] Uploading:
https://repo.foo.bar/content/repositories/foo-repo/foo/bar/maven/foo.bar.maven.paren
t/13/foo.bar.maven.parent-13.pom
[INFO] 4 KB
[INFO] 8 KB
[INFO] 12 KB
[INFO] 14 KB
[INFO]
[INFO] Uploaded:
https://repo.foo.bar/content/repositories/foo-repo/foo/bar/maven/foo.bar.maven.parent
/13/foo.bar.maven.parent-13.pom (14 KB at 5.0 KB/sec)
[INFO] Downloading:
https://repo.foo.bar/content/repositories/foo-repo/foo/bar/maven/foo.bar.maven.par
ent/maven-metadata.xml
[INFO]
[INFO] Uploading:
https://repo.foo.bar/content/repositories/foo-repo/foo/bar/maven/foo.bar.maven.paren
t/maven-metadata.xml
[INFO] 311 B
[INFO]
[INFO] Uploaded:
https://repo.foo.bar/content/repositories/foo-repo/foo/bar/maven/foo.bar.maven.parent
/maven-metadata.xml (311 B at 1.2 KB/sec)
[INFO] Uploading:
https://repo.foo.bar/content/repositories/foo-repo/foo/bar/maven/foo.bar.maven.paren
t/13/foo.bar.maven.parent-13-site.xml
[INFO] 751 B
[INFO]
[INFO
[jira] Created: (MCHANGES-246) Create an issue link template for Trackplus
Create an issue link template for Trackplus --- Key: MCHANGES-246 URL: http://jira.codehaus.org/browse/MCHANGES-246 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: other issue-trackers Reporter: Benjamin Voigt Trackplus (http://www.trackplus.com/) is a commercial tracking system, that we use in our company. The Issue Link Template would look like the following: %URL%/printItem.action?key=%ISSUE% -- 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: (WAGON-330) Move to ASF httpclient 4.x
[ http://jira.codehaus.org/browse/WAGON-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated WAGON-330: --- Fix Version/s: 2.0 Assignee: Olivier Lamy > Move to ASF httpclient 4.x > -- > > Key: WAGON-330 > URL: http://jira.codehaus.org/browse/WAGON-330 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-webdav >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.0 > > -- 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: (WAGON-330) Move to ASF httpclient 4.x
Move to ASF httpclient 4.x -- Key: WAGON-330 URL: http://jira.codehaus.org/browse/WAGON-330 Project: Maven Wagon Issue Type: Improvement Components: wagon-http, wagon-webdav Reporter: Olivier Lamy -- 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-627) Fix multi-repository support in the release plugin and make it work with e.g. mercurial subrepositories
[ http://jira.codehaus.org/browse/MRELEASE-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268300#action_268300 ] Lukas Fryc commented on MRELEASE-627: - Hello, any chance to have this patch in 2.2 release? > Fix multi-repository support in the release plugin and make it work with e.g. > mercurial subrepositories > --- > > Key: MRELEASE-627 > URL: http://jira.codehaus.org/browse/MRELEASE-627 > Project: Maven 2.x Release Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Henning Schmiedehausen > Attachments: MRELEASE-627-2, release-plugin-patch > > > The maven-release-plugin is pretty much designed to work with a single > repository and tag and branch from this. As soon as a project tree is more > complex and e.g. uses nested or multiple repositories (such as the Mercurial > subrepos), it fails. > The attached patch fixes most of the use cases that allow releasing large > (reactor) projects that span multiple projects and use one repository per > project. > New properties: > revertOrder (boolean) - Default: false > Reverts the order in which commit, tag and branch process multi-repos. E.g. > in Mercurial, the main repository (which contains the subrepos) must be > processed last, because it implicitly records state of the relationship > between the main and the sub repository. If it gets committed first, then > this state is not recorded correctly. By reverting the order, the main > repository is committed last. > commitAllChanges (boolean) - Default: false > The release plugin tries to explicitly list which files it commits. However, > in the case of a multi-repository tree, in then tries e.g. to commit > repo/pom.xml, repo/a/pom.xml and repo/b/pom.xml in the context of "repo" > which then fails (because repo/a/pom.xml and repo/b/pom.xml are actually part > of the subrepos a and b). Setting this parameters omits the list of files and > tells the SCM to "commit everything". E.g. Mercurial then picks up the > changes correctly and also records the implicit state between master and sub > repositories correctly. > tagByProject, branchByProject (boolean) - Default: false > Similar to the existing 'commitByProject', these options select whether a tag > or a branch should be created by running the tag command in the root of the > tree or by looping through all projects and tagging or branching them > one-by-one. Default is to tag in the root. > tagRequiresCommit / branchRequiresCommit (boolean) - Default: false > Mercurial manages tags by adding entries to the '.hgtags' file, which is > managed implicitly by the SCM. If a subrepository gets tagged as part of a > larger, multi-repo project, then the changes must be explicitly committed, > else they don't get picked up by the main repository. This sounds more > complicated than it actually is, the summary is that "this must be 'true' for > Mercurial and probably "false" for everything else. > Those changes *should* work with the 1.4 SCM provider, but were tested only > with the 1.5-SNAPSHOT release. It also benefits from fixing the pushChanges > support in the Mercurial provider. > If you want to test drive this patch, you should also be interested in > SCM-587. -- 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: (DOXIA-431) Doxia creates illegal URLs from local paths
[
http://jira.codehaus.org/browse/DOXIA-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268294#action_268294
]
Lukas Theussl commented on DOXIA-431:
-
Yeah, I'm somewhat familiar with url encoding :)
I meant whether it is documented somewhere within maven/doxia wheher file
references have to be urls, eg whether you are allowed to use in an apt source
file
{noformat}
[The ExTeX Project.png] Figure caption
{noformat}
or in a site.xml
{noformat}
{noformat}
I guess the answer is yes, but I'm just wondering if there is anything in the
docs.
> Doxia creates illegal URLs from local paths
> ---
>
> Key: DOXIA-431
> URL: http://jira.codehaus.org/browse/DOXIA-431
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2
>Reporter: Aaron Digulla
>
> If a local resource contains characters which are illegal in a URL, Doxia
> creates illegal code or crashes.
--
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: (DOXIASITETOOLS-60) Useless error message "error in opening zip file" in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268293#action_268293
]
Lukas Theussl commented on DOXIASITETOOLS-60:
-
Try site-plugin-2.4-SNAPSHOT. Also did you run with -X to get the full debug
output?
> Useless error message "error in opening zip file" in
> DefaultSiteRenderer.createContextForSkin()
> ---
>
> Key: DOXIASITETOOLS-60
> URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-60
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.2
>Reporter: Aaron Digulla
>Assignee: Lukas Theussl
> Fix For: 1.2.1
>
>
> When I run {{mvn site}} on my project, I get an exception in
> DefaultSiteRenderer.createContextForSkin(): "error in opening zip file"
> Which zip file?
--
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: (WAGON-329) FtpWagon currently tries to invoka an invalid MKD command with nested directories
[ http://jira.codehaus.org/browse/WAGON-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated WAGON-329: Attachment: WAGON-329.patch This is a patch which drops the avalon based old ftp server, upgrades to java5 and a new junit-4 version which we need for finally enabling the TCK. Lots of things are still broken, but the MKD issue is clearly reproducable. This also drops a few stone old dependencies like a <1.0 plexus-utils, avalon, etc Please review this patch, especially the way I start the FTP server. I just felt that using old plexus for setting up test components is just too complicated and fired up the (Apache MINA based) FTP server manually. If we need this in other places too, then we should of course move this to a real component. It may be a good idea to create a new maintenance branch from the current trunk and bump the version on wagon to 1.1 or even 2.0 for moving to the latest and greatest stuff. WDYT? > FtpWagon currently tries to invoka an invalid MKD command with nested > directories > - > > Key: WAGON-329 > URL: http://jira.codehaus.org/browse/WAGON-329 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ftp >Affects Versions: 1.0-alpha-7 >Reporter: Mark Struberg > Attachments: WAGON-329.patch > > > Currently a wagon request to remotely create a deep subdirectory (unix > equivalent would be mkdir -p /dir1/dir2/dir3) will result in a MKD invocation > with the full deep subdirectory path. > According to the FTP specification this is *not* valid (RFC-959 > http://www.faqs.org/rfcs/rfc959.html APPENDIX II - DIRECTORY COMMANDS). > There might be some FTP servers out there which curreclty create the > directory, but 2 ftpd I tried just returned an error. > Instead we should split up the directory paths and walk over them recursively. -- 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: (WAGON-329) FtpWagon currently tries to invoka an invalid MKD command with nested directories
FtpWagon currently tries to invoka an invalid MKD command with nested directories - Key: WAGON-329 URL: http://jira.codehaus.org/browse/WAGON-329 Project: Maven Wagon Issue Type: Bug Components: wagon-ftp Affects Versions: 1.0-alpha-7 Reporter: Mark Struberg Currently a wagon request to remotely create a deep subdirectory (unix equivalent would be mkdir -p /dir1/dir2/dir3) will result in a MKD invocation with the full deep subdirectory path. According to the FTP specification this is *not* valid (RFC-959 http://www.faqs.org/rfcs/rfc959.html APPENDIX II - DIRECTORY COMMANDS). There might be some FTP servers out there which curreclty create the directory, but 2 ftpd I tried just returned an error. Instead we should split up the directory paths and walk over them recursively. -- 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: (MCHANGES-199) changes:trac-report fails with [Fatal Error] :1:50: White spaces are required between publicId and systemId.
[ http://jira.codehaus.org/browse/MCHANGES-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268289#action_268289 ] Alexander Papaspyrou commented on MCHANGES-199: --- If someone would tell me what to do to get this report, I could as well do this -- it's just that I don't have any idea how... > changes:trac-report fails with [Fatal Error] :1:50: White spaces are required > between publicId and systemId. > > > Key: MCHANGES-199 > URL: http://jira.codehaus.org/browse/MCHANGES-199 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: trac >Affects Versions: 2.3 > Environment: Server: > Trac 0.11.5 (with XML-RPC plugin 1.1.0) on Apache 2.2.12 > Client: > Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: de_DE, platform encoding: MacRoman > OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac" >Reporter: Alexander Papaspyrou > > The changes plugin fails on changes:trac-report invocation (and as part of > mvn site:site) with > [Fatal Error] :1:50: White spaces are required between publicId and > systemId. > and later (end of build) with > Embedded error: XmlRpc Error. > Failed to parse servers response: White spaces are required between > publicId and systemId. > The XML-RPC installation in Trac is working fine > (http://trac.localhost/trac//xmlrpc renders help pages; Eclipse > Mylyn able to access), and XML_RPC/TICKET_VIEW/REPORT_VIEW permissions are > granted to anonymous. > Ideas? -- 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: (DOXIASITETOOLS-2) Doxia default site renderer redefines local macros over and over again
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIASITETOOLS-2: --- Fix Version/s: (was: 1.3) > Doxia default site renderer redefines local macros over and over again > -- > > Key: DOXIASITETOOLS-2 > URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-2 > Project: Maven Doxia Sitetools > Issue Type: Bug > Components: Site renderer >Reporter: Henning Schmiedehausen > > The Doxia default site renderer uses Apache Velocity to render its pages. > Every time a page is rendered, Doxia tries to define Velocity Macros but the > Plexus Velocity component sets the replacement of Velocity Macro to false > (the default). > In Velocity Version 1.4, these error messages are silently discarded. In > newer Versions (1.5 beta 2 and beyond), these messages are logged out and > appear to be errors. -- 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: (WAGON-274) Copying directories (recursively) should be handled as one transfer
[ http://jira.codehaus.org/browse/WAGON-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated WAGON-274: Component/s: (was: wagon-ftp) > Copying directories (recursively) should be handled as one transfer > --- > > Key: WAGON-274 > URL: http://jira.codehaus.org/browse/WAGON-274 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-webdav >Affects Versions: 1.0-beta-2 >Reporter: Johan Vogelzang >Assignee: Mark Struberg > Fix For: 1.x > > > As well as for wagon-ftp as for wagon-webdav deployment of directory > structures is really slow. > Each file is handled as a separate transfer. Each transfer cost a lot of > ceremony for handling the protocol. > Deploying our project site with scp takes about 1 minute, while deploying > with wagon-webdav it takes 16 minutes. > Copying directory structures in one transfer should speed it up. -- 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-458) Fixing the order of items in "Modules" menu
[
http://jira.codehaus.org/browse/MSITE-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268287#action_268287
]
Lukas Theussl commented on MSITE-458:
-
I added the test project as an IT:
[r1126918|http://svn.apache.org/viewvc?rev=1126918&view=rev]
> Fixing the order of items in "Modules" menu
> ---
>
> Key: MSITE-458
> URL: http://jira.codehaus.org/browse/MSITE-458
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: New Feature
> Components: multi module
>Affects Versions: 2.1
>Reporter: Andreas Sewe
>Assignee: Lukas Theussl
> Fix For: 2.3, 3.0-beta-4
>
> Attachments: demo.tar.gz
>
>
> Currently, it is impossible to influence the order in which the "Modules"
> show up in a generated site's menu when including them like this in the site
> descriptor:
> bq.
> As far as I can tell, the order of items in the menu depends on the order in
> which Maven builds the modules -- and this does not always put the most
> important module at the top of the list. In fact, the top of the list is in
> all likelihood occupied by various low-level infrastructure modules; the
> high-level, user-visible modules typically come much later. :-(
> This also means that the order of menu items depends on the module's
> dependencies; thus, this can result in unforeseen changes to the *site* when
> one module's *build* changes. Why doesn't Maven simply use the order of the
> {{module}} elements? That would be simple and predictable.
--
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] Reopened: (WAGON-274) Copying directories (recursively) should be handled as one transfer
[ http://jira.codehaus.org/browse/WAGON-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reopened WAGON-274: - oops of course this bug is also filed against webdav. Reopen and remove wagon-ftp > Copying directories (recursively) should be handled as one transfer > --- > > Key: WAGON-274 > URL: http://jira.codehaus.org/browse/WAGON-274 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-ftp, wagon-webdav >Affects Versions: 1.0-beta-2 >Reporter: Johan Vogelzang >Assignee: Mark Struberg > Fix For: 1.x > > > As well as for wagon-ftp as for wagon-webdav deployment of directory > structures is really slow. > Each file is handled as a separate transfer. Each transfer cost a lot of > ceremony for handling the protocol. > Deploying our project site with scp takes about 1 minute, while deploying > with wagon-webdav it takes 16 minutes. > Copying directory structures in one transfer should speed it up. -- 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: (WAGON-274) Copying directories (recursively) should be handled as one transfer
[ http://jira.codehaus.org/browse/WAGON-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed WAGON-274. --- Resolution: Won't Fix Assignee: Mark Struberg I fear this is not possible! The FTP specification clearly says that a STOR command only works on a 'per file' basis: >From RFC-959 (FTP) http://www.faqs.org/rfcs/rfc959.html > STORE (STOR) > This command causes the server-DTP to accept the data > transferred via the data connection and to store the data as > a file at the server site. If the file specified in the > pathname exists at the server site, ... > Copying directories (recursively) should be handled as one transfer > --- > > Key: WAGON-274 > URL: http://jira.codehaus.org/browse/WAGON-274 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-ftp, wagon-webdav >Affects Versions: 1.0-beta-2 >Reporter: Johan Vogelzang >Assignee: Mark Struberg > Fix For: 1.x > > > As well as for wagon-ftp as for wagon-webdav deployment of directory > structures is really slow. > Each file is handled as a separate transfer. Each transfer cost a lot of > ceremony for handling the protocol. > Deploying our project site with scp takes about 1 minute, while deploying > with wagon-webdav it takes 16 minutes. > Copying directory structures in one transfer should speed it up. -- 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: (DOXIA-431) Doxia creates illegal URLs from local paths
[
http://jira.codehaus.org/browse/DOXIA-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268284#action_268284
]
Aaron Digulla commented on DOXIA-431:
-
> Doxia 1.2 is not used...
I had problems with the site plugin 3.0-beta-3, so I tried beta-4-SNAPSHOT.
> Is this a regression?
Probably. My guess is that recent code changes unveiled a whole set of errors.
> where does this image come from...
The image comes from the folder {{src/site/resources/images/}}
I'm not the maintainer of the project, so I have no idea how Doxia includes the
image. All I have is the error message and the filename. I can't see any
reference to the image in site.xml, so it must be included from somewhere else,
probably the skin.
> Is it documented somewhere that image/file references...?
A URL can contain only some characters. See
http://www.blooberry.com/indexdot/html/topics/urlencoding.htm for a pretty good
explanation.
File names on Unix can contain anything except "/" (slash) and 0-bytes.
So if you accept Unix file names anywhere in Doxia, you must escape them as
soon as they are converted to URLs and you must unescape them when they are
converted back to file names.
My suggestion is a new type which can be both and which has accessor methods to
get a OS-specific path or a RFC-compliant URL and to get rid of the type String
as soon as you can to make sure you don't have any gaps in the chain.
> Doxia creates illegal URLs from local paths
> ---
>
> Key: DOXIA-431
> URL: http://jira.codehaus.org/browse/DOXIA-431
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2
>Reporter: Aaron Digulla
>
> If a local resource contains characters which are illegal in a URL, Doxia
> creates illegal code or crashes.
--
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-5102) Mixin POM fragments
[ http://jira.codehaus.org/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maurizio Pillitu updated MNG-5102: -- Attachment: maven-tiles.zip Hi, I've some code to share - tested on Maven 3.0.2 - which composes a Maven POM from different tiles; it's a spike of 2 days work, but I think results are very interesting. The implementation consists of: - an implementation of MavenLifecycleParticipant.java (120 lines) - a components.xml The attached ZIP file contains a Maven build to produce a JAR that needs to be copied in M2_HOME/lib, a README.txt and a working sample; there are still some issues (e.g. properties inheritance), which are reported in the README, but I think that it gives the idea. I really hope this could help with this feature implementation. > Mixin POM fragments > --- > > Key: MNG-5102 > URL: http://jira.codehaus.org/browse/MNG-5102 > Project: Maven 2 & 3 > Issue Type: Wish > Components: POM >Affects Versions: 2.2.1 >Reporter: Anthony Whitford > Fix For: 3.1 > > Attachments: maven-tiles.zip > > > I am looking for a way to _mixin_ POM fragments into POMs. Note that this > idea is beyond parent pom inheritance because all projects inherit from a > corporate parent pom. The problem that I am running into is that the > corporate parent pom is turning into an _"everything but the kitchen sink"_ > POM and I'd like to dissect it into POM fragments relevant for individual > modules. > For example, I would like to have mixins for: > * Java projects (that include static code analysis plugins, javadoc, etc.) > * JPA projects (that include DDL generation) > * Flex projects (that include flexmojos, asdoc, etc.) > * Scala projects (that include the maven-scala-compiler plugin, scaladoc, > etc.) > * JavaScript projects (that include build plugins like > maven-yuicompressor-plugin with jslint and compress goals) > Hopefully, you get the idea. Without the ability to factor pom logic, we are > left with two symptoms: > # copy/paste duplication > # complex _"it does it all"_ parent poms (which slow down builds because more > plugins are loaded even though they might not do anything material) > Note that a project may include multiple mixins as I could have a project > that contains Java code, Scala code, and JavaScript. > Another idea is that the mixins could be parameterized, so that the ultimate > pom can be customized based on the parameters (like tokens). > I recall reading about Mixins coming in Maven 3.1, but could not find any > such issue to watch, so am creating one. -- 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: (DOXIASITETOOLS-60) Useless error message "error in opening zip file" in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268281#action_268281
]
Aaron Digulla commented on DOXIASITETOOLS-60:
-
The JAR file seems OK so the problem must be that Maven is pulling something in
that I don't expect/see.
How can I get this version of Doxia to test?
> Useless error message "error in opening zip file" in
> DefaultSiteRenderer.createContextForSkin()
> ---
>
> Key: DOXIASITETOOLS-60
> URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-60
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Affects Versions: 1.2
>Reporter: Aaron Digulla
>Assignee: Lukas Theussl
> Fix For: 1.3
>
>
> When I run {{mvn site}} on my project, I get an exception in
> DefaultSiteRenderer.createContextForSkin(): "error in opening zip file"
> Which zip file?
--
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-458) Fixing the order of items in "Modules" menu
[
http://jira.codehaus.org/browse/MSITE-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268278#action_268278
]
Lukas Theussl commented on MSITE-458:
-
Herve: checking the attached test project with published site-plugin-2.3, the
reactor build order is still second-first, but the order in the Modules menu of
the generated site is first-second. So I consider this issue fixed.
> Fixing the order of items in "Modules" menu
> ---
>
> Key: MSITE-458
> URL: http://jira.codehaus.org/browse/MSITE-458
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: New Feature
> Components: multi module
>Affects Versions: 2.1
>Reporter: Andreas Sewe
>Assignee: Lukas Theussl
> Fix For: 2.3, 3.0-beta-4
>
> Attachments: demo.tar.gz
>
>
> Currently, it is impossible to influence the order in which the "Modules"
> show up in a generated site's menu when including them like this in the site
> descriptor:
> bq.
> As far as I can tell, the order of items in the menu depends on the order in
> which Maven builds the modules -- and this does not always put the most
> important module at the top of the list. In fact, the top of the list is in
> all likelihood occupied by various low-level infrastructure modules; the
> high-level, user-visible modules typically come much later. :-(
> This also means that the order of menu items depends on the module's
> dependencies; thus, this can result in unforeseen changes to the *site* when
> one module's *build* changes. Why doesn't Maven simply use the order of the
> {{module}} elements? That would be simple and predictable.
--
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-458) Fixing the order of items in "Modules" menu
[
http://jira.codehaus.org/browse/MSITE-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268277#action_268277
]
Andreas Sewe commented on MSITE-458:
What for? Wasn't it fixed in the current 3.0-beta-4-SNAPSHOT?
> Fixing the order of items in "Modules" menu
> ---
>
> Key: MSITE-458
> URL: http://jira.codehaus.org/browse/MSITE-458
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: New Feature
> Components: multi module
>Affects Versions: 2.1
>Reporter: Andreas Sewe
>Assignee: Lukas Theussl
> Fix For: 2.3, 3.0-beta-4
>
> Attachments: demo.tar.gz
>
>
> Currently, it is impossible to influence the order in which the "Modules"
> show up in a generated site's menu when including them like this in the site
> descriptor:
> bq.
> As far as I can tell, the order of items in the menu depends on the order in
> which Maven builds the modules -- and this does not always put the most
> important module at the top of the list. In fact, the top of the list is in
> all likelihood occupied by various low-level infrastructure modules; the
> high-level, user-visible modules typically come much later. :-(
> This also means that the order of menu items depends on the module's
> dependencies; thus, this can result in unforeseen changes to the *site* when
> one module's *build* changes. Why doesn't Maven simply use the order of the
> {{module}} elements? That would be simple and predictable.
--
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
