You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2010/02/25 16:15:21 UTC
Java.net Maven Repository Rescue Mission
As Maven users if you care about the quality of the Maven Repositories at Java.net then please help support us in our effort to get Snorcle to help fix the situation.
Sonatype is going to try and help by dedicating staff on March 5th to help Java.net projects transition over to a healthy Maven repository infrastructure:
http://www.sonatype.com/people/2010/02/java-net-maven-repository-rescue-mission-on-march-5th/
We already have support from Jean-Francois Arcand:
http://weblogs.java.net/blog/jfarcand/archive/2010/02/25/pain-over-javanets-maven-artifacts
Please show your support by voting on the DZone article here, which seems to draw attention:
http://www.dzone.com/links/javanet_maven_repository_rescue_mission_on_march.html
It's all about visibility and if we have enough users in the Maven community raise this as a concern then maybe we'll get somewhere this time.
And if you're a project at Java.net please let us help you on March 5th!
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Re: Java.net Maven Repository Rescue Mission
Posted by Jason van Zyl <ja...@sonatype.com>.
On Feb 25, 2010, at 10:56 AM, Justin Edelson wrote:
> On 2/25/10 10:36 AM, Brian Fox wrote:
>> Justin,
>> Yes we would but obviously the license on those binaries is important.
>> Some of the original binaries couldn't be redistributed which is why
>> they were pulled from central years ago.
> ...obligatory IANAL...
>
> My understanding, and I could be wrong about this, is that these
> artifacts were pulled because there was no way to have the user accept
> the license agreement before downloading.
>
It was actually Apache that made me pull them off. Sun didn't care and weren't going to sue us.
But that was the Sun Binary License and that's not used anymore. At least I haven't seen any artifacts of late using that license. All seems to be CDDL.
> However, Sun/Oracle distributes these artifacts (via the java.net repo)
> without this pre-download requirement. This doesn't necessarily mean
> that redistribution via central is ok, but it does suggest that it is at
> least worth having the conversation.
>
> (Furthermore, the JTA JAR on the java.net repository has *no* license
> information, so it's not like they're being diligent about this kind of
> thing.)
>
> Perhaps I should have written "legal teams" instead of "project teams"
> below.
>
> Justin
>
>
>>
>> On Thu, Feb 25, 2010 at 10:28 AM, Justin Edelson
>> <ju...@gmail.com> wrote:
>>> Jason-
>>> As I commented on your blog entry, what I think would be most useful is
>>> to handle the currently deployed javax.* artifacts. Don't get me wrong,
>>> dealing with the current/new releases will be helpful.
>>>
>>> Would Sonatype be willing to accept a list of artifact submissions from
>>> the community and then proactively work with the responsible project teams?
>>>
>>> For anyone running an caching MRM, it should be trivial to look in the
>>> cache for the java.net repo. Culling this list should be fairly straight
>>> forward.
>>>
>>> If the goal is to eliminiate (not just reduce) the dependency on the
>>> java.net repo, I'm pretty sure something like the above will need to be
>>> done.
>>>
>>> Justin
>>>
>>>
>>>
>>> On 2/25/10 10:15 AM, Jason van Zyl wrote:
>>>> As Maven users if you care about the quality of the Maven Repositories at Java.net then please help support us in our effort to get Snorcle to help fix the situation.
>>>>
>>>> Sonatype is going to try and help by dedicating staff on March 5th to help Java.net projects transition over to a healthy Maven repository infrastructure:
>>>>
>>>> http://www.sonatype.com/people/2010/02/java-net-maven-repository-rescue-mission-on-march-5th/
>>>>
>>>> We already have support from Jean-Francois Arcand:
>>>>
>>>> http://weblogs.java.net/blog/jfarcand/archive/2010/02/25/pain-over-javanets-maven-artifacts
>>>>
>>>> Please show your support by voting on the DZone article here, which seems to draw attention:
>>>>
>>>> http://www.dzone.com/links/javanet_maven_repository_rescue_mission_on_march.html
>>>>
>>>> It's all about visibility and if we have enough users in the Maven community raise this as a concern then maybe we'll get somewhere this time.
>>>>
>>>> And if you're a project at Java.net please let us help you on March 5th!
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ----------------------------------------------------------
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Re: Java.net Maven Repository Rescue Mission
Posted by Justin Edelson <ju...@gmail.com>.
On 2/25/10 10:36 AM, Brian Fox wrote:
> Justin,
> Yes we would but obviously the license on those binaries is important.
> Some of the original binaries couldn't be redistributed which is why
> they were pulled from central years ago.
...obligatory IANAL...
My understanding, and I could be wrong about this, is that these
artifacts were pulled because there was no way to have the user accept
the license agreement before downloading.
However, Sun/Oracle distributes these artifacts (via the java.net repo)
without this pre-download requirement. This doesn't necessarily mean
that redistribution via central is ok, but it does suggest that it is at
least worth having the conversation.
(Furthermore, the JTA JAR on the java.net repository has *no* license
information, so it's not like they're being diligent about this kind of
thing.)
Perhaps I should have written "legal teams" instead of "project teams"
below.
Justin
>
> On Thu, Feb 25, 2010 at 10:28 AM, Justin Edelson
> <ju...@gmail.com> wrote:
>> Jason-
>> As I commented on your blog entry, what I think would be most useful is
>> to handle the currently deployed javax.* artifacts. Don't get me wrong,
>> dealing with the current/new releases will be helpful.
>>
>> Would Sonatype be willing to accept a list of artifact submissions from
>> the community and then proactively work with the responsible project teams?
>>
>> For anyone running an caching MRM, it should be trivial to look in the
>> cache for the java.net repo. Culling this list should be fairly straight
>> forward.
>>
>> If the goal is to eliminiate (not just reduce) the dependency on the
>> java.net repo, I'm pretty sure something like the above will need to be
>> done.
>>
>> Justin
>>
>>
>>
>> On 2/25/10 10:15 AM, Jason van Zyl wrote:
>>> As Maven users if you care about the quality of the Maven Repositories at Java.net then please help support us in our effort to get Snorcle to help fix the situation.
>>>
>>> Sonatype is going to try and help by dedicating staff on March 5th to help Java.net projects transition over to a healthy Maven repository infrastructure:
>>>
>>> http://www.sonatype.com/people/2010/02/java-net-maven-repository-rescue-mission-on-march-5th/
>>>
>>> We already have support from Jean-Francois Arcand:
>>>
>>> http://weblogs.java.net/blog/jfarcand/archive/2010/02/25/pain-over-javanets-maven-artifacts
>>>
>>> Please show your support by voting on the DZone article here, which seems to draw attention:
>>>
>>> http://www.dzone.com/links/javanet_maven_repository_rescue_mission_on_march.html
>>>
>>> It's all about visibility and if we have enough users in the Maven community raise this as a concern then maybe we'll get somewhere this time.
>>>
>>> And if you're a project at Java.net please let us help you on March 5th!
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ----------------------------------------------------------
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Java.net Maven Repository Rescue Mission
Posted by Justin Edelson <ju...@gmail.com>.
On 2/25/10 10:47 AM, Jesse Farinacci wrote:
> Hi,
>
> On Thu, Feb 25, 2010 at 10:36 AM, Brian Fox <br...@infinity.nu> wrote:
>> Justin,
>> Yes we would but obviously the license on those binaries is important.
>> Some of the original binaries couldn't be redistributed which is why
>> they were pulled from central years ago.
>>
>
> Well, one thing that could be done to help this problem is to locate
> all projects which depend on the unfriendly licenses and convert them
> to use the Geronimo specification packages instead. Once those
> (superficial?) changes had been completed, there would be little
> stopping them from being deployed into Central.
Unless these artifacts are going to be deployed as javax.<something>,
this would require changing poms which have already deployed to Central:
http://repo1.maven.org/maven2/log4j/log4j/1.2.15/log4j-1.2.15.pom
There are a few open feature requests for global exclusions and artifact
replacement strategies. Those would enable the wholesale replacement of
javax for geronimo packages.
Justin
>
> Can such a query be crafted--to locate all of the projects which
> depend on Sun/Oracle javax.*?
>
> -Jesse
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Java.net Maven Repository Rescue Mission
Posted by Jesse Farinacci <ji...@gmail.com>.
Hi,
On Thu, Feb 25, 2010 at 10:36 AM, Brian Fox <br...@infinity.nu> wrote:
> Justin,
> Yes we would but obviously the license on those binaries is important.
> Some of the original binaries couldn't be redistributed which is why
> they were pulled from central years ago.
>
Well, one thing that could be done to help this problem is to locate
all projects which depend on the unfriendly licenses and convert them
to use the Geronimo specification packages instead. Once those
(superficial?) changes had been completed, there would be little
stopping them from being deployed into Central.
Can such a query be crafted--to locate all of the projects which
depend on Sun/Oracle javax.*?
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Java.net Maven Repository Rescue Mission
Posted by Brian Fox <br...@infinity.nu>.
Justin,
Yes we would but obviously the license on those binaries is important.
Some of the original binaries couldn't be redistributed which is why
they were pulled from central years ago.
On Thu, Feb 25, 2010 at 10:28 AM, Justin Edelson
<ju...@gmail.com> wrote:
> Jason-
> As I commented on your blog entry, what I think would be most useful is
> to handle the currently deployed javax.* artifacts. Don't get me wrong,
> dealing with the current/new releases will be helpful.
>
> Would Sonatype be willing to accept a list of artifact submissions from
> the community and then proactively work with the responsible project teams?
>
> For anyone running an caching MRM, it should be trivial to look in the
> cache for the java.net repo. Culling this list should be fairly straight
> forward.
>
> If the goal is to eliminiate (not just reduce) the dependency on the
> java.net repo, I'm pretty sure something like the above will need to be
> done.
>
> Justin
>
>
>
> On 2/25/10 10:15 AM, Jason van Zyl wrote:
>> As Maven users if you care about the quality of the Maven Repositories at Java.net then please help support us in our effort to get Snorcle to help fix the situation.
>>
>> Sonatype is going to try and help by dedicating staff on March 5th to help Java.net projects transition over to a healthy Maven repository infrastructure:
>>
>> http://www.sonatype.com/people/2010/02/java-net-maven-repository-rescue-mission-on-march-5th/
>>
>> We already have support from Jean-Francois Arcand:
>>
>> http://weblogs.java.net/blog/jfarcand/archive/2010/02/25/pain-over-javanets-maven-artifacts
>>
>> Please show your support by voting on the DZone article here, which seems to draw attention:
>>
>> http://www.dzone.com/links/javanet_maven_repository_rescue_mission_on_march.html
>>
>> It's all about visibility and if we have enough users in the Maven community raise this as a concern then maybe we'll get somewhere this time.
>>
>> And if you're a project at Java.net please let us help you on March 5th!
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Java.net Maven Repository Rescue Mission
Posted by Justin Edelson <ju...@gmail.com>.
Jason-
As I commented on your blog entry, what I think would be most useful is
to handle the currently deployed javax.* artifacts. Don't get me wrong,
dealing with the current/new releases will be helpful.
Would Sonatype be willing to accept a list of artifact submissions from
the community and then proactively work with the responsible project teams?
For anyone running an caching MRM, it should be trivial to look in the
cache for the java.net repo. Culling this list should be fairly straight
forward.
If the goal is to eliminiate (not just reduce) the dependency on the
java.net repo, I'm pretty sure something like the above will need to be
done.
Justin
On 2/25/10 10:15 AM, Jason van Zyl wrote:
> As Maven users if you care about the quality of the Maven Repositories at Java.net then please help support us in our effort to get Snorcle to help fix the situation.
>
> Sonatype is going to try and help by dedicating staff on March 5th to help Java.net projects transition over to a healthy Maven repository infrastructure:
>
> http://www.sonatype.com/people/2010/02/java-net-maven-repository-rescue-mission-on-march-5th/
>
> We already have support from Jean-Francois Arcand:
>
> http://weblogs.java.net/blog/jfarcand/archive/2010/02/25/pain-over-javanets-maven-artifacts
>
> Please show your support by voting on the DZone article here, which seems to draw attention:
>
> http://www.dzone.com/links/javanet_maven_repository_rescue_mission_on_march.html
>
> It's all about visibility and if we have enough users in the Maven community raise this as a concern then maybe we'll get somewhere this time.
>
> And if you're a project at Java.net please let us help you on March 5th!
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org