You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scm-dev@maven.apache.org by Olivier Lamy <ol...@apache.org> on 2009/03/19 01:22:12 UTC
svnjava provider and maven scm
Hi,
As we don't distribute the svnkit (it's only a dependency available in
the central repo), why we can't make a release of this provider ?
Any objections to move the sandbox module in trunk ?
Thanks,
--
Olivier
Re: svnjava provider and maven scm
Posted by Olivier Lamy <ol...@apache.org>.
done. there is now only a README.TXT
(https://svn.apache.org/repos/asf/maven/sandbox/trunk/scm/README.TXT)
--
Olivier
2009/3/21 Brett Porter <br...@apache.org>:
> 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
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: svnjava provider and maven scm
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://blogs.exist.com/bporter/
Re: svnjava provider and maven scm
Posted by Olivier Lamy <ol...@apache.org>.
So I have moved back the provider to sandbox and start a fork here [1]
If someone want to have karma ping me.
--
Olivier
[1] http://code.google.com/p/maven-scm-provider-svnjava/
2009/3/20 Jason van Zyl <jv...@sonatype.com>:
> 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.
>
> On 20-Mar-09, at 8:02 AM, Olivier Lamy wrote:
>
>> only maven-scm-provider-svnjava
>>
>> --
>> Olivier
>>
>> 2009/3/20 Jason van Zyl <jv...@sonatype.com>:
>>>
>>> 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 <br...@apache.org>:
>>>>>
>>>>> 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
>>>>> brett@apache.org
>>>>> 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
>>>
>>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
> the course of true love never did run smooth ...
>
> -- Shakespeare
>
>
Re: svnjava provider and maven scm
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://blogs.exist.com/bporter/
Re: svnjava provider and maven scm
Posted by Jason van Zyl <jv...@sonatype.com>.
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.
On 20-Mar-09, at 8:02 AM, Olivier Lamy wrote:
> only maven-scm-provider-svnjava
>
> --
> Olivier
>
> 2009/3/20 Jason van Zyl <jv...@sonatype.com>:
>> 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 <br...@apache.org>:
>>>>
>>>> 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
>>>> brett@apache.org
>>>> 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
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
the course of true love never did run smooth ...
-- Shakespeare
Re: svnjava provider and maven scm
Posted by Olivier Lamy <ol...@apache.org>.
only maven-scm-provider-svnjava
--
Olivier
2009/3/20 Jason van Zyl <jv...@sonatype.com>:
> 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 <br...@apache.org>:
>>>
>>> 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
>>> brett@apache.org
>>> 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
>
>
Re: svnjava provider and maven scm
Posted by Jason van Zyl <jv...@sonatype.com>.
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 <br...@apache.org>:
>>
>> 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
>> brett@apache.org
>> 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
Re: svnjava provider and maven scm
Posted by Olivier Lamy <ol...@apache.org>.
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 <br...@apache.org>:
>
> 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
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: svnjava provider and maven scm
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://blogs.exist.com/bporter/
Re: svnjava provider and maven scm
Posted by Jason van Zyl <jv...@sonatype.com>.
On 19-Mar-09, at 8: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.
The svn library is not optional for this component to work. You
require it to run.
SVNKit and that's not LGPL, it's a license we've never validated here.
It's a custom license called the TMate Open Source License.
Brett's proposal is not fine.
You may not like the way the legal process is here but you can't end-
run the safe guards in place by saying something is optional when it
clearly is not. And then trying to draw an analogy to a project where
the license isn't even the same and a completely custom one at that.
Ask Apache legal. Explain to them you're marking optional what isn't
and show them the TMate license and see what they tell you.
> --
> Olivier
>
> 2009/3/19 Jason van Zyl <jv...@sonatype.com>:
>> From my experience asking anyone about anything legal has never been
>> resolved in any timely manner.
>>
>> Whether grand fathered or anything else. Discussions have gone on
>> for a very
>> long time.
>>
>> Olivier if you want to release it then I would just taking it to
>> mojo and
>> then there are no issues.
>>
>> On 19-Mar-09, at 5:12 AM, Brett Porter wrote:
>>
>>>
>>> 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
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Re: svnjava provider and maven scm
Posted by Olivier Lamy <ol...@apache.org>.
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.
--
Olivier
2009/3/19 Jason van Zyl <jv...@sonatype.com>:
> From my experience asking anyone about anything legal has never been
> resolved in any timely manner.
>
> Whether grand fathered or anything else. Discussions have gone on for a very
> long time.
>
> Olivier if you want to release it then I would just taking it to mojo and
> then there are no issues.
>
> On 19-Mar-09, at 5:12 AM, Brett Porter wrote:
>
>>
>> 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
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
>
Re: svnjava provider and maven scm
Posted by Jason van Zyl <jv...@sonatype.com>.
From my experience asking anyone about anything legal has never been
resolved in any timely manner.
Whether grand fathered or anything else. Discussions have gone on for
a very long time.
Olivier if you want to release it then I would just taking it to mojo
and then there are no issues.
On 19-Mar-09, at 5:12 AM, Brett Porter wrote:
>
> 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
> brett@apache.org
> http://blogs.exist.com/bporter/
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Re: svnjava provider and maven scm
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://blogs.exist.com/bporter/
Re: svnjava provider and maven scm
Posted by Jason van Zyl <jv...@sonatype.com>.
On 19-Mar-09, at 1:25 AM, Olivier Lamy wrote:
> Hi,
> Ok. It's was not really clear for me.
>
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.
> Thanks for clarification,
> --
> Olivier
>
> 2009/3/19 Jason van Zyl <jv...@sonatype.com>:
>> If the license is not one that the ASF accepts then we can't really
>> dodge
>> the issue by saying that it's only in the POM.
>>
>> On 18-Mar-09, at 5:22 PM, Olivier Lamy wrote:
>>
>>> Hi,
>>> As we don't distribute the svnkit (it's only a dependency
>>> available in
>>> the central repo), why we can't make a release of this provider ?
>>> Any objections to move the sandbox module in trunk ?
>>>
>>> Thanks,
>>> --
>>> Olivier
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>> To do two things at once is to do neither.
>>
>> -—Publilius Syrus, Roman slave, first century B.C.
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Re: svnjava provider and maven scm
Posted by Olivier Lamy <ol...@apache.org>.
Hi,
Ok. It's was not really clear for me.
Thanks for clarification,
--
Olivier
2009/3/19 Jason van Zyl <jv...@sonatype.com>:
> If the license is not one that the ASF accepts then we can't really dodge
> the issue by saying that it's only in the POM.
>
> On 18-Mar-09, at 5:22 PM, Olivier Lamy wrote:
>
>> Hi,
>> As we don't distribute the svnkit (it's only a dependency available in
>> the central repo), why we can't make a release of this provider ?
>> Any objections to move the sandbox module in trunk ?
>>
>> Thanks,
>> --
>> Olivier
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
> To do two things at once is to do neither.
>
> -—Publilius Syrus, Roman slave, first century B.C.
>
>
Re: svnjava provider and maven scm
Posted by Jason van Zyl <jv...@sonatype.com>.
If the license is not one that the ASF accepts then we can't really
dodge the issue by saying that it's only in the POM.
On 18-Mar-09, at 5:22 PM, Olivier Lamy wrote:
> Hi,
> As we don't distribute the svnkit (it's only a dependency available in
> the central repo), why we can't make a release of this provider ?
> Any objections to move the sandbox module in trunk ?
>
> Thanks,
> --
> Olivier
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.