[jira] Closed: (MNG-2531) Source jar + POM changes
[ http://jira.codehaus.org/browse/MNG-2531?page=all ] Brett Porter closed MNG-2531. - Assignee: Brett Porter Resolution: Won't Fix - you can already create a source jar with sources:jar - you can already automate that by adding it to an execution in the package phase (which the release plugin does). It would not be sensible to do this by default though. - the IDEA plugin already preserves your source settings (or is supposed to). If it doesn't, that's a bug. Hope that covers it :) > Source jar + POM changes > > > Key: MNG-2531 > URL: http://jira.codehaus.org/browse/MNG-2531 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Reporter: Brian Topping > Assigned To: Brett Porter >Priority: Minor > > [This idea is kind of half-baked, but please think it through. I think it > could save a lot of time if it worked.] > Would it be reasonable to automatically create some kind of source jar for > projects when they are built? All the data is there to create the source > tree, and if it was, the POM could be extended such that the IDE plugins such > as IDEA could make use of knowing where the sources are for a dependency, > download and unjar them automagically as a part of the build, then configure > the IDE project so the sources were linked to the JAR. > I'm thinking about this because the IDE plugins are really one of the best > integrations with the IDEs, but when one rebuilds the IDE project file, the > source links are typically destroyed. If you have several dependencies in > your IDE that you have to re-establish the source link with every time you > rebuild the project, the expense of using the IDE plugin goes way up. When > that happens, the IDE becomes an easier place to make the changes, and > sometimes these changes get forgotten about, breaking the Maven build. If > that's the de-facto build for an organization (because the IDEs can generate > from it), then it's a problem. > Another (probably easier) option would be to upgrade all the IDE plugins to > cache the existing source locations for JARs across runs of the project > generation, but it does require an implementation for each IDE plugin. > Storing sources in the Maven repos are probably not the ideal situation, but > putting hardcoded source addresses in the POM would not work either because > developers typically have different locations for things. It might be > possible to set it up so the local source addresses are stored in the user > properties, but that sounds like a very difficult thing to do in a clean > manner. > Thanks for reading this rather long winded brainstorm. -- 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-46) Using the dateFormat option the generate changelog report shows a wrong date
[ http://jira.codehaus.org/browse/MCHANGELOG-46?page=comments#action_73444 ] Giorgio Urto commented on MCHANGELOG-46: I confirm that the date returned by svn are in the format -MM-dd as you can see in the log D:\myproject\mycomponent >svn log pom.xml r463 | 990 | 2006-08-28 09:08:11 +0200 (lun, 28 ago 2006) | 1 line But i try to format the date using this template dd-MM-. Thank you > Using the dateFormat option the generate changelog report shows a wrong date > > --- > > Key: MCHANGELOG-46 > URL: http://jira.codehaus.org/browse/MCHANGELOG-46 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 >Reporter: Giorgio Urto > Assigned To: Dennis Lundberg >Priority: Minor > > Using the dateFormat option in the generated changelog report a file that was > changed the 14 december 2005 at 11.48.50 is show using this timestamp > 0020-05-27 00:00:00. > Here is my configuration for the plugin: > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-SNAPSHOT > > > dual-report > > range > 365 > dd-MM- > > > changelog > file-activity > dev-activity > > > > > Without the dateFormat attribute set, the date in the report is ok. -- 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-2531) Source jar + POM changes
[ http://jira.codehaus.org/browse/MNG-2531?page=comments#action_73445 ] Brian Topping commented on MNG-2531: Sweet, thanks! I'll check one more time on the source settings issue and file it on the idea plugin if so. It's probably something to do with Demetra. > Source jar + POM changes > > > Key: MNG-2531 > URL: http://jira.codehaus.org/browse/MNG-2531 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Reporter: Brian Topping > Assigned To: Brett Porter >Priority: Minor > > [This idea is kind of half-baked, but please think it through. I think it > could save a lot of time if it worked.] > Would it be reasonable to automatically create some kind of source jar for > projects when they are built? All the data is there to create the source > tree, and if it was, the POM could be extended such that the IDE plugins such > as IDEA could make use of knowing where the sources are for a dependency, > download and unjar them automagically as a part of the build, then configure > the IDE project so the sources were linked to the JAR. > I'm thinking about this because the IDE plugins are really one of the best > integrations with the IDEs, but when one rebuilds the IDE project file, the > source links are typically destroyed. If you have several dependencies in > your IDE that you have to re-establish the source link with every time you > rebuild the project, the expense of using the IDE plugin goes way up. When > that happens, the IDE becomes an easier place to make the changes, and > sometimes these changes get forgotten about, breaking the Maven build. If > that's the de-facto build for an organization (because the IDEs can generate > from it), then it's a problem. > Another (probably easier) option would be to upgrade all the IDE plugins to > cache the existing source locations for JARs across runs of the project > generation, but it does require an implementation for each IDE plugin. > Storing sources in the Maven repos are probably not the ideal situation, but > putting hardcoded source addresses in the POM would not work either because > developers typically have different locations for things. It might be > possible to set it up so the local source addresses are stored in the user > properties, but that sounds like a very difficult thing to do in a clean > manner. > Thanks for reading this rather long winded brainstorm. -- 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-46) Using the dateFormat option the generate changelog report shows a wrong date
[ http://jira.codehaus.org/browse/MCHANGELOG-46?page=comments#action_73447 ] Dennis Lundberg commented on MCHANGELOG-46: --- Like I said in a previous comment, the dateFormat parameter is not used for formating but for parsing. Do you have any suggestion on how we can make this more clear in the documentation? > Using the dateFormat option the generate changelog report shows a wrong date > > --- > > Key: MCHANGELOG-46 > URL: http://jira.codehaus.org/browse/MCHANGELOG-46 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 >Reporter: Giorgio Urto > Assigned To: Dennis Lundberg >Priority: Minor > > Using the dateFormat option in the generated changelog report a file that was > changed the 14 december 2005 at 11.48.50 is show using this timestamp > 0020-05-27 00:00:00. > Here is my configuration for the plugin: > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-SNAPSHOT > > > dual-report > > range > 365 > dd-MM- > > > changelog > file-activity > dev-activity > > > > > Without the dateFormat attribute set, the date in the report is ok. -- 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: (MRM-155) When proxy is used by maven1artifact are stored in managed repo using legacy layout.
[ http://jira.codehaus.org/browse/MRM-155?page=all ] nicolas de loof updated MRM-155: Attachment: DefaultProxyRequestHandler.java.patch patch Updated for "archiva" renamed project, with some cleanup from debug logs I've accidently included in previous patch > When proxy is used by maven1artifact are stored in managed repo using legacy > layout. > > > Key: MRM-155 > URL: http://jira.codehaus.org/browse/MRM-155 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Reporter: nicolas de loof > Attachments: DefaultProxyRequestHandler.java.patch, > DefaultProxyRequestHandler.java.patch, LegacyArtifactDiscoverer.java.patch > > > When Archiva downloads a maven1 artifact, (let's say servletapi-2.3) the > artifact is stored using legacy layout (maven1 path). When a maven2 client > asks for it, the artifact is downloaded a second time and stored using maven2 > layout. > This may produce lot's of duplicates in the managed repo. > request for "/proxy/xxx/servletapi\jars\servletapi-2.3.jar" > -> servletapi\servletapi\2.3\servletapi-2.3.jar.sha1 > -> servletapi\jars\servletapi-2.3.jar > request for "/proxy/xxx/servletapi\servletapi\2.3\servletapi-2.3.jar " > -> servletapi\servletapi\2.3\servletapi-2.3.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=comments#action_73452 ] Marek Bieganski commented on MNGECLIPSE-59: --- Step 0: Turn on auto build Step 1: Import attached simple projects Step 2: Deploy library project (jar and pom) into maven2 repository Setp 3: Clean workspace to ensure situation on picture 1 Step 4: Close library project (picture 2). Repository jar should be used, but eclipse is still looking for project "Project application is missing required Java project: 'library'" Cleaning workspace has no effect. Step 5: Close eclipse, and reopen it Situation is still like on picture 2 Step 6: Clean workspace This time it has effect, and jar from repository is used (picture 3). Step 7: Open library project Project is available, but jar is still used. (picture 4) First clean has no effect. Second clean has effect and we are back in step 3 Similar problems occurs on deleting and e.g importing library project. When auto build is on, no workspace cleaning nor closing eclipse should be needed. > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature > Components: Dependency Resolver >Affects Versions: 0.0.4 >Reporter: Leonardo Quijano Vincenzi > Attachments: ArtifactResolver-try3.patch, MNGECLIPSE-59, > mngeclipse-59-drew-hack.txt, project-artifacts-2006062701.patch, > project-artifacts-2006062900.patch, project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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: (MNGECLIPSE-59) Allow artifact resolution from workspace projects
[ http://jira.codehaus.org/browse/MNGECLIPSE-59?page=all ] Marek Bieganski updated MNGECLIPSE-59: -- Attachment: CloseAndOpen.zip > Allow artifact resolution from workspace projects > - > > Key: MNGECLIPSE-59 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-59 > Project: Maven 2.x Extension for Eclipse > Issue Type: New Feature > Components: Dependency Resolver >Affects Versions: 0.0.4 >Reporter: Leonardo Quijano Vincenzi > Attachments: ArtifactResolver-try3.patch, CloseAndOpen.zip, > MNGECLIPSE-59, mngeclipse-59-drew-hack.txt, > project-artifacts-2006062701.patch, project-artifacts-2006062900.patch, > project-artifacts.patch > > > Provide artifact resolution from workspace projects, which override the same > artifact from the local or remote repositories. This would allow to work with > dependant Eclipse projects without specifying the Eclipse dependency manually. > The workspace artifact resolution would have to be specified manually, since > several Maven-Enabled projects in the same workspace could have the same > artifact and version Id. Or at least automatic resolution with an optional > override would be nice. > More comments here: > http://jira.codehaus.org/browse/MNGECLIPSE-58 -- 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: (MRM-153) when used as a maven1 proxy, Archiva should handle relocation from maven2 poms
[ http://jira.codehaus.org/browse/MRM-153?page=all ] nicolas de loof updated MRM-153: Attachment: DefaultProxyManager.java.patch Patch updated for "archiva" renamed project. > when used as a maven1 proxy, Archiva should handle relocation from maven2 poms > -- > > Key: MRM-153 > URL: http://jira.codehaus.org/browse/MRM-153 > Project: Archiva > Issue Type: Improvement > Environment: Archiva as a repository proxy for maven1 >Reporter: nicolas de loof >Priority: Minor > Attachments: DefaultProxyManager.java.patch, patch.patch > > > When a maven1 client asks for /servletapi/jars/servletapi-2.4.jar, Archiva > converts path to the maven2 location of this artifact. As maven1 has no > relocation support, the jar is required in the repo. > Archiva can be more that a proxy : download the artifact POM, read relocation > infos, and return the relocated jar. > attached Patch add a new "applyRelocation" to DefaultProxyManager. > I've tried this code with the servletapi example, but it may be bad designed > as I just discovered maven / archiva APIs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1099) Upload jMock 1.1.0
Upload jMock 1.1.0 -- Key: MAVENUPLOAD-1099 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1099 Project: maven-upload-requests Issue Type: Task Reporter: Joerg Schaible http://people.apache.org/~joehni/jmock-cglib-1.1.0-bundle.jar jMock is a well known library for mock objects. New version released on weekend. -- 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-45) All reports generated links point to the trunk of the svn module
[ http://jira.codehaus.org/browse/MCHANGELOG-45?page=comments#action_73458 ] Rob MavenUser commented on MCHANGELOG-45: - I've tested it. Now it's ok. Using the pom above, the links point correctly to the files. Thanks Dennis Rob > All reports generated links point to the trunk of the svn module > > > Key: MCHANGELOG-45 > URL: http://jira.codehaus.org/browse/MCHANGELOG-45 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 > Environment: Windows >Reporter: Rob MavenUser > Assigned To: Dennis Lundberg >Priority: Minor > > Hello, > *all* my generated links (changelog reports, 2.0-SNAPSHOT, Maven 2.0.4) point > to the trunk of my svn module. > For example, for mypage.jsp, the link should be : > http://my.svn.com:/rep/prj/modname/trunk/src/www/webmodname/jsp/mypage.jsp > > but it is : > http://my.svn.com:/rep/prj/modname/trunk/ > The same for all my files. > Is it a bug or do I miss anything in my configuration ? > Thanks in advance > Best Regards > Rob > Here my settings : > ... > > > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-SNAPSHOT > > > dual-report > > range > 90 > > > changelog > file-activity > dev-activity > > > > > > > > > > scm:svn:http://my.svn.com:/rep/prj/modname/trunk > > scm:svn:http://my.svn.com:/rep/prj/modname/trunk > > http://my.svn.com:/rep/prj/modname/trunk/ > > > > src/java > > > src/www > > > -- 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: (MRM-155) When proxy is used by maven1artifact are stored in managed repo using legacy layout.
[ http://jira.codehaus.org/browse/MRM-155?page=comments#action_73463 ] nicolas de loof commented on MRM-155: - The attached LegacyArtifactDiscoverer is an error. It is not required to solve this issue and introduced a test failure.. > When proxy is used by maven1artifact are stored in managed repo using legacy > layout. > > > Key: MRM-155 > URL: http://jira.codehaus.org/browse/MRM-155 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Reporter: nicolas de loof > Attachments: DefaultProxyRequestHandler.java.patch, > DefaultProxyRequestHandler.java.patch, LegacyArtifactDiscoverer.java.patch > > > When Archiva downloads a maven1 artifact, (let's say servletapi-2.3) the > artifact is stored using legacy layout (maven1 path). When a maven2 client > asks for it, the artifact is downloaded a second time and stored using maven2 > layout. > This may produce lot's of duplicates in the managed repo. > request for "/proxy/xxx/servletapi\jars\servletapi-2.3.jar" > -> servletapi\servletapi\2.3\servletapi-2.3.jar.sha1 > -> servletapi\jars\servletapi-2.3.jar > request for "/proxy/xxx/servletapi\servletapi\2.3\servletapi-2.3.jar " > -> servletapi\servletapi\2.3\servletapi-2.3.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRM-153) when used as a maven1 proxy, Archiva should handle relocation from maven2 poms
[ http://jira.codehaus.org/browse/MRM-153?page=all ] nicolas de loof updated MRM-153: Attachment: DefaultProxyManager.java.patch Patch updated to allow request for checksum on a relocated artifact to return the checksum of the relocated artifact. > when used as a maven1 proxy, Archiva should handle relocation from maven2 poms > -- > > Key: MRM-153 > URL: http://jira.codehaus.org/browse/MRM-153 > Project: Archiva > Issue Type: Improvement > Environment: Archiva as a repository proxy for maven1 >Reporter: nicolas de loof >Priority: Minor > Attachments: DefaultProxyManager.java.patch, > DefaultProxyManager.java.patch, patch.patch > > > When a maven1 client asks for /servletapi/jars/servletapi-2.4.jar, Archiva > converts path to the maven2 location of this artifact. As maven1 has no > relocation support, the jar is required in the repo. > Archiva can be more that a proxy : download the artifact POM, read relocation > infos, and return the relocated jar. > attached Patch add a new "applyRelocation" to DefaultProxyManager. > I've tried this code with the servletapi example, but it may be bad designed > as I just discovered maven / archiva APIs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-129) Release fails on EAR project with EJB module reference
[ http://jira.codehaus.org/browse/MRELEASE-129?page=comments#action_73465 ]
Markku Saarela commented on MRELEASE-129:
-
Same effect is for ejb-client type dependencies.
> Release fails on EAR project with EJB module reference
> --
>
> Key: MRELEASE-129
> URL: http://jira.codehaus.org/browse/MRELEASE-129
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: Mike Perham
> Fix For: 2.0
>
>
> {code:xml}
>
> com.webify.fabric
> fabric-pm-mdb
> 1.2.1
> ejb
>
> {code}
> During release:prepare, it transforms the POMs to the release version (as
> above) and then runs the full build. The EAR build fails because the EJB
> artifact is not installed to the local repo so it can't package that
> dependent module by pulling it from the local repo.
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) com.webify.fabric:fabric-pm-mdb:ejb:1.2.1
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=com.webify.fabric
> -DartifactId=fabric-pm-mdb \
> -Dversion=1.2.1 -Dpackaging=ejb -Dfile=/path/to/file
> Path to dependency:
> 1) com.webify.fabric:fabric-tools-ear:ear:4.1.1
> 2) com.webify.fabric:fabric-pm-mdb:ejb:1.2.1
> The workaround is to let it fail, run the build by hand to populate the local
> repo and run the prepare goal again so it can find the binary.
--
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: (CONTINUUM-808) continuum-core-it does not use sever time zone
[ http://jira.codehaus.org/browse/CONTINUUM-808?page=all ] Jason van Zyl closed CONTINUUM-808. --- Resolution: Fixed Patch applied. > continuum-core-it does not use sever time zone > -- > > Key: CONTINUUM-808 > URL: http://jira.codehaus.org/browse/CONTINUUM-808 > Project: Continuum > Issue Type: Bug > Environment: Debian Linux >Reporter: Andrew Williams > Assigned To: Jason van Zyl > Attachments: it-localtime.patch > > > Propagating a patch from continutrac whereby the times are in UTC rather than > servers timezone. > patch applies in the continuum-core-it directpry, on top of other patches I > have submitted -- 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: (CONTINUUM-753) buildNumber is incorrectly reported if a build fails after a build has suceedded
[ http://jira.codehaus.org/browse/CONTINUUM-753?page=all ] Jason van Zyl closed CONTINUUM-753. --- Resolution: Fixed Patch applied. > buildNumber is incorrectly reported if a build fails after a build has > suceedded > > > Key: CONTINUUM-753 > URL: http://jira.codehaus.org/browse/CONTINUUM-753 > Project: Continuum > Issue Type: Bug > Components: XMLRPC Interface >Affects Versions: 1.0.3 > Environment: debian linux / ubuntu linux >Reporter: Andrew Williams > Assigned To: Jason van Zyl >Priority: Minor > Fix For: 1.1 > > Attachments: buildnumber.patch > > > If buildNumber is 0 then it is blanked by the python. > Unfortunately the buildNumber is reported as the last successful, so we need > to blank it if the build nwas not successful, not if the number is 0 > Attatched patch on continuum-core-it does just that -- 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: (CONTINUUM-754) build details lists build numbers for build that have failed
[ http://jira.codehaus.org/browse/CONTINUUM-754?page=all ] Jason van Zyl closed CONTINUUM-754. --- Resolution: Fixed Patch applied. > build details lists build numbers for build that have failed > > > Key: CONTINUUM-754 > URL: http://jira.codehaus.org/browse/CONTINUUM-754 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.0.3 > Environment: dbian linux / ubuntu linux >Reporter: Andrew Williams > Assigned To: Jason van Zyl >Priority: Minor > Fix For: 1.1 > > Attachments: web-buildid.patch > > > The build list correctly omits the build number if a build has failed, but > the build details page lists the number of the last successful build instead > of omitting it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-468) ability to consistently apply a toolchain across plugins
[ http://jira.codehaus.org/browse/MNG-468?page=comments#action_73471 ] Milos Kleint commented on MNG-468: -- discussed on mailing list at http://www.nabble.com/-proposal--toolchain-support-for-Maven-2.1-tf1942937.html#a5325520 > ability to consistently apply a toolchain across plugins > > > Key: MNG-468 > URL: http://jira.codehaus.org/browse/MNG-468 > Project: Maven 2 > Issue Type: New Feature >Reporter: Brett Porter >Priority: Minor > Fix For: 2.1 > > > for things like the JDK, it may be desirable to compile, jar etc. across the > board with a particular version of the toolchain, other than the one > currently executing. It would be good to be able to configure this location > in the settings.xml and have the plugins use it, forking the compiler, using > a particular runtime, and generating an appropriate manifest. > This is likely to be relevant to other languages too. -- 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: (MPECLIPSE-102) Running 'maven:eclipse' turns CheckStyle off for the project.
[ http://jira.codehaus.org/browse/MPECLIPSE-102?page=comments#action_73473 ] Jamie Bisotti commented on MPECLIPSE-102: - Since it's fixed in M2 version, can't it be fixed fairly easily in the M1 version too? > Running 'maven:eclipse' turns CheckStyle off for the project. > - > > Key: MPECLIPSE-102 > URL: http://jira.codehaus.org/browse/MPECLIPSE-102 > Project: maven-eclipse-plugin > Issue Type: Bug >Affects Versions: 1.9 >Reporter: Jamie Bisotti > > Assuming project is already setup in Eclipse 3.1 (either manually or via the > eclipse plugin) > 1. Install CheckStyle Eclispe plugin > 2. Turn it on for the project. > 3. Shutdown Eclipse > 4. Run maven eclipse on the project > 5. Restart Eclipse > 6. Notice CheckStyle is now turned off. -- 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: (MSUREFIRE-114) With forkmode once, XML reports are cumulative
[ http://jira.codehaus.org/browse/MSUREFIRE-114?page=all ] Eugene Zhuravlev updated MSUREFIRE-114: --- Attachment: XMLReporter-patch.txt Attached is the patch for the XMLReporter that fixes the problem > With forkmode once, XML reports are cumulative > -- > > Key: MSUREFIRE-114 > URL: http://jira.codehaus.org/browse/MSUREFIRE-114 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Daniel Kulp > Fix For: 2.3 > > Attachments: XMLReporter-patch.txt > > > With forkmode set to once, the resulting XML files seem to include the test > results of all the tests in the previous suites as well as it's own. > pseudo example: > ATest is run, it has 2 test methods. The ATest.xml report says 2 tests run > and passed > BTest is run, it has 2 test methods. The BTest.xml report says 4 tests run > and passed. > CTest is run, it has 3 test methods. The CTest.xml report says 7 tests run > and passed. > When we use cruisecontrol or other reporting tools, it then say 13 tests run > and passed instead of 5. What's worse, if a test in ATest fails, it's > listed as a failure in all the tests so you get 3 tests failed, not 1. > Plus, it's harder to figure out which test suite reallly had the failure. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-176) AbstractSiteRenderingMojo causes a NPE if url of current project is not set
[ http://jira.codehaus.org/browse/MSITE-176?page=all ] Vincent Siveton updated MSITE-176: -- Attachment: msite-176.log I tried all your steps (see log file) and all works a treat here. I tried with msite version 2.0-SNAPSHOT, 2.0-beta-5 and 2.0-beta-4 > AbstractSiteRenderingMojo causes a NPE if url of current project is not set > --- > > Key: MSITE-176 > URL: http://jira.codehaus.org/browse/MSITE-176 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: WinXP, Java5 >Reporter: Martin Zeltner >Priority: Blocker > Attachments: msite-176.log, patch_maven-site-plugin.txt > > > AbstractSiteRenderingMojo causes a NullPointerException in > org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler > if url of current project is not set. > $ mvn site:site > ... > [INFO] [site:site] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.getParentPrefix > (DefaultDecorationModelInheritanceAssembler.java:340) > at > org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelIn > heritance(DefaultDecorationModelInheritanceAssembler.java:46) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:225 > ) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:217 > ) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:492 > ) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo. > java:431) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:108) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:417) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:393) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:182) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:690) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:380) > 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 url is mostly not set, anyway not for each child module. To solve this > issue I did the following in method *getDecorationModel* of > *org.apache.maven.plugins.site.AbstractSiteRenderingMojo*: > If the parent model descriptor exists, the current and the parent model will > be assembled by using following url parameters: > If parent's url is null but child's not child's url will be used for parent. > If both urls are null the "url" "./" will be used for current and parent. > See appended patch. > Cheers, > Martin -- 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: h
[jira] Commented: (MCHANGELOG-45) All reports generated links point to the trunk of the svn module
[ http://jira.codehaus.org/browse/MCHANGELOG-45?page=comments#action_73477 ] Giorgio Urto commented on MCHANGELOG-45: I've also tested it. Now the links are ok. Thanks Dennis Giorgio > All reports generated links point to the trunk of the svn module > > > Key: MCHANGELOG-45 > URL: http://jira.codehaus.org/browse/MCHANGELOG-45 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 > Environment: Windows >Reporter: Rob MavenUser > Assigned To: Dennis Lundberg >Priority: Minor > > Hello, > *all* my generated links (changelog reports, 2.0-SNAPSHOT, Maven 2.0.4) point > to the trunk of my svn module. > For example, for mypage.jsp, the link should be : > http://my.svn.com:/rep/prj/modname/trunk/src/www/webmodname/jsp/mypage.jsp > > but it is : > http://my.svn.com:/rep/prj/modname/trunk/ > The same for all my files. > Is it a bug or do I miss anything in my configuration ? > Thanks in advance > Best Regards > Rob > Here my settings : > ... > > > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-SNAPSHOT > > > dual-report > > range > 90 > > > changelog > file-activity > dev-activity > > > > > > > > > > scm:svn:http://my.svn.com:/rep/prj/modname/trunk > > scm:svn:http://my.svn.com:/rep/prj/modname/trunk > > http://my.svn.com:/rep/prj/modname/trunk/ > > > > src/java > > > src/www > > > -- 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-46) Using the dateFormat option the generate changelog report shows a wrong date
[ http://jira.codehaus.org/browse/MCHANGELOG-46?page=comments#action_73479 ] Giorgio Urto commented on MCHANGELOG-46: I beg your pardon, i don't read enough carefully the usage for the parameter. "This format will also be reflected in the reports." makes me in error, but the documentation is clear as your explanation. Thank you. > Using the dateFormat option the generate changelog report shows a wrong date > > --- > > Key: MCHANGELOG-46 > URL: http://jira.codehaus.org/browse/MCHANGELOG-46 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 >Reporter: Giorgio Urto > Assigned To: Dennis Lundberg >Priority: Minor > > Using the dateFormat option in the generated changelog report a file that was > changed the 14 december 2005 at 11.48.50 is show using this timestamp > 0020-05-27 00:00:00. > Here is my configuration for the plugin: > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-SNAPSHOT > > > dual-report > > range > 365 > dd-MM- > > > changelog > file-activity > dev-activity > > > > > Without the dateFormat attribute set, the date in the report is ok. -- 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-45) All reports generated links point to the trunk of the svn module
[ http://jira.codehaus.org/browse/MCHANGELOG-45?page=comments#action_73481 ] Giorgio Urto commented on MCHANGELOG-45: We have structured ours svn repository in a format of . often whe have product and component with equals name es: http://mysubversion/workarea/lgrefapp/lgrefapp/trunk... The links generated by changelog (only in this situation) are like "http://mysubversion/workarea/lgrefapp/trunk/"; so the link generated loose one of the repetition for the word "lgrefapp". This is a known behaviour? There are workaround/solution? Thank you Giorgio > All reports generated links point to the trunk of the svn module > > > Key: MCHANGELOG-45 > URL: http://jira.codehaus.org/browse/MCHANGELOG-45 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 > Environment: Windows >Reporter: Rob MavenUser > Assigned To: Dennis Lundberg >Priority: Minor > > Hello, > *all* my generated links (changelog reports, 2.0-SNAPSHOT, Maven 2.0.4) point > to the trunk of my svn module. > For example, for mypage.jsp, the link should be : > http://my.svn.com:/rep/prj/modname/trunk/src/www/webmodname/jsp/mypage.jsp > > but it is : > http://my.svn.com:/rep/prj/modname/trunk/ > The same for all my files. > Is it a bug or do I miss anything in my configuration ? > Thanks in advance > Best Regards > Rob > Here my settings : > ... > > > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-SNAPSHOT > > > dual-report > > range > 90 > > > changelog > file-activity > dev-activity > > > > > > > > > > scm:svn:http://my.svn.com:/rep/prj/modname/trunk > > scm:svn:http://my.svn.com:/rep/prj/modname/trunk > > http://my.svn.com:/rep/prj/modname/trunk/ > > > > src/java > > > src/www > > > -- 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: (MSOURCES-6) Sources plugin ignores resource includes/excludes
[ http://jira.codehaus.org/browse/MSOURCES-6?page=all ] Micah Whitacre updated MSOURCES-6: -- Attachment: maven-sources-plugin-patches_v1.1.zip Patches for the files that do no include non-passive changes. > Sources plugin ignores resource includes/excludes > - > > Key: MSOURCES-6 > URL: http://jira.codehaus.org/browse/MSOURCES-6 > Project: Maven 2.x Sources Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Matthew Beermann >Priority: Critical > Fix For: 2.0.2 > > Attachments: maven-sources-plugin-patches.zip, > maven-sources-plugin-patches_v1.1.zip, patch.txt > > > The sources plugin appears to ignore the and filters on > items. I discovered this because I have a project that needs to > package certain files that appear in the project root; e.g. > ., and then I certain files. > Trouble is, when the source plugin runs, it packages up EVERYTHING - > including the stuff in the "target" (output) directory! This leads to a > source attachment that's much too large. Worse, if you forget to clean > between builds, the size of the source jar will increase exponentially with > each build. > Checking out the source code at > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-source-plugin/src/main/java/org/apache/maven/plugin/source/AbstractJarSourceMojo.java?view=markup, > I think the problem is in the addDirectories() method, which is simply > adding resource.getDirectory() and dropping the other information on the > floor. -- 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: (MAVEN-1784) running war plugin while skipping unit tests results in a war without src and resources
running war plugin while skipping unit tests results in a war without src and resources --- Key: MAVEN-1784 URL: http://jira.codehaus.org/browse/MAVEN-1784 Project: Maven Issue Type: Bug Components: core Affects Versions: 1.1-beta-3 Reporter: Michael Franken Priority: Critical (Probably) due to Jelly issues, plugin pregoals are sometimes evaluated wrongly. In our case this causes a war goal to NOT call the necessary pregoal (java:jar-resources and even java:compile) when you skip running the tests (maven.test.skip=true). The problem does not occur with maven 1.02, and it does not occur when NOT skipping unit tests. The issues can be verified by running: maven -Dmaven.test,skip=true war on a web 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] Commented: (MAVEN-1784) running war plugin while skipping unit tests results in a war without src and resources
[ http://jira.codehaus.org/browse/MAVEN-1784?page=comments#action_73487 ] Marnix J. van Wendel de Joode commented on MAVEN-1784: -- This goes for the ejb plugin as well. When running ejb:install with maven.test.skip=true no XML files are included in the META-INF directory of the resulting jar. > running war plugin while skipping unit tests results in a war without src and > resources > --- > > Key: MAVEN-1784 > URL: http://jira.codehaus.org/browse/MAVEN-1784 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 1.1-beta-3 >Reporter: Michael Franken >Priority: Critical > > (Probably) due to Jelly issues, plugin pregoals are sometimes evaluated > wrongly. In our case this causes a war goal to NOT call the necessary pregoal > (java:jar-resources and even java:compile) when you skip running the tests > (maven.test.skip=true). The problem does not occur with maven 1.02, and it > does not occur when NOT skipping unit tests. > The issues can be verified by running: > maven -Dmaven.test,skip=true war on a web 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] Closed: (MCHANGELOG-45) All reports generated links point to the trunk of the svn module
[ http://jira.codehaus.org/browse/MCHANGELOG-45?page=all ] Dennis Lundberg closed MCHANGELOG-45. - Resolution: Fixed Fix Version/s: 2.0 > All reports generated links point to the trunk of the svn module > > > Key: MCHANGELOG-45 > URL: http://jira.codehaus.org/browse/MCHANGELOG-45 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 > Environment: Windows >Reporter: Rob MavenUser > Assigned To: Dennis Lundberg >Priority: Minor > Fix For: 2.0 > > > Hello, > *all* my generated links (changelog reports, 2.0-SNAPSHOT, Maven 2.0.4) point > to the trunk of my svn module. > For example, for mypage.jsp, the link should be : > http://my.svn.com:/rep/prj/modname/trunk/src/www/webmodname/jsp/mypage.jsp > > but it is : > http://my.svn.com:/rep/prj/modname/trunk/ > The same for all my files. > Is it a bug or do I miss anything in my configuration ? > Thanks in advance > Best Regards > Rob > Here my settings : > ... > > > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-SNAPSHOT > > > dual-report > > range > 90 > > > changelog > file-activity > dev-activity > > > > > > > > > > scm:svn:http://my.svn.com:/rep/prj/modname/trunk > > scm:svn:http://my.svn.com:/rep/prj/modname/trunk > > http://my.svn.com:/rep/prj/modname/trunk/ > > > > src/java > > > src/www > > > -- 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-45) All reports generated links point to the trunk of the svn module
[ http://jira.codehaus.org/browse/MCHANGELOG-45?page=comments#action_73496 ] Dennis Lundberg commented on MCHANGELOG-45: --- Giorgio, please file another JIRA issue for that. It's not something that I have heard of before. > All reports generated links point to the trunk of the svn module > > > Key: MCHANGELOG-45 > URL: http://jira.codehaus.org/browse/MCHANGELOG-45 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 > Environment: Windows >Reporter: Rob MavenUser > Assigned To: Dennis Lundberg >Priority: Minor > Fix For: 2.0 > > > Hello, > *all* my generated links (changelog reports, 2.0-SNAPSHOT, Maven 2.0.4) point > to the trunk of my svn module. > For example, for mypage.jsp, the link should be : > http://my.svn.com:/rep/prj/modname/trunk/src/www/webmodname/jsp/mypage.jsp > > but it is : > http://my.svn.com:/rep/prj/modname/trunk/ > The same for all my files. > Is it a bug or do I miss anything in my configuration ? > Thanks in advance > Best Regards > Rob > Here my settings : > ... > > > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-SNAPSHOT > > > dual-report > > range > 90 > > > changelog > file-activity > dev-activity > > > > > > > > > > scm:svn:http://my.svn.com:/rep/prj/modname/trunk > > scm:svn:http://my.svn.com:/rep/prj/modname/trunk > > http://my.svn.com:/rep/prj/modname/trunk/ > > > > src/java > > > src/www > > > -- 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-87) doc-files ignored if they reside in the resources directory
doc-files ignored if they reside in the resources directory --- Key: MJAVADOC-87 URL: http://jira.codehaus.org/browse/MJAVADOC-87 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Matthew Beermann It looks like MJAVADOC-76 was closed prematurely, or maybe it just had a bad summary. The bug is this: if you have a "doc-files" folder in the "src/main/resources" branch of your project, its contents will be omitted from the Javadoc output. However, if you move the same folder over to "src/main/java", it will be included in the output. This bug is present in the released (2.0) version of the plugin. The file "package.html", by comparison, will be included in the Javadoc output no matter where it is. This is the expected behavior, AFAICT. More information about the "doc-files" directory can be found here: http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javadoc.html#unprocessed -- 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-46) Using the dateFormat option the generate changelog report shows a wrong date
[ http://jira.codehaus.org/browse/MCHANGELOG-46?page=all ] Dennis Lundberg closed MCHANGELOG-46. - Resolution: Fixed Fix Version/s: 2.0 I removed the section about the dateFormat being "reflected in the reports" so it won't confuse users. > Using the dateFormat option the generate changelog report shows a wrong date > > --- > > Key: MCHANGELOG-46 > URL: http://jira.codehaus.org/browse/MCHANGELOG-46 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 >Reporter: Giorgio Urto > Assigned To: Dennis Lundberg >Priority: Minor > Fix For: 2.0 > > > Using the dateFormat option in the generated changelog report a file that was > changed the 14 december 2005 at 11.48.50 is show using this timestamp > 0020-05-27 00:00:00. > Here is my configuration for the plugin: > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-SNAPSHOT > > > dual-report > > range > 365 > dd-MM- > > > changelog > file-activity > dev-activity > > > > > Without the dateFormat attribute set, the date in the report is ok. -- 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-1099) Upload jMock 1.1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1099?page=comments#action_73501 ] Carlos Sanchez commented on MAVENUPLOAD-1099: - ERROR 403: Forbidden > Upload jMock 1.1.0 > -- > > Key: MAVENUPLOAD-1099 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1099 > Project: maven-upload-requests > Issue Type: Task >Reporter: Joerg Schaible > > http://people.apache.org/~joehni/jmock-cglib-1.1.0-bundle.jar > jMock is a well known library for mock objects. New version released on > weekend. -- 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-1098) Upload Stripes 1.4 to IBiblio repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1098?page=all ] Carlos Sanchez closed MAVENUPLOAD-1098. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload Stripes 1.4 to IBiblio repository > > > Key: MAVENUPLOAD-1098 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1098 > Project: maven-upload-requests > Issue Type: Task >Reporter: Tim Fennell > Assigned To: Carlos Sanchez > -- 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-1099) Upload jMock 1.1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1099?page=comments#action_73502 ] Joerg Schaible commented on MAVENUPLOAD-1099: - Sorry, fixed! > Upload jMock 1.1.0 > -- > > Key: MAVENUPLOAD-1099 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1099 > Project: maven-upload-requests > Issue Type: Task >Reporter: Joerg Schaible > > http://people.apache.org/~joehni/jmock-cglib-1.1.0-bundle.jar > jMock is a well known library for mock objects. New version released on > weekend. -- 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: (CONTINUUM-549) A build must always be executed when previous was in failure even if there are no changes in scm
[ http://jira.codehaus.org/browse/CONTINUUM-549?page=comments#action_73503 ] Brill Pappin commented on CONTINUUM-549: I originally agreed with the comments from Jamie Flournoy, Henri Yandell, Trygve Laugstol but after using it for a while I have changed my mind. The reason is that there are many things that can cause a build to fail including dependency issues, build order, environment (e.g. systems bounces the cvs server) etc. and in those cases you *do not* want to change the code in the module thats failing because its dependency is failing. I've run into all of those mentioned in the last few weeks and it's a bit of a pain to have to go and "force" build the module. The only way to be sure that a build reruns if it fails is to run it even if there are no changes. If you don't have this ability then you have to manually go an force a build when it not actualy required. So IMO, Christian Gruber has the best idea -- make it configurable. > A build must always be executed when previous was in failure even if there > are no changes in scm > > > Key: CONTINUUM-549 > URL: http://jira.codehaus.org/browse/CONTINUUM-549 > Project: Continuum > Issue Type: Improvement > Components: Core system >Affects Versions: 1.0.2 >Reporter: Emmanuel Venisse > Fix For: 1.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGES-55) Add ability to turn off download URL in email
Add ability to turn off download URL in email - Key: MCHANGES-55 URL: http://jira.codehaus.org/browse/MCHANGES-55 Project: Maven 2.x Changes Plugin Issue Type: Improvement Reporter: Eric Bernstein If you are releasing a library, you may not want to provide a way to download except through the maven repository. Building that URL in the pom is non-trivial (unless you hardcode). It would be nice to be able to just remove that part from the email altogether. -- 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-1097) Upload ASM 2.2.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1097?page=all ] Carlos Sanchez closed MAVENUPLOAD-1097. --- Assignee: Carlos Sanchez Resolution: Fixed Next time please provide the files as they would be in the repo, subfolders, checksums,... > Upload ASM 2.2.3 > > > Key: MAVENUPLOAD-1097 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1097 > Project: maven-upload-requests > Issue Type: Task >Reporter: Eugene Kuleshov > Assigned To: Carlos Sanchez > > http://www.md.pp.ru/~eu/11/asm-2.2.3-bundle.zip > http://asm.objectweb.org/ > http://asm.objectweb.org/team.html > ASM is a Java bytecode manipulation framework. > Please note that this bundle actually contains 9 artifacts (including parent > pom) -- 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-1096) Upload ASM 3.0rc1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1096?page=comments#action_73505 ] Carlos Sanchez commented on MAVENUPLOAD-1096: - Please provide the files as they would be in the repo, subfolders, checksums,... Next time you can put several files in only one jira, or create a m2 repo to be synced, see end of http://maven.apache.org/guides/mini/guide-ibiblio-upload.html > Upload ASM 3.0rc1 > - > > Key: MAVENUPLOAD-1096 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1096 > Project: maven-upload-requests > Issue Type: Task >Reporter: Eugene Kuleshov > > http://www.md.pp.ru/~eu/11/asm-3.0_RC1-bundle.zip > http://asm.objectweb.org/ > http://asm.objectweb.org/team.html > ASM is a Java bytecode manipulation framework. > Please note that this bundle actually contains 8 artifacts (including parent > pom) -- 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-1094) jasperreports 1.2.5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1094?page=all ] Carlos Sanchez closed MAVENUPLOAD-1094. --- Assignee: Carlos Sanchez Resolution: Fixed > jasperreports 1.2.5 > --- > > Key: MAVENUPLOAD-1094 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1094 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina > Assigned To: Carlos Sanchez > -- 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: (MCHANGES-56) Default announcement.vm doesn't check issue type correctly.
Default announcement.vm doesn't check issue type correctly. - Key: MCHANGES-56 URL: http://jira.codehaus.org/browse/MCHANGES-56 Project: Maven 2.x Changes Plugin Issue Type: Bug Affects Versions: 2.0-beta-2 Reporter: Eric Bernstein Attachments: announcement.diff It currently displays all issue heads if new features exist. Attaching diff with my changes. -- 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-1095) Cojen 2.0.0 bundle upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1095?page=comments#action_73506 ] Carlos Sanchez commented on MAVENUPLOAD-1095: - why org.cojen, you must ptrovide proof of owning that domain or use net.sf.cojen > Cojen 2.0.0 bundle upload > - > > Key: MAVENUPLOAD-1095 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1095 > Project: maven-upload-requests > Issue Type: Task >Reporter: Brian S O'Neill > > Cojen is a Java library which makes it easy to dynamically generate and > inject Java bytecode. > I am listed as lead developer "broneill" on the team-list page. > http://cojen.sourceforge.net/team-list.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: (MAVENUPLOAD-1093) asm:asm-commons 2.2.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1093?page=all ] Carlos Sanchez closed MAVENUPLOAD-1093. --- Assignee: Carlos Sanchez Resolution: Fixed next time please put several related bundles in same issue > asm:asm-commons 2.2.2 > - > > Key: MAVENUPLOAD-1093 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1093 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina > Assigned To: Carlos Sanchez > -- 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-1092) asm:asm 2.2.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1092?page=all ] Carlos Sanchez closed MAVENUPLOAD-1092. --- Assignee: Carlos Sanchez Resolution: Fixed next time please put several related bundles in same issue > asm:asm 2.2.2 > - > > Key: MAVENUPLOAD-1092 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1092 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina > Assigned To: Carlos Sanchez > -- 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-16) when using svn, links are wrong
[ http://jira.codehaus.org/browse/MCHANGELOG-16?page=all ] Dennis Lundberg updated MCHANGELOG-16: -- Issue Type: Improvement (was: Bug) > when using svn, links are wrong > --- > > Key: MCHANGELOG-16 > URL: http://jira.codehaus.org/browse/MCHANGELOG-16 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Affects Versions: 2.0 > Environment: osx 10.4.5, java 1.4.2_09 >Reporter: Julian Wood >Priority: Minor > Attachments: MCHANGELOG-16.patch, test.zip > > > Here's my setup: > > scm:svn:http://apollo.ucalgary.ca:8800/pmgt/trunk > > scm:svn:http://apollo.ucalgary.ca:8800/pmgt/trunk > > http://apollo.ucalgary.ca/websvncommons/listing.php?repname=pmgt&rev=0&sc=0&path=/trunk > > ... > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-beta-2-SNAPSHOT > > > changes > > > http://apollo.ucalgary.ca/websvncommons/filedetails.php?repname=pmgt&rev=0&sc=0&path= > range > 90 > > > changelog > file-activity > dev-activity > > > > > With that displayFileDetailUrl, I get links like this in the resultant > changelog in my site: > http://apollo.ucalgary.ca/websvncommons/filedetails.php/trunk/pmgt-webapp/src/main/webapp/links/create_groups.jsp?repname=pmgt&sc=0&path= > but it should be like this: > link = > http://apollo.ucalgary.ca/websvncommons/filedetails.php?repname=pmgt&sc=0&rev=0&path=/trunk/pmgt-webapp/src/main/webapp/links/create_groups.jsp -- 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-16) when using svn, links are wrong
[ http://jira.codehaus.org/browse/MCHANGELOG-16?page=all ] Dennis Lundberg updated MCHANGELOG-16: -- Fix Version/s: (was: 2.0) > when using svn, links are wrong > --- > > Key: MCHANGELOG-16 > URL: http://jira.codehaus.org/browse/MCHANGELOG-16 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: osx 10.4.5, java 1.4.2_09 >Reporter: Julian Wood >Priority: Minor > Attachments: MCHANGELOG-16.patch, test.zip > > > Here's my setup: > > scm:svn:http://apollo.ucalgary.ca:8800/pmgt/trunk > > scm:svn:http://apollo.ucalgary.ca:8800/pmgt/trunk > > http://apollo.ucalgary.ca/websvncommons/listing.php?repname=pmgt&rev=0&sc=0&path=/trunk > > ... > > org.apache.maven.plugins > maven-changelog-plugin > 2.0-beta-2-SNAPSHOT > > > changes > > > http://apollo.ucalgary.ca/websvncommons/filedetails.php?repname=pmgt&rev=0&sc=0&path= > range > 90 > > > changelog > file-activity > dev-activity > > > > > With that displayFileDetailUrl, I get links like this in the resultant > changelog in my site: > http://apollo.ucalgary.ca/websvncommons/filedetails.php/trunk/pmgt-webapp/src/main/webapp/links/create_groups.jsp?repname=pmgt&sc=0&path= > but it should be like this: > link = > http://apollo.ucalgary.ca/websvncommons/filedetails.php?repname=pmgt&sc=0&rev=0&path=/trunk/pmgt-webapp/src/main/webapp/links/create_groups.jsp -- 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-1080) Upload org.eclipse.jdt:core:3.2.0.666 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1080?page=comments#action_73510 ] Carlos Sanchez commented on MAVENUPLOAD-1080: - we try to improve the repo with some minimal requirements > Upload org.eclipse.jdt:core:3.2.0.666 to ibiblio > > > Key: MAVENUPLOAD-1080 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1080 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > > http://www.mattwhitlock.com/core-3.2.0.666-bundle.jar > http://www.eclipse.org/jdt/ -- 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-1078) subethasmtp 1.0.3 bundles
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1078?page=all ] Carlos Sanchez closed MAVENUPLOAD-1078. --- Assignee: Carlos Sanchez Resolution: Fixed Next time please provide the files as they would be in the repo, with subfolders, checksums,... > subethasmtp 1.0.3 bundles > - > > Key: MAVENUPLOAD-1078 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1078 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina > Assigned To: Carlos Sanchez > > subethasmtp-smtp and subethasmtp-wiser bundles: contain jar, sources, javadoc > plus an additional artifact for the jdk14 compatible version with a "java14" > classifier > http://magnolia.sourceforge.net/bundles/subethasmtp-smtp-1.0.3-bundle.jar > http://magnolia.sourceforge.net/bundles/subethasmtp-wiser-1.0.3-bundle.jar > subethasmtp-parent: only contains the parent pom > http://magnolia.sourceforge.net/bundles/subethasmtp-parent-1.0.3-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1096) Upload ASM 3.0rc1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1096?page=comments#action_73511 ] Eugene Kuleshov commented on MAVENUPLOAD-1096: -- Carlos, the layout should be the same as for 2.2.3 you just uploaded as per MAVENUPLOAD-1097 ASM buils is currently not using Maven, so I don't really have checksums. Will look on synching repos for the future uploads, but can you please let me know what else you need from me for this one? > Upload ASM 3.0rc1 > - > > Key: MAVENUPLOAD-1096 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1096 > Project: maven-upload-requests > Issue Type: Task >Reporter: Eugene Kuleshov > > http://www.md.pp.ru/~eu/11/asm-3.0_RC1-bundle.zip > http://asm.objectweb.org/ > http://asm.objectweb.org/team.html > ASM is a Java bytecode manipulation framework. > Please note that this bundle actually contains 8 artifacts (including parent > pom) -- 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-1071) Spring Framework 2.0-rc3 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1071?page=comments#action_73512 ] Carlos Sanchez commented on MAVENUPLOAD-1071: - we don't upload incomplete poms, please check http://opensource.atlassian.com/projects/spring/browse/SPR-1484 to improve poms in spring CVS. > Spring Framework 2.0-rc3 upload request > --- > > Key: MAVENUPLOAD-1071 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1071 > Project: maven-upload-requests > Issue Type: Task >Reporter: Stepan Koltsov > > Please upload Spring Framework 2.0-rc3 to ibiblio. Spring is fantastic! > Spring contains many jars, all they are located under > http://mx1.ru/~yozh/2006-08-21/. URL are: > http://mx1.ru/~yozh/2006-08-21/spring-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-aop-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-aspects-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-beans-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-context-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-core-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-dao-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-hibernate2-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-hibernate3-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-ibatis-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-jca-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-jdbc-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-jdo-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-jms-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-jmx-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-jpa-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-mock-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-ojb-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-portlet-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-remoting-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-struts-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-support-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-toplink-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-web-2.0-rc3-maven.jar > http://mx1.ru/~yozh/2006-08-21/spring-webmvc-2.0-rc3-maven.jar > To make this bundle I've downloaded Spring binary distributive, and packed > each jar into own bundle. -- 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: (MAVEN-1784) running war plugin while skipping unit tests results in a war without src and resources
[ http://jira.codehaus.org/browse/MAVEN-1784?page=all ] Lukas Theussl closed MAVEN-1784. Assignee: Lukas Theussl Resolution: Duplicate Both the test and ejb plugins are scheduled to be re-released for Maven 1.1rc1 [1], if you think that your issues are not covered by the respective roadmaps [2,3], please open new tickets at either MPTEST or MPEJB. Thanks. [1] http://jira.codehaus.org/browse/MAVEN?report=com.atlassian.jira.plugin.system.project:roadmap-panel [2] http://jira.codehaus.org/browse/MPTEST?report=com.atlassian.jira.plugin.system.project:roadmap-panel [3] http://jira.codehaus.org/browse/MPEJB?report=com.atlassian.jira.plugin.system.project:roadmap-panel > running war plugin while skipping unit tests results in a war without src and > resources > --- > > Key: MAVEN-1784 > URL: http://jira.codehaus.org/browse/MAVEN-1784 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 1.1-beta-3 >Reporter: Michael Franken > Assigned To: Lukas Theussl >Priority: Critical > > (Probably) due to Jelly issues, plugin pregoals are sometimes evaluated > wrongly. In our case this causes a war goal to NOT call the necessary pregoal > (java:jar-resources and even java:compile) when you skip running the tests > (maven.test.skip=true). The problem does not occur with maven 1.02, and it > does not occur when NOT skipping unit tests. > The issues can be verified by running: > maven -Dmaven.test,skip=true war on a web 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] Commented: (MAVENUPLOAD-1080) Upload org.eclipse.jdt:core:3.2.0.666 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1080?page=comments#action_73514 ] Matt Whitlock commented on MAVENUPLOAD-1080: Added packaging and license information. Bundle JAR updated. > Upload org.eclipse.jdt:core:3.2.0.666 to ibiblio > > > Key: MAVENUPLOAD-1080 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1080 > Project: maven-upload-requests > Issue Type: Task >Reporter: Matt Whitlock > > http://www.mattwhitlock.com/core-3.2.0.666-bundle.jar > http://www.eclipse.org/jdt/ -- 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: (MCLOVER-51) Clover causes build failure
Clover causes build failure
---
Key: MCLOVER-51
URL: http://jira.codehaus.org/browse/MCLOVER-51
Project: Maven 2.x Clover Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Mike Perham
Priority: Critical
Fix For: 2.3
This is an interesting one. Take module A and B where B depends on A.
I run clover to get the coverage numbers for A. This installs A-clover.jar in
the repo.
I modify some interfaces in A and install A.jar. The tests pass.
I modify B to work with the new A interfaces and install B. The compile and
tests pass.
I run clover to get coverage numbers for B.
B fails to build because it says the code is not using A's old interfaces.
This is because Clover tries to use A-clover.jar instead of A.jar in the
classpath and the A-clover.jar was built before the code in A was refactored.
I would suggest that you prefer the newer of { a.jar, a-clover.jar} in order to
guarantee that these types of build failures will not occur. Marked as
Critical because the plugin is erroneously failing the build.
--
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: (MSUREFIRE-129) argLine with -Xmx option has no effect
[ http://jira.codehaus.org/browse/MSUREFIRE-129?page=comments#action_73515 ] Hendrik Schreiber commented on MSUREFIRE-129: - I believe I have a similar problem. Specifying disable assertions in 2.2 is broken, but works fine with 2.1.3. org.apache.maven.plugins maven-surefire-plugin -disableassertions leads to: [] [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-surefire-plugin:2.2:test' --> [DEBUG] (f) argLine = -disableassertions [DEBUG] (f) basedir = C:\IdeaProjects\beatunes\trunk\beatunes [DEBUG] (f) childDelegation = false [DEBUG] (f) classesDirectory = C:\IdeaProjects\beatunes\trunk\beatunes\target\classes [DEBUG] (f) classpathElements = [.] [DEBUG] (f) disableXmlReport = false [DEBUG] (f) forkMode = once [DEBUG] (f) jvm = java [DEBUG] (f) localRepository = [local] -> file://C:\Documents and Settings\Administrator\.m2\repository [DEBUG] (f) parallel = false [DEBUG] (f) pluginArtifactMap = [] [DEBUG] (f) printSummary = true [DEBUG] (f) projectArtifactMap = [] [DEBUG] (f) remoteRepositories = [[central] -> http://repo1.maven.org/maven2] [DEBUG] (f) reportFormat = brief [DEBUG] (f) reportsDirectory = C:\IdeaProjects\beatunes\trunk\beatunes\target\surefire-reports [DEBUG] (f) testClassesDirectory = C:\IdeaProjects\beatunes\trunk\beatunes\target\test-classes [DEBUG] (f) testSourceDirectory = C:\IdeaProjects\beatunes\trunk\beatunes\src\test\java [DEBUG] (f) threadCount = 5 [DEBUG] (f) trimStackTrace = true [DEBUG] (f) useFile = true [DEBUG] -- end configuration -- [...] Forking command line: java -disableassertions -classpath "C:\Documents and Setti ngs\Administrator\.m2\repository\org\apache\maven\surefire\surefire-api\2.0\sure fire-api-2.0.jar;C:\Documents and Settings\Administrator\.m2\repository\org\code haus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;C:\Documents and Settings\Admi nistrator\.m2\repository\org\apache\maven\surefire\surefire-booter\2.0\surefire- booter-2.0.jar" org.apache.maven.surefire.booter.SurefireBooter C:\DOCUME~1\ADMI NI~1\LOCALS~1\Temp\surefire34197tmp C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\surefire3 4198tmp So the commandline argument makes it into the displayed commandline. I just doubt that that commandline is actually executed. > argLine with -Xmx option has no effect > -- > > Key: MSUREFIRE-129 > URL: http://jira.codehaus.org/browse/MSUREFIRE-129 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Per Olesen > Fix For: 2.3 > > Attachments: OutOfMemoryError.log > > > In v2.1.3 of surefire plugin, this worked fine: > > org.apache.maven.plugins > maven-surefire-plugin > > pertest > -Xmx1024M > > > > But after doing a "mvn -U" and getting a v2.2 of the plugin, my tests starts > failing with OutOfMemoryException again. Doing a "mvn -X" shows me, that it > actually has read the option: > > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-surefire-plugin:2.2:test' --> > [DEBUG] (f) argLine = -Xmx1024M > > But maybe it is not applying the argline? > Forcing it to run with v2.1.3 makes everyting work again. -- 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: (MSUREFIRE-160) Documentation link on website does not point to surefire parameter docs
Documentation link on website does not point to surefire parameter docs --- Key: MSUREFIRE-160 URL: http://jira.codehaus.org/browse/MSUREFIRE-160 Project: Maven 2.x Surefire Plugin Issue Type: Bug Environment: irrelevant Reporter: Harold Shinsato Priority: Minor On page http://maven.apache.org/plugins/maven-surefire-plugin/howto.html, and the very end, there is a promise that "There are other parameters that you can configure like testFailureIgnore, reportsDirectory, and so on. For full documentation, click here." Clicking "here" only leads back to the empty index page. Where are the docs for the 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] Created: (MDEP-34) Documentation shows wrong groupId and artifactId
Documentation shows wrong groupId and artifactId Key: MDEP-34 URL: http://jira.codehaus.org/browse/MDEP-34 Project: Maven 2.x Dependency Plugin Issue Type: Bug Reporter: Binyan The current published documentation has examples that use the wrong groupId and artifactId as seen here, http://maven.apache.org/plugins/maven-dependency-plugin/howto.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] Created: (MAVENUPLOAD-1100) Please upload qalab-0.9.1
Please upload qalab-0.9.1 - Key: MAVENUPLOAD-1100 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1100 Project: maven-upload-requests Issue Type: Task Reporter: Benoit Xhenseval Attachments: qalab-0.9.1-bundle.jar Thanks a lot. Will it be also made available in the maven 2 repo? -- 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-1101) Please upload Maven 1 plugin for qalab-0.9.1
Please upload Maven 1 plugin for qalab-0.9.1 Key: MAVENUPLOAD-1101 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1101 Project: maven-upload-requests Issue Type: Task Reporter: Benoit Xhenseval Attachments: maven-qalab-plugin-0.9.1-bundle.jar 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: (MEAR-37) Parameters ignored when set on the command line
Parameters ignored when set on the command line --- Key: MEAR-37 URL: http://jira.codehaus.org/browse/MEAR-37 Project: Maven 2.x Ear Plugin Issue Type: Bug Environment: Win XP Reporter: Shelley L Several maven2 ear plugin configuration options seem to be ignored when set through the command line. The parameters outputDirectory, earName, workDirectory, and applicationXml are honored when set in the POM, but ignored when set on the command line. For example: After setting the workDirectory in the POM, and executing "mvn ear:ear," the outputDirectory is "test" as expected. test Other configuration options are honored as expected as well. However, when executing the ear goal from the command line, passing the configuration options using their expressions, the parameters are ignored. After executing the following: mvn clean ear:ear -Dproject.build.directory=test The outputDirectory remains the default "target," or whatever has been defined in the POM. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGELOG-47) Cannot find .cvspass file. Documentation not up-to-date.
Cannot find .cvspass file. Documentation not up-to-date. - Key: MCHANGELOG-47 URL: http://jira.codehaus.org/browse/MCHANGELOG-47 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.0-beta-1 Environment: Maven2 on Windows in Eclipse with CVS (anonymous pserver) Maven2 on GenToo in CruiseControl with CVS (anonymous pserver) Reporter: Paul R. Saxman I've run into a few issues while using this plugin, which are as follows: - When I try to run the Maven 2 changelog plugin in Eclipse or using CruiseControl, I get an error that the file .cvspass cannot be found. - I've found a reference to the .cvspass file on the Maven 1 plugin documentation, but not in the Maven 2 documentation. - The Maven 2 documentation specifies to use the groupId org.apache.maven.plugins for the plugin, which doesn't exist on ibiblio. The plugin actually exists at org.codehaus.mojo; HOWEVER, it is not documented as being part of Mojo at http://mojo.codehaus.org. - When I follow the Maven 1 instructions to generate the .cvspass file, I get the error "The plugin 'org.apache.maven.plugins:maven-changelog-plugin' does not exist or no valid version could be found". - Passing in a password (which doesn't really exist since I'm using an anonymous pserver) using the Maven 2 plugin "password" parameter has no effect, which is consistent with the documentation. Is there any way to not bother with a password or to specify an empty password? -- 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: (MDEP-34) Documentation shows wrong groupId and artifactId
[ http://jira.codehaus.org/browse/MDEP-34?page=all ] Dennis Lundberg closed MDEP-34. --- Resolution: Fixed Fixed in SVN. > Documentation shows wrong groupId and artifactId > > > Key: MDEP-34 > URL: http://jira.codehaus.org/browse/MDEP-34 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug >Reporter: Binyan > Assigned To: Dennis Lundberg > > The current published documentation has examples that use the wrong groupId > and artifactId as seen here, > http://maven.apache.org/plugins/maven-dependency-plugin/howto.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] Commented: (MAVENUPLOAD-1095) Cojen 2.0.0 bundle upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1095?page=comments#action_73522 ] Brian S O'Neill commented on MAVENUPLOAD-1095: -- Do a whois lookup. http://reports.internic.net/cgi/whois?whois_nic=cojen.org&type=domain > Cojen 2.0.0 bundle upload > - > > Key: MAVENUPLOAD-1095 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1095 > Project: maven-upload-requests > Issue Type: Task >Reporter: Brian S O'Neill > > Cojen is a Java library which makes it easy to dynamically generate and > inject Java bytecode. > I am listed as lead developer "broneill" on the team-list page. > http://cojen.sourceforge.net/team-list.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] Updated: (MNG-671) implement a license clickthrough
[ http://jira.codehaus.org/browse/MNG-671?page=all ] Daniel Gredler updated MNG-671: --- Attachment: maven-license-patches-3.zip I just realized the last patches I uploaded did not include new files. Argh. Uploading a third set of patches as a zip file that contains the missing files. > implement a license clickthrough > > > Key: MNG-671 > URL: http://jira.codehaus.org/browse/MNG-671 > Project: Maven 2 > Issue Type: New Feature >Reporter: Brett Porter > Fix For: 2.1 > > Attachments: maven-artifact-manager-patch-2.txt, > maven-artifact-manager-patch.txt, maven-artifact-patch-2.txt, > maven-license-patches-3.zip, maven-settings-patch-2.txt, > maven-settings-patch.txt > > > we need some basic license acceptance policy for downloadable artifacts. For > now, this can just be a Y/N that is saved forever. -- 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: (MRM-150) add field validations for forms
[ http://jira.codehaus.org/browse/MRM-150?page=all ] Maria Odea Ching updated MRM-150: - Due Date: 01/Sep/06 Remaining Estimate: 20 hours Original Estimate: 20 hours > add field validations for forms > --- > > Key: MRM-150 > URL: http://jira.codehaus.org/browse/MRM-150 > Project: Archiva > Issue Type: Task > Components: web application >Reporter: Brett Porter > Assigned To: Maria Odea Ching > Fix For: 1.0-beta-1 > > Original Estimate: 20 hours > Remaining Estimate: 20 hours > > these are documented in the validation files by todos -- 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-1096) Upload ASM 3.0rc1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1096?page=comments#action_73531 ] Eugene Kuleshov commented on MAVENUPLOAD-1096: -- Ok. I've created folder structure and checksums. http://www.md.pp.ru/~eu/11/asm-3.0_RC1-bundle2.zip > Upload ASM 3.0rc1 > - > > Key: MAVENUPLOAD-1096 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1096 > Project: maven-upload-requests > Issue Type: Task >Reporter: Eugene Kuleshov > > http://www.md.pp.ru/~eu/11/asm-3.0_RC1-bundle.zip > http://asm.objectweb.org/ > http://asm.objectweb.org/team.html > ASM is a Java bytecode manipulation framework. > Please note that this bundle actually contains 8 artifacts (including parent > pom) -- 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: (ARCHETYPE-45) Revise and review plugin documentation
[ http://jira.codehaus.org/browse/ARCHETYPE-45?page=all ] Maria Odea Ching closed ARCHETYPE-45. - Resolution: Fixed > Revise and review plugin documentation > -- > > Key: ARCHETYPE-45 > URL: http://jira.codehaus.org/browse/ARCHETYPE-45 > Project: Maven Archetype > Issue Type: Task >Reporter: Maria Odea Ching > Assigned To: Maria Odea Ching > Attachments: ARCHETYPE-45-maven-archetype-plugin-3.patch, > ARCHETYPE-45-maven-archetype-plugin.patch, > ARCHETYPE-45-maven-archetype-plugin.patch > > Original Estimate: 23 hours > Time Spent: 2 hours > Remaining Estimate: 21 hours > -- 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: (MRM-155) When proxy is used by maven1artifact are stored in managed repo using legacy layout.
[ http://jira.codehaus.org/browse/MRM-155?page=comments#action_73533 ] Brett Porter commented on MRM-155: -- Nicolas, we've started a policy of only applying patches with test cases to attempt to boost and maintain our test coverage. Please resubmit with a test that exhibits the problem, and the code that fixes it. Also, it really is difficult to apply a patch generated like this. Please use svn diff from the root of the project, as explained in the Maven "how to help" pages. Thanks! > When proxy is used by maven1artifact are stored in managed repo using legacy > layout. > > > Key: MRM-155 > URL: http://jira.codehaus.org/browse/MRM-155 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Reporter: nicolas de loof > Attachments: DefaultProxyRequestHandler.java.patch, > DefaultProxyRequestHandler.java.patch, LegacyArtifactDiscoverer.java.patch > > > When Archiva downloads a maven1 artifact, (let's say servletapi-2.3) the > artifact is stored using legacy layout (maven1 path). When a maven2 client > asks for it, the artifact is downloaded a second time and stored using maven2 > layout. > This may produce lot's of duplicates in the managed repo. > request for "/proxy/xxx/servletapi\jars\servletapi-2.3.jar" > -> servletapi\servletapi\2.3\servletapi-2.3.jar.sha1 > -> servletapi\jars\servletapi-2.3.jar > request for "/proxy/xxx/servletapi\servletapi\2.3\servletapi-2.3.jar " > -> servletapi\servletapi\2.3\servletapi-2.3.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-160) Lucene test sometime fail on Windows
Lucene test sometime fail on Windows Key: MRM-160 URL: http://jira.codehaus.org/browse/MRM-160 Project: Archiva Issue Type: Bug Components: indexing Environment: Windows 2000 / JRE 1.5.0_8 Reporter: nicolas de loof Priority: Minor When building archiva, I sometime get Failures on some Lucene tests : java.io.IOException: Directory D:\opensources\archiva\archiva-indexer\target\test-index unable to be deleted. This exception is throwed by commons-io FileUtils.deleteDirectory. According to http://www.gossamer-threads.com/lists/lucene/java-user/39116, some file handler opened by Lucene may stay opened and must wait for GC to be closed. Maybe this is an Lucene issue (handler may be closed explicitly, not just waiting for GC to do the job) ? -- 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
