[jira] Created: (MNG-4076) Maven tries to download the correct artifact version, but from the false repository
Maven tries to download the correct artifact version, but from the false repository --- Key: MNG-4076 URL: http://jira.codehaus.org/browse/MNG-4076 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.10 Reporter: Clovis Seragiotto My project depends on the artifact org.eclipse.core.runtime 3.4.0, which depends on org.eclipse.osgi [3.2.0,4.0.0). Our company's repository has both org.eclipse.core.runtime 3.4.0 and org.eclipse.osgi.3.4.2, while the Maven central repository has older versions of both artifacts. When compiling our project, maven tries to download org.eclipse.osgi.3.4.2 from the central repository but not from the company's repository: ... [INFO] Using default encoding to copy filtered resources. Downloading: http://repo1.maven.org/maven2/org/eclipse/osgi/3.4.2/osgi-3.4.2.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.eclipse:osgi:jar:3.4.2 ... Path to dependency: 1) main:main:jar:0 2) org.eclipse.core:runtime:jar:3.4.0 3) org.eclipse:osgi:jar:3.4.2 ... from the specified remote repositories: OurRepository (file:///O|/maven-repository) central (http://repo1.maven.org/maven2) This is how the project's pom looks like: ?xml version=1.0 encoding=UTF-8? project xmlns=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; modelVersion4.0.0/modelVersion groupIdmain/groupId artifactIdmain/artifactId version0/version dependencies dependency groupIdorg.eclipse.core/groupId artifactIdruntime/artifactId version3.4.0/version /dependency /dependencies repositories repository idOurRepository/id nameour repository/name urlfile:///O|/maven-repository/url releases enabledtrue/enabled updatePolicydaily/updatePolicy checksumPolicyfail/checksumPolicy /releases snapshots enabledfalse/enabled /snapshots /repository /repositories /project If I add the central repository to the pom BEFORE our repository, then org.eclipse.osgi is found in our repository. If, however, I add the central repository to the pom AFTER our repository, org.eclipse.osgi is again not found. Simplified version for the poms of org.eclipse.* (so that one can deploy fake versions of org.eclipse.osgi and org.eclipse.core.runtime): ?xml version=1.0 encoding=UTF-8? project xmlns=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; modelVersion4.0.0/modelVersion groupIdorg.eclipse/groupId artifactIdosgi/artifactId version3.4.2/version distributionManagement repository idOurRepository/id nameour repository/name urlfile:///O|/maven-repository/url /repository /distributionManagement /project ?xml version=1.0 encoding=UTF-8? project xmlns=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; modelVersion4.0.0/modelVersion groupIdorg.eclipse.core/groupId artifactIdruntime/artifactId version3.4.0/version dependencies dependency groupIdorg.eclipse/groupId artifactIdosgi/artifactId version[3.2.0,4.0.0)/version /dependency /dependencies distributionManagement repository idOurRepository/id nameour repository/name urlfile:///O:|/maven-repository/url /repository /distributionManagement /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
[jira] Commented: (DOXIA-294) Apt verbatim box not correct
[ http://jira.codehaus.org/browse/DOXIA-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168704#action_168704 ] Lukas Theussl commented on DOXIA-294: - I just realized that we have the same problem in 1.0 too. It's a different issue though, for 1.1 the bug was in AptParser (this one I fixed), for 1.0 it's in XhtmlSink. The effect is the same, verbatim blocks are always boxed. I'm not sure if we'll do a 1.0.1 release but I'll open another issue for it. Apt verbatim box not correct Key: DOXIA-294 URL: http://jira.codehaus.org/browse/DOXIA-294 Project: Maven Doxia Issue Type: Bug Components: Module - Apt, Site Renderer Affects Versions: 1.1 Environment: Max OS X (Leopard), Sun Java 1.5.0_16. Maven 2.0.10 Reporter: Jakob Vad Nielsen Assignee: Lukas Theussl Fix For: 1.1.1 Attachments: dump.txt, proof.zip It seems to me that there are a mess on what Doxia packages versions that are chosen when rendering a site with mvn site:site. See the attached dump.txt. It seems to me that version 1.0 of doxia is not chosen. And that older versions are used. I have added this to my pom.xml plugin groupIdorg.apache.maven.doxia/groupId artifactIddoxia-maven-plugin/artifactId version1.0/version /plugin I discovered this when trying to find out why verbatime text doesn't work like it did before from an apt file. - Verbatime - gives thes same markup as +--+ Verbatime 2 +--+ Both are converted into div class=sourcepreVerbatime/pre/div. This is a new bug that I haven't seen before. I have attached a small maven project that demonstrates this. demo.html generated with site:site demonstrates the problem. -- 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-297) Verbatim blocks are always boxed
Verbatim blocks are always boxed
Key: DOXIA-297
URL: http://jira.codehaus.org/browse/DOXIA-297
Project: Maven Doxia
Issue Type: Bug
Components: Core, Module - Xhtml
Affects Versions: 1.0
Reporter: Lukas Theussl
The two apt verbatim blocks
{noformat}
+--
boxed
+--
---
not boxed
---
{noformat}
are rendered the same, i.e. the second is incorrectly boxed.
--
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-297) Verbatim blocks are always boxed
[
http://jira.codehaus.org/browse/DOXIA-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated DOXIA-297:
Fix Version/s: 1.0.1
Verbatim blocks are always boxed
Key: DOXIA-297
URL: http://jira.codehaus.org/browse/DOXIA-297
Project: Maven Doxia
Issue Type: Bug
Components: Core, Module - Xhtml
Affects Versions: 1.0
Reporter: Lukas Theussl
Fix For: 1.0.1
The two apt verbatim blocks
{noformat}
+--
boxed
+--
---
not boxed
---
{noformat}
are rendered the same, i.e. the second is incorrectly boxed.
--
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: (MNG-4038) No resolution of ~ (tilde) when installing a file to local repo
[ http://jira.codehaus.org/browse/MNG-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Michalik closed MNG-4038. -- Resolution: Not A Bug Confirmed that tilde is resolved by the shell (see http://www.vias.org/linux-knowhow/bbg_sect_03_04_03.html). Java does not resolve it at all. No resolution of ~ (tilde) when installing a file to local repo --- Key: MNG-4038 URL: http://jira.codehaus.org/browse/MNG-4038 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.9 Environment: Linux, JDK 6u12 Reporter: Adam Michalik Priority: Minor On Linux the ~ sign (tilde) is an abbreviation for user's home directory. However, when installing a file to a local repository like this: mvn install:install-file -DgroupId=jmork -DartifactId=jmork -Dversion=1.0.4 -Dpackaging=jar -Dfile=~/Download/jmork-1.0.4/jmork-1.0.4.jar where the home directory is /home/adam and current directory is /home/adam/tmp the tilde is taken literally as if it was a directories name, resulting in: [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'install'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [install:install-file] (aggregator-style) [INFO] [INFO] [install:install-file] [INFO] Installing /home/adam/tmp/~/Download/jmork-1.0.4/jmork-1.0.4.jar to /home/adam/.m2/repository/jmork/jmork/1.0.4/jmork-1.0.4.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error installing artifact 'jmork:jmork:jar': Error installing artifact: File /home/adam/tmp/~/Download/jmork-1.0.4/jmork-1.0.4.jar does not exist Workaround: specify a full path or use $HOME instead of ~ I am aware that this may be more of a Java problem and not Maven specific, but I thought it may be useful to report it anyway. -- 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-4077) Review log level for VersionExpressionTransformation.transformVersions()
Review log level for VersionExpressionTransformation.transformVersions()
Key: MNG-4077
URL: http://jira.codehaus.org/browse/MNG-4077
Project: Maven 2
Issue Type: Task
Components: Artifacts and Repositories
Affects Versions: 2.1.0-RC1
Reporter: Benjamin Bentmann
Priority: Trivial
The new transformer producer info logs like
{noformat}
[INFO] Artifact: org.apache.maven:maven-plugin-api:jar:2.0.4 does not have
project-builder metadata (ProjectBuilderConfiguration) associated with it.
Cannot access CLI properties for version transformation.
{noformat}
for any artifact created via the {{DefaultArtifactFactory}} and passed to the
installer/deployer.
This affects the Install Plugin, the Deploy Plugin and the Invoker Plugin. For
{{invoker:install}}, this causes massive info logs. Probably make this log at
debug instead?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4077) Review log level for VersionExpressionTransformation.transformVersions()
[
http://jira.codehaus.org/browse/MNG-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4077:
---
Fix Version/s: 2.1.0
Review log level for VersionExpressionTransformation.transformVersions()
Key: MNG-4077
URL: http://jira.codehaus.org/browse/MNG-4077
Project: Maven 2
Issue Type: Task
Components: Artifacts and Repositories
Affects Versions: 2.1.0-RC1
Reporter: Benjamin Bentmann
Priority: Trivial
Fix For: 2.1.0
The new transformer producer info logs like
{noformat}
[INFO] Artifact: org.apache.maven:maven-plugin-api:jar:2.0.4 does not have
project-builder metadata (ProjectBuilderConfiguration) associated with it.
Cannot access CLI properties for version transformation.
{noformat}
for any artifact created via the {{DefaultArtifactFactory}} and passed to the
installer/deployer.
This affects the Install Plugin, the Deploy Plugin and the Invoker Plugin.
For {{invoker:install}}, this causes massive info logs. Probably make this
log at debug instead?
--
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: (SCM-445) Extend command coverage of AccuRev provider for use with Continuum and Release Plugin
Extend command coverage of AccuRev provider for use with Continuum and Release Plugin - Key: SCM-445 URL: http://jira.codehaus.org/browse/SCM-445 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-accurev Reporter: Grant Gardner Attachments: maven-scm-provider-accurev.tar.gz Replacement accurev provider with additional commands - Login, Checkout, Update, Add, Changelog, CheckIn, Status, Tag, Export. See site documentation for full coverage Note that the URL syntax is different from the original minimal AccuRev 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-4078) [regression] Plugin metaversion RELEASE no longer resolved
[regression] Plugin metaversion RELEASE no longer resolved -- Key: MNG-4078 URL: http://jira.codehaus.org/browse/MNG-4078 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 3.0-alpha-3 Reporter: Benjamin Bentmann [r751083|http://svn.eu.apache.org/viewvc?view=revrevision=751083] broke resolution of plugin metaversions such that RELEASE is no longer resolved to an actual version. Hence, non-versioned plugin invocations from the CLI fail (see IT for MNG-377). -- 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: (MNG-3732) [regression] project.getActiveProfiles() has not the same behaviour
[ http://jira.codehaus.org/browse/MNG-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann reopened MNG-3732: Assignee: (was: Benjamin Bentmann) Has again been broken by some refactoring. [regression] project.getActiveProfiles() has not the same behaviour --- Key: MNG-3732 URL: http://jira.codehaus.org/browse/MNG-3732 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 3.0-alpha-1 Reporter: Vincent Siveton Fix For: 3.0-alpha-3 See MPH-38 -- 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: (MSITE-389) Maven's CSS shows ugly green shadows
Maven's CSS shows ugly green shadows Key: MSITE-389 URL: http://jira.codehaus.org/browse/MSITE-389 Project: Maven 2.x Site Plugin Issue Type: Improvement Environment: Windows, the shadows are not shown on Firefox 3.1, but on 3.1 they are shown. Also, doesn't appear on my IE 7 Reporter: Eric Lewis Priority: Minor Attachments: uglyGreenShadows.png The maven-base.css contains text shadowing for the banner text-shadow: #7CFC00 1px 1px 1px; This has problably not been reported before, because it's only shown in Firefox 3.1. However, it looks terrible, so please remove it. -- 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-539) Double quotes in fork call / long classpath
Double quotes in fork call / long classpath --- Key: SUREFIRE-539 URL: http://jira.codehaus.org/browse/SUREFIRE-539 Project: Maven Surefire Issue Type: Bug Components: classloading Affects Versions: 2.4.3 Environment: Windows XP SP3 Reporter: Patrik Kleindl Priority: Trivial We use a customized TestSuite for our test cases, it works fine when executed in the IDE (Eclipse), but when i run mvn test then the test fails with a nondescript [INFO] [surefire:test] [INFO] Surefire report directory: ... [ERROR] There are test failures. The config in pom.xml is plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.4.3/version configuration argLine-Xms500M -Xmx500M -Xmn250M/argLine useManifestOnlyJarfalse/useManifestOnlyJar includes testClasses after here When i tried it from the commandline with the debug option i saw a big block of text when then fork call happend, as mentioned in the documentation the classpath was very long. Although this might be the root of the problem i also noticed that the statement had double quotes which might not work Forking command line: cmd.exe /X /C C:\Programme\Java\jdk1.5.0_16\jre\bin\java -Xms500M -Xmx500M -Xmn250M -classpath C:\ org.apache.maven.surefire.booter.SurefireBooter tempFiles I cut out the long classpath and the file names after SurefireBooter but i think you see what i mean It's no big deal as it runs fine on Linux and on Windows you can always execute it from the IDE. -- 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-540) Surefire doesn't support @IfProfileValue
Surefire doesn't support @IfProfileValue
Key: SUREFIRE-540
URL: http://jira.codehaus.org/browse/SUREFIRE-540
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.4.3
Reporter: Christoph Kutzinski
Regression from 2.4.2:
I'm using Spring's @IfProfileValue annotation to run certain unit tests only in
specific circumstances. E.g.
@IfProfileValue(name=test.profile.stress, value=true)
public class StressTest { ... }
and start the tests with mvn test -Dtest.profile.stress=true.
This works with Surefire 2.4.2, but with 2.4.3 the tests are skipped without
further explanation.
--
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-389) Maven's CSS shows ugly green shadows
[ http://jira.codehaus.org/browse/MSITE-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168757#action_168757 ] Lukas Theussl commented on MSITE-389: - Which version of the site plugin? This is supposed to be fixed in doxia 1.0-alpha-11, see DOXIASITETOOLS-6, i.e. site plugin 2.0-beta-7. Maven's CSS shows ugly green shadows Key: MSITE-389 URL: http://jira.codehaus.org/browse/MSITE-389 Project: Maven 2.x Site Plugin Issue Type: Improvement Environment: Windows, the shadows are not shown on Firefox 3.1, but on 3.1 they are shown. Also, doesn't appear on my IE 7 Reporter: Eric Lewis Priority: Minor Attachments: uglyGreenShadows.png The maven-base.css contains text shadowing for the banner text-shadow: #7CFC00 1px 1px 1px; This has problably not been reported before, because it's only shown in Firefox 3.1. However, it looks terrible, so please remove it. -- 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-540) Surefire doesn't support @IfProfileValue
[
http://jira.codehaus.org/browse/SUREFIRE-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed SUREFIRE-540.
--
Assignee: Benjamin Bentmann
Resolution: Duplicate
This change was deliberately made, see the linked issue.
Surefire doesn't support @IfProfileValue
Key: SUREFIRE-540
URL: http://jira.codehaus.org/browse/SUREFIRE-540
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.4.3
Reporter: Christoph Kutzinski
Assignee: Benjamin Bentmann
Regression from 2.4.2:
I'm using Spring's @IfProfileValue annotation to run certain unit tests only
in specific circumstances. E.g.
@IfProfileValue(name=test.profile.stress, value=true)
public class StressTest { ... }
and start the tests with mvn test -Dtest.profile.stress=true.
This works with Surefire 2.4.2, but with 2.4.3 the tests are skipped without
further explanation.
--
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: (SUREFIRE-540) Surefire doesn't support @IfProfileValue
[
http://jira.codehaus.org/browse/SUREFIRE-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168759#action_168759
]
Benjamin Bentmann edited comment on SUREFIRE-540 at 3/10/09 9:05 AM:
-
The handling of system properties was deliberately changed, see the linked
issue.
was (Author: bentmann):
This change was deliberately made, see the linked issue.
Surefire doesn't support @IfProfileValue
Key: SUREFIRE-540
URL: http://jira.codehaus.org/browse/SUREFIRE-540
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.4.3
Reporter: Christoph Kutzinski
Assignee: Benjamin Bentmann
Regression from 2.4.2:
I'm using Spring's @IfProfileValue annotation to run certain unit tests only
in specific circumstances. E.g.
@IfProfileValue(name=test.profile.stress, value=true)
public class StressTest { ... }
and start the tests with mvn test -Dtest.profile.stress=true.
This works with Surefire 2.4.2, but with 2.4.3 the tests are skipped without
further explanation.
--
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-275) site:stage for multimodule project creates wrong links
[
http://jira.codehaus.org/browse/MSITE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168760#action_168760
]
Hugo Palma commented on MSITE-275:
--
I'm still getting this problem with both 2.0-beta-8-SNAPSHOT and 2.0-SNAPSHOT.
If i revert back to 2.0-beta-5 it works fine.
site:stage for multimodule project creates wrong links
---
Key: MSITE-275
URL: http://jira.codehaus.org/browse/MSITE-275
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: multi module
Affects Versions: 2.0-beta-6
Environment: Debian testing,maven 2.0.8
Reporter: Roman Kitko
Fix For: 2.0
Attachments: MSITE-275.zip
For multimodule project when I exec 'mvn site:stage
-DstagingDirectory=MY_STAGING_DIR', created links in index.html are hardcoded
with path to project dir :
a
href=../../mnt/data/projects/vpda/current/workspace/ws/../../../../../../localhost/home/vpda/site/org.vpda/0.02.01-SNAPSHOTvpda-common/a
When I exec mvn site, then index.html in target/site is correctly generated.
There is workaround : use site-deploy and specify some property that is
resolved in pom.xml as your deploy site url :
mvn site-deploy -Dvpda.deployUrlSite=file:///home/rki/tmp/XXX
My site.xml :
project name=vpda-site
bannerLeft
nameView providers driven applications/name
srcimages/vpda.jpg/src
hrefhttp://vpda.org//href
/bannerLeft
body
links
item name=Home href=index.html /
item name=Maven 2 href=http://maven.apache.org//
/links
menu name=VPDA inherit=none
item name=Introduction href=introduction.html/
item name=Usage href=usage.html/
item name=Downloads
href=../${project.artifactId}-${project.version}.zip/
/menu
menu ref=modules/
menu ref=reports/
menu ref=parent/
/body
/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
[jira] Commented: (MEAR-81) Suppressing application.xml creation (and inclusion) completely
[ http://jira.codehaus.org/browse/MEAR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168764#action_168764 ] Bugittaa Pahasti commented on MEAR-81: -- Hmm, I can't spot that parameter from http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html? Am I missing something? Suppressing application.xml creation (and inclusion) completely --- Key: MEAR-81 URL: http://jira.codehaus.org/browse/MEAR-81 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3.1 Environment: Glassfish V2 appserver Reporter: Andri Saar Assignee: Stephane Nicoll Priority: Minor Fix For: 2.3.2 Currently, the maven EAR plugin requires you to include an application.xml descriptor in every EAR file; however, according to the Java EE 5 spec, this descriptor is now considered optional. Furthermore, the existence of application.xml appears to change the semantics of how the application is deployed, at least on Glassfish V2 (if application.xml exists, EJB3 beans with just a local interface are not registered in the JNDI directory; if application.xml is not there, all beans are registered in JNDI). I can suppress the automatic creation of application.xml with the generateApplicationXml parameter; however, if I do that, maven-ear-plugin starts complaining about not finding application.xml, and currently there is no way (or at least I didn't find any easy way) to stop maven-ear-plugin from trying to include the application.xml. It would be great if maven-ear-plugin provided a parameter, say suppressApplicationXml, with what you could force maven-ear-plugin not to include an application.xml in the generated EAR file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MEAR-81) Suppressing application.xml creation (and inclusion) completely
[ http://jira.codehaus.org/browse/MEAR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168764#action_168764 ] Bugittaa Pahasti edited comment on MEAR-81 at 3/10/09 9:34 AM: --- Hmm, I can't spot that parameter from http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html? Am I missing something? Edit: Seems to be listed here: http://maven.apache.org/plugins/maven-ear-plugin/generate-application-xml-mojo.html. But isn't it applicable also for the ear task? was (Author: bugittaa): Hmm, I can't spot that parameter from http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html? Am I missing something? Suppressing application.xml creation (and inclusion) completely --- Key: MEAR-81 URL: http://jira.codehaus.org/browse/MEAR-81 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3.1 Environment: Glassfish V2 appserver Reporter: Andri Saar Assignee: Stephane Nicoll Priority: Minor Fix For: 2.3.2 Currently, the maven EAR plugin requires you to include an application.xml descriptor in every EAR file; however, according to the Java EE 5 spec, this descriptor is now considered optional. Furthermore, the existence of application.xml appears to change the semantics of how the application is deployed, at least on Glassfish V2 (if application.xml exists, EJB3 beans with just a local interface are not registered in the JNDI directory; if application.xml is not there, all beans are registered in JNDI). I can suppress the automatic creation of application.xml with the generateApplicationXml parameter; however, if I do that, maven-ear-plugin starts complaining about not finding application.xml, and currently there is no way (or at least I didn't find any easy way) to stop maven-ear-plugin from trying to include the application.xml. It would be great if maven-ear-plugin provided a parameter, say suppressApplicationXml, with what you could force maven-ear-plugin not to include an application.xml in the generated EAR file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-389) Maven's CSS shows ugly green shadows
[ http://jira.codehaus.org/browse/MSITE-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168766#action_168766 ] Eric Lewis commented on MSITE-389: -- I'm using Maven 2.0.9, so according to its release notes, it's 2.0-beta-6. Maven's CSS shows ugly green shadows Key: MSITE-389 URL: http://jira.codehaus.org/browse/MSITE-389 Project: Maven 2.x Site Plugin Issue Type: Improvement Environment: Windows, the shadows are not shown on Firefox 3.1, but on 3.1 they are shown. Also, doesn't appear on my IE 7 Reporter: Eric Lewis Priority: Minor Attachments: uglyGreenShadows.png The maven-base.css contains text shadowing for the banner text-shadow: #7CFC00 1px 1px 1px; This has problably not been reported before, because it's only shown in Firefox 3.1. However, it looks terrible, so please remove it. -- 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: (MEAR-81) Suppressing application.xml creation (and inclusion) completely
[ http://jira.codehaus.org/browse/MEAR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168765#action_168765 ] Stephane Nicoll commented on MEAR-81: - why do you care? It's a plugin config thing. It's not linked to a particular mojo Suppressing application.xml creation (and inclusion) completely --- Key: MEAR-81 URL: http://jira.codehaus.org/browse/MEAR-81 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3.1 Environment: Glassfish V2 appserver Reporter: Andri Saar Assignee: Stephane Nicoll Priority: Minor Fix For: 2.3.2 Currently, the maven EAR plugin requires you to include an application.xml descriptor in every EAR file; however, according to the Java EE 5 spec, this descriptor is now considered optional. Furthermore, the existence of application.xml appears to change the semantics of how the application is deployed, at least on Glassfish V2 (if application.xml exists, EJB3 beans with just a local interface are not registered in the JNDI directory; if application.xml is not there, all beans are registered in JNDI). I can suppress the automatic creation of application.xml with the generateApplicationXml parameter; however, if I do that, maven-ear-plugin starts complaining about not finding application.xml, and currently there is no way (or at least I didn't find any easy way) to stop maven-ear-plugin from trying to include the application.xml. It would be great if maven-ear-plugin provided a parameter, say suppressApplicationXml, with what you could force maven-ear-plugin not to include an application.xml in the generated EAR file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-81) Suppressing application.xml creation (and inclusion) completely
[ http://jira.codehaus.org/browse/MEAR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168769#action_168769 ] Bugittaa Pahasti commented on MEAR-81: -- Good question. :) I have always thought that only the parameters listed for the goal are used, i.e. that the goal lists all the parameters it uses. If that's not the case, how can I know which parameters the goal will actually use? Suppressing application.xml creation (and inclusion) completely --- Key: MEAR-81 URL: http://jira.codehaus.org/browse/MEAR-81 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3.1 Environment: Glassfish V2 appserver Reporter: Andri Saar Assignee: Stephane Nicoll Priority: Minor Fix For: 2.3.2 Currently, the maven EAR plugin requires you to include an application.xml descriptor in every EAR file; however, according to the Java EE 5 spec, this descriptor is now considered optional. Furthermore, the existence of application.xml appears to change the semantics of how the application is deployed, at least on Glassfish V2 (if application.xml exists, EJB3 beans with just a local interface are not registered in the JNDI directory; if application.xml is not there, all beans are registered in JNDI). I can suppress the automatic creation of application.xml with the generateApplicationXml parameter; however, if I do that, maven-ear-plugin starts complaining about not finding application.xml, and currently there is no way (or at least I didn't find any easy way) to stop maven-ear-plugin from trying to include the application.xml. It would be great if maven-ear-plugin provided a parameter, say suppressApplicationXml, with what you could force maven-ear-plugin not to include an application.xml in the generated EAR file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-81) Suppressing application.xml creation (and inclusion) completely
[ http://jira.codehaus.org/browse/MEAR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168771#action_168771 ] Stephane Nicoll commented on MEAR-81: - you don't need to worry about it. Say that you're interested by the generation of application xml, you look to the parameters, you add the ones you want in the plugin config. Same for the main goal. There's no difference. As you may guess, it is obvious that the generate application xml mojo (ans so the ear:generate-application-xml goal) is responsible to decide whether or not the application.xml should be generated. Again, you don't care as a user because the only thing you would do is 'mvn package' or 'mvn deploy' or ... Suppressing application.xml creation (and inclusion) completely --- Key: MEAR-81 URL: http://jira.codehaus.org/browse/MEAR-81 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3.1 Environment: Glassfish V2 appserver Reporter: Andri Saar Assignee: Stephane Nicoll Priority: Minor Fix For: 2.3.2 Currently, the maven EAR plugin requires you to include an application.xml descriptor in every EAR file; however, according to the Java EE 5 spec, this descriptor is now considered optional. Furthermore, the existence of application.xml appears to change the semantics of how the application is deployed, at least on Glassfish V2 (if application.xml exists, EJB3 beans with just a local interface are not registered in the JNDI directory; if application.xml is not there, all beans are registered in JNDI). I can suppress the automatic creation of application.xml with the generateApplicationXml parameter; however, if I do that, maven-ear-plugin starts complaining about not finding application.xml, and currently there is no way (or at least I didn't find any easy way) to stop maven-ear-plugin from trying to include the application.xml. It would be great if maven-ear-plugin provided a parameter, say suppressApplicationXml, with what you could force maven-ear-plugin not to include an application.xml in the generated EAR file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-389) Maven's CSS shows ugly green shadows
[ http://jira.codehaus.org/browse/MSITE-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Lewis closed MSITE-389. Resolution: Fixed Ok, I just tested it on 2.0-beta-7, the text-shadow is gone. Thanks! Maven's CSS shows ugly green shadows Key: MSITE-389 URL: http://jira.codehaus.org/browse/MSITE-389 Project: Maven 2.x Site Plugin Issue Type: Improvement Environment: Windows, the shadows are not shown on Firefox 3.1, but on 3.1 they are shown. Also, doesn't appear on my IE 7 Reporter: Eric Lewis Priority: Minor Attachments: uglyGreenShadows.png The maven-base.css contains text shadowing for the banner text-shadow: #7CFC00 1px 1px 1px; This has problably not been reported before, because it's only shown in Firefox 3.1. However, it looks terrible, so please remove it. -- 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-398) outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping is working on Maven 2.0.4 (provided with Maestro 1.1) but not working with Maven 2.0.10
outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping is
working on Maven 2.0.4 (provided with Maestro 1.1) but not working with Maven
2.0.10
-
Key: MASSEMBLY-398
URL: http://jira.codehaus.org/browse/MASSEMBLY-398
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Reporter: Usman Muhammed Syed
Maven Assembly Syntax:
outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping
working with Maven 2.0.4 but with Maven 2.0.10, it creates all the jar file
with one single name which is the artificat id of the project and .${extension}
as the filename extension. Here is my clientAssembly file.
assembly
formats
formatzip/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
fileSets
fileSet
directory
../../kiosk/presentation-war/src/main/webapp/images
/directory
outputDirectory/images//outputDirectory
/fileSet
fileSet
outputDirectory/images//outputDirectory
/fileSet
/fileSets
dependencySets
dependencySet
outputDirectory/images//outputDirectory
!-- The line below is not working in newer versions of
Maven. Working with Maven included in Maestro 1.1. A regression in Maven --
outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping
unpackfalse/unpack
scoperuntime/scope
includes
includecommons-logging:commons-logging/include
includeorg.apache.log4j:log4j/include
includeidl:idl/include
includejacorb:jacorb/include
includexerces:xercesImpl/include
includexml-apis:xml-apis/include
!--includeorg.netscape.plugin:plugin/include--
/includes
/dependencySet
/dependencySets
/assembly
--
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: (DOXIA-296) HTML is escaped inside source
[
http://jira.codehaus.org/browse/DOXIA-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIA-296.
---
Assignee: Lukas Theussl
Resolution: Fixed
Fixed in r752148.
HTML is escaped inside source
---
Key: DOXIA-296
URL: http://jira.codehaus.org/browse/DOXIA-296
Project: Maven Doxia
Issue Type: Bug
Components: Module - Xdoc
Affects Versions: 1.1
Reporter: Lukas Theussl
Assignee: Lukas Theussl
Fix For: 1.1.1
The following two source boxes give the same output:
{code:xml}
sourcea href=what.htmlwhat/a/source
source![CDATA[a href=what.htmlwhat/a]]/source
{code}
ie the html characters are incorrectly escaped in the first version.
--
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-398) outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping is working on Maven 2.0.4 (provided with Maestro 1.1) but not working with Maven 2.0.10
[
http://jira.codehaus.org/browse/MASSEMBLY-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168778#action_168778
]
Usman Muhammed Syed commented on MASSEMBLY-398:
---
Is there a newer syntax?
outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping is
working on Maven 2.0.4 (provided with Maestro 1.1) but not working with Maven
2.0.10
-
Key: MASSEMBLY-398
URL: http://jira.codehaus.org/browse/MASSEMBLY-398
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Reporter: Usman Muhammed Syed
Maven Assembly Syntax:
outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping
working with Maven 2.0.4 but with Maven 2.0.10, it creates all the jar file
with one single name which is the artificat id of the project and
.${extension} as the filename extension. Here is my clientAssembly file.
assembly
formats
formatzip/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
fileSets
fileSet
directory
../../kiosk/presentation-war/src/main/webapp/images
/directory
outputDirectory/images//outputDirectory
/fileSet
fileSet
outputDirectory/images//outputDirectory
/fileSet
/fileSets
dependencySets
dependencySet
outputDirectory/images//outputDirectory
!-- The line below is not working in newer versions of
Maven. Working with Maven included in Maestro 1.1. A regression in Maven --
outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping
unpackfalse/unpack
scoperuntime/scope
includes
includecommons-logging:commons-logging/include
includeorg.apache.log4j:log4j/include
includeidl:idl/include
includejacorb:jacorb/include
includexerces:xercesImpl/include
includexml-apis:xml-apis/include
!--includeorg.netscape.plugin:plugin/include--
/includes
/dependencySet
/dependencySets
/assembly
--
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-275) site:stage for multimodule project creates wrong links
[
http://jira.codehaus.org/browse/MSITE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168779#action_168779
]
Dennis Lundberg commented on MSITE-275:
---
Hugo, if this is not working for you, then you need to supply us with a test
project that shows that. This issue has been closed as fixed in 2.0 - so it
should work in the current 2.0-SNAPSHOT.
site:stage for multimodule project creates wrong links
---
Key: MSITE-275
URL: http://jira.codehaus.org/browse/MSITE-275
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: multi module
Affects Versions: 2.0-beta-6
Environment: Debian testing,maven 2.0.8
Reporter: Roman Kitko
Fix For: 2.0
Attachments: MSITE-275.zip
For multimodule project when I exec 'mvn site:stage
-DstagingDirectory=MY_STAGING_DIR', created links in index.html are hardcoded
with path to project dir :
a
href=../../mnt/data/projects/vpda/current/workspace/ws/../../../../../../localhost/home/vpda/site/org.vpda/0.02.01-SNAPSHOTvpda-common/a
When I exec mvn site, then index.html in target/site is correctly generated.
There is workaround : use site-deploy and specify some property that is
resolved in pom.xml as your deploy site url :
mvn site-deploy -Dvpda.deployUrlSite=file:///home/rki/tmp/XXX
My site.xml :
project name=vpda-site
bannerLeft
nameView providers driven applications/name
srcimages/vpda.jpg/src
hrefhttp://vpda.org//href
/bannerLeft
body
links
item name=Home href=index.html /
item name=Maven 2 href=http://maven.apache.org//
/links
menu name=VPDA inherit=none
item name=Introduction href=introduction.html/
item name=Usage href=usage.html/
item name=Downloads
href=../${project.artifactId}-${project.version}.zip/
/menu
menu ref=modules/
menu ref=reports/
menu ref=parent/
/body
/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
[jira] Commented: (MASSEMBLY-398) outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping is working on Maven 2.0.4 (provided with Maestro 1.1) but not working with Maven 2.0.10
[
http://jira.codehaus.org/browse/MASSEMBLY-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168780#action_168780
]
John Casey commented on MASSEMBLY-398:
--
Try ${artifact.artifactId} and ${artifact.extension} instead...that should work.
outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping is
working on Maven 2.0.4 (provided with Maestro 1.1) but not working with Maven
2.0.10
-
Key: MASSEMBLY-398
URL: http://jira.codehaus.org/browse/MASSEMBLY-398
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Reporter: Usman Muhammed Syed
Maven Assembly Syntax:
outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping
working with Maven 2.0.4 but with Maven 2.0.10, it creates all the jar file
with one single name which is the artificat id of the project and
.${extension} as the filename extension. Here is my clientAssembly file.
assembly
formats
formatzip/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
fileSets
fileSet
directory
../../kiosk/presentation-war/src/main/webapp/images
/directory
outputDirectory/images//outputDirectory
/fileSet
fileSet
outputDirectory/images//outputDirectory
/fileSet
/fileSets
dependencySets
dependencySet
outputDirectory/images//outputDirectory
!-- The line below is not working in newer versions of
Maven. Working with Maven included in Maestro 1.1. A regression in Maven --
outputFileNameMapping${artifactId}.${extension}/outputFileNameMapping
unpackfalse/unpack
scoperuntime/scope
includes
includecommons-logging:commons-logging/include
includeorg.apache.log4j:log4j/include
includeidl:idl/include
includejacorb:jacorb/include
includexerces:xercesImpl/include
includexml-apis:xml-apis/include
!--includeorg.netscape.plugin:plugin/include--
/includes
/dependencySet
/dependencySets
/assembly
--
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-4079) Duplicate error messages
Duplicate error messages Key: MNG-4079 URL: http://jira.codehaus.org/browse/MNG-4079 Project: Maven 2 Issue Type: Bug Affects Versions: 2.1.0-RC1 Environment: Apache Maven 2.1.0 (r751709; 2009-03-09 16:35:14+0100) Java version: 1.4.2_17 Java home: C:\j2sdk1.4.2_17\jre Default locale: fr_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: Julien HENRY Priority: Minor Attachments: output.txt Very often with Maven the error messages are duplicated. For example deprecation warnings and compilation issues. I've attached an example with -e option. In my case I'm trying to build a project that requires JDK 1.5+ with JDK 1.4. -- 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] Work started: (MNG-4077) Review log level for VersionExpressionTransformation.transformVersions()
[
http://jira.codehaus.org/browse/MNG-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MNG-4077 started by John Casey.
Review log level for VersionExpressionTransformation.transformVersions()
Key: MNG-4077
URL: http://jira.codehaus.org/browse/MNG-4077
Project: Maven 2
Issue Type: Task
Components: Artifacts and Repositories
Affects Versions: 2.1.0-RC1
Reporter: Benjamin Bentmann
Assignee: John Casey
Priority: Trivial
Fix For: 2.1.0
The new transformer producer info logs like
{noformat}
[INFO] Artifact: org.apache.maven:maven-plugin-api:jar:2.0.4 does not have
project-builder metadata (ProjectBuilderConfiguration) associated with it.
Cannot access CLI properties for version transformation.
{noformat}
for any artifact created via the {{DefaultArtifactFactory}} and passed to the
installer/deployer.
This affects the Install Plugin, the Deploy Plugin and the Invoker Plugin.
For {{invoker:install}}, this causes massive info logs. Probably make this
log at debug instead?
--
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] Work started: (MNG-4075) Tone down warnings about reactor dependencies that don't have an associated file
[ http://jira.codehaus.org/browse/MNG-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-4075 started by John Casey. Tone down warnings about reactor dependencies that don't have an associated file Key: MNG-4075 URL: http://jira.codehaus.org/browse/MNG-4075 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.1.0 Reporter: John Casey Assignee: John Casey Fix For: 2.1.0 currently this is logged to the WARNING level, but it can be disquieting without causing any real problems. I'm not entirely sure how these messages come up during the clean phase, but at least in the CXF project, they definitely seem to. We should tone them down to the DEBUG log level for now, unless/until we can find a way of being certain they're going to cause a problem. -- 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-4080) running mvn fails on IBM JDK 6 with NullPointerException
running mvn fails on IBM JDK 6 with NullPointerException Key: MNG-4080 URL: http://jira.codehaus.org/browse/MNG-4080 Project: Maven 2 Issue Type: Bug Components: Bootstrap Build Affects Versions: 2.0.10, 2.0.9, 2.0.8 Environment: Windows XP, IBM SDK 6.0 Reporter: Volker Karlmeier Running mvn under IBM SDK 6.0 fails with NullPointerException: [INFO] Scanning for projects... [INFO] [INFO] Building AlertBatches [INFO]task-segment: [compile] [INFO] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java 164) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssemble .assembleBuildInheritance(DefaultModelInheritanceAssembler.java:369) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssemble .assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssemble .assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(De aultMavenProjectBuilder.java:851) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromReposit ry(DefaultMavenProjectBuilder.java:252) at org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersi n(DefaultPluginManager.java:265) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(D faultPluginManager.java:197) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPlu inManager.java:176) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Def ultLifecycleExecutor.java:1275) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLife ycle(DefaultLifecycleExecutor.java:1239) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecyc eMappings(DefaultLifecycleExecutor.java:1005) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defa ltLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHa dleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegme ts(DefaultLifecycleExecutor.java:292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultL fecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl java:59) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce sorImpl.java:39) at java.lang.reflect.Method.invoke(Method.java:612) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430 at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 1 second [INFO] Finished at: Tue Mar 10 17:49:51 CET 2009 [INFO] Final Memory: 5M/1024M [INFO] -- 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-4075) Tone down warnings about reactor dependencies that don't have an associated file
[ http://jira.codehaus.org/browse/MNG-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168793#action_168793 ] John Casey commented on MNG-4075: - If we think it's a valuable thing to warn about sibling artifacts used for dependencies, that assumes those dependencies might have changed, which might change the compile or test results of the project currently being built. These are relatively easy to see, since they will likely stop the build. They may not be simple to debug without a message like this, but fundamentally this is a slightly less dangerous state of affairs than the following: If a plugin has been updated yet isn't used for the current build, the old copy may inject _very_ subtle errors into the final project artifact, which could actually push off the discovery of this error to some point outside the build...even to the production runtime, if integration tests aren't run on that artifact. Same goes for build extensions. If we dial down this message for plugins, there should be no problem doing so for dependencies. Maybe a better solution would be to find a way to _avoid_ using plugin/extension artifacts from projects in the reactor, that cannot be found in the reactor...I'm not sure how to do this for extensions, but for plugins (that don't use the extensions == true flag) we might use a just-in-time approach to loading the plugin artifact itself... I'll turn down this error message to debug log-level for now, but open a new issue for later to review the plugin/extension problem outlined above. Tone down warnings about reactor dependencies that don't have an associated file Key: MNG-4075 URL: http://jira.codehaus.org/browse/MNG-4075 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.1.0 Reporter: John Casey Assignee: John Casey Fix For: 2.1.0 currently this is logged to the WARNING level, but it can be disquieting without causing any real problems. I'm not entirely sure how these messages come up during the clean phase, but at least in the CXF project, they definitely seem to. We should tone them down to the DEBUG log level for now, unless/until we can find a way of being certain they're going to cause a problem. -- 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-4081) Subtle case: Avoid resolving artifacts from outside the reactor for plugins and extensions whose projects are inside the reactor
Subtle case: Avoid resolving artifacts from outside the reactor for plugins and extensions whose projects are inside the reactor Key: MNG-4081 URL: http://jira.codehaus.org/browse/MNG-4081 Project: Maven 2 Issue Type: Improvement Reporter: John Casey DefaultLifecycleExecutor.constructLifecycleMappings() can trigger the resolution of all the plugins declared in the project's build section. When this happens, even if those plugins are in the current reactor, *that version will not be used*. Instead, since those plugin artifacts haven't been built yet, the plugin will be resolved externally and bound into the plugin collector for later use. This means that even if the plugin itself isn't used until after it's build in the reactor, that version won't be used. I'm still investigating exactly how build extensions will interact with the reactor, but I suspect they cannot be available from the current reactor either, since build extensions are loaded up front and for the entire reactor at once. I'll post an update once I've explored that section of the code. -- 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: (MNG-4080) running mvn fails on IBM JDK 6 with NullPointerException
[ http://jira.codehaus.org/browse/MNG-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4080. -- Assignee: Benjamin Bentmann Resolution: Duplicate From the stack trace, this appears to be a duplicate of MNG-3580 which should be fixed with IBM JDK 1.6 SR2. running mvn fails on IBM JDK 6 with NullPointerException Key: MNG-4080 URL: http://jira.codehaus.org/browse/MNG-4080 Project: Maven 2 Issue Type: Bug Components: Bootstrap Build Affects Versions: 2.0.8, 2.0.9, 2.0.10 Environment: Windows XP, IBM SDK 6.0 Reporter: Volker Karlmeier Assignee: Benjamin Bentmann Running mvn under IBM SDK 6.0 fails with NullPointerException: [INFO] Scanning for projects... [INFO] [INFO] Building AlertBatches [INFO]task-segment: [compile] [INFO] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.project.ModelUtils.mergePluginLists(ModelUtils.java 164) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssemble .assembleBuildInheritance(DefaultModelInheritanceAssembler.java:369) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssemble .assembleModelInheritance(DefaultModelInheritanceAssembler.java:168) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssemble .assembleModelInheritance(DefaultModelInheritanceAssembler.java:61) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(De aultMavenProjectBuilder.java:851) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromReposit ry(DefaultMavenProjectBuilder.java:252) at org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersi n(DefaultPluginManager.java:265) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(D faultPluginManager.java:197) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPlu inManager.java:176) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(Def ultLifecycleExecutor.java:1275) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLife ycle(DefaultLifecycleExecutor.java:1239) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecyc eMappings(DefaultLifecycleExecutor.java:1005) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defa ltLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHa dleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegme ts(DefaultLifecycleExecutor.java:292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultL fecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl java:59) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce sorImpl.java:39) at java.lang.reflect.Method.invoke(Method.java:612) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430 at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 1 second [INFO] Finished at: Tue Mar 10 17:49:51 CET 2009 [INFO] Final Memory: 5M/1024M [INFO] -- 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-4081) Subtle case: Avoid resolving artifacts from outside the reactor for plugins and extensions whose projects are inside the reactor
[ http://jira.codehaus.org/browse/MNG-4081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168797#action_168797 ] John Casey commented on MNG-4081: - Looking at DefaultExtensionManager.addExtension(..), extensions aren't even looked for in the current reactor. I suppose this makes sense, given how early extensions are added to the build runtime. Subtle case: Avoid resolving artifacts from outside the reactor for plugins and extensions whose projects are inside the reactor Key: MNG-4081 URL: http://jira.codehaus.org/browse/MNG-4081 Project: Maven 2 Issue Type: Improvement Reporter: John Casey DefaultLifecycleExecutor.constructLifecycleMappings() can trigger the resolution of all the plugins declared in the project's build section. When this happens, even if those plugins are in the current reactor, *that version will not be used*. Instead, since those plugin artifacts haven't been built yet, the plugin will be resolved externally and bound into the plugin collector for later use. This means that even if the plugin itself isn't used until after it's build in the reactor, that version won't be used. I'm still investigating exactly how build extensions will interact with the reactor, but I suspect they cannot be available from the current reactor either, since build extensions are loaded up front and for the entire reactor at once. I'll post an update once I've explored that section of the code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4081) Subtle case: Avoid resolving artifacts from outside the reactor for plugins and extensions whose projects are inside the reactor
[ http://jira.codehaus.org/browse/MNG-4081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-4081: Affects Version/s: 2.1.0-M1 Fix Version/s: 2.x Subtle case: Avoid resolving artifacts from outside the reactor for plugins and extensions whose projects are inside the reactor Key: MNG-4081 URL: http://jira.codehaus.org/browse/MNG-4081 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.1.0-M1 Reporter: John Casey Fix For: 2.x DefaultLifecycleExecutor.constructLifecycleMappings() can trigger the resolution of all the plugins declared in the project's build section. When this happens, even if those plugins are in the current reactor, *that version will not be used*. Instead, since those plugin artifacts haven't been built yet, the plugin will be resolved externally and bound into the plugin collector for later use. This means that even if the plugin itself isn't used until after it's build in the reactor, that version won't be used. I'm still investigating exactly how build extensions will interact with the reactor, but I suspect they cannot be available from the current reactor either, since build extensions are loaded up front and for the entire reactor at once. I'll post an update once I've explored that section of the code. -- 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: (MNG-4075) Tone down warnings about reactor dependencies that don't have an associated file
[ http://jira.codehaus.org/browse/MNG-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-4075. --- Resolution: Fixed now output just a small one-liner warning in recognition of the dangers described in MNG-4081. If you use -X you'll see a fair amount more information, and it'll be a little more prominent. Tone down warnings about reactor dependencies that don't have an associated file Key: MNG-4075 URL: http://jira.codehaus.org/browse/MNG-4075 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.1.0 Reporter: John Casey Assignee: John Casey Fix For: 2.1.0 currently this is logged to the WARNING level, but it can be disquieting without causing any real problems. I'm not entirely sure how these messages come up during the clean phase, but at least in the CXF project, they definitely seem to. We should tone them down to the DEBUG log level for now, unless/until we can find a way of being certain they're going to cause a problem. -- 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: (MNG-4077) Review log level for VersionExpressionTransformation.transformVersions()
[
http://jira.codehaus.org/browse/MNG-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-4077.
---
Resolution: Fixed
this was move to the debug log-level.
Review log level for VersionExpressionTransformation.transformVersions()
Key: MNG-4077
URL: http://jira.codehaus.org/browse/MNG-4077
Project: Maven 2
Issue Type: Task
Components: Artifacts and Repositories
Affects Versions: 2.1.0-RC1
Reporter: Benjamin Bentmann
Assignee: John Casey
Priority: Trivial
Fix For: 2.1.0
The new transformer producer info logs like
{noformat}
[INFO] Artifact: org.apache.maven:maven-plugin-api:jar:2.0.4 does not have
project-builder metadata (ProjectBuilderConfiguration) associated with it.
Cannot access CLI properties for version transformation.
{noformat}
for any artifact created via the {{DefaultArtifactFactory}} and passed to the
installer/deployer.
This affects the Install Plugin, the Deploy Plugin and the Invoker Plugin.
For {{invoker:install}}, this causes massive info logs. Probably make this
log at debug instead?
--
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: (MSITE-275) site:stage for multimodule project creates wrong links
[
http://jira.codehaus.org/browse/MSITE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hugo Palma updated MSITE-275:
-
Attachment: MSITE-275-UseCase2.zip
When i run mvn site:stage the links are generated all wrong
site:stage for multimodule project creates wrong links
---
Key: MSITE-275
URL: http://jira.codehaus.org/browse/MSITE-275
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: multi module
Affects Versions: 2.0-beta-6
Environment: Debian testing,maven 2.0.8
Reporter: Roman Kitko
Fix For: 2.0
Attachments: MSITE-275-UseCase2.zip, MSITE-275.zip
For multimodule project when I exec 'mvn site:stage
-DstagingDirectory=MY_STAGING_DIR', created links in index.html are hardcoded
with path to project dir :
a
href=../../mnt/data/projects/vpda/current/workspace/ws/../../../../../../localhost/home/vpda/site/org.vpda/0.02.01-SNAPSHOTvpda-common/a
When I exec mvn site, then index.html in target/site is correctly generated.
There is workaround : use site-deploy and specify some property that is
resolved in pom.xml as your deploy site url :
mvn site-deploy -Dvpda.deployUrlSite=file:///home/rki/tmp/XXX
My site.xml :
project name=vpda-site
bannerLeft
nameView providers driven applications/name
srcimages/vpda.jpg/src
hrefhttp://vpda.org//href
/bannerLeft
body
links
item name=Home href=index.html /
item name=Maven 2 href=http://maven.apache.org//
/links
menu name=VPDA inherit=none
item name=Introduction href=introduction.html/
item name=Usage href=usage.html/
item name=Downloads
href=../${project.artifactId}-${project.version}.zip/
/menu
menu ref=modules/
menu ref=reports/
menu ref=parent/
/body
/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
[jira] Issue Comment Edited: (MSITE-275) site:stage for multimodule project creates wrong links
[
http://jira.codehaus.org/browse/MSITE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=168803#action_168803
]
Hugo Palma edited comment on MSITE-275 at 3/10/09 1:06 PM:
---
As it turns out, it doesn't even take a multi-module project.
This simple test case that i've attached also reproduces the problem.
Just run site:stage.
was (Author: hpalma):
When i run mvn site:stage the links are generated all wrong
site:stage for multimodule project creates wrong links
---
Key: MSITE-275
URL: http://jira.codehaus.org/browse/MSITE-275
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: multi module
Affects Versions: 2.0-beta-6
Environment: Debian testing,maven 2.0.8
Reporter: Roman Kitko
Fix For: 2.0
Attachments: MSITE-275-UseCase2.zip, MSITE-275.zip
For multimodule project when I exec 'mvn site:stage
-DstagingDirectory=MY_STAGING_DIR', created links in index.html are hardcoded
with path to project dir :
a
href=../../mnt/data/projects/vpda/current/workspace/ws/../../../../../../localhost/home/vpda/site/org.vpda/0.02.01-SNAPSHOTvpda-common/a
When I exec mvn site, then index.html in target/site is correctly generated.
There is workaround : use site-deploy and specify some property that is
resolved in pom.xml as your deploy site url :
mvn site-deploy -Dvpda.deployUrlSite=file:///home/rki/tmp/XXX
My site.xml :
project name=vpda-site
bannerLeft
nameView providers driven applications/name
srcimages/vpda.jpg/src
hrefhttp://vpda.org//href
/bannerLeft
body
links
item name=Home href=index.html /
item name=Maven 2 href=http://maven.apache.org//
/links
menu name=VPDA inherit=none
item name=Introduction href=introduction.html/
item name=Usage href=usage.html/
item name=Downloads
href=../${project.artifactId}-${project.version}.zip/
/menu
menu ref=modules/
menu ref=reports/
menu ref=parent/
/body
/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
[jira] Updated: (MNG-4079) Duplicate error messages
[ http://jira.codehaus.org/browse/MNG-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-4079: Affects Version/s: (was: 2.1.0-RC1) 2.1.0 Fix Version/s: 2.1.0 Duplicate error messages Key: MNG-4079 URL: http://jira.codehaus.org/browse/MNG-4079 Project: Maven 2 Issue Type: Bug Affects Versions: 2.1.0 Environment: Apache Maven 2.1.0 (r751709; 2009-03-09 16:35:14+0100) Java version: 1.4.2_17 Java home: C:\j2sdk1.4.2_17\jre Default locale: fr_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: Julien HENRY Priority: Minor Fix For: 2.1.0 Attachments: output.txt Very often with Maven the error messages are duplicated. For example deprecation warnings and compilation issues. I've attached an example with -e option. In my case I'm trying to build a project that requires JDK 1.5+ with JDK 1.4. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4077) Review log level for VersionExpressionTransformation.transformVersions()
[
http://jira.codehaus.org/browse/MNG-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MNG-4077:
Affects Version/s: (was: 2.1.0-RC1)
2.1.0
Review log level for VersionExpressionTransformation.transformVersions()
Key: MNG-4077
URL: http://jira.codehaus.org/browse/MNG-4077
Project: Maven 2
Issue Type: Task
Components: Artifacts and Repositories
Affects Versions: 2.1.0
Reporter: Benjamin Bentmann
Assignee: John Casey
Priority: Trivial
Fix For: 2.1.0
The new transformer producer info logs like
{noformat}
[INFO] Artifact: org.apache.maven:maven-plugin-api:jar:2.0.4 does not have
project-builder metadata (ProjectBuilderConfiguration) associated with it.
Cannot access CLI properties for version transformation.
{noformat}
for any artifact created via the {{DefaultArtifactFactory}} and passed to the
installer/deployer.
This affects the Install Plugin, the Deploy Plugin and the Invoker Plugin.
For {{invoker:install}}, this causes massive info logs. Probably make this
log at debug instead?
--
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: (MNG-3947) [regression] Configuration of plugin execution with id default pollutes configuration of standalone plugin execution from CLI
[
http://jira.codehaus.org/browse/MNG-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-3947.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: (was: 3.0-alpha-4)
3.0-alpha-3
Fixed in [r752224|http://svn.eu.apache.org/viewvc?view=revrevision=752224].
[regression] Configuration of plugin execution with id default pollutes
configuration of standalone plugin execution from CLI
---
Key: MNG-3947
URL: http://jira.codehaus.org/browse/MNG-3947
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.0-alpha-1
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
Priority: Minor
Fix For: 3.0-alpha-3
Something like
{code:xml}
execution
iddefault/id
configuration
foobar/foo
/configuration
/execution
{code}
affects the configuration of standalone goal executions from the CLI, e.g.
{{prefix:goal}} will pick up {{foo=bar}} from the configuration for the POM
execution. In contrast, Maven 2.x configures CLI goals only from
{{plugin/configuration}} and never from {{execution/configuration}}.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3760) Support property ${baseurl} to get RFC-compliant URL of project base directory
[
http://jira.codehaus.org/browse/MNG-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-3760:
---
Fix Version/s: 3.0-alpha-3
Merged to 3.x in
[r752241|http://svn.eu.apache.org/viewvc?view=revrevision=752241].
Support property ${baseurl} to get RFC-compliant URL of project base directory
--
Key: MNG-3760
URL: http://jira.codehaus.org/browse/MNG-3760
Project: Maven 2
Issue Type: New Feature
Components: Artifacts and Repositories, Inheritance and Interpolation
Affects Versions: 2.0.9
Reporter: Benjamin Bentmann
Assignee: Brett Porter
Priority: Minor
Fix For: 2.1.0, 3.0-alpha-3
If people currently need a URL to their project base directory or any file
within, they need to write {{file://$\{basedir}}/}}. The problem about this
approach is that it doesn't deliver a [RFC-compliant
URL|http://tools.ietf.org/html/rfc3986] since characters are not properly
percent-encoded. Also, the exact number of slashes between {{file:}} and
{{${basedir}}} depends on the OS (e.g. {{file:///C:/user/}} and
{{file:///home/user}}, Unix paths have a leading slash by themselves, Windows
not). This makes it currently impossible to configure plugins that expect a
URL as input and do strict URL parsing.
For this reason, I suggest to support an additional property {{${baseurl}}}
with the value
{code:java}
baseurl = new File( basedir ).toURI().toString()
{code}
for POM interpolation.
Some day, when Maven/Wagon itself handle percent-encoded {{file:}} URLs
correctly (WAGON-111), this property could also be used to define local
deployment repos like we commonly use for testing.
--
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: (MAVENUPLOAD-2388) Jacex Project
Jacex Project - Key: MAVENUPLOAD-2388 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2388 Project: Maven Upload Requests Issue Type: Wish Reporter: Alexey Noskov org.jacex,mavens...@web.sourceforge.net:/home/groups/j/ja/jacex/htdocs/maven,rsync_ssh,Alexey Noskov,alexey.nos...@gmail.com,, -- 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: (MAVENUPLOAD-2389) File doesn't sync
File doesn't sync - Key: MAVENUPLOAD-2389 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2389 Project: Maven Upload Requests Issue Type: Bug Reporter: Ivan Chang I made a mistake that I upload wrong files.So I tried to re-post it to overwrite with the right release , but it didn't sync to http://repo1.maven.org/maven2/org/zkoss/zk/zk/3.6.0/ . So how should I do ? Can I delete this folder and re-upload 3.6.0? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
