You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Jaroslav Tulach <ja...@gmail.com> on 2016/09/28 03:13:00 UTC
Reuse Maven repository more was: Preliminary NetBeans cost findings
On sobota 24. září 2016 12:17:21 CEST, Daniel Gruno wrote:
> Certain services like the plugins hosting will rely on Legal giving the
> go-ahead for it, otherwise we'll have to find other people willing to
> host this.
Hi.
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. As such the Maven central could be a natural place to upload NetBeans
related binaries.
NetBeans already knows how to produce Maven artifacts and there is a NetBeans
Maven repository: http://bits.netbeans.org/nexus/content/groups/netbeans/
In addition to that we could modify the http://plugins.netbeans.org to be just
a catalog over bits available in Maven central.
There are also the [3rd party binaries used during NetBeans build](http://
hg.netbeans.org/binaries/) - most of them available from Maven central. I
already [created a patch](http://hg.netbeans.org/releases/rev/3178d0a561c8) to
allow such download and it seems to work.
Would downloading bits from Maven repository address the legal and
infrastructure issues?
It might, right? Legal issues of hosting bits at maven.org are probably well
understood. The storage capacity is high. Download is instant. Maven
repository is the natural storage for Apache projects. If my observations are
true, let's start of modifying NetBeans to use Maven central more.
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 was: Preliminary NetBeans cost findings
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Sep 28, 2016 at 5:13 AM, Jaroslav Tulach
<ja...@gmail.com> wrote:
> There are also the [3rd party binaries used during NetBeans build](http://
> hg.netbeans.org/binaries/) - most of them available from Maven central. I
> already [created a patch](http://hg.netbeans.org/releases/rev/3178d0a561c8) to
> allow such download and it seems to work.
Depends on the license. That should certainly do for GPL'ed artifacts.
I don't foresee cases like Oracle JDBC Drivers, or the like.
Jochen
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reuse Maven repository more
Posted by 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
Re: Reuse Maven repository more
Posted by 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 was: Preliminary NetBeans cost findings
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Sep 28, 2016 at 12:56 PM, Wade Chandler
<co...@wadechandler.com> wrote:
> ...more later when we get to an incubator...
+1
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Reuse Maven repository more was: Preliminary NetBeans cost findings
Posted by Wade Chandler <co...@wadechandler.com>.
On Sep 28, 2016 5:55 AM, "Sven Reimers" <sv...@gmail.com> wrote:
>
>
> 2. Use Maven repository as storahe backend for the plugin portal, so that
> only the metadata is hosted at the portal not the module binaries..
>
I think the terminology here is key. A "storage backend" for plugins.n.o.
Thus the current UI continues to work for users who are not perhaps self
hosting their plugins or building them to mvn central. I think plugins.n.o
can then be changed to support artifact coordinates as well, then plugin
authors can register them in multiple ways, and one of them upload and the
other meta-data plus coordinates. It could be future wise an archive type
could be uploaded to house all that extra plugin information or may already
be in the plugin itself...outside of screen shots, then then portal could
take only coordinate references without a version and automatically
reference the various versions over time, and be mostly automatic. We could
even drive more of this from DOAP registration (an Apache thing for those
who don't know) https://projects.apache.org/doap.html. Anyways, more later
when we get to an incubator.
Thanks
Wade
Re: Reuse Maven repository more was: Preliminary NetBeans cost findings
Posted by Sven Reimers <sv...@gmail.com>.
Hi,
if I understood Jaroslav correct he is proposing two changes
1. Download 3rd party binaries needed to build NetBeans from a maven
repository (maven central, jcenter or if you behinf corporate firewalls a
synced self hosted repo using nexus or artifactory)
2. Use Maven repository as storahe backend for the plugin portal, so that
only the metadata is hosted at the portal not the module binaries..
Both ideas seem to be really good enhancements to the way this works now!
Thanks Jaroslav for the great idea and support
Sven
Am 28.09.2016 11:25 schrieb "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)
>
> Cheers,
> -g
>
Re: Reuse Maven repository more was: Preliminary NetBeans cost findings
Posted by 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)
Cheers,
-g
Re: Reuse Maven repository more was: Preliminary NetBeans cost findings
Posted by Geertjan Wielenga <ge...@googlemail.com>.
This would be brilliant. Make it happen!
Gj
On Wednesday, September 28, 2016, Jaroslav Tulach <ja...@gmail.com>
wrote:
> On sobota 24. září 2016 12:17:21 CEST, Daniel Gruno wrote:
> > Certain services like the plugins hosting will rely on Legal giving the
> > go-ahead for it, otherwise we'll have to find other people willing to
> > host this.
>
> Hi.
> 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. As such the Maven central could be a natural place to upload
> NetBeans
> related binaries.
>
> NetBeans already knows how to produce Maven artifacts and there is a
> NetBeans
> Maven repository: http://bits.netbeans.org/nexus/content/groups/netbeans/
>
> In addition to that we could modify the http://plugins.netbeans.org to be
> just
> a catalog over bits available in Maven central.
>
> There are also the [3rd party binaries used during NetBeans build](http://
> hg.netbeans.org/binaries/) - most of them available from Maven central. I
> already [created a patch](http://hg.netbeans.org/releases/rev/3178d0a561c8)
> to
> allow such download and it seems to work.
>
> Would downloading bits from Maven repository address the legal and
> infrastructure issues?
>
> It might, right? Legal issues of hosting bits at maven.org are probably
> well
> understood. The storage capacity is high. Download is instant. Maven
> repository is the natural storage for Apache projects. If my observations
> are
> true, let's start of modifying NetBeans to use Maven central more.
>
> 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:;>
>
>