Hi all,
I regret having to say this whole thing of UC and plugins is quite
complicated for me :-). During the years we have been improving things
(adding https, proxying for the old Oracle hosted update center in
netbeans-vm.apache.org/pluginportal2, etc.)
As far as I understand the PP2 will remain untouched. This is so because
URLs are already fixed in code and because NetBeans < 12.0 uses plain
http for plugins, whereas 12.0+ uses https.
For simplicity, let's abbreviate:
NAO - netbeans.apache.org
PNAO - plugins.netbeans.apache.org (hosted as virtual server in
netbeans-vm.apache.org [1])
What about this?
https://NAO/nb/updates/dev -302-> https://PNAO/dev/updates
https://NAO/nb/plugins/dev -302-> https://PNAO/dev/plugins
https://NAO/nb/updates -302-> https://PNAO/12.0/updates
https://NAO/nb/plugins -302-> https://PNAO/12.0/plugins
Of course this will require hosting the binaries in PNAO (which may be
somewhat slow, but faster than hosting them in the Jenkins builds).
We are already synchronizing javadocs, so there's no reason why we can't
synchronize binaries (note that Jenkins builds don't support rsync,
though, so we'll have to download whole zips, and this may be slow).
What say? Did I understand things correctly? Will this work?
Cheers,
Antonio
[1]
https://github.com/apache/infrastructure-puppet/blob/9bb6860a8f07c3a04e77177ba752012fb0c629d9/data/nodes/netbeans-vm.apache.org.yaml#L207
El 30/5/20 a las 15:32, Neil C Smith escribió:
Hi,
Just bringing the discussion part of
https://github.com/apache/netbeans-website/pull/473 on to here.
Matthias correctly pointed out in the above PR that we've not kept
redirects for the master branch update centre and plugin portal always
in line with the current release branch. Not just for 12.0 - probably
over each release for the last year. This is one reason a current
issue with the plugin portal may have gone unnoticed.
Over the last year or two we've moved to having all inbound links from
the IDE come in under https://netbeans.apache.org/nb. This has a
variety of benefits, one being we can easily manage redirecting things
to the right place in
https://github.com/apache/netbeans-website/blob/master/netbeans.apache.org/src/content/.htaccess
Useful, particularly during transition from Oracle to Apache
infrastructure, to change things without requiring IDE updates.
It has also given us predictable links for update centre and plugin
portal for each release and master, even with underlying changes.
After 12.0 is released we should probably make the following 3
changes, only the third part of which was really cause for discussion
on the PR.
# Stage 1
Change the dev redirects in the .htaccess to -
Redirect 302 /nb/updates/dev/ https://netbeans-vm.apache.org/uc/dev/
Redirect 302 /nb/plugins/dev/ https://plugins.netbeans.apache.org/data/dev/
This will require setting up /dev endpoints for the UC on the VM and
on the plugin portal. Initially as symlinks for 12.0?
# Stage 2
Once the above is working, we can remove a lot of the redirects and
move everything up a level - then we have no need to update the
.htaccess for each release -
Redirect 302 /nb/updates/ https://netbeans-vm.apache.org/uc/
Redirect 302 /nb/plugins/ https://plugins.netbeans.apache.org/data/
We could also just proxy those links from those places without
redirect? Might help with issue of being blocked when processing a
lot of updates?
# Stage 3
We can then make a decision on what update centre and plugin portal
catalogues make sense for dev builds.
IMO, and the bit that really caused discussion, we adjust the latest
master build on Jenkins to serve the NBMs and point at that (via the
VM). I think this is what happened before the Apache transition?
https://builds.apache.org/view/M-R/view/NetBeans/job/netbeans-TLP/job/netbeans/job/master/lastSuccessfulBuild/artifact/
Antonio raised concerns on the PR that infra might not appreciate that
- obviously we don't have to do it, but considering we've been
distributing beta builds direct from Jenkins, it's probably a very
minor increase in bandwidth. Would it actually be useful?
We could also consider a dev / next specific section on the plugin
portal to allow plugin authors to test with master? Or to try new
plugin portal features?
Sorry about the long email about what feel like minor changes, but
given the discussion on the PR, be good to know this is what we're
heading for, or not. Losing track of how much of this has happened by
release manager convention, and how much is an actual plan! :-)
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
