You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Christian Lenz <ch...@gmx.net> on 2018/05/28 08:33:38 UTC
Contrib repo & Community Plugin Repo
Hey Devs,
long time ago, there was mail thread (private) with Geertjan and a guy who created an „organization“ on GitHub for NetBeans Plugins, where I wanted to join and added all of my plugins to this repo, to have it under a global, public (official) repo for NetBeans. I don’t know what happened, I couldn’t figure out the guy who created it, maybe have a look into my mails.
Anyway, the Thing is that it doesn’t work out, maybe lack of time, only one person was responsible for this or whatever. So why I wanted to bring this up again is, that in my opinion, it would be nice if we can have a GitHub repo/organization (Maybe Apache/NetBeans-Plugins) where we can add all of our 3rd-party-plugins, which are not part of the core and/or a contrib repo again or whatever. I don’t know the history of the contrib repo anymore, since we don’t have it atm?
I don’t know how the contrib repo was handled, but afaik, Maybe we don’t Need it anymore or so? The contrib repo still exists with a lot of features (some are old, some are strill working) who are still not part of the core but part of a Plugin but to add it, you have to add the contrib repo as a dependency to the Plugins section.
So what do you think, do we still need a contrib repo? If yes, how could it be handled? As a GitHub or Apache git repo with a GitHub Mirror? Should we have an official Apache/netbeans-plugins repo like JetBrains have it for there community Plugins? https://github.com/JetBrains/intellij-plugins
Thread is kind of brainstorming.
Cheers
Chris
Re: [MENTORS] Re: Contrib repo & Community Plugin Repo
Posted by Daniel Gruno <hu...@apache.org>.
On 07/26/2018 07:49 PM, Antonio wrote:
>
>
> El 26/07/2018 a las 9:55, Bertrand Delacretaz escribió:
>> Hi,
>>
>> On Wed, Jul 25, 2018 at 7:58 PM Antonio <an...@vieiro.net> wrote:
>>> ... I've raised the [MENTORS] flag with two kind requests for
>>> clarification :-)...
>>
>> I'm not sure what you are asking exactly, can you reformulate? Or
>> start new threads for clarity.
>
> Apologies for not being clear.
>
> Would it be possible for the Apache NetBeans (Incubating) to create a
> website similar to https://extensions.openoffice.org?
>
> More specifically, would it be possible o create a website:
>
> 1. Where companies and individuals can announce their plugins (released
> under any sort of license, even proprietary).
> 2. That has some sort of "voting" mechanism (requires user log-in stuff,
> a database to hold votes).
> 3. That contains links to executables hosted elsewhere.
With the proper caveats and notices, sure. We'd have to build it
ourselves, but we could get a machine for it, if we sought a budget.
We had something like this for the http server (modules.apache.org),
though that was discontinued due to severe spam.
>
> Thanks,
> Antonio
>
>>
>> -Bertrand
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [MENTORS] Re: Contrib repo & Community Plugin Repo
Posted by Antonio <an...@vieiro.net>.
El 26/07/2018 a las 9:55, Bertrand Delacretaz escribió:
> Hi,
>
> On Wed, Jul 25, 2018 at 7:58 PM Antonio <an...@vieiro.net> wrote:
>> ... I've raised the [MENTORS] flag with two kind requests for clarification :-)...
>
> I'm not sure what you are asking exactly, can you reformulate? Or
> start new threads for clarity.
Apologies for not being clear.
Would it be possible for the Apache NetBeans (Incubating) to create a
website similar to https://extensions.openoffice.org?
More specifically, would it be possible o create a website:
1. Where companies and individuals can announce their plugins (released
under any sort of license, even proprietary).
2. That has some sort of "voting" mechanism (requires user log-in stuff,
a database to hold votes).
3. That contains links to executables hosted elsewhere.
Thanks,
Antonio
>
> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: [MENTORS] Re: Contrib repo & Community Plugin Repo
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Jul 25, 2018 at 7:58 PM Antonio <an...@vieiro.net> wrote:
>... I've raised the [MENTORS] flag with two kind requests for clarification :-)...
I'm not sure what you are asking exactly, can you reformulate? Or
start new threads for clarity.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[MENTORS] Re: Contrib repo & Community Plugin Repo
Posted by Antonio <an...@vieiro.net>.
On 28/05/18 16:50, Emilian Bold wrote:
> [...]
> Apache OpenOffice has https://extensions.openoffice.org and https://templates.openoffice.org but I don't know how it works out from a hosting / licensing perspective.
Tried out that one. Some comments:
a) There are commercial products there:
https://extensions.openoffice.org/en/project/business-box#releases
(i.e., without any open source code, so no APLv2 nor GPL licenses: plain
proprietary)
b) The download link seems to be from Apache, as in...
https://extensions.openoffice.org/en/download/3996
...but is then redirected to a proprietary page...
< HTTP/1.1 302 Found
< Server: nginx/1.13.12
< Date: Wed, 25 Jul 2018 17:51:43 GMT
< Content-Type: text/html
< Content-Length: 0
< Connection: keep-alive
< Vary: Host,X-Forwarded-Proto
< Expires: Sun, 19 Nov 1978 05:00:00 GMT
< Cache-Control: no-cache, must-revalidate
< X-Content-Type-Options: nosniff
< Location: http://www.biztree.com/dist/business-in-a-box_setup.exe
< X-From: sfp-aoo-web-3
< Vary: Accept-Encoding
c) A similar website would be good enough for publishing people's
plugins, but I think we can do better with a Swing GUI and some simple
XML files. Of course we should inform the user about third-party plugins
on their own risk, etc.
So, to summarize: if "Apache OpenOffice" can do that (redirect to
proprietary plugins without source code) I imagine that "Apache
NetBeans" can do it also.
The difference being that we are "Apache NetBeans (incubating)", i.e.,
we're not yet an official Apache Project but an Apache Incubator Project.
So maybe we should try harder to become an official Apache Project?
>
> We should be able to point out some quality plugins, somehow... Maybe mentors could clear up?
>
> --emi
>
I've raised the [MENTORS] flag with two kind requests for clarification :-)
Thanks, mentors!
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Contrib repo & Community Plugin Repo
Posted by Wade Chandler <wa...@apache.org>.
On May 28, 2018, at 10:50 AM, Emilian Bold <em...@protonmail.ch> wrote:
>
> I don't think under Apache we will be able to have a NetBeans-endorsed collection of 3rd party plugins.
>
> Clearly we won't be able to host them, but I'm not ever certain we could attach the NetBeans (and Apache) brand to a repository of code we don't really control or oversee much.
>
We can’t. However, we can certainly have the IDE download plugins per the users directions, and I think the plugin portal needs to be more flexible in that it pulls releases from the authors release locations (just a binary), and have better schemes for contributing and validating download sources, and making that safe.
> I believe we could have some plugins that become NetBeans sub-projects if the authors donate them and relicense them under the Apache license and users might optionally install them.
>
Agreed.
>
> We should be able to point out some quality plugins, somehow... Maybe mentors could clear up?
>
We can certainly reference other projects from our documentation if other projects are precedent: http://groovy-lang.org/ecosystem.html <http://groovy-lang.org/ecosystem.html>
The plugin portal also offers an opportunity for this.
Wade
Re: Contrib repo & Community Plugin Repo
Posted by Emilian Bold <em...@protonmail.ch>.
I don't think under Apache we will be able to have a NetBeans-endorsed collection of 3rd party plugins.
Clearly we won't be able to host them, but I'm not ever certain we could attach the NetBeans (and Apache) brand to a repository of code we don't really control or oversee much.
I believe we could have some plugins that become NetBeans sub-projects if the authors donate them and relicense them under the Apache license and users might optionally install them.
Apache OpenOffice has https://extensions.openoffice.org and https://templates.openoffice.org but I don't know how it works out from a hosting / licensing perspective.
We should be able to point out some quality plugins, somehow... Maybe mentors could clear up?
--emi
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On 28 May 2018 11:33 AM, Christian Lenz <ch...@gmx.net> wrote:
> Hey Devs,
>
> long time ago, there was mail thread (private) with Geertjan and a guy who created an „organization“ on GitHub for NetBeans Plugins, where I wanted to join and added all of my plugins to this repo, to have it under a global, public (official) repo for NetBeans. I don’t know what happened, I couldn’t figure out the guy who created it, maybe have a look into my mails.
>
> Anyway, the Thing is that it doesn’t work out, maybe lack of time, only one person was responsible for this or whatever. So why I wanted to bring this up again is, that in my opinion, it would be nice if we can have a GitHub repo/organization (Maybe Apache/NetBeans-Plugins) where we can add all of our 3rd-party-plugins, which are not part of the core and/or a contrib repo again or whatever. I don’t know the history of the contrib repo anymore, since we don’t have it atm?
>
> I don’t know how the contrib repo was handled, but afaik, Maybe we don’t Need it anymore or so? The contrib repo still exists with a lot of features (some are old, some are strill working) who are still not part of the core but part of a Plugin but to add it, you have to add the contrib repo as a dependency to the Plugins section.
>
> So what do you think, do we still need a contrib repo? If yes, how could it be handled? As a GitHub or Apache git repo with a GitHub Mirror? Should we have an official Apache/netbeans-plugins repo like JetBrains have it for there community Plugins? https://github.com/JetBrains/intellij-plugins
>
> Thread is kind of brainstorming.
>
> Cheers
>
> Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Contrib repo & Community Plugin Repo
Posted by Geertjan Wielenga <ge...@googlemail.com>.
I like the idea. Good plan.
Gj
On Monday, May 28, 2018, Christian Lenz <ch...@gmx.net> wrote:
> Hey Devs,
>
> long time ago, there was mail thread (private) with Geertjan and a guy who
> created an „organization“ on GitHub for NetBeans Plugins, where I wanted to
> join and added all of my plugins to this repo, to have it under a global,
> public (official) repo for NetBeans. I don’t know what happened, I couldn’t
> figure out the guy who created it, maybe have a look into my mails.
>
> Anyway, the Thing is that it doesn’t work out, maybe lack of time, only
> one person was responsible for this or whatever. So why I wanted to bring
> this up again is, that in my opinion, it would be nice if we can have a
> GitHub repo/organization (Maybe Apache/NetBeans-Plugins) where we can add
> all of our 3rd-party-plugins, which are not part of the core and/or a
> contrib repo again or whatever. I don’t know the history of the contrib
> repo anymore, since we don’t have it atm?
>
> I don’t know how the contrib repo was handled, but afaik, Maybe we don’t
> Need it anymore or so? The contrib repo still exists with a lot of features
> (some are old, some are strill working) who are still not part of the core
> but part of a Plugin but to add it, you have to add the contrib repo as a
> dependency to the Plugins section.
>
> So what do you think, do we still need a contrib repo? If yes, how could
> it be handled? As a GitHub or Apache git repo with a GitHub Mirror? Should
> we have an official Apache/netbeans-plugins repo like JetBrains have it for
> there community Plugins? https://github.com/JetBrains/intellij-plugins
>
> Thread is kind of brainstorming.
>
>
> Cheers
>
> Chris
>
Re: Contrib repo & Community Plugin Repo
Posted by Tim Boudreau <ni...@gmail.com>.
On Wed, Jul 25, 2018 at 1:11 PM Emilian Bold
<em...@protonmail.ch.invalid> wrote:
> I think C++ is much more important.
>
+1. *That* contrib will get handled is more important than that it happen
immediately (nice as that would be).
-Tim
Re: Contrib repo & Community Plugin Repo
Posted by Emilian Bold <em...@protonmail.ch.INVALID>.
I think C++ is much more important.
--emi
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On 25 July 2018 3:17 PM, Geertjan Wielenga <ge...@googlemail.com.INVALID> wrote:
> On Wed, Jul 25, 2018 at 11:13 AM, Tim Boudreau niftiness@gmail.com wrote:
>
> > > Resurrecting this thread, since Tim Boudreau recently Mavenized the
> > > contrib repo:
> > > https://github.com/timboudreau/netbeans-contrib
> >
> > I sent a note to this list about that on Monday, but got no response at
> > all. Wondering if it went into a black hole, or nobody cares :-)
> >
> > > The Mavenization is certainly welcome (to me at least!) but someone
> > > needs to officially decide what to do with all that stuff.
> >
> > Agreed. I hadn't seen any specific proposal, so I figured I'd do
> > something since contrib/ still contains things I rely on daily.
> > So here's a proposal:
> >
> > 1. The big, critical thing that needs to happen is for Oracle to
> > relicense this code to Apache license, the same as NetBeans. Everything in
> > there was contributed under a contributor agreement that assigns joint
> > copyright ownership to Oracle nee Sun. So, Oracle is the one party that
> > can do that for everything - former Oracle employees can't even relicense
> > their own code, since it was work-for-hire and only external contributors
> > hold joint copyright. Geertjan, can you make that happen?
> >
>
> Yes, there's no question or discussion about this at all. It will happen.
>
> We maybe should bump this up before the current plan for the 4th donation,
> which is focused on C/C++. I think we should prioritize 'contrib' over that.
>
> Gj
>
> > 2. I agree with Jesse that the things that are actively maintained there
> > should probably find separate homes on Github or wherever their maintainers
> > want. In the meantime, I'm happy to babysit the repo while that happens
> > (likely it can't happen until 1. is done).
> >
> >
> > So what I'd suggest is that Geertjan (or whatever Oracle employee is
> > empowered to do it) fork the repo, change the license headers (scriptable,
> > not hard), and - depending on who wants it long-term - either send me a
> > pull request, or if the Apache organization wants to own it going forward,
> > I can retire this repo.
> >
> > 3. In the meantime, if anyone has stuff they want to work on in there, I'm
> > happy to add anybody who wants as a collaborator or accept pull requests,
> > or whatever works for folks - until the licensing is straightened out and
> > things can find their own homes, it's probably best for there to be one
> > repository of record.
> >
> > 4. Distributing things: I have a temporary plan for this: Set up a
> > continuous build of the whole enchilada on my Jenkins server, and dump all
> > the modules of a separate instance of
> > https://github.com/timboudreau/meta-update-center - all the build has to
> > do
> > is dump the contents into a folder it's watching, and updates will show
> > up. It's a tiny, lightweight update center server - example here
> > https://timboudreau.com/modules - no user rankings or frilly UI (could be
> > added if someone were ambitious), but it does what it does with zero
> > headaches.
> >
> >
> > I'll probably get to that next week - I'm replacing my server on Friday
> > with a 72Gb box, so since I've migrated all of the VMs, I'm not making
> > major changes on the old machine this week as I'd have to replicate them.
> >
> > 5. Longer term...
> >
> > A. There should probably a continuous build of this stuff somewhere else
> > (Apache? Something else?), which interested module owners can add jobs to,
> > with the same sort of automated distribution (Jenkins publishes nbms,
> > meta-update-center polls the URL of the built NBM and automatically updates
> > if the Last-Modified header has changed) - so there remains some kind of
> > one-stop-shopping for community modules. I was never a huge fan of the
> > plugin portal's model for how developers use it, since you had to go and
> > manually update it - that's actually what inspired me to write
> > meta-update-center. So you set up Jenkins to build a "stable" branch, and
> > that gets distributed automagically whenever you push to it.
> > B. Need a way to flag stuff in contrib as clearly junk, because some of it
> > is. We could just nuke stuff, or remove it from the master POM, but at the
> > moment that's also serving as the notes for what needs fixing, so I'm not
> > dying to mix concerns there, and probably shouldn't take a chainsaw to
> > stuff until the relicensing is done or that will complicate things.
> > C. Something fancier could and probably should be done for distribution
> > long-term. I can contribute hosting of some stuff for now, but I barter
> > hosting a local TV station's streaming video server on that box for free
> > commercial-grade bandwidth, and I've had situations where Comcast techs
> > came in and screwed with the network configuration and I had to go figure
> > out what they'd done and fix it. So we're talking 95% uptime, but not five
> > nines. It will do for getting things going, though.
> > Thoughts?
> > -Tim
> >
> > > Probably
> > > all the live modules or logical module groups (those active on the
> > > Plugin Portal) should each get their own GH repo somewhere—does not
> > > make sense to shove them all into one repo. And then how do bits get
> > > distributed to users? I am not sure what happened to deadlock and its
> > > CI job for contrib modules. Plugin Portal still seems to be alive but
> > > what is its future? Of
> > > http://plugins.netbeans.org/my-plugins
> > > there are a number of plugins I would like to keep running and
> > > available; some were already being maintained on GitHub, but some
> > > (notably quickfilechooser) were not.
> > >
> > > To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> > > For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
> > > For further information about the NetBeans mailing lists, visit:
> > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> > --
> > http://timboudreau.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
***UNCHECKED*** Re: Contrib repo & Community Plugin Repo
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
On Wed, Jul 25, 2018 at 6:06 PM, Tim Boudreau <ni...@gmail.com> wrote:
> On Wed, Jul 25, 2018 at 8:34 AM Geertjan Wielenga
> <ge...@googlemail.com.invalid> wrote:
>
> > PS: Just for the record, Oracle doesn't relicense anything at all to
> > Apache. Instead, Oracle donates code to Apache, and we together, here in
> > Apache NetBeans community, do the relicensing.
>
>
> Great. So what will it take to make that happen for contrib?
>
It's already been explained -- first Oracle will donate the code to Apache,
then we together as a community will relicense that code to Apache, just as
we did for the 1st donation.
Gj
>
> -Tim
>
>
> > --
> http://timboudreau.com
>
Re: Contrib repo & Community Plugin Repo
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi Tim,
Am Mittwoch, den 25.07.2018, 12:06 -0400 schrieb Tim Boudreau:
> On Wed, Jul 25, 2018 at 8:34 AM Geertjan Wielenga
> <ge...@googlemail.com.invalid> wrote:
>
> > PS: Just for the record, Oracle doesn't relicense anything at all
> > to
> > Apache. Instead, Oracle donates code to Apache, and we together,
> > here in
> > Apache NetBeans community, do the relicensing.
>
>
> Great. So what will it take to make that happen for contrib?
be patient :-)
Here is the outline from the start:
https://cwiki.apache.org/confluence/display/NETBEANS/Apache+Transition
See: "Proposed NetBeans Incubation Milestones", Pint 5.e.v. is done
contrib is explicitly mentioned. 9.0 is being released, I see a lot of
work to work through the modules donated via 5.e. (see the 2ndDonation
branch). The same as happend for the current code has to happen for the
code mentioned in 5.e, 5.g and 5.h (contrib is there).
Maybe that helps.
Matthias, not working for oracle, but knowing corporate processes...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Contrib repo & Community Plugin Repo
Posted by Tim Boudreau <ni...@gmail.com>.
On Wed, Jul 25, 2018 at 8:34 AM Geertjan Wielenga
<ge...@googlemail.com.invalid> wrote:
> PS: Just for the record, Oracle doesn't relicense anything at all to
> Apache. Instead, Oracle donates code to Apache, and we together, here in
> Apache NetBeans community, do the relicensing.
Great. So what will it take to make that happen for contrib?
-Tim
> --
http://timboudreau.com
Re: Contrib repo & Community Plugin Repo
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
PS: Just for the record, Oracle doesn't relicense anything at all to
Apache. Instead, Oracle donates code to Apache, and we together, here in
Apache NetBeans community, do the relicensing.
Gj
On Wed, Jul 25, 2018 at 2:17 PM, Geertjan Wielenga <
geertjan.wielenga@googlemail.com> wrote:
>
>
> On Wed, Jul 25, 2018 at 11:13 AM, Tim Boudreau <ni...@gmail.com>
> wrote:
>
>> >
>> > Resurrecting this thread, since Tim Boudreau recently Mavenized the
>> > contrib repo:
>> >
>> > https://github.com/timboudreau/netbeans-contrib
>>
>>
>> I sent a note to this list about that on Monday, but got no response at
>> all. Wondering if it went into a black hole, or nobody cares :-)
>>
>>
>> > The Mavenization is certainly welcome (to me at least!) but someone
>> > needs to officially decide what to *do* with all that stuff.
>>
>>
>> Agreed. I hadn't seen any specific proposal, so I figured I'd do
>> *something* since contrib/ still contains things I rely on daily.
>>
>> So here's a proposal:
>>
>> 1. The *big, critical thing that needs to happen* is for Oracle to
>> relicense this code to Apache license, the same as NetBeans. Everything
>> in
>> there was contributed under a contributor agreement that assigns joint
>> copyright ownership to Oracle nee Sun. So, Oracle is the one party that
>> can do that for everything - former Oracle employees can't even relicense
>> their own code, since it was work-for-hire and only external contributors
>> hold joint copyright. Geertjan, can you make that happen?
>>
>
>
> Yes, there's no question or discussion about this at all. It will happen.
>
> We maybe should bump this up before the current plan for the 4th donation,
> which is focused on C/C++. I think we should prioritize 'contrib' over that.
>
> Gj
>
>
>
>
>>
>> 2. I agree with Jesse that the things that are actively maintained there
>> should probably find separate homes on Github or wherever their
>> maintainers
>> want. In the meantime, I'm happy to babysit the repo while that happens
>> (likely it can't happen until 1. is done).
>>
>> So what I'd suggest is that Geertjan (or whatever Oracle employee is
>> empowered to do it) fork the repo, change the license headers (scriptable,
>> not hard), and - depending on who wants it long-term - either send me a
>> pull request, or if the Apache organization wants to own it going forward,
>> I can retire this repo.
>>
>> 3. In the meantime, if anyone has stuff they want to work on in there,
>> I'm
>> happy to add anybody who wants as a collaborator or accept pull requests,
>> or whatever works for folks - until the licensing is straightened out and
>> things can find their own homes, it's probably best for there to be one
>> repository of record.
>>
>> 4. Distributing things: I have a temporary plan for this: Set up a
>> continuous build of the whole enchilada on my Jenkins server, and dump all
>> the modules of a separate instance of
>> https://github.com/timboudreau/meta-update-center - all the build has to
>> do
>> is dump the contents into a folder it's watching, and updates will show
>> up. It's a tiny, lightweight update center server - example here
>> https://timboudreau.com/modules - no user rankings or frilly UI (could be
>> added if someone were ambitious), but it does what it does with zero
>> headaches.
>>
>> I'll probably get to that next week - I'm replacing my server on Friday
>> with a 72Gb box, so since I've migrated all of the VMs, I'm not making
>> major changes on the old machine this week as I'd have to replicate them.
>>
>> 5. Longer term...
>>
>> A. There should probably a continuous build of this stuff somewhere else
>> (Apache? Something else?), which interested module owners can add jobs to,
>> with the same sort of automated distribution (Jenkins publishes nbms,
>> meta-update-center polls the URL of the built NBM and automatically
>> updates
>> if the Last-Modified header has changed) - so there remains some kind of
>> one-stop-shopping for community modules. I was never a huge fan of the
>> plugin portal's model for how *developers* use it, since you had to go and
>> manually update it - that's actually what inspired me to write
>> meta-update-center. So you set up Jenkins to build a "stable" branch, and
>> that gets distributed automagically whenever you push to it.
>>
>> B. Need a way to flag stuff in contrib as clearly junk, because some of
>> it
>> is. We could just nuke stuff, or remove it from the master POM, but at
>> the
>> moment that's also serving as the notes for what needs fixing, so I'm not
>> dying to mix concerns there, and probably shouldn't take a chainsaw to
>> stuff until the relicensing is done or that will complicate things.
>>
>> C. Something fancier could and probably should be done for distribution
>> long-term. I can contribute hosting of some stuff for now, but I barter
>> hosting a local TV station's streaming video server on that box for free
>> commercial-grade bandwidth, and I've had situations where Comcast techs
>> came in and screwed with the network configuration and I had to go figure
>> out what they'd done and fix it. So we're talking 95% uptime, but not
>> five
>> nines. It will do for getting things going, though.
>>
>> Thoughts?
>>
>> -Tim
>>
>>
>> > Probably
>> > all the live modules or logical module groups (those active on the
>> > Plugin Portal) should each get their own GH repo somewhere—does not
>> > make sense to shove them all into one repo. And then how do bits get
>> > distributed to users? I am not sure what happened to deadlock and its
>> > CI job for contrib modules. Plugin Portal still seems to be alive but
>> > what is its future? Of
>> >
>> > http://plugins.netbeans.org/my-plugins
>> >
>> > there are a number of plugins I would like to keep running and
>> > available; some were already being maintained on GitHub, but some
>> > (notably quickfilechooser) were not.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
>> > For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>> >
>> > For further information about the NetBeans mailing lists, visit:
>> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>> >
>> >
>> >
>> >
>>
>> --
>> http://timboudreau.com
>>
>
>
Re: Contrib repo & Community Plugin Repo
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
On Wed, Jul 25, 2018 at 11:13 AM, Tim Boudreau <ni...@gmail.com> wrote:
> >
> > Resurrecting this thread, since Tim Boudreau recently Mavenized the
> > contrib repo:
> >
> > https://github.com/timboudreau/netbeans-contrib
>
>
> I sent a note to this list about that on Monday, but got no response at
> all. Wondering if it went into a black hole, or nobody cares :-)
>
>
> > The Mavenization is certainly welcome (to me at least!) but someone
> > needs to officially decide what to *do* with all that stuff.
>
>
> Agreed. I hadn't seen any specific proposal, so I figured I'd do
> *something* since contrib/ still contains things I rely on daily.
>
> So here's a proposal:
>
> 1. The *big, critical thing that needs to happen* is for Oracle to
> relicense this code to Apache license, the same as NetBeans. Everything in
> there was contributed under a contributor agreement that assigns joint
> copyright ownership to Oracle nee Sun. So, Oracle is the one party that
> can do that for everything - former Oracle employees can't even relicense
> their own code, since it was work-for-hire and only external contributors
> hold joint copyright. Geertjan, can you make that happen?
>
Yes, there's no question or discussion about this at all. It will happen.
We maybe should bump this up before the current plan for the 4th donation,
which is focused on C/C++. I think we should prioritize 'contrib' over that.
Gj
>
> 2. I agree with Jesse that the things that are actively maintained there
> should probably find separate homes on Github or wherever their maintainers
> want. In the meantime, I'm happy to babysit the repo while that happens
> (likely it can't happen until 1. is done).
>
> So what I'd suggest is that Geertjan (or whatever Oracle employee is
> empowered to do it) fork the repo, change the license headers (scriptable,
> not hard), and - depending on who wants it long-term - either send me a
> pull request, or if the Apache organization wants to own it going forward,
> I can retire this repo.
>
> 3. In the meantime, if anyone has stuff they want to work on in there, I'm
> happy to add anybody who wants as a collaborator or accept pull requests,
> or whatever works for folks - until the licensing is straightened out and
> things can find their own homes, it's probably best for there to be one
> repository of record.
>
> 4. Distributing things: I have a temporary plan for this: Set up a
> continuous build of the whole enchilada on my Jenkins server, and dump all
> the modules of a separate instance of
> https://github.com/timboudreau/meta-update-center - all the build has to
> do
> is dump the contents into a folder it's watching, and updates will show
> up. It's a tiny, lightweight update center server - example here
> https://timboudreau.com/modules - no user rankings or frilly UI (could be
> added if someone were ambitious), but it does what it does with zero
> headaches.
>
> I'll probably get to that next week - I'm replacing my server on Friday
> with a 72Gb box, so since I've migrated all of the VMs, I'm not making
> major changes on the old machine this week as I'd have to replicate them.
>
> 5. Longer term...
>
> A. There should probably a continuous build of this stuff somewhere else
> (Apache? Something else?), which interested module owners can add jobs to,
> with the same sort of automated distribution (Jenkins publishes nbms,
> meta-update-center polls the URL of the built NBM and automatically updates
> if the Last-Modified header has changed) - so there remains some kind of
> one-stop-shopping for community modules. I was never a huge fan of the
> plugin portal's model for how *developers* use it, since you had to go and
> manually update it - that's actually what inspired me to write
> meta-update-center. So you set up Jenkins to build a "stable" branch, and
> that gets distributed automagically whenever you push to it.
>
> B. Need a way to flag stuff in contrib as clearly junk, because some of it
> is. We could just nuke stuff, or remove it from the master POM, but at the
> moment that's also serving as the notes for what needs fixing, so I'm not
> dying to mix concerns there, and probably shouldn't take a chainsaw to
> stuff until the relicensing is done or that will complicate things.
>
> C. Something fancier could and probably should be done for distribution
> long-term. I can contribute hosting of some stuff for now, but I barter
> hosting a local TV station's streaming video server on that box for free
> commercial-grade bandwidth, and I've had situations where Comcast techs
> came in and screwed with the network configuration and I had to go figure
> out what they'd done and fix it. So we're talking 95% uptime, but not five
> nines. It will do for getting things going, though.
>
> Thoughts?
>
> -Tim
>
>
> > Probably
> > all the live modules or logical module groups (those active on the
> > Plugin Portal) should each get their own GH repo somewhere—does not
> > make sense to shove them all into one repo. And then how do bits get
> > distributed to users? I am not sure what happened to deadlock and its
> > CI job for contrib modules. Plugin Portal still seems to be alive but
> > what is its future? Of
> >
> > http://plugins.netbeans.org/my-plugins
> >
> > there are a number of plugins I would like to keep running and
> > available; some were already being maintained on GitHub, but some
> > (notably quickfilechooser) were not.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> > For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>
> --
> http://timboudreau.com
>
Re: Contrib repo & Community Plugin Repo
Posted by Emilian Bold <em...@protonmail.ch.INVALID>.
I was thinking of the BSD ports tree.
Some plugins are closed-source but a whole lot of them are open-source.
There is no need the Plugin Portal to be a binary-only repository, we could indeed just build stuff ourselves.
It doesn't need any fancy GitHub hooks, just a nightly cron job every now and then would be good.
--emi
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On 25 July 2018 12:13 PM, Tim Boudreau <ni...@gmail.com> wrote:
> > Resurrecting this thread, since Tim Boudreau recently Mavenized the
> > contrib repo:
> > https://github.com/timboudreau/netbeans-contrib
>
> I sent a note to this list about that on Monday, but got no response at
> all. Wondering if it went into a black hole, or nobody cares :-)
>
> > The Mavenization is certainly welcome (to me at least!) but someone
> > needs to officially decide what to do with all that stuff.
>
> Agreed. I hadn't seen any specific proposal, so I figured I'd do
> something since contrib/ still contains things I rely on daily.
>
> So here's a proposal:
>
> 1. The big, critical thing that needs to happen is for Oracle to
> relicense this code to Apache license, the same as NetBeans. Everything in
> there was contributed under a contributor agreement that assigns joint
> copyright ownership to Oracle nee Sun. So, Oracle is the one party that
> can do that for everything - former Oracle employees can't even relicense
> their own code, since it was work-for-hire and only external contributors
> hold joint copyright. Geertjan, can you make that happen?
>
> 2. I agree with Jesse that the things that are actively maintained there
> should probably find separate homes on Github or wherever their maintainers
> want. In the meantime, I'm happy to babysit the repo while that happens
> (likely it can't happen until 1. is done).
>
> So what I'd suggest is that Geertjan (or whatever Oracle employee is
> empowered to do it) fork the repo, change the license headers (scriptable,
> not hard), and - depending on who wants it long-term - either send me a
> pull request, or if the Apache organization wants to own it going forward,
> I can retire this repo.
>
> 3. In the meantime, if anyone has stuff they want to work on in there, I'm
> happy to add anybody who wants as a collaborator or accept pull requests,
> or whatever works for folks - until the licensing is straightened out and
> things can find their own homes, it's probably best for there to be one
> repository of record.
>
> 4. Distributing things: I have a temporary plan for this: Set up a
> continuous build of the whole enchilada on my Jenkins server, and dump all
> the modules of a separate instance of
> https://github.com/timboudreau/meta-update-center - all the build has to do
> is dump the contents into a folder it's watching, and updates will show
> up. It's a tiny, lightweight update center server - example here
> https://timboudreau.com/modules - no user rankings or frilly UI (could be
> added if someone were ambitious), but it does what it does with zero
> headaches.
>
> I'll probably get to that next week - I'm replacing my server on Friday
> with a 72Gb box, so since I've migrated all of the VMs, I'm not making
> major changes on the old machine this week as I'd have to replicate them.
>
> 5. Longer term...
>
> A. There should probably a continuous build of this stuff somewhere else
> (Apache? Something else?), which interested module owners can add jobs to,
> with the same sort of automated distribution (Jenkins publishes nbms,
> meta-update-center polls the URL of the built NBM and automatically updates
> if the Last-Modified header has changed) - so there remains some kind of
> one-stop-shopping for community modules. I was never a huge fan of the
> plugin portal's model for how developers use it, since you had to go and
> manually update it - that's actually what inspired me to write
> meta-update-center. So you set up Jenkins to build a "stable" branch, and
> that gets distributed automagically whenever you push to it.
>
> B. Need a way to flag stuff in contrib as clearly junk, because some of it
> is. We could just nuke stuff, or remove it from the master POM, but at the
> moment that's also serving as the notes for what needs fixing, so I'm not
> dying to mix concerns there, and probably shouldn't take a chainsaw to
> stuff until the relicensing is done or that will complicate things.
>
> C. Something fancier could and probably should be done for distribution
> long-term. I can contribute hosting of some stuff for now, but I barter
> hosting a local TV station's streaming video server on that box for free
> commercial-grade bandwidth, and I've had situations where Comcast techs
> came in and screwed with the network configuration and I had to go figure
> out what they'd done and fix it. So we're talking 95% uptime, but not five
> nines. It will do for getting things going, though.
>
> Thoughts?
>
> -Tim
>
>
> > Probably
> > all the live modules or logical module groups (those active on the
> > Plugin Portal) should each get their own GH repo somewhere—does not
> > make sense to shove them all into one repo. And then how do bits get
> > distributed to users? I am not sure what happened to deadlock and its
> > CI job for contrib modules. Plugin Portal still seems to be alive but
> > what is its future? Of
> > http://plugins.netbeans.org/my-plugins
> > there are a number of plugins I would like to keep running and
> > available; some were already being maintained on GitHub, but some
> > (notably quickfilechooser) were not.
> >
> > To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> > For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
> --
>
> http://timboudreau.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Contrib repo & Community Plugin Repo
Posted by Tim Boudreau <ni...@gmail.com>.
>
> Resurrecting this thread, since Tim Boudreau recently Mavenized the
> contrib repo:
>
> https://github.com/timboudreau/netbeans-contrib
I sent a note to this list about that on Monday, but got no response at
all. Wondering if it went into a black hole, or nobody cares :-)
> The Mavenization is certainly welcome (to me at least!) but someone
> needs to officially decide what to *do* with all that stuff.
Agreed. I hadn't seen any specific proposal, so I figured I'd do
*something* since contrib/ still contains things I rely on daily.
So here's a proposal:
1. The *big, critical thing that needs to happen* is for Oracle to
relicense this code to Apache license, the same as NetBeans. Everything in
there was contributed under a contributor agreement that assigns joint
copyright ownership to Oracle nee Sun. So, Oracle is the one party that
can do that for everything - former Oracle employees can't even relicense
their own code, since it was work-for-hire and only external contributors
hold joint copyright. Geertjan, can you make that happen?
2. I agree with Jesse that the things that are actively maintained there
should probably find separate homes on Github or wherever their maintainers
want. In the meantime, I'm happy to babysit the repo while that happens
(likely it can't happen until 1. is done).
So what I'd suggest is that Geertjan (or whatever Oracle employee is
empowered to do it) fork the repo, change the license headers (scriptable,
not hard), and - depending on who wants it long-term - either send me a
pull request, or if the Apache organization wants to own it going forward,
I can retire this repo.
3. In the meantime, if anyone has stuff they want to work on in there, I'm
happy to add anybody who wants as a collaborator or accept pull requests,
or whatever works for folks - until the licensing is straightened out and
things can find their own homes, it's probably best for there to be one
repository of record.
4. Distributing things: I have a temporary plan for this: Set up a
continuous build of the whole enchilada on my Jenkins server, and dump all
the modules of a separate instance of
https://github.com/timboudreau/meta-update-center - all the build has to do
is dump the contents into a folder it's watching, and updates will show
up. It's a tiny, lightweight update center server - example here
https://timboudreau.com/modules - no user rankings or frilly UI (could be
added if someone were ambitious), but it does what it does with zero
headaches.
I'll probably get to that next week - I'm replacing my server on Friday
with a 72Gb box, so since I've migrated all of the VMs, I'm not making
major changes on the old machine this week as I'd have to replicate them.
5. Longer term...
A. There should probably a continuous build of this stuff somewhere else
(Apache? Something else?), which interested module owners can add jobs to,
with the same sort of automated distribution (Jenkins publishes nbms,
meta-update-center polls the URL of the built NBM and automatically updates
if the Last-Modified header has changed) - so there remains some kind of
one-stop-shopping for community modules. I was never a huge fan of the
plugin portal's model for how *developers* use it, since you had to go and
manually update it - that's actually what inspired me to write
meta-update-center. So you set up Jenkins to build a "stable" branch, and
that gets distributed automagically whenever you push to it.
B. Need a way to flag stuff in contrib as clearly junk, because some of it
is. We could just nuke stuff, or remove it from the master POM, but at the
moment that's also serving as the notes for what needs fixing, so I'm not
dying to mix concerns there, and probably shouldn't take a chainsaw to
stuff until the relicensing is done or that will complicate things.
C. Something fancier could and probably should be done for distribution
long-term. I can contribute hosting of some stuff for now, but I barter
hosting a local TV station's streaming video server on that box for free
commercial-grade bandwidth, and I've had situations where Comcast techs
came in and screwed with the network configuration and I had to go figure
out what they'd done and fix it. So we're talking 95% uptime, but not five
nines. It will do for getting things going, though.
Thoughts?
-Tim
> Probably
> all the live modules or logical module groups (those active on the
> Plugin Portal) should each get their own GH repo somewhere—does not
> make sense to shove them all into one repo. And then how do bits get
> distributed to users? I am not sure what happened to deadlock and its
> CI job for contrib modules. Plugin Portal still seems to be alive but
> what is its future? Of
>
> http://plugins.netbeans.org/my-plugins
>
> there are a number of plugins I would like to keep running and
> available; some were already being maintained on GitHub, but some
> (notably quickfilechooser) were not.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
--
http://timboudreau.com
Re: Contrib repo & Community Plugin Repo
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
There are a few known unknowns (and also unknown unknowns) in this area.
Firstly, what we know is the the Plugin Portal itself (i.e., the
application at plugins.netbeans.org) is going to be part of the 3rd
donation, i.e., the sources of the application have been audited and will
be donated to Apache as part of the 3rd donation (i.e., right now we have
completed the 1st and 2nd donation and are working on the 3rd donation
which is focused on tutorials and related resources, as well as the Plugin
Portal application). Where it will then be hosted is not entirely clear --
possibly on the netbeans-vm at Apache, possibly at one of our partner
organizations, e.g., DukeScript run by Toni Epple in Munich, etc.
Secondly, once we have the Plugin Portal application up and running
somewhere (ideally with the same URL, and if hosted outside Apache branded
in such a way that its relationship to Apache NetBeans is clear), the next
question will be where to host the NBMs, which will be uploaded via the
Plugin Portal, i.e., the NBMs could be hosted somewhere else. They could be
considered to be convenience binaries somehow in Apache terms and could
then be distributed via Apache hosting, though that's probably not viable.
Thirdly, there's the question where the sources of the plugins will be
located -- and indeed individual GitHub repos for each individual code base
would be logical.
Anyway, that's where things are and I may have overlooked some developments.
Gj
On Wed, Jul 25, 2018 at 2:46 AM, Jesse Glick <ty...@gmail.com> wrote:
> Resurrecting this thread, since Tim Boudreau recently Mavenized the
> contrib repo:
>
> https://github.com/timboudreau/netbeans-contrib
>
> The Mavenization is certainly welcome (to me at least!) but someone
> needs to officially decide what to *do* with all that stuff. Probably
> all the live modules or logical module groups (those active on the
> Plugin Portal) should each get their own GH repo somewhere—does not
> make sense to shove them all into one repo. And then how do bits get
> distributed to users? I am not sure what happened to deadlock and its
> CI job for contrib modules. Plugin Portal still seems to be alive but
> what is its future? Of
>
> http://plugins.netbeans.org/my-plugins
>
> there are a number of plugins I would like to keep running and
> available; some were already being maintained on GitHub, but some
> (notably quickfilechooser) were not.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Contrib repo & Community Plugin Repo
Posted by Jesse Glick <ty...@gmail.com>.
Resurrecting this thread, since Tim Boudreau recently Mavenized the
contrib repo:
https://github.com/timboudreau/netbeans-contrib
The Mavenization is certainly welcome (to me at least!) but someone
needs to officially decide what to *do* with all that stuff. Probably
all the live modules or logical module groups (those active on the
Plugin Portal) should each get their own GH repo somewhere—does not
make sense to shove them all into one repo. And then how do bits get
distributed to users? I am not sure what happened to deadlock and its
CI job for contrib modules. Plugin Portal still seems to be alive but
what is its future? Of
http://plugins.netbeans.org/my-plugins
there are a number of plugins I would like to keep running and
available; some were already being maintained on GitHub, but some
(notably quickfilechooser) were not.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.incubator.apache.org
For additional commands, e-mail: dev-help@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Contrib repo & Community Plugin Repo
Posted by Neil C Smith <ne...@apache.org>.
Hi,
On Mon, 28 May 2018, 19:02 Wade Chandler, <wa...@apache.org> wrote:
> I think for the plugin portal, we could have a real simple registration
> scheme that is a repository that has a particular structure for a publisher
> with YAML files and images in it for plugin registration, and have a static
> site generator for it. We could protect to a reasonable degree the
> publishers files from anyone outside the Apache contributor organization by
> validating the userid of the commit matches the folder structure of the
> “publisher” or the publisher belongs to a GH organization. We could take
> that a step further, and allow links to other repositories of similar
> layout for publishers. We could easily pull in someones master repository
> during build time of a static repository.
>
Agreed! I've suggested this a few times and was going to look at it a few
months ago, but that was pending some work elsewhere that was looking at
running the existing plugin portal on the VM. I've lost track of where
that's got to, and still think licensing might be an issue with that
anyway.
One thing I'd add to your suggestion is I think the catalog should be
enhanced with a checksum for the plugin so each update link can be checked
and validated via PR to the catalog repo.
Best wishes,
Neil
> --
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
Re: Contrib repo & Community Plugin Repo
Posted by Wade Chandler <wa...@apache.org>.
I think those things get dated quickly. People tend to like to have recognition IMO, and is why to me the plugin portal grew, and contrib faded off. It would also mean folks putting code there have to keep it up, and we have to rely on them to do so, and they have to be all in on the Apache process and license if it is a project repo.
It seems it would make more sense to get the plugin portal working, and have it be able to pull from binaries and archives which could be stored any where; such as Github releases. If folks then want to contribute a plugin to NetBeans, it seems we’d figure out which cluster it made sense to be in, and then look at it as a code donation, and then put it in the proper repository for Apache NB (incubating). Otherwise, they’d just register with the portal.
I think for the plugin portal, we could have a real simple registration scheme that is a repository that has a particular structure for a publisher with YAML files and images in it for plugin registration, and have a static site generator for it. We could protect to a reasonable degree the publishers files from anyone outside the Apache contributor organization by validating the userid of the commit matches the folder structure of the “publisher” or the publisher belongs to a GH organization. We could take that a step further, and allow links to other repositories of similar layout for publishers. We could easily pull in someones master repository during build time of a static repository.
Anyways, I think that would be a better approach than facilitating contrib which gets odd considering the way Apache works versus how NB worked (the project). Contrib was a lighter more relaxed model where one did not need commit access to everything. Apache has no such model; contributors must be contributors.
Wade
> On May 28, 2018, at 4:33 AM, Christian Lenz <ch...@gmx.net> wrote:
>
> Hey Devs,
>
> long time ago, there was mail thread (private) with Geertjan and a guy who created an „organization“ on GitHub for NetBeans Plugins, where I wanted to join and added all of my plugins to this repo, to have it under a global, public (official) repo for NetBeans. I don’t know what happened, I couldn’t figure out the guy who created it, maybe have a look into my mails.
>
> Anyway, the Thing is that it doesn’t work out, maybe lack of time, only one person was responsible for this or whatever. So why I wanted to bring this up again is, that in my opinion, it would be nice if we can have a GitHub repo/organization (Maybe Apache/NetBeans-Plugins) where we can add all of our 3rd-party-plugins, which are not part of the core and/or a contrib repo again or whatever. I don’t know the history of the contrib repo anymore, since we don’t have it atm?
>
> I don’t know how the contrib repo was handled, but afaik, Maybe we don’t Need it anymore or so? The contrib repo still exists with a lot of features (some are old, some are strill working) who are still not part of the core but part of a Plugin but to add it, you have to add the contrib repo as a dependency to the Plugins section.
>
> So what do you think, do we still need a contrib repo? If yes, how could it be handled? As a GitHub or Apache git repo with a GitHub Mirror? Should we have an official Apache/netbeans-plugins repo like JetBrains have it for there community Plugins? https://github.com/JetBrains/intellij-plugins
>
> Thread is kind of brainstorming.
>
>
> Cheers
>
> Chris