[
https://issues.apache.org/jira/browse/SCM-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17960086#comment-17960086
]
ASF GitHub Bot commented on SCM-13:
-----------------------------------
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.
> Investigate pure Java SVN interface
> -----------------------------------
>
> Key: SCM-13
> URL: https://issues.apache.org/jira/browse/SCM-13
> Project: Maven SCM (Moved to GitHub Issues)
> Issue Type: Task
> Components: maven-scm-provider-svn
> Reporter: Brett Porter
> Assignee: Emmanuel Venisse
> Priority: Major
> Fix For: 1.0-beta-3
>
> Attachments: SCM-13-maven-scm-api.patch,
> SCM-13-maven-scm-manager-plexus.patch, SCM-13-maven-scm-plugin.patch,
> SCM-13-maven-scm-provider-svn.tar.gz, ch.ethz.ganymed.tar.gz,
> tmate.org.javasvn.tar.gz
>
>
> There is this: http://tmate.org/svn/
> I'd say javahl is out because it requires native binaries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
