[jira] Commented: (MNG-3004) Allow build lifecycle to execute projects in parallel
[ http://jira.codehaus.org/browse/MNG-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219348#action_219348 ] Kristian Rosenvold commented on MNG-3004: - Thank you, Christian, nice with some feedback. The output demultiplexer that is present in the code base was only intended as a stop-gap, and is architecturally not the proper solution. MNG-2727 is targeted at beta-2 and we are awaiting its completion. In the event that MNG-2727 does not resolve demultiplexing of the output in parallel build, there will be another issue (with a likely target of beta-2) to fix this. Regarding your team-city issue I will not be surprised if they're parsing the output somehow, so I can imagine it being slightly confused. Please also note that there are several other issues being fixed in the maven ecosystem related to stable running of parallel tests, and I'll try to keep this updated in the "relates to section" of this issue. The workaround until updated plugins are released will normally involve adding dependencies to newer library versions to your plugins at the moment. > Allow build lifecycle to execute projects in parallel > - > > Key: MNG-3004 > URL: http://jira.codehaus.org/browse/MNG-3004 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Bootstrap & Build, General, Performance >Affects Versions: 2.0.6 >Reporter: Nigel Magnay >Assignee: Kristian Rosenvold > Fix For: 3.0-beta-1 > > Attachments: > MNG-3004-Resurrected-StringSearchModelInterpolatorTest.patch, > MNG-3004.increased-testability.patch, MNG3004-SSMI.patch, mng3004.patch, > mng3004v2_rev2.patch, parallel-builds.patch > > > One of the great advantages with maven over scripted build environments is > that it can calculate the dependencies of the build, and it could execute > items that are independent of each other in parallel. > Unfortunately it currently doesn't do this, which would be a big win over > tools such as 'ant'. It also means that multicore machines have lots of idle > capacity when running a serial build that could be utilised. > I had a quick shot at seeing what might be required. Bear in mind this is the > first time I have looked at maven internally, and I was just trying to feel > my way around and build a POC. I got some of the way there, but my build > threads don't seem to have the correct classpath - I think this is something > to do with plexus / classworlds - but I don't know enough. > It'd be great to get this feature in a future version, or a way of running my > hack (figuring out why in a thread has not the plexus stuff) in the interim. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-614) Run tests in random order
Run tests in random order - Key: SUREFIRE-614 URL: http://jira.codehaus.org/browse/SUREFIRE-614 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Reporter: Joerg Schaible By definition all tests should be completely self-contained. However, some developers fail to write proper tests and this can be forced if surefire would run the tests in arbitrary order. This is in contrast to SUREFIRE-321, so it should be configurable if the test sould be run in native, random or alphabetical order. -- 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: (MECLIPSE-636) MECLIPSE-156 wasn't resolved
[ http://jira.codehaus.org/browse/MECLIPSE-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramiro Pereira de Magalhães updated MECLIPSE-636: - Attachment: patch-MECLIPSE-636.patch Added a patch that solves this issue using patches from MECLIPSE-156 and suggestions that came from this thread. Now, eclipse:eclipse uses the text from the maven-compiler-plugin to set source code's and resources' encoding. It does not set the global encoding setting of an Eclipse project, so only the source and resource folders will have the encoding set. Also, fixed the eclipse:clean mojo, allowing it to properly exclude the .settings/org.eclipse.core.resources.prefs file which contains such preferences. > MECLIPSE-156 wasn't resolved > > > Key: MECLIPSE-636 > URL: http://jira.codehaus.org/browse/MECLIPSE-636 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.7 >Reporter: Ramiro Pereira de Magalhães > Attachments: patch-MECLIPSE-636.patch > > > Task MECLIPSE-156 wasn't correctly implemented and the proposed feature > (namely, that the plugin should support setting file encoding) does not work. > I think that only one of the proposed patches there were implemented (on > IdeUtils.java) while the other (on EclipseUtils.java) one wasn't. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-156) Plugin should support setting file encoding
[ http://jira.codehaus.org/browse/MECLIPSE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219355#action_219355 ] Ramiro Pereira de Magalhães commented on MECLIPSE-156: -- Proposed solution attached to issue MECLIPSE-636. > Plugin should support setting file encoding > --- > > Key: MECLIPSE-156 > URL: http://jira.codehaus.org/browse/MECLIPSE-156 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Reporter: Ralph Poellath >Assignee: nicolas de loof > Fix For: 2.8 > > Attachments: maven-eclipse-plugin-2.5.1.tar.gz, > MECLIPSE-156-maven-eclipse-plugin.patch, > MECLIPSE-156_proper_use_of_project_build_sourceEncoding.patch > > > The plugin should support setting Eclipse's text file encoding on a > per-project basis. -- 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: (MECLIPSE-636) MECLIPSE-156 wasn't resolved
[ http://jira.codehaus.org/browse/MECLIPSE-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219354#action_219354 ] Ramiro Pereira de Magalhães edited comment on MECLIPSE-636 at 4/29/10 3:24 AM: --- Added a patch that solves this issue using patches and suggestions from MECLIPSE-156. Now, eclipse:eclipse uses the text from the maven-compiler-plugin to set source code's and resources' encoding. It does not set the global encoding setting of an Eclipse project, so only the source and resource folders will have the encoding set. Also, fixed the eclipse:clean mojo, allowing it to properly exclude the .settings/org.eclipse.core.resources.prefs file which contains such preferences. was (Author: ramiromagalhaes): Added a patch that solves this issue using patches from MECLIPSE-156 and suggestions that came from this thread. Now, eclipse:eclipse uses the text from the maven-compiler-plugin to set source code's and resources' encoding. It does not set the global encoding setting of an Eclipse project, so only the source and resource folders will have the encoding set. Also, fixed the eclipse:clean mojo, allowing it to properly exclude the .settings/org.eclipse.core.resources.prefs file which contains such preferences. > MECLIPSE-156 wasn't resolved > > > Key: MECLIPSE-636 > URL: http://jira.codehaus.org/browse/MECLIPSE-636 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.7 >Reporter: Ramiro Pereira de Magalhães > Attachments: patch-MECLIPSE-636.patch > > > Task MECLIPSE-156 wasn't correctly implemented and the proposed feature > (namely, that the plugin should support setting file encoding) does not work. > I think that only one of the proposed patches there were implemented (on > IdeUtils.java) while the other (on EclipseUtils.java) one wasn't. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[ http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219361#action_219361 ] Mark Hobson commented on SUREFIRE-482: -- This is the second most popular issue for Surefire so we need to resolve it. First step would be for someone to contribute a patch that fixes this behaviour. > Surefire tries to run JUnit4 tests that contain no @Test annotations > > > Key: SUREFIRE-482 > URL: http://jira.codehaus.org/browse/SUREFIRE-482 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.4.2 >Reporter: Mark Hobson > Attachments: test.zip > > > Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that > contain no @Test annotations as tests, resulting in the exception: > java.lang.Exception: No runnable methods > at > org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32) > at > org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43) > at > org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36) > at > org.junit.internal.runners.JUnit4ClassRunner.(JUnit4ClassRunner.java:27) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:494) > at > org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33) > at > org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.(JUnit4TestSet.java:45) > at > org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) > at > org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) > at org.apache.maven.surefire.Surefire.run(Surefire.java:156) > 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) > Such classes should be ignored by Surefire. -- 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: (MECLIPSE-654) eclipse:eclipse fails if jre/lib/rt.jar has no manifest
eclipse:eclipse fails if jre/lib/rt.jar has no manifest --- Key: MECLIPSE-654 URL: http://jira.codehaus.org/browse/MECLIPSE-654 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.8 Environment: Debian Linux running java-1.5.0-gcj-4.3-1.5.0.0. Reporter: Ramiro Pereira de Magalhães Attachments: noNullPointer.patch If the JVM's file rt.jar has no manifest, eclipse:eclipse throws a NullPointerException. The provided patch solves this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-550) Version incrementation in non interactive release (batch-mode / -B)
Version incrementation in non interactive release (batch-mode / -B) --- Key: MRELEASE-550 URL: http://jira.codehaus.org/browse/MRELEASE-550 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: Windows 7, jdk1.6.0_17 Reporter: Christian Moser Attachments: versionIncrementation.patch This feature makes it possible to configure the incrementation process in batch-mode. As default the release plugin increments the patch-level digit and adds -SNAPSHOT after a release has been executed. e,g 1.3.3-SNAPSHOT --> 1.3.3 --> *1.3.4-SNAPSHOT* With the following feature, the user will be allowed by setting a property in the release:prepare goal to change this behavior -DdevVersionIncrementation=2 1.3.3-SNAPSHOT --> 1.3.3 --> *1.4.0-SNAPSHOT* or (-DdevVersionIncrementation=1) 1.3.3-SNAPSHOT --> 1.3.3 --> *2.0.0-SNAPSHOT* the default value is -DdevVersionIncrementation=3 and will increment the patch-level digit as usual. In the attachment you'll find a patch for the fully implemented feature, I'd very thankful if someone could insert it into the next version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2753) Request add of new project "pojava" to central repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219392#action_219392 ] Juven Xu commented on MAVENUPLOAD-2753: --- pojava.org is still dead to me > Request add of new project "pojava" to central repository > - > > Key: MAVENUPLOAD-2753 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2753 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: John Pile >Assignee: Juven Xu > > http://pojava.org/releases/pojava-2.2.1-bundle.jar > http://pojava.org/releases/persistence-2.2.1-bundle.jar > I am John Pile, aka "Phatfingers". This project is hosted on > https://sourceforge.net/projects/pojava/, and its home page is > http://pojava.org. Per your guide-central-repository-upload page, a project > will be deemed "suspicious" if it has no dependencies, and will require > verification. I wish to answer in advance that the "pojava" project > deliberately has no dependencies, and the "persistence" project is dependent > on "pojava". -- 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-4652) Parallel builds don't support mixed goals and phases
Parallel builds don't support mixed goals and phases Key: MNG-4652 URL: http://jira.codehaus.org/browse/MNG-4652 Project: Maven 2 & 3 Issue Type: Bug Components: Reactor and workspace Affects Versions: 3.0-beta-1 Reporter: Clay Atkins Priority: Minor I have aggregate & parent set of projects. Running maven on parent, using the new -T options, I do the following: -T 8.0C help:active-profiles clean install The reactor only runs help:active-profiles on all the subprojects. If I do the following: -T 8.0C clean install The reactor does as expected, running clean phase and install phase on subprojects. If I do the following: help:active-profiles clean install The reactor runs the help:active-profiles goal and clean and install phases on each subproject. -- 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: (MDEP-261) Adding dependencies to existing poms via shell
Adding dependencies to existing poms via shell -- Key: MDEP-261 URL: http://jira.codehaus.org/browse/MDEP-261 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Reporter: Oliver Schrenk Assignee: Brian Fox Priority: Minor It would be a nice addition if you could be able to inject dependencies while you are in your shell. Maybe something like: mvn dependency:add -DgroupID=com.acme -DartifactId=project which then injects the dependency into the pom. The approach felt natural and I was kinda confused that this doesn't exist yet. Thoughts? -- 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-4653) versions:display-plugin-updates throws a NullPointerException
versions:display-plugin-updates throws a NullPointerException - Key: MNG-4653 URL: http://jira.codehaus.org/browse/MNG-4653 Project: Maven 2 & 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 3.0-beta-1 Reporter: Andreas Christoforides Attachments: exception.txt Running mvn versions:display-plugin-updates throws a NullPointerException when executed using maven 3.0-beta-1 but works fine with maven 3.0-alpha7. The project I am using is fairly simple. It is actually a company POM with no parent and consists mostly of properties and plugin management configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINVOKER-102) Provide a way to install Extra dependencies
Provide a way to install Extra dependencies --- Key: MINVOKER-102 URL: http://jira.codehaus.org/browse/MINVOKER-102 Project: Maven 2.x Invoker Plugin Issue Type: New Feature Affects Versions: 1.5 Reporter: Marvin Froeder Attachments: maven-invoker-plugin.patch -- 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: (MCHANGELOG-90) Developer activity can't resolve developer name using clearcase SCM
[ http://jira.codehaus.org/browse/MCHANGELOG-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219436#action_219436 ] Dennis Lundberg commented on MCHANGELOG-90: --- The current 2.2-SNAPSHOT of this plugin has had the SCM component upgraded to version 1.3. Could you please test 2.2-SNAPSHOT to see if it resolves this issue. > Developer activity can't resolve developer name using clearcase SCM > --- > > Key: MCHANGELOG-90 > URL: http://jira.codehaus.org/browse/MCHANGELOG-90 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: Rational Clearcase, Maven 2.0.9, Red Hat Linux >Reporter: Peter Hayes > Attachments: changelog.xml > > > The change log changelog.xml file generated when using clearcase as an SCM > provider includes an additional space after the user id. This prevents the > matching of userid to pom's developer's id. I checked the scm:changelog > output and it does not include a space so it seems that this is a changelog > issue. > I have attached a sample changelog.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] Commented: (MCHANGELOG-94) Changelog report does not pick up svn changes when author has spaces
[ http://jira.codehaus.org/browse/MCHANGELOG-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219438#action_219438 ] Dennis Lundberg commented on MCHANGELOG-94: --- Plugin version 2.2-SNAPSHOT uses SCM 1.3 which fixes SCM-455. Please give it a try. > Changelog report does not pick up svn changes when author has spaces > > > Key: MCHANGELOG-94 > URL: http://jira.codehaus.org/browse/MCHANGELOG-94 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Todd Thiessen > > This bug is caused by a bug in the scm project. Please see > http://jira.codehaus.org/browse/SCM-455 for further details. When/if the scm > bug is fixed, the change log plugin would have to be updated to point to the > SCM release where it is fixed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGELOG-95) Getting historical information from Microsoft Visual source is not working
[ http://jira.codehaus.org/browse/MCHANGELOG-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MCHANGELOG-95: -- Patch Submitted: [Yes] > Getting historical information from Microsoft Visual source is not working > -- > > Key: MCHANGELOG-95 > URL: http://jira.codehaus.org/browse/MCHANGELOG-95 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: VSS 6.0, maven 2.0 >Reporter: Radhakrishnan > Attachments: dateFormatNotBeingPassed > > > file's creaion date is defined as in VSS 4/08/09 8:47p. I am getting below > error when trying to execute changelog report. I tried using the dateformat > as M/dd/yy hh:mma as well as M/dd/yy hh:mm & MM/dd/yy h:mm. But no options > worked out. > java.text.ParseException: Unparseable date: "4/08/09 8:47p" > at java.text.DateFormat.parse(DateFormat.java:335) > at > org.apache.maven.scm.util.AbstractConsumer.parseDate(AbstractConsumer.java:106) > at > org.apache.maven.scm.util.AbstractConsumer.parseDate(AbstractConsumer.java:68) > at > org.apache.maven.scm.provider.vss.commands.changelog.VssChangeLogConsumer.processGetAuthor(VssChangeLogConsumer.java:198) > at > org.apache.maven.scm.provider.vss.commands.changelog.VssChangeLogConsumer.consumeLine(VssChangeLogConsumer.java:147) > at > org.codehaus.plexus.util.cli.StreamPumper.consumeLine(StreamPumper.java:194) > at > org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:143) -- 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: (MCHANGELOG-102) NullpointerException thrown when a revision has no file changes
[
http://jira.codehaus.org/browse/MCHANGELOG-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219439#action_219439
]
Dennis Lundberg commented on MCHANGELOG-102:
The current 2.2-SNAPSHOT of this plugin has had the SCM component upgraded to
version 1.3. Could you please test 2.2-SNAPSHOT to see if it resolves this
issue.
> NullpointerException thrown when a revision has no file changes
> ---
>
> Key: MCHANGELOG-102
> URL: http://jira.codehaus.org/browse/MCHANGELOG-102
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows, SVN, Java 1.5
>Reporter: Krishna Pothula
>
> Received below error when svn log returns revisions with no File changes.
> When executed separately svn command executed fine.
> svn --non-interactive log -v -r "{2009-07-20 05:33:41 +}:{2009-08-20
> 05:33:41 +}"
> org.apache.maven.lifecycle.LifecycleExecutionException: An error has occurred
> in Change Log report generation.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: An error has
> occurred in Change Log report generation.
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:79)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
> ... 16 more
> Caused by: java.lang.NullPointerException
> at org.apache.maven.scm.ChangeSet.toXML(ChangeSet.java:425)
> at
> org.apache.maven.scm.command.changelog.ChangeLogSet.toXML(ChangeLogSet.java:198)
> at
> org.apache.maven.plugin.changelog.ChangeLogReport.writeChangelogXml(ChangeLogReport.java:421)
> at
> org.apache.maven.plugin.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:397)
> at
> org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98)
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73)
> ... 18 more
--
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: (MCHANGELOG-104) NPE when using the plugin with the git provider
[ http://jira.codehaus.org/browse/MCHANGELOG-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219440#action_219440 ] Dennis Lundberg commented on MCHANGELOG-104: The current 2.2-SNAPSHOT of this plugin has had the SCM component upgraded to version 1.3. Could you please test 2.2-SNAPSHOT to see if it resolves this issue. > NPE when using the plugin with the git provider > --- > > Key: MCHANGELOG-104 > URL: http://jira.codehaus.org/browse/MCHANGELOG-104 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Maarten Billemont >Assignee: Mark Struberg > > I've manually added a dependency on the gitexe provider to make the plugin > able to use it. However, using the plugin with GIT then causes the following > NullPointerEception: > Caused by: java.lang.NullPointerException > at org.apache.maven.scm.ChangeSet.toXML(ChangeSet.java:425) > at > org.apache.maven.scm.command.changelog.ChangeLogSet.toXML(ChangeLogSet.java:198) > at > org.apache.maven.plugin.changelog.ChangeLogReport.writeChangelogXml(ChangeLogReport.java:421) > at > org.apache.maven.plugin.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:397) > at > org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) > at > org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:73) > ... 19 more -- 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: (MCHANGELOG-106) NoSuchElementException During Site generation
[ http://jira.codehaus.org/browse/MCHANGELOG-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219441#action_219441 ] Dennis Lundberg commented on MCHANGELOG-106: Can you give us a sample project that can be used to reproduce this issue? > NoSuchElementException During Site generation > - > > Key: MCHANGELOG-106 > URL: http://jira.codehaus.org/browse/MCHANGELOG-106 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: * Windows XP, SVN 1.5.4, MVN 2.2.1 > java version "1.6.0" > Java(TM) SE Runtime Environment (build 1.6.0-b105) > Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode) > * Linux, Hudson 1.326, MVN 2.0.9, > Java 1.6-SUN >Reporter: Karl Heinz Marbaise > > I have configured to use maven-changelog-plugin as follows in my reporting > part: > > org.apache.maven.plugins > maven-changelog-plugin > 2.1 > > During the site generation i get the following message: > java.util.NoSuchElementException > at java.util.StringTokenizer.nextToken(StringTokenizer.java:332) > at > org.apache.maven.plugin.changelog.ChangeLogReport.getAbsolutePath(ChangeLogReport.java:1344) > at > org.apache.maven.plugin.changelog.ChangeLogReport.generateLinks(ChangeLogReport.java:1266) > at > org.apache.maven.plugin.changelog.ChangeLogReport.generateLinks(ChangeLogReport.java:1208) > at > org.apache.maven.plugin.changelog.FileActivityReport.doRows(FileActivityReport.java:189) > at > org.apache.maven.plugin.changelog.FileActivityReport.doChangedSets(FileActivityReport.java:160) > at > org.apache.maven.plugin.changelog.FileActivityReport.doGenerateReport(FileActivityReport.java:125) > at > org.apache.maven.plugin.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:340) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:303) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:133) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:100) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > 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:597) > 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] Commented: (MCHANGELOG-108) read/write changelog.xml inconsistency
[
http://jira.codehaus.org/browse/MCHANGELOG-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219442#action_219442
]
Dennis Lundberg commented on MCHANGELOG-108:
I'm sorry, but I don't understand what it that is broken. Can you explain some
more?
Please use an example: "current behavior is this, but I expected it to be that".
> read/write changelog.xml inconsistency
> --
>
> Key: MCHANGELOG-108
> URL: http://jira.codehaus.org/browse/MCHANGELOG-108
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Grzegorz Kochanski
>Priority: Minor
>
> ChangelogHandler.java:165
> bufSet.setStartVersion(new
> ScmTag(attributes.getValue("startTag")));
> bufSet.setEndVersion(new ScmTag(attributes.getValue("endTag")));
> ChangeLogSet.java:180
> if ( startVersion != null )
> {
> buffer.append( " startVersion=\"" )
> .append( getStartVersion() )
> .append( "\"" );
> }
> if ( endVersion != null )
> {
> buffer.append( " endVersion=\"" )
> .append( getEndVersion() )
> .append( "\"" );
> }
> Please fix field name to startVersion/endVersion.
> When changelog.xml is present then settings like: type, range, dates should
> be taken from this file during repoprt generation.
--
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: (MCHANGELOG-85) Use the members Name in the changelog.html
[ http://jira.codehaus.org/browse/MCHANGELOG-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGELOG-85. - Resolution: Duplicate > Use the members Name in the changelog.html > -- > > Key: MCHANGELOG-85 > URL: http://jira.codehaus.org/browse/MCHANGELOG-85 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Affects Versions: 2.1 > Environment: Maven 2.0.8 >Reporter: Arnaud >Priority: Minor > > Why doesn't replace the member ID in the changelog.html by the member Name > when its possible (like it is in the dev-activity.html) > Or if it's was not possible, juste add a link to team-list.html like this : > team-list.html #IDnumber -- 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: (MCHANGELOG-67) Add parameter to allow errors during build
[
http://jira.codehaus.org/browse/MCHANGELOG-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219443#action_219443
]
Dennis Lundberg commented on MCHANGELOG-67:
---
I am not in favor of adding this feature.
If you create a branch you must update the SCM section in the POM. Otherwise
you won't be able to do a release from the branch.
> Add parameter to allow errors during build
> --
>
> Key: MCHANGELOG-67
> URL: http://jira.codehaus.org/browse/MCHANGELOG-67
> Project: Maven 2.x Changelog Plugin
> Issue Type: New Feature
>Reporter: Shelley Baker
>Priority: Minor
>
> Adding a parameter to prevent BUILD ERRORs when an error occurs in the
> changelog plugin could be quite convenient in certain cases. For example,
> when a project is copied or branched temporarily (or initially created), the
> SCM URLs defined in the POM may not always be updated. When the SCM path is
> not found, it causes the entire build to fail.
> {noformat}
> [INFO] Generate "Change Log" report.
> [INFO] Generating changed sets xml to: C:\the-project\target\changelog.xml
> [INFO] Executing: svn --non-interactive log -v -r "{2007-06-25 15:25:29
> +}:{2007-07-26 15:25:29 +}"
> https://scm.url/svn/the.group.id/trunk/the-project/
> [INFO] Working directory: C:\the-project\src\main\java
> [ERROR] Provider message:
> [ERROR] The svn command failed.
> [ERROR] Command output:
> [ERROR] svn: REPORT request failed on
> '/svn/!svn/bc/28239/the.group.id/trunk/the-project'
> svn: '/svn/!svn/bc/28239/the.group.id/trunk/the-project' path not found
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: An error is occurred during
> changelog command :
> Command failed.
> {noformat}
> An optional boolean parameter such as ${maven.changelog.error.ignore} could
> be quite convenient in such cases.
--
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: (MCHANGELOG-84) wrong SVN directory path created when using cascaded pom modules(?)
[
http://jira.codehaus.org/browse/MCHANGELOG-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHANGELOG-84.
-
Resolution: Not A Bug
I added an entry on the FAQ page about SCM URL inheritance.
> wrong SVN directory path created when using cascaded pom modules(?)
> ---
>
> Key: MCHANGELOG-84
> URL: http://jira.codehaus.org/browse/MCHANGELOG-84
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: java 1.5.0_13 / mac os x / maven 2.0.7
>Reporter: jens breitenstein
>
> When executing "site" the plugin accesses a wrong svn path (see log below).
> the pom look similar to this (well, I simplified it a bit :-)
> root.pom
>
> {code:xml}
>
>...
>
> ...
> configuration
> ...
>
>
>
> {code}
> pom (in directory configuration)
> --
> {code:xml}
>
> ... root.pom ...
>
> 4.0.0
> my.group.configuration
> PREFIX-configuration
> jar
>
>
> {code}
> directory layout:
> {noformat}
>
> ` root-pom
> `
> ` sub-module-pom this file defines the artifact
> "PREFIX-configuration.jar"
> {noformat}
> [INFO] Generating "Change Log" report.
> [INFO] Generating changed sets xml to:
> /**/trunk/configuration/target/changelog.xml
> [INFO] Executing: svn --username --password * --non-interactive log
> -v -r "{2008-03-24 13:32:56 +}:{2008-04-24 13:32:56 +}"
> https://***/svn/***/trunk/PREFIX-configuration
> [INFO] Working directory: //trunk/configuration
> [ERROR] Provider message:
> [ERROR] The svn command failed.
> [ERROR] Command output:
> [ERROR] svn: REPORT request failed on
> '/svn/!svn/bc/461/***/trunk/PREFIX-configuration'
> svn: '/svn/!svn/bc/461//trunk/PREFIX-configuration' path not found
> "PREFIX-configuration" is the artifact name in the "sub-module" pom not a
> directory. The root pom access this child pom via the module element
> "configuration" which is identical to the directory in the file system and
> the svn repository. So correctly the svn command should look like
> {noformat}"https://***/svn/***/trunk/configuration"{noformat} and not
> {noformat}"https://***/svn/***/trunk/PREFIX-configuration"{noformat}.
> In case I understand the error message correctly the plugin tries to read a
> directory which is named like the artifact-id which is wrong here?
--
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-2754) Please remove group id 'org.jomc' from sync.csv
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MAVENUPLOAD-2754. -- Resolution: Fixed Assignee: Brian Fox done > Please remove group id 'org.jomc' from sync.csv > --- > > Key: MAVENUPLOAD-2754 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2754 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Christian Schulte >Assignee: Brian Fox > > Group id 'org.jomc' migrated to Nexus @ OSS. Please remove it from sync.csv. > 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] Created: (MSITE-475) Unwanted lifecycle phases triggered by mvn site:site
Unwanted lifecycle phases triggered by mvn site:site
Key: MSITE-475
URL: http://jira.codehaus.org/browse/MSITE-475
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Benson Margulies
Attachments: huh.tar.gz
The attached test cases consists of a detached parent, an aggregating parent,
and a child.
Instructions:
{noformat}
1. cd 'parent'; mvn
2. mvn site:site
{noformat}
observe that the antrun execution from the compile phase is executed.
Then, if you like, edit the toplevel pom.xml to remove the element
that points to the parent in the parent directory, and observe that site:site
stops running the compile phase.
I can't see anything about that parent that has any reason to make the site
plugin turn around and launch the standard (non-site) lifecycle, but obviously
there's something I don't know.
--
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-475) Unwanted lifecycle phases triggered by mvn site:site
[
http://jira.codehaus.org/browse/MSITE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219470#action_219470
]
Benson Margulies commented on MSITE-475:
The javadoc plugin in the reporting section seems to be the trigger.
> Unwanted lifecycle phases triggered by mvn site:site
>
>
> Key: MSITE-475
> URL: http://jira.codehaus.org/browse/MSITE-475
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Benson Margulies
> Attachments: huh.tar.gz
>
>
> The attached test cases consists of a detached parent, an aggregating parent,
> and a child.
> Instructions:
> {noformat}
> 1. cd 'parent'; mvn
> 2. mvn site:site
> {noformat}
> observe that the antrun execution from the compile phase is executed.
> Then, if you like, edit the toplevel pom.xml to remove the element
> that points to the parent in the parent directory, and observe that site:site
> stops running the compile phase.
> I can't see anything about that parent that has any reason to make the site
> plugin turn around and launch the standard (non-site) lifecycle, but
> obviously there's something I don't know.
--
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: (MJAVADOC-281) Javadoc plugin in reporting section triggers compile phase
Javadoc plugin in reporting section triggers compile phase -- Key: MJAVADOC-281 URL: http://jira.codehaus.org/browse/MJAVADOC-281 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.6.1 Reporter: Benson Margulies Please see MSITE-475. Using the test case project attached there, you will observe that including the javadoc plugin in the reporting section has the result of triggering the compile phase when running mvn site:site. This is inconvenient and I think arguably wrong. -- 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-2753) Request add of new project "pojava" to central repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219479#action_219479 ] John Pile commented on MAVENUPLOAD-2753: Sorry. I appreciate your patience. I found and corrected a DNS issue and this time, tested successfully from a proxy instead of from the local network. > Request add of new project "pojava" to central repository > - > > Key: MAVENUPLOAD-2753 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2753 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: John Pile >Assignee: Juven Xu > > http://pojava.org/releases/pojava-2.2.1-bundle.jar > http://pojava.org/releases/persistence-2.2.1-bundle.jar > I am John Pile, aka "Phatfingers". This project is hosted on > https://sourceforge.net/projects/pojava/, and its home page is > http://pojava.org. Per your guide-central-repository-upload page, a project > will be deemed "suspicious" if it has no dependencies, and will require > verification. I wish to answer in advance that the "pojava" project > deliberately has no dependencies, and the "persistence" project is dependent > on "pojava". -- 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-2753) Request add of new project "pojava" to central repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juven Xu closed MAVENUPLOAD-2753. - Resolution: Fixed bundle is deployed: http://repo2.maven.org/maven2/org/pojava/ for your future deployment, please use Sonatype's DIY service: http://www.sonatype.com/people/2010/04/uploading-artifacts-to-the-central-maven-repository-diy/ > Request add of new project "pojava" to central repository > - > > Key: MAVENUPLOAD-2753 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2753 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: John Pile >Assignee: Juven Xu > > http://pojava.org/releases/pojava-2.2.1-bundle.jar > http://pojava.org/releases/persistence-2.2.1-bundle.jar > I am John Pile, aka "Phatfingers". This project is hosted on > https://sourceforge.net/projects/pojava/, and its home page is > http://pojava.org. Per your guide-central-repository-upload page, a project > will be deemed "suspicious" if it has no dependencies, and will require > verification. I wish to answer in advance that the "pojava" project > deliberately has no dependencies, and the "persistence" project is dependent > on "pojava". -- 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
