[jira] (MSHADE-182) ServicesResourceTransformer incorrectly ignores given Relocators
[ https://jira.codehaus.org/browse/MSHADE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sharmarke Aden updated MSHADE-182: -- Attachment: MSHADE-182.patch This patch addresses both issue a and b mentioned above. > ServicesResourceTransformer incorrectly ignores given Relocators > > > Key: MSHADE-182 > URL: https://jira.codehaus.org/browse/MSHADE-182 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Thomas Kielbus > Attachments: MSHADE-182.patch, MSHADE-182.patch > > > When using the ServicesResourceTransformer in conjunction with relocators for > classes that have META-INF/services/ entries, the behavior of the Shade > Plugin is unexpected because those services files entries do not get > relocated. > For example: > Relocator: org.foo.Clazz to org.foo.shaded.Clazz > Services files: META-INF/services/org.foo.Clazz > We would expect a services file at META-INF/services/org.foo.shaded.Clazz in > the shaded jar, but that does not happen (the file remains at > META-INF/services/org.foo.Clazz) since the ServicesResourceTransformer > ignores the given Relocators. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHADE-182) ServicesResourceTransformer incorrectly ignores given Relocators
[ https://jira.codehaus.org/browse/MSHADE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356327#comment-356327 ] Sharmarke Aden commented on MSHADE-182: --- The issue is two folds: a) the service files must be relocated b) the content of the service files must also be relocated. The patch submitted by Trask address issue a but not b. > ServicesResourceTransformer incorrectly ignores given Relocators > > > Key: MSHADE-182 > URL: https://jira.codehaus.org/browse/MSHADE-182 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Thomas Kielbus > Attachments: MSHADE-182.patch > > > When using the ServicesResourceTransformer in conjunction with relocators for > classes that have META-INF/services/ entries, the behavior of the Shade > Plugin is unexpected because those services files entries do not get > relocated. > For example: > Relocator: org.foo.Clazz to org.foo.shaded.Clazz > Services files: META-INF/services/org.foo.Clazz > We would expect a services file at META-INF/services/org.foo.shaded.Clazz in > the shaded jar, but that does not happen (the file remains at > META-INF/services/org.foo.Clazz) since the ServicesResourceTransformer > ignores the given Relocators. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] Created: (SCM-240) add support for tagging a revision
add support for tagging a revision -- Key: SCM-240 URL: http://jira.codehaus.org/browse/SCM-240 Project: Maven SCM Issue Type: Improvement Components: maven-plugin, maven-scm-api Reporter: Sharmarke Aden I am not sure if this functionality can be supported by all scm providers but in subversion one can tag a revision using the copy command. I would love to see support added to SCM so that a) one can determine the current working revision and b) based on the working revision ID create a tag. In subversion on can do this by using the following set of commands. #get the working copy revision information svn info #create a tag from the trunk using revision 1204 svn copy -r1204 http://svn.example.com/repos/calc/trunk http://svn.example.com/repos/calc/tags/release-1.0 -m "revision tag" Notes: My understanding is that SCM API currently does support getting the revision of the current working copy. -- 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-2551) pom metadata file gets truncated during install into local repository
[ http://jira.codehaus.org/browse/MNG-2551?page=comments#action_74886 ] Sharmarke Aden commented on MNG-2551: - >>I went from version 0.3 to 0.4-SNAPSHOT yesterday and now this problem does >>not occur anymore for this project. You mean you are using the 0.4-SNAPSHOT of artifact? > pom metadata file gets truncated during install into local repository > - > > Key: MNG-2551 > URL: http://jira.codehaus.org/browse/MNG-2551 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Artifacts >Affects Versions: 2.0.4 > Environment: Win XP, JDK 1.4 >Reporter: Sharmarke Aden > Attachments: pom.xml, shared-1.9.0.pom > > > When I attempt to install my project artifact to my local repository it seems > that sometimes an incomplete/truncated ".pom" is deployed to my local > repository. It's kind of weird because sometimes it happens and sometimes it > doesn't. Any thoughts as to what could cause this? Attached is my pom.xml and > the truncated pom meta data artifact deployed to my local repository. One > thing I found that's odd is that the size of the truncated pom generated is > consistently 4096 bytes. > p.s. my pom.xml is UTF-8 encoded and uses Unix style line delimiters. -- 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-2551) pom metadata file gets truncated during install into local repository
[ http://jira.codehaus.org/browse/MNG-2551?page=comments#action_74763 ] Sharmarke Aden commented on MNG-2551: - Yes, I should have also mentioned that I'm using Continuum as well. This problem occurs when a project depends on another project. If we build the main project, the sub project is built first and during the build of the sub project is when a truncated pom file is installed into the local repository. Now an attempt is made to build the main project, and of course this is when everything comes crashing down because the sub project pom is not a valid/complete XML. I wasn't sure if this is a continuum bug or a artifact, but looking at the continuum code, I saw nothing whacking or bizarre. > pom metadata file gets truncated during install into local repository > - > > Key: MNG-2551 > URL: http://jira.codehaus.org/browse/MNG-2551 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Artifacts >Affects Versions: 2.0.4 > Environment: Win XP, JDK 1.4 >Reporter: Sharmarke Aden > Attachments: pom.xml, shared-1.9.0.pom > > > When I attempt to install my project artifact to my local repository it seems > that sometimes an incomplete/truncated ".pom" is deployed to my local > repository. It's kind of weird because sometimes it happens and sometimes it > doesn't. Any thoughts as to what could cause this? Attached is my pom.xml and > the truncated pom meta data artifact deployed to my local repository. One > thing I found that's odd is that the size of the truncated pom generated is > consistently 4096 bytes. > p.s. my pom.xml is UTF-8 encoded and uses Unix style line delimiters. -- 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-2551) pom metadata file gets truncated during install into local repository
pom metadata file gets truncated during install into local repository - Key: MNG-2551 URL: http://jira.codehaus.org/browse/MNG-2551 Project: Maven 2 Issue Type: Bug Components: Artifacts, Artifacts and Repositories Affects Versions: 2.0.4 Environment: Win XP, JDK 1.4 Reporter: Sharmarke Aden Attachments: pom.xml, shared-1.9.0.pom When I attempt to install my project artifact to my local repository it seems that sometimes an incomplete/truncated ".pom" is deployed to my local repository. It's kind of weird because sometimes it happens and sometimes it doesn't. Any thoughts as to what could cause this? Attached is my pom.xml and the truncated pom meta data artifact deployed to my local repository. One thing I found that's odd is that the size of the truncated pom generated is consistently 4096 bytes. p.s. my pom.xml is UTF-8 encoded and uses Unix style line delimiters. -- 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: (CONTINUUM-801) Maven2: Add Project Homepage URL to the project info page and build result page.
Maven2: Add Project Homepage URL to the project info page and build result page. Key: CONTINUUM-801 URL: http://jira.codehaus.org/browse/CONTINUUM-801 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.0.3 Reporter: Sharmarke Aden Priority: Minor Attachments: continuum_webinterface_homepage.patch In maven 2 you can specify a URL for your project's homepage in the pom.xml. It would be nice if a link to this URL could be show on the project info page and the build result page of continuum web interface. Attached is a patch that adds a row containing project homepage to both View.vm and ProjectBuild.vm if the property "$project.url" exists. -- 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: (MPMD-36) PMD Reports Not Generated for Projects Using POM Packaging
[ http://jira.codehaus.org/browse/MPMD-36?page=comments#action_69247 ] Sharmarke Aden commented on MPMD-36: In response to Mike Perham comments: Are you guys familiar with the assembly plugin (http://maven.apache.org/plugins/maven-assembly-plugin/introduction.html)? It provides an alternative way of package an application and as it stands you can't use the PMD plugin in conjunction with the assembly plugin. I believe this is an issue the PMD plugin needs to deal with. My application is packaged in fashion similar to the how Jetty is packaged (http://prdownloads.sourceforge.net/jetty/jetty-5.1.10.zip?download) . Look at their directory structure and try using war packaging to create that sort of directory structure. In response to Brett Porter comment: My patch also insures that the project has a source directory defined before proceeding. The patch basically allows the PMD continue if the follow condition is met: ((java || pom) && has source) > PMD Reports Not Generated for Projects Using POM Packaging > --- > > Key: MPMD-36 > URL: http://jira.codehaus.org/browse/MPMD-36 > Project: Maven 2.x Pmd Plugin > Type: Bug > Versions: 2.0 > Environment: WinXP SP2, Pentium 4, Cygwin, Maven 2.0.4 > Reporter: Sharmarke Aden > Assignee: Mike Perham > Attachments: modulePOM.xml, parentPOM.xml, pmd-plugin_MPMD36.patch > > > My project uses the assembly plugin and thus uses pom based packaging: > jar > It seems that the PMD plugin only creates reports for projects utilizing > archive based packaging such as jar and war but not for projects using pom > based packaging. -- 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: (MPMD-36) PMD Reports Not Generated for Projects Using POM Packaging
[ http://jira.codehaus.org/browse/MPMD-36?page=all ] Sharmarke Aden updated MPMD-36: --- Attachment: pmd-plugin_MPMD36.patch > PMD Reports Not Generated for Projects Using POM Packaging > --- > > Key: MPMD-36 > URL: http://jira.codehaus.org/browse/MPMD-36 > Project: Maven 2.x Pmd Plugin > Type: Bug > Versions: 2.0 > Environment: WinXP SP2, Pentium 4, Cygwin, Maven 2.0.4 > Reporter: Sharmarke Aden > Assignee: Mike Perham > Attachments: modulePOM.xml, parentPOM.xml, pmd-plugin_MPMD36.patch > > > My project uses the assembly plugin and thus uses pom based packaging: > jar > It seems that the PMD plugin only creates reports for projects utilizing > archive based packaging such as jar and war but not for projects using pom > based packaging. -- 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: (MPMD-36) PMD Reports Not Generated for Projects Using POM Packaging
[ http://jira.codehaus.org/browse/MPMD-36?page=comments#action_69143 ] Sharmarke Aden commented on MPMD-36: I have no control over directory structures if I use jar packaging. My project has to have the following directory structure: -> bin (directory) -> server -> lib (directory) -> conf (directory) -> config-templates (directory) -> app.config -> log4j.properties -> web (directory) -> WEB-INF -> classes -> [logs] (directory) -> start.sh I delved into the pmd plugin code in svn and it seems that the "canGenerateReport()" method in the AbstractPmdReport class returns false. The artifactHandler.getLanguage() call appears to return "none" which stops the plugin from further execution since the plugin requires that it return "java" to continue. > PMD Reports Not Generated for Projects Using POM Packaging > --- > > Key: MPMD-36 > URL: http://jira.codehaus.org/browse/MPMD-36 > Project: Maven 2.x Pmd Plugin > Type: Bug > Versions: 2.0 > Environment: WinXP SP2, Pentium 4, Cygwin, Maven 2.0.4 > Reporter: Sharmarke Aden > Assignee: Mike Perham > Attachments: modulePOM.xml, parentPOM.xml > > > My project uses the assembly plugin and thus uses pom based packaging: > jar > It seems that the PMD plugin only creates reports for projects utilizing > archive based packaging such as jar and war but not for projects using pom > based packaging. -- 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: (MPMD-36) PMD Reports Not Generated for Projects Using POM Packaging
[ http://jira.codehaus.org/browse/MPMD-36?page=comments#action_69136 ] Sharmarke Aden commented on MPMD-36: Sorry, "jar" in the bug description should be "pom" > PMD Reports Not Generated for Projects Using POM Packaging > --- > > Key: MPMD-36 > URL: http://jira.codehaus.org/browse/MPMD-36 > Project: Maven 2.x Pmd Plugin > Type: Bug > Versions: 2.0 > Environment: WinXP SP2, Pentium 4, Cygwin, Maven 2.0.4 > Reporter: Sharmarke Aden > Attachments: modulePOM.xml, parentPOM.xml > > > My project uses the assembly plugin and thus uses pom based packaging: > jar > It seems that the PMD plugin only creates reports for projects utilizing > archive based packaging such as jar and war but not for projects using pom > based packaging. -- 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: (MPMD-36) PMD Reports Not Generated for Projects Using POM Packaging
[ http://jira.codehaus.org/browse/MPMD-36?page=all ] Sharmarke Aden updated MPMD-36: --- Attachment: parentPOM.xml modulePOM.xml > PMD Reports Not Generated for Projects Using POM Packaging > --- > > Key: MPMD-36 > URL: http://jira.codehaus.org/browse/MPMD-36 > Project: Maven 2.x Pmd Plugin > Type: Bug > Versions: 2.0 > Environment: WinXP SP2, Pentium 4, Cygwin, Maven 2.0.4 > Reporter: Sharmarke Aden > Attachments: modulePOM.xml, parentPOM.xml > > > My project uses the assembly plugin and thus uses pom based packaging: > jar > It seems that the PMD plugin only creates reports for projects utilizing > archive based packaging such as jar and war but not for projects using pom > based packaging. -- 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: (MPMD-36) PMD Reports Not Generated for Projects Using POM Packaging
PMD Reports Not Generated for Projects Using POM Packaging --- Key: MPMD-36 URL: http://jira.codehaus.org/browse/MPMD-36 Project: Maven 2.x Pmd Plugin Type: Bug Versions: 2.0 Environment: WinXP SP2, Pentium 4, Cygwin, Maven 2.0.4 Reporter: Sharmarke Aden My project uses the assembly plugin and thus uses pom based packaging: jar It seems that the PMD plugin only creates reports for projects utilizing archive based packaging such as jar and war but not for projects using pom based packaging. -- 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-509) Ability to process scheduled builds the same as forced builds.
[ http://jira.codehaus.org/browse/CONTINUUM-509?page=comments#action_68720 ] Sharmarke Aden commented on CONTINUUM-509: -- The priority of this issue shouldn't be "minor" as it is an essential feature of a Continuous Integration Systems. I'd like to fix this bug and would appreciate it if anyone give me a hint as to what components I need to look at to resolve the bug. Thanks. > Ability to process scheduled builds the same as forced builds. > -- > > Key: CONTINUUM-509 > URL: http://jira.codehaus.org/browse/CONTINUUM-509 > Project: Continuum > Type: Improvement > Components: Core system > Versions: 1.0.2 > Reporter: Shinobu Kawai > Priority: Minor > Fix For: 1.1 > > > It would be great if you could configure a build schedule to act like a > forced build on the scheduled build. > The use case for this is when you have two build definitions: > - One will be set to default for a forced, light build. For example, install > the artifact. > - Another will be set to a scheduled, heavy build. For example, deploy the > artifact and the project site. > If the default build is triggered, the other build will be skipped since > nothing has been updated since the forced build. And we do not want to do > heavy stuff in the default 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: (MNG-2301) Maven Archiver deleteing already existing pom.properties file.
[ http://jira.codehaus.org/browse/MNG-2301?page=comments#action_68282 ] Sharmarke Aden commented on MNG-2301: - The rational behind not deleting the pom.properties files are: 1) Implicitly deleting a file explicitly created by the user is bad policy. 2) The idea behind not deleting the pom.properties is to facilitate external systems such as build systems to interact with maven. For example, communicating build number and date. The build system would place the build number in the pom.properties file and the maven can pickup this build information from the pom.properties file. Basically, this fix is necessary to support maven built-in properties enhancement request (see http://jira.codehaus.org/browse/MNG-1832). > Maven Archiver deleteing already existing pom.properties file. > -- > > Key: MNG-2301 > URL: http://jira.codehaus.org/browse/MNG-2301 > Project: Maven 2 > Type: Bug > Components: maven-archiver > Versions: 2.0.4 > Reporter: Sharmarke Aden > Fix For: 2.0.5 > Attachments: maven-archiver_pomDelete.patch > > > My project has it's own pom.properties file and it seems that maven archiver > is deleting it right after packaging the application. Any particular reason > why it's doing this? It seems to me the archiver shouldn't be deleting the > file if it already exists. It should delete the file if it doesn't exists > otherwise it should add the necessary information (version, groupId, etc) to > the file and leave it be. I have attached a patch that fixes the issue. > Also note that this patch adds the "builtOn" property to the pom.properties > which is satisfy the following enhancement request: > http://jira.codehaus.org/browse/MNG-1830 -- 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-1832) built-in property containing current timestamp
[ http://jira.codehaus.org/browse/MNG-1832?page=all ] Sharmarke Aden updated MNG-1832: Attachment: maven-core_defaultExpressions.patch > built-in property containing current timestamp > -- > > Key: MNG-1832 > URL: http://jira.codehaus.org/browse/MNG-1832 > Project: Maven 2 > Type: New Feature > Versions: 2.0.1 > Reporter: Michal Stochmialek > Attachments: maven-archiver_pomDelete.patch, > maven-core_defaultExpressions.patch > > > Current timestamp (time or date) is often used while filtering resources or > creating manifest in ant builds. There is no equivalent in maven. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-108) Assembly Plugin Implicitly Excludes Empty Directory
Assembly Plugin Implicitly Excludes Empty Directory --- Key: MASSEMBLY-108 URL: http://jira.codehaus.org/browse/MASSEMBLY-108 Project: Maven 2.x Assembly Plugin Type: Bug Versions: 2.1 Reporter: Sharmarke Aden It seems that the inclusion of an empty directory isn't currently possible with the assembly plugin. This is a problem because I would like to have an empty "logs" directory included with my zip file assembly. It would be nice if the assembly plugin gave you the option to add empty directories to an assembly. -- 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-1830) add a 'compiled on ' label when maven 2 is invoked with --version option
[ http://jira.codehaus.org/browse/MNG-1830?page=comments#action_65540 ] Sharmarke Aden commented on MNG-1830: - I have submitted the Maven-Archive patch to the archive component. Please use that patch instead. Note that a minor change has been made to the date format. It is now "MMM d HH:mm:ss z" http://jira.codehaus.org/browse/MNG-2301 > add a 'compiled on ' label when maven 2 is invoked with --version > option > > > Key: MNG-1830 > URL: http://jira.codehaus.org/browse/MNG-1830 > Project: Maven 2 > Type: Improvement > Reporter: Rahul Thakur > Priority: Minor > Attachments: bootstrap_builtOn.patch, maven-archiver_builtOn.patch > > > It might be a good idea to append > 'compiled on ' > when maven2 is invoked with '--version' swtich/option, just like Ant does. > Can be helpful when compiling m2 locally 'n' times and need to ensure the m2 > installation was infact updated or when was it last updated. -- 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-1832) built-in property containing current timestamp
[ http://jira.codehaus.org/browse/MNG-1832?page=all ] Sharmarke Aden updated MNG-1832: Attachment: maven-archiver_pomDelete.patch > built-in property containing current timestamp > -- > > Key: MNG-1832 > URL: http://jira.codehaus.org/browse/MNG-1832 > Project: Maven 2 > Type: New Feature > Versions: 2.0.1 > Reporter: Michal Stochmialek > Attachments: maven-archiver_pomDelete.patch > > > Current timestamp (time or date) is often used while filtering resources or > creating manifest in ant builds. There is no equivalent in maven. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2301) Maven Archiver deleteing already existing pom.properties file.
Maven Archiver deleteing already existing pom.properties file. -- Key: MNG-2301 URL: http://jira.codehaus.org/browse/MNG-2301 Project: Maven 2 Type: Bug Components: maven-archiver Versions: 2.0.4 Reporter: Sharmarke Aden Attachments: maven-archiver_pomDelete.patch My project has it's own pom.properties file and it seems that maven archiver is deleting it right after packaging the application. Any particular reason why it's doing this? It seems to me the archiver shouldn't be deleting the file if it already exists. It should delete the file if it doesn't exists otherwise it should add the necessary information (version, groupId, etc) to the file and leave it be. I have attached a patch that fixes the issue. Also note that this patch adds the "builtOn" property to the pom.properties which is satisfy the following enhancement request: http://jira.codehaus.org/browse/MNG-1830 -- 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-1830) add a 'compiled on ' label when maven 2 is invoked with --version option
[ http://jira.codehaus.org/browse/MNG-1830?page=all ] Sharmarke Aden updated MNG-1830: Attachment: bootstrap_builtOn.patch > add a 'compiled on ' label when maven 2 is invoked with --version > option > > > Key: MNG-1830 > URL: http://jira.codehaus.org/browse/MNG-1830 > Project: Maven 2 > Type: Improvement > Reporter: Rahul Thakur > Priority: Minor > Attachments: bootstrap_builtOn.patch, maven-archiver_builtOn.patch > > > It might be a good idea to append > 'compiled on ' > when maven2 is invoked with '--version' swtich/option, just like Ant does. > Can be helpful when compiling m2 locally 'n' times and need to ensure the m2 > installation was infact updated or when was it last updated. -- 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-1830) add a 'compiled on ' label when maven 2 is invoked with --version option
[ http://jira.codehaus.org/browse/MNG-1830?page=all ] Sharmarke Aden updated MNG-1830: Attachment: maven-archiver_builtOn.patch > add a 'compiled on ' label when maven 2 is invoked with --version > option > > > Key: MNG-1830 > URL: http://jira.codehaus.org/browse/MNG-1830 > Project: Maven 2 > Type: Improvement > Reporter: Rahul Thakur > Priority: Minor > Attachments: bootstrap_builtOn.patch, maven-archiver_builtOn.patch > > > It might be a good idea to append > 'compiled on ' > when maven2 is invoked with '--version' swtich/option, just like Ant does. > Can be helpful when compiling m2 locally 'n' times and need to ensure the m2 > installation was infact updated or when was it last updated. -- 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-1830) add a 'compiled on ' label when maven 2 is invoked with --version option
[ http://jira.codehaus.org/browse/MNG-1830?page=comments#action_65428 ] Sharmarke Aden commented on MNG-1830: - The truck version of "maven-cli/src/main/java/org/apache/maven/cli/MavenCli.java" includes the necessary code to add the build date when mvn --version is invoked but the problem is that MavenArchiver doesn't include the "builtOn" property that MavenCli looks for. I've created a patch for the MavenArchiver in component to add a "builtOn" property to the pom.properties file it generates. The maven bootstrap component also doesn't include the "builtOn" property to pom.properties file it generates. I have created a patch for that too. Note that the date format is "MMM d " (i.e. May 15 2006). > add a 'compiled on ' label when maven 2 is invoked with --version > option > > > Key: MNG-1830 > URL: http://jira.codehaus.org/browse/MNG-1830 > Project: Maven 2 > Type: Improvement > Reporter: Rahul Thakur > Priority: Minor > > > It might be a good idea to append > 'compiled on ' > when maven2 is invoked with '--version' swtich/option, just like Ant does. > Can be helpful when compiling m2 locally 'n' times and need to ensure the m2 > installation was infact updated or when was it last updated. -- 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: (MPSCM-79) [scm:tag] Add Ability to Append Timestamp to Tag Name
[scm:tag] Add Ability to Append Timestamp to Tag Name - Key: MPSCM-79 URL: http://jira.codehaus.org/browse/MPSCM-79 Project: maven-scm-plugin Type: New Feature Reporter: Sharmarke Aden Attachments: timestamp.patch I have created a patch that, based on configuration properties, appends today's date/time to the tag name that I would like to share and see part of scm plug-in's future releases. This enhancement adds three new configuration properties. 1) A Boolean property called "addTimestamp" which indicates whether the plug-in should append timestamp to the tag name. 2) A string property called "timestampFormat" which contains date pattern akin to java.text.SimpleDateFormat class. If "timestampFormat" is not set and "addTimestamp" property is set to true the default date pattern of "MMddHHmmss" will be used. 3) A string property called "timestampPrefix" which will be used to separate the tag name and the timestamp. The default timestampPrefix value is "-" Here is what the plug-in definition should look like: org.apache.maven.plugins maven-scm-plugin 1.0-beta-3 deploy tag http://my/svn/project/tags my-tag-name true MMddHHmmss -tag- ... Note that both timestampFormat and timestampPrefix have default values and therefore are optional. -- 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: (MPSCM-78) [SVN] scm:tag goal doesn't allow you to attach a message with a tag
[SVN] scm:tag goal doesn't allow you to attach a message with a tag --- Key: MPSCM-78 URL: http://jira.codehaus.org/browse/MPSCM-78 Project: maven-scm-plugin Type: Improvement Reporter: Sharmarke Aden I'm using SVN and it would be nice if support for adding your own custom message to a tag instead of the default hard-coded "[maven-scm] copy for tag [tag name]." I'm not sure if all the other SCM allow you to attache a message with a tag (I believe CVS doesn't) but adding support for this feature will require making a change to the tag(...) method in the ScmProvider interface and trickling that change down to all the SCM providers. If that won't work, perhaps we can set a system property called "scm.message" and check for that property in the SvnTagCommand class. -- 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-687) Option to trigger the SCM system to tag successful builds with a build number or timestamp.
[ http://jira.codehaus.org/browse/CONTINUUM-687?page=comments#action_65214 ] Sharmarke Aden commented on CONTINUUM-687: -- Since there are quite a number of continuous integration systems and project management systems out there you can't really pick a particular method and expect that to fly with everyone. Ideally what you want is to have some kind of protocol that's understood by everyone that passes a build number from the continuous integration system to the project management and leave it up to the project management system to do the actually work of tagging. In the case of Maven2, it's probably best to make the build number available to POM via a variable. I image that would be useful to people using ant as well. > Option to trigger the SCM system to tag successful builds with a build number > or timestamp. > --- > > Key: CONTINUUM-687 > URL: http://jira.codehaus.org/browse/CONTINUUM-687 > Project: Continuum > Type: New Feature > Components: Core system > Reporter: Christian Gruber > > > This is complex, because it would be different for each type. For maven2, > for example, it would be potentially compled on its own, insofar as tagging > is handled quite differently between CVS and SVN (to pick two). I could see > a potential workaround, if build defs were independent within a project, by > using a specific goal (say on a nightly build) and therefor "manually" > invoking scm:tag or something. > In short, I'm not sure if it's better to do this within the build system, or > continuum. Suggestions? Best practices anyone? -- 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
