[jira] Commented: (CONTINUUM-608) Script gets cut off when building a shell project
[ http://jira.codehaus.org/browse/CONTINUUM-608?page=comments#action_59461 ] Emmanuel Venisse commented on CONTINUUM-608: Can you attach your script? Script gets cut off when building a shell project - Key: CONTINUUM-608 URL: http://jira.codehaus.org/browse/CONTINUUM-608 Project: Continuum Type: Bug Components: Core system Versions: 1.0.2 Environment: Windows XP Pro SP2 Reporter: Mang Lau When building a shell project, the shell script exits prematurely after Maven finishes. This means that nothing else can be executed after the Maven build is successful. It seems that Continuum is receiving the Maven exit code right after Maven ends and cuts off (does not execute) the rest of the script code. I don't think this should be happening as you can't perform post-build tasks such as copying the build elsewhere or tagging it in CVS. -- 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: (CONTINUUM-605) Add a RecipientSource that derives addresses from the change list
[ http://jira.codehaus.org/browse/CONTINUUM-605?page=all ] Emmanuel Venisse updated CONTINUUM-605: --- Fix Version: (was: 1.0.3) 1.1 Add a RecipientSource that derives addresses from the change list - Key: CONTINUUM-605 URL: http://jira.codehaus.org/browse/CONTINUUM-605 Project: Continuum Type: New Feature Components: Core system Reporter: John Didion Fix For: 1.1 Attachments: ChangeListRecipientSource.diff CruiseControl has the nice feature of only sending notification email to those users who submitted the changes in the build. I missed that feature when switching to Continuum, so I implemented it. It compiles a list of scm ids from the change list, then matches them against the developers in the POM to get email addresses. It delegates to the default RecipientSource if there is no change list. -- 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
[continuum build trunk - SUCCESS - checkout] Sun Feb 26 01:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/trunk/continuum-20060226.01.war Log: http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build-log-20060226.01.txt
[continuum build branches/continuum-1.0.x - FAILED - checkout] Sun Feb 26 02:00:00 GMT 2006
Log: http://maven.zones.apache.org/~continuum/logs/branches/continuum-1.0.x/continuum-build-log-20060226.020001.txt
[continuum build trunk - SUCCESS - update] Sun Feb 26 03:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~continuum/builds/trunk/continuum-20060226.030001.war Log: http://maven.zones.apache.org/~continuum/logs/trunk/continuum-build-log-20060226.030001.txt
[jira] Commented: (SCM-168) PerforceChangeLogConsumer should use relative paths
[ http://jira.codehaus.org/browse/SCM-168?page=comments#action_59480 ]
Mike Perham commented on SCM-168:
-
Are you diffing off of the maven 1.x SCM source code or an old beta or alpha,
John? Your diff, while recognizable, does not match up with the latest
codebase. Nonetheless, I'm applying your changes by hand.
PerforceChangeLogConsumer should use relative paths
---
Key: SCM-168
URL: http://jira.codehaus.org/browse/SCM-168
Project: Maven SCM
Type: Bug
Components: maven-scm-provider-perforce
Versions: 1.0
Reporter: John Didion
Assignee: Mike Perham
Priority: Critical
Attachments: PerforceChangeLogConsumer.diff
It seems like all scm providers are dealing with relative paths, rather than
absolute repository paths. PerforceCheckOutCommand is definitely doing this.
PerforceChangeLogConsumer, however, does not, which means
ChangeSet.containsFilename always returns false because it's comparing a
relative path to an absolute one.
There are two changes. First, in PerforceChangeLogCommand:
{noformat}
PerforceChangeLogConsumer consumer = new PerforceChangeLogConsumer(
((PerforceScmProviderRepository) repo).getPath(), startDate, endDate );
{noformat}
The attached diff is for the second set of changes, which are to
PerforceChangeLogConsumer.
--
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: (SCM-165) PerforceChangeLogCommand needs to use the same clientspec as the update command
[ http://jira.codehaus.org/browse/SCM-165?page=comments#action_59481 ] Mike Perham commented on SCM-165: - This patch fails when running the changelog command in standalone mode. Use the SCM plugin to run a changelog on some directory mvn scm:changelog -DconnectionUrl=XXX where XXX is your developerConnection string in the POM and you will find that the command fails due to the clientspec not existing. This is because your patch assumes it is always run after an update. Nonetheless, I'm inclined to think this is better than before since Continuum is the major user of the changelog command and it wasn't working for Continuum before. I'm assuming that most people don't use the SCM plugin except for testing. Emmanuel, do you have any opinion here? Would you rather see the changelog command only work as part of an update/checkout or not work with those but work standalone? PerforceChangeLogCommand needs to use the same clientspec as the update command --- Key: SCM-165 URL: http://jira.codehaus.org/browse/SCM-165 Project: Maven SCM Type: Bug Components: maven-scm-provider-perforce Versions: 1.0 Reporter: John Didion Assignee: Mike Perham Priority: Critical Attachments: PerforceChangeLogCommand.diff, svn.diff The PerforceChangeLogCommand as written does not work if the update was done with the client spec generated by the checkout/update command. The attached diff will fix the problem. -- 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-61) systemProperties field is ignored
systemProperties field is ignored - Key: MSUREFIRE-61 URL: http://jira.codehaus.org/browse/MSUREFIRE-61 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.1.3 Environment: xp Reporter: Dan Tran Fix For: 2.1.3 Currently Maven does not support Properties field injection, change it to Map should work -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MSUREFIRE-61) systemProperties field is ignored
[ http://jira.codehaus.org/browse/MSUREFIRE-61?page=comments#action_59471 ] Dan Tran commented on MSUREFIRE-61: --- Better yet, have maven to support Properties injection systemProperties field is ignored - Key: MSUREFIRE-61 URL: http://jira.codehaus.org/browse/MSUREFIRE-61 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.1.3 Environment: xp Reporter: Dan Tran Fix For: 2.1.3 Currently Maven does not support Properties field injection, change it to Map should work -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MSUREFIRE-61) systemProperties field is ignored
[ http://jira.codehaus.org/browse/MSUREFIRE-61?page=all ] Dan Tran closed MSUREFIRE-61: - Assign To: Dan Tran Resolution: Fixed I will go ahead with Map injection. Once Maven supports Properties injection, we can reverse it and still backward compatible systemProperties field is ignored - Key: MSUREFIRE-61 URL: http://jira.codehaus.org/browse/MSUREFIRE-61 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.1.3 Environment: xp Reporter: Dan Tran Assignee: Dan Tran Fix For: 2.1.3 Currently Maven does not support Properties field injection, change it to Map should work -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Sat Feb 25 17:45:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060225.174500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060225.174500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Sat Feb 25 18:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060225.180001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060225.180001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-935) Gentoo style pom dependencies
[ http://jira.codehaus.org/browse/MNG-935?page=comments#action_59487 ] Philipp Scholl commented on MNG-935: I absolutely like this Idea. What's the current Status? Did Brian already implement something? Gentoo style pom dependencies - Key: MNG-935 URL: http://jira.codehaus.org/browse/MNG-935 Project: Maven 2 Type: Wish Environment: None appropriate Reporter: Brian C. Dilley Fix For: 2.1 I'm a long time Gentoo Linux (http://www.gentoo.org/) user, and i think that Maven could adpot some idea's from gentoo's portage (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2chap=1). Gentoo has a concept of ebuilds (which can be compared to poms). An ebuild is an install script of sorts for installing a particular piece of software. An ebuild defines, among other things, what it's dependencies (other ebuilds) are. There are two types of dependencies: optional and required. A required depency is something that the software needs to be built or run, while an optional depency is the exact opposite... it is optional at compile and run time. Basically an optional depency is a feature that the piece of sotware supports that isn't necessary for it to function. There is also something in gentoo called USE flags. Use flags are a system scope set of parameters that determine how ebuilds are built... and which features are included or excluded. For instance, alsa is a USE flag. If your use flags have alsa in them then any application that supports Alsa (Advanced Linux Sound Architecture) as an optional dependency will be compiled with support for alsa. Likewise, if your USE flags contain -alsa then anything that has optional support for alsa will not be compiled with support for alsa. I should also mention that if a particular ebuild requires alsa... alsa will be built as well as it (because it requires alsa at compile/run time)... but it and anything else that requires it will be the only piece of software on the machine that has alsa support. I should also note that Gentoo has what is called profiles. Profiles contain (among other things) a default set of USE flags for the general user, so in theory a Gentoo user doesn't have to modify their USE flags whatsoever. My thinking is that Maven could adopt this. Poms could specify required and optional dependencies, and at a project level USE flags could be defined to filter what gets included in a project. For instance someone using the Spring Framework may not be using Hibernate... in their use flags -hibernate could be defined so that maven knows not to grab hibernate (and all of it's dependencies) just because they want to use the spring MVC framework. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Publishing Glassfish jars (javax.* apis) in Maven repos
I'm hoping we can update the Sun Licensing Journey and get some javax.* apis published in Maven repository without requiring special permission from Sun now that Project Glassfish is publishing many of them under the CDDL license which very clearly *allows* distribution. I know there is an effort to introduce click to agree to license functionality in Maven in the near future, so certain Jars that require agreeing to a license etc before being downloaded can still be accommodated as downloadable dependencies in Maven. This is a great idea and I don't want to detract from it. I glanced at Glassfish CVS and noticed the following apis immediately: javax.activation v1.1 javax.connector v1.5 javax.enterprise.deploy javax.ejb v2.1 javax.security.jacc javax.jms v1.1 javax.management.j2ee javax.persistence v3.0 javax.transaction The Geronimo project is already publishing a few of these, but not all. I don't want to duplicate any efforts, so we'd want to limit it to the currently-unpublished APIs only -- specifically transaction and persistence come to mind but I'm sure some others would go in as well. Another api I'd like to add would be jdbc-stdext (javax.sql) but I can't find it in Glassfish at this point. It might be there and I just don't see it, in which case it would be added too. Since the code is coming from Glassfish, we'd probably want to put it in net.java.glassfish (?). Without Sun's explicit permission and perhaps even co-operation with the effort, I'd hesitate putting them in javax.*. But we could update the javax.* poms to reflect a dependency on the net.java.glassfish files. Assuming we all agree that we can do it legally, I'd be happy to build the jars, write the poms, and add to Jira for uploading. Comments? Thanks. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Can you provide the urls where the jars can be downloaded and the url of the license so we can take a look? If everything is ok and they are the official reference implementations they can go under javax.* On 2/25/06, Wayne Fay [EMAIL PROTECTED] wrote: I'm hoping we can update the Sun Licensing Journey and get some javax.* apis published in Maven repository without requiring special permission from Sun now that Project Glassfish is publishing many of them under the CDDL license which very clearly *allows* distribution. I know there is an effort to introduce click to agree to license functionality in Maven in the near future, so certain Jars that require agreeing to a license etc before being downloaded can still be accommodated as downloadable dependencies in Maven. This is a great idea and I don't want to detract from it. I glanced at Glassfish CVS and noticed the following apis immediately: javax.activation v1.1 javax.connector v1.5 javax.enterprise.deploy javax.ejb v2.1 javax.security.jacc javax.jms v1.1 javax.management.j2ee javax.persistence v3.0 javax.transaction The Geronimo project is already publishing a few of these, but not all. I don't want to duplicate any efforts, so we'd want to limit it to the currently-unpublished APIs only -- specifically transaction and persistence come to mind but I'm sure some others would go in as well. Another api I'd like to add would be jdbc-stdext (javax.sql) but I can't find it in Glassfish at this point. It might be there and I just don't see it, in which case it would be added too. Since the code is coming from Glassfish, we'd probably want to put it in net.java.glassfish (?). Without Sun's explicit permission and perhaps even co-operation with the effort, I'd hesitate putting them in javax.*. But we could update the javax.* poms to reflect a dependency on the net.java.glassfish files. Assuming we all agree that we can do it legally, I'd be happy to build the jars, write the poms, and add to Jira for uploading. Comments? Thanks. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - checkout] Sun Feb 26 00:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060226.01.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060226.01.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - checkout] Sun Feb 26 00:30:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060226.003000.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060226.003000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ibiblio] Upload request for apacheds 1.0-RC1 release
Hiya, The directory team just released 1.0-RC1 it's up here and signed: http://www.apache.org/dist/maven-repository/org/apache/directory/ Could it be uploaded to the repo at ibiblio.org? Thanks, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ibiblio] Upload request for apacheds 1.0-RC1 release
Done. Alex Karasulu wrote: Hiya, The directory team just released 1.0-RC1 it's up here and signed: http://www.apache.org/dist/maven-repository/org/apache/directory/ Could it be uploaded to the repo at ibiblio.org? Thanks, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Publishing Glassfish jars (javax.* apis) in Maven repos
Here's the Glassfish project website: https://glassfish.dev.java.net/ More specifically, you can download the most recent Milestone5-b32g build here: https://glassfish.dev.java.net/downloads/12Feb06.html Its about 60mb packaged as Jar. That download page contains the following text, with links to licenses: Several different software components including source and binary, support the GlassFish project. The source components are released under the Common Development and Distribution License (CDDL) v1.0 whereas the binary components are covered under the binary license. You must agree to these licenses as part of installation before viewing and/or using the code. If you read the CDDL, it says: https://glassfish.dev.java.net/public/CDDLv1.0.html 3.5. Distribution of Executable Versions. You may distribute the Executable form of the Covered Software under the terms of this License or under the terms of a license of Your choice, which may contain terms different from this License, provided that You are in compliance with the terms of this License and that the license for the Executable form does not attempt to limit or alter the recipients rights in the Source Code form from the rights set forth in this License. If You distribute the Covered Software in Executable form under a different license, You must make it absolutely clear that any terms which differ from this License are offered by You alone, not by the Initial Developer or Contributor. Then if you read their binary license, it says: https://glassfish.dev.java.net./public/BinariesLicense.html 1. Definitions. Software means all the portions of the GlassFish distribution provided by Sun only in binary code form, and including any updates or error corrections or documentation provided by Sun under this Agreement. 2. Permitted Uses. Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the Software's documentation, Sun grants you a non-exclusive, non-transferable, limited license without fees to (a) reproduce and use internally the Software for the purposes of developing or running GlassFish or modified versions of GlassFish. (b) reproduce and distribute the Software (and also portions of Software identified as Redistributable in the documentation accompanying Software), provided that you (i) distribute the Software or Redistributables bundled as part of, and for the sole purpose of running, GlassFish or modified versions of GlassFish; Due to the differences in these licenses, and the fact that we certainly DO NOT intend to distribute their software for the sole purpose of running Glassfish, I don't believe we can simply download the milestone build, extract the Jars, bundle them with poms and distribute them via Maven. However, the CDDL source code license ensures we **can** download the proper source, build/unit test, package, bundle with poms, and deploy **those** executables from the repo. This is an important difference. That's why I originally said: Assuming we all agree that we can do it legally, I'd be happy to build the jars, write the poms, and add to Jira for uploading. Any more comments? :-) Wayne On 2/25/06, Carlos Sanchez [EMAIL PROTECTED] wrote: Can you provide the urls where the jars can be downloaded and the url of the license so we can take a look? If everything is ok and they are the official reference implementations they can go under javax.* On 2/25/06, Wayne Fay [EMAIL PROTECTED] wrote: I'm hoping we can update the Sun Licensing Journey and get some javax.* apis published in Maven repository without requiring special permission from Sun now that Project Glassfish is publishing many of them under the CDDL license which very clearly *allows* distribution. I know there is an effort to introduce click to agree to license functionality in Maven in the near future, so certain Jars that require agreeing to a license etc before being downloaded can still be accommodated as downloadable dependencies in Maven. This is a great idea and I don't want to detract from it. I glanced at Glassfish CVS and noticed the following apis immediately: javax.activation v1.1 javax.connector v1.5 javax.enterprise.deploy javax.ejb v2.1 javax.security.jacc javax.jms v1.1 javax.management.j2ee javax.persistence v3.0 javax.transaction The Geronimo project is already publishing a few of these, but not all. I don't want to duplicate any efforts, so we'd want to limit it to the currently-unpublished APIs only -- specifically transaction and persistence come to mind but I'm sure some others would go in as well. Another api I'd like to add would be jdbc-stdext (javax.sql) but I can't find it in Glassfish at this point. It might be there and I just don't see it, in which case it would be added too. Since the code is coming from Glassfish, we'd probably want to put it in net.java.glassfish (?). Without Sun's explicit permission and
[jira] Commented: (MSUREFIRE-23) Support TestNG
[ http://jira.codehaus.org/browse/MSUREFIRE-23?page=comments#action_59499 ] Brett Porter commented on MSUREFIRE-23: --- I have applied this locally, and am committing to a branch Support TestNG -- Key: MSUREFIRE-23 URL: http://jira.codehaus.org/browse/MSUREFIRE-23 Project: Maven 2.x Surefire Plugin Type: New Feature Reporter: Mike Perham Assignee: Brett Porter Fix For: 2.2 Attachments: maven-patches.tgz, maven-surefire-plugin-patch.txt, maven-surefire-report-maven-plugin-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-patch.txt, surefire-report-maven-plugin-patch.txt, testng-4.4.5-jdk14.jar, testng-4.4.5-jdk15.jar Add support for running unit tests with TestNG. http://www.testng.org -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
surefire refactoring
Hi, I have created branches for the test ng support, because it's not really production ready as at the patch Jesse K provided. We've been working through it. I will likely complete it tomorrow, and it will include some refactoring to turn surefire into a provider infrastructure. I'll coordinate with Jason as I think he is expecting to do the same thing. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build trunk - SUCCESS - update] Sun Feb 26 07:00:00 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/trunk/m2-20060226.070001.tar.gz Log: http://maven.zones.apache.org/~maven/logs/trunk/m2-build-log-20060226.070001.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build branches/maven-2.0.x - SUCCESS - update] Sun Feb 26 07:15:01 GMT 2006
Distribution: http://maven.zones.apache.org/~maven/builds/branches/maven-2.0.x/m2-20060226.071503.tar.gz Log: http://maven.zones.apache.org/~maven/logs/branches/maven-2.0.x/m2-build-log-20060226.071503.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
