[jira] (MPLUGIN-211) @Mojo annotations aren't inherited
Joseph Walton created MPLUGIN-211: - Summary: @Mojo annotations aren't inherited Key: MPLUGIN-211 URL: https://jira.codehaus.org/browse/MPLUGIN-211 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: maven-plugin-tools-annotations Affects Versions: 3.0 Reporter: Joseph Walton Priority: Trivial We have a project where a mojo defined in one plugin module is inherited from in another. With Javadoc-style markup, the child class is also declared as an mojo. With @Mojo, the child class needs to re-declare @Mojo in order to be included in the plugin definition. I'm reporting this as 'trivial' priority. I've fixed it by copying those @Mojo annotations across. I wouldn't have a problem with WONTFIXing this. I think the new behaviour is clearer, and I'm not convinced that the previous behaviour was intentional or desirable. However, it is still a change. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-470) Conflence: support [jira-ticket@jira] construct
Valters Vingolds created DOXIA-470:
--
Summary: Conflence: support [jira-ticket@jira] construct
Key: DOXIA-470
URL: https://jira.codehaus.org/browse/DOXIA-470
Project: Maven Doxia
Issue Type: New Feature
Reporter: Valters Vingolds
Priority: Minor
In Confluence Wiki, it is possible to link to Jira tickets with format
{{[DOXIA-293@jira]}}, because the Wiki also knows the Jira server location.
It's very useful. I'd like to see support in Doxia for this too.
The @jira signals to parser to get the location of JIRA server (configured
somewhere, http://(jira...)/browse/) and append the ticket identifier. The
information needs to come from maven-site-plugin.
I feel this would be similar story to support javadoc location macro
DOXIA-293.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valters Vingolds updated DOXIA-467:
---
Attachment: confluence-escaping-patch-files.zip
confluence-escaping-hg.patch
I am attaching updated version of patch (mercurial format, I imported source to
private hg repo to produce acceptable patch, and not lose track of other
changes I am experimenting with).
Also attaching the changed files, incase it is simply easier for you to use
some DiffMerge visual tool.
This patch also handles following markup correctly:
{code}
{{monospaced $\{with.escaped.variable\}}}
{code}
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINDEXER-44) NPE from DefaultSearchEngine.doSearchWithCeiling
[
https://jira.codehaus.org/browse/MINDEXER-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300289#comment-300289
]
Milos Kleint commented on MINDEXER-44:
--
a similar issue occurred in http://netbeans.org/bugzilla/show_bug.cgi?id=213466
The initial problem in this case seems to be this stacktrace:
java.lang.NullPointerException
at org.apache.lucene.store.Directory.copy(Directory.java:200)
at
org.apache.maven.index.context.IndexUtils.copyDirectory(IndexUtils.java:51)
at
org.apache.maven.index.context.DefaultIndexingContext.replace(DefaultIndexingContext.java:832)
at
org.apache.maven.index.updater.DefaultIndexUpdater.loadIndexDirectory(DefaultIndexUpdater.java:218)
at
org.apache.maven.index.updater.DefaultIndexUpdater.access$300(DefaultIndexUpdater.java:76)
at
org.apache.maven.index.updater.DefaultIndexUpdater$LuceneIndexAdaptor.setIndexFile(DefaultIndexUpdater.java:642)
at
org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:879)
at
org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:157)
at
org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl.indexLoadedRepo(NexusRepositoryIndexerImpl.java:498)
at
org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl.loadIndexingContext(NexusRepositoryIndexerImpl.java:288)
at
org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl.access$300(NexusRepositoryIndexerImpl.java:139)
at
org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl$2.run(NexusRepositoryIndexerImpl.java:540)
at
org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl$2.run(NexusRepositoryIndexerImpl.java:531)
at org.openide.util.Mutex.writeAccess(Mutex.java:397)
at
org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl.indexRepo(NexusRepositoryIndexerImpl.java:531)
at
org.netbeans.modules.maven.indexer.api.RepositoryIndexer.indexRepo(RepositoryIndexer.java:62)
at
org.netbeans.modules.maven.ProjectOpenedHookImpl$1.run(ProjectOpenedHookImpl.java:202)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1411)
[catch] at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1991)
NPE from DefaultSearchEngine.doSearchWithCeiling
Key: MINDEXER-44
URL: https://jira.codehaus.org/browse/MINDEXER-44
Project: Maven Indexer
Issue Type: Bug
Affects Versions: 4.1.1
Reporter: Jesse Glick
Assignee: Olivier Lamy
Priority: Minor
Fix For: 4.1.3
http://netbeans.org/bugzilla/show_bug.cgi?id=202138 reports
http://statistics.netbeans.org/exceptions/messageslog?id=533660 which shows
{code}
java.lang.NullPointerException
at
org.apache.maven.index.DefaultSearchEngine.doSearchWithCeiling(DefaultSearchEngine.java:316)
at
org.apache.maven.index.DefaultSearchEngine.searchFlat(DefaultSearchEngine.java:169)
at
org.apache.maven.index.DefaultSearchEngine.searchFlatPaged(DefaultSearchEngine.java:102)
at
org.apache.maven.index.DefaultSearchEngine.searchFlatPaged(DefaultSearchEngine.java:77)
{code}
This comes after some index download problems like
{code}
java.io.FileNotFoundException: Resource nexus-maven-repository-index.gz does
not exist
at
org.apache.maven.index.updater.WagonHelper$WagonFetcher.retrieve(WagonHelper.java:196)
at
org.apache.maven.index.updater.WagonHelper$WagonFetcher.retrieve(WagonHelper.java:166)
at
org.apache.maven.index.updater.DefaultIndexUpdater.loadIndexDirectory(DefaultIndexUpdater.java:191)
at
org.apache.maven.index.updater.DefaultIndexUpdater.access$300(DefaultIndexUpdater.java:76)
at
org.apache.maven.index.updater.DefaultIndexUpdater$LuceneIndexAdaptor.setIndexFile(DefaultIndexUpdater.java:642)
at
org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:861)
at
org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:157)
{code}
It seems that the {{DefaultIndexingContext.indexSearcher}} is null, for
whatever reason, and {{searchFlatPaged}} is not verifying that it has been
passed a valid context and does not attempt to fix an invalid context,
perhaps using {{openAndWarmupReaders}}.
Probably the caller is at fault for attempting a search on a context with no
valid index, but this ought to be reported more clearly than with an NPE
several calls down the stack, and there should be some documented method for
checking that a context is somehow complete and ready for use.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
[jira] (SCM-676) Add property revision to CheckOutScmResult
Petr Kozelka created SCM-676: Summary: Add property revision to CheckOutScmResult Key: SCM-676 URL: https://jira.codehaus.org/browse/SCM-676 Project: Maven SCM Issue Type: Improvement Components: maven-scm-api, maven-scm-provider-svn Reporter: Petr Kozelka Attachments: SCM-CheckOutScmResultWithRevision.patch It is often useful to get revision number when checking out current state. Attached patch adds this property, and implementation for SVN. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-553) Assembly plugin ignores attached assemblies
[
https://jira.codehaus.org/browse/MASSEMBLY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300290#comment-300290
]
Damjan Jovanovic commented on MASSEMBLY-553:
Still an issue in version 2.3 with all the Apache Commons projects I've tested
(configuration, imaging, net).
Assembly plugin ignores attached assemblies
---
Key: MASSEMBLY-553
URL: https://jira.codehaus.org/browse/MASSEMBLY-553
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2, 2.2.1
Reporter: SebbASF
Assignee: John Casey
Priority: Critical
Attachments: assembly-bug.zip
This used to work in 2.2-beta-5, but both 2.2 and 2.2.1 seem to ignore
attached descriptors in mvn install
Sample project to follow.
This works:
mvn -Dass.vers=2.2-beta-5 install -Prc
This does not:
mvn -Dass.vers=2.2.1 install -Prc
If you compare the ouput from the two runs, you will see that the following
is missing from 2.2.1:
[INFO] [assembly:attached {execution: default}]
[INFO] Reading assembly descriptor: src/assembly/bin.xml
[INFO] Reading assembly descriptor: src/assembly/src.xml
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-bin.zip
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-src.zip
Apache Commons cannot use 2.2 or 2.2.1 as a result of this bug
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-356) maven dependency plugin should use maven 3 dependency resolver, aether
Anthony Dahanne created MDEP-356:
Summary: maven dependency plugin should use maven 3 dependency
resolver, aether
Key: MDEP-356
URL: https://jira.codehaus.org/browse/MDEP-356
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: purge-local-repository
Affects Versions: 2.4, 2.5
Environment: mac os x or linux, maven 3.0.4 (maven 3.0.3 does not have
the same behaviour, it fails at removing the local artifacts)
Reporter: Anthony Dahanne
Attachments: pom.xml
problem initially described on the maven users mailing list :
http://mail-archives.apache.org/mod_mbox/maven-users/201206.mbox/browser
Given the attached pom, and using maven 3.0.4 (important, it does not work
with 3.0.3, it fails at removing the local artifacts)
# do a mvn clean install
# then do a mvn
org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
-Dverbose=true -DresolutionFuzziness=version
it will work as designed, removing javax.servlet:servlet-api:jar:2.5 and
net.dahanne.gallery:commons-gallery:jar:2.1.0-SNAPSHOT from your local repo,
before re downloading them.
but, the following message is displayed :
{noformat}
[WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
[WARNING] Missing POM for net.dahanne.gallery:commons-gallery:jar:2.1.0-SNAPSHOT
{noformat}
It actually means the plugin could not see those artifacts in my local repo;
it may be related to the fact that dependency plugin does not use aether to
resolve the tree.
Other problems should arise, as mentioned by Stephen Connolly on the mailing
list :
When I last chatted on this with Benjamin, he left me with the distinct
impression that I should not rely on the output of dependency:tree when run on
m3 until it has been adapted to query aether's graph more directly
The dependency plugin should use the same dependency resolver as maven 3, ie
aether.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-356) maven dependency plugin should use maven 3 dependency resolver, aether
[
https://jira.codehaus.org/browse/MDEP-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300306#comment-300306
]
Anthony Dahanne commented on MDEP-356:
--
Not sure if this issue is still relevant since those warnings arose because I
launched the purge twice in a row, and it affected my local repo :
$ ls ~/.m2/repository/javax/servlet/servlet-api/2.5/
_maven.repositories servlet-api-2.5.jar
servlet-api-2.5.jar.lastUpdated servlet-api-2.5.jar.sha1
re launching mvn clean install afterwards fixes the repo.
maven dependency plugin should use maven 3 dependency resolver, aether
--
Key: MDEP-356
URL: https://jira.codehaus.org/browse/MDEP-356
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: purge-local-repository
Affects Versions: 2.4, 2.5
Environment: mac os x or linux, maven 3.0.4 (maven 3.0.3 does not
have the same behaviour, it fails at removing the local artifacts)
Reporter: Anthony Dahanne
Attachments: pom.xml
problem initially described on the maven users mailing list :
http://mail-archives.apache.org/mod_mbox/maven-users/201206.mbox/browser
Given the attached pom, and using maven 3.0.4 (important, it does not work
with 3.0.3, it fails at removing the local artifacts)
# do a mvn clean install
# then do a mvn
org.apache.maven.plugins:maven-dependency-plugin:2.4:purge-local-repository
-Dverbose=true -DresolutionFuzziness=version
it will work as designed, removing javax.servlet:servlet-api:jar:2.5 and
net.dahanne.gallery:commons-gallery:jar:2.1.0-SNAPSHOT from your local repo,
before re downloading them.
but, the following message is displayed :
{noformat}
[WARNING] Missing POM for javax.servlet:servlet-api:jar:2.5
[WARNING] Missing POM for
net.dahanne.gallery:commons-gallery:jar:2.1.0-SNAPSHOT
{noformat}
It actually means the plugin could not see those artifacts in my local
repo; it may be related to the fact that dependency plugin does not use
aether to resolve the tree.
Other problems should arise, as mentioned by Stephen Connolly on the mailing
list :
When I last chatted on this with Benjamin, he left me with the distinct
impression that I should not rely on the output of dependency:tree when run
on m3 until it has been adapted to query aether's graph more directly
The dependency plugin should use the same dependency resolver as maven 3, ie
aether.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds commented on DOXIA-467:
Ok, with llowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block.
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds edited comment on DOXIA-467 at 6/4/12 10:56 AM:
-
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block.
was (Author: valters):
Ok, with llowing to escape { via \, now there is issue with markup like
this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block.
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds edited comment on DOXIA-467 at 6/4/12 11:00 AM:
-
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
was (Author: valters):
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block.
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGINTESTING-25) cookbook example doesn't work
Benjamin Reed created MPLUGINTESTING-25: --- Summary: cookbook example doesn't work Key: MPLUGINTESTING-25 URL: https://jira.codehaus.org/browse/MPLUGINTESTING-25 Project: Maven 2.x Plugin Testing Issue Type: Bug Affects Versions: 2.0 Reporter: Benjamin Reed I have run into issues even getting a simple unit test working with my maven plugin skeleton. I posted about it here: http://mail-archives.apache.org/mod_mbox/maven-users/201206.mbox/%3C4FCCC631.6050607%40opennms.org%3E ...in the process of being unable to debug this failure, I figured I'd try walking through the cookbook without using any of my own code. Following the cookbook example fails, with this exception: java.lang.NoClassDefFoundError: org/apache/maven/plugin/descriptor/PluginDescriptorBuilder at org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:116) at org.apache.maven.plugin.my.MyMojoTest.setUp(MyMojoTest.java:15) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: java.lang.ClassNotFoundException: org.apache.maven.plugin.descriptor.PluginDescriptorBuilder at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ... 15 more The documentation says to use the archetype for creating a maven plugin, but by default it uses maven-plugin-api 2.0, which is incompatible with the latest plugin. Changing it to maven-plugin-api 3.0 in pom.xml then results in the following exception: java.lang.NoClassDefFoundError: org/codehaus/plexus/ContainerConfiguration at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethods(Class.java:1791) at junit.framework.TestSuite.init(TestSuite.java:73) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader.getTest(JUnit3TestLoader.java:102) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader.loadTests(JUnit3TestLoader.java:59) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: java.lang.ClassNotFoundException: org.codehaus.plexus.ContainerConfiguration at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ... 10 more I've not been able to figure out how to actually unit-test the cookbook example, much less my own plugin. :P -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-482) Wrong URL for commiting to SVN
[
https://jira.codehaus.org/browse/MRELEASE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-482.
---
Resolution: Incomplete
Assignee: Robert Scholte
No feedback from user, closing it.
Wrong URL for commiting to SVN
--
Key: MRELEASE-482
URL: https://jira.codehaus.org/browse/MRELEASE-482
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: branch
Affects Versions: 2.0-beta-8, 2.0-beta-9
Environment: All
Reporter: Markus Heimhuber
Assignee: Robert Scholte
Priority: Critical
Command:
---
{noformat}
set PROJECT_NAME=fytools
set RELEASE_VERSION=1.1
set NEXT_VERSION=1.2
set URL=http://svn.office.factority.de/factority
set URL_BRANCHES=%URL%/BRANCHES
set DRY=false
mvn -U --batch-mode release:branch -Dusername=%USERNAME%
-Dpassword=%PASSWORD% \
-DtagBase=%URL_BRANCHES% -DautoVersionSubmodules=true
-DupdateBranchVersions=true \
-DupdateWorkingCopyVersions=false
-DbranchName=%PROJECT_NAME%-%RELEASE_VERSION%.1-SNAPSHOT \
-DdevelopmentVersion=%RELEASE_VERSION%.1-SNAPSHOT -DdryRun=%DRY%
{noformat}
Symptom:
---
The resulting POM contains the expected SVM link:
{noformat}
http://svn.office.factority.de/factority/BRANCHES/fytools-1.1.1-SNAPSHOT
{noformat}
The execution log contains the following:
{noformat}
[INFO] Executing: cmd.exe /X /C svn --username msheimhu --password *
--non-interactive copy
--file C:\Users\X\AppData\Local\Temp\maven-scm-439769046.commit .
http://svn.office.factority.de/factority/fytools/branches/fytools-1.1.1-SNAPSHOT;
{noformat}
The execution log indicates, that Maven tries to commit to the following link:
{noformat}
http://svn.office.factority.de/factority/fytools/branches/fytools-1.1.1-SNAPSHOT
{noformat}
This fails with the following error message:
{noformat}
[INFO] Working directory: C:\Users\msheimhu\workspace\fytools
org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable to
branch SCM
Provider message:
The svn branch command failed.
Command output:
svn: Commit failed (details follow):
svn: '/factority/fytools/branches' path not found
{noformat}
Expected behaviour:
---
The commit should use the URL from the POM, which is the correct one:
{noformat}
http://svn.office.factority.de/factority/BRANCHES/fytools-1.1.1-SNAPSHOT
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGINTESTING-25) cookbook example doesn't work
[
https://jira.codehaus.org/browse/MPLUGINTESTING-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300325#comment-300325
]
Benjamin Reed commented on MPLUGINTESTING-25:
-
OK, I just added the latest version of plexus-container-default as a dependency:
dependency
groupIdorg.codehaus.plexus/groupId
artifactIdplexus-container-default/artifactId
version1.5.5/version
/dependency
...and now I get this:
{code}org.codehaus.plexus.component.repository.exception.ComponentLookupException:
Component descriptor cannot be found in the component repository
role: org.apache.maven.plugin.Mojo
roleHint: org.apache.maven.plugin.my:maven-my-plugin:1.0-SNAPSHOT:touch
classRealm: none specified
at
org.codehaus.plexus.DefaultComponentRegistry.getComponentManager(DefaultComponentRegistry.java:435)
at
org.codehaus.plexus.DefaultComponentRegistry.getComponent(DefaultComponentRegistry.java:353)
at
org.codehaus.plexus.DefaultComponentRegistry.lookup(DefaultComponentRegistry.java:178)
at
org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:378)
at org.codehaus.plexus.PlexusTestCase.lookup(PlexusTestCase.java:202)
at
org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractMojoTestCase.java:291)
at
org.apache.maven.plugin.testing.AbstractMojoTestCase.lookupMojo(AbstractMojoTestCase.java:236)
at
org.apache.maven.plugin.my.MyMojoTest.testSomething(MyMojoTest.java:36)
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:597)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197){code}
cookbook example doesn't work
-
Key: MPLUGINTESTING-25
URL: https://jira.codehaus.org/browse/MPLUGINTESTING-25
Project: Maven 2.x Plugin Testing
Issue Type: Bug
Affects Versions: 2.0
Reporter: Benjamin Reed
I have run into issues even getting a simple unit test working with my maven
plugin skeleton. I posted about it here:
http://mail-archives.apache.org/mod_mbox/maven-users/201206.mbox/%3C4FCCC631.6050607%40opennms.org%3E
...in the process of being unable to debug this failure, I figured I'd try
walking through the cookbook without using any of my own code.
Following the cookbook example fails, with this exception:
java.lang.NoClassDefFoundError:
org/apache/maven/plugin/descriptor/PluginDescriptorBuilder
at
org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:116)
at org.apache.maven.plugin.my.MyMojoTest.setUp(MyMojoTest.java:15)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at
[jira] (MPLUGINTESTING-25) cookbook example doesn't work
[ https://jira.codehaus.org/browse/MPLUGINTESTING-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300326#comment-300326 ] Benjamin Reed commented on MPLUGINTESTING-25: - Aha! I did mvn install and *now* it runs. So I guess there's no way to test the actual code *before* installing it? The plugin test harness doesn't inject the current code into some kind of temporary internal repository to make it available to the tests? Kind of defeats the purpose... cookbook example doesn't work - Key: MPLUGINTESTING-25 URL: https://jira.codehaus.org/browse/MPLUGINTESTING-25 Project: Maven 2.x Plugin Testing Issue Type: Bug Affects Versions: 2.0 Reporter: Benjamin Reed I have run into issues even getting a simple unit test working with my maven plugin skeleton. I posted about it here: http://mail-archives.apache.org/mod_mbox/maven-users/201206.mbox/%3C4FCCC631.6050607%40opennms.org%3E ...in the process of being unable to debug this failure, I figured I'd try walking through the cookbook without using any of my own code. Following the cookbook example fails, with this exception: java.lang.NoClassDefFoundError: org/apache/maven/plugin/descriptor/PluginDescriptorBuilder at org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:116) at org.apache.maven.plugin.my.MyMojoTest.setUp(MyMojoTest.java:15) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: java.lang.ClassNotFoundException: org.apache.maven.plugin.descriptor.PluginDescriptorBuilder at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ... 15 more The documentation says to use the archetype for creating a maven plugin, but by default it uses maven-plugin-api 2.0, which is incompatible with the latest plugin. Changing it to maven-plugin-api 3.0 in pom.xml then results in the following exception: java.lang.NoClassDefFoundError: org/codehaus/plexus/ContainerConfiguration at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getDeclaredMethods(Class.java:1791) at junit.framework.TestSuite.init(TestSuite.java:73) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader.getTest(JUnit3TestLoader.java:102) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader.loadTests(JUnit3TestLoader.java:59) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: java.lang.ClassNotFoundException: org.codehaus.plexus.ContainerConfiguration at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ... 10 more I've not been able to figure out how to actually unit-test the cookbook example, much less my own plugin. :P
[jira] (MRELEASE-309) Perform goal fails if -f option is used to define non-default path to pom file
[ https://jira.codehaus.org/browse/MRELEASE-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-309. --- Resolution: Duplicate Assignee: Robert Scholte Superseded by MRELEASE-757 Perform goal fails if -f option is used to define non-default path to pom file --- Key: MRELEASE-309 URL: https://jira.codehaus.org/browse/MRELEASE-309 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.0-beta-7 Reporter: Brian Jackson Assignee: Robert Scholte Attachments: pomFileName.patch, pomFileNameWithTestCase.patch The RunPerformGoalsPhase hardcodes the pom name as pom.xml instead of using releaseDescriptor.getPomFileName(). This causes the perform goal to fail if the filename is different or the plugin is run from a different directory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-625) mvn release:perform Problem
[
https://jira.codehaus.org/browse/MRELEASE-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MRELEASE-625.
---
Resolution: Not A Bug
Assignee: Robert Scholte
It looks to me your SCM connection was misconfigured. The project was tagged
one level too high, since I see {{source}} and {{portal-all}}. When checking
out by tag it is missing the pom, so the release-plugin can't run Maven.
mvn release:perform Problem
---
Key: MRELEASE-625
URL: https://jira.codehaus.org/browse/MRELEASE-625
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.1
Environment: Linux Ubuntu 10.4
java version 1.6.0_21
Maven 2.2.1
Reporter: Vinicius de Paula
Assignee: Robert Scholte
Attachments: maven.log
Hi folks,
I have a problem when i'm trying to run the Maven task: mvn -X release:perform
My pom.xml plugin definition:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.1/version
configuration
remoteTaggingtrue/remoteTagging
arguments-Dmaven.test.skip/arguments
tagBasehttps://svn/repo/portal/tags//tagBase
/configuration
/plugin
{code}
Debug stacktrace:
Checkout from an SCM URL was done successfully.
In deploy goal the error ocurr. If i execute only mvn deploy, its done
successfully.
{noformat}
[WARNING] Maven will be executed in interactive mode, but no input stream has
been configured for this MavenInvoker instance.
[INFO] + Error stacktraces are turned on.
[INFO] Apache Maven 2.2.1 (rdebian-1)
[INFO] Java version: 1.6.0_21
[INFO] Java home: /opt/java/jdk1.6.0_21/jre
[INFO] Default locale: en_US, platform encoding: UTF-8
[INFO] OS name: linux version: 2.6.32-26-generic arch: i386 Family:
unix
[INFO] [DEBUG] Building Maven user-level plugin registry from:
'/home/vinidog/.m2/plugin-registry.xml'
[INFO] [DEBUG] Building Maven global-level plugin registry from:
'/usr/share/maven2/conf/plugin-registry.xml'
[INFO] [INFO] Scanning for projects...
[INFO] [DEBUG] Wagons could not be registered as the extension container was
never created
[INFO] [INFO]
[INFO] [INFO] Building Maven Default Project
[INFO] [INFO]task-segment: [deploy]
[INFO] [INFO]
[INFO] [DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins:pom:12 for project:
null:maven-resources-plugin:maven-plugin:2.3 from the repository.
[INFO] [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:9 for
project: org.apache.maven.plugins:maven-plugins:pom:12 from the repository.
[INFO] [DEBUG] Retrieving parent-POM: org.apache:apache:pom:4 for project:
org.apache.maven:maven-parent:pom:9 from the repository.
[INFO] [DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins:pom:8 for project:
null:maven-compiler-plugin:maven-plugin:2.0.2 from the repository.
[INFO] [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:5 for
project: org.apache.maven.plugins:maven-plugins:pom:8 from the repository.
[INFO] [DEBUG] Retrieving parent-POM: org.apache:apache:pom:3 for project:
org.apache.maven:maven-parent:pom:5 from the repository.
[INFO] [DEBUG] Retrieving parent-POM:
org.apache.maven.surefire:surefire:pom:2.4.3 for project:
org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:null from the
repository.
[INFO] [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:7 for
project: org.apache.maven.surefire:surefire:pom:2.4.3 from the repository.
[INFO] [DEBUG] Adding managed dependencies for
org.apache.maven.plugins:maven-surefire-plugin
[INFO] [DEBUG] org.apache.maven.surefire:surefire-api:jar:2.4.3
[INFO] [DEBUG] org.apache.maven.surefire:surefire-booter:jar:2.4.3
[INFO] [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.1
[INFO] [DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins:pom:10 for project:
null:maven-jar-plugin:maven-plugin:2.2 from the repository.
[INFO] [DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins:pom:13 for project:
null:maven-install-plugin:maven-plugin:2.3 from the repository.
[INFO] [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:11
for project: org.apache.maven.plugins:maven-plugins:pom:13 from the
repository.
[INFO] [DEBUG] Retrieving parent-POM: org.apache:apache:pom:5 for project:
org.apache.maven:maven-parent:pom:11 from the repository.
[INFO] [DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins:pom:11 for project:
null:maven-deploy-plugin:maven-plugin:2.4 from the repository.
[INFO] [DEBUG] Retrieving parent-POM:
[jira] (MRELEASE-643) it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2
[ https://jira.codehaus.org/browse/MRELEASE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-643. --- Resolution: Incomplete Assignee: Robert Scholte No feedback from user, closing it. it wont use maven-site-plugin 3.0-beta-3 when used with Maven 3.0.2 Key: MRELEASE-643 URL: https://jira.codehaus.org/browse/MRELEASE-643 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.1 Environment: Win 7 64-bit Maven 3.0.2 Reporter: shane mills Assignee: Robert Scholte We use Maven as project management tool. For building releases we use maven-release-plugin. Up until a few days ago we used Maven 2.2.1 but unfortunately we recognized that for some reason when triggering mvn release:prepare on a project with local modifications it would just prepare the release without saying anything about it. We actually just recognized this issue a few days ago so I started to track down the problem with no result but the fact that with maven 3 it terminates just as expected. So instead of tracking down the maven 2.2.1 issue i started to check on maven 3 and if we could use it instead of maven 2.2.1. Actually everything works just fine except of the site-plugin. I found out that with maven 3.x you should use the site-plugin 3.x and so i tried to bend dependencies so that the release-plugin uses the site-plugin 3.0-beta-3 instead of site-plugin 2.0.1, but it just wont do so. When triggering mvn site:site on the command line it works just fine, but when triggering mvn release:prepare and afterwards mvn release:perform it still uses the site-plugin 2.0.1 not as expected maven-site-plugin 3.0-beta-3. I am using maven 3.0.2 with maven-release-plugin 2.0.1 We are looking forward to switching to maven 3.x but at first we need to be sure everything works at least as fine as with maven 2.2.1 :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-456) Resolving version during release:prepare of main
[ https://jira.codehaus.org/browse/MRELEASE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-456. --- Resolution: Incomplete Assignee: Robert Scholte No feedback from user, closing it. Resolving version during release:prepare of main Key: MRELEASE-456 URL: https://jira.codehaus.org/browse/MRELEASE-456 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform, prepare Affects Versions: 2.0-beta-8 Environment: Windows Vista(main release), Unix(other projects' build), Nexus Repository Manager,Maven2.1.0, Maven-release-plugin2.0-beta-8 Reporter: Puneet Sahani Assignee: Robert Scholte Attachments: error.txt Hi, we have a main project(of type pom) containing DependencyMgmt section which lists all the projects and a version property pointing to SNAPSHOT by default and changed to a version range with the activation of a profile. All other projects have a concrete versioned 'main' as there parent. But from my local PC(Windows Vista), if i run release:prepare of the main project, while deploying the pom to Nexus, it resolves the tag to the SNAPSHOT dependency. Hence build during the patch/release is failing during dependency resolution as it tries to resolve SNAPSHOT dependency instead of resolving via the Version-Range. I switched back to Maven2.0.9 and it works fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-200) Artifacts are uploaded to wrong directory
[ https://jira.codehaus.org/browse/MRELEASE-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300331#comment-300331 ] Robert Scholte commented on MRELEASE-200: - I agree with Emmanuel, I don't think it's a maven-release-plugin issue, but it's more likely a [wagon|http://maven.apache.org/wagon]-issue, which is responsible for the movements of files. Without logs it's hard too see which causes this problem. Artifacts are uploaded to wrong directory - Key: MRELEASE-200 URL: https://jira.codehaus.org/browse/MRELEASE-200 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Environment: The maven repository is running Red Hat Linux Enterprise Server. The clients are PCs running Windows XP. Reporter: Chris Baumgartner Priority: Minor When doing a release:perform, the artifacts are occassionally uploaded to the wrong directory. We are using scp from the upload. Instead of uploading to the path of /maven-repository, the files are being uploaded to ~/om/maven-repository. For some reason it is creating a subdirectory called om in the user's home directory and uploading the artifacts there. It doesn't happen all the time, but it does seem to be consitently putting them there when it does fail. I can work around this by manually moving the files, but it is very annoying. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-298) -DupdateDependencies flag is not honored in non-interactive mode
[
https://jira.codehaus.org/browse/MRELEASE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-298:
Description:
Doing {{mvn release:prepare}} In non-interactive mode always fails if my
release depends on SNAPSHOTS. I would like it to automatically resolveSnapshots
as although I said yes, However setting {{-DupdateDependencies}} doesn't
help.
{noformat}
org.apache.maven.BuildFailureException: Can't release project due to non
released dependencies :
com.BLAH.test:test-dummy1:jar:1.0.0-SNAPSHOT:compile
in project '' (com.BLAH.test:test-dummy2:jar:1.0.0-SNAPSHOT)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
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:597)
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.MojoFailureException: Can't release project
due to non released dependencies :
com.BLAH.test:test-dummy1:jar:1.0.0-SNAPSHOT:compile
in project '' (com.ml.elt.era.test:test-dummy2:jar:1.0.0-SNAPSHOT)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:144)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
... 16 more
{noformat}
was:
Doing mvn release:prepare In non-interactive mode always fails if my release
depends on SNAPSHOTS. I would like it to automatically resolveSnapshots as
although I said yes, However settig -DupdateDependencies doesn't help
org.apache.maven.BuildFailureException: Can't release project due to non
released dependencies :
com.BLAH.test:test-dummy1:jar:1.0.0-SNAPSHOT:compile
in project '' (com.BLAH.test:test-dummy2:jar:1.0.0-SNAPSHOT)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
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:597)
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.MojoFailureException: Can't release project
due to non released dependencies :
com.BLAH.test:test-dummy1:jar:1.0.0-SNAPSHOT:compile
in project ''
[jira] (MPMD-151) Use canonical paths for the file list / Unit test failures on builds.apache.org
[
https://jira.codehaus.org/browse/MPMD-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300334#comment-300334
]
Andreas Dangel commented on MPMD-151:
-
I verified the code of PMD and we use indeed the canonical paths of the files.
I was also able to verify this issue manually by adding the following
constructor to PmdReportTest
(sorry, couldn't find an easier way to reproduce this :)):
{noformat}
public PmdReportTest() throws Exception {
Field field = PlexusTestCase.class.getDeclaredField( basedirPath );
field.setAccessible( true );
field.set( null, /M_TEST/maven-pmd-plugin );
}
{noformat}
whereby M_TEST is a symlink to my home directory (/home/andreas). Now run it,
e.g. mvn test.
The attached patch solves this problem.
Use canonical paths for the file list / Unit test failures on
builds.apache.org
---
Key: MPMD-151
URL: https://jira.codehaus.org/browse/MPMD-151
Project: Maven 2.x PMD Plugin
Issue Type: Improvement
Components: PMD
Affects Versions: 2.8
Reporter: Andreas Dangel
Attachments: canonical-files.patch
On the CI server, some unit tests are failing for maven-pmd-plugin
(https://builds.apache.org/job/maven-plugins/).
It seems that the tests run fine on the slave ubuntu2 but not on ubuntu3.
ubuntu2 workspace path:
/home/hudson/hudson-slave/workspace/maven-plugins
ubuntu3 workspace path:
/home/jenkins/jenkins-slave/workspace/maven-plugins
However, PMD found violations in the following file:
/x1/jenkins/jenkins-slave/workspace/maven-plugins/maven-pmd-plugin/src/test/resources/unit/default-configuration/def/configuration/App.java
This could indicate the /x1 is actually a sym-link to /home. Maven-pmd-plugin
sees /home/... and PMD sees /x1/ PMD reports violations against /x1 but
the maven-pmd-plugin doesn't know about this (it requested to process files
under /home) - so the internal PmdFileInfo object couldn't not be determined.
Assuming the above is correct, then the attached patch *could* solve this
problem. It determines the canonical paths of the files to be processed,
hoping that the filenames are unique then. However, I could not reproduce
this problem locally (I started maven from commandline instead letting
Jenkins start it, maybe that's the difference?).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds edited comment on DOXIA-467 at 6/4/12 1:50 PM:
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the prevous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the greedy (but Confluence
does not match them greedy)
was (Author: valters):
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds edited comment on DOXIA-467 at 6/4/12 1:51 PM:
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the prevous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the {{monospace}}} greedy (but
Confluence Wiki does not match them greedy)
was (Author: valters):
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the prevous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the greedy (but Confluence
does not match them greedy)
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds edited comment on DOXIA-467 at 6/4/12 1:51 PM:
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the prevous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the
{code}
{{monospace}}}
{code}
greedy (but Confluence Wiki does not match them greedy: {{monospace}}}
was (Author: valters):
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the prevous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the {{monospace}}} greedy (but
Confluence Wiki does not match them greedy)
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds edited comment on DOXIA-467 at 6/4/12 1:52 PM:
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the previous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the
{code}
{{monospace}}}
{code}
greedy (but Confluence Wiki does not match them greedy: {{monospace}}}
was (Author: valters):
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the prevous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the
{code}
{{monospace}}}
{code}
greedy (but Confluence Wiki does not match them greedy: {{monospace}}}
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-553) Assembly plugin ignores attached assemblies
[
https://jira.codehaus.org/browse/MASSEMBLY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300338#comment-300338
]
Dennis Lundberg commented on MASSEMBLY-553:
---
I've had another look at this issue and the behavior you see is actually the
expected, and documented, one. Compare the docs for the single goal between
2.2-beta-5 and 2.2
http://maven.apache.org/plugins/maven-assembly-plugin-2.2-beta-5/single-mojo.html
http://maven.apache.org/plugins/maven-assembly-plugin-2.2/single-mojo.html
Under the attributes heading you can see that the single goal Is NOT
inherited by default in multi-project builds. in 2.2. That text is missing
from the 2.2-beta-5 docs. So apparently this change was made deliberately.
What does this mean then? It means that an execution of maven-assembly-plugin
which is defined in a parent POM will not be inherited by a project using that
parent POM as its parent. I'm currently trying to find out if/how one can make
it be inherited.
Assembly plugin ignores attached assemblies
---
Key: MASSEMBLY-553
URL: https://jira.codehaus.org/browse/MASSEMBLY-553
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2, 2.2.1
Reporter: SebbASF
Assignee: John Casey
Priority: Critical
Attachments: assembly-bug.zip
This used to work in 2.2-beta-5, but both 2.2 and 2.2.1 seem to ignore
attached descriptors in mvn install
Sample project to follow.
This works:
mvn -Dass.vers=2.2-beta-5 install -Prc
This does not:
mvn -Dass.vers=2.2.1 install -Prc
If you compare the ouput from the two runs, you will see that the following
is missing from 2.2.1:
[INFO] [assembly:attached {execution: default}]
[INFO] Reading assembly descriptor: src/assembly/bin.xml
[INFO] Reading assembly descriptor: src/assembly/src.xml
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-bin.zip
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-src.zip
Apache Commons cannot use 2.2 or 2.2.1 as a result of this bug
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-467) Confluence: Inconsistent handling of '\' escape characters, incorrect handling of \\ inside {{monospace}} blocks.
[
https://jira.codehaus.org/browse/DOXIA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300315#comment-300315
]
Valters Vingolds edited comment on DOXIA-467 at 6/4/12 3:45 PM:
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
than idea to include links in monospace blocks.
For the previous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the
{code}
{{monospace}}}
{code}
greedy (but Confluence Wiki does not match them greedy: {{monospace}}}
was (Author: valters):
Ok, by allowing to escape { via \, now there is issue with markup like this:
{code}
{{\\path\to\folder\}}
{code}
now it thinks } is escaped, and does not terminate the monospace block
correctly. I am thinking to make } and { to be treated literally in the
monospace block. Probably also [ and ], because [subscripts] are more common
that idea to include links in monospace blocks.
For the previous example, I will support following markup:
{code}
{{monospaced ${with.escaped.variable}}}
{code}
though that means we must be able to match the
{code}
{{monospace}}}
{code}
greedy (but Confluence Wiki does not match them greedy: {{monospace}}}
Confluence: Inconsistent handling of '\' escape characters, incorrect
handling of \\ inside {{monospace}} blocks.
-
Key: DOXIA-467
URL: https://jira.codehaus.org/browse/DOXIA-467
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Valters Vingolds
Attachments: confluence-escaping-hg.patch,
confluence-escaping-patch-files.zip, monospace-escapes.patch
I noticed that our generated pages are mostly nonsense where we have
\\unc\path\strings and also some general DOS-style paths (c:\dos\run). The
issue is that \ are eaten because they are treated as escape characters and
get suppressed from output. This is incorrect, per Confluence rules, they
should appear almost always, and only function as escapes when directly
preceding _ and * characters with special meaning (note, in Confluence they
also have + and - and ^ and ~ with special meaning, it would be used to
escape them too, but we don't have that yet).
The other issue is with \\, confluence actually does not support line breaks
within the line (it seems to me), and only forces linebreak if \\ appears at
the end of line. This makes sense, because otherwise writing \\unc\path is
impossible (as you can't quite escape the '\\' with another '\'). I haven't
yet looked how feasible it is to make \\ only work as line break if it
appears at the end of line, but my requirement was simpler: to make \\ work
inside {{monospace}} blocks, i.e., make it appear verbatim, and not produce
linebreak. So that {{\\unc\path}} can be written and appear so.
I want to also propose to make handling of italic less zealous, as we happen
to have a lot of code variables that use underscore (variables_like_this),
and currently the underscores get eaten, and (like) part gets italicized.
(Escaping all underscores is not practical.)
I wish to propose that italic modifier _ should only work if preceded by
whitespace or * (+ some other edge cases). So _this_ should get italicized
but something_like_this would not.
(You can actually see the above work right here in this comment, as JIRA
parses this text according to Confluence rules. We should strive to replicate
this behaviour, as I see one use-case of this module is to transfer wiki
pages created in Confluence into source tree as documentation. That does not
work if our implementation does not faithfully render markup as Confluence
wiki would).
I am attaching a proposed patch.
(Sorry this patch also includes lines for DOXIA-466, I don't know how to
remove them. So if you already applied that patch, you will get some rejected
hunks).
Another part is that * and _ are always produced verbatim in monospace blocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-471) Confluence: should output page title (sink.title(), title_())
Valters Vingolds created DOXIA-471: -- Summary: Confluence: should output page title (sink.title(), title_()) Key: DOXIA-471 URL: https://jira.codehaus.org/browse/DOXIA-471 Project: Maven Doxia Issue Type: Bug Components: Module - Confluence Reporter: Valters Vingolds With DOXIASITETOOLS-70 the page title is constructed as (Site title) - (Page title). So having a nicely constructed page title is ever important. Unfortunately the Confluence module actually does not provide the page title to sink ever (understandably so - because with confluence page we don't really know what the page title should be). We need to come up with some idea what could be used as page title. I would like to propose to catch first h1. header (or any first section header), and just register that as page title. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-767) releasing flat multi-module projects using git
[
https://jira.codehaus.org/browse/MRELEASE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300341#comment-300341
]
Jeremy Norris commented on MRELEASE-767:
The workaround I am using for now (although a more proper fix is needed wrt the
maven scm API and the release manager):
--- a/src/main/java/org/apache/maven/shared/release/util/ReleaseUtil.java
+++ b/src/main/java/org/apache/maven/shared/release/util/ReleaseUtil.java
@@ -179,7 +179,12 @@ public class ReleaseUtil
FileUtils.normalize( releaseDescriptor.getWorkingDirectory() ) );
String url = releaseDescriptor.getScmSourceUrl();
-url = realignScmUrl( parentLevels, url );
+if (!url.matches(scm:git.*)) {
+ String urlOrig = url;
+ url = realignScmUrl( parentLevels, url );
+ // No logger available:
+ System.out.println(SCM source URL realignment: + urlOrig + =
+ url);
+}
ReleaseDescriptor descriptor = new ReleaseDescriptor();
descriptor.setWorkingDirectory( basedir );
releasing flat multi-module projects using git
--
Key: MRELEASE-767
URL: https://jira.codehaus.org/browse/MRELEASE-767
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.3.1
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
Maven home: /usr/share/maven
Java version: 1.6.0_31, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: mac os x, version: 10.7.4, arch: x86_64, family: mac
Reporter: Jeremy Norris
When releasing a project as follows:
./parent/pom.xml
./module-a/pom.xml
./module-b/pom.xml
From the parent directory, with an scm config in the parent pom.xml (only) as
follows:
scm
connectionscm:git:ssh://github.com/repox.git/connection
developerConnectionscm:git:ssh://github.com/repox.git/developerConnection
tagmaster/tag
urlhttps://github.com/view/repox.git/url
/scm
In org/apache/maven/shared/release/util/ReleaseUtils.java:182 it does this
indiscriminately:
url = realignScmUrl( parentLevels, url );
This will trim the repo url from 'ssh://github.com/repox.git' -
'ssh://github.com', which will cause a failure when pushing the tag.
This type of realignment is not appropriate when using a git scm type.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4998) Variables interpolation: dynamic in Maven 2, static in Maven 3
[
https://jira.codehaus.org/browse/MNG-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300342#comment-300342
]
Evgeny Goldin commented on MNG-4998:
Thanks for your kind words, Darshak. Appreciate it. Let me know if you have any
ideas to make it better. So far it helped me a lot with creating dynamic Maven
properties using Groovy expressions. And sorry for off-topic, guys.
Variables interpolation: dynamic in Maven 2, static in Maven 3
--
Key: MNG-4998
URL: https://jira.codehaus.org/browse/MNG-4998
Project: Maven 2 3
Issue Type: Bug
Components: POM
Affects Versions: 3.0.2
Reporter: Evgeny Goldin
Please, see
http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-td3360336.html.
It demonstrates two examples where expression with ${variables} are
interpolated differently in Maven 2 and Maven 3: Maven 2 allows to update
properties and effect expressions interpolated later, Maven 3 also allows
to update properties but all expressions are interpolated with their old
values.
I believe Maven 2 dynamic behavior is much more preferable than Maven 3
Ant-like stickiness to what's defined in properties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-767) releasing flat multi-module projects using git
[
https://jira.codehaus.org/browse/MRELEASE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300341#comment-300341
]
Jeremy Norris edited comment on MRELEASE-767 at 6/4/12 4:09 PM:
The workaround I am using for now (although a more proper fix is needed wrt the
maven scm API and the release manager):
{noformat}
--- a/src/main/java/org/apache/maven/shared/release/util/ReleaseUtil.java
+++ b/src/main/java/org/apache/maven/shared/release/util/ReleaseUtil.java
@@ -179,7 +179,12 @@ public class ReleaseUtil
FileUtils.normalize( releaseDescriptor.getWorkingDirectory() ) );
String url = releaseDescriptor.getScmSourceUrl();
-url = realignScmUrl( parentLevels, url );
+if (!url.matches(scm:git.*)) {
+ String urlOrig = url;
+ url = realignScmUrl( parentLevels, url );
+ // No logger available:
+ System.out.println(SCM source URL realignment: + urlOrig + =
+ url);
+}
ReleaseDescriptor descriptor = new ReleaseDescriptor();
descriptor.setWorkingDirectory( basedir );
{noformat}
was (Author: jnorris):
The workaround I am using for now (although a more proper fix is needed wrt
the maven scm API and the release manager):
--- a/src/main/java/org/apache/maven/shared/release/util/ReleaseUtil.java
+++ b/src/main/java/org/apache/maven/shared/release/util/ReleaseUtil.java
@@ -179,7 +179,12 @@ public class ReleaseUtil
FileUtils.normalize( releaseDescriptor.getWorkingDirectory() ) );
String url = releaseDescriptor.getScmSourceUrl();
-url = realignScmUrl( parentLevels, url );
+if (!url.matches(scm:git.*)) {
+ String urlOrig = url;
+ url = realignScmUrl( parentLevels, url );
+ // No logger available:
+ System.out.println(SCM source URL realignment: + urlOrig + =
+ url);
+}
ReleaseDescriptor descriptor = new ReleaseDescriptor();
descriptor.setWorkingDirectory( basedir );
releasing flat multi-module projects using git
--
Key: MRELEASE-767
URL: https://jira.codehaus.org/browse/MRELEASE-767
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.3.1
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
Maven home: /usr/share/maven
Java version: 1.6.0_31, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: mac os x, version: 10.7.4, arch: x86_64, family: mac
Reporter: Jeremy Norris
When releasing a project as follows:
./parent/pom.xml
./module-a/pom.xml
./module-b/pom.xml
From the parent directory, with an scm config in the parent pom.xml (only) as
follows:
scm
connectionscm:git:ssh://github.com/repox.git/connection
developerConnectionscm:git:ssh://github.com/repox.git/developerConnection
tagmaster/tag
urlhttps://github.com/view/repox.git/url
/scm
In org/apache/maven/shared/release/util/ReleaseUtils.java:182 it does this
indiscriminately:
url = realignScmUrl( parentLevels, url );
This will trim the repo url from 'ssh://github.com/repox.git' -
'ssh://github.com', which will cause a failure when pushing the tag.
This type of realignment is not appropriate when using a git scm type.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-553) Assembly plugin ignores attached assemblies
[
https://jira.codehaus.org/browse/MASSEMBLY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300343#comment-300343
]
Dennis Lundberg commented on MASSEMBLY-553:
---
Okay, I've got this working now.
I had to tweak commons-parent a bit to override the do not inherit behavior
that was introduced in maven-assembly-plugin 2.2. Here's the new plugin
configuration for commons-parent:
{code:xml}
profile
idrc/id
...
build
plugins
...
plugin
artifactIdmaven-assembly-plugin/artifactId
inheritedtrue/inherited
executions
execution
goals
goalsingle/goal
/goals
phasepackage/phase
/execution
/executions
/plugin
/plugins
/build
/profile
{code}
I added this line, to make sure it is inherited:
{{inheritedtrue/inherited}}
Assembly plugin ignores attached assemblies
---
Key: MASSEMBLY-553
URL: https://jira.codehaus.org/browse/MASSEMBLY-553
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2, 2.2.1
Reporter: SebbASF
Assignee: John Casey
Priority: Critical
Attachments: assembly-bug.zip
This used to work in 2.2-beta-5, but both 2.2 and 2.2.1 seem to ignore
attached descriptors in mvn install
Sample project to follow.
This works:
mvn -Dass.vers=2.2-beta-5 install -Prc
This does not:
mvn -Dass.vers=2.2.1 install -Prc
If you compare the ouput from the two runs, you will see that the following
is missing from 2.2.1:
[INFO] [assembly:attached {execution: default}]
[INFO] Reading assembly descriptor: src/assembly/bin.xml
[INFO] Reading assembly descriptor: src/assembly/src.xml
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-bin.zip
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-src.zip
Apache Commons cannot use 2.2 or 2.2.1 as a result of this bug
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-553) Assembly plugin does not inherit configuration/execution from parent
[
https://jira.codehaus.org/browse/MASSEMBLY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-553:
--
Assignee: Dennis Lundberg (was: John Casey)
Summary: Assembly plugin does not inherit configuration/execution from
parent (was: Assembly plugin ignores attached assemblies)
Assembly plugin does not inherit configuration/execution from parent
Key: MASSEMBLY-553
URL: https://jira.codehaus.org/browse/MASSEMBLY-553
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2, 2.2.1
Reporter: SebbASF
Assignee: Dennis Lundberg
Priority: Critical
Attachments: assembly-bug.zip
This used to work in 2.2-beta-5, but both 2.2 and 2.2.1 seem to ignore
attached descriptors in mvn install
Sample project to follow.
This works:
mvn -Dass.vers=2.2-beta-5 install -Prc
This does not:
mvn -Dass.vers=2.2.1 install -Prc
If you compare the ouput from the two runs, you will see that the following
is missing from 2.2.1:
[INFO] [assembly:attached {execution: default}]
[INFO] Reading assembly descriptor: src/assembly/bin.xml
[INFO] Reading assembly descriptor: src/assembly/src.xml
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-bin.zip
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-src.zip
Apache Commons cannot use 2.2 or 2.2.1 as a result of this bug
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-767) releasing flat multi-module projects using git
[ https://jira.codehaus.org/browse/MRELEASE-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MRELEASE-767: --- Assignee: Mark Struberg I've talked with Mark about this. He'll have a look at it once he has some more time. releasing flat multi-module projects using git -- Key: MRELEASE-767 URL: https://jira.codehaus.org/browse/MRELEASE-767 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.3.1 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800) Maven home: /usr/share/maven Java version: 1.6.0_31, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x, version: 10.7.4, arch: x86_64, family: mac Reporter: Jeremy Norris Assignee: Mark Struberg When releasing a project as follows: ./parent/pom.xml ./module-a/pom.xml ./module-b/pom.xml From the parent directory, with an scm config in the parent pom.xml (only) as follows: scm connectionscm:git:ssh://github.com/repox.git/connection developerConnectionscm:git:ssh://github.com/repox.git/developerConnection tagmaster/tag urlhttps://github.com/view/repox.git/url /scm In org/apache/maven/shared/release/util/ReleaseUtils.java:182 it does this indiscriminately: url = realignScmUrl( parentLevels, url ); This will trim the repo url from 'ssh://github.com/repox.git' - 'ssh://github.com', which will cause a failure when pushing the tag. This type of realignment is not appropriate when using a git scm type. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-208) HelpMojo class generated by helpmojo goal uses deprecated annotations
[
https://jira.codehaus.org/browse/MPLUGIN-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MPLUGIN-208.
-
Resolution: Fixed
Assignee: Herve Boutemy (was: Olivier Lamy)
fixed in [r1346166|http://svn.apache.org/viewvc?rev=1346166view=rev]
HelpMojo class generated by helpmojo goal uses deprecated annotations
-
Key: MPLUGIN-208
URL: https://jira.codehaus.org/browse/MPLUGIN-208
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.0
Reporter: Martin Ellis
Assignee: Herve Boutemy
Fix For: 3.1
Attachments: annots-test.tar.gz
The helpmojo goal generates a HelpMojo class that uses 'expression'
annotations on parameter fields rather than 'property' annotations. This
results in a lots of output at warning level when building a plugin that uses
the helpmojo goal for documentation.
This issue refers to javadoc/qdox style annotations generated by the
maven-plugin-plugin 3.0 helpmojo. This version of the 'plugin' plugin does
output Java 5 style annotations too but they are commented out.
Sample project attached. Running {{mvn package}} on the project will show the
warnings.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-212) Won't Fix ?
Herve Boutemy created MPLUGIN-212: - Summary: Won't Fix ? Key: MPLUGIN-212 URL: https://jira.codehaus.org/browse/MPLUGIN-212 Project: Maven 2.x Plugin Tools Issue Type: Bug Reporter: Herve Boutemy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-210) NPE in generated help mojo with M2 when no goal has description
[ https://jira.codehaus.org/browse/MPLUGIN-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPLUGIN-210. - Resolution: Fixed Fix Version/s: 3.1 Assignee: Herve Boutemy fixed in [r1345805|http://svn.apache.org/viewvc?rev=1345805view=rev] NPE in generated help mojo with M2 when no goal has description --- Key: MPLUGIN-210 URL: https://jira.codehaus.org/browse/MPLUGIN-210 Project: Maven 2.x Plugin Tools Issue Type: Bug Affects Versions: 3.0 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: 3.1 java-basic-annotations IT fails under M2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-212) Won't Fix ?
[ https://jira.codehaus.org/browse/MPLUGIN-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy deleted MPLUGIN-212: -- Won't Fix ? --- Key: MPLUGIN-212 URL: https://jira.codehaus.org/browse/MPLUGIN-212 Project: Maven 2.x Plugin Tools Issue Type: Bug Reporter: Herve Boutemy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-553) Assembly plugin does not inherit configuration/execution from parent
[
https://jira.codehaus.org/browse/MASSEMBLY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MASSEMBLY-553.
-
Resolution: Fixed
Fix Version/s: 2.4
The current behavior is by design.
I documented it in the FAQ in
[r1346176|http://svn.apache.org/viewvc?view=revisionrevision=1346176].
Assembly plugin does not inherit configuration/execution from parent
Key: MASSEMBLY-553
URL: https://jira.codehaus.org/browse/MASSEMBLY-553
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2, 2.2.1
Reporter: SebbASF
Assignee: Dennis Lundberg
Priority: Critical
Fix For: 2.4
Attachments: assembly-bug.zip
This used to work in 2.2-beta-5, but both 2.2 and 2.2.1 seem to ignore
attached descriptors in mvn install
Sample project to follow.
This works:
mvn -Dass.vers=2.2-beta-5 install -Prc
This does not:
mvn -Dass.vers=2.2.1 install -Prc
If you compare the ouput from the two runs, you will see that the following
is missing from 2.2.1:
[INFO] [assembly:attached {execution: default}]
[INFO] Reading assembly descriptor: src/assembly/bin.xml
[INFO] Reading assembly descriptor: src/assembly/src.xml
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-bin.zip
[INFO] Building zip:
D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-src.zip
Apache Commons cannot use 2.2 or 2.2.1 as a result of this bug
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-104) JAVA_HOME pointing to JDK but /usr/lib/java/../lib/tools.jar being used
[
https://jira.codehaus.org/browse/MCOMPILER-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300348#comment-300348
]
Mike Hansen commented on MCOMPILER-104:
---
I have this problem too and unfortunately, my situation doesn't seem as simple
to solve as #sombriks. I'm using command-line mvn, but I also see this in
netbeans.
I get the same error and I also use Slackware (13.37). My JAVA_HOME is set to
/usr/lib/java, which is a JDK and has a jre subdirectory (I'm using the
'real' Oracle jdk 1.6).
From the error message, it seems the java compiler plugin (not forked) is
expecting JAVA_HOME to be set to the JRE which would be /usr/lib/java/jre. If
that were the case, /usr/lib/java/../lib/tools.jar would indeed resolve
correctly. So that is one work-around, but I don't see why I would need to
set my JAVA_HOME to the jre location to make things work and I don't want to
set it to the JRE.
I've looked all around in the mvn script and settings files and I can't find
anywhere that it might even hint at putting in this .. or expecting JAVA_HOME
to be the jre.
When I type 'which java', I get /usr/lib/java/bin/java, which is indeed my jdk.
It isn't a symlink and I have no symlink for java in /usr/bin.
When I type 'mvn --version' it shows my proper JAVA_HOME value as I'd expect.
Another workaround is to configure the compiler plugin in my pom file and set
the executable location to ${JAVA_HOME}/bin/java, and that works fine. But I'm
very curious to understand why the default settings cause this problem.
Here is the compiler configuration I'm using in my POM, with the work-around
commented out:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
!--
forktrue/fork
executable${JAVA_HOME}/bin/javac/executable
--
source${java-version}/source
target${java-version}/target
/configuration
/plugin
Any ideas what could be going on here?
JAVA_HOME pointing to JDK but /usr/lib/java/../lib/tools.jar being used
-
Key: MCOMPILER-104
URL: https://jira.codehaus.org/browse/MCOMPILER-104
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.0.2
Environment: Linux sombriks 2.6.24.5-smp #2 SMP Wed Apr 30 13:41:38
CDT 2008 i686 Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz GenuineIntel
GNU/Linux
java version 1.6.0_10
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)
echo $JAVA_HOME
/usr/lib/java
which javac
/usr/lib/java/bin/javac
Reporter: sombriks
using command line or netbeans plugin it's happening:
leonardo@sombriks:~/NetBeansProjects/arena/arena-client$ mvn compile
[INFO] Scanning for projects...
[INFO]
[INFO] Building Arena PUJ Client (jar)
[INFO]task-segment: [compile]
[INFO]
[INFO] [resources:resources {execution: default-resources}]
[WARNING] Using platform encoding (ISO-8859-1 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 1 source file to
/home/leonardo/NetBeansProjects/arena/arena-client/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
Unable to locate the Javac Compiler in:
/usr/lib/java/../lib/tools.jar
Please ensure you are using JDK 1.4 or above and
not a JRE (the com.sun.tools.javac.Main class is required).
In most cases you can change the location of your Java
installation by setting the JAVA_HOME environment variable.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 3 seconds
[INFO] Finished at: Wed Aug 19 11:10:59 BRT 2009
[INFO] Final Memory: 9M/65M
[INFO]
leonardo@sombriks:~/NetBeansProjects/arena/arena-client$
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
[jira] (MPLUGIN-211) @Mojo annotations aren't inherited
[ https://jira.codehaus.org/browse/MPLUGIN-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Walton closed MPLUGIN-211. - Resolution: Not A Bug Apologies for the mistake - this was a migration from Anno Mojo to maven-plugin-tools-annotations, not from Javadoc. There's no need to duplicate their behaviour. @Mojo annotations aren't inherited -- Key: MPLUGIN-211 URL: https://jira.codehaus.org/browse/MPLUGIN-211 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: maven-plugin-tools-annotations Affects Versions: 3.0 Reporter: Joseph Walton Priority: Trivial We have a project where a mojo defined in one plugin module is inherited from in another. With Javadoc-style markup, the child class is also declared as an mojo. With @Mojo, the child class needs to re-declare @Mojo in order to be included in the plugin definition. I'm reporting this as 'trivial' priority. I've fixed it by copying those @Mojo annotations across. I wouldn't have a problem with WONTFIXing this. I think the new behaviour is clearer, and I'm not convinced that the previous behaviour was intentional or desirable. However, it is still a change. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
