only maven-scm-provider-svnjava -- Olivier
2009/3/20 Jason van Zyl <[email protected]>: > That's an old fork of svnkit, not sure you want to put it there. That > project is essentially dead. > > On 20-Mar-09, at 1:46 AM, Olivier Lamy wrote: > >> Hi, >> Not in mojo but here : http://xircles.codehaus.org/projects/svn4j ? >> >> a new path : https://svn.codehaus.org/svn4j/maven-scm-provider-svnjava/ >> >> -- >> Olivier >> >> 2009/3/20 Brett Porter <[email protected]>: >>> >>> 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 >>> [email protected] >>> http://blogs.exist.com/bporter/ >>> >>> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > ---------------------------------------------------------- > > People develop abstractions by generalizing from concrete examples. > Every attempt to determine the correct abstraction on paper without > actually developing a running system is doomed to failure. No one > is that smart. A framework is a resuable design, so you develop it by > looking at the things it is supposed to be a design of. The more examples > you look at, the more general your framework will be. > > -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks > >
