[jira] Commented: (MRESOURCES-39) Filtering fails for command line properties
[ http://jira.codehaus.org/browse/MRESOURCES-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124738 ] A commented on MRESOURCES-39: - There was a propertyset in ANT where you can select only command-line options as a selector. I can't find Project and other classes' description in maven's Javadoc API so this is pure guess. I'll try the patch these days, thanks! > Filtering fails for command line properties > --- > > Key: MRESOURCES-39 > URL: http://jira.codehaus.org/browse/MRESOURCES-39 > Project: Maven 2.x Resources Plugin > Issue Type: Bug > Environment: maven-2.0.4 and maven-2.0.5 > Mac OS X >Reporter: Matt Brozowski >Priority: Critical > Attachments: filtering-bug.tar, > maven-resources-plugin-prop-filtering-r630241.patch > > > When passing a property on the command line to maven using -D it does not > properly override values passed to filters. > I have attached a sample project that defines a property in the pom.xml > called 'filtered' This property is used as a filter in the > filtered.properties file in src/main/filtered/filtered.properties. I have > also included a test that gets passed the filtered property as a System > property via the surefire plugin. It then loaded the filtered.properties > file and tests to ensure the filters match. > The tests pass when run as > mvn test > BUT if I run as > mvn -Dfiltered=from-cmd-line teset > They fail. > I have also included the antrun plugin print its perspective on the value of > the property. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1925) please upload DynamicJasper 2.0.5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124737 ] Dan Tran commented on MAVENUPLOAD-1925: --- So it seems removing the repositories element, but leave the one defined in profile alone, solves the upload requirements. Juan, could you fixup the pom and push it thru 2.0.7 release ( 2.0.6 already out) > please upload DynamicJasper 2.0.5 > - > > Key: MAVENUPLOAD-1925 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1925 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Juan Manuel Alvarez > > http://dynamicjasper.sourceforge.net/downloads/DynamicJasper-2.0.5-bundle.jar > http://dynamicjasper.sourceforge.net/ > http://dynamicjasper.sourceforge.net/team-list.html > I am DynamicJasper's project leader, please upload. > DynamicJasper (DJ) is an API that hides the complexity of Jasper Reports, it > helps developers to save time when designing simple/medium complexity reports > generating the layout of the report elements automatically. It creates > reports dynamically, defining at runtime the columns, column width (auto > width), groups, variables, fonts, charts, crosstabs, sub reports (that can > also be dynamic), page size and everything else that you can define at design > time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPLUGIN-39) adding package-info.java breaks build
[ http://jira.codehaus.org/browse/MPLUGIN-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124734 ] Kedar Mhaswade commented on MPLUGIN-39: --- I can reproduce this issue on maven build 2.0.7 with Mac OS X. > adding package-info.java breaks build > - > > Key: MPLUGIN-39 > URL: http://jira.codehaus.org/browse/MPLUGIN-39 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Environment: Windows XP, Java 5, maven 2.0.7 >Reporter: Florian Kleedorfer >Priority: Minor > Attachments: MPLUGIN-39.patch > > > As soon as I add a package-info.java file to the package of my mojo, the > build breaks with the following output: > [INFO] [plugin:descriptor] > [INFO] Using 2 extractors. > [INFO] Applying extractor for language: java > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] 0 > [INFO] > > [DEBUG] Trace > java.lang.ArrayIndexOutOfBoundsException: 0 > at > org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.getJavaClass(JavaMojoDescriptorExtractor.java:534) > at > org.apache.maven.tools.plugin.extractor.java.JavaMojoDescriptorExtractor.execute(JavaMojoDescriptorExtractor.java:553) > at > org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:84) > at > org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:135) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Wed Oct 17 11:48:52 CEST 2007 > [INFO] Final Memory: 4M/1016M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-226) Make XML based parsers better handle whitespace
Make XML based parsers better handle whitespace
---
Key: DOXIA-226
URL: http://jira.codehaus.org/browse/DOXIA-226
Project: Maven Doxia
Issue Type: Improvement
Reporter: Benjamin Bentmann
Regarding whitespace in XML documents, one needs to consider the following
aspects:
- ignorable whitespace, i.e. view "{{ }}" and
"{{}}" as equivalent
- collapsible whitespace, i.e. view "{{Text Text}}" and "{{Text Text}}"
as equivalent
- trimmable whitespace, i.e. view "{{ Text }}" and "{{Text}}"
as equivalent
Those distinctions require a DTD/XSD in combination with a validating parser
and/or application-specific knowledge. For robustness, doxia parsers for
XML-based formats should not depend on the existence of a schema definition
such that they reliably deliver events into the sinks. Hence I suggest to
hard-code the required logic for proper whitespace handling into each parser.
Currently, whitespace handling is rather static, e.g. {{XhtmlBaseParser}}
pushes all input whitespace into the sink. This might cause troubles with sinks
that are not expected to receive ignorable whitespace. To address this issue,
it seems helpful if {{AbstractXmlParser}} provided a default implementation of
{{handleText()}} that subclasses can simply control via state flags instead of
implementing {{handleText()}} from scratch in each parser. Copy&Paste - which
caused DOXIA-225 - needs to be avoided.
More precisely, I image the following changes:
- Have {{AbstractXmlParser}} maintain a stack of tuples (ignorable,
collapsible, trimmable) where each tuple describes the whitespace handling for
the currently parsed element
- Have {{AbstractXmlParser}} push/pop a tuple from this stack before/after
calling {{handleStartTag()}}/{{handleEndTag()}}
- Have {{AbstractXmlParser}} provide setters to allow subclasses to control the
desired whitespace handling in their {{handleStartTag()}} implementation
- Have {{AbstractXmlParser}} implement {{handleText()}} where it evalutes the
top-most tuple from the stack
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1892) SableCC 3.2 upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124720 ] Paul Donohue commented on MAVENUPLOAD-1892: --- The "released" version of sablecc is just a zip file of the source code. It does actually contain a compiled .jar file, but it's in a subdirectory, and I hadn't previously noticed it was there... (I only noticed just now when I went back to double check it) Since I had assumed there was only source code in the zip file, I had compiled it myself ... not because I needed my own version of it, but because I didn't realize there was an original version that was already compiled... I also didn't realize that it mattered whether it was compiled with jdk 1.5 or 1.6, until the developer for the sablecc-maven-plugin mentioned it. The .jar file from the original .zip file for sablecc is compiled using jdk 1.5, so I've updated the bundle at http://psd.umd.edu/sablecc-3.2a-bundle.jar to contain the original .jar file from the original .zip file from http://sablecc.org/wiki/DownloadPage instead of the .jar file that I compiled myself. Sorry for the confusion ... > SableCC 3.2 upload > -- > > Key: MAVENUPLOAD-1892 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1892 > Project: maven-upload-requests > Issue Type: Improvement >Reporter: Paul Donohue >Assignee: Carlos Sanchez > > http://psd.umd.edu/sablecc-3.2-bundle.jar > http://www.sablecc.org/ > I am not a developer for SableCC. > SableCC 3.1 is currently in the repository. > SableCC 3.2 was released ~3 years ago, and is still the latest stable version > (the unstable version 4.0 is still under active development). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-64) Deploy to locale repository cuts the pom
[ http://jira.codehaus.org/browse/MDEPLOY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124719 ] Olivier Lamy commented on MDEPLOY-64: - You mean your local repository is the same as your repository configured in your distributionManagement ? IMHO this configuration has not to be used! (currently that's why it failed) > Deploy to locale repository cuts the pom > > > Key: MDEPLOY-64 > URL: http://jira.codehaus.org/browse/MDEPLOY-64 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Martin Ritz > > Within the release process maven deploy the artifact to my locale repository. > The Build is displayed as an successfull build. But my project pom which is > delivered to the locale repository is cutted off after some lines (between > line 80 and 95 - depends on my project). This happens for alle project i have > released yet (3). How can i fix/ avoid this error? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEPLOY-63) Allow disabling deployment for artifacts that should not be deployed
[ http://jira.codehaus.org/browse/MDEPLOY-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MDEPLOY-63. --- Assignee: Olivier Lamy Resolution: Fixed fixed in rev 630347. > Allow disabling deployment for artifacts that should not be deployed > > > Key: MDEPLOY-63 > URL: http://jira.codehaus.org/browse/MDEPLOY-63 > Project: Maven 2.x Deploy Plugin > Issue Type: Task >Affects Versions: 2.3 >Reporter: Vincent Massol >Assignee: Olivier Lamy > Fix For: 2.4 > > > In my cargo build I have some projects producing artifacts that are purely > used for functional tests. I'd like a way to tell m2 not to deploy those when > "mvn deploy" is called at the top level. > jdcasey suggested on IRC: " I'd say you would need a flag in the > deploy plugin's config, or a or something..." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1892) SableCC 3.2 upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124713 ] Carlos Sanchez commented on MAVENUPLOAD-1892: - why dont you use the one released by them? your are not supposed to provide your version of a project, only their original version. you can put your version in your groupId > SableCC 3.2 upload > -- > > Key: MAVENUPLOAD-1892 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1892 > Project: maven-upload-requests > Issue Type: Improvement >Reporter: Paul Donohue >Assignee: Carlos Sanchez > > http://psd.umd.edu/sablecc-3.2-bundle.jar > http://www.sablecc.org/ > I am not a developer for SableCC. > SableCC 3.1 is currently in the repository. > SableCC 3.2 was released ~3 years ago, and is still the latest stable version > (the unstable version 4.0 is still under active development). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1892) SableCC 3.2 upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124707 ] Paul Donohue commented on MAVENUPLOAD-1892: --- Yes, I recompiled it using jdk 1.5 instead of jdk 1.6 > SableCC 3.2 upload > -- > > Key: MAVENUPLOAD-1892 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1892 > Project: maven-upload-requests > Issue Type: Improvement >Reporter: Paul Donohue >Assignee: Carlos Sanchez > > http://psd.umd.edu/sablecc-3.2-bundle.jar > http://www.sablecc.org/ > I am not a developer for SableCC. > SableCC 3.1 is currently in the repository. > SableCC 3.2 was released ~3 years ago, and is still the latest stable version > (the unstable version 4.0 is still under active development). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3259. --- Resolution: Fixed I just tested this on OS X and WinXP, using maven 2.0.7, 2.0.8, and 2.0.9-SNAPSHOT from revId: 630321. All of my tests used JDK 1.4. In the cases of 2.0.8 and 2.0.9-SNAPSHOT on OS X, it didn't fail. In the cases of 2.0.7 and 2.0.8 on WinXP, it failed. In the case of 2.0.9-SNAPSHOT on WinXP, it didn't fail. I'm not sure, but it looks like it has been fixed inadvertently...not a great thing to say, but there you go. I'd welcome some more eyes on this issue, to see if you can prove me wrong/crazy/something. I built a distro from that revision, and parked it here: http://people.apache.org/~jdcasey/maven-drops/2.0.9-SNAPSHOT Please reopen this issue if you can't replicate my success. > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8 >Reporter: Joerg Schaible >Assignee: John Casey >Priority: Blocker > Fix For: 2.0.9 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5 hours > Remaining Estimate: 0 minutes > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRESOURCES-39) Filtering fails for command line properties
[ http://jira.codehaus.org/browse/MRESOURCES-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MRESOURCES-39: Attachment: maven-resources-plugin-prop-filtering-r630241.patch The problem seems to be that the resources plugin first adds all the system properties to it's properties object, then adds properties from project.getProperties(). So the project properties override the system properties. The patch reverses this order, and changes one test case to reflect this change. The only problem I see is if you wanted to override some default system property (for example "user.home") in your pom, you wouldn't be able to do this anymore. I didn't find any easy way to get just the command line props from within the plugin, but if this was possible it would probably be a better solution. > Filtering fails for command line properties > --- > > Key: MRESOURCES-39 > URL: http://jira.codehaus.org/browse/MRESOURCES-39 > Project: Maven 2.x Resources Plugin > Issue Type: Bug > Environment: maven-2.0.4 and maven-2.0.5 > Mac OS X >Reporter: Matt Brozowski >Priority: Critical > Attachments: filtering-bug.tar, > maven-resources-plugin-prop-filtering-r630241.patch > > > When passing a property on the command line to maven using -D it does not > properly override values passed to filters. > I have attached a sample project that defines a property in the pom.xml > called 'filtered' This property is used as a filter in the > filtered.properties file in src/main/filtered/filtered.properties. I have > also included a test that gets passed the filtered property as a System > property via the surefire plugin. It then loaded the filtered.properties > file and tests to ensure the filters match. > The tests pass when run as > mvn test > BUT if I run as > mvn -Dfiltered=from-cmd-line teset > They fail. > I have also included the antrun plugin print its perspective on the value of > the property. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEPLOY-45) Classifier not supported by deploy:deploy
[ http://jira.codehaus.org/browse/MDEPLOY-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124703 ] Olivier Lamy commented on MDEPLOY-45: - Could you provide a simple test project to reproduce the issue ? With it we can test the patch and integrate the project as an it test. Thanks! > Classifier not supported by deploy:deploy > - > > Key: MDEPLOY-45 > URL: http://jira.codehaus.org/browse/MDEPLOY-45 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Fabian Bauschulte >Priority: Critical > Fix For: 2.4 > > Attachments: MDEPLOY-45-maven-deploy-plugin.patch > > > I am using classifieres in some projects (jar, war, ear) and installing the > artefacts works fine. I am getting an Exception during the deployment of the > artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-225) DocBookParser swallows significant whitespace
[
http://jira.codehaus.org/browse/DOXIA-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIA-225.
---
Assignee: Lukas Theussl
Resolution: Fixed
Fix Version/s: 1.0-beta-1
Applied in r630310, thanks!
However, I prefer to leave the text handling to the implementation, at least
for now. Sure, we could reduce some code duplication but I don't know if the
current behavior is sensible as a default. I don't remember the exact reason
but I introduced the splitting only to make the identity tests pass
(http://svn.apache.org/viewvc?view=rev&revision=583455), but in principle I
don't see why a parser should emit separate text events for each new line.
> DocBookParser swallows significant whitespace
> -
>
> Key: DOXIA-225
> URL: http://jira.codehaus.org/browse/DOXIA-225
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Docbook Simple
>Reporter: Benjamin Bentmann
>Assignee: Lukas Theussl
> Fix For: 1.0-beta-1
>
> Attachments: significant-whitespace.patch
>
>
> The same as DOXIA-222 just for another XML parser. The patch is defensive and
> copies the fix from XhtmlBaseParser around just like the orginal code was
> copy&paste. However, I believe it would make sense to move this
> implementation of {{handleText()}} into {{AbstractXmlParser}} such that the
> various XML parsers get this behaviour out-of-the-box. Those that need
> different handling can still override the method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1942) jline 0.9.94
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1942. --- Resolution: Fixed > jline 0.9.94 > > > Key: MAVENUPLOAD-1942 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1942 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jason Dillon >Assignee: Carlos Sanchez > > JLine 0.9.94 update, with some fixes for use w/Java 4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1939) Upload Checkstyle 4.4 bundles
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1939. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload Checkstyle 4.4 bundles > - > > Key: MAVENUPLOAD-1939 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1939 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Oliver Burn >Assignee: Carlos Sanchez > Attachments: checkstyle-4.4-bundle.jar, > checkstyle-optional-4.4-bundle.jar > > > I am the developer of Checkstyle. Attached are the bundles for version 4.4 of > Checkstyle for inclusion into the repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1922) JSTags is a Java Open Source Tags Library whose aim is to provide a set of easy-to-use tags which perform JavaScript related tasks.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1922. --- Assignee: Carlos Sanchez Resolution: Fixed > JSTags is a Java Open Source Tags Library whose aim is to provide a set of > easy-to-use tags which perform JavaScript related tasks. > --- > > Key: MAVENUPLOAD-1922 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1922 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Soraya Sanchez >Assignee: Carlos Sanchez > > http://jstags.sourceforge.net/bundles/jstags-lib-1.1-bundle.jar > http://jstags.sourceforge.net > http://jstags.sourceforge.net/team-list.html > JSTags is a Java Open Source Tags Library whose aim is to provide a set of > easy-to-use tags which perform common tasks that, otherwise, would have to be > implemented by means of JavaScript code. By using JSTags, it is as simple as > including a tag instead of having to create JavaScript code yourself...you > just forget about that part. > Please, upload this. > Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1941) Please update strutstestcase to version 2.1.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1941. --- Assignee: Carlos Sanchez Resolution: Duplicate > Please update strutstestcase to version 2.1.4 > - > > Key: MAVENUPLOAD-1941 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1941 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Yuriy Tumakha >Assignee: Carlos Sanchez > Attachments: strutstestcase-2.1.4-1.2-2.4-bundle.jar > > > Download strutstestcase 2.1.4 > http://sourceforge.net/project/showfiles.php?group_id=39190 > StrutsTestCase directory on repository > http://repo1.maven.org/maven2/strutstestcase/strutstestcase/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1931) Please update strutstestcase to version 2.1.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1931. --- Assignee: Carlos Sanchez Resolution: Fixed > Please update strutstestcase to version 2.1.4 > - > > Key: MAVENUPLOAD-1931 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1931 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Yuriy Tumakha >Assignee: Carlos Sanchez > Attachments: strutstestcase-2.1.4-1.2-2.4-bundle.jar, > strutstestcase-2.1.4-1.2-2.4-sources.jar, strutstestcase-2.1.4-1.2-2.4.pom, > strutstestcase-2.1.4.jar > > > Download strutstestcase 2.1.4 > http://sourceforge.net/project/showfiles.php?group_id=39190 > 1. From > http://downloads.sourceforge.net/strutstestcase/strutstest214-1.2_2.4.zip?modtime=1192154035&big_mirror=0 > extract "strutstest\strutstest-2.1.4.jar" and rename as > "strutstestcase-2.1.4.jar" > 2. Download > http://downloads.sourceforge.net/strutstestcase/strutstest-214-src.zip?modtime=1192154061&big_mirror=0 > and repack as "strutstestcase-2.1.4-1.2-2.4-sources.jar" > 3. strutstestcase-2.1.4-1.2-2.4.pom - in attachment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1934) gnu-hylafax 1.0.0-b2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124697 ] Carlos Sanchez commented on MAVENUPLOAD-1934: - can you put it in some rsync/ssh server and I'll add it to the automatic sync. groupId can't be that, should be net.sf.gnu-hylafax > gnu-hylafax 1.0.0-b2 > > > Key: MAVENUPLOAD-1934 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1934 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina > > the release is made up by 4 artifacts (4 upload bundles below) + 1 parent pom: > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-core-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-inet-ftp-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-pool-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-utils-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-1.0.0-b2.pom > Note that gnu-hylafax uses maven 2 to build, so these are official poms. > Groupid is "gnu-hylafax", which is not so good accorting maven convention, > but this is how artifacts are officially released. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1940) CLONE -Please update strutstestcase to version 2.1.4
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1940. --- Assignee: Carlos Sanchez Resolution: Duplicate > CLONE -Please update strutstestcase to version 2.1.4 > > > Key: MAVENUPLOAD-1940 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1940 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Yuriy Tumakha >Assignee: Carlos Sanchez > > Download strutstestcase 2.1.4 > http://sourceforge.net/project/showfiles.php?group_id=39190 > 1. From > http://downloads.sourceforge.net/strutstestcase/strutstest214-1.2_2.4.zip?modtime=1192154035&big_mirror=0 > extract "strutstest\strutstest-2.1.4.jar" and rename as > "strutstestcase-2.1.4.jar" > 2. Download > http://downloads.sourceforge.net/strutstestcase/strutstest-214-src.zip?modtime=1192154061&big_mirror=0 > and repack as "strutstestcase-2.1.4-1.2-2.4-sources.jar" > 3. strutstestcase-2.1.4-1.2-2.4.pom - in attachment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1935) JIntellitype 1.3.1 upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1935. --- Assignee: Carlos Sanchez Resolution: Fixed > JIntellitype 1.3.1 upload > - > > Key: MAVENUPLOAD-1935 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1935 > Project: maven-upload-requests > Issue Type: Task >Reporter: Emil A. Lefkof III >Assignee: Carlos Sanchez > > JIntellitype is a Java API for interacting with Microsoft Intellitype > commands as well as registering for Global Hotkeys in your Java application. > Have you ever wanted your Java application to use those special Play, Pause, > and Stop media keys that are on many keyboards today? Now you can! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1930) Please add ini4j to repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1930. --- Assignee: Carlos Sanchez Resolution: Fixed > Please add ini4j to repository > -- > > Key: MAVENUPLOAD-1930 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1930 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Ivan Szkiba >Assignee: Carlos Sanchez > Attachments: org.ini4j.sh > > > I'd like to add ini4j to maven repository. Project hosted on SourceForge > (script attached). > thanx > Ivan Szkiba -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1892) SableCC 3.2 upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124696 ] Carlos Sanchez commented on MAVENUPLOAD-1892: - did you recompile sablecc? > SableCC 3.2 upload > -- > > Key: MAVENUPLOAD-1892 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1892 > Project: maven-upload-requests > Issue Type: Improvement >Reporter: Paul Donohue >Assignee: Carlos Sanchez > > http://psd.umd.edu/sablecc-3.2-bundle.jar > http://www.sablecc.org/ > I am not a developer for SableCC. > SableCC 3.1 is currently in the repository. > SableCC 3.2 was released ~3 years ago, and is still the latest stable version > (the unstable version 4.0 is still under active development). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1927) Please upload JCROM 1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124694 ] Carlos Sanchez commented on MAVENUPLOAD-1927: - please dont use a folder with spaces, just put all the files in the root of the jar > Please upload JCROM 1.0 > --- > > Key: MAVENUPLOAD-1927 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1927 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Olafur Gauti Gudmundsson > > http://jcrom.googlecode.com/files/jcrom-1.0-bundle.jar > http://jcrom.org (forwards to the google-code page for JCROM) > http://code.google.com/u/oli.gauti/ > I am the project owner, please upload. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1925) please upload DynamicJasper 2.0.5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124693 ] Carlos Sanchez commented on MAVENUPLOAD-1925: - FAQ and common mistakes * I have other repositories or pluginRepositories listed in my pom, is that a problem? Yes, the central repo must be self contained, which means that all your dependencies must be already in the central repository. You need to remove the repositories and pluginRepositories entries and make sure your project still builds when your local repository cache is empty. > please upload DynamicJasper 2.0.5 > - > > Key: MAVENUPLOAD-1925 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1925 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Juan Manuel Alvarez > > http://dynamicjasper.sourceforge.net/downloads/DynamicJasper-2.0.5-bundle.jar > http://dynamicjasper.sourceforge.net/ > http://dynamicjasper.sourceforge.net/team-list.html > I am DynamicJasper's project leader, please upload. > DynamicJasper (DJ) is an API that hides the complexity of Jasper Reports, it > helps developers to save time when designing simple/medium complexity reports > generating the layout of the report elements automatically. It creates > reports dynamically, defining at runtime the columns, column width (auto > width), groups, variables, fonts, charts, crosstabs, sub reports (that can > also be dynamic), page size and everything else that you can define at design > time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1923) Please upload MessAdmin 4.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1923. --- Assignee: Carlos Sanchez Resolution: Fixed > Please upload MessAdmin 4.1 > --- > > Key: MAVENUPLOAD-1923 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1923 > Project: maven-upload-requests > Issue Type: Wish >Reporter: codehauser >Assignee: Carlos Sanchez > Attachments: MessAdmin-4.1-Bundles.zip > > > http://messadmin.sourceforge.net/maven2/4.1/MessAdmin-Core-4.1-bundle.jar > http://messadmin.sourceforge.net/maven2/4.1/MessAdmin-ClickStream-4.1-bundle.jar > http://messadmin.sourceforge.net/maven2/4.1/MessAdmin-JMX-4.1-bundle.jar > http://messadmin.sourceforge.net/maven2/4.1/MessAdmin-Serializable-4.1-bundle.jar > http://messadmin.sourceforge.net/maven2/4.1/MessAdmin-ServletStats-4.1-bundle.jar > http://messadmin.sourceforge.net/maven2/4.1/MessAdmin-SessionKiller-4.1-bundle.jar > http://messadmin.sourceforge.net/ > http://messadmin.sourceforge.net/#%5B%5BLicense%20%2F%20Contact%5D%5D > MessAdmin is a light-weigth and non-intrusive tool for monitoring Java > HttpSession. Please upload! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1907) Winstone 0.9.10
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1907. --- Resolution: Fixed > Winstone 0.9.10 > --- > > Key: MAVENUPLOAD-1907 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1907 > Project: maven-upload-requests > Issue Type: Task >Reporter: Grzegorz Slowikowski >Assignee: Carlos Sanchez > Attachments: winstone-0.9.10-bundle.jar, > winstone-lite-0.9.10-bundle.jar > > > Winstone pom.xml from project cvs repository: > http://winstone.cvs.sourceforge.net/winstone/winstone/pom.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1943) Please sync the com.hp.hpl.jena repository with the central one
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1943. --- Assignee: Carlos Sanchez Resolution: Fixed > Please sync the com.hp.hpl.jena repository with the central one > --- > > Key: MAVENUPLOAD-1943 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1943 > Project: maven-upload-requests > Issue Type: Task >Reporter: Andy Seaborne >Assignee: Carlos Sanchez > Attachments: com.hp.hpl.jena.sh, com.hp.hpl.jena.sh > > > CSV form: > "com.hp.hpl.jena","[EMAIL PROTECTED]:/var/repo","rsync_ssh","Andy > Seaborne","[EMAIL PROTECTED]",, > I am one of the developers contributing to Jena. > Domain ownership: the groupId and DNS name are the same. > http://tech.groups.yahoo.com/group/jena-dev/message/33012 is the announcement > message sent from [EMAIL PROTECTED] > If you wish to confirm [EMAIL PROTECTED] and [EMAIL PROTECTED] are the same > within HP, send an email to the first with a codeword and I'll reply from the > second. (sorry it's different emails addresses - servers for yahoo groups get > themselves on the public block list sometimes.) > (Or confirm via [EMAIL PROTECTED] as listed in the contributors in the > Sourceforge contributor URL.) > The public Maven ssh key has been added to the ~mavensync/.ssh/authorized_keys > Attached: > script version > CVS version (copy of above) > Please let me know if anything is missing or if you prefer a different format > to make it easier to manage, > Thanks - Andy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1943) Please sync the com.hp.hpl.jena repository with the central one
Please sync the com.hp.hpl.jena repository with the central one --- Key: MAVENUPLOAD-1943 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1943 Project: maven-upload-requests Issue Type: Task Reporter: Andy Seaborne Attachments: com.hp.hpl.jena.sh, com.hp.hpl.jena.sh CSV form: "com.hp.hpl.jena","[EMAIL PROTECTED]:/var/repo","rsync_ssh","Andy Seaborne","[EMAIL PROTECTED]",, I am one of the developers contributing to Jena. Domain ownership: the groupId and DNS name are the same. http://tech.groups.yahoo.com/group/jena-dev/message/33012 is the announcement message sent from [EMAIL PROTECTED] If you wish to confirm [EMAIL PROTECTED] and [EMAIL PROTECTED] are the same within HP, send an email to the first with a codeword and I'll reply from the second. (sorry it's different emails addresses - servers for yahoo groups get themselves on the public block list sometimes.) (Or confirm via [EMAIL PROTECTED] as listed in the contributors in the Sourceforge contributor URL.) The public Maven ssh key has been added to the ~mavensync/.ssh/authorized_keys Attached: script version CVS version (copy of above) Please let me know if anything is missing or if you prefer a different format to make it easier to manage, Thanks - Andy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1832) built-in property containing current timestamp
[ http://jira.codehaus.org/browse/MNG-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124682 ] Arnout Engelen commented on MNG-1832: - buildinfo is at: http://mojo.codehaus.org/buildnumber-maven-plugin/ . I don't quite see how I can use that to add a timestamp to a properties file though. IMHO there should be a proper description showing how this can be done before this issue can be considered 'fixed'. > built-in property containing current timestamp > -- > > Key: MNG-1832 > URL: http://jira.codehaus.org/browse/MNG-1832 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Michal Stochmialek > Attachments: maven-archiver_pomDelete.patch, > maven-core_defaultExpressions.patch > > > Current timestamp (time or date) is often used while filtering resources or > creating manifest in ant builds. There is no equivalent in maven. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-225) DocBookParser swallows significant whitespace
DocBookParser swallows significant whitespace
-
Key: DOXIA-225
URL: http://jira.codehaus.org/browse/DOXIA-225
Project: Maven Doxia
Issue Type: Bug
Components: Module - Docbook Simple
Reporter: Benjamin Bentmann
Attachments: significant-whitespace.patch
The same as DOXIA-222 just for another XML parser. The patch is defensive and
copies the fix from XhtmlBaseParser around just like the orginal code was
copy&paste. However, I believe it would make sense to move this implementation
of {{handleText()}} into {{AbstractXmlParser}} such that the various XML
parsers get this behaviour out-of-the-box. Those that need different handling
can still override the method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-80) Detection of report goals always fails due to class loader separation
Detection of report goals always fails due to class loader separation
-
Key: MPLUGIN-80
URL: http://jira.codehaus.org/browse/MPLUGIN-80
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: API, Plugin Plugin
Reporter: Benjamin Bentmann
{{PluginUtils}} simply invokes {{Class.forName(String)}} to load a mojo class
from the current project using its plugin class loader. However, as outlined in
[Guide to Maven
Classloading|http://maven.apache.org/guides/mini/guide-maven-classloading.html],
Maven plugins have no direct access to the classes of the current project.
Besides, wouldn't the maven-plugin-plugin's {{report}} goal need [EMAIL
PROTECTED] phase="compile"}} in order to ensure the mojo classes are existent
prior to try to load them?
Not sure about that but maybe it's worth to extend the mojo descriptor with a
flag "report" such that this info could be retrieved without reflection in some
far future but is derived by the goal extractors.
P.S: You don't need to instantiate a class just to do {{instanceof}} checking.
To check for a report mojo simply do:
{code:java}
MavenReport.class.isAssignableFrom( clazz );
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-305) Left menu not generated when run site:site outside the pom.xm directory specifying the pom.xml location with -f maven argument
Left menu not generated when run site:site outside the pom.xm directory specifying the pom.xml location with -f maven argument -- Key: MSITE-305 URL: http://jira.codehaus.org/browse/MSITE-305 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Environment: Windows XP Professional Version 2002 Service Pack 2 Reporter: Mael Caldas Priority: Critical When a run the mvn site:site outside the root pom.xml 's directory, specifying the location of the pom.xml with the -f argument, the site menu is generated empty! That is my dir structure: My_CC_View\ | |My_CC_VOB\ | |project | |___pom.xml So, I go to the My_CC_View and run the command: mvn -f My_CC_VOB/project/pom.xml site:site site:deploy The build goes ok, the site is generated, but without the left menu This is because I'm using Continuum with ClearCase, and the directory structure is aways created like this on checkout, so I have to specify the pom.xml file with the relative path, and continuum runs the maven commands on the root view directory... and that is used as the basedir, not the pom.xml 's dir... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3417) command-line properties not regarded sometimes
[ http://jira.codehaus.org/browse/MNG-3417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124672 ] avalon edited comment on MNG-3417 at 2/22/08 7:58 AM: - There could be some relationship with MNG-1992 but I see the same behavior with 2.1-snapshot as well. was (Author: avalon): There could be some relationship with MNG-1992 > command-line properties not regarded sometimes > -- > > Key: MNG-3417 > URL: http://jira.codehaus.org/browse/MNG-3417 > Project: Maven 2 > Issue Type: Bug > Components: Maven Filtering >Affects Versions: 2.0.8 >Reporter: A > Attachments: test_proj.zip > > > I'm attaching a sample project to show properties specified on the > command-line (CLI) not being regarded when filtering true. These are being > regarded for other purposes though. > Reproduce: > $ mvn test > $ cat target/test-classes/test.txt > Contents: default > $ mvn -P test.profile test > $ cat target/test-classes/test.txt > Contents: profile > $ mvn -Dtest.property='overridden' clean verify > Contents: default > $ mvn -P test.profile -Dtest.property='overridden' clean verify > Contents: profile > As you see last two results should have been "Contents: overridden". > The behavior is not completely broken though because if you try to set > "test.include.pattern" then it works fine. Thus I set as component > "filtering". This doesn't mean I've any idea where the issue lies. Test proj > is a modified version of this on > http://www.nabble.com/How-to-override-POM-properties-from-CLI-td15344487s177.html#a15605671 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3417) command-line properties not regarded sometimes
command-line properties not regarded sometimes -- Key: MNG-3417 URL: http://jira.codehaus.org/browse/MNG-3417 Project: Maven 2 Issue Type: Bug Components: Maven Filtering Affects Versions: 2.0.8 Reporter: A Attachments: test_proj.zip I'm attaching a sample project to show properties specified on the command-line (CLI) not being regarded when filtering true. These are being regarded for other purposes though. Reproduce: $ mvn test $ cat target/test-classes/test.txt Contents: default $ mvn -P test.profile test $ cat target/test-classes/test.txt Contents: profile $ mvn -Dtest.property='overridden' clean verify Contents: default $ mvn -P test.profile -Dtest.property='overridden' clean verify Contents: profile As you see last two results should have been "Contents: overridden". The behavior is not completely broken though because if you try to set "test.include.pattern" then it works fine. Thus I set as component "filtering". This doesn't mean I've any idea where the issue lies. Test proj is a modified version of this on http://www.nabble.com/How-to-override-POM-properties-from-CLI-td15344487s177.html#a15605671 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-222) XhtmlBaseParser swallows significant whitespace
[ http://jira.codehaus.org/browse/DOXIA-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-222. --- Assignee: Lukas Theussl Resolution: Fixed Fixed in r630198 with a couple of necessary adjustments in various tests. For your parsing comments I suggest you open a separate issue for discussion. Thanks! > XhtmlBaseParser swallows significant whitespace > --- > > Key: DOXIA-222 > URL: http://jira.codehaus.org/browse/DOXIA-222 > Project: Maven Doxia > Issue Type: Bug > Components: Core >Affects Versions: 1.0-beta-1 >Reporter: Benjamin Bentmann >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: significant-whitespace.patch > > > The current head discards whitespace which is intended to seperate words. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPLUGIN-45) Plugin dependencies are not put in generated plugin.xml
[ http://jira.codehaus.org/browse/MPLUGIN-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MPLUGIN-45: --- Fix Version/s: 2.4 > Plugin dependencies are not put in generated plugin.xml > --- > > Key: MPLUGIN-45 > URL: http://jira.codehaus.org/browse/MPLUGIN-45 > Project: Maven 2.x Plugin Tools > Issue Type: Bug >Reporter: Joost den Boer > Fix For: 2.4 > > > In a plugin project, the dependencies of the project are not placed in the > META-INF/maven/plugin.xml which is generated by Maven. > In the documentation I can not find the feature or annotation to make this > happen, so maybe it does not exist yet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-79) Fix detection of JDK requirement
Fix detection of JDK requirement
Key: MPLUGIN-79
URL: http://jira.codehaus.org/browse/MPLUGIN-79
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Reporter: Benjamin Bentmann
Priority: Trivial
Attachments: jdk-requirement.patch
- {{getPluginArtifactMap()}} returns {{Map}} while
{{Map}} is required for {{discoverJdkRequirementFromPlugins()}}
- The [Maven Compiler
Plugin|http://maven.apache.org/plugins/maven-compiler-plugin/] has a fixed
default value for "target", the current JDK version is irrelevant.
Last but not least: Why is {{discoverJdkRequirementFromPlugins()}} iterating
over a map searching for a key? Wouldn't
{{pluginsAsMap.get("org.apache.maven.plugins:maven-compiler-plugin")}} just do
fine?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTRUN-53) add ant optional task support
[
http://jira.codehaus.org/browse/MANTRUN-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124666
]
Sebastien Brunot commented on MANTRUN-53:
-
The documentation explains ho to retrieve the different maven classpaths in an
ant script, but it does not explains how to add optional tasks to the classpath
that the ant instance launched by the maven-antrun-plugin uses. Any clue about
this ?
> add ant optional task support
> -
>
> Key: MANTRUN-53
> URL: http://jira.codehaus.org/browse/MANTRUN-53
> Project: Maven 2.x Antrun Plugin
> Issue Type: Improvement
>Affects Versions: 1.2
> Environment: windows 2000,java 1.4.2
>Reporter: bingwuli
>Assignee: Carlos Sanchez
>
> I use maven-antrun-plugin for my project recently. Althought this plugin give
> me some convenience, I find it doesn't support ant optional task. In my
> project ,I need to use native2ascii to convert my messages. When I put such
> ant segment dest="${project.build.outputDirectory}" includes="**/*.txt" ext =
> ".properties"/> into plugin's configuration, it doesn't work.
> After I carefully study plugin's docment ,I find the plugin doesn't depend on
> ant optional jar .After I add ant-optional jar into dependency path ,and
> rewrite ant segent as such ,it does work for me.
> classname="org.apache.tools.ant.taskdefs.optional.Native2Ascii" classpathref
> = "maven.compile.classpath" /> src="src/main/conf/message"dest="${project.build.outputDirectory}"
> includes="**/*.txt" ext = ".properties"/>
> I think it good idea that this plugin will support ant optional task.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MNGSITE-34) Document how to define new lifecycle
[ http://jira.codehaus.org/browse/MNGSITE-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton moved MPLUGIN-14 to MNGSITE-34: --- Affects Version/s: (was: 2.1) Key: MNGSITE-34 (was: MPLUGIN-14) Project: Maven Project Web Site (was: Maven 2.x Plugin Tools) > Document how to define new lifecycle > > > Key: MNGSITE-34 > URL: http://jira.codehaus.org/browse/MNGSITE-34 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Andreas Ebbert-Karroum > > Please update the documentation [1] to include how the plexus/components.xml > can be included in the plugin, so that a new lifecycle or artifact handler > can be defined, as described here [2]. It took me a week to find out (and > also the mailing list was no big help BTW). > The solution is really simple, but if you don't know how to do it, it's not > obvious. I've described it in my mail [3]. > [1] http://maven.apache.org/guides/plugin/guide-ant-plugin-development.html > [2] > http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html > [3] http://www.mail-archive.com/[EMAIL PROTECTED]/msg37705.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPLUGIN-28) Error of goal value in Plugin documentation generation
[
http://jira.codehaus.org/browse/MPLUGIN-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed MPLUGIN-28.
--
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 2.4
fixed in r630181
> Error of goal value in Plugin documentation generation
> --
>
> Key: MPLUGIN-28
> URL: http://jira.codehaus.org/browse/MPLUGIN-28
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Environment: Maven 2.0.4 / Windows 2000
>Reporter: David Vicente
>Assignee: Vincent Siveton
>Priority: Critical
> Fix For: 2.4
>
>
> in my pom, i configure maven-plugin-plugin to modify the goalPrefix value as :
> ...
> org.codehaus.mojo
> dashboard-maven-plugin
> 1.0-SNAPSHOT
> ...
>
> ...
>
> org.apache.maven.plugins
> maven-plugin-plugin
>
> dashboard-report
>
>
>
> the descriptor of my plugin is ok.
> But when i generate the plugin's site, the generated goal in plugin-info.html
> file is "dashboard:dashboard" instead of "dashboard-report:dashboard".
> When i read the code, i see in AbstractGeneratorMojo class :
> {code}
> /**
> * The goal prefix that will appear before the ":".
> *
> * @parameter
> */
> protected String goalPrefix;
> ...
> public void execute()
> throws MojoExecutionException
> {
> if ( !project.getPackaging().equals( "maven-plugin" ) )
> {
> return;
> }
> String defaultGoalPrefix = PluginDescriptor.getGoalPrefixFromArtifactId(
> project.getArtifactId() );
> if ( goalPrefix == null )
> {
> goalPrefix = defaultGoalPrefix;
> }
> else
> {
> getLog().warn( "Goal prefix is: " + goalPrefix + "; Maven currently
> expects it to be " + defaultGoalPrefix );
> }
> {code}
> but when i see the PluginReport class :
> {code}
> protected void executeReport( Locale locale )
> throws MavenReportException
> {
> if ( !project.getPackaging().equals( "maven-plugin" ) )
> {
> return;
> }
> String goalPrefix = PluginDescriptor.getGoalPrefixFromArtifactId(
> project.getArtifactId() );
> // TODO: could use this more, eg in the writing of the plugin descriptor!
> PluginDescriptor pluginDescriptor = new PluginDescriptor();
> pluginDescriptor.setGroupId( project.getGroupId() );
> pluginDescriptor.setArtifactId( project.getArtifactId() );
> pluginDescriptor.setVersion( project.getVersion() );
> pluginDescriptor.setGoalPrefix( goalPrefix );
> {code}
> To fix this error :
> - add a goal prefix parameter in the PluginReport class and do the same code
> as AbstractGeneratorMojo class to retreive the goal Prefix
> or
> - read directly the plugin descriptor which is well generated instead of to
> re-create the plugin descriptor with project parameters
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1942) jline 0.9.94
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124662 ] Guillaume Laforge commented on MAVENUPLOAD-1942: Yoopiee! > jline 0.9.94 > > > Key: MAVENUPLOAD-1942 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1942 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jason Dillon >Assignee: Carlos Sanchez > > JLine 0.9.94 update, with some fixes for use w/Java 4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-287) Clarify/fix documentation about encoding for translated resource bundles.
[ http://jira.codehaus.org/browse/MSITE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124661 ] Vincent Siveton commented on MSITE-287: --- Like said, I used an Eclipse plugin to edit properties but unfortunately, by default, it was set to read properties in UTF-8. The original file de.properties was in ISO-8859-1. > Clarify/fix documentation about encoding for translated resource bundles. > - > > Key: MSITE-287 > URL: http://jira.codehaus.org/browse/MSITE-287 > Project: Maven 2.x Site Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-6 >Reporter: Benjamin Bentmann >Priority: Minor > > According to http://maven.apache.org/plugins/maven-site-plugin/i18n.html > translators are expected to provide their properties files in UTF-8 encoding. > However, the JRE reads properties files using ISO-8859-1 encoding (see [class > javadoc for > PropertyResourceBundle|http://java.sun.com/javase/6/docs/api/java/util/PropertyResourceBundle.html]). > Either the documentation should be fixed to state ISO-8859-1 or it should be > made clear why Maven requires another encoding than usual. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPLUGIN-78) Fix german localization
[ http://jira.codehaus.org/browse/MPLUGIN-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPLUGIN-78. -- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.4 done in r630167 > Fix german localization > --- > > Key: MPLUGIN-78 > URL: http://jira.codehaus.org/browse/MPLUGIN-78 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: API, Plugin Plugin >Reporter: Benjamin Bentmann >Assignee: Vincent Siveton >Priority: Trivial > Fix For: 2.4 > > Attachments: i18n-de.patch > > > The commit in [r630057|http://svn.apache.org/viewvc?view=rev&revision=630057] > messed up file encoding (BTW, we should come to a conclusion about MSITE-287) > and contains bad translations. > My offer remains: If there is need for German translations updated/added > somewhere in Maven, just open a JIRA issue and send me a notification. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPLUGIN-78) Fix german localization
[ http://jira.codehaus.org/browse/MPLUGIN-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124655 ] Vincent Siveton commented on MPLUGIN-78: bq: The commit in r630057 messed up file encoding (BTW, we should come to a conclusion about MSITE-287) and contains bad translations I used an Eclipse plugin and it seems to be faulty for encoding. Thanks for the offer, my German courses are definitely lost ;) > Fix german localization > --- > > Key: MPLUGIN-78 > URL: http://jira.codehaus.org/browse/MPLUGIN-78 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: API, Plugin Plugin >Reporter: Benjamin Bentmann >Priority: Trivial > Attachments: i18n-de.patch > > > The commit in [r630057|http://svn.apache.org/viewvc?view=rev&revision=630057] > messed up file encoding (BTW, we should come to a conclusion about MSITE-287) > and contains bad translations. > My offer remains: If there is need for German translations updated/added > somewhere in Maven, just open a JIRA issue and send me a notification. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1942) jline 0.9.94
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124652 ] Jason Dillon commented on MAVENUPLOAD-1942: --- Groovy Java 1.4 compat is dependent on this... please push it out :-) > jline 0.9.94 > > > Key: MAVENUPLOAD-1942 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1942 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jason Dillon >Assignee: Carlos Sanchez > > JLine 0.9.94 update, with some fixes for use w/Java 4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1942) jline 0.9.94
jline 0.9.94 Key: MAVENUPLOAD-1942 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1942 Project: maven-upload-requests Issue Type: Task Reporter: Jason Dillon Assignee: Carlos Sanchez JLine is a popular Java library for handling console input. It is similar in functionality to BSD editline and GNU readline. People familiar with the readline/editline capabilities for modern shells (such as bash and tcsh) will find most of the command editing features of JLine to be familiar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MAVENUPLOAD-1942) jline 0.9.94
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated MAVENUPLOAD-1942: -- Description: JLine 0.9.94 update, with some fixes for use w/Java 4 (was: JLine is a popular Java library for handling console input. It is similar in functionality to BSD editline and GNU readline. People familiar with the readline/editline capabilities for modern shells (such as bash and tcsh) will find most of the command editing features of JLine to be familiar.) Bundle URL: http://jline.sourceforge.net/jline-0.9.94-bundle.jar (was: http://jline.sourceforge.net/jline-0.9.9-bundle.jar) > jline 0.9.94 > > > Key: MAVENUPLOAD-1942 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1942 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jason Dillon >Assignee: Carlos Sanchez > > JLine 0.9.94 update, with some fixes for use w/Java 4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-137) Problem when setting default values for archetype-metadata.xml
Problem when setting default values for archetype-metadata.xml -- Key: ARCHETYPE-137 URL: http://jira.codehaus.org/browse/ARCHETYPE-137 Project: Maven Archetype Issue Type: Bug Affects Versions: 2.0-alpha-2 Reporter: Dominique Jean-Prost I have an archetype-metadata.xml like this : ... com.dexia.sofaxis < requiredProperty key="version"> 1.0.0-SNAPSHOT If I try to use this archetype, groupId and version are not asked on command line, but I then get the exception. If I remove the requiredProperty elements, I don't get it. [ERROR] The archetype is not configured org.apache.maven.archetype.exception.ArchetypeNotConfigured: The archetype is not configured at org.apache.maven.archetype.generator.DefaultFilesetArchetypeGenerator.generateArchetype(DefaultFilesetArchetypeGenerator.java:98) at org.apache.maven.archetype.generator.DefaultArchetypeGenerator.processFileSetArchetype(DefaultArchetypeGenerator.java:215) at org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype(DefaultArchetypeGenerator.java:130) at org.apache.maven.archetype.generator.DefaultArchetypeGenerator.generateArchetype(DefaultArchetypeGenerator.java:290) at org.apache.maven.archetype.DefaultArchetype.generateProjectFromArchetype(DefaultArchetype.java:75) at org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute(CreateProjectFromArchetypeMojo.java:169) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-78) Fix german localization
Fix german localization --- Key: MPLUGIN-78 URL: http://jira.codehaus.org/browse/MPLUGIN-78 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: API, Plugin Plugin Reporter: Benjamin Bentmann Priority: Trivial Attachments: i18n-de.patch The commit in [r630057|http://svn.apache.org/viewvc?view=rev&revision=630057] messed up file encoding (BTW, we should come to a conclusion about MSITE-287) and contains bad translations. My offer remains: If there is need for German translations updated/added somewhere in Maven, just open a JIRA issue and send me a notification. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPA-106) Process Benjamin Bentmann
[ http://jira.codehaus.org/browse/MPA-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124646 ] Lukas Theussl commented on MPA-106: --- Vote thread: http://www.nabble.com/-vote--Benjamin-Bentmann-as-Maven-committer-td15550377s177.html > Process Benjamin Bentmann > - > > Key: MPA-106 > URL: http://jira.codehaus.org/browse/MPA-106 > Project: Maven Project Administration > Issue Type: Task > Components: New Committers >Affects Versions: 2008-q1 >Reporter: Lukas Theussl > > Waiting for CLA -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPA-106) Process Benjamin Bentmann
Process Benjamin Bentmann - Key: MPA-106 URL: http://jira.codehaus.org/browse/MPA-106 Project: Maven Project Administration Issue Type: Task Components: New Committers Affects Versions: 2008-q1 Reporter: Lukas Theussl Waiting for CLA -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3416) Setting testOutDirectory to ${basedir}/target/test-classes causes test classpath to be reversed.
[
http://jira.codehaus.org/browse/MNG-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124642
]
Ben Lidgey commented on MNG-3416:
-
See http://www.nabble.com/Surefire-2.4.1-classpath-order-td15498825s177.html
for the maven-users thread.
> Setting testOutDirectory to ${basedir}/target/test-classes causes test
> classpath to be reversed.
>
>
> Key: MNG-3416
> URL: http://jira.codehaus.org/browse/MNG-3416
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.8
>Reporter: Ben Lidgey
>
> Environment: maven 2.0.8, surefire 2.4.1,2.4.2
> We are running tests using Surefire 2.4.1 and Maven 2.0.8. The Junit test
> classes are expecting to load a properties file from
> {{src/test/resources}} with the same name as a properties file in
> {{src/main/resources}} to load test data etc. However the src/main/resources
> properties file is being loaded.
> Looking at the debug output shows:
> [DEBUG] Test Classpath :
> [DEBUG] C:\Documents and
> Settings\benl\.m2\repository\junit\junit\4.2\junit-4.2.jar
> [more jars]
> [DEBUG] c:\Development\Projects\MyProject\target\classes
> [DEBUG] c:\Development\Projects\MyProject\target\test-classes
> Which would explain it. Setting childDelegation to true doesn't get the
> test-classes before classes in the classpath order.
> I generated the effective-pom and used it in a copy of the Surefire
> integration test for the classpath order
> (http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/classpath-order).
> The tests failed. I then trawled through the project POM and then its parent
> POM commenting out plugins, reporting, dependencies, and other bits until the
> test passed.
> The thing that was causing the test to fail was that in the parent POM:
> {code:xml}
> package
> target
> ${pom.artifactId}-${pom.version}
> ${basedir}/src/main/java
> ${basedir}/src/test/java
> ${basedir}/target/test-classes
> ${basedir}/target/classes
> {code}
> Changing just testOutputDirectory to
> {code:xml}
> target/test-classes
> {code}
> Made the tests pass. I've no idea why.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3416) Setting testOutDirectory to ${basedir}/target/test-classes causes test classpath to be reversed.
Setting testOutDirectory to ${basedir}/target/test-classes causes test
classpath to be reversed.
Key: MNG-3416
URL: http://jira.codehaus.org/browse/MNG-3416
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.8
Reporter: Ben Lidgey
Environment: maven 2.0.8, surefire 2.4.1,2.4.2
We are running tests using Surefire 2.4.1 and Maven 2.0.8. The Junit test
classes are expecting to load a properties file from
{{src/test/resources}} with the same name as a properties file in
{{src/main/resources}} to load test data etc. However the src/main/resources
properties file is being loaded.
Looking at the debug output shows:
[DEBUG] Test Classpath :
[DEBUG] C:\Documents and
Settings\benl\.m2\repository\junit\junit\4.2\junit-4.2.jar
[more jars]
[DEBUG] c:\Development\Projects\MyProject\target\classes
[DEBUG] c:\Development\Projects\MyProject\target\test-classes
Which would explain it. Setting childDelegation to true doesn't get the
test-classes before classes in the classpath order.
I generated the effective-pom and used it in a copy of the Surefire integration
test for the classpath order
(http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/classpath-order).
The tests failed. I then trawled through the project POM and then its parent
POM commenting out plugins, reporting, dependencies, and other bits until the
test passed.
The thing that was causing the test to fail was that in the parent POM:
{code:xml}
package
target
${pom.artifactId}-${pom.version}
${basedir}/src/main/java
${basedir}/src/test/java
${basedir}/target/test-classes
${basedir}/target/classes
{code}
Changing just testOutputDirectory to
{code:xml}
target/test-classes
{code}
Made the tests pass. I've no idea why.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-136) Add the possibility to generate resources using the package variable
[ http://jira.codehaus.org/browse/ARCHETYPE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124641 ] Dominique Jean-Prost commented on ARCHETYPE-136: Well, I've retried to find the documentation for archtype.xml, and I found a new one I didn't got last time. It's well explained, so that I think I will be able to use it correctly. Excuse me. > Add the possibility to generate resources using the package variable > > > Key: ARCHETYPE-136 > URL: http://jira.codehaus.org/browse/ARCHETYPE-136 > Project: Maven Archetype > Issue Type: Improvement >Affects Versions: 2.0-alpha-2 >Reporter: Dominique Jean-Prost > > Actually, the sources files are generated in filesystem using the package > variable. Resources are not. Add the possibility to get resources in > filesystem using package variable too. > Example : > with package = com.foo > and > > foo > > src/main/java/App.java > > > src/main/resources/i18n_FR.properties > > > App.java is created in dir /src/main/java/com/foo/App.java > i18n_FR.properties is created in /src/main/resources/i18n_FR.properties. I > would like to have this properties file in > /src/main/resources/com/foo/i18n_FR.properties. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-287) Clarify/fix documentation about encoding for translated resource bundles.
[ http://jira.codehaus.org/browse/MSITE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124640 ] Benjamin Bentmann commented on MSITE-287: - I would like to continue to argue against needlessly introducing Unicode escapes for Latin-1 characters into a file that is by common convention assumed to be encoded in ISO-8859-1. As Vincent himself has just proven, using Unicode escapes does not prevent messing up the I18n ([plugin-report_de.properties|http://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-plugin/src/main/resources/plugin-report_de.properties?r1=620114&r2=630057&pathrev=630057], [pluginxdoc_de.properties|http://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-tools-api/src/main/resources/pluginxdoc_de.properties?r1=629657&r2=630057&pathrev=630057], [Unicode FFFD|http://unicode.org/glossary/index.html#replacement_character]): - the conversion itself is error-prone - the result is not easily readable/controllable by humans So why scramble a file that is supposed to be human-readable with unicode escapes? Contributors that provide I18n for their native language usually know about the details of properly encoding their properties files because they are used to this in their other Java projects. In contrast, English speaking developers are used to live in an ASCII world and seem less sensitive to encoding issues. > Clarify/fix documentation about encoding for translated resource bundles. > - > > Key: MSITE-287 > URL: http://jira.codehaus.org/browse/MSITE-287 > Project: Maven 2.x Site Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-6 >Reporter: Benjamin Bentmann >Priority: Minor > > According to http://maven.apache.org/plugins/maven-site-plugin/i18n.html > translators are expected to provide their properties files in UTF-8 encoding. > However, the JRE reads properties files using ISO-8859-1 encoding (see [class > javadoc for > PropertyResourceBundle|http://java.sun.com/javase/6/docs/api/java/util/PropertyResourceBundle.html]). > Either the documentation should be fixed to state ISO-8859-1 or it should be > made clear why Maven requires another encoding than usual. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-136) Add the possibility to generate resources using the package variable
[ http://jira.codehaus.org/browse/ARCHETYPE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_124639 ] Milos Kleint commented on ARCHETYPE-136: this is already possible with the current 2.0-alpha-1 check http://svn.codehaus.org/mojo/trunk/mojo/mojo-archetypes/nbm-archetype/src/main/resources/META-INF/maven/archetype-metadata.xml as an example how to do it.. it will not work with 1.x version of archetype plugin though.. > Add the possibility to generate resources using the package variable > > > Key: ARCHETYPE-136 > URL: http://jira.codehaus.org/browse/ARCHETYPE-136 > Project: Maven Archetype > Issue Type: Improvement >Affects Versions: 2.0-alpha-2 >Reporter: Dominique Jean-Prost > > Actually, the sources files are generated in filesystem using the package > variable. Resources are not. Add the possibility to get resources in > filesystem using package variable too. > Example : > with package = com.foo > and > > foo > > src/main/java/App.java > > > src/main/resources/i18n_FR.properties > > > App.java is created in dir /src/main/java/com/foo/App.java > i18n_FR.properties is created in /src/main/resources/i18n_FR.properties. I > would like to have this properties file in > /src/main/resources/com/foo/i18n_FR.properties. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-368) Windows path length limitations can be overcome by feeding an absolute path to SVN
[ http://jira.codehaus.org/browse/SCM-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-368: - Fix Version/s: 1.1 > Windows path length limitations can be overcome by feeding an absolute path > to SVN > -- > > Key: SCM-368 > URL: http://jira.codehaus.org/browse/SCM-368 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api >Affects Versions: 1.0 > Environment: Any Windows machine >Reporter: Kurt Tometich >Priority: Minor > Fix For: 1.1 > > > When calling Subversion with relative paths there is a limit of 255 > characters to the path length. If you call Subversion with an absolute path > that no longer applies and you now have access to 32K chars. I have tried > this myself and it does work. Try feeding SVN a path that is relative and is > over 255 chars. It will not be able to complete the transaction. Now, try > to the same path again only as an absolute path and it will successfully > complete the transaction. Here is a link to the forum where I found this > information: http://en-us.www.mozilla.com/en-US/firefox/2.0.0.4/firstrun/. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-136) Add the possibility to generate resources using the package variable
Add the possibility to generate resources using the package variable Key: ARCHETYPE-136 URL: http://jira.codehaus.org/browse/ARCHETYPE-136 Project: Maven Archetype Issue Type: Improvement Affects Versions: 2.0-alpha-2 Reporter: Dominique Jean-Prost Actually, the sources files are generated in filesystem using the package variable. Resources are not. Add the possibility to get resources in filesystem using package variable too. Example : with package = com.foo and foo src/main/java/App.java src/main/resources/i18n_FR.properties App.java is created in dir /src/main/java/com/foo/App.java i18n_FR.properties is created in /src/main/resources/i18n_FR.properties. I would like to have this properties file in /src/main/resources/com/foo/i18n_FR.properties. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-135) add a variabl containing package in a path format
add a variabl containing package in a path format - Key: ARCHETYPE-135 URL: http://jira.codehaus.org/browse/ARCHETYPE-135 Project: Maven Archetype Issue Type: Improvement Affects Versions: 2.0-alpha-2 Reporter: Dominique Jean-Prost Actually, there is a variable "package" than can be used in the file during generation. It could be great if there was another variable than contained the package in a path format. Example : package = com.foo packageInPathFormat=com/foo This new variable could be used in resources path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRESOURCES-55) filter file location does not expand ${project.build.directory}
filter file location does not expand ${project.build.directory}
---
Key: MRESOURCES-55
URL: http://jira.codehaus.org/browse/MRESOURCES-55
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Reporter: Matthijs Wensveen
When specifying a propeties file with
..
${project.build.directory}/build.properties
..
${project.build.directory} is not expanded to the defined build directory.
Usually this is 'target' but this may be overridden in the pom or settings.xml,
possibly using profiles.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
