jira-importer commented on issue #322: URL: https://github.com/apache/maven-scm/issues/322#issuecomment-2964585630
**[David Hawkins](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=dhawkins)** commented I have implemented the maven-scm-provider-svn using the tmate.org JavaSVN library, which is a 100% java subversion client. I have details of the changes below. Quick Summary: (Detailed explanation of each below) - scm:svnexe will call the old svn provider which uses the svn executable. - scm:svn will use the new java implementation - There are a couple dependencies which I included that I am not sure what to do with - The test cases for svnjava are a bit of a hassle to set up so they are excluded by default in the pom. - There are changes to other scm artifacts which are needed for this change. - I have tested the java implementation by passing all Tck test cases, using the maven-release-plugin to prepare and perform releases, and using most of the maven-scm-plugin features to test the functionality. maven-scm-provider-svn: To provide a straight drop in replacement for the exiting provider, the project has been segmented some. The requirement was support both the java and exe subversion clients and the user could determine which to use based on what is in their classpath. I had troubles with this because many of the tools/plugins have explicit dependencies on the maven-scm-provider-svn artifact. If I had created a svnjava client and added the item to every plugin that depended on the original svn provider I would still have a problem because the role-hint in components.xml is ultimately what decides the implementation used. For now what I did was separate the project into 4 sub-components. - maven-scm-provider-svn-commons - Common shared components that are used in both of the following components. - maven-scm-provider-svnexe - This is basically the existing svn provider that works by calling the svn executable. To make things work, I had to change the role-hint to svnexe. This is just a temporary measure while I get advice from others as to how to handle this. - maven-scm-provider-svnjava - This is the new svn provider which uses the tmate.org JavaSVN library which is a 100% pure java subversion client. It is currently configured as with the role-hint of "svn" which makes it the default scm:svn provider. - maven-scm-provider-svn - This is basically a compatibility project which has dependencies on the components listed above. This causes existing plugins/components with dependencies on the svn provider to get access to both the svnexe and svnjava implementations. I don't really like this solution a lot, but that's all I could come up with initially. Dependencies: The ganymed and javasvn .tar.gz files are files I created and put in my local repository while developing and testing. I am not sure how to handle these once we actually start using this plugin. For now I just created my own packages. Testing: One limitation of JavaSVN is that it does not support file:// urls for the subversion repository. This poses a problem with the test cases because the standard Scm Tck test cases expect being able to create a local repository and access it. I have all of the Tck test cases excluded in the pom for the svnjava implementation because of the external requirements needed to execute the test cases. To run them, you have to install apache and point it's SVNParentPath to a local directory which acts as a root for svn repositories. You then have to configure a properties file and tell it the location of the repository root as well as the url to access it. The test cases will then create new repositories under that root and access them via the url. By doing this, all of the exiting Tck test cases pass for the new svnjava implementation. For detailed setup information, see the comments in: org.apache.maven.scm.provider.svn.svnjava.SvnJavaTestUtils.java Once again, these tests are disabled by default and this setup is not required to compile the library. maven-scm-plugin changes: - scm:status now displays the file statuses - scm:changelog now supports an optional parameter of dateFormat which defaults to "yyyy-MM-dd". Previously, the date format defaulted to SimpleDateFormat.toLocalizedPattern. On my machine this happens to be "M/d/yy h:mm a". Maven appears to have an issue with handling a command line that contains any ":" colons at all. This is a separate issue, but I thought it would be nice to allow the user to specify any date format that they like. - Now handles generically assigning the username and password to the ScmProviderRepository rather than having a special case for subversion. maven-scm-api changes: - ChangeSet now has a constructor which accepts a Date as a parameter rather than just taking strings. maven-scm-manager-plexus - Added exclusion for plexus:plexus-utils for the plexus container dependency. Since plexus:plexus-utils is the same thing as org.codehaus.plexus:plexus-utils, maven will end up selecting both while resolving transitive dependencies. This causes a problem if the older version of the library is first in the classpath. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
