[
https://jira.codehaus.org/browse/SCM-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=324702#comment-324702
]
Markus KARG commented on SCM-718:
---------------------------------
Thanks for sharing your ideas. In fact, extending the svn-settings.xml is
actually what I would propose. If one could say in svn-settings.xml that SVN
should be resolved by SVK instead of native SVN, then there is no licence
trouble, as there is no SVK code included in the SCM plugin then. From the
licence side this would be a clean solution, and technically it should not
induce too much trouble.
A solution that enforces POM changes is by far not as smart.
> Please include Java-based SVN client
> ------------------------------------
>
> Key: SCM-718
> URL: https://jira.codehaus.org/browse/SCM-718
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-svn
> Affects Versions: future
> Reporter: Markus KARG
> Assignee: Robert Scholte
>
> It is rather annoying that both major "Maven Embedders" (Eclipse IDE and
> Jenkins CI Server) are able to talk to SVN Servers without the need to have
> Subversion installed explicitly, but when running MVN:SCM mojos the same
> containers "inherit" Maven SCM's need for a native and explicitly installed
> Subversion client. :-(
> It would be so great if the SCM:SVN implementation would include a Java-based
> SVN client just as Eclipse and Jenkins do. For most use cases this would
> simplify the admin's job by far (think of a Jenkins CI build farm for
> example, where the admin currently needs to install SVN on each build slave),
> while all others could still explicitly disable the built-in Java-based
> client, effectively falling back to the current need of having SVN on disk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
