Re: Reuse Maven repository more

[Jaroslav Tulach <ja...@gmail.com>]

28. 9. 2016 v 11:25, Greg Stein <gs...@gmail.com>:

> On Tue, Sep 27, 2016 at 10:13 PM, Jaroslav Tulach <jaroslav.tulach@gmail.com
>> wrote:
>> ...
> 
>> One idea that keeps puzzling in my mind is to reuse central Maven
>> repository
>> more than we used to. If I understand correctly while the Maven central is
>> operated by Sonatype, it is just "leased" to them and still oversight by
>> Apache.
> 
> 
> Not so much. We license the "Apache Maven" trademark to them, to provide a
> fantastic service to the Maven community. But Maven Central is *all*
> Sonatype, and the ASF generally just provides oversight over trademark use
> (rather than operation).
> 
> To state things another way: the ASF has zero control over what goes onto
> their platform. Shoot, we have a copy of the software which runs Maven
> Central, but it is proprietary and we merely hold a license to run it. This
> isn't pillows and unicorns. You will need to make a business case with
> Sonatype to include stuff beyond artifacts that Apache Maven can consume
> from their repository.
> 
> (that is my reasonably-informed understanding; a discussion with Sonatype
> and the Apache Maven PMC is your best bet)

Thanks Greg for your answer.

On one side of my proposal is cost control for Apache foundation. By reusing infrastructure that already exists and is (has to be as the trademark is owned by the foundation) friendly, we can eliminate the load for extra services (http://plugins.netbeans.org) NetBeans currently has. I don't think the increase of the load is going to be any significant - the amounts of downloads Apache Maven central has to handle is way bigger than NetBeans needs, I assume.

Simplification of the build infrastructure is the other goal. If we use only the bits on the Apache Maven central, then we don't need any special support infrastructure (http://hg.netbeans.org/binaries). That requires a bit of work, but again it could help Apache control the cost of adopting NetBeans.

The last side is related to legal issues. Any infrastructure that helps to distribute 3rd party code is troublesome: viruses, malware, spyware, etc. By reusing the same infrastructure as Apache Maven, we align NetBeans with existing Apache approved solution. Apache NetBeans would only download what Apache Maven can - e.g. The risk of using NetBeans would be the same as using Maven. In my view, this should make the foundation OK with distributing such software like NetBeans.

I agree with Wade, that all such changes should only happen when NetBeans is accepted for the incubation phase. The only reason of my proposal is to show that we don't have "insolvable issues". We may have challenging ones, but I am sure, we can solve all of them.

Jaroslav Tulach
NetBeans Platform Architect





---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Reuse Maven repository more

[Stephen Connolly <st...@gmail.com>]

On Friday 30 September 2016, Jaroslav Tulach <ja...@gmail.com>
wrote:

> 28. 9. 2016 v 11:25, Greg Stein <gstein@gmail.com <javascript:;>>:
>
> > On Tue, Sep 27, 2016 at 10:13 PM, Jaroslav Tulach <
> jaroslav.tulach@gmail.com <javascript:;>
> >> wrote:
> >> ...
> >
> >> One idea that keeps puzzling in my mind is to reuse central Maven
> >> repository
> >> more than we used to. If I understand correctly while the Maven central
> is
> >> operated by Sonatype, it is just "leased" to them and still oversight by
> >> Apache.
> >
> >
> > Not so much. We license the "Apache Maven" trademark to them, to provide
> a
> > fantastic service to the Maven community. But Maven Central is *all*
> > Sonatype, and the ASF generally just provides oversight over trademark
> use
> > (rather than operation).
> >
> > To state things another way: the ASF has zero control over what goes onto
> > their platform. Shoot, we have a copy of the software which runs Maven
> > Central, but it is proprietary and we merely hold a license to run it.
> This
> > isn't pillows and unicorns. You will need to make a business case with
> > Sonatype to include stuff beyond artifacts that Apache Maven can consume
> > from their repository.
> >
> > (that is my reasonably-informed understanding; a discussion with Sonatype
> > and the Apache Maven PMC is your best bet)


Not quite true.

Sonatype is running the active hosting of central, but there are
full mirrors of the content that are kept live (modulo a few hours for some
to a few days/weeks for others).

The URL that maven distos now point to is an apache.org URL rather than the
maven.org URL. If there were an issue with the current sonatype provided
service, we *could* switch to the apache mirror hosting on and change the
DNS entry.

The value sonatype currently provides is the artifact on-ramp (aside from
covering the bandwidth charges)

Previously there was a long complex set of rsync rules to pull content from
various sources. That has by and large been replaced by Sonatype Nexus and
some Mexus federation "magic".

We probably could get Artifactory to a place where it could perform the
same functionality but currently there is a gap...

Having said that, I think we are happy with the Sonatype service.


> Thanks Greg for your answer.
>
> On one side of my proposal is cost control for Apache foundation. By
> reusing infrastructure that already exists and is (has to be as the
> trademark is owned by the foundation) friendly, we can eliminate the load
> for extra services (http://plugins.netbeans.org) NetBeans currently has.
> I don't think the increase of the load is going to be any significant - the
> amounts of downloads Apache Maven central has to handle is way bigger than
> NetBeans needs, I assume.


Yeah but you'd want to check with Sonatype before adding that load onto
Central first...

The internal copy of Nexus that hosts repository.apache.org is probably not
sized to handle the netbeans load. Rather it is sized to handle the
deployment be developers, occasional downloads by PMCs testing artifacts
being voted on and the sync to central.


>
> Simplification of the build infrastructure is the other goal. If we use
> only the bits on the Apache Maven central, then we don't need any special
> support infrastructure (http://hg.netbeans.org/binaries). That requires a
> bit of work, but again it could help Apache control the cost of adopting
> NetBeans.


For building netbeans, yes you want to go that route.


>
> The last side is related to legal issues. Any infrastructure that helps to
> distribute 3rd party code is troublesome: viruses, malware, spyware, etc.
> By reusing the same infrastructure as Apache Maven, we align NetBeans with
> existing Apache approved solution. Apache NetBeans would only download what
> Apache Maven can - e.g. The risk of using NetBeans would be the same as
> using Maven. In my view, this should make the foundation OK with
> distributing such software like NetBeans.
>
> I agree with Wade, that all such changes should only happen when NetBeans
> is accepted for the incubation phase. The only reason of my proposal is to
> show that we don't have "insolvable issues". We may have challenging ones,
> but I am sure, we can solve all of them.
>
> Jaroslav Tulach
> NetBeans Platform Architect
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <javascript:;>
> For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
>
>

-- 
Sent from my phone