On 2016-09-14 17:14, David Nalley wrote:
On Wed, Sep 14, 2016 at 9:10 AM, Bertrand Delacretaz
<bdelacre...@apache.org> wrote:
Hi,
On Wed, Sep 14, 2016 at 2:57 PM, Geertjan Wielenga
<geertjan.wiele...@googlemail.com> wrote:
...there is no code on plugins.netbeans.org at all. No one can donate
any code from anywhere on plugins.netbeans.org to anyone else. It simply
contains binaries...
Thanks for the clarification.
This confirms my view, I don't think we should make hosting
plugins.netbeans.org part of the incubation plan. That hosting might
happen later, separately, but it's IMO not a condition for a
successful move of NetBeans to Apache and much better discussed
separately, once the project starts.
-Bertrand
While it may not be a requirement to enter incubation, I do want us to
understand plugins.netbeans.org (and any other pieces of their
infrastructure) I admit it's been some years since I have used
Netbeans in anger, but plugins are (or were) pretty important to the
user community. I don't want us to defer the discussion for it to come
back some years down the road, especially for something that I
perceive is important for the user community.
I just created an account on netbeans.org to get an understanding what
plugins.netbeans.org 'portal' provides.
AFAICT it provides 4 main features, see [1] and [2]:
- register a plugin 'advertisement', meaning plugin documentation
is provided through the plugins portal, which can include a link where
users can find and download the plugin elsewhere.
(note: I couldn't find an example nor can you specifically query on this)
- register *and* upload a plugin which then can be downloaded
from the plugin portal itself
- "Plugin Update Center" service through which plugins hosted by the portal
which also are verified against some criteria, are accessible and downloadable
from within Netbeans itself.
- a backend database / CMS to store and manage above metadata, as well as a
frontend web application for managing and accessing this.
Now, considering the above features the following idea is just a 'thinking out
loud' brain fart for a possible solution which might make it feasible
to host a Netbeans plugin portal by Apache itself, if:
- It can/will use/support external hosting of 3rd party plugins (binaries).
For example as Maven artifact at Maven Central.
But Netbeans project provided/verified plugins could be hosted at Apache.
- It just stores and provides editing capability for the meta-data concerning
the plugins. This might even be stored 'statically', e.g. as plain text or
json, or whatever, and even in a SCM if so desired.
- It provides a specialized 'CMS' to allow (registered) end-users to add and
maintain their own plugin documentation. Again, this content might be
stored and served 'statically', kind of similar as we do for the Apache CMS.
- It probably needs to support a separate 'end user' database and account
management, maybe similar to what we use for MoinMoin today (file based)?
- Finally, the "Plugin Update Center" likewise could be a lightweight
'service' just querying the already statically made available meta-data.
It would be a major benefit if something like this can make it feasible to host
(only) the portal and its meta-data at Apache, thereby ensuring control and
oversight by the Netbeans project itself.
That way there is no need to 'license' the Netbeans plugins management to a
third party and have them administer it, like in the case of Maven Central as
David explained below.
Of course, externally hosted plugin binaries still remain external.
But verified Apache compliant plugins could be hosted at Apache itself.
As well as clearly marked in the plugin portal as such, further strengthening
the project and community binding at Apache.
Ate
[1] http://wiki.netbeans.org/FaqPluginAdd
[2] http://wiki.netbeans.org/FaqPluginUpdateCenter
I think this is similar to Maven Central - yes, we license maven
central to a third party and they administer the service. However, if
the time comes that either Sonatype or the PMC kill that off, Maven
Central can't just 'go away' - either a second third-party would have
to come in, or the ASF will have to bear the responsibility. So even
if someone else is licensed the ability to run plugins.netbeans.org -
we need to understand the responsibilities, as it may come home to
roost.[1]
--David
[1] http://idioms.thefreedictionary.com/come+home+to+roost - My
apologies for the idiom.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
