[jira] (SUREFIRE-1138) Enabling reuseForks runs all tests in series on just one fork
[
https://jira.codehaus.org/browse/SUREFIRE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362163#comment-362163
]
Andreas Gudian commented on SUREFIRE-1138:
--
OK, I found out how the problem was introduced in 2.18. Fortunately, only the
JUnit4 provider is affected.
You can easily work-around the issue by using the more modern provider
implementation for JUnit 4.7+ by adding this to your pom:
{code}
org.apache.maven.plugins
maven-surefire-plugin
2.18.1
org.apache.maven.surefire
surefire-junit47
2.18.1
{code}
@[~tibor17], the issue was introduced in commit
4df65165717126c88569e1fa62b0ea30559cbfa3, which eagerly iterates over
TestsToRun in JUnit4Provider.createTestsDescription(). Can you remember why
that might be necessary? Could you please take a look? If you see a quick way
to fix it, feel free to grab the issue - otherwise let me know and I'll try it
myself... :)
> Enabling reuseForks runs all tests in series on just one fork
> -
>
> Key: SUREFIRE-1138
> URL: https://jira.codehaus.org/browse/SUREFIRE-1138
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.18, 2.18.1
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 19:44:56+1100)
> Java version: 1.7.0_17, vendor: Oracle Corporation
> Ubuntu 12.04 LTS
>Reporter: Matthew Provis
>Assignee: Andreas Gudian
> Attachments: test.zip
>
>
> When using Surefire >= 2.18, I've encountered a problem when setting
> {{forkCount > 1}} and {{reuseForks = true}}.
> Expected behaviour:
> Tests should run simultaneously, each on a separate fork.
> Actual behaviour:
> All tests run on just one fork, sequentially.
> Setting {{reuseForks = false}} gives the expected behaviour.
> Reverting to Surefire 2.17 also gives the expected behaviour.
> I've attached a project that demonstrates the issue. Here I've created two
> tests, each of which prints the fork number and sleeps for 5 seconds. The
> total run time is 10 seconds with Surefire 2.18 and 2.18.1, but 5 seconds
> with version 2.17.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSITE-492) publishDate position="bottom" doesn't work
[ https://jira.codehaus.org/browse/MSITE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSITE-492: - Fix Version/s: (was: 2.1.1) > publishDate position="bottom" doesn't work > -- > > Key: MSITE-492 > URL: https://jira.codehaus.org/browse/MSITE-492 > Project: Maven Site Plugin > Issue Type: Bug > Components: site descriptor >Affects Versions: 2.1.1 >Reporter: Aaron Digulla > > In the file "default-site.vm" is a call for the macro #publishDate with the > parameter "buttom" but this value isn't used in the macro code. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPA-82) Invalid jar in the central repository : sitemesh 2.2.1
[ https://jira.codehaus.org/browse/MPA-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPA-82: -- Fix Version/s: (was: 2006-q4) > Invalid jar in the central repository : sitemesh 2.2.1 > -- > > Key: MPA-82 > URL: https://jira.codehaus.org/browse/MPA-82 > Project: Maven Project Administration > Issue Type: Bug > Components: Repository Management >Affects Versions: 2006-q4 >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier > > The following jar seems to be corrupted : > http://repo1.maven.org/maven2/opensymphony/sitemesh/2.2.1/sitemesh-2.2.1.jar > Can it be fixed ? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPLUGIN-109) Misleading warning when creating a Maven plugin defining a custom packaging
[ https://jira.codehaus.org/browse/MPLUGIN-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPLUGIN-109: --- Fix Version/s: (was: 2.5) > Misleading warning when creating a Maven plugin defining a custom packaging > --- > > Key: MPLUGIN-109 > URL: https://jira.codehaus.org/browse/MPLUGIN-109 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Affects Versions: 2.4.1 >Reporter: Ludovic Claude >Assignee: John Casey >Priority: Minor > Attachments: console.log, test-custom-packaging.zip > > > When creating a custom packaging using the 2.4.1 version of the > maven-plugin-plugin, I'm getting the following warning message: > [INFO] Building foobar-maven-plugin > [INFO]task-segment: [install] > [INFO] > > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] Extractor for language: java found 0 mojo descriptors. > [INFO] Applying extractor for language: bsh > [INFO] Extractor for language: bsh found 0 mojo descriptors. > [WARNING] > [WARNING] > [WARNING] *** > [WARNING] Deprecation Alert: > [WARNING] No mojo descriptors were found in this project which has a > packaging type of maven-plugin. > [WARNING] In future versions of the plugin tools, this will fail the build. > [WARNING] If this project is an archetype, change the packaging type from > maven-plugin to maven-archetype. > [WARNING] > Indeed, my project contains no Mojos, only a plexus components.xml file. Now > if you try to enforce a rule that says that a maven-plugin must contain at > least one Mojo (see MPLUGIN-106), that's fine, but which packaging am I > supposed to use to create a plugin that defines a new packaging (here, the > foobar packaging) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-75) PMD plugin unable to exclude groovy-stub files.
[ https://jira.codehaus.org/browse/MPMD-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPMD-75: --- Fix Version/s: (was: 2.4) > PMD plugin unable to exclude groovy-stub files. > --- > > Key: MPMD-75 > URL: https://jira.codehaus.org/browse/MPMD-75 > Project: Maven PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 2.3 > Environment: windows xp, java 1.6.0_04, maven 2.0.8, groovy 1.5.1, > groovy-maven-plugin 1.0-beta3 >Reporter: Jonathan Baker >Assignee: Benjamin Bentmann > > When trying to run the pmd plugin to fail our build on a mixed java and > groovy project, I am unable to exclude groovy-generated java stubs. It seems > as though all of the exclude patterns are package and filename filters only. > If this is true, then the only way to exclude groovy-generated java sources > would be to move all of our groovy files into a package that contains the > word groovy, or to name all of our groovy classes ClassNameGroovy.groovy. > This seems unacceptible. The example on the webage for usage shows something > like this: > > **/generated/*.java > > This implies that we could do something similar like this: > > **/groovy-stubs/*.java > > But that doesn't seem to work because it ends up looking for > target/groovy-stubs/main/groovy-stubs/*.java because the patterns are all > relative to the source roots. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MGPG-8) Build error when plugin tries to sign nonexistent jar file in a war module
[
https://jira.codehaus.org/browse/MGPG-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MGPG-8:
--
Fix Version/s: (was: 1.0-alpha-4)
> Build error when plugin tries to sign nonexistent jar file in a war module
> --
>
> Key: MGPG-8
> URL: https://jira.codehaus.org/browse/MGPG-8
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 1.0-alpha-3
>Reporter: Wendy Smoak
>Assignee: Daniel Kulp
>
> During release:perform for Archiva 0.9-alpha-1, the gpg plugin is complaining
> that a jar is not found, when the module has packaging=war
> [INFO] [gpg:sign {execution: default}]
> gpg: can't open
> `e:\svn\maven\archiva\target\checkout\archiva-webapp\target\archiva-webapp-0.9-alpha-1.jar':
> No such file or directory
> gpg: signing failed: file open error
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Exit code: 2
> [INFO]
> -
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-60) Bump MI project to to Java6
[ https://jira.codehaus.org/browse/MINDEXER-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MINDEXER-60: --- Fix Version/s: (was: 5.0.0) > Bump MI project to to Java6 > --- > > Key: MINDEXER-60 > URL: https://jira.codehaus.org/browse/MINDEXER-60 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > > Maven Indexer project should be bumped to Java6 source and target levels. As > Java6 is about to EOL, and MI is still Java5... -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPH-26) New goal help:help to provide help on how to use helper plugins in maven
[ https://jira.codehaus.org/browse/MPH-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPH-26: -- Fix Version/s: (was: 2.1) > New goal help:help to provide help on how to use helper plugins in maven > > > Key: MPH-26 > URL: https://jira.codehaus.org/browse/MPH-26 > Project: Maven Help Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Eirik Maus > > It is almost impossible to remember the usage of the helper utility plugins > in maven. Every single time I have problems with transient dependencies I end > up searching google for "maven help plugin" and "maven dependency plugin". > That is not good enough. > The help plugin should have a goal called help, describing the usage of the > plugin. This would make help (or, rather, a bootstrap on how to use the help > system) available under the obvious command "mvn help:help". This goal could > also hint about the existence of the dependency plugin, since many of the > difficult problems when using maven are related to complex transitive > dependencies. > The command "mvn -help" should also describe the use of the > maven-help-plugin, but I will create a separate issue in the maven core > module for that. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MGPG-14) With maven 2.1.0 some poms end up with invalid signatures
[ https://jira.codehaus.org/browse/MGPG-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MGPG-14: --- Fix Version/s: (was: 1.0) > With maven 2.1.0 some poms end up with invalid signatures > - > > Key: MGPG-14 > URL: https://jira.codehaus.org/browse/MGPG-14 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 1.0-alpha-4 >Reporter: Daniel Kulp >Assignee: John Casey > Attachments: patch2.txt, patch.txt > > > The pom-transformed.xml is installed, but gpg is signing the original > pom.xml. Thus, the signature is invalid. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MIDEA-71) Sources are not consistently attached to dependencies
[ https://jira.codehaus.org/browse/MIDEA-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MIDEA-71: Fix Version/s: (was: 2.1) > Sources are not consistently attached to dependencies > - > > Key: MIDEA-71 > URL: https://jira.codehaus.org/browse/MIDEA-71 > Project: Maven IDEA Plugin (RETIRED) > Issue Type: Bug >Reporter: Jan Thomae > Attachments: admin-pom.xml, module1.jpg, module2.jpg, root-pom.xml, > server-pom.xml > > > I have a multimodule project, where all submodules depend on commons-logging > (and other modules). When i run idea:idea with downloadSources enabled, the > sources for commons logging are correctly downloaded, and commons logging is > added to the dependency list of all modules. However, the sources are only > added to some of the modules, not all of them. I wasnt able yet, to find out > some reason for this. I have attached two shots of one module with attached > source and one without, plus the root pom and the module poms -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJARSIGNER-12) It should be possible to save the keystore in one location for multi module projects
[ https://jira.codehaus.org/browse/MJARSIGNER-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MJARSIGNER-12: - Fix Version/s: (was: 1.3) > It should be possible to save the keystore in one location for multi module > projects > > > Key: MJARSIGNER-12 > URL: https://jira.codehaus.org/browse/MJARSIGNER-12 > Project: Maven Jar Signer Plugin > Issue Type: New Feature >Reporter: Sven Kirmess >Assignee: Tony Chemit > > We have a multi module maven setup. The problem is that this plugin requires > us to have the keystore either in the same location on all machines or in the > source code along each and every pom.xml file. > I would like to have one of the following: > - Save the file on one location in Subversion and use something like >svn://svn.example.com/trunk/keystore >and the plugin would have to take care to check out the keystore into > every project as needed. > or > - Put the keystore into a JAR file and save that JAR file on the Nexus > server. Then make the jarsigner plugin depend on this JAR file, download it > for every project and extract the keystore from there. This would be like > what the assembly plugin can do for its descriptors. > http://docs.codehaus.org/display/MAVENUSER/Assembly+Plugin -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRRESOURCES-37) embedded error with maven-remote-resources-plugin; maven build order?
[
https://jira.codehaus.org/browse/MRRESOURCES-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MRRESOURCES-37:
--
Fix Version/s: (was: 1.1)
> embedded error with maven-remote-resources-plugin; maven build order?
> -
>
> Key: MRRESOURCES-37
> URL: https://jira.codehaus.org/browse/MRRESOURCES-37
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: [INFO] [enforcer:display-info {execution: default}]
> [INFO] Maven Version: 2.0.10
> [INFO] JDK Version: 1.5.0_16 normalized as: 1.5.0-16
> [INFO] OS Info: Arch: i386 Family: unix Name: linux Version: 2.6.28.8
>Reporter: jieryn
>Assignee: John Casey
> Attachments: MNG-4094.zip, testing.zip
>
>
> I am attaching a sample project which exhibits the error. Please run mvn -f
> pom-firstTime.xml to prime your .m2/repository so that the real pom.xml's
> finds the artifacts properly. Now, run mvn (default goal install is
> coded) and notice the Embedded error. I scan the previously created JARs in
> my .m2/repository and the maven-remote-resources-plugin files are definitely
> in the JAR.
> I am at a loss, not convinced this is a bug, but need better minds to examine
> this. Thank you!
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (DOXIA-99) Figures require extension in APT and they should not
[ https://jira.codehaus.org/browse/DOXIA-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated DOXIA-99: Fix Version/s: (was: 1.1) > Figures require extension in APT and they should not > > > Key: DOXIA-99 > URL: https://jira.codehaus.org/browse/DOXIA-99 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.0-alpha-5, 1.0-alpha-6, 1.0-alpha-7, 1.0-alpha-8 >Reporter: Greg Luck >Assignee: Lukas Theussl > > Figures require extension in APT and they should not. > For example, http://ehcache.sourceforge.net/nameandlogo.html shows a broken > image. The APT for this page is: > [images/ehcache_logo] > Now, if I change it to [images/ehcache_logo.gif] it works. However this > breaks aptconvert. The reason is that it is illegal in APT to specify the > figure extension. I use aptconvert to create a pdf and single HTML page. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-71) javac compilation error for package-info.java containing package annotation
[ https://jira.codehaus.org/browse/MCOMPILER-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MCOMPILER-71: Fix Version/s: (was: backlog) > javac compilation error for package-info.java containing package annotation > --- > > Key: MCOMPILER-71 > URL: https://jira.codehaus.org/browse/MCOMPILER-71 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: Windows XP SP2 > JDK 1.5.0_15 >Reporter: Gabriel Forro >Assignee: John Casey > Attachments: compile_error_2.0.2.log > > > The package-info.java files can not be compiled in Maven 2 if the 2.0.2 > maven-compiler-plugin is used. package-info.java files can be compiled by > earlier versions of the maven-compiler-plugin (I have tried 2.0 and 2.0.1). > Newer snapshot versions does not work also and it fails in the same error (I > have tried version 2.1-snapshot). > This problem can be caused by an unusual behavior of the javac from jdk 1.5. > This behavior is as follows: > You can not use '/' file separator during compiling package-info.java (for > instance "javac sk/forro/package-info.java"). You must use '\' separator (for > instance "javac sk\forro\package-info.java"). If you use the '/' separator > you get the the compilation error reported by this bug (package annotations > should be in file package-info.java). This is javac 'feature' has been > removed in jdk 6 and in jdk 6 you can use either '/' or '\' - it does not > matter. > It looks like the maven-compiler-plugin or one of its components (I mean > plexus-x artefacts used by maven-compiler-plugin) uses '/' instead of the '\' > in the MS Windows environment. > I have attached a log file of an unsuccessful build (generated by mvn install > -X) > A possible workaround to solve this problem temporarily: > The compilation successes if I use either an older version of > maven-compiler-plugin or jdk 6 or do not use package-info.java files at all. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-21) compiler smarts
[ https://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MCOMPILER-21: Fix Version/s: (was: backlog) > compiler smarts > --- > > Key: MCOMPILER-21 > URL: https://jira.codehaus.org/browse/MCOMPILER-21 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Brett Porter >Assignee: Mark Struberg > Attachments: MCOMPILER-21.patch, MCOMPILER-21-v2.patch > > > there are probably other ways we can make the compiler stale check smarter. > List them out here if you think of them. > 1) if a snapshot was resolved to a newer version, rebuild everything. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEPLOY-7) deploy plugin leaves unnecessary information in the deployed pom.xml
[ https://jira.codehaus.org/browse/MDEPLOY-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MDEPLOY-7: - Fix Version/s: (was: 2.2) > deploy plugin leaves unnecessary information in the deployed pom.xml > > > Key: MDEPLOY-7 > URL: https://jira.codehaus.org/browse/MDEPLOY-7 > Project: Maven Deploy Plugin > Issue Type: Bug >Reporter: Jorg Heymans >Assignee: Allan Ramirez > > ideally, during deployment, the deployed pom should be stripped of elements > like and > IRC log : > jorg Can someone enlighten me here : when i "deploy" an artifact (m2), why > does the deployed plugin contain the and > elements ? > jorg s/plugin/artifact/ > jorg surely these elements are only relevant to the deployer ? > jesse in the pom that is in the jar? > jorg no the one that is deployed alongside the jar > jorg shall I jira this ? > jesse hm, I think that is a bug similar to the one with stuff in the > META-INF/maven file too > jorg yeah that's what i figured too > jesse might as well bug it > jdcasey jorg: we're not cleaning up that pom at all, just sending it > on...but it's a good point > jorg jdcasey: you mean about the maven version ? > jdcasey I mean about the build/distributionManagement stuff...or > anything that makes it into the POM that's deployed > jorg oh ok , yup i think the pom should be stripped of anything not > dependency related > jorg i'm using deploy plugin v2.0 > jdcasey I think I agree that it should be stripped of the functional > parts of the POM, but not the informational stuff...it will allow us to make > a richer map of project info if we leave that stuff in > jorg jdcasey: yes thinking of it that's what i meant .. anything build or > deploy related can go > jdcasey "don't ask *how" this got here, it just did." ;-) > jorg hehe exactly -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (DOXIA-51) RtfSink supports only ".ppm" image type in figureGraphics()
[ https://jira.codehaus.org/browse/DOXIA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated DOXIA-51: Fix Version/s: (was: 1.1) > RtfSink supports only ".ppm" image type in figureGraphics() > --- > > Key: DOXIA-51 > URL: https://jira.codehaus.org/browse/DOXIA-51 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Rtf >Affects Versions: 1.0-alpha-8 >Reporter: Vincent Siveton > > Need to update the writeImage() method to support more image types -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCLEAN-53) directory (specified in the section) not removed if it's not empty
[
https://jira.codehaus.org/browse/MCLEAN-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MCLEAN-53:
-
Fix Version/s: (was: 2.5)
> directory (specified in the section) not removed if it's not empty
> -
>
> Key: MCLEAN-53
> URL: https://jira.codehaus.org/browse/MCLEAN-53
> Project: Maven Clean Plugin
> Issue Type: Bug
>Affects Versions: 2.4, 2.4.1, 2.5
> Environment: fedora 17, 64bit
> java -version:
> java version "1.7.0_09"
> Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
> Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)
> mvn --version
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.7.0_09
> Java home: /usr/java/jdk1.7.0_09/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux" version: "3.6.8-2.fc17.x86_64" arch: "amd64" Family: "unix"
>Reporter: Peter Butkovic
> Attachments: sample.zip
>
>
> in case of following configuration:
> {code:xml}
>
> maven-clean-plugin
> 2.5
>
>
>
> ./
>
> deleteme
>
>
>
>
>
> {code}
> and having directory structure like this:
> {code}
> deleteme/i_prevent_deletion.txt
> pom.xml
> {code}
> directory deleteme won't be deleted. If the i_prevent_deletion.txt file is
> removed, all works.
> Problematic behavior doesn't seem to be working since 2.4 version.
> However for 2.3 version it works OK.
> Usage of the section is critical here, because in our real world
> application we don't have single directory, but rather multilevel directory
> structure and we use * in the includes (this could not be achieved by the
> only as far as I know).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-28) Renderer html code provided in an action record
[ https://jira.codehaus.org/browse/MCHANGES-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MCHANGES-28: --- Fix Version/s: (was: 2.0-beta-3) > Renderer html code provided in an action record > --- > > Key: MCHANGES-28 > URL: https://jira.codehaus.org/browse/MCHANGES-28 > Project: Maven Changes Plugin > Issue Type: New Feature > Components: changes.xml > Environment: windows and solaris >Reporter: Olivier Lamy > Attachments: changes.xml > > > Is there any way to renderer the html code provided in an action reccord. > > Added method : > > int getInt(final String key, int defaultValue); > double getDouble(final String key, double defaultValue); > long getLong(final String key); > long getLong(final String key, long defaultValue); > > > And having the ... in the html page. > Or using apt format ?? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHANGES-49) javax.mail dependency should be optional
[ https://jira.codehaus.org/browse/MCHANGES-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MCHANGES-49: --- Fix Version/s: (was: 2.0-beta-3) > javax.mail dependency should be optional > > > Key: MCHANGES-49 > URL: https://jira.codehaus.org/browse/MCHANGES-49 > Project: Maven Changes Plugin > Issue Type: Improvement > Components: changes.xml >Affects Versions: 2.0-beta-2 >Reporter: Wendy Smoak >Assignee: Stéphane Nicoll > > With maven-changes-plugin configured, I'm unable to generate the changes > report for the website without installing Sun's mail and activation jars. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHANGELOG-7) Multimodule support not working properly
[ https://jira.codehaus.org/browse/MCHANGELOG-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MCHANGELOG-7: Fix Version/s: (was: 2.0) > Multimodule support not working properly > > > Key: MCHANGELOG-7 > URL: https://jira.codehaus.org/browse/MCHANGELOG-7 > Project: Maven Changelog Plugin > Issue Type: Improvement > Environment: OSX 10.4.3, java 1.4.2_09, maven 2.0.1-SNAPSHOT, > maven-changelog-plugin 2.0-beta-2-SNAPSHOT >Reporter: Julian Wood >Assignee: Edwin Punzalan >Priority: Minor > > I have a pom with two submodules. In the parent pom, I specify that I want a > changelog report. Then I create a site from the parent pom. I end up getting > this: > For the parent pom - no sources found for changelog. > Module 1 - no sources found. > Module 2 - I get a decent report on changes in the parent and both modules. > It seems to me I should get a report from the parent's point of view, and > then changes from the module 1 and module 2 subdirectories from svn. At > worst, I should get the parent report and no sources found for both > submodules. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-97) Export resource key/values as POM properties
[ https://jira.codehaus.org/browse/MSHARED-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSHARED-97: -- Fix Version/s: (was: maven-filtering-1.0-beta-3) > Export resource key/values as POM properties > > > Key: MSHARED-97 > URL: https://jira.codehaus.org/browse/MSHARED-97 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-filtering >Reporter: Paul Benedict >Assignee: John Casey > > This issue relates to MNG-2562 and the maven-setproperty-plugin > (http://www.mail-archive.com/dev@maven.apache.org/msg62789.html). > Sometimes the interpolation of resources creates a completed key/value that I > would like to re-use in later phases. Unfortunately there is no way to get > these values to use in the POM unless there is a mechanism to export the > values. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-149) Add a qualityManagement goal
[
https://jira.codehaus.org/browse/MPIR-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPIR-149:
Labels: (was: close-pending)
> Add a qualityManagement goal
>
>
> Key: MPIR-149
> URL: https://jira.codehaus.org/browse/MPIR-149
> Project: Maven Project Info Reports Plugin
> Issue Type: Wish
>Reporter: Xavier Chatelain
>Priority: Minor
> Attachments: MPIR-149_maven-2.0.x.patch, MPIR-149_maven-2.1.x.patch,
> MPIR-149_maven-project-info-reports-plugin.patch
>
>
> More and more projects use an external quality management tool. So it would
> be interesting to add a qualityManagement goal similar to the cim and
> issueTracking goals. With this goal, user could add this kind of
> configuration in his pom.xml:
> {code}
>
> sonar
> http://host/sonar/myProject
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSKINS-94) Left margin on p elements leads to rugged indentation
[
https://jira.codehaus.org/browse/MSKINS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSKINS-94:
-
Labels: (was: close-pending)
> Left margin on p elements leads to rugged indentation
> -
>
> Key: MSKINS-94
> URL: https://jira.codehaus.org/browse/MSKINS-94
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
> Environment: maven-fluido-skin 1.3.1
>Reporter: Tobias Oberlies
>
> The {{margin-left}} on {{p}} elements in the Fluido skin leads to a rugged
> indentation, and there is no way to avoid it in a typical Mojo site doc page.
> Consider for example the
> [test-mojo|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html]
> page: On this page, each of the parameter descriptions is not enclosed in
> {{p}} elements. In the overview table this leads to a proper alignment with
> the "User property" and "Default value" lines because they are also not
> enclosed in paragraphs.
> In the "Parameter Details" section however, the parameter names are enclosed
> in {{p}} elements, making the parameter descriptions look as if they have a
> negative indentation.
> Enclosing the parameter descriptions in {{p}} elements (in the Mojo sources)
> would help for the parameter details section, but this then leads to a rugged
> indentation in the overview table.
> So, since it cannot be ensured that {{p}} elements are used everywhere,
> Fluido should not assing a left margin to them.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-251) Artifact ###### has no file error regression.
[
https://jira.codehaus.org/browse/MPIR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPIR-251:
Labels: (was: close-pending)
> Artifact ## has no file error regression.
> -
>
> Key: MPIR-251
> URL: https://jira.codehaus.org/browse/MPIR-251
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.5
>Reporter: Ian Brandt
>Priority: Minor
> Attachments: pom.xml
>
>
> It appears that MPIR-158 has regressed. I'm seeing the same exact issue in
> 2.5 with Maven 3.0.4:
> {noformat}
> [INFO] Generating "Dependencies" report---
> maven-project-info-reports-plugin:2.5
> [ERROR] Artifact: com.sun:tools:jar:1.5.0 has no file.
> [ERROR] Artifact: com.thoughtworks.xstream:xstream:jar:1.3 has no file.
> [ERROR] Artifact: commons-beanutils:commons-beanutils:jar:1.8.0 has no file.
> [ERROR] Artifact: commons-cli:commons-cli:jar:1.1 has no file.
> [ERROR] Artifact: commons-codec:commons-codec:jar:1.3 has no file.
> [ERROR] Artifact: commons-collections:commons-collections:jar:3.2.1 has no
> file.
> [ERROR] Artifact: commons-digester:commons-digester:jar:2.0 has no file.
> [ERROR] Artifact: commons-fileupload:commons-fileupload:jar:1.2.2 has no file.
> ...{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (JXR-83) Allow custom stylesheet from dependent jar
[ https://jira.codehaus.org/browse/JXR-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed JXR-83. - Resolution: Won't Fix No reaction upon request. > Allow custom stylesheet from dependent jar > -- > > Key: JXR-83 > URL: https://jira.codehaus.org/browse/JXR-83 > Project: Maven JXR > Issue Type: Improvement > Components: maven2 jxr plugin >Affects Versions: 2.1 > Environment: maven 2.2.1 >Reporter: Brian Relph > Attachments: stylesheet > > > Allow specifying a custom stylesheet that is included from a dependent jar > (similar to javadoc plugin). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSKINS-69) REGRESSION: reporting section titles are not enough visible (was better in previous version)
[ https://jira.codehaus.org/browse/MSKINS-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSKINS-69. Resolution: Won't Fix No reaction upon request. > REGRESSION: reporting section titles are not enough visible (was better in > previous version) > > > Key: MSKINS-69 > URL: https://jira.codehaus.org/browse/MSKINS-69 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: fluido-1.3.0 >Reporter: Herve Boutemy >Priority: Critical > Attachments: fluido-1.2.png, fluido-1.3.0.png > > > see attachements to compare Fluido 1.2 and Fluido 1.3.0 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (JXR-2) Add a basic code transformer
[ https://jira.codehaus.org/browse/JXR-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed JXR-2. Resolution: Won't Fix No reaction upon request. > Add a basic code transformer > > > Key: JXR-2 > URL: https://jira.codehaus.org/browse/JXR-2 > Project: Maven JXR > Issue Type: New Feature > Components: jxr >Reporter: Emmanuel Venisse > > BasicCodeTransform transform all files that don't have a specific transformer -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-225) Change 'developer access', optionally, to show trunk for Subversion, not tag URL
[ https://jira.codehaus.org/browse/MPIR-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPIR-225. --- Resolution: Won't Fix No reaction upon request. > Change 'developer access', optionally, to show trunk for Subversion, not tag > URL > > > Key: MPIR-225 > URL: https://jira.codehaus.org/browse/MPIR-225 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.4 >Reporter: Benson Margulies > > When I go to look at the scm report for the SVN url, I am getting ready to > prepare to fix something. In that case, I essentially never want the tagged > version of the release. I want the 'corresponding development branch'. This > is not a concept currently modelled in maven at all. > At very least, I'd like to add a config property to this plugin that > specifies that URL, and then add it as an additional clause in the output. > Obviously, it's would be slicker in some respects to add another something to > the pom, but that's a much bigger deal (though there might be other uses for > it). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-731) footer elements in site.xml are ignored
[ https://jira.codehaus.org/browse/MSITE-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSITE-731. Resolution: Won't Fix No reaction upon request. > footer elements in site.xml are ignored > --- > > Key: MSITE-731 > URL: https://jira.codehaus.org/browse/MSITE-731 > Project: Maven Site Plugin > Issue Type: Bug >Affects Versions: 3.4 >Reporter: Benson Margulies > > See https://github.com/basis-technology-corp/tcl-regex-java. If you clone > this and run mvn site:site, you will see a copyright notice that I don't > want, instead of the footer that is supplied in the site.xml. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSKINS-88) Add a generic search form
[ https://jira.codehaus.org/browse/MSKINS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSKINS-88. Resolution: Won't Fix No reaction upon request. > Add a generic search form > - > > Key: MSKINS-88 > URL: https://jira.codehaus.org/browse/MSKINS-88 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Affects Versions: fluido-1.3.0 >Reporter: barnaby relph >Priority: Minor > > For fluido-based sites with an in-house search engine, I'd like to be able to > specify a search element (like the existing google search element) but to > supply the action URL and field name, so that I can point the search at an > in-house server. > This seems to be the same requirement as this SO question too: > http://stackoverflow.com/questions/14373950/maven-site-search-capabilities > Happy to know if there's another way of achieving this. > Would something like this work: > ## > #macro ( customSearch $top ) > #set( $customsearchURL = $decoration.custom.getChild( 'fluidoSkin' > ).getChild( 'customSearch' ).getChild( 'customsearchURL' ).getValue() ) > #if ( $decoration.custom.getChild( 'fluidoSkin' ).getChild( 'customSearch' > ).getChild( 'customsearchParamName' ) ) > #set( $customsearchParamName = $decoration.custom.getChild( 'fluidoSkin' > ).getChild( 'customSearch' ).getChild( 'customsearchParamName' ).getValue() ) > #else > #set( $customsearchParamName = "q" ) > #end > class="navbar-search pull-right" #end> >type="text" /> > > #end -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-250) Allow cleaning of the remote area or staging site
[ https://jira.codehaus.org/browse/MSITE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSITE-250. Resolution: Won't Fix No reaction upon request. > Allow cleaning of the remote area or staging site > - > > Key: MSITE-250 > URL: https://jira.codehaus.org/browse/MSITE-250 > Project: Maven Site Plugin > Issue Type: New Feature > Components: site:deploy, site:stage(-deploy) >Reporter: Wim Deblauwe > > When files have been removed, they are not removed from the remote deploy > area or the staging site. A new goal to clean the staging or the final deploy > area would be a nice addon to this plugin. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-387) Allow user/admin to provide deletion command from commandline
[ https://jira.codehaus.org/browse/MSITE-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSITE-387. Resolution: Won't Fix No reaction upon request. > Allow user/admin to provide deletion command from commandline > - > > Key: MSITE-387 > URL: https://jira.codehaus.org/browse/MSITE-387 > Project: Maven Site Plugin > Issue Type: Improvement > Components: site:deploy >Affects Versions: 2.0-beta-4, 2.0-beta-5, 2.0-beta-6, 2.0-beta-7, 2.0 > Environment: A windows machine deploying to a Linux or Unix node >Reporter: Renaud Lepage >Priority: Minor > > Just a suggestion here - in fact I could basically do the patch if someone > wants me to. We currently have LOTS (and I do mean LOTS) of systems down here > at work, where we'd like to automatically deploy websites over SSH by means > of SCP. Problem is that some machines have "alias rm='rm -i'" in their shell > environment, therefore blocking the rm command from finishing. I'd suggest > allowing the user/admin to provide the deletion command so as to be able to > force "/bin/rm" for example, which would not take the damned "-i" in account. > Any thoughts on this one? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (JXR-101) Add support to generate xrefs for groovy sources
[ https://jira.codehaus.org/browse/JXR-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed JXR-101. -- Resolution: Won't Fix No reaction upon request. > Add support to generate xrefs for groovy sources > > > Key: JXR-101 > URL: https://jira.codehaus.org/browse/JXR-101 > Project: Maven JXR > Issue Type: New Feature > Components: jxr >Affects Versions: 2.3 >Reporter: Davide Cavestro > > Having crossreference for groovy sources would be great. Groovy is widely > used, and partially compatible with java syntax. Maybe some fixes to the Java > source parser (i.e. JXR-100) could let us produce good xrefs even for groovy > sources (provided that parsing them is enabled). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-90) Possibility to check classes, chosen with datetime filter
[
https://jira.codehaus.org/browse/MPMD-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPMD-90.
--
Resolution: Won't Fix
No reaction upon request.
> Possibility to check classes, chosen with datetime filter
> -
>
> Key: MPMD-90
> URL: https://jira.codehaus.org/browse/MPMD-90
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: PMD
>Reporter: Sergey Petrovskiy
>
> The goal is to check not all classes of project, but only last commited.
> If I start pmd with Ant, I can define datetime:
> {code:xml}
>
> rulesets/basic.xml
> rulesets/unusedcode.xml
> rulesets/codesize.xml
> rulesets/imports.xml
>toConsole="true"/>
>
>
>
>
>
>
> {code}
> I could not find this possibility for maven pmd plugin.
> BTW: the same possibility required in checkstyle plugin.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (DOXIASITETOOLS-95) Provide possibility to expand Project Reports menu
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed DOXIASITETOOLS-95. Resolution: Won't Fix No reaction upon request. > Provide possibility to expand Project Reports menu > -- > > Key: DOXIASITETOOLS-95 > URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-95 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Decoration model >Reporter: Damien Lecan > > By default, "Project Reports" menu is collapsed. > The site.xml file could allow user to specify if this menu has to be > collapsed or not : > > This will expand "Project Reports" and "Project Information" together. > Doxia doesn't seem to provide a such feature (MenuItem can be collapsed, but > "reports" is a Menu, not a MenuItem) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-530) use standard Maven caching for local repository site descriptors
[ https://jira.codehaus.org/browse/MSITE-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSITE-530. Resolution: Won't Fix No reaction upon request. > use standard Maven caching for local repository site descriptors > > > Key: MSITE-530 > URL: https://jira.codehaus.org/browse/MSITE-530 > Project: Maven Site Plugin > Issue Type: Improvement >Affects Versions: 3.0-beta-3 >Reporter: Brett Porter > > I've found that the site plugin (or perhaps Doxia) is caching 404's for site > descriptors in the local repository as empty files, as a form of added > efficiency for descriptors that are often not present. > However, this has a downside - I had one cached due to switching to a > different parent before it could be downloaded - so even when it was > available it silently used an empty parent descriptor (even through -U), > causing the Maven site to be deployed with no skin. > Likewise, when the 17-SNAPSHOT maven-parent was cleaned up, the previously > working site build would no longer have a valid parent descriptor and > silently failed. > There should be a clear indication in the build that no site descriptor was > found (or not used due to previously caching), and where possible rely on > Maven's built in handling for caching resolution failures. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-308) fails with java 8 (caused by BCEL)
[ https://jira.codehaus.org/browse/MPIR-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPIR-308. --- Resolution: Won't Fix No reaction upon request. > fails with java 8 (caused by BCEL) > -- > > Key: MPIR-308 > URL: https://jira.codehaus.org/browse/MPIR-308 > Project: Maven Project Info Reports Plugin > Issue Type: Bug > Components: dependencies >Affects Versions: 2.7 > Environment: Windows 7 / java 8 >Reporter: Mickaël VERA > Attachments: maven.output.log > > > The build finishes with success but there is a stack trace is logged. > The log file is attached. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-704) generate index using a maven plugin
[ https://jira.codehaus.org/browse/MSITE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSITE-704. Resolution: Won't Fix No reaction upon request. > generate index using a maven plugin > --- > > Key: MSITE-704 > URL: https://jira.codehaus.org/browse/MSITE-704 > Project: Maven Site Plugin > Issue Type: Improvement >Reporter: Brett Porter > > write our own site plugin, or make index generation a part of the site plugin. > need to be able to add metadata to APT, XDOC and FML files to be able to > specify the category, etc. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-514) Document / Content Harvesting (Word, Excel.. others)
[
https://jira.codehaus.org/browse/MSITE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSITE-514.
Resolution: Won't Fix
No reaction upon request.
> Document / Content Harvesting (Word, Excel.. others)
>
>
> Key: MSITE-514
> URL: https://jira.codehaus.org/browse/MSITE-514
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.0-beta-2
>Reporter: Andrew Hughes
>
> Hi Guys,
> Have an idea, but I wouldn't know where to get started on this... besides I
> think this is more than a one person job. Just like we have reporting plugins
> and the project-info reports, I think a "project documents" site plugin would
> be an excellent idea.
> Purpose:
> The primary purpose is to provide easy integration of non apt, xdoc...
> formatted documents into maven sites.
> Objectives:
> The primary objective should be to create a menu on the site that lists all
> of the discovered documents in the project source.
> Example (that extents the normal "Project Documentation" menu.
> * Project Documentation
> ** Project Information
> *** Continuous Integration
> *** Issue Tracking
> *** Project Team
> *** Source Repository
> ** Project Reports
> *** Maven Surefire Report
> *** Other Report
> ** Documents <- NEW name TDB, clicking on this should open a page with a
> table of all documents with their harvested metadata.
> *** Acme Project SRS (doc) <- New, showing a harvested word document.. the
> link title is the document title
> *** Contract (pdf) <- New, showing a harvested pdf document.
> *** Estimates (xls) <- New, an excel spreadsheet
> *** Risk Register (xls) <- New, another excel spreadsheet.
> The index page's could hopefully gather enuff metadata about the documents to
> create something that looks like...
> ||Title||Filename||Format||Author||Last Modified||Last Mofified By||
> |Acme Project SRS| APD-ACME-SRS.doc|doc|John Smith|14-10-2010|A Hughes|
> |Contact| APC-ACME-CONTACT-23489345.pdf|pdf|N/A|22-02-2010|N/A|
> |Estimates| APE-ACME-Estimates.xls|xls|A Schwarzenegger|22-02-2010|JP Freely|
> Implementation:
> I got very little idea how this kinda thing could be integrated into the
> site. From menu creation, velocity templates e.t.c... sorry I am quite
> useless. I do know that we have things like http://poi.apache.org/ to help
> gather meta data about microsoft documents, and similarly pdf is available.
> LaTex or other formats hopefully have similar API's.
> Configuration:
> I'd think that the pom config might help define how this could work.. what
> options and functionality it would/could potentially offer...
> {noformat}
>
> ...ommitting normal stuff...
>
>
>
>
> ${basedir}/documents
>
>
> **.doc
> **.xls
>
>
>
>
> Documentz
>
>
> title,version,author,lastModifiedBy,lastModifiedData
>
>
> {noformat}
> What do you think, is this a practical idea? is this achievable and how much
> work would be involved?
> CHEERS :)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (JXR-3) Add an XML code tranformer
[ https://jira.codehaus.org/browse/JXR-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed JXR-3. Resolution: Won't Fix No reaction upon request. > Add an XML code tranformer > -- > > Key: JXR-3 > URL: https://jira.codehaus.org/browse/JXR-3 > Project: Maven JXR > Issue Type: New Feature > Components: jxr >Reporter: Emmanuel Venisse > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-183) Multiple programming language support
[ https://jira.codehaus.org/browse/MPMD-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPMD-183. --- Resolution: Won't Fix No reaction upon request. > Multiple programming language support > - > > Key: MPMD-183 > URL: https://jira.codehaus.org/browse/MPMD-183 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Affects Versions: 3.0.1 >Reporter: Andrey Utis > > Currently PMD supports multiple languages (with 5.1.0 it supports even more). > But the only way to run the PMD plugin for multiple languages is to run > multiple executions. It would be great to be able to configure multiple > languages within one execution. Example: a project that contains Java, > JavaScript, Velocity templates, and PL/SQL code. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-634) Invalid links to sub-modules when specifying site url using a profile
[
https://jira.codehaus.org/browse/MSITE-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSITE-634.
Resolution: Won't Fix
No reaction upon request.
> Invalid links to sub-modules when specifying site url using a profile
> -
>
> Key: MSITE-634
> URL: https://jira.codehaus.org/browse/MSITE-634
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: multi module, relative links
>Affects Versions: 2.3
>Reporter: Matthias Henkel
> Attachments: childpom.xml
>
>
> When using a profile for specifying the site url the links to the sub-modules
> get broken.
> {code}
>
> 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
> com.company.application
> application
> pom
> 04.00.02-9_19-SNAPSHOT
> application
>
> 2.2.1
>
>
>
>
>
>
> org.apache.maven.plugins
>
> maven-site-plugin
> 2.3
>
>
>
>
>
>
> company
>
>
> application.site
>
> scpexe://projects.company.com/srv/filestore/application/site/siteFixing/
>
>
>
>
>
> com.company.application.module
>
>
> {code}
> Executed command: {{mvn clean site-deploy -P company}}
> Reproducible with: {{maven-site-plugin}} {{2.3}} but not with {{2.2}}.
> When specifying the {{distributionManagement}} section outside of a profile
> everything works fine.
> The site of the parent module is deployed to
> https://projects.company.com/application/filestore/site/siteFixing/index.html
> but the link to the sub-module points to
> https://projects.company.com/module/index.html even though the sub-module has
> been deployed to
> https://projects.company.com/application/filestore/site/siteFixing/module/index.html
> .
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSITE-448) Support proper project identity in site URLs
[ https://jira.codehaus.org/browse/MSITE-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSITE-448. Resolution: Won't Fix No reaction upon request. > Support proper project identity in site URLs > > > Key: MSITE-448 > URL: https://jira.codehaus.org/browse/MSITE-448 > Project: Maven Site Plugin > Issue Type: Improvement >Reporter: John Allen > > IMHO there is a lack of proper POM UID namespace management in the URL > inheritence and extension schemes used in site generation. I may have > a latest version of a project and this may have a nice site but i need to be > able to continue to access, and critically link to (from other projects), > older versions of the same project's sites. The 'latest' version can always > be made accessible via some nice URL mapping e.g. > http://maven.apache.org/plugins/maven-clean-plugin/ == > http://maven.apache.org/org/apache/maven/plugins/maven-clean-plugin/2.1.1/ > For me a site is simply another 'view' onto a project's products and in the > same way one can access different versions of those products based on specify > the version one can not access the various different sites. Note this can be > done by manually specifying the project.url and > project.distributionManagement.site.url for every project such that the URLS > include the group, artefact and versionId information but this is error prone > and nasty. > In a nutshell, for us a project's site is just another project artefact and > therefore its identity should be preserved in the same robust way the the > other project products are (jars, pom, src-jars etc), i.e. stored in a unique > federated namespace. > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-248) Internationalization: Do not duplicate css files and image resources.
[ https://jira.codehaus.org/browse/MSITE-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSITE-248. Resolution: Won't Fix No reaction upon request. > Internationalization: Do not duplicate css files and image resources. > -- > > Key: MSITE-248 > URL: https://jira.codehaus.org/browse/MSITE-248 > Project: Maven Site Plugin > Issue Type: Improvement > Components: internationalization >Affects Versions: 2.0-beta-5 >Reporter: Alexander Hars > > Currently, Maven copies the skin's css files and image resources into each > locale directory. This leads to redundancy and has serious drawbacks when the > developer adds their own .css files (which most developers will do). If the > .css files are not packaged into a skin, then the developer has to copy each > change to the .css file into teach locale. (And we should not expect a > developer to create skin for a single project.). > Redundant resources also additional drawbacks. For example, if the localized > files are distributed as help files for a Java application we unnecessarily > increase the size of our distribution. > It would be much better to use a single location for all css files and image > resource (Of course, this does not prevent the developer from adding > localized css files or image resources, should they be needed). > The solution is simple: save the css files and resources only once below the > root directory. Then use relative links that point from the localized pages > to the root. > This can easily be done if the maven template could distinguish between the > localized directory for the default locale and the other locales (would > require another property to be passed to Velocity). It would even be simpler > if the directory structure treated all locales as equals, as is best practice > for internationalized applications. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (JXR-54) Discuss about Forrestdoc and JXR
[ https://jira.codehaus.org/browse/JXR-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed JXR-54. - Resolution: Won't Fix No reaction upon request. > Discuss about Forrestdoc and JXR > > > Key: JXR-54 > URL: https://jira.codehaus.org/browse/JXR-54 > Project: Maven JXR > Issue Type: Improvement > Components: jxr >Reporter: Vincent Siveton > > http://www.nabble.com/Forrestdoc-and-Maven-JXR-tf3864888s177.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-282) Allow customisation via a parent POM
[
https://jira.codehaus.org/browse/MPIR-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPIR-282.
---
Resolution: Won't Fix
No reaction upon request.
> Allow customisation via a parent POM
>
>
> Key: MPIR-282
> URL: https://jira.codehaus.org/browse/MPIR-282
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
>Reporter: SebbASF
>
> Individual projects can easily customise the PIR report text by providing
> replacement properties in a custom bundle at
> ${project.basedir}/src/site/custom/project-info-report.properties
> It would be useful for projects which share a common parent pom (e.g. Apache
> Commons) to be able to share a custom bundle.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSITE-213) site:deploy to support tar gzip
[ https://jira.codehaus.org/browse/MSITE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSITE-213. Resolution: Won't Fix No reaction upon request. > site:deploy to support tar gzip > --- > > Key: MSITE-213 > URL: https://jira.codehaus.org/browse/MSITE-213 > Project: Maven Site Plugin > Issue Type: Wish > Components: site:deploy >Reporter: Greg Luck > > Hi > I am using sourceforge to host my site. > They just removed unzip. Not sure if it is coming back. > Wagon relies on unzip. > It would be good if it could also use gzip by creating acrhives such as are > created using "tar -zcf arhive_name dir" > That way it would work in more environments. > Thanks > Greg -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-651) Unnecessary "parent" and "modules" menus show up as empty sections in sitemap
[
https://jira.codehaus.org/browse/MSITE-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSITE-651.
Resolution: Won't Fix
No reaction upon request.
> Unnecessary "parent" and "modules" menus show up as empty sections in sitemap
> -
>
> Key: MSITE-651
> URL: https://jira.codehaus.org/browse/MSITE-651
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 3.1
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
>Reporter: Andreas Sewe
> Attachments: example.tar.gz, screenshot-1.jpg
>
>
> When using {{generateSitemap}}, the resulting {{sitemap.html}} contains ugly
> empty sections (empty {{}}, superfluous {{}}) if one of the _special_
> menus ({{parent}}, {{module}}) is empty as the project in question does not
> have a parent or modules, respectively.
> The {{sitemap.html}} generated by the attached example project ({{mvn site}})
> illustrates this issue.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSITE-82) M2 Site Plugin too strict about document structure
[ https://jira.codehaus.org/browse/MSITE-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSITE-82. --- Resolution: Won't Fix No reaction upon request. > M2 Site Plugin too strict about document structure > -- > > Key: MSITE-82 > URL: https://jira.codehaus.org/browse/MSITE-82 > Project: Maven Site Plugin > Issue Type: New Feature >Affects Versions: 2.0-beta-4 > Environment: Java 1.5, WinXP SP2 >Reporter: John R Fallows > > Site generation generally assumes total ownership of the generated HTML > content, such that complete HTML pages are expected to be generated. > Therefore, strict rules are specified when parsing APT documentation files as > input to site generation process, to make sure that APT files have full page > structure. > Unfortunately, this restriction is too brittle for Java.Net based Maven2 > projects that want to generate site documentation. > Java.Net adds chrome dynamically at runtime to all pages (not a problem) but > it also adds a project summary and a header for the project "Description" > around any HTML content in the top level index.html page for a project. > This means that the generated index.html page needs to have a structure such > as ...Next Section > As you can see, this is not a valid HTML document, but an HTML fragments. > Unfortunately, the APT parser is too strict to support the corresponding > index.apt syntax logically required to produce such an index.html. > Please allow the syntax checking during parsing to be relaxed as necessary to > achieve the desired generated HTML. > As mentioned by Brett, we could support out-of-order elements, but with > warnings This might be generally useful for fragment generation in general, > anywhere a server-side include could be used by the generated site. > However, if we take this approach, it would be useful to be able to still get > a clean build with no warnings, possibly by specifying which site files are > fragments so that warnings could still be generated for user errors in other > non-fragment pages. > Perhaps the .aptf extension could be used to indicate a fragment APT file. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (JXR-22) Refactoring JavaCodeTransform
[ https://jira.codehaus.org/browse/JXR-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed JXR-22. - Resolution: Won't Fix No reaction upon request. > Refactoring JavaCodeTransform > - > > Key: JXR-22 > URL: https://jira.codehaus.org/browse/JXR-22 > Project: Maven JXR > Issue Type: Improvement > Components: jxr >Affects Versions: 2.1 >Reporter: Vincent Siveton > Attachments: CodeTransform.java, JXR-22.patch > > > JavaCodeTransform needs to be refactored to handle other transformers (see > JXR-2 and JXR-3) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSKINS-83) Table header are not highlighted enough
[ https://jira.codehaus.org/browse/MSKINS-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSKINS-83. Resolution: Won't Fix No reaction upon request. > Table header are not highlighted enough > --- > > Key: MSKINS-83 > URL: https://jira.codehaus.org/browse/MSKINS-83 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.3.0 >Reporter: Christophe Lallement > > When you draw table (with xdoc for example) > The row header has the same background color as other row, meaning it's very > difficult to see there is a header. > Trying to add bgcolor to xdoc element doesn't change anything. > Regards > Christophe -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (JXR-68) ignores classes with same name in other packages
[ https://jira.codehaus.org/browse/JXR-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed JXR-68. - Resolution: Won't Fix No reaction upon request. > ignores classes with same name in other packages > > > Key: JXR-68 > URL: https://jira.codehaus.org/browse/JXR-68 > Project: Maven JXR > Issue Type: Bug > Components: maven2 jxr plugin >Affects Versions: 2.1 >Reporter: Paul Sundling > > say you the following classes > package1/MyClass > package2/MyClass > While both will show up in javadocs plugin, only one will show up in JXR > report. > Let me know if you need a test case. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-563) Enable easier debugging of VM scripts by adding context to the context
[ https://jira.codehaus.org/browse/MSITE-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSITE-563. Resolution: Won't Fix No reaction upon request. > Enable easier debugging of VM scripts by adding context to the context > -- > > Key: MSITE-563 > URL: https://jira.codehaus.org/browse/MSITE-563 > Project: Maven Site Plugin > Issue Type: New Feature >Reporter: SebbASF > > Sometimes it would be useful to display all the variables that are set in the > context of a VM template. > The suggestion is to optionally add the context to itself. > For example, if the following property is defined: > -Dvelocity.context.variable=ctx > then define the variable "ctx" to contain the current context pointer. > It would be best if this were available as a command-line option (as well as > a config option). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-283) CLONE - Announce e-mail and project website must reference source download page
[ https://jira.codehaus.org/browse/MPIR-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPIR-283. --- Resolution: Won't Fix No reaction upon request. > CLONE - Announce e-mail and project website must reference source download > page > --- > > Key: MPIR-283 > URL: https://jira.codehaus.org/browse/MPIR-283 > Project: Maven Project Info Reports Plugin > Issue Type: Bug >Reporter: Robert Scholte >Priority: Blocker > > The ASF releases source. > As such, announcements must link to the download page, and the component > website must also link to the download page. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-17) Create XML documents containing report data.
[ https://jira.codehaus.org/browse/MPIR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPIR-17. -- Resolution: Won't Fix No reaction upon request. > Create XML documents containing report data. > > > Key: MPIR-17 > URL: https://jira.codehaus.org/browse/MPIR-17 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3 >Reporter: Chris Hagmann > Fix For: 2.x > > Original Estimate: 10 hours > Remaining Estimate: 10 hours > > It would be a huge improvement if each report was written as as XML document > before optionally rendering it. If you did that, then other plugins could use > those XML reports, apply XSLT or whatever to generate their own version of a > report. It would make the whole reporting thing much more flexible. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-559) Delayed resolution of variables in inherited site.xml files
[ https://jira.codehaus.org/browse/MSITE-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSITE-559. Resolution: Won't Fix No reaction upon request. > Delayed resolution of variables in inherited site.xml files > --- > > Key: MSITE-559 > URL: https://jira.codehaus.org/browse/MSITE-559 > Project: Maven Site Plugin > Issue Type: Improvement > Components: inheritance, property interpolation >Reporter: SebbASF > > At present, variable references in site.xml files are resolved in the context > of the project that contains the site.xml. This is often not what is required > - e.g. if a parent site.xml is used to define settings for several modules. > It would be useful if there was a way to declare references that are resolved > in the context of the module that is being built. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSKINS-48) make Fluido Skin more responsive
[ https://jira.codehaus.org/browse/MSKINS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSKINS-48. Resolution: Won't Fix No reaction upon request. > make Fluido Skin more responsive > > > Key: MSKINS-48 > URL: https://jira.codehaus.org/browse/MSKINS-48 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.2.1 >Reporter: Hugues Obolonsky > Attachments: fluido-responsive.patch > > > The maven fluido skin is not optimise for cellphone device. > Patch provided as a proposition but maybe need more css tuning. > The patch provide an upgraded version of bootstrap with .hidden_phone > class which work on tag. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-252) Dependency Management report doesn't exclude system scoped dependencies
[
https://jira.codehaus.org/browse/MPIR-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPIR-252.
---
Resolution: Won't Fix
No reaction upon request.
> Dependency Management report doesn't exclude system scoped dependencies
> ---
>
> Key: MPIR-252
> URL: https://jira.codehaus.org/browse/MPIR-252
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependency-management
>Affects Versions: 2.5.1
> Environment: Mac OS X 10.7.2, Maven 3.0.4, JDK 1.7.0_06 / JDK 1.6.0_34
>Reporter: Martijn Verburg
>
> {noformat}
> [WARNING] Unable to create Maven project for com.sun:tools:pom:localVersion
> from repository.
> org.apache.maven.project.ProjectBuildingException: Error resolving project
> artifact: Failure to find com.sun:tools:pom:localVersion in
> http://ci.jclarity.com:8081/nexus/content/groups/public/ was cached in the
> local repository, resolution will not be reattempted until the update
> interval of jclarity-central has elapsed or updates are forced for project
> com.sun:tools:pom:localVersion
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:296)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:236)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository(RepositoryUtils.java:298)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(DependencyManagementRenderer.java:237)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForScope(DependencyManagementRenderer.java:204)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForAllScopes(DependencyManagementRenderer.java:157)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderSectionProjectDependencies(DependencyManagementRenderer.java:146)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderBody(DependencyManagementRenderer.java:132)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
> at
> org.apache.maven.report.projectinfo.DependencyManagementReport.executeReport(DependencyManagementReport.java:112)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.la
[jira] (SUREFIRE-1136) Current working directory propagation in forked mode
[
https://jira.codehaus.org/browse/SUREFIRE-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362199#comment-362199
]
Norbert Wnuk commented on SUREFIRE-1136:
Known limitation: $\{surefire.forkNumber\} propagation is not supported on
Maven 2.x, the variable will be resolved to 'null' value all the time -
https://github.com/apache/maven-surefire/pull/84
> Current working directory propagation in forked mode
>
>
> Key: SUREFIRE-1136
> URL: https://jira.codehaus.org/browse/SUREFIRE-1136
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.18.1
>Reporter: Norbert Wnuk
>Assignee: Andreas Gudian
>Priority: Minor
> Fix For: 2.19
>
>
> Surefire plugin does not resolve surefire.forkNumber variable for working
> directory so that the same invalid directory is set for all forked JVMs. The
> same time user.dir property is propagated properly which leads to
> inconsistent behavior in JDK API -
> http://stackoverflow.com/questions/1234795/why-is-the-user-dir-system-property-working-in-java
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSANDBOX-41) Generic external report plugin
[ https://jira.codehaus.org/browse/MSANDBOX-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSANDBOX-41. -- Resolution: Won't Fix outdated project, closing as won't fix. > Generic external report plugin > -- > > Key: MSANDBOX-41 > URL: https://jira.codehaus.org/browse/MSANDBOX-41 > Project: Maven Sandbox (retired) > Issue Type: New Feature >Reporter: Dave Syer > Attachments: external-report.zip > > > A very simple plugin to add an external report (e.g. junit html report) to > the project reports. This is really trivial (if anyone wants some code that > does it ask), but would be quite valuable to many people. > Example: > > > > org.apache.maven > maven-external-report-plugin > > JUnit Report > JUnit test results for this project > junit-reports > > > > > This generates a link in the project reports to junit-reports/index.html, > which has to be populated elsewhere (e.g. by an ant task). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSANDBOX-42) plugin to facilitate downloads of snapshot plugins and dependencies for each insertion into internal repository.
[ https://jira.codehaus.org/browse/MSANDBOX-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSANDBOX-42. -- Resolution: Won't Fix outdated project, closing as won't fix. > plugin to facilitate downloads of snapshot plugins and dependencies for each > insertion into internal repository. > > > Key: MSANDBOX-42 > URL: https://jira.codehaus.org/browse/MSANDBOX-42 > Project: Maven Sandbox (retired) > Issue Type: New Feature >Reporter: brianfox brianfox >Priority: Minor > > Discussed here. > http://www.nabble.com/Re%3A-Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-p9965795s177.html > > > > Here's how I deal with instances where I need a snapshot plugin in my > > corp build: > > 1. Checkout the code for the snapshot. > > 2. Build it, changing the version to something like > > 2.0-[companyname]-svnrev 3. If I have to patch the source at all, I > > take the whole thing and put it in my svn. If not, then the svnrev in > > the release points me back to where I got it in case I need it later. > > 4. Deploy it to my repos. > > 5. Use this now "internally released" version in my builds. > > > I've done this, and also with smaller external snapshots I've downloaded them > and just adjusted the metadata (and filename) before deploying to my local > repos. > What would be really, really, really useful would be a plugin that you could > call that would download a snapshot of a project and its (transient, > snapshot) dependencies, re-label it as a fixed internal version. There's > occasions where you just can't wait for an external project to release (and > of course this problem is recursive!), and rebuilding everything yourself is > a bit drag on the person doing a release. > something like > mvn artifact:freeze-snapshot org.apache.myfaces myfaces-all 1.1.6-SNAPSHOT > 1.1.6-mycorp -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSANDBOX-43) Annotation proccessing tool plugin introduction
[ https://jira.codehaus.org/browse/MSANDBOX-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSANDBOX-43. -- Resolution: Won't Fix outdated project, closing as won't fix. > Annotation proccessing tool plugin introduction > > > Key: MSANDBOX-43 > URL: https://jira.codehaus.org/browse/MSANDBOX-43 > Project: Maven Sandbox (retired) > Issue Type: New Feature >Reporter: Juraj Burian >Priority: Minor > Attachments: maven-apt-plugin.zip > > > Hi, > I have first working and (partially) tested prototype of Apt plugin. (see > attachment) > Behavior: > - plugin is associated with phase:generate-sources. > - src/main/gen directory is the default value for generated sources. (created > if it's missing) config entry: > - src/test/gen directory is the default value for generated test sources. > config entry: > - all switches are supported except -factorypath (any suggestion how to do > it?) see copy of my yesterday mail (see bellow). > - during execution new compile source root is introduced : > project.addCompileSourceRoot( getGenerated() ); >and new resource is introduced too: > Resource resource = new Resource(); > resource.setDirectory( getGenerated() ); > resource.addExclude( "**/*.java" ); > project.addResource( resource ); > I hope that it's useful for you :-) . > Best regards & have nice day > JuBu > Yesterday mail: > Hi, > We are working on jboss-aop & APT plugins implementation. > We encountered the folowing problem (in general): > We need to split classpath into several parts. In other words, we need to > group dependencies. > For example, when running JBoss AOP it is necessary to supply classpath where > aspects are found and a different classpath where classes that should be > weaved are (ie. 2 different classpath). > We can see 2 possible solutions: > 1) Adding properties to dependency (as in Maven1). That could be used to > distinguish between different dependency groups. > 2) Adding group attribute to xml tag and allowing to have more > than one sections. group attribute would be propagated to > individual dependency objects. > 3) any other idea? > In our opinion this "dependency grouping" may be required in many plugins > (JBoss AOP, AspectJ, APT, ...). > Best regards, > JUBU -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSANDBOX-3) Rewrite of the maven-jdeveloper-plugin to use classes for IDE like in the Eclipse plugins
[ https://jira.codehaus.org/browse/MSANDBOX-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSANDBOX-3. - Resolution: Won't Fix outdated project, closing as won't fix. > Rewrite of the maven-jdeveloper-plugin to use classes for IDE like in the > Eclipse plugins > - > > Key: MSANDBOX-3 > URL: https://jira.codehaus.org/browse/MSANDBOX-3 > Project: Maven Sandbox (retired) > Issue Type: Improvement >Reporter: Sylvain Deschenes > Attachments: myplugin.diff, patch.txt > > > Following a discussion on the Maven developer List started by Brett Porter, I > have rewrited the JDeveloper plugin in order to make it use the utility > classes wich are found in the maven eclipse plugin. > I have kept the same idea wich was used by John Fallows. The plugin updates a > blank jdeveloper project with informations coming from the pom and some > additional configuration options. > It still needs some work - some of the original features are still not > implemented. For instance, it doesn't generate a test project, and it only > work with version 10.1.3. > I am planning to continue workint on it but I would like the original > author's feedback first. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSANDBOX-25) CSharp plugins don't support test-jar equivalent
[
https://jira.codehaus.org/browse/MSANDBOX-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MSANDBOX-25.
--
Resolution: Won't Fix
outdated project, closing as won't fix.
> CSharp plugins don't support test-jar equivalent
>
>
> Key: MSANDBOX-25
> URL: https://jira.codehaus.org/browse/MSANDBOX-25
> Project: Maven Sandbox (retired)
> Issue Type: Improvement
> Environment: Windows XP
>Reporter: James Carpenter
>Priority: Minor
>
> Although the csharp plugins support nunit tests, they don't provide a
> mechanism to include these as attached artifacts. This is of course
> inconvenient when one wants to share some shared test utilities, etc.
> I tried to quickly hack around the situation with the following in my pom:
>
>
>
> org.codehaus.mojo
> build-helper-maven-plugin
>
>
> attach-artifacts
> package
>
> attach-artifact
>
>
>
>
>
> ${project.build.directory}/test-dotnet-assembly/unit-tests.dll
> dotnet-library
> unit-tests
>
>
>
>
>
>
>
>
> Unfortunately, this doesn't work out. I haven't spent any more time looking
> at the issue. This is a fairly low priority issue, I post it just to be able
> to keep track.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSANDBOX-51) Rewrite Plexus Utils classes at the ASF from scratch
[ https://jira.codehaus.org/browse/MSANDBOX-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSANDBOX-51. -- Resolution: Won't Fix outdated project, closing as won't fix. > Rewrite Plexus Utils classes at the ASF from scratch > > > Key: MSANDBOX-51 > URL: https://jira.codehaus.org/browse/MSANDBOX-51 > Project: Maven Sandbox (retired) > Issue Type: New Feature >Reporter: Mark Struberg > Attachments: diff.txt, plexus-utils-tck.patch, plexus-utils-tck.patch > > > plexus-utils are 85% written by ASF committers, but we still don't have a IP > cleared history. > For cleaning this up we aim to rewrite those classes from scratch in ASF > maven sandbox. > The strategy is the following: > 1. create unit tests for the existing plexus classes > 2. create a new implementation from scratch > 3. the new implementation must be a binary API compatible drop-in replacement -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSANDBOX-26) Generic 3rd Party DotNet Libraries not appropriately handled
[ https://jira.codehaus.org/browse/MSANDBOX-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSANDBOX-26. -- Resolution: Won't Fix outdated project, closing as won't fix. > Generic 3rd Party DotNet Libraries not appropriately handled > > > Key: MSANDBOX-26 > URL: https://jira.codehaus.org/browse/MSANDBOX-26 > Project: Maven Sandbox (retired) > Issue Type: Improvement > Environment: Windows XP >Reporter: James Carpenter > > The csharp plugins work great when using .Net dependencies built with the > csharp plugins, but don't work in the general case. > Problem Statement: > (Note: As a Java developer, I might mess this up a bit.) > A .NET assembly contains a manifest which lists the assemblies it depends > upon. In addition to checking digital signatures for public assemblies, the > classloader (whatever MS calls it) expects the filenames of the dependencies > to match that described in the manifest. The problem is the maven repository > structure imposes a particular naming convention upon the artifacts placed > within it. So you can't just take a third party dll change its name to fit > into the maven repo artifact naming convention and create an associated POM. > Artifacts built by maven using the csharp plugins match the maven repo > artifact naming conventions and the assembly manifests contain dependencies > whose names are consistent with the maven repo artifact naming conventions. > Tatical Solution: > The nasty tatical solution I am currently using, is to simple refer to any > 3rd party dlls as system dependencies. (system) > Potential Strategic Solution: > I believe the solution is to create another maven artifact type to support > 3rd party dlls. The artifact actually stored in the maven repo should be an > archieve of some sort (jar, zip, etc.). During the process-resources (some > phase prior to compilation, might need custom lifecycle) phase these 3rd > party dependencies would be downloaded by the ArtifactResolver and > unarchieved in some directory structure which maintains the versioning > through directory naming, but not by file name. The dll filename would be > the same as the original name of the 3rd party dll (most likely > implementation choice is simply to let the archieve maintain the original > name). > When maven builds the classpath, any artifact of this new type would be > represented in the classpath as the path to the unarchieved dll. (The > current csharp compiler plugin sees these as the path to the local repo.) > I believe, it will actually be necessary to produce two new artifact types. > One will be used for "managed" dependencies and another for native > "unmanaged" dependencies. This distinction is important because the csc (C# > compiler) only wants to know about "managed" dependencies. (See as /resource > arguments to csc compiler. Refer to plexus csharp compiler code for details.) > I'm not sure my proposed solution is 100% accurate, as I still don't know the > maven internals that well, but I think its close. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPCASTOR-14) update dependency to org.codehaus.castor and upgrade plugin to SourceGeneratorMain
[ https://jira.codehaus.org/browse/MPCASTOR-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPCASTOR-14. -- Resolution: Won't Fix Project has been retired, closing as won't fix. > update dependency to org.codehaus.castor and upgrade plugin to > SourceGeneratorMain > -- > > Key: MPCASTOR-14 > URL: https://jira.codehaus.org/browse/MPCASTOR-14 > Project: Maven 1.x Castor Plugin > Issue Type: Improvement >Reporter: nicolas de loof >Priority: Minor > Attachments: castor.patch > > > Castor has moved to codehaus, and many deprecated methods have been removed. > 0.9.5 generated code is not compatible with latests castor builds. > the pactch updates dependencies and use the SourceGeneratorMain class > (SourceGenerator is deprecated) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJIRA-9) generate changes.xml from jira query
[ https://jira.codehaus.org/browse/MPJIRA-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJIRA-9. --- Resolution: Won't Fix Project has been retired, closing as won't fix. > generate changes.xml from jira query > > > Key: MPJIRA-9 > URL: https://jira.codehaus.org/browse/MPJIRA-9 > Project: Maven 1.x JIRA Plugin > Issue Type: New Feature >Reporter: Ryan Sonnek > > since JIRA has all of the roadmap/changelog information, it would be really > sweet to have the jira plugin update the changes.xml for a project. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPREPO-1) delete old timestamped snapshot artifacts
[ https://jira.codehaus.org/browse/MPREPO-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPREPO-1. --- Resolution: Won't Fix Project has been retired, closing as won't fix. > delete old timestamped snapshot artifacts > - > > Key: MPREPO-1 > URL: https://jira.codehaus.org/browse/MPREPO-1 > Project: Maven 1.x Repository Plugin > Issue Type: Improvement >Reporter: Ryan Sonnek > Attachments: ArtifactUtil.java, CleanSnapshots.java, > CleanSnapshotsTest.java > > > add a task/goal to delete old timestamped snapshot artifacts from the local > repository. It should not delete the artifact's SNAPSHOT or the newest > timestamped file (which should be the same as the snapshot). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJCOVERAGE-11) Place generated files, like jcoverage.ser and HEAD.xml in the target directory
[ https://jira.codehaus.org/browse/MPJCOVERAGE-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJCOVERAGE-11. - Resolution: Won't Fix Project has been retired, closing as won't fix. > Place generated files, like jcoverage.ser and HEAD.xml in the target directory > -- > > Key: MPJCOVERAGE-11 > URL: https://jira.codehaus.org/browse/MPJCOVERAGE-11 > Project: Maven 1.x JCoverage Plugin > Issue Type: Improvement >Affects Versions: 1.0.4 >Reporter: Paul Spencer >Priority: Minor > > Jcoverage currently places 3 files in the project's root directory, > jcoverage.ser and 2 XML files. Since these files are generated, they should > be placed somewhere in the target directory tree. This would accomplish the > following: > o The files will be deleted by "maven clean" without then need for > in plugin.jelly > o Prevent the need to change to .cvsignore since the files should > not be in the CVS repository. > o Remove a collision when the old or new tag matches a file in the > project's home directory. Imagine the problems cause by the > following: >maven.jdiff.old.tag=maven >maven.jdiff.new.tag=project -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPDIST-31) Move consolidated javadocs into multiproject:site.
[ https://jira.codehaus.org/browse/MPDIST-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPDIST-31. Resolution: Won't Fix Project has been retired, closing as won't fix. > Move consolidated javadocs into multiproject:site. > -- > > Key: MPDIST-31 > URL: https://jira.codehaus.org/browse/MPDIST-31 > Project: Maven 1.x Distribution Plugin > Issue Type: Task >Affects Versions: 1.7 >Reporter: Lukas Theussl > > Makes more sense there. However, we'll need to release another version of the > multiproject plugin. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPCHECKSTYLE-39) The checkstyle report should use the maven.xdoc.locale.default
[ https://jira.codehaus.org/browse/MPCHECKSTYLE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPCHECKSTYLE-39. -- Resolution: Won't Fix Project has been retired, closing as won't fix. > The checkstyle report should use the maven.xdoc.locale.default > -- > > Key: MPCHECKSTYLE-39 > URL: https://jira.codehaus.org/browse/MPCHECKSTYLE-39 > Project: Maven 1.x Checkstyle Plugin > Issue Type: Wish >Affects Versions: 2.5 > Environment: maven 1.1 beta 2 >Reporter: Arnaud Heritier > Fix For: 3.0 > > > The checkstyle locale is actually defined from the JVM and not from the > property : maven.xdoc.locale.default > If I have a project with maven.xdoc.locale.default=En but I build it on a > french system, the checkstyle report will be generated in French. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJAVADOC-74) [ Junit plugin ] Add javadoc for the junit tests
[ https://jira.codehaus.org/browse/MPJAVADOC-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJAVADOC-74. --- Resolution: Won't Fix Project has been retired, closing as won't fix. > [ Junit plugin ] Add javadoc for the junit tests > > > Key: MPJAVADOC-74 > URL: https://jira.codehaus.org/browse/MPJAVADOC-74 > Project: Maven 1.x Javadoc Plugin > Issue Type: New Feature >Reporter: Peter Lynch >Priority: Minor > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > There is no javadoc for the unit test files. We should add this as a new > feature. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJBOSS-13) SAR support
[ https://jira.codehaus.org/browse/MPJBOSS-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJBOSS-13. - Resolution: Won't Fix Project has been retired, closing as won't fix. > SAR support > --- > > Key: MPJBOSS-13 > URL: https://jira.codehaus.org/browse/MPJBOSS-13 > Project: Maven 1.x JBoss Plugin > Issue Type: New Feature >Reporter: Janne Kario >Priority: Minor > > Support for creating and deploying JBoss specific SAR packages (eg. goals > jboss:sar, jboss:deploy-sar, jboss:deploy-exploded-sarfile and > jboss:sar-install as well as jboss:sar-deploy for deploying artifact to > repositories). > jboss:sar would be an almost exact replicate of ear:ear. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJCOVERAGE-27) JCoverage link in project reports should open in a new window just as javadoc does
[ https://jira.codehaus.org/browse/MPJCOVERAGE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJCOVERAGE-27. - Resolution: Won't Fix Project has been retired, closing as won't fix. > JCoverage link in project reports should open in a new window just as javadoc > does > -- > > Key: MPJCOVERAGE-27 > URL: https://jira.codehaus.org/browse/MPJCOVERAGE-27 > Project: Maven 1.x JCoverage Plugin > Issue Type: Improvement >Reporter: thierry lach >Priority: Minor > > JCoverage link in project reports should open in a new window just as javadoc > does. When it replaces the existing documentation with its menu, it > complicates navigation of the docs. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJBUILDER-14) Have a goal creating a project librairy from a maven project
[
https://jira.codehaus.org/browse/MPJBUILDER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPJBUILDER-14.
Resolution: Won't Fix
Project has been retired, closing as won't fix.
> Have a goal creating a project librairy from a maven project
>
>
> Key: MPJBUILDER-14
> URL: https://jira.codehaus.org/browse/MPJBUILDER-14
> Project: Maven 1.x JBuilder Plugin
> Issue Type: New Feature
>Affects Versions: 1.5
>Reporter: Henri Tremblay
>
> I've developed a JBuilder plugin that creates a project librairy. The created
> librairy if the added (manually) to the JBuilder project which is normally in
> the same directory as the project.xml.
> And so I have a jbuilder project having all the correct dependencies. I'm not
> using the usual JBuilder plugin goals because I want to be able to have my
> own JBuilder project with for example the code formatting setup and the maven
> project as no information about that.
> Here's the diff from head:
> Index: plugin.jelly
> ===
> RCS file: /home/cvspublic/maven-plugins/jbuilder/plugin.jelly,v
> retrieving revision 1.24
> diff -b -r1.24 plugin.jelly
> 562a563,589
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > JBuilder Library Definition File
> > ${fileName}
> >
> >
> >
> > > value="${maven.repo.local}/${lib.artifactDirectory}/${lib.getType()}s/${lib.getArtifact()}"
> > />
> > > value="${jarPath}"/>
> >
> >
> >
> >
> >
> >
> > Creating ${fileName}.library ...
> >
> I understand that parts of the code might be redundant with the librairy
> generator already in the plugin. I'll let you do the needed refactoring.
> BTW, this goal is a modified version of a plugin developed by Dominique
> Collette.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPECLIPSE-70) Make it possible to add linked resources
[
https://jira.codehaus.org/browse/MPECLIPSE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPECLIPSE-70.
---
Resolution: Won't Fix
Project has been retired, closing as won't fix.
> Make it possible to add linked resources
>
>
> Key: MPECLIPSE-70
> URL: https://jira.codehaus.org/browse/MPECLIPSE-70
> Project: Maven 1.x Eclipse Plugin
> Issue Type: Improvement
>Affects Versions: 1.9
>Reporter: Felipe Leme
>Priority: Minor
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> I have some projects that share some common Java files (in a ../common
> directory) and I need to access that directory as a source tree (I know that
> having multiple source directory is not the maven way of doing things, but
> sometimes that's a need).
> So, one way to do this is creating a folder on the project as a link to an
> existing one in the filesystem (or to an Eclipse variable). If I do so on
> Eclipse, it generates an entry like the following in .project:
>
>
> folder_A
> 2
> FOLDER_VARIABLE_NAME
>
>
> file_B
> 1
> /folder/location/on/filesystem
>
>
> So, I think it would be nice to have a property (similar to what we have on
> the natures element) to add such links. Something like this:
> maven.eclipse.links=folderA, fileB
> maven.eclipse.links.folderA.name=folder_A
> maven.eclipse.links.folderA.type=2
> maven.eclipse.links.folderA.location=FOLDER_VARIABLE_NAME
> maven.eclipse.links.fileB.name=file_B
> maven.eclipse.links.fileB.type=1
> maven.eclipse.links.fileB.location=/folder/location/on/filesystem
> Optional, we could eliminate the need for a type variable by using variable
> or path:
> maven.eclipse.links.folderA.name=folder_A
> maven.eclipse.links.folderA.variable=FOLDER_VARIABLE_NAME
> maven.eclipse.links.fileB.name=file_B
> maven.eclipse.links.fileB.path=/folder/location/on/filesystem
>
>
>
> ${maven.eclipse.links}
>
>
>
>
>
>
> ${context.getVariable(name)}
> ${context.getVariable(link)}
> ${context.getVariable(location)}
>
>
>
> -- Felipe
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPCHANGES-33) Make it possible to configure the location of the changes.xml file
[ https://jira.codehaus.org/browse/MPCHANGES-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPCHANGES-33. --- Resolution: Won't Fix Project has been retired, closing as won't fix. > Make it possible to configure the location of the changes.xml file > -- > > Key: MPCHANGES-33 > URL: https://jira.codehaus.org/browse/MPCHANGES-33 > Project: Maven 1.x Changes Plugin > Issue Type: New Feature >Affects Versions: 1.7 >Reporter: Dennis Lundberg > Fix For: 1.7.1 > > Attachments: MPCHANGES-33.patch > > > It is useful for people that are in a transition from Maven 1 to Maven 2 to > be able to move the changes.xml file to another location that the default > one. The attached patch introduces a new property "maven.changes.file" that > can be used to configure the location of the file. The default value is the > same as what has been used in the previous versions. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPDIST-30) Dist plugin should take into account the javadoc properties
[ https://jira.codehaus.org/browse/MPDIST-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPDIST-30. Resolution: Won't Fix Project has been retired, closing as won't fix. > Dist plugin should take into account the javadoc properties > --- > > Key: MPDIST-30 > URL: https://jira.codehaus.org/browse/MPDIST-30 > Project: Maven 1.x Distribution Plugin > Issue Type: Improvement >Affects Versions: 1.7 > Environment: Win 2K, JDK 1.6 b2 >Reporter: Benoit Xhenseval > > 1/ The consolidated javadoc does not seem to take into account any javadoc > settings, nor use any default like: > maven.javadoc.bottom (for copyright stuff). > 2/ I also seems to complain (just warnings) that the classpath does not > include reference to the dependencies jars (hence it cannot link to some > imported classes, eg: > [javadoc] > C:\project\objectlabkit\datecalc-joda\src\main\java\net\objectlab\kit\datecalc\joda\HolidayHandlerYearMonthDayWrapper.java:23: > package org.joda.time does not exist > [javadoc] import org.joda.time.LocalDate; > [javadoc] ^ > May be it could include the dependencies by default? > Thanks -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJAR-27) Send e-mail after successfully deploying jars and jar snapshots
[ https://jira.codehaus.org/browse/MPJAR-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJAR-27. --- Resolution: Won't Fix Project has been retired, closing as won't fix. > Send e-mail after successfully deploying jars and jar snapshots > --- > > Key: MPJAR-27 > URL: https://jira.codehaus.org/browse/MPJAR-27 > Project: Maven 1.x Jar Plugin > Issue Type: New Feature >Reporter: Boris Boehlen > > It would be great if an e-mail is send after successfully deploying jars and > jar snapshots. This way developers would know that a new version has been > uploaded to the repository. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIDEA-41) A new property where I can set a comma separated list of excluded directories
[ https://jira.codehaus.org/browse/MPIDEA-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPIDEA-41. Resolution: Won't Fix Project has been retired, closing as won't fix. > A new property where I can set a comma separated list of excluded directories > - > > Key: MPIDEA-41 > URL: https://jira.codehaus.org/browse/MPIDEA-41 > Project: Maven 1.x IDEA Plugin > Issue Type: New Feature >Affects Versions: 1.6 >Reporter: rossmason rossmason > > This is usful for for exculding things like xdoc and lib dirs -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPPDF-58) Upgrade to use FOP 0.93
[ https://jira.codehaus.org/browse/MPPDF-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPPDF-58. --- Resolution: Won't Fix Project has been retired, closing as won't fix. > Upgrade to use FOP 0.93 > --- > > Key: MPPDF-58 > URL: https://jira.codehaus.org/browse/MPPDF-58 > Project: Maven 1.x PDF Plugin > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Arnaud Heritier >Priority: Minor > > FOP 0.93 is just released. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJBUILDER-12) Generate WAR/EJB modules in project file
[ https://jira.codehaus.org/browse/MPJBUILDER-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJBUILDER-12. Resolution: Won't Fix Project has been retired, closing as won't fix. > Generate WAR/EJB modules in project file > > > Key: MPJBUILDER-12 > URL: https://jira.codehaus.org/browse/MPJBUILDER-12 > Project: Maven 1.x JBuilder Plugin > Issue Type: Improvement >Affects Versions: 1.4 > Environment: JBX, WinXP >Reporter: Dan Tran > > Hi I have a patch that can generate WAR and EJB modules for project file. > But I only tested the patch on JBX. Can someone test the patch on older > versions of JB? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJBUILDER-15) Allow defenition of short list for goals shown
[ https://jira.codehaus.org/browse/MPJBUILDER-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJBUILDER-15. Resolution: Won't Fix Project has been retired, closing as won't fix. > Allow defenition of short list for goals shown > -- > > Key: MPJBUILDER-15 > URL: https://jira.codehaus.org/browse/MPJBUILDER-15 > Project: Maven 1.x JBuilder Plugin > Issue Type: New Feature > Environment: Windows XP. Jbuilder Enterprise X. Maven 1.0 >Reporter: Marteijn Nouwens >Priority: Minor > > It would be nice to allow the user to define a list of most often used goals > so that it is easier to navigate. > project.xml >- goal 1 >- goal 2 >- goal 3 >- goal x >- other goals > - current view of goals > I think this should be an improvement since most developers only use 3 to 5 > goals from their ide. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPJCOVERAGE-24) Prevent duplicate execution of JUnit testcases
[ https://jira.codehaus.org/browse/MPJCOVERAGE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPJCOVERAGE-24. - Resolution: Won't Fix Project has been retired, closing as won't fix. > Prevent duplicate execution of JUnit testcases > -- > > Key: MPJCOVERAGE-24 > URL: https://jira.codehaus.org/browse/MPJCOVERAGE-24 > Project: Maven 1.x JCoverage Plugin > Issue Type: Improvement >Reporter: Nascif A. Abousalh-Neto > > Currently if a project uses both JUnit and JCoverage reports, the unit > testcases are executed twice. This has been solved by Clover with an extra > property that instruments the code before the first (junit-report) run, and > the uses the result to generate the report in the second (jcoverage-report) > run. > See http://jira.codehaus.org/browse/MPCLOVER-18 for details. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MAVENUPLOAD-2819) Upload request for new version of jcifs: 1.3.17
[ https://jira.codehaus.org/browse/MAVENUPLOAD-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MAVENUPLOAD-2819. --- Resolution: Won't Fix > Upload request for new version of jcifs: 1.3.17 > --- > > Key: MAVENUPLOAD-2819 > URL: https://jira.codehaus.org/browse/MAVENUPLOAD-2819 > Project: Maven Upload Requests (retired) > Issue Type: Wish >Reporter: Pontus Ullgren > Attachments: jcifs-1.3.17-bundle.jar > > > http://jcifs.samba.org/ > JCIFS is an Open Source client library that implements the CIFS/SMB > networking protocol in 100% Java. CIFS is the standard file sharing protocol > on the Microsoft Windows platform (e.g. Map Network Drive ...). This client > is used extensively in production on large Intranets. > The bundle jar with a classes jar, sources jar and java-doc jar, is attached. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPCHECKSTYLE-20) Unable to get class information for custom exceptions
[ https://jira.codehaus.org/browse/MPCHECKSTYLE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPCHECKSTYLE-20. -- Resolution: Won't Fix Project has been retired, closing as won't fix. > Unable to get class information for custom exceptions > - > > Key: MPCHECKSTYLE-20 > URL: https://jira.codehaus.org/browse/MPCHECKSTYLE-20 > Project: Maven 1.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: maven-1.0-rc2 >Reporter: Ryan Sonnek > > checkstyle reports an error "Unable to get class information" for custom > exceptions within the same project. it is able to load exceptions that are > listed as dependencies for the project, but not for other exceptions. one > workaround is to only use throws Exception in the signiture, but that's > really a hack. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MAVENUPLOAD-2823) Sync between DataNucleus M2 repo and Maven Central is broken
[ https://jira.codehaus.org/browse/MAVENUPLOAD-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MAVENUPLOAD-2823. --- Resolution: Won't Fix Project has been retired, closing as won't fix. > Sync between DataNucleus M2 repo and Maven Central is broken > > > Key: MAVENUPLOAD-2823 > URL: https://jira.codehaus.org/browse/MAVENUPLOAD-2823 > Project: Maven Upload Requests (retired) > Issue Type: Bug >Reporter: DN > > This was set up a long time ago to sync between > http://www.datanucleus.org/downloads/maven2/ > (groupId=org.datanucleus) > and Maven Central repo (there is an entry in .ssh/authorized_keys that was > provided by someone on the Maven/Codehaus team, and worked great for a very > long time). Seems to have been broken before 9th Aug. Nothing has changed at > the DataNucleus end that I'm aware of. > Thanks -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MAVENUPLOAD-2819) Upload request for new version of jcifs: 1.3.17
[ https://jira.codehaus.org/browse/MAVENUPLOAD-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362259#comment-362259 ] Michael Osipov commented on MAVENUPLOAD-2819: - Project has been retired, closing as won't fix. > Upload request for new version of jcifs: 1.3.17 > --- > > Key: MAVENUPLOAD-2819 > URL: https://jira.codehaus.org/browse/MAVENUPLOAD-2819 > Project: Maven Upload Requests (retired) > Issue Type: Wish >Reporter: Pontus Ullgren > Attachments: jcifs-1.3.17-bundle.jar > > > http://jcifs.samba.org/ > JCIFS is an Open Source client library that implements the CIFS/SMB > networking protocol in 100% Java. CIFS is the standard file sharing protocol > on the Microsoft Windows platform (e.g. Map Network Drive ...). This client > is used extensively in production on large Intranets. > The bundle jar with a classes jar, sources jar and java-doc jar, is attached. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPA-94) Clean up patch submission
[ https://jira.codehaus.org/browse/MPA-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPA-94. - Resolution: Fixed All subtasks have been fixed. > Clean up patch submission > - > > Key: MPA-94 > URL: https://jira.codehaus.org/browse/MPA-94 > Project: Maven Project Administration > Issue Type: Task > Components: Issue Management >Reporter: Brett Porter > -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSTAGE-8) Add parameters for groupId and artifactId to make it possible to copy only one artifact from a staging repository
[ https://jira.codehaus.org/browse/MSTAGE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSTAGE-8. --- Resolution: Won't Fix Project has been retired, closing as won't fix. > Add parameters for groupId and artifactId to make it possible to copy only > one artifact from a staging repository > - > > Key: MSTAGE-8 > URL: https://jira.codehaus.org/browse/MSTAGE-8 > Project: Maven Stage Plugin > Issue Type: Improvement >Affects Versions: 1.0-alpha-1 >Reporter: Dennis Lundberg > > If we take the current version parameter and add groupId and artifactId > parameters, we can create a path to the artifact within the source > repository. This enables us to copy only a part of the staging repository. > If groupId is omitted, the whole staging repo is copied, just like now. > If the groupId is supplied but the artifactId is omitted, all artifacts for > that group is copied. > If groupId and artifactId is supplied, only that artifact is copied. In fact > only that *version* of that artifact is copied, since we already have the > mandatory version parameter. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSTAGE-17) copy all dependencies automatically
[ https://jira.codehaus.org/browse/MSTAGE-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSTAGE-17. Resolution: Won't Fix Project has been retired, closing as won't fix. > copy all dependencies automatically > --- > > Key: MSTAGE-17 > URL: https://jira.codehaus.org/browse/MSTAGE-17 > Project: Maven Stage Plugin > Issue Type: Bug >Reporter: Hannes Kogler > > as it seems the dependencies of the artifact are not copied automatically too. > but thats what the feature of an artifact copy from one repository to another > should be?! > or am I doing anything wrong? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSTAGE-14) DefaultRepositoryCopier rename script does not check move command exit codes
[ https://jira.codehaus.org/browse/MSTAGE-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSTAGE-14. Resolution: Won't Fix Project has been retired, closing as won't fix. > DefaultRepositoryCopier rename script does not check move command exit codes > > > Key: MSTAGE-14 > URL: https://jira.codehaus.org/browse/MSTAGE-14 > Project: Maven Stage Plugin > Issue Type: Improvement >Affects Versions: 1.0-alpha-2 >Reporter: Francis De Brabandere > > Only if the last move command fails will the plugin fail. This because the > exit code for unix scipts is the one from the last command. > Better would be to use something like this: > #!/bin/sh > touch test.txt \ > && rm test.txt \ > && rm test2.txt \ <- fails here and won't continue > && touch test2.txt \ > rm test2.txt > this script will fail even if the last 2 commands would succeed (those will > not even run) > I know this failing is something that is not common but still possible. We > actually had this issue and it took quite some time to find out why certain > builds failed and others not (depended on what the last mv command was). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSTAGE-10) Adds support for non-CommandExecutor Wagon implementations
[ https://jira.codehaus.org/browse/MSTAGE-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSTAGE-10. Resolution: Won't Fix Project has been retired, closing as won't fix. > Adds support for non-CommandExecutor Wagon implementations > -- > > Key: MSTAGE-10 > URL: https://jira.codehaus.org/browse/MSTAGE-10 > Project: Maven Stage Plugin > Issue Type: Improvement >Affects Versions: 1.0-alpha-1 >Reporter: Jacob Robertson > Attachments: maven-stage-plugin.patch > > > Here's a patch to generalize support for all Wagon implementations. Note > that we can't presume that repository uploading is batched, so it iterates > one at a time. We have been using this patched version successfully. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1138) Enabling reuseForks runs all tests in series on just one fork
[
https://jira.codehaus.org/browse/SUREFIRE-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362266#comment-362266
]
Tibor Digana commented on SUREFIRE-1138:
@Andreas
I'll have a look.
> Enabling reuseForks runs all tests in series on just one fork
> -
>
> Key: SUREFIRE-1138
> URL: https://jira.codehaus.org/browse/SUREFIRE-1138
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.18, 2.18.1
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 19:44:56+1100)
> Java version: 1.7.0_17, vendor: Oracle Corporation
> Ubuntu 12.04 LTS
>Reporter: Matthew Provis
>Assignee: Andreas Gudian
> Attachments: test.zip
>
>
> When using Surefire >= 2.18, I've encountered a problem when setting
> {{forkCount > 1}} and {{reuseForks = true}}.
> Expected behaviour:
> Tests should run simultaneously, each on a separate fork.
> Actual behaviour:
> All tests run on just one fork, sequentially.
> Setting {{reuseForks = false}} gives the expected behaviour.
> Reverting to Surefire 2.17 also gives the expected behaviour.
> I've attached a project that demonstrates the issue. Here I've created two
> tests, each of which prints the fork number and sleeps for 5 seconds. The
> total run time is 10 seconds with Surefire 2.18 and 2.18.1, but 5 seconds
> with version 2.17.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1136) Current working directory propagation in forked mode
[ https://jira.codehaus.org/browse/SUREFIRE-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362267#comment-362267 ] Tibor Digana commented on SUREFIRE-1136: commit 2b4629c71e5c82716d99a738f02063c90413253f > Current working directory propagation in forked mode > > > Key: SUREFIRE-1136 > URL: https://jira.codehaus.org/browse/SUREFIRE-1136 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 2.18.1 >Reporter: Norbert Wnuk >Assignee: Andreas Gudian >Priority: Minor > Fix For: 2.19 > > > Surefire plugin does not resolve surefire.forkNumber variable for working > directory so that the same invalid directory is set for all forked JVMs. The > same time user.dir property is propagated properly which leads to > inconsistent behavior in JDK API - > http://stackoverflow.com/questions/1234795/why-is-the-user-dir-system-property-working-in-java -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1137) Problem with Umlauts in stdout
[ https://jira.codehaus.org/browse/SUREFIRE-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362268#comment-362268 ] Tibor Digana commented on SUREFIRE-1137: @Michael @Jürgen You have contradictory results. Then do we have a bug in surefire? > Problem with Umlauts in stdout > -- > > Key: SUREFIRE-1137 > URL: https://jira.codehaus.org/browse/SUREFIRE-1137 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18 > Environment: Linux >Reporter: Jürgen Zeller >Assignee: Andreas Gudian > Attachments: surefire-test.zip > > > When using Cp1252 as file encoding, the generated Surefire stdout report > contains invalid characters when run on Linux. When running the same test on > Windows, everything is fine. > A simular Problem was reported in SUREFIRE-998 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
