[jira] Created: (MASSEMBLY-296) XML DTD assembly.xsd is obsolete
XML DTD assembly.xsd is obsolete Key: MASSEMBLY-296 URL: http://jira.codehaus.org/browse/MASSEMBLY-296 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Environment: Files obsolete on http server Reporter: Jean-Paul GUIGUI Priority: Minor The DTD file for the assembly descriptor is not correct. The http://maven.apache.org/xsd/assembly-1.1.0-SNAPSHOT.xsd and http://maven.apache.org/xsd/assembly-1.0.0.xsd are dating from 16-Dec-2006 and are not up to date. For instance the element is missing from these DTD files. It's not convenient when editing the descriptor with an XMLEditor, we are not able to know the new options and completion. -- 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: (MRELEASE-273) Regression: NullPointerException at end of standalone "release:perform"
[
http://jira.codehaus.org/browse/MRELEASE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126913
]
Tom DeWire commented on MRELEASE-273:
-
We're having quite a bit of trouble with this as well. It is preventing our
build console from ever registering a successful build, which is causing a
cascade of secondary problems with getting a release out. Definitely with a
vote...
> Regression: NullPointerException at end of standalone "release:perform"
> ---
>
> Key: MRELEASE-273
> URL: http://jira.codehaus.org/browse/MRELEASE-273
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-6
> Environment: Maven 2.0.7, maven-release-plugin 2.0-alpha-6
>Reporter: Max Bowsher
>Priority: Blocker
>
> I executed "mvn release:perform -DconnectionUrl=scm:svn:..". The actual
> performing succeeded, but then the plugin failed with a NullPointerException
> - it seems that the plugin attempts to unconditionally run code analogous to
> "mvn release:clean", but this is inappropriate because release:perform is not
> supposed to require a project to be able to run.
> Output:
> {noformat}
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 28 seconds
> [INFO] Finished at: Thu Aug 02 12:53:49 BST 2007
> [INFO] Final Memory: 13M/23M
> [INFO]
>
> [INFO] Cleaning up after release...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [DEBUG] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.shared.release.util.ReleaseUtil.getReleasePom(ReleaseUtil.java:73)
> at
> org.apache.maven.shared.release.util.ReleaseUtil.getStandardPom(ReleaseUtil.java:61)
> at
> org.apache.maven.shared.release.phase.AbstractBackupPomsPhase.getPomBackup(AbstractBackupPomsPhase.java:37)
> at
> org.apache.maven.shared.release.phase.AbstractBackupPomsPhase.deletePomBackup(AbstractBackupPomsPhase.java:51)
> at
> org.apache.maven.shared.release.phase.CreateBackupPomsPhase.clean(CreateBackupPomsPhase.java:70)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.clean(DefaultReleaseManager.java:427)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:324)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:267)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:260)
> at
> org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:102)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> 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]
> -
[jira] Updated: (DOXIA-230) Review Doxia generation for Apt and Docbook
[ http://jira.codehaus.org/browse/DOXIA-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated DOXIA-230: -- Fix Version/s: 1.0-beta-1 > Review Doxia generation for Apt and Docbook > --- > > Key: DOXIA-230 > URL: http://jira.codehaus.org/browse/DOXIA-230 > Project: Maven Doxia > Issue Type: Bug > Components: Doxia Tools >Reporter: Vincent Siveton > Fix For: 1.0-beta-1 > > > Doxia converter tests failed when converting Apt => xhtml => apt. See the > TODO in ConverterTest class. > Same for docbook. -- 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-230) Review Doxia generation for Apt and Docbook
Review Doxia generation for Apt and Docbook --- Key: DOXIA-230 URL: http://jira.codehaus.org/browse/DOXIA-230 Project: Maven Doxia Issue Type: Bug Components: Doxia Tools Reporter: Vincent Siveton Fix For: 1.0-beta-1 Doxia converter tests failed when converting Apt => xhtml => apt. See the TODO in ConverterTest class. Same for docbook. -- 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: (MCHANGELOG-82) Filter changelog to report on specific folders
Filter changelog to report on specific folders -- Key: MCHANGELOG-82 URL: http://jira.codehaus.org/browse/MCHANGELOG-82 Project: Maven 2.x Changelog Plugin Issue Type: Task Environment: Red Hat 4; Windows XP Reporter: Samatha Sung Priority: Minor Hi, If I understand it correctly, Changelog reports at the module level. I would like to know if any current features will allow me to specify certain folders/files of interest. Our module has over 30 folders, but we only care when activity occurs on 2 of them. Our date range is set to 30 days so our report can be very long. It would be good if we could filter our report so we would not have to scroll pages looking for files that might not have been modified. Thank you in advance for your help. Sam- -- 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-2744) checksum comparison should be case-insensitive
[ http://jira.codehaus.org/browse/MNG-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-2744: --- Attachment: mng-2744-it.patch bq. we all know that no one will ever come along and fix that issue ... bq. would you still make an IT for it? Pretty please? Could I have said "no" to a kind guy ;-) ? OK, so here's my first try at a core-it, seems to happily fail right now. > checksum comparison should be case-insensitive > -- > > Key: MNG-2744 > URL: http://jira.codehaus.org/browse/MNG-2744 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Ian Springer > Fix For: 2.0.9 > > Attachments: case-insensitive-checksums-2.0.x.patch, > case-insensitive-checksums-2.1.x.patch, > case-insensitive-checksums-2.1.x.patch, mng-2744-it.patch > > > Validation of MD5 and SHA1 checksums should be case-insensitive (since the > individual characters represent hexadecimal digits). For example: > [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = > '9657ed010cea89caa1e35ae326dfccf28ea007f5'; remote > = '9657ED010CEA89CAA1E35AE326DFCCF28EA007F5' - RETRYING -- 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-3455) Expose Model From Toolchain Interface
[ http://jira.codehaus.org/browse/MNG-3455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Isbell closed MNG-3455. - Resolution: Won't Fix As suggested, adding my extension dependency using the provided scope solves the class casting problem, so this issue is no longer relevant. org.apache.maven.dotnet maven-dotnet-toolchain 0.16-incubating-SNAPSHOT provided > Expose Model From Toolchain Interface > - > > Key: MNG-3455 > URL: http://jira.codehaus.org/browse/MNG-3455 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.0.9 >Reporter: Shane Isbell >Assignee: Milos Kleint >Priority: Minor > Attachments: toolchain-2.0.9.patch, toolchain-2.1.patch > > > I need to expose the model from the toolchain interface for the dotnet > toolchain. This is to get around the problem of not being able to cast to a > subclass when using an extension. -- 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-471) Infinite loop when ERROR is detected
Infinite loop when ERROR is detected Key: SUREFIRE-471 URL: http://jira.codehaus.org/browse/SUREFIRE-471 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.4.2 Environment: Windows XP, Maven 2.0.8, Spring 1.2.8, JDK 1.6 Reporter: Paul Benedict I can't supply a test case, but I will try to describe in detail exactly what occurs so you can reproduce it: My hibernate integration tests are in a separate profile named "itest". My integration tests load Hibernate via Spring. I had a Hibernate mapping configuration error in which my element was missing its element. Now usually a mapping error causes the testing to immediately quit, but here it didn't. Instead it reported the error and reran the whole phase again, and again, etc. My debug output: [DEBUG] Using JVM: D:\jdk1.6.0_01\jre\bin\java [INFO] Surefire report directory: D:\workspace\myproject\target\surefire-reports Forking command line: cmd.exe /X /C '"D:\jdk1.6.0_01\jre\bin\java -jar c:\temp\surefirebooter4340.jar c:\temp\surefire4338tmp c:\temp\surefire4339tmp"' .. test output. 31876 [main] ERROR org.hibernate.util.XMLHelper - Error parsing XML: XML InputStream(23) The content of element type "set" must match "(meta*,subselect?,cache?,synchronize*,comment?,key,(element|one-to-many|many-to-many|composite-element|many-to-any),loader?,sql-insert?,sql-update?,sql-delete?,sql-delete-all?,filter*)" .. test output.. ..repeat. -- 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-295) Repository assembly contains local metadata
Repository assembly contains local metadata --- Key: MASSEMBLY-295 URL: http://jira.codehaus.org/browse/MASSEMBLY-295 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Wendy Smoak When using the assembly plugin to construct a remote repository as described on http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html, the repository contains "local" metadata files such as maven-metadata-central.xml. The remote repository format should only contain maven-metadata.xml files. Need to re-test with 2.2-beta-2 to confirm. -- 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: (MINVOKER-25) invoke postBuildHookScript even if build failed
invoke postBuildHookScript even if build failed --- Key: MINVOKER-25 URL: http://jira.codehaus.org/browse/MINVOKER-25 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Affects Versions: 1.2 Reporter: Mykola Nikishov Priority: Critical Attachments: 0001-enable-negative-tests.patch I develop a plugin which is ok to break a build. Current workflow using maven-invoker-plugin looks like: - if my plug-in works as expected ;-) it breaks an IT build during integration-test phase - the MojoFailureException is thrown - the maven-invoker-plugin reports that build failed - a script defined in postBuildHookScript is never used As a result I have a false alarm - a broken build when everything is ok. I would like to have an opportunity to decide from a postBuildHookScript whether a build was successful or not. I've implemented desired functionality and attached a patch against trunk/[EMAIL PROTECTED] -- 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-2972) Ignores version of plugin dependency specified in my pom
[ http://jira.codehaus.org/browse/MNG-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2972. -- Resolution: Fixed This is confirmed fixed in 2.0.9, an additional IT was created to be sure. > Ignores version of plugin dependency specified in my pom > > > Key: MNG-2972 > URL: http://jira.codehaus.org/browse/MNG-2972 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: maven 2.0.6, java version "1.5.0_07" >Reporter: Derek Alexander >Assignee: Brian Fox >Priority: Critical > Fix For: 2.0.9 > > > xmlbeans-maven-plugin declares a dependency on xmlbeans-2.0.0 > I want to use xmlbeans-2.2.0 > So in my pom I put: > > org.codehaus.mojo > xmlbeans-maven-plugin > > > > xmlbeans > > > > > ... > > > > xmlbeans > xbean > 2.2.0 > > >But it still downloads 2.0.0. (as well as 2.2.0). Haven't got a clue which it > is using as it doesn't seem to output stuff like that. Couldn't see a verbose > or debug switch mentioned in the docs. Anyway I think it is still using 2.0.0. > Seems like I'm not the first to experience this: > http://www.nabble.com/Override-plugin-dependency-version-tf2357806s177.html#a6568092 > Apparently this should be possible: http://maven.apache.org/pom.html#plugins > "dependencies: Dependencies are seen a lot within the POM, and are an element > under all plugins element blocks. The dependencies have the same structure > and function as under that base build. The major difference in this case is > that instead of applying as dependencies of the project, they now apply as > dependencies of the plugin that they are under. The power of this is to alter > the dependency list of a plugin, perhaps by removing an unused runtime > dependency via exclusions, or by altering the version of a required > dpendency. See above under Dependencies for more information." -- 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-2848) Environment variables in profile activation not working
[
http://jira.codehaus.org/browse/MNG-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-2848.
---
Assignee: John Casey (was: Vincent Siveton)
Resolution: Fixed
Looks like the system-property-setting has been reinstated, and the execution
properties are still setup and used internally as specified in the patch. This
is probably the best we can expect for now, unless/until we find a way to
control the way plugins use (and more importantly, pass on to their delegates)
the system properties.
I'm closing this issue. We can open a new one later if we need to fine-tune
this behavior further.
> Environment variables in profile activation not working
> ---
>
> Key: MNG-2848
> URL: http://jira.codehaus.org/browse/MNG-2848
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.4, 2.0.5
> Environment: Windows XP Professional, JDK 1.5
>Reporter: Muhammad Alsebaey
>Assignee: John Casey
> Fix For: 2.0.9
>
> Attachments: MNG-2848.patch
>
>
> When using an environment variable as a profile activation variable, it
> doesnt work, using either env.X or ${env.X} doesnt work.
> I found the same issue on the forums unresolved.
> http://www.nabble.com/profile-activation-based-on-environment-variables-tf2585492s177.html#a7208580
> Basically, the following doesnt work, where FOO is a windows environment
> variable (like PATH for example) :
> {code:xml}
>
> haroon-workstation
>
>
> env.FOO
> foo
>
>
> ...
>
> {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] Work started: (MNG-2972) Ignores version of plugin dependency specified in my pom
[ http://jira.codehaus.org/browse/MNG-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-2972 started by Brian Fox. > Ignores version of plugin dependency specified in my pom > > > Key: MNG-2972 > URL: http://jira.codehaus.org/browse/MNG-2972 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: maven 2.0.6, java version "1.5.0_07" >Reporter: Derek Alexander >Assignee: Brian Fox >Priority: Critical > Fix For: 2.0.9 > > > xmlbeans-maven-plugin declares a dependency on xmlbeans-2.0.0 > I want to use xmlbeans-2.2.0 > So in my pom I put: > > org.codehaus.mojo > xmlbeans-maven-plugin > > > > xmlbeans > > > > > ... > > > > xmlbeans > xbean > 2.2.0 > > >But it still downloads 2.0.0. (as well as 2.2.0). Haven't got a clue which it > is using as it doesn't seem to output stuff like that. Couldn't see a verbose > or debug switch mentioned in the docs. Anyway I think it is still using 2.0.0. > Seems like I'm not the first to experience this: > http://www.nabble.com/Override-plugin-dependency-version-tf2357806s177.html#a6568092 > Apparently this should be possible: http://maven.apache.org/pom.html#plugins > "dependencies: Dependencies are seen a lot within the POM, and are an element > under all plugins element blocks. The dependencies have the same structure > and function as under that base build. The major difference in this case is > that instead of applying as dependencies of the project, they now apply as > dependencies of the plugin that they are under. The power of this is to alter > the dependency list of a plugin, perhaps by removing an unused runtime > dependency via exclusions, or by altering the version of a required > dpendency. See above under Dependencies for more information." -- 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-1832) built-in property containing current timestamp
[ http://jira.codehaus.org/browse/MNG-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126893 ] Paul Benedict commented on MNG-1832: Unfortunately, the buildnumber plugin works only with SVN. Maven supports a greater breadth of SCM implementations, which I believe should be considered here. > built-in property containing current timestamp > -- > > Key: MNG-1832 > URL: http://jira.codehaus.org/browse/MNG-1832 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Michal Stochmialek > Attachments: maven-archiver_pomDelete.patch, > maven-core_defaultExpressions.patch > > > Current timestamp (time or date) is often used while filtering resources or > creating manifest in ant builds. There is no equivalent in maven. -- 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-3455) Expose Model From Toolchain Interface
Expose Model From Toolchain Interface - Key: MNG-3455 URL: http://jira.codehaus.org/browse/MNG-3455 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.0.9 Reporter: Shane Isbell Priority: Minor Attachments: toolchain-2.0.9.patch, toolchain-2.1.patch I need to expose the model from the toolchain interface for the dotnet toolchain. This is to get around the problem of not being able to cast to a subclass when using an extension. -- 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: (JXR-58) Syntax highlighting broken for inline comments
Syntax highlighting broken for inline comments
--
Key: JXR-58
URL: http://jira.codehaus.org/browse/JXR-58
Project: Maven JXR
Issue Type: Bug
Components: jxr
Affects Versions: 2.1
Reporter: Lukas Theussl
For instance, for the line
{code}
out.write( text, /*preserveSpace*/ false );
{code}
the whole rest of the line after the comment will also be highlighted in green,
where only the comment should be.
--
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-3244) inherited site url not properly handling parameters
[
http://jira.codehaus.org/browse/MNG-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-3244:
---
Fix Version/s: (was: 2.0.9)
2.1-alpha-1
There seems to be no solution available to fix this in 2.0.x
> inherited site url not properly handling parameters
> ---
>
> Key: MNG-3244
> URL: http://jira.codehaus.org/browse/MNG-3244
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation, Sites & Reporting
>Affects Versions: 2.0.7
>Reporter: Jacob Robertson
>Assignee: Brian Fox
> Fix For: 2.1-alpha-1
>
> Attachments: fix-inherited-site-url.patch, guide-site.patch
>
>
> Here is the test case to reroduce this problem. Take the following two
> pom.xml files
>
>
> org.bar
> foo
> foo
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
>
> foo-site
> file://C:/Documents and
> Settings/foo/.m2/site/${project.artifactId}
>
>
>
>
>
> org.bar
> baz
> baz
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
> foo
> org.bar
> 1.0-SNAPSHOT
>
>
> And run the site-deploy goal on each. What you get under the site directory
> is this
> - site
> /- foo
> ---/site docs
> /- baz
> ---/- baz (extra directory)
> --- ---/site docs
> This is the simplest test case. In the case where I have a "grandparent"
> pom, the site directory uses the grandparent/parent as the path to the site,
> and doesn't use the actual artifactId of the artifact I'm creating the site
> for.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3284) Cached plugins are used, even when the specifically declared
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126889 ] brianfox edited comment on MNG-3284 at 3/11/08 1:48 PM: - Attaching an svn patch (MNG-3284.patch) by hand applying these changes to 2.0.9. The IT is already committed to the core-its but with this patch there is a crash: INFO] [ERROR] FATAL ERROR [INFO] [INFO] The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-plugin-plugin] was not found. [INFO] [INFO] Trace java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-plugin-plugin] was not found. at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:329) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:215) If you can fix the patch and reattach, then we can include for 2.0.9 was (Author: brianfox): Attaching an svn patch by hand applying these changes to 2.0.9. The IT is already committed to the core-its but with this patch there is a crash: INFO] [ERROR] FATAL ERROR [INFO] [INFO] The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-plugin-plugin] was not found. [INFO] [INFO] Trace java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-plugin-plugin] was not found. at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:329) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:215) If you can fix the patch and reattach, then we can include for 2.0.9 > Cached plugins are used, even when the specifically declared > - > > Key: MNG-3284 > URL: http://jira.codehaus.org/browse/MNG-3284 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: Nigel Magnay >Assignee: Brian Fox >Priority: Critical > Fix For: 2.0.9 > > Attachments: > 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, > 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, > maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, pluginbug.tar > > > In the attached project, you can build module A, then build module B, but the > top level aggregator project will fail at B. > The reason this happens is that maven seems to cache plugins. When B is built > in isolation, all things are fine - but when built in aggregation, one of the > plugins that it uses has already been instantiated, and so it uses that one. > This is incorrect, since the declared version is different in B, and is > relying on functionality not present in the version declared in A. > I have seen similar behaviour when a plugin relies on other plugins to get > work done - all of a sudden a build mysteriously stops working, because of a > completely unrelated plugin. > This is pretty painful because > - it's possible to get into a 'no solution', where one project relies on one > behaviour so can't upgrade, and one project relies on new behaviour, so can't > downgrade. > - you get builds that work OK in isolation, but not in their project. This is > bad. Also builds tied together in bigger aggregator projects can fail in > mysterious ways (mysterious because the user /has/ specified the plugin > version, and maven has ignored them, or it's a plugin dependency that got > there first) > - subtle build ordering changes can cause new failures (the example has B > depend on A - but the bug might only manifest itself in certain build orders > that change even when B and A don't). -- 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-3284) Cached plugins are used, even when the specifically declared
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3284: --- Attachment: MNG-3284.patch Attaching an svn patch by hand applying these changes to 2.0.9. The IT is already committed to the core-its but with this patch there is a crash: INFO] [ERROR] FATAL ERROR [INFO] [INFO] The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-plugin-plugin] was not found. [INFO] [INFO] Trace java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-plugin-plugin] was not found. at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:329) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:215) If you can fix the patch and reattach, then we can include for 2.0.9 > Cached plugins are used, even when the specifically declared > - > > Key: MNG-3284 > URL: http://jira.codehaus.org/browse/MNG-3284 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: Nigel Magnay >Assignee: Brian Fox >Priority: Critical > Fix For: 2.0.9 > > Attachments: > 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, > 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, > maven-bug-2.tar, MNG-3284.patch, mng3284-usingCachedPlugins.tar, pluginbug.tar > > > In the attached project, you can build module A, then build module B, but the > top level aggregator project will fail at B. > The reason this happens is that maven seems to cache plugins. When B is built > in isolation, all things are fine - but when built in aggregation, one of the > plugins that it uses has already been instantiated, and so it uses that one. > This is incorrect, since the declared version is different in B, and is > relying on functionality not present in the version declared in A. > I have seen similar behaviour when a plugin relies on other plugins to get > work done - all of a sudden a build mysteriously stops working, because of a > completely unrelated plugin. > This is pretty painful because > - it's possible to get into a 'no solution', where one project relies on one > behaviour so can't upgrade, and one project relies on new behaviour, so can't > downgrade. > - you get builds that work OK in isolation, but not in their project. This is > bad. Also builds tied together in bigger aggregator projects can fail in > mysterious ways (mysterious because the user /has/ specified the plugin > version, and maven has ignored them, or it's a plugin dependency that got > there first) > - subtle build ordering changes can cause new failures (the example has B > depend on A - but the bug might only manifest itself in certain build orders > that change even when B and A don't). -- 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-3284) Cached plugins are used, even when the specifically declared
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126881 ] Brian Fox commented on MNG-3284: patch doesn't work, it still has git junk in there. I'll try to do it manually > Cached plugins are used, even when the specifically declared > - > > Key: MNG-3284 > URL: http://jira.codehaus.org/browse/MNG-3284 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: Nigel Magnay >Assignee: Brian Fox >Priority: Critical > Fix For: 2.0.9 > > Attachments: > 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, > 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, > maven-bug-2.tar, mng3284-usingCachedPlugins.tar, pluginbug.tar > > > In the attached project, you can build module A, then build module B, but the > top level aggregator project will fail at B. > The reason this happens is that maven seems to cache plugins. When B is built > in isolation, all things are fine - but when built in aggregation, one of the > plugins that it uses has already been instantiated, and so it uses that one. > This is incorrect, since the declared version is different in B, and is > relying on functionality not present in the version declared in A. > I have seen similar behaviour when a plugin relies on other plugins to get > work done - all of a sudden a build mysteriously stops working, because of a > completely unrelated plugin. > This is pretty painful because > - it's possible to get into a 'no solution', where one project relies on one > behaviour so can't upgrade, and one project relies on new behaviour, so can't > downgrade. > - you get builds that work OK in isolation, but not in their project. This is > bad. Also builds tied together in bigger aggregator projects can fail in > mysterious ways (mysterious because the user /has/ specified the plugin > version, and maven has ignored them, or it's a plugin dependency that got > there first) > - subtle build ordering changes can cause new failures (the example has B > depend on A - but the bug might only manifest itself in certain build orders > that change even when B and A don't). -- 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-3284) Cached plugins are used, even when the specifically declared
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126871 ] Brian Fox commented on MNG-3284: perfect timing...i just finished merging in the IT. > Cached plugins are used, even when the specifically declared > - > > Key: MNG-3284 > URL: http://jira.codehaus.org/browse/MNG-3284 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: Nigel Magnay >Assignee: Brian Fox >Priority: Critical > Fix For: 2.0.9 > > Attachments: > 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, > 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, > maven-bug-2.tar, mng3284-usingCachedPlugins.tar, pluginbug.tar > > > In the attached project, you can build module A, then build module B, but the > top level aggregator project will fail at B. > The reason this happens is that maven seems to cache plugins. When B is built > in isolation, all things are fine - but when built in aggregation, one of the > plugins that it uses has already been instantiated, and so it uses that one. > This is incorrect, since the declared version is different in B, and is > relying on functionality not present in the version declared in A. > I have seen similar behaviour when a plugin relies on other plugins to get > work done - all of a sudden a build mysteriously stops working, because of a > completely unrelated plugin. > This is pretty painful because > - it's possible to get into a 'no solution', where one project relies on one > behaviour so can't upgrade, and one project relies on new behaviour, so can't > downgrade. > - you get builds that work OK in isolation, but not in their project. This is > bad. Also builds tied together in bigger aggregator projects can fail in > mysterious ways (mysterious because the user /has/ specified the plugin > version, and maven has ignored them, or it's a plugin dependency that got > there first) > - subtle build ordering changes can cause new failures (the example has B > depend on A - but the bug might only manifest itself in certain build orders > that change even when B and A don't). -- 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-3284) Cached plugins are used, even when the specifically declared
[ http://jira.codehaus.org/browse/MNG-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nigel Magnay updated MNG-3284: -- Attachment: 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn I think this should apply with SVN (if that's what you meant?) - it's the same patch but with --no-prefix; I'm told tortoiseSVN is a bit picky about patch formats.. > Cached plugins are used, even when the specifically declared > - > > Key: MNG-3284 > URL: http://jira.codehaus.org/browse/MNG-3284 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: Nigel Magnay >Assignee: Brian Fox >Priority: Critical > Fix For: 2.0.9 > > Attachments: > 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch, > 0001-Initial-fix-to-see-if-we-can-have-1-version-of-a-pl.patch.svn, > maven-bug-2.tar, mng3284-usingCachedPlugins.tar, pluginbug.tar > > > In the attached project, you can build module A, then build module B, but the > top level aggregator project will fail at B. > The reason this happens is that maven seems to cache plugins. When B is built > in isolation, all things are fine - but when built in aggregation, one of the > plugins that it uses has already been instantiated, and so it uses that one. > This is incorrect, since the declared version is different in B, and is > relying on functionality not present in the version declared in A. > I have seen similar behaviour when a plugin relies on other plugins to get > work done - all of a sudden a build mysteriously stops working, because of a > completely unrelated plugin. > This is pretty painful because > - it's possible to get into a 'no solution', where one project relies on one > behaviour so can't upgrade, and one project relies on new behaviour, so can't > downgrade. > - you get builds that work OK in isolation, but not in their project. This is > bad. Also builds tied together in bigger aggregator projects can fail in > mysterious ways (mysterious because the user /has/ specified the plugin > version, and maven has ignored them, or it's a plugin dependency that got > there first) > - subtle build ordering changes can cause new failures (the example has B > depend on A - but the bug might only manifest itself in certain build orders > that change even when B and A don't). -- 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-308) allow specifying an alternate repository URL on the command-line
allow specifying an alternate repository URL on the command-line Key: MSITE-308 URL: http://jira.codehaus.org/browse/MSITE-308 Project: Maven 2.x Site Plugin Issue Type: New Feature Components: site:deploy Environment: Linux (RHEL5), Java 1.5.0_15 Reporter: Benjamin Reed The maven deploy plugin lets me specify, eg, "-DaltDeploymentRepository=opennms-snapshots::default::file:///var/www/sites/opennms.org/site/repo/snapshots" on the command-line to override the default repository; it would be nice to be able to do the same thing for the site plugin. In the meantime it appears I should be able to use the staging url as a workaround. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-332) release:prepare fails if project does not contain directory src/main/java
release:prepare fails if project does not contain directory src/main/java - Key: MRELEASE-332 URL: http://jira.codehaus.org/browse/MRELEASE-332 Project: Maven 2.x Release Plugin Issue Type: Bug Environment: OSX 10.5, jdk 1.5, mvn 2.0.8 Reporter: Alphonse Bendt i'm trying to perform mvn release:prepare on a project that does not contain any java sources (e.g. the directory src/main/java does not exist). this seems to break build to break. if i add the directory it seems to work. > mvn release:prepare [...] [INFO] Tagging release with the label mps-webapplication-1.3... [INFO] Executing: svn --non-interactive copy --file /tmp/maven-scm-248675112.commit . svn://42.42.0.23/mps/tags/mps-webapplication-1.3 [INFO] Working directory: /Users/bendt/Projekte/MPS/mps-webapplication [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to tag SCM Provider message: The svn tag command failed. Command output: svn: Commit failed (details follow): svn: Directory '/Users/bendt/Projekte/MPS/mps-webapplication/src/main/java' is missing [INFO] [DEBUG] Trace org.apache.maven.BuildFailureException: Unable to tag SCM Provider message: The svn tag command failed. Command output: svn: Commit failed (details follow): svn: Directory '/Users/bendt/Projekte/MPS/mps-webapplication/src/main/java' is missing at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:560) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) 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) Caused by: org.apache.maven.plugin.MojoFailureException: Unable to tag SCM Provider message: The svn tag command failed. Command output: svn: Commit failed (details follow): svn: Directory '/Users/bendt/Projekte/MPS/mps-webapplication/src/main/java' is missing at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:144) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Tue Mar 11 16:29:29 CET 2008 [INFO] Final Memory: 6M/12M [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] Updated: (MJAR-69) When 'index' and 'addClasspath' are both true, plugin fails.
[
http://jira.codehaus.org/browse/MJAR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Aime updated MJAR-69:
Attachment: trace.log
Don't know if this is of any help, this is the full trace of the problem. The
module has no dependencies, besides one on junit marked as "provided", but it's
part of a large multimodule build where most of the other modules would enjoy
having an index
> When 'index' and 'addClasspath' are both true, plugin fails.
>
>
> Key: MJAR-69
> URL: http://jira.codehaus.org/browse/MJAR-69
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Anagnostopoulos Kostis
>Assignee: Olivier Lamy
> Attachments: trace.log
>
>
> When both the 'index' and 'addClasspath' are true, the plugin fails to create
> jar with the following msg:
> Embedded error: Problem creating jar: **/target/classes (Is a directory)
> A typical configuration to produce the error would be:
> {code:xml}
>
> maven-jar-plugin
>
>
> true
>
> true
>
>
>
> {code}
> The issue below (about including dependency files in index) claims that it
> introduced this bug:
> http://jira.codehaus.org/browse/MJAR-40
> I'm posting this issue so that to ensure that version 2.2-SNAPSHOT does not
> suffer from the same 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] Commented: (MJAR-69) When 'index' and 'addClasspath' are both true, plugin fails.
[
http://jira.codehaus.org/browse/MJAR-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126862
]
Andrea Aime commented on MJAR-69:
-
I'm trying to add index support to GeoTools build, using maven 2, and I'm
facing exactly the same problem.
> When 'index' and 'addClasspath' are both true, plugin fails.
>
>
> Key: MJAR-69
> URL: http://jira.codehaus.org/browse/MJAR-69
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Anagnostopoulos Kostis
>Assignee: Olivier Lamy
>
> When both the 'index' and 'addClasspath' are true, the plugin fails to create
> jar with the following msg:
> Embedded error: Problem creating jar: **/target/classes (Is a directory)
> A typical configuration to produce the error would be:
> {code:xml}
>
> maven-jar-plugin
>
>
> true
>
> true
>
>
>
> {code}
> The issue below (about including dependency files in index) claims that it
> introduced this bug:
> http://jira.codehaus.org/browse/MJAR-40
> I'm posting this issue so that to ensure that version 2.2-SNAPSHOT does not
> suffer from the same 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: (MJAR-101) excluding files from jar doesn't work completely well
excluding files from jar doesn't work completely well - Key: MJAR-101 URL: http://jira.codehaus.org/browse/MJAR-101 Project: Maven 2.x Jar Plugin Issue Type: Bug Affects Versions: 2.2 Environment: Windows XP, JDK 1.5 Reporter: Patrizio Munzi Attachments: mavenjarplugin.bug.tar.gz Maven Jar Plugin exclude feature seems not to work completely well. It actually excludes the specified files from the built jar but creates however the folders path into it. Here's my configuration: **/*.properties **/*.xml **/*.xsd Although all the specified files are actually excluded from the deployed jar, the directory paths of the excluded files are still created into the jar. I mean, if I have the following files under the resources directory: resources/log4j.properties resources/xml/file.xml resources/xml/schema/schema.xsd These files won't be included in the built jar, but I'll still have the following path into it: /xml/schema/ Find attached a simple project test case to reproduce the problem. - Extract it - Change to the main dir - run: mvn compile - run: mvn jar:jar -- 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-170) Confluence module should do something with non-doxia formatting
[ http://jira.codehaus.org/browse/DOXIA-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126855 ] Lukas Theussl commented on DOXIA-170: - strikethrough, underlined, superscript and subscript are now supported via SinkEventAttributes, see DOXIA-163. The confluence parser just needs to be adapted to emit the correct attributes. > Confluence module should do something with non-doxia formatting > --- > > Key: DOXIA-170 > URL: http://jira.codehaus.org/browse/DOXIA-170 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence >Affects Versions: 1.0-alpha-8 >Reporter: Dave Syer > Fix For: 2.0 > > > These wiki formats are not recognised ??citation?? -strikethrough- > +underlined+ ^superscript^ ~subscript~ -- 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-164) Add support for strikethroughs
[ http://jira.codehaus.org/browse/DOXIA-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-164. --- Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: (was: 2.0) 1.0-beta-1 Done in r635929, using DOXIA-204. > Add support for strikethroughs > -- > > Key: DOXIA-164 > URL: http://jira.codehaus.org/browse/DOXIA-164 > Project: Maven Doxia > Issue Type: Improvement > Components: Sink API >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Massol >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > -- 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-3139) The skin does not exist: Unable to determine the release version
[ http://jira.codehaus.org/browse/MNG-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126852 ] Matthew McCullough commented on MNG-3139: - This is really putting egg on the face of this particular maven plugin at a consulting client of mine. I'd like to cure it to get it back in good standing with my customer. Is it really as simple as me deploying to the central repo with -DupdateReleaseInfo=true? How do I get permissions to do that? I'll try to help and fix it (I'm not one of those open source whiners that wants other people to fix everything) but I need to be told how I get permissions to deploy to the central repo. Thanks in advance, Matthew McCullough [EMAIL PROTECTED] > The skin does not exist: Unable to determine the release version > > > Key: MNG-3139 > URL: http://jira.codehaus.org/browse/MNG-3139 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 2.0.7 >Reporter: eyal david >Assignee: Brett Porter > > hi I have problem generating site when im using the command mvn site > it performs all stagegs and when it came to site generation the message is > shown : > The skin does not exist: Unable to determine the release version > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.maven.skins > -DartifactId=maven > -default-skin \ > -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file > org.apache.maven.skins:maven-default-skin:jar:RELEASE > do u have an idea what is the problem ? > p.s the jar is registered in my local repository and in the remote repository > thank u -- 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-163) Add support for underscores
[ http://jira.codehaus.org/browse/DOXIA-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-163. --- Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: (was: 2.0) 1.0-beta-1 Done in r635929, using DOXIA-204. > Add support for underscores > --- > > Key: DOXIA-163 > URL: http://jira.codehaus.org/browse/DOXIA-163 > Project: Maven Doxia > Issue Type: Improvement > Components: Sink API >Affects Versions: 1.0-alpha-9 >Reporter: Vincent Massol >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > -- 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-294) Regression - dependency is skipped?
Regression - dependency is skipped?
---
Key: MASSEMBLY-294
URL: http://jira.codehaus.org/browse/MASSEMBLY-294
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Environment: Windows Vista Business, Sun JDK 5
Fedora Core 4, Sun JDK 5
Reporter: James Abley
There has been a regression between 2.2-beta-1, which was working for us, and
2.2-beta-2, which showed up the problem.
With 2.2-beta-1, we saw the following output.
[INFO] [assembly:directory-inline {execution: create-directories}]
[INFO] Reading assembly descriptor:
c:\Users\jabley\work\eclipse\workspaces\main\mpinstaller\mpinstaller-dependencies\src\main\assembly\dep.xml
[INFO] Processing DependencySet (output=/applications)
[INFO] Expanding:
C:\Users\jabley\.m2\repository\com\example\serviceoptimizer\serviceoptimizer-webapp\1.17-SNAPSHOT\serviceoptimizer-webapp-1.17-SNAPSHOT.war
into c:\Users\jabley\
AppData\Local\Temp\archived-file-set.770382062.tmp
[INFO] Processing DependencySet (output=/applications)
[INFO] Expanding:
C:\Users\jabley\.m2\repository\com\example\contentrepository\gwt-interface\1.16-SNAPSHOT\gwt-interface-1.16-SNAPSHOT.war
into c:\Users\jabley\AppData\Local\Temp\
archived-file-set.1945898079.tmp
[INFO] Processing DependencySet (output=/applications)
[INFO] Copying 1878 files to
c:\Users\jabley\work\eclipse\workspaces\main\mpinstaller\mpinstaller-dependencies\target\mpinstaller-dependencies.dir
[INFO] [antrun:run {execution: default}]
With 2.2-beta-2, we see the output below.
[INFO] [assembly:directory-inline {execution: create-directories}]
[INFO] Reading assembly descriptor: src/main/assembly/dep.xml
[INFO] Processing DependencySet (output=/applications)
[WARNING] Cannot include project artifact:
com.example.mpinstaller:mpinstaller-dependencies:pom:1.14-SNAPSHOT; it doesn't
have an associated file or directory.
[INFO] Processing DependencySet (output=/applications)
[WARNING] Cannot include project artifact:
com.example.mpinstaller:mpinstaller-dependencies:pom:1.14-SNAPSHOT; it doesn't
have an associated file or directory.
[WARNING] Archive:
C:\Users\jabley\.m2\repository\com\example\contentrepository\gwt-interface\1.16-SNAPSHOT\gwt-interface-1.16-SNAPSHOT.war
has already been added. Skipping.
[WARNING] Archive:
C:\Users\jabley\.m2\repository\com\example\serviceoptimizer\serviceoptimizer-webapp\1.17-SNAPSHOT\serviceoptimizer-webapp-1.17-SNAPSHOT.war
has already been add
ed. Skipping.
[INFO] Processing DependencySet (output=/applications)
[WARNING] Cannot include project artifact:
com.example.mpinstaller:mpinstaller-dependencies:pom:1.14-SNAPSHOT; it doesn't
have an associated file or directory.
[INFO] Copying files to
c:\Users\jabley\work\eclipse\workspaces\main\mpinstaller\mpinstaller-dependencies\target\mpinstaller-dependencies.dir
[INFO] [antrun:run {execution: default}]
I can provide debug output if you think it would be helpful, for both cases.
In my pom.xml
maven-assembly-plugin
2.2-beta-2
false
src/main/assembly/dep.xml
create-directories
compile
directory-inline
And in the assembly dep.xml mentioned in the pom.xml
mpinstaller-dependencies
zip
false
src/site
RELEASE-NOTES.txt
docs
serviceoptimizer-*war
ms.war
/applications
true
runtime
gwt-interface*war
mmi.war
/applications
true
runtime
jackrabbit*rar
jcr-repository.rar
/applications
false
runtime
Sorry for not being able to provide a test case. I'm not yet familiar with how
to write tests for maven. This ticket may be a duplicate of one of the existing
reported issues with dependency resolution in 2.2-beta-2, but I thought it
worth reporting (as much a reference for me as for the developers). I can at
least try out subsequent RC for the plugin and see if the problem is fixed.
--
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 JI
[jira] Commented: (MNG-1832) built-in property containing current timestamp
[
http://jira.codehaus.org/browse/MNG-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126846
]
Jorg Heymans commented on MNG-1832:
---
the buildnumber plugin exposes by default 2 properties: ${buildNumber} and
${timestamp}. You can use these anywere in the pom, for example pass them as a
parameter to a custom mojo that writes them to your custom property file if
you'ld like.
Alternatively just add them to the manifest with something like this:
maven-jar-plugin
${buildNumber}
${timestamp}
> built-in property containing current timestamp
> --
>
> Key: MNG-1832
> URL: http://jira.codehaus.org/browse/MNG-1832
> Project: Maven 2
> Issue Type: New Feature
>Affects Versions: 2.0.1
>Reporter: Michal Stochmialek
> Attachments: maven-archiver_pomDelete.patch,
> maven-core_defaultExpressions.patch
>
>
> Current timestamp (time or date) is often used while filtering resources or
> creating manifest in ant builds. There is no equivalent in maven.
--
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-1960) "net.sf.btb","[EMAIL PROTECTED]/home/groups/b/bt/btb/htdocs/m2repo","rsync_ssh","Jean-Philippe Gravel","[EMAIL PROTECTED]",,
"net.sf.btb","[EMAIL PROTECTED]/home/groups/b/bt/btb/htdocs/m2repo","rsync_ssh","Jean-Philippe Gravel","[EMAIL PROTECTED]",, - Key: MAVENUPLOAD-1960 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1960 Project: maven-upload-requests Issue Type: Bug Reporter: Jean-Philippe Gravel -- 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-3139) The skin does not exist: Unable to determine the release version
[ http://jira.codehaus.org/browse/MNG-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126838 ] Michael Phillimore-Brown commented on MNG-3139: --- For anyone else finding this error, see my comment in MNG-3139 as you may have the same issue, especially if upgrading from a previous version of Maven (2.0.5 -> 2.0.8 in my case). > The skin does not exist: Unable to determine the release version > > > Key: MNG-3139 > URL: http://jira.codehaus.org/browse/MNG-3139 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 2.0.7 >Reporter: eyal david >Assignee: Brett Porter > > hi I have problem generating site when im using the command mvn site > it performs all stagegs and when it came to site generation the message is > shown : > The skin does not exist: Unable to determine the release version > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.maven.skins > -DartifactId=maven > -default-skin \ > -Dversion=RELEASE -Dpackaging=jar -Dfile=/path/to/file > org.apache.maven.skins:maven-default-skin:jar:RELEASE > do u have an idea what is the problem ? > p.s the jar is registered in my local repository and in the remote repository > thank u -- 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-48) add reusable skin functionality and create skins default, stylus and classic
[ http://jira.codehaus.org/browse/MSITE-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126837 ] Michael Brown commented on MSITE-48: I also had this error, so to help anyone else looking for this my issue was that the maven-metadata-central.xml file in the repo under org/apache/maven/skins/maven-default-skin did not have the versioning element. This may have been as a result of some old cached file somewhere. The complete file (as per http://repo1.maven.org/maven2/org/apache/maven/skins/maven-default-skin/maven-metadata.xml) is below. org.apache.maven.skins maven-default-skin 1.0 1.0 1.0 20060507032433 See also MNG-3139 > add reusable skin functionality and create skins default, stylus and classic > > > Key: MSITE-48 > URL: http://jira.codehaus.org/browse/MSITE-48 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.0-beta-5 > > Original Estimate: 4 hours > Time Spent: 4 hours > Remaining Estimate: 0 minutes > > add the classic theme from m1, and perhaps a derivative of the new theme for > other sites -- 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
