[jira] Closed: (MNG-3316) Barfs at attribues named .*encoding
[
http://jira.codehaus.org/browse/MNG-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MNG-3316.
--
Resolution: Fixed
fixed in r630415 in trunk and r630416 in 2.0.x branch
> Barfs at attribues named .*encoding
> ---
>
> Key: MNG-3316
> URL: http://jira.codehaus.org/browse/MNG-3316
> Project: Maven 2
> Issue Type: Bug
> Components: POM::Encoding
>Affects Versions: 2.0.8
>Reporter: David J. M. Karlsen
>Assignee: Herve Boutemy
>Priority: Blocker
> Fix For: 2.0.9
>
> Attachments: examplepom.xml, pom.xml
>
>
> With 2.0.8 a regression snuck in:
> Please see attached pom for details.
> In several of my project I use xdoclet-maven-plugin. In
> xdoclet-maven-plugin's configuration element there is an element, with an
> attribute xmlencoding="${variable}" (installed into my repository - NOT
> talking about building them).
> If maven tries to read these pom's (from my repo) it barfs with an error
> message:
> "
> Project ID: some.group.id:myproject-war
> Reason: Failed to build model from file
> 'c:\data\.m2\repository\some\group\id\myproject-war\1.3-SNAPSHOT\myproject-war-1.3-SNAPSHOT.pom'.
> Error: '${ENCODING.DEFAULT}' for project some.group.id:myproject-war .
> "
> This did NOT happen before 2.0.8 - so it must be a regression.
> What really puzzles me is why maven tries to parse these tags in the first
> place (as they are configurations for elements which should be of no value
> for this maven execution) - but I guess it was introduced when fixing
> MNG-2932, MNG-2025 and/or MNG-2254 without knowing any details.
> As 2.0.8 fails the entire build (which works on 2.0.7) I'm rating this as
> Blocker.
--
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-3244) inherited site url not properly handling parameters
[
http://jira.codehaus.org/browse/MNG-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124745
]
Jens Riboe commented on MNG-3244:
-
[I sent this comment to the list, without any repsonse, so I decided to put
them here - where they belong]
As I understand it; the current rule implements implicit URLs as
${parent.url}/${project.artifactId}
For example:
${parentPOM.scm.connection}/${project.artifactId}
...
/scm>
Where parentPOM is a made-up symbol denoting an upward search for the pom
property that follows (scm.connection).
So, how about the following suggestion:
The Super POM contains this kind of definition for all URLs where this rule
applies today. When the effective POM
is computed for a sub-project it uses the "closest" url definition that
contains the symbol parentPOM. If none is
found expect the def in super pom, this one is used and the rule applies as it
always has.
On the other hand, if one decides to put an url expression containing parentPOM
into a POM of type 'pom',
then there is a new definition and will be used. That means, we have a way to
define how sub-project urls should
be constructed. I would be delighted if I could define an expression like
${parentPOM.scm.connection}/${project.name}/trunk
There is a residual problem, however: I cannot define both an url expansion
expression and an actual url expression
that is intended to be used in sub-projects. The easiest solution, is just to
have two organization poms, the top-most
pom contains the url expansion expressions (overriding the rule from the super
pom) and the one beneath is the
original org pom, containing actual urls that will be used in the expansions
further down.
I'm convinced there are other more elegant solutions. However, the suggestion
above would be fairly easy to implement
without breaking existing code and poms (or require a POM version increment),
but still provide a way for org-pom
designers to tweak the url expansions the way they want.
Comments / Objections ???
> inherited site url not properly handling parameters
> ---
>
> Key: MNG-3244
> URL: http://jira.codehaus.org/browse/MNG-3244
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation, Sites & Reporting
>Affects Versions: 2.0.7
>Reporter: Jacob Robertson
>Assignee: Brian Fox
> Fix For: 2.0.9
>
> Attachments: fix-inherited-site-url.patch, guide-site.patch
>
>
> Here is the test case to reroduce this problem. Take the following two
> pom.xml files
>
>
> org.bar
> foo
> foo
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
>
> foo-site
> file://C:/Documents and
> Settings/foo/.m2/site/${project.artifactId}
>
>
>
>
>
> org.bar
> baz
> baz
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
> foo
> org.bar
> 1.0-SNAPSHOT
>
>
> And run the site-deploy goal on each. What you get under the site directory
> is this
> - site
> /- foo
> ---/site docs
> /- baz
> ---/- baz (extra directory)
> --- ---/site docs
> This is the simplest test case. In the case where I have a "grandparent"
> pom, the site directory uses the grandparent/parent as the path to the site,
> and doesn't use the actual artifactId of the artifact I'm creating the site
> for.
--
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: (MDEPLOY-63) Allow disabling deployment for artifacts that should not be deployed
[ http://jira.codehaus.org/browse/MDEPLOY-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124756 ] Vincent Massol commented on MDEPLOY-63: --- Thanks Olivier. Is there any doc explaining how to use it? (or maybe you could simply explain it in this issue)? > Allow disabling deployment for artifacts that should not be deployed > > > Key: MDEPLOY-63 > URL: http://jira.codehaus.org/browse/MDEPLOY-63 > Project: Maven 2.x Deploy Plugin > Issue Type: Task >Affects Versions: 2.3 >Reporter: Vincent Massol >Assignee: Olivier Lamy > Fix For: 2.4 > > > In my cargo build I have some projects producing artifacts that are purely > used for functional tests. I'd like a way to tell m2 not to deploy those when > "mvn deploy" is called at the top level. > jdcasey suggested on IRC: " I'd say you would need a flag in the > deploy plugin's config, or a or something..." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MDEPLOY-63) Allow disabling deployment for artifacts that should not be deployed
[
http://jira.codehaus.org/browse/MDEPLOY-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reopened MDEPLOY-63:
-
Reopen issue until documentation has been added in the web site.
Vincent,
In the plugin configuration you must add :
{code:xml}
true
{code}
With the cli is -Dmaven.deploy.skip=true
> Allow disabling deployment for artifacts that should not be deployed
>
>
> Key: MDEPLOY-63
> URL: http://jira.codehaus.org/browse/MDEPLOY-63
> Project: Maven 2.x Deploy Plugin
> Issue Type: Task
>Affects Versions: 2.3
>Reporter: Vincent Massol
>Assignee: Olivier Lamy
> Fix For: 2.4
>
>
> In my cargo build I have some projects producing artifacts that are purely
> used for functional tests. I'd like a way to tell m2 not to deploy those when
> "mvn deploy" is called at the top level.
> jdcasey suggested on IRC: " I'd say you would need a flag in the
> deploy plugin's config, or a or something..."
--
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: (MDEPLOY-63) Allow disabling deployment for artifacts that should not be deployed
[ http://jira.codehaus.org/browse/MDEPLOY-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124758 ] Wendy Smoak commented on MDEPLOY-63: Hi Vincent. You can use the following configuration to skip deployment of the main artifact: maven-deploy-plugin 2.4-SNAPSHOT true Updated docs will show up here soon: http://maven.apache.org/plugins/maven-deploy-plugin-2.4-SNAPSHOT > Allow disabling deployment for artifacts that should not be deployed > > > Key: MDEPLOY-63 > URL: http://jira.codehaus.org/browse/MDEPLOY-63 > Project: Maven 2.x Deploy Plugin > Issue Type: Task >Affects Versions: 2.3 >Reporter: Vincent Massol >Assignee: Olivier Lamy > Fix For: 2.4 > > > In my cargo build I have some projects producing artifacts that are purely > used for functional tests. I'd like a way to tell m2 not to deploy those when > "mvn deploy" is called at the top level. > jdcasey suggested on IRC: " I'd say you would need a flag in the > deploy plugin's config, or a or something..." -- 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: (MDEPLOY-73) Don't add checksums on gpg signature files
Don't add checksums on gpg signature files -- Key: MDEPLOY-73 URL: http://jira.codehaus.org/browse/MDEPLOY-73 Project: Maven 2.x Deploy Plugin Issue Type: Wish Affects Versions: 2.3 Reporter: Wendy Smoak Priority: Minor Similar to MINSTALL-48, don't create checksums when deploying a gpg signature file along with the artifact. Currently we end up with filename.asc, filename.asc.md5 and filename.asc.sha1 in the remote repository, and only filename.asc is necessary. -- 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: (MRESOURCES-39) Filtering fails for command line properties
[ http://jira.codehaus.org/browse/MRESOURCES-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124738 ] avalon edited comment on MRESOURCES-39 at 2/23/08 9:41 AM: -- -There was a propertyset in ANT where you can select only command-line options as a selector. I can't find Project and other classes' description in maven's Javadoc API so this is pure guess.- I'll try the patch these days, thanks! was (Author: avalon): There was a propertyset in ANT where you can select only command-line options as a selector. I can't find Project and other classes' description in maven's Javadoc API so this is pure guess. I'll try the patch these days, thanks! > Filtering fails for command line properties > --- > > Key: MRESOURCES-39 > URL: http://jira.codehaus.org/browse/MRESOURCES-39 > Project: Maven 2.x Resources Plugin > Issue Type: Bug > Environment: maven-2.0.4 and maven-2.0.5 > Mac OS X >Reporter: Matt Brozowski >Priority: Critical > Attachments: filtering-bug.tar, > maven-resources-plugin-prop-filtering-r630241.patch > > > When passing a property on the command line to maven using -D it does not > properly override values passed to filters. > I have attached a sample project that defines a property in the pom.xml > called 'filtered' This property is used as a filter in the > filtered.properties file in src/main/filtered/filtered.properties. I have > also included a test that gets passed the filtered property as a System > property via the surefire plugin. It then loaded the filtered.properties > file and tests to ensure the filters match. > The tests pass when run as > mvn test > BUT if I run as > mvn -Dfiltered=from-cmd-line teset > They fail. > I have also included the antrun plugin print its perspective on the value of > the property. -- 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: (MRESOURCES-39) Filtering fails for command line properties
[ http://jira.codehaus.org/browse/MRESOURCES-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124759 ] A commented on MRESOURCES-39: - Sorry I'm new to mvn... How can I use the patched plug-in? I've built it but couldn't find a way to make maven pick it up. > Filtering fails for command line properties > --- > > Key: MRESOURCES-39 > URL: http://jira.codehaus.org/browse/MRESOURCES-39 > Project: Maven 2.x Resources Plugin > Issue Type: Bug > Environment: maven-2.0.4 and maven-2.0.5 > Mac OS X >Reporter: Matt Brozowski >Priority: Critical > Attachments: filtering-bug.tar, > maven-resources-plugin-prop-filtering-r630241.patch > > > When passing a property on the command line to maven using -D it does not > properly override values passed to filters. > I have attached a sample project that defines a property in the pom.xml > called 'filtered' This property is used as a filter in the > filtered.properties file in src/main/filtered/filtered.properties. I have > also included a test that gets passed the filtered property as a System > property via the surefire plugin. It then loaded the filtered.properties > file and tests to ensure the filters match. > The tests pass when run as > mvn test > BUT if I run as > mvn -Dfiltered=from-cmd-line teset > They fail. > I have also included the antrun plugin print its perspective on the value of > the property. -- 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: (MRESOURCES-39) Filtering fails for command line properties
[ http://jira.codehaus.org/browse/MRESOURCES-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124759 ] avalon edited comment on MRESOURCES-39 at 2/23/08 10:17 AM: --- -Sorry I'm new to mvn... How can I use the patched plug-in? I've built it but couldn't find a way to make maven pick it up.- Ah, it just needs to be in the local repo. How can I make sure it is used when put on a private repository? Btw I don't think overwriting jvm default properties from POM is a big issue since that would be kind of hack and should be done on cmdline if needed. Thanks for the patch and hope it will be included in next plug-in versions! was (Author: avalon): Sorry I'm new to mvn... How can I use the patched plug-in? I've built it but couldn't find a way to make maven pick it up. > Filtering fails for command line properties > --- > > Key: MRESOURCES-39 > URL: http://jira.codehaus.org/browse/MRESOURCES-39 > Project: Maven 2.x Resources Plugin > Issue Type: Bug > Environment: maven-2.0.4 and maven-2.0.5 > Mac OS X >Reporter: Matt Brozowski >Priority: Critical > Attachments: filtering-bug.tar, > maven-resources-plugin-prop-filtering-r630241.patch > > > When passing a property on the command line to maven using -D it does not > properly override values passed to filters. > I have attached a sample project that defines a property in the pom.xml > called 'filtered' This property is used as a filter in the > filtered.properties file in src/main/filtered/filtered.properties. I have > also included a test that gets passed the filtered property as a System > property via the surefire plugin. It then loaded the filtered.properties > file and tests to ensure the filters match. > The tests pass when run as > mvn test > BUT if I run as > mvn -Dfiltered=from-cmd-line teset > They fail. > I have also included the antrun plugin print its perspective on the value of > the property. -- 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: (MCHECKSTYLE-87) Use Release 4.4 of Checkstyle
[ http://jira.codehaus.org/browse/MCHECKSTYLE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHECKSTYLE-87. -- Resolution: Fixed A new SNAPSHOT has also been deployed. > Use Release 4.4 of Checkstyle > - > > Key: MCHECKSTYLE-87 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-87 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Ulli Hafner >Assignee: Dennis Lundberg > Fix For: 2.2 > > > 4.3 of Checkstyle was released on January 25, 2007. Please update Maven 2.x > Checkstyle 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] Closed: (MDEPLOY-63) Allow disabling deployment for artifacts that should not be deployed
[ http://jira.codehaus.org/browse/MDEPLOY-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MDEPLOY-63. -- Resolution: Fixed Added item to faq describing how to skip deployment. It will show up here (soon): http://maven.apache.org/plugins/maven-deploy-plugin-2.4-SNAPSHOT/faq.html > Allow disabling deployment for artifacts that should not be deployed > > > Key: MDEPLOY-63 > URL: http://jira.codehaus.org/browse/MDEPLOY-63 > Project: Maven 2.x Deploy Plugin > Issue Type: Task >Affects Versions: 2.3 >Reporter: Vincent Massol >Assignee: Olivier Lamy > Fix For: 2.4 > > > In my cargo build I have some projects producing artifacts that are purely > used for functional tests. I'd like a way to tell m2 not to deploy those when > "mvn deploy" is called at the top level. > jdcasey suggested on IRC: " I'd say you would need a flag in the > deploy plugin's config, or a or something..." -- 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: (SUREFIRE-460) surefire-api manifest content is wrong: it is a copy of commons-lang
surefire-api manifest content is wrong: it is a copy of commons-lang Key: SUREFIRE-460 URL: http://jira.codehaus.org/browse/SUREFIRE-460 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.4.2, 2.4.1, 2.4 Reporter: Herve Boutemy this causes trouble if you're relying (like me) on the manifest content to know a jar content description -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MASSEMBLY-256) Regression: pom properties are no longer expanded in descriptor.
[
http://jira.codehaus.org/browse/MASSEMBLY-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Reynolds reopened MASSEMBLY-256:
-
Just reopening for a clarification. This is marked as fixed, but I don't see
any change in behavior. Does this mean that using a property in the
is not supported for the next release?
> Regression: pom properties are no longer expanded in descriptor.
>
>
> Key: MASSEMBLY-256
> URL: http://jira.codehaus.org/browse/MASSEMBLY-256
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: maven 2.0.8
> windows xp sp2
>Reporter: Mark Reynolds
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
> Attachments: assembly-issue.zip
>
>
> Attached is a minimal project which demonstrates this issue.
> The pom contains a property:
>
> ...
>
> file/path
>
>
> The descriptor uses this property in specifying the output directory for a
> fileSet:
>
> ...
>
>
> src/main/files
> ${fileLocation}
>
>
>
> In versions 2.1, 2.2-beta-1, and 2.2-SNAPSHOT of the assembly plugin, this
> property is expanded so the resulting archive has files in file/path/
> In the latest 2.2-beta-2-SNAPSHOT, the resulting archive has files in
> ${fileLocation}/...
--
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: (MSHADE-16) Manifest should never be copied from dependent JARs
[ http://jira.codehaus.org/browse/MSHADE-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSHADE-16. --- Assignee: Herve Boutemy Resolution: Fixed Fix Version/s: 1.0-beta-2 fixed in r630511 the manifest from the original jar is retained instead > Manifest should never be copied from dependent JARs > --- > > Key: MSHADE-16 > URL: http://jira.codehaus.org/browse/MSHADE-16 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.0-beta-1 >Reporter: Brett Porter >Assignee: Herve Boutemy > Fix For: 1.0-beta-2 > > > currently, the manifest from the first dependency encountered is included - > however only the one from the main JAR being shaded (or generated by the > standard archiver mechanism) should be included. > Note this is slightly different from MSHADE-17 where files from dependent > JARs should be included but only if they don't exist in the main artifact -- 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: (MSHADE-18) Configure META-INF/MANIFEST.MF
[ http://jira.codehaus.org/browse/MSHADE-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSHADE-18. --- Assignee: Herve Boutemy Resolution: Fixed Fix Version/s: 1.0-beta-2 fixed by MSHADE-16: the manifest from the original jar is retained, which can be customized like explained in the doc you pointed out > Configure META-INF/MANIFEST.MF > -- > > Key: MSHADE-18 > URL: http://jira.codehaus.org/browse/MSHADE-18 > Project: Maven 2.x Shade Plugin > Issue Type: Task >Affects Versions: 1.0-beta-1 >Reporter: Alexander Wagner >Assignee: Herve Boutemy > Fix For: 1.0-beta-2 > > > Creating a possibility to configuring the manifest file for e.g. main-class > Maybe like this: http://maven.apache.org/guides/mini/guide-manifest.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: (WAGONSSH-60) wagon ignores username part of scpexe URLs.
wagon ignores username part of scpexe URLs. --- Key: WAGONSSH-60 URL: http://jira.codehaus.org/browse/WAGONSSH-60 Project: wagon-ssh Issue Type: Bug Affects Versions: 1.0-alpha-7 Environment: maven-2.0.8, sun-java-1.6.0.03 Reporter: Wolfgang Glas We use a single user to access a project's maven repository, where this user has a list of ssh-pubkeys in .ssh/authorized_keys. Thus, we are using an URL like scpexe://[EMAIL PROTECTED]/var/maven2/repo However, wagon-ssh ignore the username of the URL and cowardly tries to log in to the server und the name of the user logged in on the desktop. Fixing this issue would be very benefitial, TIA, Wolfgang -- 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] Moved: (DOXIA-227) [regression] site plugin strips attributes from img tags
[ http://jira.codehaus.org/browse/DOXIA-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl moved MSITE-282 to DOXIA-227: --- Affects Version/s: (was: 2.0-beta-7) 1.0-alpha-9 Key: DOXIA-227 (was: MSITE-282) Project: Maven Doxia (was: Maven 2.x Site Plugin) > [regression] site plugin strips attributes from img tags > > > Key: DOXIA-227 > URL: http://jira.codehaus.org/browse/DOXIA-227 > Project: Maven Doxia > Issue Type: Bug >Affects Versions: 1.0-alpha-9 >Reporter: Brett Porter > > previous versions didn't do this, but it is happening on trunk. For an > example, run it on the Archiva site and compare outputs with the last release. -- 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: (WAGONSSH-60) wagon ignores username part of scpexe URLs.
[ http://jira.codehaus.org/browse/WAGONSSH-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wolfgang Glas updated WAGONSSH-60: -- Attachment: wagon-ssh-external-username.patch output of 'svn diff src/main/java/org/apache/maven/wagon/providers/ssh/external/ScpExternalWagon.java' of my fixed version of wagon-ssh-external-1.0-beta-2 > wagon ignores username part of scpexe URLs. > --- > > Key: WAGONSSH-60 > URL: http://jira.codehaus.org/browse/WAGONSSH-60 > Project: wagon-ssh > Issue Type: Bug >Affects Versions: 1.0-alpha-7 > Environment: maven-2.0.8, sun-java-1.6.0.03 >Reporter: Wolfgang Glas > Attachments: wagon-ssh-external-username.patch > > > We use a single user to access a project's maven repository, where this user > has a list of ssh-pubkeys in .ssh/authorized_keys. > Thus, we are using an URL like > scpexe://[EMAIL PROTECTED]/var/maven2/repo > However, wagon-ssh ignore the username of the URL and cowardly tries to log > in to the server und the name of the user logged in on the desktop. >Fixing this issue would be very benefitial, > TIA, Wolfgang -- 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-227) [regression] attributes stripped from img tags
[
http://jira.codehaus.org/browse/DOXIA-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated DOXIA-227:
Fix Version/s: 1.0-beta-1
Component/s: Sink API
Modules
Module - Xhtml
Module - Xdoc
Core
Summary: [regression] attributes stripped from img tags (was:
[regression] site plugin strips attributes from img tags)
I guess at least width and height attributes should be conserved.
However, we should work on a more general solution that allows to pass
arbitrary attributes to any sink methods. Something like (taking figure as
example, this should be applied to all relevant sink methods)
{code}
public void figure( SinkEventAttributes attributes );
{code}
where SinkEventAttributes is just a Map of attribute names-values which should
be parsed and processed by the receiving Sink. I'm not sure about the details
yet but this would solve a couple of issues apart from the current one, eg
DOXIA-38, DOXIA-63, DOXIA-78, DOXIA-163, DOXIA-164, DOXIA-204.
Comments, ideas?
> [regression] attributes stripped from img tags
> --
>
> Key: DOXIA-227
> URL: http://jira.codehaus.org/browse/DOXIA-227
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Xdoc, Module - Xhtml, Modules, Sink API
>Affects Versions: 1.0-alpha-9
>Reporter: Brett Porter
> Fix For: 1.0-beta-1
>
>
> previous versions didn't do this, but it is happening on trunk. For an
> example, run it on the Archiva site and compare outputs with the last release.
--
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: (SUREFIRE-448) @Before, @After, @BeforeClass, @AfterClass do not seem to be functioning as of 2.4
[ http://jira.codehaus.org/browse/SUREFIRE-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated SUREFIRE-448: -- Attachment: surefire448.zip updated project > @Before, @After, @BeforeClass, @AfterClass do not seem to be functioning as > of 2.4 > -- > > Key: SUREFIRE-448 > URL: http://jira.codehaus.org/browse/SUREFIRE-448 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.4 > Environment: Windows XP > maven 2.0.8 >Reporter: George Harp > Attachments: log.txt, surefire448.zip, surefire448.zip, > WeatherMessageGeneratorCallableTest.java, > WeatherMessageGeneratorCallableTest.java > > > the attached class only outputs the testOne() message: -- 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-204) Add generic parameters support to Figure and Link events
[
http://jira.codehaus.org/browse/DOXIA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124783
]
Lukas Theussl commented on DOXIA-204:
-
Just realized that your proposal is the same as what I noted at DOXIA-227, let
me copy&paste the relevant part as it really belongs here:
Something like (taking figure as example, this should be applied to all
relevant sink methods)
{code}
public void figure( SinkEventAttributes attributes );
{code}
where SinkEventAttributes is just a Map of attribute names-values which should
be parsed and processed by the receiving Sink. I'm not sure about the details
yet but this would solve a couple of issues apart from the current one, eg
DOXIA-38, DOXIA-63, DOXIA-78, DOXIA-163, DOXIA-164, DOXIA-227.
Comments, ideas?
> Add generic parameters support to Figure and Link events
>
>
> Key: DOXIA-204
> URL: http://jira.codehaus.org/browse/DOXIA-204
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Sink API
>Affects Versions: 1.0-alpha-10
>Reporter: Vincent Massol
> Fix For: 1.0-beta-1
>
>
> For example XWiki has the following syntax for image macros and links:
> * image: http://code.xwiki.org/xwiki/bin/view/Macros/ImageMacro
> * links: http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HLinks
> For the image macro there are the "document" and "fromincludingdoc" which are
> specific to XWiki and thus cannot be put as standard parameters.
> Same for links.
> Thus I propose to allow parsers to pass a Map of properties (pair/values) to
> the Sink API so that sinks can be written to understand them (the XWiki sink
> would understand them for example).
--
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-204) Add generic parameters support to Figure and Link events
[ http://jira.codehaus.org/browse/DOXIA-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated DOXIA-204: Fix Version/s: 1.0-beta-1 > Add generic parameters support to Figure and Link events > > > Key: DOXIA-204 > URL: http://jira.codehaus.org/browse/DOXIA-204 > Project: Maven Doxia > Issue Type: Improvement > Components: Sink API >Affects Versions: 1.0-alpha-10 >Reporter: Vincent Massol > Fix For: 1.0-beta-1 > > > For example XWiki has the following syntax for image macros and links: > * image: http://code.xwiki.org/xwiki/bin/view/Macros/ImageMacro > * links: http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax#HLinks > For the image macro there are the "document" and "fromincludingdoc" which are > specific to XWiki and thus cannot be put as standard parameters. > Same for links. > Thus I propose to allow parsers to pass a Map of properties (pair/values) to > the Sink API so that sinks can be written to understand them (the XWiki sink > would understand them for example). -- 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: (SUREFIRE-448) @Before, @After, @BeforeClass, @AfterClass do not seem to be functioning as of 2.4
[ http://jira.codehaus.org/browse/SUREFIRE-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed SUREFIRE-448. - Resolution: Cannot Reproduce Your log states that you're not using Surefire 2.4; you're using Surefire 2.2 (maven-surefire-plugin:2.2). I updated the sample project to include an explicit reference to version 2.4.2; I think you'll find that works better for you. > @Before, @After, @BeforeClass, @AfterClass do not seem to be functioning as > of 2.4 > -- > > Key: SUREFIRE-448 > URL: http://jira.codehaus.org/browse/SUREFIRE-448 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.4 > Environment: Windows XP > maven 2.0.8 >Reporter: George Harp > Attachments: log.txt, surefire448.zip, surefire448.zip, > WeatherMessageGeneratorCallableTest.java, > WeatherMessageGeneratorCallableTest.java > > > the attached class only outputs the testOne() message: -- 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: (MRELEASE-324) There should be a way to update POM version numbers without tagging/branching
There should be a way to update POM version numbers without tagging/branching - Key: MRELEASE-324 URL: http://jira.codehaus.org/browse/MRELEASE-324 Project: Maven 2.x Release Plugin Issue Type: Improvement Reporter: Dan Fabulich Updating versions is useful; sometimes you just want to change the version numbers in your POMs without checking in right away. There should be a way to do that. It could either be a new goal (release:update-versions) or simply an option on release:prepare to avoid tagging. Why would you want this? ... because you need to use svnmerge.py http://www.orcaware.com/svn/wiki/Svnmerge.py ... because you're using an unsupported SCM MRELEASE-184 ... because you need to take other manual steps before tagging (updating other metadata files) ... because you need to make a branch instead of making a tag MRELEASE-203 ... because you're skipping version numbers (I was calling this 1.1-SNAPSHOT, but now I want to call it 2.0-SNAPSHOT) ... because you don't want to tag until after you've blessed the release (in the Maven release process, if the vote fails, you have to delete the tag) ... because you want to update your version number to contain special build-based metadata every time you build -- 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: (MINSTALL-47) Add option to append the file name to the md5/sha1 checksums
[
http://jira.codehaus.org/browse/MINSTALL-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated MINSTALL-47:
Attachment: maven-install-checksum-patterns-v1.patch
Attaching an alternative patch that provides the option to specify a
MessagFormat style patterns for the MD5 and SHA1 checksums:
Has two new pattern properties (md5Pattern and sha1Pattern) where {0} is
replaced with the checksum, {1} with the file name and {2} is a new line.
This is almost the same as the functionality provided by the Ant checksum task
and gives greater and individual control over what is output for both md5 and
sha1 checksums.
> Add option to append the file name to the md5/sha1 checksums
>
>
> Key: MINSTALL-47
> URL: http://jira.codehaus.org/browse/MINSTALL-47
> Project: Maven 2.x Install Plugin
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Niall Pemberton
>Priority: Minor
> Attachments: maven-install-checksum-append-filename-v1.patch,
> maven-install-checksum-patterns-v1.patch
>
>
> Some tools which check checksums expect the sum to be followed by
> *filename
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg67770.html
> It would be good to have a configuration option so that the install plugin
> can do this
--
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
