[jira] Created: (MPLUGIN-185) check plugin naming conventions and issue a warning in case of problem
check plugin naming conventions and issue a warning in case of problem -- Key: MPLUGIN-185 URL: http://jira.codehaus.org/browse/MPLUGIN-185 Project: Maven 2.x Plugin Tools Issue Type: Improvement Components: Plugin Plugin Affects Versions: 2.7 Reporter: Herve Boutemy see http://markmail.org/search/?q=list%3Aorg.apache.maven.dev#query:list%3Aorg.apache.maven.dev+page:1+mid:cmqxvj6ddshmnzwr+state:results -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPLUGIN-185) check plugin naming conventions and issue a warning in case of problem
[ http://jira.codehaus.org/browse/MPLUGIN-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPLUGIN-185. - Resolution: Fixed Fix Version/s: 2.8 Assignee: Stephen Connolly fixed in [r1125604|http://svn.apache.org/viewvc?rev=1125604&view=rev] + [r1125820|http://svn.apache.org/viewvc?rev=1125820&view=rev] > check plugin naming conventions and issue a warning in case of problem > -- > > Key: MPLUGIN-185 > URL: http://jira.codehaus.org/browse/MPLUGIN-185 > Project: Maven 2.x Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Affects Versions: 2.7 >Reporter: Herve Boutemy >Assignee: Stephen Connolly > Fix For: 2.8 > > > see > http://markmail.org/search/?q=list%3Aorg.apache.maven.dev#query:list%3Aorg.apache.maven.dev+page:1+mid:cmqxvj6ddshmnzwr+state:results -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-458) Fixing the order of items in "Modules" menu
[
http://jira.codehaus.org/browse/MSITE-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=267658#action_267658
]
Herve Boutemy commented on MSITE-458:
-
Andreas, can you open another issue with this problem?
> Fixing the order of items in "Modules" menu
> ---
>
> Key: MSITE-458
> URL: http://jira.codehaus.org/browse/MSITE-458
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: New Feature
> Components: multi module
>Affects Versions: 2.1
>Reporter: Andreas Sewe
>Assignee: Lukas Theussl
> Fix For: 2.3, 3.0-beta-4
>
> Attachments: demo.tar.gz
>
>
> Currently, it is impossible to influence the order in which the "Modules"
> show up in a generated site's menu when including them like this in the site
> descriptor:
> bq.
> As far as I can tell, the order of items in the menu depends on the order in
> which Maven builds the modules -- and this does not always put the most
> important module at the top of the list. In fact, the top of the list is in
> all likelihood occupied by various low-level infrastructure modules; the
> high-level, user-visible modules typically come much later. :-(
> This also means that the order of menu items depends on the module's
> dependencies; thus, this can result in unforeseen changes to the *site* when
> one module's *build* changes. Why doesn't Maven simply use the order of the
> {{module}} elements? That would be simple and predictable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSKINS-12) Internet Explorer 9 shows scrollbar on
Internet Explorer 9 shows scrollbar on
-
Key: MSKINS-12
URL: http://jira.codehaus.org/browse/MSKINS-12
Project: Maven Skins
Issue Type: Bug
Components: Classic Skin
Affects Versions: stylus-1.3
Environment: Microsoft Windows Vista, Internet Explorer 9
Reporter: Heinrich Schuchardt
Priority: Trivial
Attachments: ie9.png
Internet Explorer 9 shows a scroll bar on the navigation column.
Examples are:
http://maven.apache.org/skins/maven-default-skin/
http://maven.apache.org/index.html
A workaround is:
#navcolumn {
overflow: hidden;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-426) Markdown module
[ http://jira.codehaus.org/browse/DOXIA-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268114#action_268114 ] Lukas Theussl commented on DOXIA-426: - Are you an apache committer? In that case you should have commit rights in the sandbox (I think). Tell me, otherwise I'll review the patch. > Markdown module > --- > > Key: DOXIA-426 > URL: http://jira.codehaus.org/browse/DOXIA-426 > Project: Maven Doxia > Issue Type: New Feature > Components: Modules >Affects Versions: 1.3 >Reporter: Julien Nicoulaud > Attachments: doxia-module-markdown-2.patch, > doxia-module-markdown.patch > > > [Markdown|http://en.wikipedia.org/wiki/Markdown] is a widespread Markup > language. It would be nice if there was a Doxia module for Markdown. > Here is a proposed simple implementation that defers all the parsing and > rendering to [PegDown|http://pegdown.org] (Apache License V2), which is the > most reliable Java library for Markdown. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-426) Markdown module
[ http://jira.codehaus.org/browse/DOXIA-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268115#action_268115 ] Julien Nicoulaud commented on DOXIA-426: No, I'm not. > Markdown module > --- > > Key: DOXIA-426 > URL: http://jira.codehaus.org/browse/DOXIA-426 > Project: Maven Doxia > Issue Type: New Feature > Components: Modules >Affects Versions: 1.3 >Reporter: Julien Nicoulaud > Attachments: doxia-module-markdown-2.patch, > doxia-module-markdown.patch > > > [Markdown|http://en.wikipedia.org/wiki/Markdown] is a widespread Markup > language. It would be nice if there was a Doxia module for Markdown. > Here is a proposed simple implementation that defers all the parsing and > rendering to [PegDown|http://pegdown.org] (Apache License V2), which is the > most reliable Java library for Markdown. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGSITE-135) Faq should include information about project.reporting.outputEncoding
[
http://jira.codehaus.org/browse/MNGSITE-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MNGSITE-135.
-
Resolution: Won't Fix
Assignee: Herve Boutemy
output encoding defaults to UTF-8, which is a perfectly reproducible value
(contrary to source encoding which defaults to platform encoding)
see
https://cwiki.apache.org/confluence/display/MAVENOLD/Reporting+Encoding+Configuration
then setting project.reporting.outputEncoding is absolutely not necessary,
particularly if you choose UTF-8 like the default value
it wouldn't be a good practice to add this unnecessary property
If failsafe reports a warning, then the plugin should be fixed: please create
an issue with a test-case. I'll be happy to fix the plugin
> Faq should include information about project.reporting.outputEncoding
> -
>
> Key: MNGSITE-135
> URL: http://jira.codehaus.org/browse/MNGSITE-135
> Project: Maven Project Web Site
> Issue Type: Improvement
>Reporter: Paul Nyheim
>Assignee: Herve Boutemy
> Attachments: faqissue.patch
>
>
> Failsafe plugin reports a WARNING if
> {code:xml}
> UTF-8
> {code}
> is not set. The FAQ only suggests to set the
> {code:xml}
> UTF-8
> {code}
> ref:
> http://stackoverflow.com/questions/3017695/how-to-configure-encoding-in-maven
> Suggested patch attached
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-328) Allow putDirectory to continue even if an individual file transfer fails
Allow putDirectory to continue even if an individual file transfer fails Key: WAGON-328 URL: http://jira.codehaus.org/browse/WAGON-328 Project: Maven Wagon Issue Type: Improvement Components: wagon-webdav Affects Versions: 1.0-beta-8 Reporter: Andrew Phillips The current WebDAV wagon implements putDirectory as a recursive sequence of individual put commands for the individual files. This means that failure of an individual put will abort the entire putDirectory. This, of course, is generally correct and desired behaviour. However, in a few cases it may not be critical that all files in a directory are correctly uploaded. The use case in mind here is uploading Maven sites to not 100% reliable DAV resources, e.g. Google Code (see also [WAGON-319]). The request would be thus to add a "continueOnFailure" option (or similar) which would not throw a TransferFailureException if put fails, but instead log a warning or similar. This option would be false by default. Admittedly, the better/"correct" place to address this issue would be in the code that *calls* the wagon (in the case of this example, in the Maven Site plugin), because it can make the context-specific decision of whether to be lenient with errors or not. However, there is no "putDirectoryLeniently" wagon method that the parent can call, and this use case does not seem significant enough to merit changing the wagon interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-328) Allow putDirectory to continue even if an individual file transfer fails
[ http://jira.codehaus.org/browse/WAGON-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Phillips updated WAGON-328: -- Attachment: WAGON-328-patch.diff > Allow putDirectory to continue even if an individual file transfer fails > > > Key: WAGON-328 > URL: http://jira.codehaus.org/browse/WAGON-328 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-webdav >Affects Versions: 1.0-beta-8 >Reporter: Andrew Phillips > Attachments: WAGON-328-patch.diff > > > The current WebDAV wagon implements putDirectory as a recursive sequence of > individual put commands for the individual files. This means that failure of > an individual put will abort the entire putDirectory. > This, of course, is generally correct and desired behaviour. However, in a > few cases it may not be critical that all files in a directory are correctly > uploaded. The use case in mind here is uploading Maven sites to not 100% > reliable DAV resources, e.g. Google Code (see also [WAGON-319]). > The request would be thus to add a "continueOnFailure" option (or similar) > which would not throw a TransferFailureException if put fails, but instead > log a warning or similar. This option would be false by default. > Admittedly, the better/"correct" place to address this issue would be in the > code that *calls* the wagon (in the case of this example, in the Maven Site > plugin), because it can make the context-specific decision of whether to be > lenient with errors or not. > However, there is no "putDirectoryLeniently" wagon method that the parent can > call, and this use case does not seem significant enough to merit changing > the wagon interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGSITE-137) Web page rendering issue on Maven in 5 Minutes
[ http://jira.codehaus.org/browse/MNGSITE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268120#action_268120 ] Herve Boutemy commented on MNGSITE-137: --- this is an IE7 rendering bug: there is no problem in IE8 you should avoid IE7... > Web page rendering issue on Maven in 5 Minutes > -- > > Key: MNGSITE-137 > URL: http://jira.codehaus.org/browse/MNGSITE-137 > Project: Maven Project Web Site > Issue Type: Bug > Environment: Internet Explorer 7.0 >Reporter: Jacob Robertson > Attachments: maven-in-5-minutes-weird-spacing.PNG > > > Background: my organization is providing hands-on Continuous Integration > training courses, and as part of that, we bring up the Maven in 5 Minutes web > page > (http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html). > Every class so far there has been a little moment of "huh?" when students get > to a huge blank part of the guide they have to scroll down through (screen > shot attached). The problem only happens on non-wide-screen monitors, and > only in IE. However, as you see from the screenshot, it's pretty odd. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5098) Environment variable HOME with space leads to an error
Environment variable HOME with space leads to an error
--
Key: MNG-5098
URL: http://jira.codehaus.org/browse/MNG-5098
Project: Maven 2 & 3
Issue Type: Bug
Components: General
Affects Versions: 3.0.3
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: C:\PROGRA~1\APACHE~1\APACHE~1.3
Java version: 1.6.0_23, vendor: Sun Microsystems Inc.
Java home: c:\Program Files\Java\jdk1.6.0_23\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
Reporter: Heinrich Schuchardt
Priority: Minor
Setting the environment variable
HOME="C:\Program Files\Microsoft Visual Studio 10.0\VC"
leads to an error when executing Maven:
C:\Users\MyUser\workspace\myproject\trunk>mvn.bat
"Files\Microsoft" kann syntaktisch an dieser Stelle nicht verarbeitet werden.
("Files\Microsoft" cannot be processed syntactically in this place.)
The equivalent to the HOME variable in Linux is USERPROFILE for Windows systems.
No assumptions about the value of variable HOME should be made on Windows.
Please observe that the value of USERPROFILE is not necessarily the
concatenation of the values of HOMEDRIVE and HOMEPATH.
Please change mvn.bat to use %USERPROFILE% instead of %HOME% on Windows systems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-328) Allow putDirectory to continue even if an individual file transfer fails
[ http://jira.codehaus.org/browse/WAGON-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268123#action_268123 ] Andrew Phillips commented on WAGON-328: --- Version with patch applied available for testing at https://github.com/demobox/wagon-webdav-jackrabbit/tree/1.0-beta-8-WAGON-319.328 > Allow putDirectory to continue even if an individual file transfer fails > > > Key: WAGON-328 > URL: http://jira.codehaus.org/browse/WAGON-328 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-webdav >Affects Versions: 1.0-beta-8 >Reporter: Andrew Phillips > Attachments: WAGON-328-patch.diff > > > The current WebDAV wagon implements putDirectory as a recursive sequence of > individual put commands for the individual files. This means that failure of > an individual put will abort the entire putDirectory. > This, of course, is generally correct and desired behaviour. However, in a > few cases it may not be critical that all files in a directory are correctly > uploaded. The use case in mind here is uploading Maven sites to not 100% > reliable DAV resources, e.g. Google Code (see also [WAGON-319]). > The request would be thus to add a "continueOnFailure" option (or similar) > which would not throw a TransferFailureException if put fails, but instead > log a warning or similar. This option would be false by default. > Admittedly, the better/"correct" place to address this issue would be in the > code that *calls* the wagon (in the case of this example, in the Maven Site > plugin), because it can make the context-specific decision of whether to be > lenient with errors or not. > However, there is no "putDirectoryLeniently" wagon method that the parent can > call, and this use case does not seem significant enough to merit changing > the wagon interface. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5094) If POM's parent is not availabe in local repository then DefaultProjectBuilder is unable to resolve this parent while POM build
[ http://jira.codehaus.org/browse/MNG-5094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=268140#action_268140 ] amaresh mourya commented on MNG-5094: - Any update on this? Thanks, Amaresh > If POM's parent is not availabe in local repository then > DefaultProjectBuilder is unable to resolve this parent while POM build > --- > > Key: MNG-5094 > URL: http://jira.codehaus.org/browse/MNG-5094 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0.3 > Environment: Linux, Using maven 3.0.3 apis to build a MavenProject > from a POM file via DefaultProjectBuilder. >Reporter: amaresh mourya > > I created a maven project via "mvn archetype:generate" with selection item > no as 3. Project I created was abc:xyz:1.0:jar. > I am using build( File pomFile, ProjectBuildingRequest request ) method of > DefaultProjectBuilder which returns ProjectBuildingResult containing > MavenProject of POM file. > Here is parent section of POM > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > > com.cedarsoft > open > 4.0.2 > > abc > xyz > 1.0 > --- > > Problem: My local repository doesn't contain com.cedarsoft:open:4.0.2. So > while building with this build method I was expecting it to download parent > (com.cedarsoft:open:4.0.2) and move ahead with the building work, but it > didn't happen. This used to happen with maven 2.2.1 apis using > DefaultMavenProjectBuilder. > I debugged and found that while resolving parent (com.cedarsoft:open:4.0.2) > repositories list is empty whereas it should provide Central repository from > Super POM to resolve this parent artifact. This used to happen with maven > 2.2.1 apis > What I did to avoid this : Either I add central repository in my POM or add > Central repository in ProjectBuildingRequest. > So I think this is a bug of maven 3.0.3 where its unable to pass central > repository while resolving artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
