[jira] [Commented] (MPOM-244) Deploy SHA-512 for source-release to Remote Repository
[ https://issues.apache.org/jira/browse/MPOM-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374979#comment-17374979 ] Julien Nicoulaud commented on MPOM-244: --- Hi guys, I just released version 3.11 of checksum-maven-plugin that restores compatibility with Maven 3.1.1. > Deploy SHA-512 for source-release to Remote Repository > -- > > Key: MPOM-244 > URL: https://issues.apache.org/jira/browse/MPOM-244 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-23 >Reporter: Konrad Windszus >Assignee: Herve Boutemy >Priority: Major > Fix For: ASF-24 > > > As now the ASF staging repository supports SHA2 hashes > (https://issues.apache.org/jira/browse/INFRA-14923) they should be generated > for > - the ASF source release artifact (as recommended in > https://infra.apache.org/release-distribution.html#sigs-and-sums) > - deployed to the Staging repository (i.e. attached to build as well) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6603) XDG Base Directory Specification support
[ https://issues.apache.org/jira/browse/MNG-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Nicoulaud updated MNG-6603: -- Description: Could Maven please follow the XDG Base Directory Specification for the configuration/data directory on linux? More infos here: * [http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html] * [http://www.freedesktop.org/wiki/Software/pyxdg] * [https://wiki.archlinux.org/index.php/XDG_Base_Directory#Support] was: Could Maven please follow the XDG Base Directory Specification for the configuration/data directory on linux? More infos here: * [http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html] * [http://www.freedesktop.org/wiki/Software/pyxdg] > XDG Base Directory Specification support > > > Key: MNG-6603 > URL: https://issues.apache.org/jira/browse/MNG-6603 > Project: Maven > Issue Type: Improvement > Components: Settings >Affects Versions: 3.6.0 >Reporter: Julien Nicoulaud >Priority: Major > Fix For: Issues to be reviewed for 4.x > > > Could Maven please follow the XDG Base Directory Specification for the > configuration/data directory on linux? > More infos here: > * [http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html] > * [http://www.freedesktop.org/wiki/Software/pyxdg] > * [https://wiki.archlinux.org/index.php/XDG_Base_Directory#Support] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6603) XDG Base Directory Specification support
[
https://issues.apache.org/jira/browse/MNG-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16777919#comment-16777919
]
Julien Nicoulaud commented on MNG-6603:
---
Currently a workaround is:
{code:xml}
mvn -gs "$XDG_CONFIG_HOME"/maven/settings.xml{code}
With {{settings.xml}}:
{code:xml}
http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
https://maven.apache.org/xsd/settings-1.0.0.xsd;>
...
${env.XDG_CACHE_HOME}/maven/repository
...
{code}
> XDG Base Directory Specification support
>
>
> Key: MNG-6603
> URL: https://issues.apache.org/jira/browse/MNG-6603
> Project: Maven
> Issue Type: Improvement
> Components: Settings
>Affects Versions: 3.6.0
>Reporter: Julien Nicoulaud
>Priority: Major
>
> Could Maven please follow the XDG Base Directory Specification for the
> configuration/data directory on linux?
> More infos here:
> * [http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html]
> * [http://www.freedesktop.org/wiki/Software/pyxdg]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6603) XDG Base Directory Specification support
Julien Nicoulaud created MNG-6603: - Summary: XDG Base Directory Specification support Key: MNG-6603 URL: https://issues.apache.org/jira/browse/MNG-6603 Project: Maven Issue Type: Improvement Components: Settings Affects Versions: 3.6.0 Reporter: Julien Nicoulaud Could Maven please follow the XDG Base Directory Specification for the configuration/data directory on linux? More infos here: * [http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html] * [http://www.freedesktop.org/wiki/Software/pyxdg] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DOXIA-436) Remove xhtml-module dependency of markdown module
[ https://issues.apache.org/jira/browse/DOXIA-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853337#comment-15853337 ] Julien Nicoulaud commented on DOXIA-436: This is pretty old, I just searched my hard drive and I can't find it. I remember starting it, but it was more work than I could put into this, sorry. Also, I can see the doxia module has evolved in the meanwhile to support some extensions. Please note Pegdown has been discontinued (see https://github.com/sirthias/pegdown/blob/master/README.markdown), maybe it is worth migrating at the same time to https://github.com/vsch/flexmark-java > Remove xhtml-module dependency of markdown module > - > > Key: DOXIA-436 > URL: https://issues.apache.org/jira/browse/DOXIA-436 > Project: Maven Doxia > Issue Type: Task > Components: Module - Markdown >Reporter: Lukas Theussl > > The markdown parser in its original form (see DOXIA-426) uses the pegdown > library to get a whole html document which is then piped through the xhtml > parser to produce proper doxia events. This double-parsing should be removed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MENFORCER-248) Upgrading maven-enforcer-plugin to 1.4.1 breaks maven-assembly-plugin
[ https://issues.apache.org/jira/browse/MENFORCER-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15711697#comment-15711697 ] Julien Nicoulaud commented on MENFORCER-248: I confirm it happens with 1.4.1 and maven-assembly-plugin 3.0.0. > Upgrading maven-enforcer-plugin to 1.4.1 breaks maven-assembly-plugin > - > > Key: MENFORCER-248 > URL: https://issues.apache.org/jira/browse/MENFORCER-248 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Reporter: Blazej Checinski >Assignee: Karl Heinz Marbaise > Fix For: 1.4.1 > > Attachments: extjars.xml, pom.xml > > > After upgrading m-e-p from 1.4 to 1.4.1 the maven-assembly-plugin generates > the following error: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.4:single (assemble) on > project extjars: Execution assemble of goal > org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed. > NullPointerException -> [Help 1] > Downgrading to m-e-p 1.4 makes the assembly work again. > Sample pom & assembly that expose the error attached. > When called via: > mvn -Dplugins.maven-enforcer-plugin.version=1.4 > a zip file is generated as expected, when called via > mvn -Dplugins.maven-enforcer-plugin.version=1.4.1 > (or without argument) you will get the NPE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MASSEMBLY-628) Bogus warning when assembling to a directory
[
https://jira.codehaus.org/browse/MASSEMBLY-628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=346956#comment-346956
]
Julien Nicoulaud commented on MASSEMBLY-628:
This is still an annoying issue.
I could have my pom as simple as this:
{code}
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
executions
execution
idpackage-assemblies/id
phasepackage/phase
goals
goalsingle/goal
/goals
/execution
/executions
configuration
descriptorSourceDirectory${project.basedir}/src/assembly/descriptors/descriptorSourceDirectory
/configuration
/plugin
/plugins
/build
{code}
but because of this, I have to invoke the assembly plugin twice, list each
descriptor in the pom, extract the descriptor contents to components, and
duplicate the descriptor files, just to avoid a warning.
I agree this is the expected behaviour so it's not a bug, but this is is
counter-intuitive and there is no elegant way to deal with it.
Can you please reopen this as an imrovement request ?
There are several alternatives:
1) Turn attach off by default
2) Hide warning for dir format as suggested earlier
3) Add a doNotWarnAboutAttachingDir parameter
Bogus warning when assembling to a directory
Key: MASSEMBLY-628
URL: https://jira.codehaus.org/browse/MASSEMBLY-628
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
Maven home: c:\Users\visola\Downloads\springsource\apache-maven-3.0.3
Java version: 1.6.0_32, vendor: Sun Microsystems Inc.
Java home: c:\Program Files\Java\jdk1.6.0_32\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
maven-assembly-plugin:2.3
Reporter: Vinicius Isola
Attachments: test.zip
When adding a dir format to the assembly file, it will output a bogus
warning like the following:
[WARNING] Assembly file: c:\Users\visola\temp\test\target\test-1.0.0 is not a
regular file (it may be a directory). It cannot be attached to the project
build for installation or deployment.
I think it is related to bug: http://jira.codehaus.org/browse/MASSEMBLY-289
Attached is an example project that can reproduce the problem just running
mvn clean install
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-449) Permissions on directories in a zipped archive incorrect
[
https://jira.codehaus.org/browse/MASSEMBLY-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326385#comment-326385
]
Julien Nicoulaud commented on MASSEMBLY-449:
I can still see this bug in 2.4. The workaround with the archiverConfig works.
Permissions on directories in a zipped archive incorrect
Key: MASSEMBLY-449
URL: https://jira.codehaus.org/browse/MASSEMBLY-449
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Components: permissions
Affects Versions: 2.2-beta-4
Reporter: James Kavanagh
Fix For: 2.4
Using the following assembly plugin:
{code:xml}
assembly
idtarget-packaged/id
formats
formatzip/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
moduleSets
moduleSet
includes
include*:core-env/include
/includes
binaries
attachmentClassifierenv/attachmentClassifier
includeDependenciesfalse/includeDependencies
unpacktrue/unpack
/binaries
/moduleSet
moduleSet
includes
include*:data-bridge/include
/includes
binaries
attachmentClassifiertarget/attachmentClassifier
includeDependenciesfalse/includeDependencies
unpacktrue/unpack
/binaries
/moduleSet
moduleSet
includes
include*:web/include
/includes
binaries
attachmentClassifierweb/attachmentClassifier
includeDependenciesfalse/includeDependencies
unpacktrue/unpack
/binaries
/moduleSet
/moduleSets
/assembly
{code}
When unzipping the result on a Linux host all the directory permissions have
been set to 777.
If I revert the plugin version to 2.2-beta-3 the issue goes away.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-51) Github ribbon image broken
Julien Nicoulaud created MSKINS-51: -- Summary: Github ribbon image broken Key: MSKINS-51 URL: https://jira.codehaus.org/browse/MSKINS-51 Project: Maven Skins Issue Type: Bug Components: Fluido Skin Affects Versions: fluido-1.2.1 Reporter: Julien Nicoulaud The Github ribbon image has changed address (example here: http://nicoulaj.github.com/checksum-maven-plugin) -- 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-606) descriptorSourceDirectory should only scan for actual assembly descriptor files
Julien Nicoulaud created MASSEMBLY-606: -- Summary: descriptorSourceDirectory should only scan for actual assembly descriptor files Key: MASSEMBLY-606 URL: https://jira.codehaus.org/browse/MASSEMBLY-606 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Julien Nicoulaud This is a logical followup of MASSEMBLY-274. It would be better if descriptorSourceDirectory only took actual assembly descriptors files, may be by checking XML doc root element ? Right now having component descriptors in the directory causes the build to fail. -- 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] Commented: (DOXIA-436) Remove xhtml-module dependency of markdown module
[ https://jira.codehaus.org/browse/DOXIA-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272628#comment-272628 ] Julien Nicoulaud commented on DOXIA-436: The proper way is to implement a Pegdown AST [Visitor|https://github.com/sirthias/pegdown/blob/master/src/main/java/org/pegdown/ast/Visitor.java] that directly fires Doxia events. I will provide a patch for this. Remove xhtml-module dependency of markdown module - Key: DOXIA-436 URL: https://jira.codehaus.org/browse/DOXIA-436 Project: Maven Doxia Issue Type: Task Components: Module - Markdown Reporter: Lukas Theussl The markdown parser in its original form (see DOXIA-426) uses the pegdown library to get a whole html document which is then piped through the xhtml parser to produce proper doxia events. This double-parsing should be removed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-426) Markdown module
[ https://jira.codehaus.org/browse/DOXIA-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Nicoulaud updated DOXIA-426: --- Attachment: doxia-module-markdown-4.patch This should have been fixed by pegdown 1.0.2 that just hit Central. Markdown module --- Key: DOXIA-426 URL: https://jira.codehaus.org/browse/DOXIA-426 Project: Maven Doxia Issue Type: New Feature Components: Modules Affects Versions: 1.3 Reporter: Julien Nicoulaud Assignee: Lukas Theussl Fix For: 1.3 Attachments: doxia-module-markdown-2.patch, doxia-module-markdown-3.patch, doxia-module-markdown-4.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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-691) tagNameFormat property interpolation does not use the release values but the project ones
tagNameFormat property interpolation does not use the release values but the
project ones
-
Key: MRELEASE-691
URL: https://jira.codehaus.org/browse/MRELEASE-691
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare, scm
Affects Versions: 2.2
Reporter: Julien Nicoulaud
Priority: Minor
Attachments: maven-release-plugin-tagNameFormat.log
The property interpolation in the [tagNameFormat
option|http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#tagNameFormat]
is counterintuitive, one would expect it to use the release value for the
project version, but instead the project SNAPSHOT version is used.
For example, with tagNameFormat@{project.version}/tagNameFormat (see
attached log):
{noformat}
What is the release version for flexlib?
(com.google.code.flexlib:flexlib-parent) 2.6: 2.6-M2
What is SCM release tag or label for flexlib?
(com.google.code.flexlib:flexlib-parent) 2.6-SNAPSHOT:
{noformat}
= The version should be 2.6-M2 I just entered here, not the project SNAPSHOT
one.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-691) tagNameFormat property interpolation does not use the release values but the project ones
[
https://jira.codehaus.org/browse/MRELEASE-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272482#comment-272482
]
Julien Nicoulaud commented on MRELEASE-691:
---
Just tried without specifying any tagNameFormat at all, it tries to tag a
SNAPSHOT version too (in the form artifactId-version), so I guess this issue is
major, a lot of people could get tricked into tagging -SNAPSHOT versions...
tagNameFormat property interpolation does not use the release values but the
project ones
-
Key: MRELEASE-691
URL: https://jira.codehaus.org/browse/MRELEASE-691
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare, scm
Affects Versions: 2.2
Reporter: Julien Nicoulaud
Priority: Minor
Attachments: maven-release-plugin-tagNameFormat.log
The property interpolation in the [tagNameFormat
option|http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#tagNameFormat]
is counterintuitive, one would expect it to use the release value for the
project version, but instead the project SNAPSHOT version is used.
For example, with tagNameFormat@{project.version}/tagNameFormat (see
attached log):
{noformat}
What is the release version for flexlib?
(com.google.code.flexlib:flexlib-parent) 2.6: 2.6-M2
What is SCM release tag or label for flexlib?
(com.google.code.flexlib:flexlib-parent) 2.6-SNAPSHOT:
{noformat}
= The version should be 2.6-M2 I just entered here, not the project SNAPSHOT
one.
--
This message is automatically generated by JIRA.
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-tabpanelfocusedCommentId=269011#action_269011 ] Julien Nicoulaud commented on DOXIA-426: Great ! Thanks for the guidelines. 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 Assignee: Lukas Theussl Fix For: 1.3 Attachments: doxia-module-markdown-2.patch, doxia-module-markdown-3.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] Updated: (DOXIA-426) Markdown module
[ http://jira.codehaus.org/browse/DOXIA-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Nicoulaud updated DOXIA-426: --- Attachment: doxia-module-markdown-3.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-3.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-tabpanelfocusedCommentId=268942#action_268942 ] Julien Nicoulaud commented on DOXIA-426: Sorry for the empty files, this is due to the way IntelliJ IDEA exports Subversion patches. Here is a new one: * test.md is now exhaustive. * Added a unit test I had forgotten. * Added rudimentary site index page. 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-3.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-tabpanelfocusedCommentId=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] Commented: (DOXIA-426) Markdown module
[ http://jira.codehaus.org/browse/DOXIA-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=267641#action_267641 ] Julien Nicoulaud commented on DOXIA-426: Thanks for reviewing the patch ! Here is a new one (or am I supposed to commit in the sandbox ?): - Removed MarkdownSink - MarkdownParser now extends XhtmlParser (which means doxia-module-markdown depends on doxia-module-xhtml and should be the last module in doxia-modules) - Added some test cases to make sure doxia events are fired. Not all events types are tested, tell me if you want more. - Upgraded PegDown library to last release 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] Updated: (DOXIA-426) Markdown module
[ http://jira.codehaus.org/browse/DOXIA-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Nicoulaud updated DOXIA-426: --- Attachment: doxia-module-markdown-2.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] Created: (DOXIA-426) Markdown module
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.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: (MPH-82) all-profiles does not show inactive profiles from settings file
[ http://jira.codehaus.org/browse/MPH-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=259158#action_259158 ] Julien Nicoulaud commented on MPH-82: - It only behaves this on Maven 3. Everything works fine on Maven 2.2.1. all-profiles does not show inactive profiles from settings file --- Key: MPH-82 URL: http://jira.codehaus.org/browse/MPH-82 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1.1 Reporter: Julien Nicoulaud The all-profiles goal does not lists the inactive profile from settings.xml. Only the active ones are included in the list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MPH-82) all-profiles does not show inactive profiles from settings file
[ http://jira.codehaus.org/browse/MPH-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=259158#action_259158 ] Julien Nicoulaud edited comment on MPH-82 at 3/7/11 1:10 PM: - It only behaves this way on Maven 3. Everything works fine on Maven 2.2.1. was (Author: nicoulaj): It only behaves this on Maven 3. Everything works fine on Maven 2.2.1. all-profiles does not show inactive profiles from settings file --- Key: MPH-82 URL: http://jira.codehaus.org/browse/MPH-82 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1.1 Reporter: Julien Nicoulaud The all-profiles goal does not lists the inactive profile from settings.xml. Only the active ones are included in the list. -- 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-5036) Settings.getProfiles() returning an empty list
Settings.getProfiles() returning an empty list -- Key: MNG-5036 URL: http://jira.codehaus.org/browse/MNG-5036 Project: Maven 2 3 Issue Type: Bug Components: Profiles, Settings Affects Versions: 3.0.3, 3.0.2, 3.0.1, 3.0 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /opt/maven/apache-maven-3.0.3 Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre Default locale: fr_FR, platform encoding: UTF-8 OS name: linux, version: 2.6.35-27-generic, arch: amd64, family: unix Reporter: Julien Nicoulaud This is related to MPH-82: in the help:all-profiles goal, [Settings.getProfiles()|http://maven.apache.org/plugins/maven-help-plugin/xref/org/apache/maven/plugins/help/AllProfilesMojo.html#317] returns an empty list since Maven 3.0. Strangely, it works fine when run with mvnDebug (without breakpoint). -- 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: (MPH-82) all-profiles does not show inactive profiles from settings file
[ http://jira.codehaus.org/browse/MPH-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=259178#action_259178 ] Julien Nicoulaud commented on MPH-82: - Settings.getProfiles() is returning an empty list. Opened Maven bug MNG-5036. all-profiles does not show inactive profiles from settings file --- Key: MPH-82 URL: http://jira.codehaus.org/browse/MPH-82 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1.1 Reporter: Julien Nicoulaud The all-profiles goal does not lists the inactive profile from settings.xml. Only the active ones are included in the list. -- 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: (MPH-82) all-profiles does not show inactive profiles from settings file
all-profiles does not show inactive profiles from settings file --- Key: MPH-82 URL: http://jira.codehaus.org/browse/MPH-82 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1.1 Reporter: Julien Nicoulaud The all-profiles goal does not lists the inactive profile from settings.xml. Only the active ones are included in the list. -- 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: (MPH-83) all-profiles should list profiles from settings.xml even if there is no project
[ http://jira.codehaus.org/browse/MPH-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=258761#action_258761 ] Julien Nicoulaud commented on MPH-83: - (Note: related to MPH-82) all-profiles should list profiles from settings.xml even if there is no project --- Key: MPH-83 URL: http://jira.codehaus.org/browse/MPH-83 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1.1 Reporter: Julien Nicoulaud Running the goal all-profiles somewhere outside of a project answers No profile detected !. I have active and inactive profiles in my settings.xml, they should appear. -- 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: (MPH-83) all-profiles should list profiles from settings.xml even if there is no project
all-profiles should list profiles from settings.xml even if there is no project --- Key: MPH-83 URL: http://jira.codehaus.org/browse/MPH-83 Project: Maven 2.x Help Plugin Issue Type: Bug Affects Versions: 2.1.1 Reporter: Julien Nicoulaud Running the goal all-profiles somewhere outside of a project answers No profile detected !. I have active and inactive profiles in my settings.xml, they should appear. -- 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-3328) Allow multiple profile activation properties.
[
http://jira.codehaus.org/browse/MNG-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=250414#action_250414
]
Julien Nicoulaud commented on MNG-3328:
---
+1 for Marco Sandrini's syntax.
@Alejandro Guizar: sorry for being offtopic, but what do you mean by If you
want to avoid duplication simply use XML entities ? Would you have an example ?
Allow multiple profile activation properties.
-
Key: MNG-3328
URL: http://jira.codehaus.org/browse/MNG-3328
Project: Maven 2 3
Issue Type: Improvement
Components: Profiles
Affects Versions: 2.0.8
Reporter: Paul Gier
Fix For: 3.x / Backlog
The pom model should be changed to allow multiple properties to activate a
profile. So the profile activation section could look something like this:
{code:xml}
activation
properties
my-prop-1some-value/my-prop-1
my-prop-2another-value/my-prop-2
/properties
/activation
{code}
This would provide more flexibility in profile activation.
--
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-4958) Allow plugin to declare fields of type password
Allow plugin to declare fields of type password --- Key: MNG-4958 URL: http://jira.codehaus.org/browse/MNG-4958 Project: Maven 2 3 Issue Type: New Feature Components: Plugin API Affects Versions: 3.0.1, 3.0, 2.2.1, 2.0.11, 2.0.10, 2.0.9, 2.2.2, 3.0.2, 3.1, 2.2.x (to be reviewed), Issues to be reviewed for 3.x, 3.x / Backlog, Documentation Deficit Reporter: Julien Nicoulaud Currently, encrypted passwords can only be used in the servers section. It would be nice if plugins could declare fields of type Password instead of String, on which password decryption would be attempted. There are many examples of plugins that require passwords or passphrases, such as maven-gpg-plugin or maven-jarsigner-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4841) --encrypt-password and --encrypt-master-password should be interactive
--encrypt-password and --encrypt-master-password should be interactive -- Key: MNG-4841 URL: http://jira.codehaus.org/browse/MNG-4841 Project: Maven 2 3 Issue Type: Improvement Affects Versions: 3.0-beta-3, 3.0-beta-2, 3.0-beta-1, 3.0-alpha-7, 3.0-alpha-6, 2.2.1, 2.0.11, 2.0.10, 2.0.9 Reporter: Julien Nicoulaud Password encrypting options require the password to be passed in the command line, which is not a secure place... You can find it later searching command history on most shells. What about just prompting for the password if none given ? -- 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-4099) Password encryption CLI switches should prompt for password if missing
[ http://jira.codehaus.org/browse/MNG-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=236639#action_236639 ] Julien Nicoulaud commented on MNG-4099: --- It is a security issue too, passing passwords in the command line is not secure as one could browse shell history afterwards. Most commands such as ssh do not allow it. Password encryption CLI switches should prompt for password if missing -- Key: MNG-4099 URL: http://jira.codehaus.org/browse/MNG-4099 Project: Maven 2 3 Issue Type: Improvement Components: Command Line Affects Versions: 2.1.0 Reporter: Mark Hobson Priority: Trivial Fix For: 3.x / Backlog The -emp and -ep CLI switches should prompt for a password if the user omits it. This would help to avoid having to escape shell characters in strong passwords. Note that the docs mention that these switches prompt for a password when they do not: http://maven.apache.org/guides/mini/guide-encryption.html -- 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: (MASSEMBLY-506) Allow to generate password protected archives
Allow to generate password protected archives - Key: MASSEMBLY-506 URL: http://jira.codehaus.org/browse/MASSEMBLY-506 Project: Maven 2.x Assembly Plugin Issue Type: New Feature Affects Versions: 2.2-beta-5 Reporter: Julien Nicoulaud It would be nice if an option was added to assembly descriptors to generate password protected archives. -- 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: (MINVOKER-97) Add possibility to inherit settings.xml from calling process
[ http://jira.codehaus.org/browse/MINVOKER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=232448#action_232448 ] Julien Nicoulaud commented on MINVOKER-97: -- As Konstantin said, you could add an 'inheritSettings' parameter, but the 'settingsFile' would still be loaded and add/override what it needs to. This way we would inherit the proxies section and still use the [fast build|http://maven.apache.org/plugins/maven-invoker-plugin/examples/fast-use.html] configuration. Add possibility to inherit settings.xml from calling process Key: MINVOKER-97 URL: http://jira.codehaus.org/browse/MINVOKER-97 Project: Maven 2.x Invoker Plugin Issue Type: New Feature Affects Versions: 1.4 Reporter: Konstantin Titorenko Assignee: Olivier Lamy Fix For: 1.6 Invoker will use default settings xml even if differetn settings xml is specified in calling maven process. It would be very usefull to add posibility to inherit settings.xml to invoker:run goal (settingsFile parameter is not enough, since it seems imposible to determine settings file from in calling maven process) -- 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: (MASSEMBLY-327) Using filtered within dependencySet unpackOptions
[ http://jira.codehaus.org/browse/MASSEMBLY-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=209240#action_209240 ] Julien Nicoulaud commented on MASSEMBLY-327: Not fixed yet on 2.2-beta-5, is there a due date for this issue ? Using filtered within dependencySet unpackOptions - Key: MASSEMBLY-327 URL: http://jira.codehaus.org/browse/MASSEMBLY-327 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Reporter: Andy Yeung The files within the unpacked jar did not apply the filters defined. pom configuration includes configuration filters filtersrc/assemble/filter.properties/filter /filters /configuration which contains storage.id=abcde assembly.xml defines dependency set dependencySet outputDirectory/snp-agent1/outputDirectory unpacktrue/unpack unpackOptions filteredtrue/filtered /unpackOptions scoperuntime/scope includes include XXX.agent:agent-ear-config /include /includes /dependencySet However, the files within are not filtered. -- 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: (MASSEMBLY-228) UnpackOptions filtered does not work
[ http://jira.codehaus.org/browse/MASSEMBLY-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=209241#action_209241 ] Julien Nicoulaud commented on MASSEMBLY-228: Always here on 2.2-beta-5. UnpackOptions filtered does not work Key: MASSEMBLY-228 URL: http://jira.codehaus.org/browse/MASSEMBLY-228 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Environment: Windows XP with maven 2.0.7 Reporter: Elid OR Assignee: Petar Tahchiev Fix For: 2.2 Attachments: bug.tar.gz Here my configuration in my assembly descriptor file : dependencySets dependencySet unpacktrue/unpack unpackOptions filteredtrue/filtered /unpackOptions includemy-groupId:my-artifactId/include /dependencySets And this correctly unpack my dependencies but it does not filter the token in it. The token are put in a profile that a activate when build the project. -- 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
