Re: Register new scm provider
It should not be in the lib directory. You should add it under the build extensions. - Brett On 24/10/2009, at 4:56 AM, Lee Freyberg wrote: Hi, How do you go about registering a new provider? I have created a stub impl following the instructions on the scm site, and placed the its jar in the maven/lib dir (adding it as a dependecy in the pom did not work), but I get an error when I try and run any of the scm commands. I am fairly sure mvn is picking up the provider, as if I remove the jar from the lib dir I get a 'no provider for scm 'xxx'' message. With the jar present I get a different error: [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-scm-plugin:1.2:bootstrap': Unable to load the mojo 'org.apache.maven.plugins:maven-scm-plugin:1.2:bootstrap' in the plugin 'org.apache.maven.plugins:maven-scm-plugin'. A required class is missing: org/apache/maven/scm/provider/AbstractScmProvider org.apache.maven.scm.provider.AbstractScmProvider Am I missing a dependency somewhere? Or is this not the correct way to register a provider? Any pointers appreciated. Cheers, Lee
Re: accurev provider
Do the authors of the original provider, or other users here, have an opinion on this? I like that it is more complete (functionally, and in docs and tests), however am not an accurev user myself. What effect does the URL syntax change have? Also Grant, I haven't seen the CLA yet? - Brett On 17/03/2009, at 11:58 PM, Grant Gardner wrote: I've created the jira with attached code. Let me know if there's anything else I need to do. http://jira.codehaus.org/browse/SCM-445 Will do the CLA when I find myself conveniently located near a fax or scanner. On Mon, 9 Mar 2009 05:02:15 +1100, Brett Porter wrote: 1) Create a JIRA ticket under SCM 2) you might like to submit a CLA - you can do it regardless, and if the work is accepted such a large chunk would probably require it (see http://www.apache.org/licenses/ and specifically http://www.apache.org/licenses/icla.txt) Thanks! - Brett On 07/03/2009, at 12:50 PM, Grant Gardner wrote: Hi, I've got my AccuRev provider to a point where both the release plugin and Continuum are working (for me). Includes unit tests and tck tests for all the implemented commands. How do I go about contributing the code?. Grant. -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/
Re: AW: NPE with maven-changelog-plugin and git
What version of Maven? I think prior to Maven 2.0.7 it was hardcoded
to p-u 1.1.
- Brett
On 30/03/2009, at 10:23 PM, Mark Struberg wrote:
Hi Imran!
Having only looked over your log quickly, it seems to me that this
is not a git-scm problem:
java.lang.NoSuchMethodError:
org.codehaus.plexus.util.cli.Commandline.createArg()Lorg/codehaus/
plexus/util/cli/Arg;
org
.apache
.maven
.scm
.provider
.git
.gitexe
.command
.GitCommandLineUtils.getBaseGitCommandLine(GitCommandLineUtils.java:
82)
Looks like this function is not in the plexus-utils-1.1 the
changelog uses in your setup?
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.5.6:compile
(removed - nearer found: 1.1)
hmm, why does it take the 1.1 instead of the 1.5.6? Idea, anyone?
LieGrue,
strub
--- Imran M Yousuf schrieb am Mo, 30.3.2009:
Von: Imran M Yousuf
Betreff: NPE with maven-changelog-plugin and git
An: scm-dev@maven.apache.org
Datum: Montag, 30. März 2009, 4:55
Hi,
I am getting NPE when I issue the following
configuration and
command 'mvn changelog:changelog' in scm version 1.1. When
I use scm
verison 1.2 I get No Such Method Error. I am pretty sure I
am doing
something wrong but I am unable to determine it. Please
help! I have
attached the relevant outputs as attachment -
git-log.out - Output of the git log command issued to build
the log
maven-changelog-npe.out - Output including debug info for
the NPE
maven-scm-error-1.2.out - No such method error with 1.2.
I am compressing them to reduce the size of the attachment.
I would be
deeply grateful if you would be kind enough to point me in
right
direction.
scm:git:git://repo.or.cz/smart-dao.git
scm:git:ssh://imyou...@repo.or.cz/srv/git/smart-dao.git
org.apache.maven.plugins
maven-scm-plugin
${scm.version}
org.apache.maven.plugins
maven-changelog-plugin
2.1
org.apache.maven.scm
maven-scm-provider-gitexe
${scm.version}
2.3
0.2-SNAPSHOT
0.4-SNAPSHOT
1.1
Thank you,
--
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: im...@smartitengineering.com
Blog: http://imyousuf-tech.blogs.smartitengineering.com/
Mobile: +880-1711402557
Re: svnjava provider and maven scm
On 21/03/2009, at 9:05 AM, Olivier Lamy wrote: So I have moved back the provider to sandbox and start a fork here [1] If someone want to have karma ping me. I suggest we just remove the provider from the sandbox then rather than have the ambiguity. - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/
Re: svnjava provider and maven scm
On 21/03/2009, at 6:38 AM, Jason van Zyl wrote: Brett, There is no way we accept the Sleepcat license, it's viral. It is also heavily recommend against using because it can force you to have to redistribute your source code. That from our IP lawyer who deals with every day. Please don't dispense legal advice. Everything in law is in interpretation but there are some accepted interpretation. It's also unlikely that those contracts are identical unless they are verbatim and originate from the same country. I'm not quite sure what you're saying exactly. We seem to have the same understanding of the license at least (that's exactly what I said in the issue), it is totally viral and forces you to redistribute your source code if you use it (it is based on distribution). My suggestion was how we could offer our source code, without the library, and give suitable warning on the impact of turning it on as an optional bit of Maven SCM for those that can use the license. Regardless, I closed the issue since Olivier moved it out. - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/
Re: svnjava provider and maven scm
On 20/03/2009, at 2:17 AM, Olivier Lamy wrote: So the Brett proposal looks fine too. I can mark the svnjava provider as optionnal and explain why on the scm site and explain how to use it. That was all my opinion, so we should get it confirmed before release. Note that under the current FAQ the Sleepycat license (which this is equivalent to), is not allowed for inclusion. I filed: https://issues.apache.org/jira/browse/LEGAL-45, and added a couple more points on the list about how we can avoid it getting used without being aware of the license - putting it in a separate build profile and making sure it is not in the aggregating POM. It can always go to mojo, but I think it'd be a shame to have to separate it, so it's worth asking. - Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/
Re: svnjava provider and maven scm
On 19/03/2009, at 7:29 PM, Jason van Zyl wrote: On 19-Mar-09, at 1:25 AM, Olivier Lamy wrote: Hi, Ok. It's was not really clear for me. There is precedent - we grandfathered in Checkstyle which is LGPL as it is just a dependency of a plugin, which we don't actually distribute. The general talk - though not confirmed - is that optional dependencies that the user must obtain themselves could be ok. There isn't a legal problem with the combination, but rather a policy one that you don't distribute something that is essentially useless without a dependency of a stronger license. We should ask, but I personally think this is ok, as long as: - it is not made the default provider - instructions on the site about how to use it spell out that it requires the dependency and that it is not under the AL - we don't bundle and distribute Technically we are not redistributing anything and we can ask the board for clarification because in the strictest sense we do not redistribute. But I think folks here would interpret a dependency in your POM as being equivalent. No need to ask the board, you can file a request here: https://issues.apache.org/jira/browse/LEGAL Cheers, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/
Re: accurev provider
1) Create a JIRA ticket under SCM 2) you might like to submit a CLA - you can do it regardless, and if the work is accepted such a large chunk would probably require it (see http://www.apache.org/licenses/ and specifically http://www.apache.org/licenses/icla.txt) Thanks! - Brett On 07/03/2009, at 12:50 PM, Grant Gardner wrote: Hi, I've got my AccuRev provider to a point where both the release plugin and Continuum are working (for me). Includes unit tests and tck tests for all the implemented commands. How do I go about contributing the code?. Grant. -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/
Re: create a branch from a tag
There was some recent discussion about adding server side capabilities, but it doesn't exist yet. Perhaps those working on it will respond shortly and we can push forward with it. - Brett 2008/10/14 Benoit Decherf <[EMAIL PROTECTED]> > Hi, > > I can't find a way to create a branch from a tag without checkout the tag. > Is it planned to add this feature (can't find a JIRA on it ?) > > Thanks, > Benoit > -- Brett Porter http://blogs.exist.com/bporter/
Re: Extending maven-scm with remote commands
Can't remember if I said it before, but I think this is a good idea. I think Olivier was asking you to create JIRA issues for the functionality so we make sure to track it for 1.2. I haven't reviewed the code yet, but one thought that occurred to me is whether it is best to have the API have explicit "remote" commands (rlist, etc), or is it a mode of operation passed to the existing commands (list, told to act remotely)? The first (which you've done) seems simpler to me. There was also talk of a 1.1.1 so we might need to branch for that too? Cheers, Brett On 28/08/2008, at 8:06 AM, Alexey Kakunin wrote: OK, It was already discussed some time ago in this list. So, currently, maven-scm is used in two major projects: maven itself and continuum. (Probably some other but I do not have such info). It is mostly designed to do the things, required by these project. We proposed to add commands to work with remote repositories (not with local copy) - 4 commands: 1. rlist - to get list of files in remote repository 2. rlog - get history of remote file/folder 3. rinfo - get information about remote file 4. rcat - get contents of remote file We already implemented such commands for svnjava & cvs provider, and currently starting to work on mercurial We are using these commands for source-browser implementation in emforge (currently http://www.emforge.org/browser used our extended version of maven-scm) For us - usage of maven-scm give the good infrastructure. Maven-scm can receive extra-functionality from our job and example of another tool, used maven-scm. Currently all our changes are stored in our repository: http://svn.emforge.org/svn/emforge/maven-scm/ So, it looks like a fork - but, I do not like forks, and, will be happy to include somehow & sometime our changes into core maven-scm, so, we will avoid synhronization problems, and other user will be able to use these commands. 2008/8/28 Olivier Lamy <[EMAIL PROTECTED]> Hi, Can you explain in a issue what will be this changes ? Thanks, -- Olivier 2008/8/27 Alexey Kakunin <[EMAIL PROTECTED]>: > +1 (even I have no voice for voiting) > We have couple of changes, related to allow maven-scm better work with > remote repositories (as example of using such extensions - source browser in > http://www.emforge.org) > > We are not able to incorporate our changes now - since project near to > release and it is not make sense to include big changes. Releasing of 1.1 > will allow us to start move our changes into 1.2 trunk > > > > 2008/8/27 Dan Fabulich <[EMAIL PROTECTED]> >> >> +1, new settings work for me! >> >> Olivier Lamy wrote: >> >>> Hi, >>> The last release of maven-scm is now 14 months old. >>> I'd like to release maven-scm 1.1 which include two new providers git >>> and accurev and fix some issues. >>> >>> We solved 41 issues : >>> >>> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13984&styleName=Html&projectId=10527&Create=Create >>> >>> Staging repo: http://people.apache.org/~olamy/staging-repo/ . >>> >>> Staging site: http://maven.apache.org/scm-1.1/ . >>> >>> One more issue has been fixed since take 2 ([SCM-402] - scm:checkin >>> doesn't work on OS X 10.5 Leopard) >>> >>> Vote open for 72 hours. >>> >>> [ ] +1 >>> [ ] +0 >>> [ ] -1 >>> >>> Here my +1. >>> >>> Thanks >>> -- >>> Olivier >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> > > > > -- > With best regards, > Alexey Kakunin > -- With best regards, Alexey Kakunin -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: convenience POM for "standard" providers?
Done (SCM-400). I excluded the "local" provider. I also update the SCM plugin POM to use it. - Brett On 15/08/2008, at 9:04 PM, Vincent Siveton wrote: +1 Vincent 2008/8/14 Brett Porter <[EMAIL PROTECTED]>: Hi, Dan brought this up on #maven IRC - he was looking for an easy way to import all the providers without listing them, and so is adding a dependency on the scm plugin. Would it make sense to have a POM in the build that lists the standard providers, which could be used for importing into other builds conveniently? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
convenience POM for "standard" providers?
Hi, Dan brought this up on #maven IRC - he was looking for an easy way to import all the providers without listing them, and so is adding a dependency on the scm plugin. Would it make sense to have a POM in the build that lists the standard providers, which could be used for importing into other builds conveniently? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: SCM website
Looks good to me! I think the links in the top right are out of date though. On 14/08/2008, at 6:43 AM, Vincent Siveton wrote: Hi Folks, Working with Olivier to improve the SCM website, we propose the following: http://people.apache.org/~vsiveton/maven-scm/people.apache.org/www/maven.apache.org/scm/ (some links could be broken) It used src/site in all projects and we need to remove the maven-scm-site project. WDYT? Cheers, Vincent -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: svn commit: r685168 - /maven/scm/trunk/maven-scm-site/pom.xml
Would scm/$VERSION be better, to reduce the number of directories in
the root / ?
Cheers,
Brett
On 13/08/2008, at 12:33 AM, [EMAIL PROTECTED] wrote:
Author: olamy
Date: Tue Aug 12 07:33:54 2008
New Revision: 685168
URL: http://svn.apache.org/viewvc?rev=685168&view=rev
Log:
updgrade to last parent and versionned site deployment
Modified:
maven/scm/trunk/maven-scm-site/pom.xml
Modified: maven/scm/trunk/maven-scm-site/pom.xml
URL:
http://svn.apache.org/viewvc/maven/scm/trunk/maven-scm-site/pom.xml?rev=685168&r1=685167&r2=685168&view=diff
=
=
=
=
=
=
=
=
==
--- maven/scm/trunk/maven-scm-site/pom.xml (original)
+++ maven/scm/trunk/maven-scm-site/pom.xml Tue Aug 12 07:33:54 2008
@@ -21,7 +21,7 @@
maven-scm
org.apache.maven.scm
-1.1-SNAPSHOT
+1.2-SNAPSHOT
4.0.0
maven-scm-site
@@ -32,7 +32,7 @@
apache.website
- scpexe://people.apache.org/www/maven.apache.org/scm
+ scpexe://people.apache.org/www/maven.apache.org/scm-$
{pom.version}
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
Re: Remove some files
Will they still be included in source distribution as well as the JARs? I don't think there's any harm in having the license in the source repository as well. On 13/08/2008, at 3:32 AM, Olivier Lamy wrote: ok to remove. -- Olivier 2008/8/12 Vincent Siveton <[EMAIL PROTECTED]>: Hi, I noticed that the trunk has some files like: LICENSE.TXT NOTICE.TXT checkstyle-license.txt Are they useful? If not, WDYT to remove them? Cheers, Vincent -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: when will maven-scm-1.1 be released?
Was http://jira.codehaus.org/browse/SCM-374 already applied? That seems like the last thing needed for the release. I think the only necessary patch is for http://maven.apache.org/scm/scms-overview.html if it isn't done already, but obviously any additional docs you want to submit to help describe how to use it would be particularly helpful. Thanks! Cheers, Brett On 29/07/2008, at 7:27 PM, Mark Struberg wrote: Hi folks! Since there has been a discussion about the maven-scm-1.1 due date in http://jira.codehaus.org/browse/SCM-182 , I'd like to ask if you guys (and girls if any) have something in mind with maven-scm-1.1? Is there a chance to get it released and packaged with maven-2.0.10? Aditional question: What docs do we still need for adding all the info about the maven-scm-providers-git to the proper pages (scm matrix, etc). Please provide a list, and I will provide patches. LieGrü, strub __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Should remote or "local" command be used to List, Changelog and etc. commands?
Good point - it seems we do need to have a better separation of workspace/checkout handling from repository handling in general? - Brett On 31/05/2008, at 1:01 AM, Sergey Zakusov wrote: Hello, There is one crucial issue: which kind of command should be used for commands like List, Changelog and etc. - remote or local? For example, CVS returns different results for Log (local) and Rlog (remote) commands. REM: Rlog result cannot be parsed by CvsChangeLogConsumer. AbstractCvsListCommand uses Rlist (remote) command, but the result cannot be parsed by CvsStatusConsumer (http://jira.codehaus.org/browse/SCM-380). AbstractCvsChangeLogCommand uses Log (local) command, but at the same time SvnExeScmProvider executes list command for remote items . -- Best regards, Sergey Zakusov -- Software Developer, EmDev, Saint-Petersburg, Remeslennaya 17-415, 197110, Russia Phone: +7 (812) 498-72-21 Mobile: +7 (921) 301-77-13 -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: About info command
Looks like we need a way to start introducing this into the SCM API. I have a need for the same command. - Brett On 22/05/2008, at 5:24 PM, Sergey Zakusov wrote: Hello, I've found that some providers have implementation for INFO command, for example SvnExeScmProvider and GitExeScmProvider (partially), but the problem is in that ScmProvider interface does not support info command, so how the implementation can be used now? -- Best regards, Sergey Zakusov -- Software Developer, EmDev, Saint-Petersburg, Remeslennaya 17-415, 197110, Russia Phone: +7 (812) 498-72-21 Mobile: +7 (921) 301-77-13 -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Are you going to support get_file command in the future?
These changes sound worthwhile to me - others have any thoughts? I'll respond more to the second related post. - Brett On 13/05/2008, at 2:19 AM, Sergey Zakusov wrote: Hello, We've extended svnjava lib (http://svn.emforge.org/svn/emforge/maven-scm-provider-svnjava/ ) to use it without Working Copy, but we are confronted with some difficulties: ScmManager does not provide any operation to get file (like cat command for svn); AbstractCommand.execute method are declared as final - it does not allow us to overwrite it (there is implemented hard coded condition to check ScmFileSet parameter, but in our case we don't need it) Also we propose to extend some other basic classes: ChangeSet - to provide revision/branch/tag information too; ScmFile - to provide file type, size and reference to ChangeSet; What do you think about these improvements? -- Best regards, Sergey Zakusov -- Software Developer, EmDev, St.-Petersburg, Remeslennaya 17-415, 197110, Russia Phone: +7 (812) 498-72-21 Mobile: +7 (921) 301-77-13 -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: Extending Maven SCM Interfaces
Hi Alexey, Thanks for the mail. I think your suggestions make sense and it'd be great to have help implementing them. Right now, we're focusing on pulling together a 1.1 release, but after that I'm sure we can evaluate some API changes as appropriate. I would suggest the best way is to proceed is to take one issue at a time (like the original mail), get feedback on a proposal, and then submit a patch. It will be much easier to review if they are tackled one at a time and the impact of the change can be looked at. Cheers, Brett On 14/05/2008, at 3:49 AM, Alexey Kakunin wrote: Hello dear maven-scm development team. Additionally to email from Sergey Zakusov, he sent 2 days ago. Our company developing open-source workflow based task-management system EmForge (http://www.emforge.org) One of important part of this project - is integration with version control (you can check current implementation at http://www.emforge.org/browser) Our target for next milestone (http://www.emforge.org/project/EmForge/milestone/EmForge0.24 ) was add support for CVS additionally to currently supported SVN. After small investigation, we decided to use maven-scm - since, seems it is really a great library provided common interface to many version control systems. With using maven-scm we hope to support browse for many other version controls, not only SVN and CVS (and for maven-scm we hope it will be good example of usage this library). Unfortunately, during deveopment we found, that current version of maven-scm is mostly designed to work on top of working directory and perform operations like update, commit and so on... In our case - we do not have any working directly. Plus, some functionality just missed and it is hard to implement version control browser with using maven-scm. As basic version we got svn-java provider. Unfortunately it is not a part of maven-scm - due to license problems with svnkit... anyway. And to implement fully functional repository browser we extended some basic maven-scm interfaces like: * ChangeFileEx (http://www.emforge.org/fileviewer/maven-scm-provider-svnjava/src/main/java/org/apache/maven/scm/ChangeFileEx.java ) * AbstractCatCommand (http://www.emforge.org/fileviewer/maven-scm-provider-svnjava/src/main/java/org/apache/maven/scm/provider/svn/svnjava/command/cat/AbstractCatCommand.java ) to be able get file contents for specified revision * ChangeSetEx (http://www.emforge.org/fileviewer/maven-scm-provider-svnjava/src/main/java/org/apache/maven/scm/ChangeSetEx.java ) to display additional information in changeset Plus, as Sergey wrote - many problems produced the fact, that all basic classes has validation for "working directory" - and it is not possible to implement logic, not used it (but many scm command do not required working directory to be specified) - so, we had to implement many tricks to avoid this validation. We will be happy if our changes will not be like a branch - but will be contributed into maven-scm core and from our side ready to invest time to support this functionality in some other providers. Major idea - this extensions should be like "extensions" - so, old providers should keep working - but some new provider may return, for example not basic ChangeSet - but extended ChangeSet, and programs, required it - will able to use them. So, is it possible somehow contribute our changes into maven core and that we should do from our side for it? -- With best regards, Alexey Kakunin -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: svn commit: r653572
On 09/05/2008, at 12:33 AM, Jason van Zyl wrote: On 8-May-08, at 7:29 AM, Ivan Luzyanin wrote: - What exactly wrong with headers? It is exactly the same as in APPENDIX on page http://www.apache.org/licenses/LICENSE-2.0.html We need to change the copyright to Apache. No, the copyright doesn't change - the header that is used now is just that it is licensed under a CLA: http://svn.apache.org/viewvc/maven/scm/trunk/maven-scm-api/src/main/java/org/apache/maven/scm/ScmTag.java?revision=524909&view=markup We can either remove the Accurev information, or include it once in an accompanying notice file. - I believe it is OK to set version to "1.1-SNAPSHOT" Generally we start out with 1.0-SNAPSHOT. Yep, but we can change it to 1.1-SNAPSHOT now since it's been included in the main distribution. Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
making a 1.1 release
I've been looking at what's needed for a 1.1 release. There's currently just 4 issues in JIRA, but there's also 49 unscheduled issues. Does anyone have any pet issues they think should be addressed before 1.1? Any known regressions? Are the two new providers viable to include at this stage for a final release? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: svn commit: r645182
Thanks Mark! On 06/05/2008, at 8:20 PM, Mark Struberg wrote: Hi Brett! I'm on the list frequently, and also can spare some time to get work done if needed. I'm currently working on a few code changes in the git provider (release:perform with branches does not always work, reported by Matthew Bucket - currently work in progress), plus the patch in SCM-374 still needs to be applied to the apache SVN. Signed CLA is otw. LieGrü, strub --- Brett Porter <[EMAIL PROTECTED]> schrieb: On 06/04/2008, at 7:58 AM, [EMAIL PROTECTED] wrote: Author: jvanzyl Date: Sat Apr 5 14:58:41 2008 New Revision: 645182 URL: http://svn.apache.org/viewvc?rev=645182&view=rev Log: SCM-182: Adding a GIT provider Submitted by: mark struberg and eugene kuleshov The other commit reminded me. Given the size of this contribution, I think it would be helpful for both these guys to submit CLAs - especially given Eugene contributes to the embedder too. Jason? Cheers, Brett Lesen Sie Ihre E-Mails jetzt einfach von unterwegs. www.yahoo.de/go -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: svn commit: r645182
On 06/04/2008, at 7:58 AM, [EMAIL PROTECTED] wrote: Author: jvanzyl Date: Sat Apr 5 14:58:41 2008 New Revision: 645182 URL: http://svn.apache.org/viewvc?rev=645182&view=rev Log: SCM-182: Adding a GIT provider Submitted by: mark struberg and eugene kuleshov The other commit reminded me. Given the size of this contribution, I think it would be helpful for both these guys to submit CLAs - especially given Eugene contributes to the embedder too. Jason? Cheers, Brett -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/
Re: When will SCM bug 323 be released?
Anyone think a 1.0.1 release with the current fixes might be in order? - Brett On 05/01/2008, at 4:42 AM, brewk9 wrote: I see this is fixed - just wondering how/when it would be available in a release? -- View this message in context: http://www.nabble.com/When-will-SCM-bug-323-be-released--tp14621616s177p14621616.html Sent from the Maven - SCM mailing list archive at Nabble.com.
Re: build failures on JDK 1.4
Never mind - you got it :) On 25/09/2007, at 7:51 AM, Brett Porter wrote: Thanks Dennis! SCM API is fine, there seem to be new problems in the providers though. I'll take a look. On 25/09/2007, at 6:42 AM, Dennis Lundberg wrote: Should be fixed now. We'll need to check the results in Continuum later. Brett Porter wrote: Hi, Is SCM meant to support JDK 1.4? I notice the API is causing build failures on maven.zones.apache.org. Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> Blog: http://www.devzuz.org/blogs/bporter/ -- Dennis Lundberg -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: build failures on JDK 1.4
Thanks Dennis! SCM API is fine, there seem to be new problems in the providers though. I'll take a look. On 25/09/2007, at 6:42 AM, Dennis Lundberg wrote: Should be fixed now. We'll need to check the results in Continuum later. Brett Porter wrote: Hi, Is SCM meant to support JDK 1.4? I notice the API is causing build failures on maven.zones.apache.org. Cheers, Brett -- Brett Porter - [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> Blog: http://www.devzuz.org/blogs/bporter/ -- Dennis Lundberg -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/
Re: We're near the release of 1.0 final
On 28/03/2007, at 2:37 AM, Emmanuel Venisse wrote: I added two development guide in the site, it would be cool if you can look at it. The docs look good - thanks for that. I have some questions about the SCM manager part: it's unclear about how getScmManager is used. It looks like something you'd get all the time, but you wouldn't want to start a new plexus container, or construct and add all the time. Maybe this needs to be altered a bit to be clearer? Also, can we add a basic SCM manager to the release? That looks pretty straight-forward and would take care of the JIRA issue about creating a POJO facade. For the commands: might be good to break these out into individual documents? I imagine there are probable more commands to list and document too. Finally, on the site structure: - I think more detail on the front page, as well as links to the guides is needed. - The guides index page is missing one of the links - need breadcrumbs so that when you go into the plugin site, you can get back - we should have the javadoc for the API on the site somewhere - should we move the SCM space to cwiki since it can be autoexported? Then we can put the provider matrix and the provider details pages together and link them in to the site as static pages - do we need small guides on each provider that outline the differences/quirks/specific configuration needed? Just lots of thoughts... not sure how many we need to do for 1.0 :) wdyt? - Brett
Re: We're near the release of 1.0 final
I think it's definitely time for another beta ASAP. For 1.0, I'd still like to review (if not include) the following JIRAs. High priority: - SCM-17: I think the test structure needs some review, and we need to ensure all unit tests run fast and without the software installed. The TCK should be used to execute as integration tests when the software is installed. I think this sets us in a good position for a more stable API and the ability to have quality providers (per the other discussion on the list) - SCM-156, 157, 158: TCK tests for various providers. Ties in to the above. - SCM-18: it seems some commands are not currently implemented in some providers? Note: I'm happy to cut down the number of providers for the 1.0 release (and version the others as beta or have a larger sandbox) if that's what it takes. That would be more around the model of separated releases though. Medium priority (because they might change the API it could be better to do before 1.0): - SCM-21: separate revision and tag handling - SCM-133: API clean up around repositories Low priority: - SCM-243: 'X' is treated as unknown in SVN. Seems like a simple fix, might be worth doing. I'll also review the docs. I think it's critical we have the testing in order before doing the 1.0 release - wdyt? - Brett On 28/03/2007, at 2:37 AM, Emmanuel Venisse wrote: Hi, Now, we have only one issue to fix and all issues assigned to 1.0 will be fixed :) I added two development guide in the site, it would be cool if you can look at it. Emmanuel
Re: Post 1.0 release process
On 28/03/2007, at 7:51 AM, Jason van Zyl wrote: On 27 Mar 07, at 12:30 PM 27 Mar 07, Emmanuel Venisse wrote: Hi, I describe there (http://docs.codehaus.org/display/SCM/Maven-SCM +Release+Process) the release process and scm structure I'd want to use after the release of 1.0. This is missing the tck module, and the plugin. Also, if we do this, the providers should have their own JIRA project. We should do something similar across the board whatever we decide to do, but you realize that refactoring would be a severe pain in the ass. I agree providers in any form should be amenable to patching and releasing but is this the best way to go? Yeah, I'm 50/50 on this really. I see the benefit, but I'd rather wait until we have a need to release a provider on a base API before splitting it off. In addition, the benefit of this is completely lost if the providers are tightly coupled to the API - so we might want a couple of releases to ensure that's not the case. It also adds some overhead in getting testing working. I don't think this should add any testing overhead if it is done right... Can we not release from one structure, are we just limited by some deficiencies in the release plugin? We can release from a single structure, just like the plugins do now. Whether that's the right thing to do is also debatable. I'd hold off on this until we get 1.0's out across the board and then hash it out in relation to everything that does the same thing - plugins, doxia, scm, wagon... even surefire providers. - Brett
Bazaar test failures
Hi, There appears to be a test failure in Continuum for Bazaar now that I have the client installed again. This is bzr-0.13, Python-2.5, Solaris 10 x86. http://maven.zones.apache.org/continuum/surefireReport.action? buildId=2367&projectId=202&projectGroupId=16#org.apache.maven.scm.provid er.bazaar.command.changelog.BazaarChangeLogCommandTckTest Anyone have any ideas? - Brett
Re: Synergy Provider
Hi, This is great to hear. For code of this size, I think it is wise to have a software grant on file before we accept it. Please submit the following paperwork to the ASF secretary: http://www.apache.org/licenses/software-grant.txt In addition to that, please attach the code to a JIRA item http:// jira.codehaus.org/browse/SCM Cheers, Brett Hi, My customer "La Poste" want to donate the Maven SCM Provider for Synergy CM. That provider has been realized by Julien Henry during October 2006 (see mailing list archives). Can you give me all the needed information to "publish" the provider sources/doc to the maven community ? Thanks.
wiki
FYI, I've removed anonymous commenting ability on the SCM wiki and removed all the comment SPAM on the SCM matrix. - Brett
Re: Setting svn properties or how to avoid problems with line endings
I disagree with having a general property set/get since that appears to
be SVN specific at the moment.
Regardless of setting NL's correctly, you still need to indicate whether
a file is binary or not. SVN takes a good guess (but doesn't set the
property), CVS doesn't even attempt to guess.
We can do this (SVN):
- add (text): svn add + svn propset svn:eol-style native
- add (binary): svn add (no propset)
- possibly convert text <-> binary by changing the property value
- possibly configure the provider to handle that differently
- possibly have the provider select these methods on add() based on a
set of file extensions, removing the configuration from autoprops
We can do this (CVS):
- add (text): cvs add
- add (binary): cvs add -kb
- possibly convert text <-> binary by cvs admin -kb, -kkv, etc
- other things as above
Aside from these, we should not have an inconsistency problem - that's
about the generation of the files in the first place, so in that regard
I agree with Emmanuel. None of the above will help with that (except
excluding the property altogther which is just going to be bad news).
Cheers,
Brett
Emmanuel Venisse wrote:
Carlos Sanchez a écrit :
So I have a problem when svn tries to commit text files with
inconsistent line endings (dos and unix), eg. the site generated docs
that we're trying to make consistent.
I have set auto props with the svn:native, svn complains when
commiting new files with the "inconsistent new line" message.
so you have dos and unix line endings in your file.
I've seen this code in the svn add command, but don't know how to use
it from the scm provider.
protected ScmResult executeAddCommand( ScmProviderRepository
repository, ScmFileSet fileSet, String message,
boolean binary )
throws ScmException
{
// TODO: could do this with propset?
if ( binary )
{
throw new ScmException( "This provider does not yet
support binary files" );
}
If I don't find a solution, i'm gonna add the setProperty and
deleteProperty methods to the scm provider and check if my scm is
instance of it to remove the native property before commit.
I'm +1 for these two methods but it isn't a good workaround. It'd be
better to fix your line endings before to commit your files and keep svn
properties like they are defined in svn or with auto props.
Emmanuel
Re: svn commit: r397253 - /maven/scm/trunk/maven-scm-api/src/main/java/org/apache/maven/scm/ScmFileSet.java
Carlos Sanchez wrote: now the behaviour is consistent between empty lists and non empty if we want to make the list unmodifiable, both should but not just the empty one as before Yes, I agree both should be unmodifiable (I have intellij set up to complain at me now when I leak that though I don't always worry about it). All I meant, was there a specific example where this happened that led to the change? - Brett
Re: svn commit: r397253 - /maven/scm/trunk/maven-scm-api/src/main/java/org/apache/maven/scm/ScmFileSet.java
Doesn't that seem a bit leaky to you? Why is an external entity
modifying the files list directly?
[EMAIL PROTECTED] wrote:
Author: carlos
Date: Wed Apr 26 10:48:41 2006
New Revision: 397253
URL: http://svn.apache.org/viewcvs?rev=397253&view=rev
Log:
Prevent problems when returning an unmodifiable list
Modified:
maven/scm/trunk/maven-scm-api/src/main/java/org/apache/maven/scm/ScmFileSet.java
Modified:
maven/scm/trunk/maven-scm-api/src/main/java/org/apache/maven/scm/ScmFileSet.java
URL:
http://svn.apache.org/viewcvs/maven/scm/trunk/maven-scm-api/src/main/java/org/apache/maven/scm/ScmFileSet.java?rev=397253&r1=397252&r2=397253&view=diff
==
---
maven/scm/trunk/maven-scm-api/src/main/java/org/apache/maven/scm/ScmFileSet.java
(original)
+++
maven/scm/trunk/maven-scm-api/src/main/java/org/apache/maven/scm/ScmFileSet.java
Wed Apr 26 10:48:41 2006
@@ -18,8 +18,8 @@
import java.io.File;
import java.io.IOException;
+import java.util.ArrayList;
import java.util.Arrays;
-import java.util.Collections;
import java.util.List;
import org.codehaus.plexus.util.FileUtils;
@@ -40,9 +40,7 @@
/**
* List of File objects, all relative to the basedir.
*/
-private List files = Collections.EMPTY_LIST;
-
-private static final File[] EMPTY_FILE_ARRAY = new File[0];
+private List files = new ArrayList( 0 );
/**
* Create a file set with no files, only the base directory.
@@ -51,7 +49,7 @@
*/
public ScmFileSet( File basedir )
{
-this( basedir, EMPTY_FILE_ARRAY );
+this( basedir, new ArrayList( 0 ) );
}
/**
Re: Adding a directory recursively
Emmanuel Venisse wrote: Brett Porter a écrit : Emmanuel Venisse wrote: I think it would be good to add this method and it's easy to do. For svn, we must check if : - .svn directory exist in directory for subversion - CVS directory exist in directory for CVS - .bzr directory exist in directory for bazaar - nothing to do for file provider - don't know for clearcase, perforce and starteam Is that really necessary? Shouldn't it error out if you try to add something that is already added? If you don't have .svn, CVS... directories, they aren't already added. Emmanuel Exactly - maybe I misunderstood but what I meant was that you don't need to check for it - if you do an addDirectory, you attempt to add the whole directory (and if something is already added, with .svn, it errors, but if none of them have .svn it is all happy). - Brett
Re: Adding a directory recursively
Emmanuel Venisse wrote: I think it would be good to add this method and it's easy to do. For svn, we must check if : - .svn directory exist in directory for subversion - CVS directory exist in directory for CVS - .bzr directory exist in directory for bazaar - nothing to do for file provider - don't know for clearcase, perforce and starteam Is that really necessary? Shouldn't it error out if you try to add something that is already added? - Brett
Re: Java version policy
Torbjorn Smorgrav wrote: > Do we have a Java version policy? > I guess we are targeting 1.3? > > Cheers > Torbjørn > 1.4
Re: PVCS and Maven
Thanks for contacting us. This is certainly welcome - nobody is better positioned to write this code than you are, and that is a good thing for users of PVCS that use Maven and/or Continuum. I'd just like to add that we can only accept code donations that are licensed under the Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0.txt), and it may be necessary to execute a software grant (http://www.apache.org/licenses/software-grant.txt) to go along with the contribution. Hopefully, these shouldn't be an obstacle. As Emmanuel said, we certainly look forward to hearing more from you on the the scm-dev@maven.apache.org list. We're more than happy to answer any further questions you have. Regards, Brett Kevin Parker wrote: > Dear Sir, > > Thank you. Once we have approval to donate the code we will follow the > process you suggested. > > Sincerely, > > Kevin > > Kevin Parker > Vice President Market Development > Serena Software Inc. > 2755 Campus Drive, 3rd Floor, San Mateo, CA 94403-2538 > www.serena.com > tel 650-522-6635 > fax 650-522-6835 > cell 650-224-1691 > email [EMAIL PROTECTED] > > > -Original Message- > From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 28, 2006 11:24 > To: scm-dev@maven.apache.org > Cc: David Parker; Francis Long; Kevin Parker > Subject: Re: PVCS and Maven > > Hi, > > Do you have implemented maven-scm interfaces for PVCS? > You can create an issue (http://jira.codehaus.org/browse/SCM) and attach your > code to it. > You can subscribe too scm developers list (little traffic) so you'll can help > users that want to use > your provider. > > If you have any questions about maven-scm, don't hesitate to send a mail to > developers list. > > Emmanuel > > Kevin Parker a écrit : >> Dear Maven's, >> >> We have recently developed a Maven interface for our PVCS product and >> are interested in the process for potentially donating this to the >> project. Could someone contact me and let me know what the process would be. >> >> Sincerely, >> >> *//**//**//**/Kevin >> /**//**//**/ >> /Kevin Parker >> *///Vice President Market Development >> /***Serena Software Inc*. >> 2755 Campus Drive, 3^rd Floor, San Mateo, CA 94403-2538 >> ***www.serena.com >> *tel 650-522-6635 >> fax 650-522-6835 >> cell650-224-1691 >> email [EMAIL PROTECTED] >> >> >> >> ** >> This email and any files transmitted with it are confidential and >> intended solely for the use of the individual or entity to whom they >> are addressed. Any unauthorized review, use, disclosure or distribution >> is prohibited. If you are not the intended recipient, please contact the >> sender by reply e-mail and destroy all copies of the original message. >
Re: [continuum] BUILD FAILURE: Maven SCM Bazaar Provider
That's probaly it, thanks. - Brett Torbjørn Smørgrav wrote: > Have you tested Bazaar manually? > > Form the test log it clear that every command fails > due to an import error in Bazaar. > > Check if the cElementTree module is installed properly by running: > $ python -c "import cElementTree" > > Torbjørn > > > > -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: 24. mars 2006 08:03 > To: scm-dev@maven.apache.org > Subject: Re: [continuum] BUILD FAILURE: Maven SCM Bazaar Provider > > > Any ideas on this? bzr 0.7 seems to be properly installed now. Can the > output of the tests be improved? > > - Brett > > Continuum Build Server wrote: >> Online report : > http://ci.codehaus.org/continuum-maven/servlet/continuum/target/ProjectBuild > .vm/view/ProjectBuild/id/66/buildId/714 >> Build statistics: >> State: Failed >> Previous State: Failed >> Started at: Thu, 23 Mar 2006 22:50:10 -0800 >> Finished at: Thu, 23 Mar 2006 22:50:20 -0800 >> Total time: 10s >> Build Trigger: Forced >> Exit code: 1 >> Building machine hostname: cheddar.simulalabs.com >> Operating system : Linux(unknown) >> Java version : 1.5.0_03(Sun Microsystems Inc.) >> >> Changes >> No files changed >> >> > >> Output: >> > >> [INFO] Scanning for projects... >> > [INFO] - > --- >> [INFO] Building Maven SCM Bazaar Provider >> [INFO]task-segment: [clean, install] >> > [INFO] - > --- >> [INFO] [clean:clean] >> [INFO] Deleting directory > /home/nobody/continuum-maven/working-directory/66/target >> [INFO] Deleting directory > /home/nobody/continuum-maven/working-directory/66/target/classes >> [INFO] Deleting directory > /home/nobody/continuum-maven/working-directory/66/target/test-classes >> [INFO] [resources:resources] >> [INFO] Using default encoding to copy filtered resources. >> [INFO] [compiler:compile] >> Compiling 19 source files to > /home/nobody/continuum-maven/working-directory/66/target/classes >> [INFO] [resources:testResources] >> [INFO] Using default encoding to copy filtered resources. >> [INFO] [compiler:testCompile] >> Compiling 7 source files to > /home/nobody/continuum-maven/working-directory/66/target/test-classes >> [INFO] [surefire:test] >> [INFO] Setting reports dir: > /home/nobody/continuum-maven/working-directory/66/target/surefire-reports >> --- >> T E S T S >> --- >> [surefire] Running > org.apache.maven.scm.provider.bazaar.command.checkin.BazaarCheckInCommandTes > t >> EXECUTING: bzr init >> failed to open trace file: [Errno 13] Permission denied: '/.bzr.log' >> [ERROR] exceptions.ImportError: No module named > elementtree.ElementTreeBazaar version: Unknown >> Working directory: > /home/nobody/continuum-maven/working-directory/66/target/test-branch >> failed to open trace file: [Errno 13] Permission denied: '/.bzr.log' >> [ERROR] exceptions.ImportError: No module named > elementtree.ElementTreeEXECUTING: bzr add > /home/nobody/continuum-maven/working-directory/66/target/test-branch/pom.xml > /home/nobody/continuum-maven/working-directory/66/target/test-branch/readme. > txt > /home/nobody/continuum-maven/working-directory/66/target/test-branch/src/mai > n/java/Application.java > /home/nobody/continuum-maven/working-directory/66/target/test-branch/src/tes > t/java/Test.java >> failed to open trace file: [Errno 13] Permission denied: '/.bzr.log' >> [ERROR] exceptions.ImportError: No module named > elementtree.ElementTreeBazaar version: Unknown >> Working directory: > /home/nobody/continuum-maven/working-directory/66/target/test-branch >> failed to open trace file: [Errno 13] Permission denied: '/.bzr.log' >> [ERROR] exceptions.ImportError: No module named > elementtree.ElementTreeEXECUTING: bzr init >> failed to open trace file: [Errno 13] Permission denied: '/.bzr.log' >> [ERROR] exceptions.ImportError: No module named > elementtree.ElementTreeBazaar version: Unknown >> Working directory: > /home/nobody/continuum-maven/working-directory/66/target/test-branch >> failed to open t
Re: [continuum] BUILD FAILURE: Maven SCM Bazaar Provider
Any ideas on this? bzr 0.7 seems to be properly installed now. Can the output of the tests be improved? - Brett Continuum Build Server wrote: > Online report : > http://ci.codehaus.org/continuum-maven/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/66/buildId/714 > Build statistics: > State: Failed > Previous State: Failed > Started at: Thu, 23 Mar 2006 22:50:10 -0800 > Finished at: Thu, 23 Mar 2006 22:50:20 -0800 > Total time: 10s > Build Trigger: Forced > Exit code: 1 > Building machine hostname: cheddar.simulalabs.com > Operating system : Linux(unknown) > Java version : 1.5.0_03(Sun Microsystems Inc.) > > Changes > No files changed > > > Output: > > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Maven SCM Bazaar Provider > [INFO]task-segment: [clean, install] > [INFO] > > [INFO] [clean:clean] > [INFO] Deleting directory > /home/nobody/continuum-maven/working-directory/66/target > [INFO] Deleting directory > /home/nobody/continuum-maven/working-directory/66/target/classes > [INFO] Deleting directory > /home/nobody/continuum-maven/working-directory/66/target/test-classes > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > Compiling 19 source files to > /home/nobody/continuum-maven/working-directory/66/target/classes > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:testCompile] > Compiling 7 source files to > /home/nobody/continuum-maven/working-directory/66/target/test-classes > [INFO] [surefire:test] > [INFO] Setting reports dir: > /home/nobody/continuum-maven/working-directory/66/target/surefire-reports > > --- > T E S T S > --- > [surefire] Running > org.apache.maven.scm.provider.bazaar.command.checkin.BazaarCheckInCommandTest > EXECUTING: bzr init > failed to open trace file: [Errno 13] Permission denied: '/.bzr.log' > [ERROR] exceptions.ImportError: No module named > elementtree.ElementTreeBazaar version: Unknown > Working directory: > /home/nobody/continuum-maven/working-directory/66/target/test-branch > failed to open trace file: [Errno 13] Permission denied: '/.bzr.log' > [ERROR] exceptions.ImportError: No module named > elementtree.ElementTreeEXECUTING: bzr add > /home/nobody/continuum-maven/working-directory/66/target/test-branch/pom.xml > /home/nobody/continuum-maven/working-directory/66/target/test-branch/readme.txt > > /home/nobody/continuum-maven/working-directory/66/target/test-branch/src/main/java/Application.java > > /home/nobody/continuum-maven/working-directory/66/target/test-branch/src/test/java/Test.java > failed to open trace file: [Errno 13] Permission denied: '/.bzr.log' > [ERROR] exceptions.ImportError: No module named > elementtree.ElementTreeBazaar version: Unknown > Working directory: > /home/nobody/continuum-maven/working-directory/66/target/test-branch > failed to open trace file: [Errno 13] Permission denied: '/.bzr.log' > [ERROR] exceptions.ImportError: No module named > elementtree.ElementTreeEXECUTING: bzr init > failed to open trace file: [Errno 13] Permission denied: '/.bzr.log' > [ERROR] exceptions.ImportError: No module named > elementtree.ElementTreeBazaar version: Unknown > Working directory: > /home/nobody/continuum-maven/working-directory/66/target/test-branch > failed to open trace file: [Errno 13] Permission denied: '/.bzr.log' > [ERROR] exceptions.ImportError: No module named > elementtree.ElementTreeEXECUTING: bzr add > /home/nobody/continuum-maven/working-directory/66/target/test-branch/pom.xml > /home/nobody/continuum-maven/working-directory/66/target/test-branch/readme.txt > > /home/nobody/continuum-maven/working-directory/66/target/test-branch/src/main/java/Application.java > > /home/nobody/continuum-maven/working-directory/66/target/test-branch/src/test/java/Test.java > failed to open trace file: [Errno 13] Permission denied: '/.bzr.log' > [ERROR] exceptions.ImportError: No module named > elementtree.ElementTreeBazaar version: Unknown > Working directory: > /home/nobody/continuum-maven/working-directory/66/target/test-branch > failed to open trace file: [Errno 13] Permission denied: '/.bzr.log' > [ERROR] exceptions.ImportError: No module named > elementtree.ElementTree[surefire] Tests run: 2, Failures: 0, Errors: 2, Time > elapsed: 1.622 sec FAILURE !! > [surefire] Running > org.apache.maven.scm.provider.bazaar.command.checkout.BazaarCheckOutCommandTest > EXECUTING: bzr init > failed to open t
Re: [vote] Add Torbjørn Smørgrav as Mav en-SCM committer
Got 6 x +1's here. Time to move forward? Emmanuel Venisse wrote: > Hi > > I'd want to add Torbjørn Smørgrav as Maven-SCM committer. > He's the maintainer of bazaar scm provider and have done a good work on > it and TCK. > He want to maintain it in next year (at least). > > Here my +1 > > Emmanuel >
Re: Tests of 1.0
Some more feedback. Again, sorry I didn't get this to you earlier. - since Bazaar, VSS, etc are "partially implemented", according to the site, should they be omitted from this release? Or do they do enough to be useful? Can we list what is implemented and what is not? - why is the login package not in the command package? - can the site include a short users guide: how to get a provider instance and call the common methods? This can be very rough and someone else can polish up the text afterwards - I think the examples are important. - there's some javadoc missing. Can this be added to the public facing classes? (eg, ScmFile, ScmResult, and the manager, provider and repository interfaces) - can we get the javadoc and jxr published as part of the release process, like Carlos did for m2? I think these last couple could make a big difference in getting interest in people using it on its own, rather than just those using the maven plugins and continuum. Thanks, Brett Emmanuel Venisse wrote: > Hi, > > I finished all changes in maven-scm and it's ready for the release. > > Can you test it with your respective scm? > I updated release plugin, changelog plugin (at mojo.codehaus.org) and > continuum 1.0.3 with latest maven-scm artefacts, so if you can test > Maven-scm with them, that will be great. > > I'll release Maven-SCM 1.0 probably at monday if all is ok. > > snapshot of maven-scm is deployed so you don't need to build it. > > Thanks. > Emmanuel >
Re: Tests of 1.0
Other test failures: ClearCase checkout: junit.framework.ComparisonFailure: expected:<...c...> but was:<...C...> at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.maven.scm.provider.clearcase.command.checkout.ClearCaseCheckOutCommandTest.testCreateViewCommandLine(ClearCaseCheckOutCommandTest.java:38) (looks like a windows drive letter, can usually be gotten around by getting the canonical path of both strings). cvsexe: fails due to the extreme length of the path. Is the extra level for each provider really necessary? maven-scm-providers/maven-scm-providers-cvs/maven-scm-provider-cvsexe could just be maven-scm-providers/maven-scm-provider-cvs-exe StartTeam: org.apache.maven.scm.ScmException: C:\home\brett\scm\maven\scm\maven-scm-providers\maven-scm-provider-starteam\target\testdir\testfile.txt was not contained in c:\home\brett\scm\maven\scm\maven-scm-providers\maven-scm-provider-starteam at org.apache.maven.scm.provider.starteam.StarteamScmProvider.getRelativePath(StarteamScmProvider.java:340) at org.apache.maven.scm.provider.starteam.StarteamScmProviderTest.testGoodGetRelativeFile(StarteamScmProviderTest.java:44) (I don't have starteam installed - do I need to?) Cheers, - Brett Emmanuel Venisse wrote: > Hi, > > I finished all changes in maven-scm and it's ready for the release. > > Can you test it with your respective scm? > I updated release plugin, changelog plugin (at mojo.codehaus.org) and > continuum 1.0.3 with latest maven-scm artefacts, so if you can test > Maven-scm with them, that will be great. > > I'll release Maven-SCM 1.0 probably at monday if all is ok. > > snapshot of maven-scm is deployed so you don't need to build it. > > Thanks. > Emmanuel >
Re: [vote] Release Maven-SCM 1.0 final
I think it's a good idea, or at least mark them deprecated. If this release goes out with them in, you have to keep them working forever :) - Brett Emmanuel Venisse wrote: > I'm not sure. I know all these methods are deprecated since a long time. > You can provide a patch but i don't know if i'll apply it before the > release. > > Emmanuel > >> What about removing all depricated classes and methods before releasing >> version 1.0? >> >> Regards >> Torbjørn >> >> >> >> >
Re: Tests of 1.0
Currently, the Bazaar provider tests fail for me under Windows (I have Bazaar installed in Cygwin). IT is only the status command that fails. junit.framework.AssertionFailedError: Check result was successful, output: at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.maven.scm.ScmTckTestCase.checkOut(ScmTckTestCase.java:106) at org.apache.maven.scm.ScmTckTestCase.setUp(ScmTckTestCase.java:75) I'd actually like to have the tests not require svn, cvs, bzr installed to pass, and move those tests to integration tests in some way. WDYT? - Brett Emmanuel Venisse wrote: > Hi, > > I finished all changes in maven-scm and it's ready for the release. > > Can you test it with your respective scm? > I updated release plugin, changelog plugin (at mojo.codehaus.org) and > continuum 1.0.3 with latest maven-scm artefacts, so if you can test > Maven-scm with them, that will be great. > > I'll release Maven-SCM 1.0 probably at monday if all is ok. > > snapshot of maven-scm is deployed so you don't need to build it. > > Thanks. > Emmanuel >
Re: [vote] Add Torbjørn Smørgrav as Mav en-SCM committer
+1. That looks like some great work. - Brett Emmanuel Venisse wrote: > Hi > > I'd want to add Torbjørn Smørgrav as Maven-SCM committer. > He's the maintainer of bazaar scm provider and have done a good work on > it and TCK. > He want to maintain it in next year (at least). > > Here my +1 > > Emmanuel >
Re: [vote] Release Maven-SCM 1.0 final
Hi Emmanuel, It seems everyone is happy with this vote given the time and feedback so far. I'm going to review this tomorrow before adding a +1. I'm sorry I didn't dedicate time to it sooner. Is it possible that the code can be stabilised for 24 hours before actually cutting the release to give everyone a chance to run the tests locally? Thanks, Brett Emmanuel Venisse wrote: > Hi everyone, > > I'd like to release 1.0 final of Maven-SCM. All APIs are stable since a > long time and we didn't find any blocker issues since 1.0-beta-2 release. > > The list of issues fixed are : > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10527&fixfor=12346 > > > We have now 3 issues that i will fix before the release. > > I'll leave the vote open for the customary 72 hours before summarizing. > Please cast your vote as: > > [ ] +1 Yes, release > [ ] 0 No opinion > [ ] -1 No, don't release > > Here's my +1. > > Cheers, > > Emmanuel >
Re: Questions about adding a new SCM implementation
You should have to do one of the following: - add the dependency on the new provider to the maven-scm-plugin pom.xml - in your pom, add it as part of the scm plugin declaration: maven-scm-plugin org.apache.maven.scm maven-new-scm-provider 1.0-SNAPSHOT We're working on a solution to this need for Maven 2.1. what is the new provider? Will it be contributed to the project? - Brett Mcmahon, Chris wrote: > I've implemented a new SCM provider, and everything seems to be in order, but > I can't get the SCM plugin to recognize it at runtime. I can compile and > install the new provider as an artifact locally. I've got the right > information set in the src\main\resources\META-INF\plexus\components.xml > file. > > As a sanity check, I took the source for an existing SCM provider and copied > it, altering the POM accordingly, renaming all the packages, altering > ScmProvider's getScmType() method to return the new provider key, and altered > the plexus\components.xml to point to the provider with the proper key. > Again, I was able to compile and install, but the provider is still not > recognized. > > -- Is it a requirement that SCM implementations be child modules of the > scm-providers project or can they be independent projects? > -- Should I be editing existing SCM POMs in my local repository to reference > the new implementations? > > Any help would be appreciated >
Re: Where are scm releases deployed?
Arnaud HERITIER wrote: > > The Maven 1.x repository doesn't really exist any more. Everything is > supposed to be served via the Maven 2.x repository. I'm just fixing that > now. > > > When I noticed it, I think we had always two distinct repositories. > I forgot to verify it when you changed them. Well they are still there, but the requests all go through one. I'll turn off the sync for m1 now. Try the request - you should be able to obtain it. - Brett
Re: Where are scm releases deployed?
Its unlikely to be noticed in a JIRA comment. The Maven 1.x repository doesn't really exist any more. Everything is supposed to be served via the Maven 2.x repository. I'm just fixing that now. - Brett Arnaud HERITIER wrote: > I commented the issue some months ago, but up until now nobody replied. > > http://jira.codehaus.org/browse/MPSCM-68 > > cheers, > > Arnaud > > On 1/8/06, *Brett Porter* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > > I was going to say m1 == m2 repo, but it appears that's not the case > here. I have to figure out what's going on. > > - Brett > > Mike Perham wrote: > > http://www.ibiblio.org/maven2/org/apache/maven/scm/ > > > > I guess the beta releases have not been sync'd to m1. > > > > -Original Message- > > From: Dennis Lundberg [mailto: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>] > > Sent: Sunday, January 08, 2006 8:53 AM > > To: scm-dev@maven.apache.org <mailto:scm-dev@maven.apache.org> > > Subject: Where are scm releases deployed? > > > > Hi > > > > I'm working on the Maven 1 scm-plugin. I would like to update its > > dependencies on maven-scm to a newer version. It's currently using > > 1.0-alpha-2. > > > > But I am unable to find any builds that are newer than 1.0-alpha-2 in > > any of the places that I have looked: > > - http://www.ibiblio.org/maven/org.apache.maven.scm/jars/ > > - http://cvs.apache.org/repository/org.apache.maven.scm/jars/ > > > > Am I looking in the wrong places? If not, can someone please publish > > 1.0-beta-2. > > > > Also are the snapshots published anywhere, so that Maven-1 can find > > them? > > > > -- > > Dennis Lundberg > > > >
Re: Where are scm releases deployed?
I was going to say m1 == m2 repo, but it appears that's not the case here. I have to figure out what's going on. - Brett Mike Perham wrote: > http://www.ibiblio.org/maven2/org/apache/maven/scm/ > > I guess the beta releases have not been sync'd to m1. > > -Original Message- > From: Dennis Lundberg [mailto:[EMAIL PROTECTED] > Sent: Sunday, January 08, 2006 8:53 AM > To: scm-dev@maven.apache.org > Subject: Where are scm releases deployed? > > Hi > > I'm working on the Maven 1 scm-plugin. I would like to update its > dependencies on maven-scm to a newer version. It's currently using > 1.0-alpha-2. > > But I am unable to find any builds that are newer than 1.0-alpha-2 in > any of the places that I have looked: > - http://www.ibiblio.org/maven/org.apache.maven.scm/jars/ > - http://cvs.apache.org/repository/org.apache.maven.scm/jars/ > > Am I looking in the wrong places? If not, can someone please publish > 1.0-beta-2. > > Also are the snapshots published anywhere, so that Maven-1 can find > them? > > -- > Dennis Lundberg >
Re: [vote] Mike Perham as a committer to Maven SCM
+1 Emmanuel Venisse wrote: > Hi, > > Mike works on Perforce provider. > This is a vote to make him a committer. > > +1 from me. > > Emmanuel >
Re: Exercising more commands?
Once the provider is ok, it can be dropped into a 1.0.2 install, though? Emmanuel Venisse wrote: > so, Perforce won't be support in continuum 1.0.2 > > Mike Perham a écrit : >> I don't have time to do this right now. It'll have to wait until we >> deploy continuum here internally. >> >> -Original Message- >> From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] Sent: Tuesday, >> November 29, 2005 12:04 PM >> To: scm-dev@maven.apache.org >> Subject: Re: Exercising more commands? >> >> not yet, look at sources. >> >> Can you test perforce provider with continuum? >> >> Emmanuel >> >> Mike Perham a écrit : >> >>> Any samples or docs on how to use the plugin? >>> -Original Message- >>> From: Emmanuel Venisse [mailto:[EMAIL PROTECTED] >>> Sent: Tuesday, November 29, 2005 11:35 AM >>> To: scm-dev@maven.apache.org >>> Subject: Re: Exercising more commands? >>> >>> maven-scm-plugin in maven-scm tree >>> >>> Emmanuel >>> >>> Mike Perham a écrit : >>> >>> How do I exercise the commands which are not used by the release plugin? I'm thinking mostly of the diff and changelog commands - are there any m2 plugins that use these commands? mike >>> >>> >>> >>> >>> >>> >> >> >> >> >> >
Re: Exercising more commands?
The best way is to implement the TCK methods (some of which may not exist yet). Mike Perham wrote: > How do I exercise the commands which are not used by the release plugin? > I'm thinking mostly of the diff and changelog commands - are there any > m2 plugins that use these commands? > > mike >
[jira] Created: (SCM-75) messages are logged twice
messages are logged twice - Key: SCM-75 URL: http://jira.codehaus.org/browse/SCM-75 Project: Maven SCM Type: Bug Components: maven-scm-provider-cvs Reporter: Brett Porter running scm:update on the wadi project was logging everything twice (both under normal, and under -X). It seemed to log more times as it went through a reactor 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] Created: (SCM-74) users for scm:update instead of the one in the checkout
users for scm:update instead of the one in the checkout Key: SCM-74 URL: http://jira.codehaus.org/browse/SCM-74 Project: Maven SCM Type: Bug Components: maven-scm-provider-cvs, maven-plugin Reporter: Brett Porter this is problematic with a :ext:ssh: checkout, and a :pserver: connection, as it gives the cryptic error "password is required" (which should be explained more anyway about doing a cvs login, or even use plexus-interactivity to do the login step) -- 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
Re: no such provider 'clearcase'
You can also add it within the plugin tag in your pom Emmanuel Venisse wrote: you need to update the release plugin pom and rebuild it. you need for release plugin tag, checkin, checkout, update remove and status commands. Emmanuel
[jira] Closed: (SCM-59) the mojo should refers to pom to pickup connectionUrl
[ http://jira.codehaus.org/browse/SCM-59?page=all ] Brett Porter closed SCM-59: --- Resolution: Duplicate Fix Version: (was: 1.0-alpha-4) > the mojo should refers to pom to pickup connectionUrl > - > > Key: SCM-59 > URL: http://jira.codehaus.org/browse/SCM-59 > Project: Maven SCM > Type: Bug > Components: maven-plugin > Versions: 1.0-alpha-3 > Environment: xp > Reporter: Dan Tran > > > My current directory has a pom.xml with appropriate SCM connection setting > However, when I execute > m2 scm:checkout > the command still require use to set -DconnectionUrl on command line -- 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
[Fwd: commit messages]
fyi --- Begin Message --- Subversion commit messages are sent to different lists according to the following mapping # Maven [/maven] for_paths = maven/ to_addr = commits at maven.apache.org suppress_if_match = yes [/maven/continuum] for_paths = maven/continuum/ to_addr = continuum-commits at maven.apache.org [/maven/scm] for_paths = maven/scm/ to_addr = scm-commits at maven.apache.org [/maven/wagon] for_paths = maven/wagon/ to_addr = wagon-commits at maven.apache.org In order to receive commit messages for continuum, scm, and wagon, you must be subscribed to the associated commits list. All other commits under /maven will go to the [EMAIL PROTECTED] list. Please don't ask me to "copy you over" (I did that only for the primary dev -> commits mapping). Many of the existing subscribers are using list-specific address aliases and you are the only ones who know which address you actually want on each list (if any), so please just subscribe yourselves. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- End Message ---
[jira] Created: (SCM-50) flesh out the SCM provider interface
flesh out the SCM provider interface Key: SCM-50 URL: http://jira.codehaus.org/browse/SCM-50 Project: Maven SCM Type: Task Components: maven-scm-api Reporter: Brett Porter Fix For: 1.0-alpha-2 instead of having an execute() method, the ScmProvider interface should have individual commands in the interface, like ScmManager currently does. In fact, after this, the ScmManager need not have the commands, and just needs to expose a getProvider method. This should eventually lead to the removal of CommandNameConstants -- 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: (SCM-49) bring ScmManager back to maven-scm proper
bring ScmManager back to maven-scm proper - Key: SCM-49 URL: http://jira.codehaus.org/browse/SCM-49 Project: Maven SCM Type: Task Reporter: Brett Porter Assigned to: Emmanuel Venisse Fix For: 1.0-alpha-2 we should have maven-scm-manager under maven-scm that contains the code that was recently taken from maven-scm-api instead of keeping it under plexus. -- 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
Re: scm plugin(build test failures with m2
I've seen all these before, but I can't remember how I got them. For the number of files, I thought I fixed a bug - it was uncommitted. I'm putting it in now - svn updated your code. For the bytes difference - this was experienced by someone using CVSNT on windows (it works with Cygwin). We'd really appreciate it if you can determine the problem :) There is an open JIRA for it. - Brett Rahul wrote: Hi Emmanuel, I tried building each of the providers individually, and here's what I get: For CVS provider: - CvsCheckoutCommandTest still fails with the attached error. For SVN provider: - SvnCheckOutCommandTckTest fails with attached error. - SvnUpdateCommandTckTest fails with attached error. There were quite a few errors the last time I ran "m2 install" from the root directory for all maven-scm projects but narrowed down to above three errors when I ran them individually from each project's directory. Thanks, Rahul
Re: Adding a new provider
Can you explain what you mean by "recognised"? Where are you using it? If you want it to be part of the build, include it in in maven-scm-providers/pom.xml. If you are talking about having it available at runtime - it will depend on what application you are using it with. It just needs to be in the correct classloader, and components.xml in the provider needs to have been set up properly (similarly to the other providers). Cheers, Brett Richardson, Simon (Treasury) wrote: I have just taken a copy of the source from svn trunk and can install api, test, providers and a provider successfully: maven-scm-api maven-scm-test maven-scm-providers maven-scm-provider-local I now want have my own provider recognised. How do I add a new provider? Regards Simon "MMS " made the following annotations. -- For more information on HBOS Treasury Services, please visit http://www.HBOSTS.com Or for details of our online FX & Deposit services, please go to http://www.HBOSdeal.com HBOS Treasury Services plc is part of the HBOS Group, which also includes Halifax plc and Bank of Scotland. Registered Office: 33 Old Broad Street, London EC2N 1HZ. Registered No. 2692890. Registered in England. Authorised and regulated by the Financial Services Authority. The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. This mail and any attachments have been scanned for viruses prior to leaving the HBOS Treasury Services plc network. HBOS Treasury Services plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. HBOS Treasury Services plc reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation. ==
[jira] Created: (SCM-41) username configuration not used for svn+ssh
username configuration not used for svn+ssh --- Key: SCM-41 URL: http://jira.codehaus.org/browse/SCM-41 Project: Maven SCM Type: Bug Components: maven-scm-provider-svn Reporter: Brett Porter Fix For: 1.0-alpha-2 when a username is provided as configuration, it is not passed properly to SSH for svn+ssh. It is possible this is an svn issue, but we could probably work around 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] Created: (SCM-40) username as part of svn+ssh url not accepted
username as part of svn+ssh url not accepted Key: SCM-40 URL: http://jira.codehaus.org/browse/SCM-40 Project: Maven SCM Type: Bug Components: maven-scm-provider-svn Versions: 1.0-alpha-1 Reporter: Brett Porter Fix For: 1.0 -- 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
Re: Flaw in maven-scm-api command line expansion
We discussed this online already... it is very hard to do an "excludes"
without this happening. The best way to handle it would be to:
- just use the directory name when all children in the directory are
included
- for checkin, only pass files that are modified
- not allow excludes on some operations
I think there is already a bug in JIRA under SCM or MPSCM (if not, there
should be).
What are your thoughts?
- Brett
dan tran wrote:
Folks,
Most of maven-scm-api commands like checkin, add, tag, changelog has a
ScmFileSet argument which ultimately expands into a list of individual
files on a command line. The finally command line becomes very long,
huge, so huge
for a larget project (like my legacy project).
I know for sure, it will break on windows and could be on unixes.
May this is the main reason, why a number of implementations just
simply ignore the ScmFileSet, and goes for the default which
most SCM systems consider as ${basedir}
Any thought?
-Dan
Re: PVCS and Maven
Richardson, Simon (Treasury) wrote: Jason van Zyl replied to my post to maven users regarding PVCS support in Maven. I understand from this post that you're now focusing efforts on SCM support within Maven SCM. I assume this is in relation to M2? I'm working with Maven 1.0.2 and hope to retrofit PVCS support into this. Can somebody provide me with some background on existing SCM support and I can see how it works for CVS and Subversion? Maven SCM will be used across the board. I intend to release an SCM and Changelog plugin in the next week or so for Maven 1.0 using this. BTW I will only be working with PVCS version 7.5.1.0 on Solaris - the latest release is 8.1. It's a start! :) Do you happen to know if it is backwards compatible? - Brett
Re: starteam changelog's dateformat issue
I think you may just have to hard code the format, but only if the locale is en_US. Can you test en_AU and see if it works? (We reverse the day and month in the date, would be interested to see whether that makes a difference here). - Brett dan tran wrote: Folks, starteam history command ouput has unexpected date format which the default SimpleDateTimeFormat() not able to handle it here is a sample output History for: project.xml Description: Locked by: Status: Modified Revision: 2 View: driver Branch Revision: 1.1 Author: build Date: 5/25/05 4:53:18 PM PDT If If I hardcode a SimpleDateTimeFormat according to this format, it will work, but affraid it may break on other locale Any suggestion? -Dan
[jira] Closed: (SCM-27) The SVN provider doesn't pass the tests
[ http://jira.codehaus.org/browse/SCM-27?page=all ] Brett Porter closed SCM-27: --- Resolution: Fixed > The SVN provider doesn't pass the tests > --- > > Key: SCM-27 > URL: http://jira.codehaus.org/browse/SCM-27 > Project: Maven SCM > Type: Bug > Components: maven-scm-provider-svn > Environment: Linux > Reporter: Trygve Laugstol > Assignee: Brett Porter > Attachments: > org.apache.maven.scm.provider.svn.command.diff.SvnDiffCommandTckTest.txt > > -- 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: (SCM-30) clean up dependencies
clean up dependencies - Key: SCM-30 URL: http://jira.codehaus.org/browse/SCM-30 Project: Maven SCM Type: Task Reporter: Brett Porter - move ScmTestCase out to provider-test instead of being in API - check over the dependencies (plexus-container should not be a dep) - set scope where appropriate -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-27) The SVN provider doesn't pass the tests
[ http://jira.codehaus.org/browse/SCM-27?page=history ] Brett Porter closed SCM-27: --- Fix Version: (was: 1.0-alpha-1) Resolution: Fixed Assign To: Brett Porter fixed two problems: - bad svn add command line - bad checkout directory > The SVN provider doesn't pass the tests > --- > > Key: SCM-27 > URL: http://jira.codehaus.org/browse/SCM-27 > Project: Maven SCM > Type: Bug > Components: maven-scm-provider-svn > Environment: Linux > Reporter: Trygve Laugstol > Assignee: Brett Porter > > -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
