[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
[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] 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=rev&revision=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] 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=rev&revision=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}
>
> default
>
> bar
>
>
> {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
> {{/}} and never from {{/}}.
--
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] 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] 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-tabpanel&focusedCommentId=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 :
> href="../../mnt/data/projects/vpda/current/workspace/ws/../../../../../../localhost/home/vpda/site/org.vpda/0.02.01-SNAPSHOT">vpda-common
> 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 :
>
>
> View providers driven applications
> images/vpda.jpg
> http://vpda.org/
>
>
>
>
> http://maven.apache.org/"/>
>
>
>
>
>
>href="../${project.artifactId}-${project.version}.zip"/>
>
>
>
>
>
>
>
--
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 :
> href="../../mnt/data/projects/vpda/current/workspace/ws/../../../../../../localhost/home/vpda/site/org.vpda/0.02.01-SNAPSHOT">vpda-common
> 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 :
>
>
> View providers driven applications
> images/vpda.jpg
> http://vpda.org/
>
>
>
>
> http://maven.apache.org/"/>
>
>
>
>
>
>href="../${project.artifactId}-${project.version}.zip"/>
>
>
>
>
>
>
>
--
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] 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] 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] 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-tabpanel&focusedCommentId=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] 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] 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] 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-tabpanel&focusedCommentId=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] 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] 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] 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] Commented: (MASSEMBLY-398) ${artifactId}.${extension} 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-tabpanel&focusedCommentId=168780#action_168780
]
John Casey commented on MASSEMBLY-398:
--
Try ${artifact.artifactId} and ${artifact.extension} instead...that should work.
> ${artifactId}.${extension} 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:
> ${artifactId}.${extension}
> 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.
>
>
> zip
>
> false
>
>
>
>
> ../../kiosk/presentation-war/src/main/webapp/images
>
> /images/
>
>
> /images/
>
>
>
>
> /images/
>
>
> ${artifactId}.${extension}
> false
> runtime
>
>
> commons-logging:commons-logging
> org.apache.log4j:log4j
> idl:idl
> jacorb:jacorb
> xerces:xercesImpl
> xml-apis:xml-apis
>
>
>
>
>
>
>
--
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-tabpanel&focusedCommentId=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 :
> href="../../mnt/data/projects/vpda/current/workspace/ws/../../../../../../localhost/home/vpda/site/org.vpda/0.02.01-SNAPSHOT">vpda-common
> 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 :
>
>
> View providers driven applications
> images/vpda.jpg
> http://vpda.org/
>
>
>
>
> http://maven.apache.org/"/>
>
>
>
>
>
>href="../${project.artifactId}-${project.version}.zip"/>
>
>
>
>
>
>
>
--
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) ${artifactId}.${extension} 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-tabpanel&focusedCommentId=168778#action_168778
]
Usman Muhammed Syed commented on MASSEMBLY-398:
---
Is there a newer syntax?
> ${artifactId}.${extension} 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:
> ${artifactId}.${extension}
> 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.
>
>
> zip
>
> false
>
>
>
>
> ../../kiosk/presentation-war/src/main/webapp/images
>
> /images/
>
>
> /images/
>
>
>
>
> /images/
>
>
> ${artifactId}.${extension}
> false
> runtime
>
>
> commons-logging:commons-logging
> org.apache.log4j:log4j
> idl:idl
> jacorb:jacorb
> xerces:xercesImpl
> xml-apis:xml-apis
>
>
>
>
>
>
>
--
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
[
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
> ---
>
> 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}
> what
>
> {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] Created: (MASSEMBLY-398) ${artifactId}.${extension} is working on Maven 2.0.4 (provided with Maestro 1.1) but not working with Maven 2.0.10
${artifactId}.${extension} 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:
${artifactId}.${extension}
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.
zip
false
../../kiosk/presentation-war/src/main/webapp/images
/images/
/images/
/images/
${artifactId}.${extension}
false
runtime
commons-logging:commons-logging
org.apache.log4j:log4j
idl:idl
jacorb:jacorb
xerces:xercesImpl
xml-apis:xml-apis
--
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] 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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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: (MSITE-389) Maven's CSS shows ugly green shadows
[ http://jira.codehaus.org/browse/MSITE-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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: (MEAR-81) Suppressing application.xml creation (and inclusion) completely
[ http://jira.codehaus.org/browse/MEAR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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 :
> href="../../mnt/data/projects/vpda/current/workspace/ws/../../../../../../localhost/home/vpda/site/org.vpda/0.02.01-SNAPSHOT">vpda-common
> 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 :
>
>
> View providers driven applications
> images/vpda.jpg
> http://vpda.org/
>
>
>
>
> http://maven.apache.org/"/>
>
>
>
>
>
>href="../${project.artifactId}-${project.version}.zip"/>
>
>
>
>
>
>
>
--
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-tabpanel&focusedCommentId=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] 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] 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-tabpanel&focusedCommentId=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] 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] 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 org.apache.maven.plugins maven-surefire-plugin 2.4.3 -Xms500M -Xmx500M -Xmn250M false 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: (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] 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: (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=rev&revision=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] 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] 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: (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] 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] 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] 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] Commented: (DOXIA-294) Apt verbatim box not correct
[ http://jira.codehaus.org/browse/DOXIA-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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> > org.apache.maven.doxia > doxia-maven-plugin >1.0 > > 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 Verbatime. 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: (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: http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 main main 0 org.eclipse.core runtime 3.4.0 OurRepository our repository file:///O|/maven-repository true daily fail false 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): http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 org.eclipse osgi 3.4.2 OurRepository our repository file:///O|/maven-repository http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 org.eclipse.core runtime 3.4.0 org.eclipse osgi [3.2.0,4.0.0) OurRepository our repository file:///O:|/maven-repository -- 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
