Re: Deploy snapshot to apache snapshot repo
Hi Brian, Great, i am looking forward to see the snapshots deployed soon. Should I ping you after few days I dont see them? Big Thanks -Dan On Fri, Jan 15, 2010 at 8:17 AM, Brian Fox wrote: > If it's in the grid, it would be deployed to repository.sonatype.org > and I have rao proxying that maven-snapshot folder. I figured it's > more bandwidth efficient to proxy requested items than to push every > single snapshot from the grid across. > > On Fri, Jan 15, 2010 at 12:10 AM, Brett Porter wrote: >> >> On 15/01/2010, at 3:38 PM, Dan Tran wrote: >> >>> they are not there :-) the interested artifacts are quite old. >>> >>> So I guess they are not automatically deployed. >> >> Ah, I saw the "Jan 15" on >> https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-dependency-plugin/, >> but I guess it gets touched regularly. >> >> You might need to configure them in the grid. >> >> - Brett >> >> -- >> Brett Porter >> br...@apache.org >> http://brettporter.wordpress.com/ >> >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven Clean Plugin 2.4 Released
The Maven team is pleased to announce the release of the Maven Clean Plugin, version 2.4. This plugin is used to clean the project output directories. Please see the plugin's site for more details: http://maven.apache.org/plugins/maven-clean-plugin/ To use the updated plugin in your projects, you need to add the following snippet to the plugins or plugin management section of your POM: org.apache.maven.plugins maven-clean-plugin 2.4 Release Notes - Maven 2.x Clean Plugin - Version 2.4 ** Bug * [MCLEAN-32] - Out of Memory Error cleaning target directory with *large* number of sub-directories * [MCLEAN-39] - followSymLinks is always set to true Enjoy, -The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANNOUNCE] Doxygen Maven Plugin - Release 1.0
Hello to all, I'm pleased to announce the availability of the Doxygen Maven Plugin Release 1.0 The Homepage (intermediate?) for the Plugin is: http://www.supose.org/projects/show/mavendoxygen The ChangeLog for this Release (first one), can be seen at: http://www.supose.org/versions/show/27 Unfortunately, i have to admit that the plugin is currently not in one of the Maven Repositories available... Currently you can download the POM and the JAR file here: http://www.supose.org/projects/list_files/mavendoxygen I hope it will be available via a Maven repository in a few days... If you have any questions concerning the Plugin don't hesitate to contact me Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Parallel execution of tests for Junit
If you are running java5 or higher, there's a good chance you can just drop in surefire2.5 and junit-4.8.1, without making any code changes at all. Although I haven't tested this specifically, I think it should work. You can read about how to do it here - I'll try to get parts of it into some official documentation once I get the karma and find out where ;) In the meantime there's only the javadoc in the plugin. http://incodewetrustinc.blogspot.com/2010/01/run-your-junit-tests-concurrently-with.html Kristian On Fri, 2010-01-15 at 16:39 +, Colm O'Donnell wrote: > Thanks for your prompt response. > > We are using junit 3.8 unfortunately. We will look at upgrading > version but this patch will work with no upgrades to junit. > > On 1/15/10, Stephen Connolly wrote: > > Eh Surefire 2.5 (which is in the process of being released) > > supports the parallel execution features of JUnit 4.7+ > > > > If that works for you, no patch required > > > > -Stephen > > > > 2010/1/15 Colm O'Donnell : > >> Hi, > >> > >> I work for a company that have a large number of junit tests. We have > >> migrated from ant to maven recently but are faced with a serious problem > >> with respect to the time to execute the tests. We used to execute some > >> tests > >> in parallel with ant but it was not great and depended on a lot of manual > >> effort. Currently we have to disable surefire and revert to calling ant to > >> execute the tests. > >> > >> We have attempted to patch surefire to allow for parallel execution of > >> Junit > >> tests. And we are wondering if we could submit a patch for this. It > >> required > >> some small refactorings of the surefire booter classes to create a > >> different > >> implementation of an interface for each type of booting available . e.g. > >> move the content of the method runSuitesInProcess into a class in its own > >> right. > >> > >> It reuses the existing booter functionality to spawn processes and adds > >> another for threaded execution. > >> So there exists a new class available to booter can scan the test dir and > >> find out the number of tests and then divide them up into a configurable > >> chunk size and hands chunks of tests to the implementation for the > >> selected > >> concurrency mode. > >> > >> Would this approach to sure fire be acceptable? > >> And where do I submit our patch? > >> > >> > >> Cheers > >> > >> Colm > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Wants to upload our repository to central
> The problem we have allowing unchecked rsyncs is that in the past we find > that the control over what is actually put in the repositories is not well > managed in some cases. Using http://oss.sonatype.org helps us maintain a very > high level of quality. It basically amounts to changing where you deploy to, > not changing your forge. We also look at your repository and help cleanup any > snapshot/release repository problems, and make sure there is no overlap with > artifacts outside your groupId. Deploying to http://oss.sonatype.org also > validates you have PGP signatures, javadocs and source JARs which is very > important. We are not only trying to help make it easier for you the suppler > of artifacts, but we are trying to protect our thousands of consumers from > inadvertent yet frequent mistakes that can be made. We're trying to make this > process scale which is why we are discouraging rsyncs. > Ok, Sorry I misunderstand you. I was about to propose to set a such tool in our company. Just for information : - The groupId I (we) want to be synch are self-containing - we always deploy (release-profile) sources + javadoc. - we use two repositories (one for snapshot + one for release) I will install the community version of Nexus (if it still exists ?) or another such tools. Then what is the next step to come on central ? Post here another mail ? Thanks for your explanation and hope to be soon on central :) > > Please,... says yes :) > > > >> --Brian > >> > >> On Fri, Jan 15, 2010 at 9:10 AM, Tony Chemit wrote: > >>> Hi guys, > >>> > >>> We'd like [1] to synch our repository [2] with central. > >>> > >>> Actually our repository is on a vserver with ss access), We aims to add a > >>> knockd to secure it, and it would be much appreciate if we could know the > >>> ip of your machine which will do the rsynch (to add a special in firewall > >>> just for this ip). > >>> > >>> Can you deliver us the ip ? Otherwise we will put our repository in > >>> another vserver. > >>> > >>> Thanks, > >>> > >>> > >>> [1] http://codelutin.com > >>> > >>> -- > >>> > >>> Tony Chemit > >>> > >>> tél: +33 (0) 2 40 50 29 28 > >>> email: che...@codelutin.com > >>> http://www.codelutin.com > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >>> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > > > > > -- > > > > Tony Chemit > > > > tél: +33 (0) 2 40 50 29 28 > > email: che...@codelutin.com > > http://www.codelutin.com > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > -- > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Parallel execution of tests for Junit
Thanks for your prompt response. We are using junit 3.8 unfortunately. We will look at upgrading version but this patch will work with no upgrades to junit. On 1/15/10, Stephen Connolly wrote: > Eh Surefire 2.5 (which is in the process of being released) > supports the parallel execution features of JUnit 4.7+ > > If that works for you, no patch required > > -Stephen > > 2010/1/15 Colm O'Donnell : >> Hi, >> >> I work for a company that have a large number of junit tests. We have >> migrated from ant to maven recently but are faced with a serious problem >> with respect to the time to execute the tests. We used to execute some >> tests >> in parallel with ant but it was not great and depended on a lot of manual >> effort. Currently we have to disable surefire and revert to calling ant to >> execute the tests. >> >> We have attempted to patch surefire to allow for parallel execution of >> Junit >> tests. And we are wondering if we could submit a patch for this. It >> required >> some small refactorings of the surefire booter classes to create a >> different >> implementation of an interface for each type of booting available . e.g. >> move the content of the method runSuitesInProcess into a class in its own >> right. >> >> It reuses the existing booter functionality to spawn processes and adds >> another for threaded execution. >> So there exists a new class available to booter can scan the test dir and >> find out the number of tests and then divide them up into a configurable >> chunk size and hands chunks of tests to the implementation for the >> selected >> concurrency mode. >> >> Would this approach to sure fire be acceptable? >> And where do I submit our patch? >> >> >> Cheers >> >> Colm >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my mobile device - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Releasing maven-eclipse-plugin
I'm not in any dire rush to release the plugin, so I'll defer to you. If I can release it I will, otherwise I'll wait. On 2010-01-15, at 11:30 AM, Arnaud HERITIER wrote: >> >> >> Arnaud is the one with all the outstanding issues - he should comment >> if they can get bumped to the next version. >> All those unassigned look suitable for bumping. >> > > > I'm not working on it and I won't be able soon > I unassign all my issues. You can postpone issues you don't want to fix. > You can try to deploy a SNAPSHOT and ask feedback from users before > releasing it because our ITs doesn't validate many things (just that we > always generate the same files, but it doesn't validate that you can use > them in new/current eclipse versions). > This plugin is widely used and the major part of users didn't upgrade to > last releases because w have regressions in them. Thus if you want to have a > wide usage of this new version you should take care to regressions found in > 2 previous releases. > > cheers > > Arnaud Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Parallel execution of tests for Junit
Eh Surefire 2.5 (which is in the process of being released) supports the parallel execution features of JUnit 4.7+ If that works for you, no patch required -Stephen 2010/1/15 Colm O'Donnell : > Hi, > > I work for a company that have a large number of junit tests. We have > migrated from ant to maven recently but are faced with a serious problem > with respect to the time to execute the tests. We used to execute some tests > in parallel with ant but it was not great and depended on a lot of manual > effort. Currently we have to disable surefire and revert to calling ant to > execute the tests. > > We have attempted to patch surefire to allow for parallel execution of Junit > tests. And we are wondering if we could submit a patch for this. It required > some small refactorings of the surefire booter classes to create a different > implementation of an interface for each type of booting available . e.g. > move the content of the method runSuitesInProcess into a class in its own > right. > > It reuses the existing booter functionality to spawn processes and adds > another for threaded execution. > So there exists a new class available to booter can scan the test dir and > find out the number of tests and then divide them up into a configurable > chunk size and hands chunks of tests to the implementation for the selected > concurrency mode. > > Would this approach to sure fire be acceptable? > And where do I submit our patch? > > > Cheers > > Colm > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Releasing maven-eclipse-plugin
> > > Arnaud is the one with all the outstanding issues - he should comment > if they can get bumped to the next version. > All those unassigned look suitable for bumping. > I'm not working on it and I won't be able soon I unassign all my issues. You can postpone issues you don't want to fix. You can try to deploy a SNAPSHOT and ask feedback from users before releasing it because our ITs doesn't validate many things (just that we always generate the same files, but it doesn't validate that you can use them in new/current eclipse versions). This plugin is widely used and the major part of users didn't upgrade to last releases because w have regressions in them. Thus if you want to have a wide usage of this new version you should take care to regressions found in 2 previous releases. cheers Arnaud
Re: Wants to upload our repository to central
On 2010-01-15, at 11:15 AM, Tony Chemit wrote: > Le Fri, 15 Jan 2010 10:41:51 -0500, > Brian Fox a écrit : > >> Hi Tony, >> >> We are actually in the process of updating the documentation, but >> we've decided not to accept new Rsync requests except for forges. For >> individual projects, it's simply too much overhead to handle rsyncs >> and it isn't scalable, not to mention there isn't a good way to >> enforce quality. Instead you could use one of the available forges >> that rsync to central like Codehaus, Oss.sonatype.org, etc. >> > We are an organization and use redmine as forge. We definitivly not do > projects for fun :). > > No way for us (at the moment) to change our forge, so can we still be on > central ? > > I passed a long time to normalize our artifacts with objectives to be on > central (for our clients and others developpers using our code), I would be a > bit fustrated not to be on central... just because of a forge... > You don't have to change forges. That's not what we're asking. The problem we have allowing unchecked rsyncs is that in the past we find that the control over what is actually put in the repositories is not well managed in some cases. Using http://oss.sonatype.org helps us maintain a very high level of quality. It basically amounts to changing where you deploy to, not changing your forge. We also look at your repository and help cleanup any snapshot/release repository problems, and make sure there is no overlap with artifacts outside your groupId. Deploying to http://oss.sonatype.org also validates you have PGP signatures, javadocs and source JARs which is very important. We are not only trying to help make it easier for you the suppler of artifacts, but we are trying to protect our thousands of consumers from inadvertent yet frequent mistakes that can be made. We're trying to make this process scale which is why we are discouraging rsyncs. > Please,... says yes :) > >> --Brian >> >> On Fri, Jan 15, 2010 at 9:10 AM, Tony Chemit wrote: >>> Hi guys, >>> >>> We'd like [1] to synch our repository [2] with central. >>> >>> Actually our repository is on a vserver with ss access), We aims to add a >>> knockd to secure it, and it would be much appreciate if we could know the >>> ip of your machine which will do the rsynch (to add a special in firewall >>> just for this ip). >>> >>> Can you deliver us the ip ? Otherwise we will put our repository in another >>> vserver. >>> >>> Thanks, >>> >>> >>> [1] http://codelutin.com >>> >>> -- >>> >>> Tony Chemit >>> >>> tél: +33 (0) 2 40 50 29 28 >>> email: che...@codelutin.com >>> http://www.codelutin.com >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > > > -- > > Tony Chemit > > tél: +33 (0) 2 40 50 29 28 > email: che...@codelutin.com > http://www.codelutin.com > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Parallel execution of tests for Junit
Hi, I work for a company that have a large number of junit tests. We have migrated from ant to maven recently but are faced with a serious problem with respect to the time to execute the tests. We used to execute some tests in parallel with ant but it was not great and depended on a lot of manual effort. Currently we have to disable surefire and revert to calling ant to execute the tests. We have attempted to patch surefire to allow for parallel execution of Junit tests. And we are wondering if we could submit a patch for this. It required some small refactorings of the surefire booter classes to create a different implementation of an interface for each type of booting available . e.g. move the content of the method runSuitesInProcess into a class in its own right. It reuses the existing booter functionality to spawn processes and adds another for threaded execution. So there exists a new class available to booter can scan the test dir and find out the number of tests and then divide them up into a configurable chunk size and hands chunks of tests to the implementation for the selected concurrency mode. Would this approach to sure fire be acceptable? And where do I submit our patch? Cheers Colm
Re: Deploy snapshot to apache snapshot repo
If it's in the grid, it would be deployed to repository.sonatype.org and I have rao proxying that maven-snapshot folder. I figured it's more bandwidth efficient to proxy requested items than to push every single snapshot from the grid across. On Fri, Jan 15, 2010 at 12:10 AM, Brett Porter wrote: > > On 15/01/2010, at 3:38 PM, Dan Tran wrote: > >> they are not there :-) the interested artifacts are quite old. >> >> So I guess they are not automatically deployed. > > Ah, I saw the "Jan 15" on > https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-dependency-plugin/, > but I guess it gets touched regularly. > > You might need to configure them in the grid. > > - Brett > > -- > Brett Porter > br...@apache.org > http://brettporter.wordpress.com/ > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Wants to upload our repository to central
Le Fri, 15 Jan 2010 10:41:51 -0500, Brian Fox a écrit : > Hi Tony, > > We are actually in the process of updating the documentation, but > we've decided not to accept new Rsync requests except for forges. For > individual projects, it's simply too much overhead to handle rsyncs > and it isn't scalable, not to mention there isn't a good way to > enforce quality. Instead you could use one of the available forges > that rsync to central like Codehaus, Oss.sonatype.org, etc. > We are an organization and use redmine as forge. We definitivly not do projects for fun :). No way for us (at the moment) to change our forge, so can we still be on central ? I passed a long time to normalize our artifacts with objectives to be on central (for our clients and others developpers using our code), I would be a bit fustrated not to be on central... just because of a forge... Please,... says yes :) > --Brian > > On Fri, Jan 15, 2010 at 9:10 AM, Tony Chemit wrote: > > Hi guys, > > > > We'd like [1] to synch our repository [2] with central. > > > > Actually our repository is on a vserver with ss access), We aims to add a > > knockd to secure it, and it would be much appreciate if we could know the > > ip of your machine which will do the rsynch (to add a special in firewall > > just for this ip). > > > > Can you deliver us the ip ? Otherwise we will put our repository in another > > vserver. > > > > Thanks, > > > > > > [1] http://codelutin.com > > > > -- > > > > Tony Chemit > > > > tél: +33 (0) 2 40 50 29 28 > > email: che...@codelutin.com > > http://www.codelutin.com > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Wants to upload our repository to central
Hi Tony, We are actually in the process of updating the documentation, but we've decided not to accept new Rsync requests except for forges. For individual projects, it's simply too much overhead to handle rsyncs and it isn't scalable, not to mention there isn't a good way to enforce quality. Instead you could use one of the available forges that rsync to central like Codehaus, Oss.sonatype.org, etc. --Brian On Fri, Jan 15, 2010 at 9:10 AM, Tony Chemit wrote: > Hi guys, > > We'd like [1] to synch our repository [2] with central. > > Actually our repository is on a vserver with ss access), We aims to add a > knockd to secure it, and it would be much appreciate if we could know the ip > of your machine which will do the rsynch (to add a special in firewall just > for this ip). > > Can you deliver us the ip ? Otherwise we will put our repository in another > vserver. > > Thanks, > > > [1] http://codelutin.com > > -- > > Tony Chemit > > tél: +33 (0) 2 40 50 29 28 > email: che...@codelutin.com > http://www.codelutin.com > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Wants to upload our repository to central
Hi guys, We'd like [1] to synch our repository [2] with central. Actually our repository is on a vserver with ss access), We aims to add a knockd to secure it, and it would be much appreciate if we could know the ip of your machine which will do the rsynch (to add a special in firewall just for this ip). Can you deliver us the ip ? Otherwise we will put our repository in another vserver. Thanks, [1] http://codelutin.com -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Maven Clean Plugin 2.4
Hi, The vote has passed with the following result: +1 (binding): Benjamin Bentmann, Olivier Lamy, Vincent Siveton, Hervé Boutemy +1 (non-binding): Nicolas de Loof, Kristian Rosenvold I will promote the artifacts to the central repository and continue with the release. Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Documentation about inheritance of POM elements..
Hi, I have, based on a question in a forum, reread the documentation about inheritance in the pom's... the following information is documented: -- The packaging type required to be pom for parent and aggregation (multi-module) projects. These types define the goals bound to a set of lifecycle stages. For example, if packaging is jar, then the package phase will execute the jar:jar goal. If the packaging is pom, the goal executed will be site:attach-descriptor. Now we may add values to the parent POM, which will be inherited by its children. The elements in the parent POM that are inherited by its children are: dependencies developers and contributors plugin lists reports lists plugin executions with matching ids plugin configuration - But i have checked the information via mvn help:effective-pom and found out the e.g. distributionManagement is inherited as well Or did i oversight or misunderstand a thing ? Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[ANN] Maven Scm 1.3 Released
Hi, The Maven team is pleased to announce the release of the Maven Scm, version 1.3. Release Notes - Maven SCM - Version 1.3 ** Bug * [SCM-261] - Synergy provider assumes instance of 1 for projects... won't work for distributed CM (and some other scenarios) * [SCM-418] - Support for Perforce changelogs in Continuum and changelog plugin * [SCM-439] - Maven SCM Mercurial provider remove functionnality doesn't work * [SCM-453] - changelog command doesn't support branches yet * [SCM-454] - GitChangelogCommand doesn't support tag ranges yet * [SCM-455] - scm:changelog command does not pick up svn changes when author has spaces * [SCM-458] - GitChangeLogCommand always reports over the whole git repo - also for child modules * [SCM-460] - tag command ignores custom message parameter * [SCM-464] - gitexe GitAddCommand should use '--' to separate the files from the options and version info * [SCM-466] - Release prepare causing exit Code 141 in linux with clearcase * [SCM-471] - some TCK tests check for files in a position dependent way * [SCM-480] - "mvn scm:status" doesn't show modified file * [SCM-488] - Git provider fails to support 'release:perform' if not releasing from remote HEAD * [SCM-489] - the bazaar provider needs to support the following protocols: bzr, bzr+ssh, ssh * [SCM-490] - bazaar scm:add doesn't return the correct list of added files * [SCM-491] - release:perform with Mercurial performs a full hg clone from the remote repository * [SCM-492] - [Patch] Support for tagging * [SCM-493] - bazaar scm:checkin fails to push if there are other local modifications * [SCM-498] - git providers should use the fetch and push URLs instead of 'origin' * [SCM-502] - checking out a tag from a remote repository fails if the tag was not on the current branch * [SCM-505] - Linux Synergy client fails to execute scm:update command * [SCM-509] - Tagging fails to use provided message while checking in works fine * [SCM-516] - git provider doesn't respect username in settings.xml ** Improvement * [SCM-344] - VSS provider - implement checkin * [SCM-345] - VSS provider - implement tag * [SCM-459] - Add tag() and status() methods to local scm provider to enable use with release:prepare goal * [SCM-461] - Support TFS as SCM Provider * [SCM-463] - Allow builds with Modello 1.0 * [SCM-467] - Make core SCM API objects Serializable * [SCM-474] - Make class ChangeSet thread-safe * [SCM-512] - add field revision in ChangeSet bean * [SCM-515] - branch command must support remote branching (svnexe) * [SCM-522] - Provide Util.setSettingsDirectory for git and cvs Have Fun ! -- The Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to get dependency artifacts for another artifact ?
Hm I have one problem. depProject.getDependencyArtifacts() is null How to resolve this project dependency ?? Best regards -- View this message in context: http://old.nabble.com/How-to-get-dependency-artifacts-for-another-artifact---tp27167882p27173357.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Maven SCM 1.3 (Take 2)
Hi, The vote has passed with the following result : +1 (binding) : Benjamin Bentmann, Hervé BOUTEMY, Olivier Lamy +1 (non-binding) : Subir Sasikumar, Mark Struberg. I will finish the release process. -- Olivier - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
