Re: [DISCUSS] netbeans.org to netbeans.apache.org

[Wade Chandler]

> On Apr 15, 2019, at 5:47 PM, Antonio  wrote:
> 
> Hi all,
> 
> Just to explain that ASF-Infra did setup the rerouting of pages from 
> netbeans.org to netbeans.apache.org this EU afternoon.
> 
> The rerouting worked well, the appropriate netbeans.org pages were rerouted 
> to the netbeans.apache.org domain correctly.
> 
> But

The NS and DTD files I think we have and can quickly move over to new site.

I also think there will be all kinds of various deep linking issues that we 
will just have to ignore and have a redirect backup plan for a good 404 page. 

> some other websites hosted in other subdomains (platform.netbeans.org,

For this one, what about https://issues.apache.org/jira/browse/NETBEANS-124 
 I was thinking we had this 
ready; I just don’t see the sub-directory any longer in the new site.

> edu.netbeans.org,

Maybe we just reroute this to a sub page with instructions that it is in the 
process of being moved for now or figured out, but NB is now at Apache, and 
open for all. I think we could redo this page fairly quickly and separately 
without any real disruption to anyone. Maybe Ken Fogel would like to help with 
this one.

> wiki.netbeans.org, ...) stopped working.

Again, maybe not worry about external deep linking, have a good 404 plan, and 
just point to whatever we’re calling the “Wiki” for this purpose? New world 
looking forward etc, and invite folks to search the new site for which ever 
content they may have clicked through to find… http://netbeans.apache.org/wiki/ 

> 
> This is so because these other websites require certain resources hosted in 
> netbeans.org, these include images, CSS stylesheets and JavaScript files.
> 
> As a consequence of the disruption of service in those other sites, ASF-Infra 
> decided to roll-back the changes.

In my opinion we should be able to quickly handle these items given the above.

> 
> We're starting a list of resources here:
> 
> https://cwiki.apache.org/confluence/display/NETBEANS/netbeans.org+migration
> 
> An initial PR (platform.netbeans.org) for you to review is here:
> 
> https://github.com/apache/incubator-netbeans-website/pull/350 
> 

Will check them out.

> 
> The plan is to decide which other sites we want to keep (edu.netbeans.org?) 
> and either decide how to reroute those or see which resources are missing. 
> Feel free to add resources in the confluence page above.

I can’t think of any others which are more important than the noted ones and 
moving on to Apache (plugins of course, but on the plan), but will do some 
looking.

Thanks,

Wade

Re: DTDs and XSDs

[Wade Chandler]

This is here too for extra reference; a couple Jira issues were setup for it 
too; in case anything in there helps:
https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning#NewNetBeansWebSitePlanning-RelocateDTDsandNS(XMLSchemas)
 
<https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning#NewNetBeansWebSitePlanning-RelocateDTDsandNS(XMLSchemas)>

It would be helpful to understand what the process for publishing those was 
before. Was there some build which did this automatically to the site 
previously, or were these manual steps with infrequent changes? Either way 
seems doable, but wondering if automated if the script or what ever is still 
around which we could change up to use git pushes.

Wade



> On Apr 16, 2019, at 10:35 PM, Wade Chandler  wrote:
> 
> dtds here too
> 
> https://github.com/wadechandler/netbeans-static-site/tree/master/src/content/dtds
>  
> <https://github.com/wadechandler/netbeans-static-site/tree/master/src/content/dtds>
> 
> Wade
> 
> On Tue, Apr 16, 2019, 22:28 Wade Chandler  <mailto:wadechand...@apache.org>> wrote:
> These are probably in the original site copies I made; many files there;
> 
> https://github.com/wadechandler/netbeans-static-site/tree/master/src/content/ns
>  
> <https://github.com/wadechandler/netbeans-static-site/tree/master/src/content/ns>
> 
> It seems we should be able to publish then plus new updates.
> 
> Wade
> 
> 
> On Tue, Apr 16, 2019, 16:35 Antonio  <mailto:anto...@vieiro.net>> wrote:
> Hi,
> 
> Yep, too bad we can't have that backup server.
> 
> Meanwhile we're collecting those missing links here: 
> https://cwiki.apache.org/confluence/display/NETBEANS/netbeans.org+migration 
> <https://cwiki.apache.org/confluence/display/NETBEANS/netbeans.org+migration>
> 
> Jan, can you please add your findings to that page?
> 
> Thanks,
> Antonio
> 
> El 16/04/2019 a las 21:37, Geertjan Wielenga escribió:
> > Yes, none of this is news at all. We tried rerouting, didn’t work as
> > expected, side effects, so it’s being rolled back now, may take a day or so
> > and it will be OK again.
> > 
> > Then, now that we know of several problematic areas such as this one, we
> > can investigate each case and see how to solve it.
> > 
> > Gj
> > 
> > 
> > On Tue, 16 Apr 2019 at 15:22, Jan Lahoda  > <mailto:lah...@gmail.com>> wrote:
> > 
> >> Hi,
> >>
> >> (As noted by a friend of mine.) Many modules in NetBeans use DTDs or XSDs
> >> to validate XMLs. The appropriate DTDs and XSDs are available not only
> >> inside the IDE, but also published on the web. Presumably with the recent
> >> change to use netbeans.apache.org <http://netbeans.apache.org/> instead of 
> >> www.netbeans.org <http://www.netbeans.org/>, (some of)
> >> these became unavailable. This can cause  problems when doing online
> >> validation of XMLs. That may happen e.g. in tests.
> >>
> >> As far as I can tell, these were under the "dtd" and "ns" directories under
> >> (www.)netbeans.org <http://netbeans.org/>.
> >>
> >> One thing to note is that "netbeans.org <http://netbeans.org/>" still 
> >> appears to use the old
> >> server. So:
> >> https://netbeans.org/dtds/EditorFontsColors-1_0.dtd 
> >> <https://netbeans.org/dtds/EditorFontsColors-1_0.dtd>
> >>
> >> still appears to work OK, while:
> >> https://www.netbeans.org/dtds/EditorFontsColors-1_0.dtd 
> >> <https://www.netbeans.org/dtds/EditorFontsColors-1_0.dtd>
> >>
> >> does not.
> >>
> >> I think we need to publish the DTDs and XSDs again on our pages, but it
> >> would be awesome if we could use the old server until that is done. Would a
> >> redirect from:
> >> https://www.netbeans.org/dtds/ <https://www.netbeans.org/dtds/>
> >> to:
> >> https://netbeans.org/dtds/ <https://netbeans.org/dtds/>
> >>
> >> work for now? (And the same for "https://www.netbeans.org/ns/ 
> >> <https://www.netbeans.org/ns/>".) After we
> >> (re-)publish the DTDs and XSDs, we could change the DNS for netbeans.org 
> >> <http://netbeans.org/>
> >> as
> >> well?
> >>
> >> Thanks,
> >>  Jan
> >>
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org 
> <mailto:dev-unsubscr...@netbeans.incubator.apache.org>
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org 
> <mailto:dev-h...@netbeans.incubator.apache.org>
> 
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists 
> <https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists>
> 
> 
> 

Re: DTDs and XSDs

[Wade Chandler]

These are probably in the original site copies I made; many files there;

https://github.com/wadechandler/netbeans-static-site/tree/master/src/content/ns

It seems we should be able to publish then plus new updates.

Wade


On Tue, Apr 16, 2019, 16:35 Antonio  wrote:

> Hi,
>
> Yep, too bad we can't have that backup server.
>
> Meanwhile we're collecting those missing links here:
> https://cwiki.apache.org/confluence/display/NETBEANS/netbeans.org+migration
>
> Jan, can you please add your findings to that page?
>
> Thanks,
> Antonio
>
> El 16/04/2019 a las 21:37, Geertjan Wielenga escribió:
> > Yes, none of this is news at all. We tried rerouting, didn’t work as
> > expected, side effects, so it’s being rolled back now, may take a day or
> so
> > and it will be OK again.
> >
> > Then, now that we know of several problematic areas such as this one, we
> > can investigate each case and see how to solve it.
> >
> > Gj
> >
> >
> > On Tue, 16 Apr 2019 at 15:22, Jan Lahoda  wrote:
> >
> >> Hi,
> >>
> >> (As noted by a friend of mine.) Many modules in NetBeans use DTDs or
> XSDs
> >> to validate XMLs. The appropriate DTDs and XSDs are available not only
> >> inside the IDE, but also published on the web. Presumably with the
> recent
> >> change to use netbeans.apache.org instead of www.netbeans.org, (some
> of)
> >> these became unavailable. This can cause  problems when doing online
> >> validation of XMLs. That may happen e.g. in tests.
> >>
> >> As far as I can tell, these were under the "dtd" and "ns" directories
> under
> >> (www.)netbeans.org.
> >>
> >> One thing to note is that "netbeans.org" still appears to use the old
> >> server. So:
> >> https://netbeans.org/dtds/EditorFontsColors-1_0.dtd
> >>
> >> still appears to work OK, while:
> >> https://www.netbeans.org/dtds/EditorFontsColors-1_0.dtd
> >>
> >> does not.
> >>
> >> I think we need to publish the DTDs and XSDs again on our pages, but it
> >> would be awesome if we could use the old server until that is done.
> Would a
> >> redirect from:
> >> https://www.netbeans.org/dtds/
> >> to:
> >> https://netbeans.org/dtds/
> >>
> >> work for now? (And the same for "https://www.netbeans.org/ns/;.) After
> we
> >> (re-)publish the DTDs and XSDs, we could change the DNS for
> netbeans.org
> >> as
> >> well?
> >>
> >> Thanks,
> >>  Jan
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: DTDs and XSDs

[Wade Chandler]

dtds here too

https://github.com/wadechandler/netbeans-static-site/tree/master/src/content/dtds

Wade

On Tue, Apr 16, 2019, 22:28 Wade Chandler  wrote:

> These are probably in the original site copies I made; many files there;
>
>
> https://github.com/wadechandler/netbeans-static-site/tree/master/src/content/ns
>
> It seems we should be able to publish then plus new updates.
>
> Wade
>
>
> On Tue, Apr 16, 2019, 16:35 Antonio  wrote:
>
>> Hi,
>>
>> Yep, too bad we can't have that backup server.
>>
>> Meanwhile we're collecting those missing links here:
>>
>> https://cwiki.apache.org/confluence/display/NETBEANS/netbeans.org+migration
>>
>> Jan, can you please add your findings to that page?
>>
>> Thanks,
>> Antonio
>>
>> El 16/04/2019 a las 21:37, Geertjan Wielenga escribió:
>> > Yes, none of this is news at all. We tried rerouting, didn’t work as
>> > expected, side effects, so it’s being rolled back now, may take a day
>> or so
>> > and it will be OK again.
>> >
>> > Then, now that we know of several problematic areas such as this one, we
>> > can investigate each case and see how to solve it.
>> >
>> > Gj
>> >
>> >
>> > On Tue, 16 Apr 2019 at 15:22, Jan Lahoda  wrote:
>> >
>> >> Hi,
>> >>
>> >> (As noted by a friend of mine.) Many modules in NetBeans use DTDs or
>> XSDs
>> >> to validate XMLs. The appropriate DTDs and XSDs are available not only
>> >> inside the IDE, but also published on the web. Presumably with the
>> recent
>> >> change to use netbeans.apache.org instead of www.netbeans.org, (some
>> of)
>> >> these became unavailable. This can cause  problems when doing online
>> >> validation of XMLs. That may happen e.g. in tests.
>> >>
>> >> As far as I can tell, these were under the "dtd" and "ns" directories
>> under
>> >> (www.)netbeans.org.
>> >>
>> >> One thing to note is that "netbeans.org" still appears to use the old
>> >> server. So:
>> >> https://netbeans.org/dtds/EditorFontsColors-1_0.dtd
>> >>
>> >> still appears to work OK, while:
>> >> https://www.netbeans.org/dtds/EditorFontsColors-1_0.dtd
>> >>
>> >> does not.
>> >>
>> >> I think we need to publish the DTDs and XSDs again on our pages, but it
>> >> would be awesome if we could use the old server until that is done.
>> Would a
>> >> redirect from:
>> >> https://www.netbeans.org/dtds/
>> >> to:
>> >> https://netbeans.org/dtds/
>> >>
>> >> work for now? (And the same for "https://www.netbeans.org/ns/;.)
>> After we
>> >> (re-)publish the DTDs and XSDs, we could change the DNS for
>> netbeans.org
>> >> as
>> >> well?
>> >>
>> >> Thanks,
>> >>  Jan
>> >>
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
>> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>>

Re: [DISCUSS] netbeans.org to netbeans.apache.org

[Wade Chandler]

Certainly agree just move it over, but too, why not just point to
netbeans.apache.org versus that community page?

Thanks

Wade


On Thu, Apr 11, 2019, 01:30 Antonio  wrote:

> Hi all,
>
> So do we want to
>
> A) serve content directly from "https://netbeans.org;
> So, for instance, people can navigate to
> "https://netbeans.org/community/index.html;
>
> or
>
> B) Make "https://netbeans.org; redirect to "https://netbeans.apache.org;?
> So users are redirected to
> "https://netbeans.apache.org/community/index.html;
>
> After some conversations with @fluxo in the ASF-Infra chat [1], it seems
> solution A) above (using netbeans.org to serve content) will require
> some extra approval from the ASF-Infra administrator.
>
> Thanks,
> Antonio
>
>
> [1]
> https://the-asf.slack.com/archives/CBX4TSBQ8/p1554958859575300
>
> El 10/04/2019 a las 23:55, Geertjan Wielenga escribió:
> > +1, let’s get it done.
> >
> > Gj
> >
> > On Wed, 10 Apr 2019 at 21:57, Antonio  wrote:
> >
> >> Hi all,
> >>
> >> As you may know netbeans.org currently holds the Oracle website.
> >>
> >> Our initial plan was to make this "Oracle netbeans.org" website to
> start
> >> serving under the "legacy.netbeans.org" domain, and then create an
> >> "Apache netbeans.org" that could redirect missing pages to
> >> "legacy.netbeans.org".
> >>
> >> The problem is that making the change "Oracle netbeans.org" ->
> >> "legacy.netbeans.org" seems more complicated than we initially
> >> anticipated. The web server is setup in such a way that only works with
> >> the "netbeans.org" domain. And making it start serving in
> >> "legacy.netbeans.org" would require Oracle doing things.
> >>
> >> Since we already have lots of content in netbeans.apache.org, maybe
> it's
> >> simpler to request ASF-Infra to make the domain name change (and other
> >> changes if required) and make "netbeans.org" start serving Apache
> content.
> >>
> >> If nobody opposes I'll request this to ASF-Infra within 48h or so.
> >>
> >> Thanks,
> >> Antonio
> >>
> >> P.S.: The Oracle content will still be accessible in case of need by
> >> doing a simple local hack to your /etc/hosts file.
> >>
> >>
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> >> For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: [RESULT] [VOTE] Recommend 'Apache NetBeans graduation to Top Level Project' resolution to board

[Wade Chandler]

Great news indeed! Thanks and congratulations to everyone who has
contributed in any way including the Apache mentors Bertrand, Ate, Daniel,
and Jim.

A big special thanks to Geertjan, Jirka, Jarda, Tim, Jesse, Bruno, Milos,
Tomas, Jan, and all the other old hats from NetBeans including the NBDT
members; a lot of years and hard work behind all of this; decades!

Everything we ever did looks like it will have a long and open life! I'm so
proud of you all.

After Bruno Souza and some of us started the "Dream Team" (say that without
feeling cheesy), we created a mission statement:

"The NetBeans Dream Team strives to make the NetBeans open source project
more accessible to our user, contributor, and partner communities."

Geertjan and Jirka helped us carry on that mission.

I can't think of a better way to complete it than here at Apache with it's
open and passion driven model "The Apache Way" and a TLP. Can it be more
accessible?!

Thanks for all the great years of fun, experiences and learning! Here's to
more!

Wade



On Thu, Apr 11, 2019, 08:50 Geertjan Wielenga
 wrote:

> Hi all,
>
> All the discussions and votes have succeeded -- and the Apache Board will
> be recommended to graduate Apache NetBeans to a top level project at its
> next meeting.
>
> Congrats everybody, for the great work done together and the even greater
> work to come!
>
> Thanks,
>
> Gj
>
> -- Forwarded message -
> From: Geertjan Wielenga 
> Date: Thu, Apr 11, 2019 at 1:18 PM
> Subject: [RESULT] [VOTE] Recommend 'Apache NetBeans graduation to Top
> Level Project' resolution to board
> To: 
>
>
> Hi all,
>
> Many thanks for the enthusiasm and encouragement -- the vote thread[1] has
> been open for 72 hours and the vote has passed:
>
> 18 +1 votes (and no 0 or -1 votes).
>
> Thanks,
>
> Geertjan
> on behalf of Apache NetBeans
>
> [1]
> https://lists.apache.org/thread.html/9d7c5d2048f8050fa0e438c5b14ea75c60a52ef479694f79f32e86b6@%3Cgeneral.incubator.apache.org%3E
>

Re: Editor tab control UI replacement

[Wade Chandler]

Great stuff Tim! Definitely work it in and contribute it. We need more of
that versus less, and who better! Certainly if it can be enabled and
disabled with a check box in settings it would be great; then can AB test
for which should be the default later. Maybe we should start some Apache
NetBeans feature surveys :-)

Thanks

Wade


On Wed, Apr 10, 2019, 15:56 Tim Boudreau  wrote:

> Back in 2003/4, I wrote the tab control for the NetBeans 3.6 window system,
> which is still in use - the thing JTabbedPane should have been if it had
> been written with the needs of applications like NetBeans in mind (i.e.
> model driven, not using the AWT hierarchy as its model, capable of complex
> transforms on its contents with minimal redraws, etc.).
>
> Some time after that, NetBeans' Visual Library came into being, which makes
> easy a lot of things that are otherwise very hard in Swing - animation,
> glows around components that extend beyond the bounds of the component,
> smooth scrolling and more.  So I've had it in my head for years that
> someone ought to write a replacement UI delegate for the editor tabs which
> uses it.  Needing to take a break from another project, the other day I
> finally wrote that.  It should work on any Swing look and feel (and I
> tested it on a bunch) - it derives its colors from those of the look and
> feel.  And all of the gradient painting logic is carefully memory managed
> using cached BufferedImages (10-40x faster than caching GradientPaint in my
> tests and far more consistent in its performance).
>
> What it does differently are mainly animation and bling, and highlighting
> for the selected tab that sits outside the tab.  It does have really lovely
> built-in tab-dragging support, but since drag support in the window system
> is implemented via an AWTEventListener in core.windows...I can disable that
> with a not-too-evil hack (have the UI delegate implement Tabbed.Adapter and
> then return null for its Tabbed instance), but then model changes aren't
> known to the window system, so it "corrects" them, undoing the drag on the
> next move.  But the existing tab dragging support (with its ugly polygons)
> works fine, so that's disabled by default.
>
> So, two things:
> 1.  If you'd like a little more (gratuitous?) bling in your editor tabs,
> please test it (download link below)
> 2.  I'd be happy to contribute it to NetBeans if there's interest - it's
> already licensed compatibly
>
> Screen shot (running on my own Dark Look and Feel plugin):
> https://timboudreau.com/files/screen/04-10-2019_15-48-36.png
>
> Binary download compatible w/ JDK 8 and up, NetBeans 8.2 and up:
> https://timboudreau.com/files/visual-library-tabbedcontrol-0.3.1.nbm
>
> Github repo w/ source code:
> https://github.com/timboudreau/visual-library-tabcontrol
>
> Feedback appreciated.
>
> Thanks,
>
> Tim
>
> --
> http://timboudreau.com
>

Re: AW: NetBeans GUI icons, who drew them?

[Wade Chandler]

Top posting...

Indeed, sounds like some good info!

Thanks

Wade


On Mon, Apr 8, 2019, 11:28 Andreas Sewe  wrote:

> Hi,
>
> > I want to mention here the repo of IntelliJ the community edition. They
> do it as a package inside of the platform called Icons:
> https://github.com/JetBrains/intellij-community/tree/master/platform/icons
> as you can see, everything (I don’t know whether it is 100% or less but
> most of the Icons are inside of this package in subpackages. This is
> somehow centralized and not packed with each module and we don’t need find
> any Icon out. And as far as I can see, they use SVG Icons.
>
> some more input:
>
> The Eclipse platform (aka core) project has a single Git repository [1]
> but group the icons therein by plugin. Also, each plugin ships its own
> icons, aside from a few very generic icons like "Close", "Expand", etc,
> which are present in the org.eclipse.ui and org.eclipse.jface plugins.
>
> They then use a Maven plug-in [2] (internally using Batik, I believe) to
> render the SVGs as PNGs in both low and high DPI versions. The plug-in
> also has the option to apply different CSS stylesheets to the SVGs, to
> switch between dark and light mode icons, but I haven't used that
> feature yet.
>
> While the naming conventions used for generated files (e.g., "@2x"
> suffix) currently are probably Eclipse specific, the plug-in might be a
> good basis for NetBeans icon pipeline as well.
>
> Hope this helps,
>
> Andreas
>
> [1]
> <
> https://git.eclipse.org/c/platform/eclipse.platform.images.git/tree/org.eclipse.images/eclipse-svg
> >
> [2]
> <
> https://git.eclipse.org/c/platform/eclipse.platform.images.git/tree/org.eclipse.images.renderer/README.md
> >
>
> --
> Dr. Andreas Sewe | s...@cqse.eu | +49 152 56342856
> CQSE GmbH | Centa-Hafenbraedl-Strasse 59 | 81249 Muenchen | www.cqse.eu
> Amtsgericht Muenchen | HRB 177678 | GF: F. Deissenboeck, M. Feilkas
>
>

Re: NetBeans GUI icons, who drew them?

[Wade Chandler]

On Mon, Apr 8, 2019, 01:58 Antonio  wrote:

>
>
> El 07/04/2019 a las 23:32, Wade Chandler escribió:
> >
> > I discourage such a merge where icons from various modules wind up
> inside a single module. The module code itself still has to reference these
> things, and as such now must touch more than one module just to add an
> image. Why would I want N graphic files if I am using the platform but not
> the modules which require the N graphics? I call that bloat. I think if we
> are having an issue finding icons, and need a solution, we should solve
> that versus a giant lump; it could be a module manifest marker or something
> similar.
> >
>
> Well, this can made optional.
>
> Many icons in NetBeans are retrieved using a simple String that is sent
> to ImageUtilities [1] in "openide.util.ui". This module in turn depends
> on "openide.util".
>
> We could define an "IconProvider" service interface API, responsible for
> finding icons by name.
>
> And then change ImageUtilities to lookup one (or more) IconProvider SPIs
> at runtime. When an icon is requested to ImageUtilities (by name) then
> let's send that request to all SPIs, and see if any returns a proper icon.
>
> So we end up with a set of pluggable "IconProvider"'s that people can
> extend to replace existing icons gradually, and modules won't have to be
> modified/refactored.
>

Yes, the SPI could also support a notion of "get all icons" or "get all
icon parent folders or packages" which could be used for development and
debugging purposes. Or just support a new module manifest entry(ies) to
support the same notion.

We are building a self hosting IDE, and can take advantage of this fact to
solve problems associated with modular development versus relying on common
operating system tools or less refined options like image extension
searches.

Wade

Re: NetBeans GUI icons, who drew them?

[Wade Chandler]

> On Apr 7, 2019, at 5:25 AM, Christian Lenz  wrote:
> 
> Hey guys,
> 
> I want to mention here the repo of IntelliJ the community edition. They do it 
> as a package inside of the platform called Icons: 
> https://github.com/JetBrains/intellij-community/tree/master/platform/icons as 
> you can see, everything (I don’t know whether it is 100% or less but most of 
> the Icons are inside of this package in subpackages. This is somehow 
> centralized and not packed with each module and we don’t need find any Icon 
> out. And as far as I can see, they use SVG Icons.
> 

I discourage such a merge where icons from various modules wind up inside a 
single module. The module code itself still has to reference these things, and 
as such now must touch more than one module just to add an image. Why would I 
want N graphic files if I am using the platform but not the modules which 
require the N graphics? I call that bloat. I think if we are having an issue 
finding icons, and need a solution, we should solve that versus a giant lump; 
it could be a module manifest marker or something similar.

> So all on all, I know that atm it is not possible to have it like this, but 
> this is, imho the future, that what we want and will be a lot of work. But 
> maybe we can start to move Icons one by one to such a public package. And 
> yes, I know that this will change the platform too(?).

I do think we could have a module which is used to convert graphics etc, and 
can then use an SPI. We can of course support SVG etc this way, but then too, 
could allow any other image type to be plugged in by a module author as needed. 
It would be super handy too to be able to support SVG clip paths for sprites or 
similar for pixel based images.

Wade
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: NB11 Question

[Wade Chandler]

> On Apr 3, 2019, at 2:18 PM, Mike Billman  wrote:
> 
> Figured out what was causing this...conflicting files.  At one point, we had 
> a build.gradle file in the same directory so that a gradle command could be 
> issue to build the webui into our local environment.  That is no longer 
> needed, so I deleted that file and it behaves as I would expect it.
> 

This is pointing out a general issue I’d like to focus on at some point 
“fairly” soon in NB which is the ability to blend builds and projects. As an 
example, Gradle is a build tool, not just Java specific, and as such one can 
use it for Angular projects with Gradle plugins which will make sure the proper 
Node and NPM etc are setup and installed in a special cached way to allow for 
easier consistent builds with nothing more than a JDK and a Gradle wrapper. 
This is super handy; both for QA and backend devs to work together with 
front-end folks. Of course then, one needs to be able to work on both the Node 
and Gradle projects; blended. This project structure can include C++ and even 
Python. We are currently blending Gradle and Python, but at some point will 
also have Angular & Node in the mix.

This is a similar usage in the DotNet world to using Cake as a general purpose 
build tool.

Wade

Re: NetBeans GUI icons, who drew them?

[Wade Chandler]

You're looking at nearly a couple decades of work. I doubt anyone could
track down all names etc or even every single source. The best info would
come from the hg logs is my guess.

Wade

On Fri, Apr 5, 2019, 19:09 Eirik Bakke  wrote:

> There are over 3000 bitmap icon images in the NetBeans codebase. Probably
> at least several hundred of these are frequently seen by everyday NetBeans
> users. The page below shows all the unique "gif" or "png" files that
> existed in the NetBeans mercurial repo prior to the Apache transition:
>
> htps://people.csail.mit.edu/ebakke/misc/icons.html
>
> THE QUESTION: Does anyone know who actually designed and drew these icons?
>
> I assume some were cobbled together from various sources, but on the other
> hand, many of the frequently visible ones (e.g. the ones in the toolbars)
> seem to follow a quite consistent visual style.
>
> (This question relates to the effort of making NetBeans look better on
> HiDPI/Retina screens; see separate email thread.)
>
> -- Eirik
>
>

Re: netbeans launchers source code location

[Wade Chandler]

On Fri, Apr 5, 2019, 19:27 Gary Bello  wrote:

>
> Wondering where the source code that causes this behavior is located ?
>

https://github.com/apache/incubator-netbeans/tree/master/nb/ide.launcher

Wade

Re: netbeans launchers source code location

[Wade Chandler]

Are you using the releases or something else like dev builds on your own?
It sounds like you are using the same user directory.

Wade

On Fri, Apr 5, 2019, 19:27 Gary Bello  wrote:

> Have noticed for some time that nb9, nb10, nb11 consider each version the
> same when trying to run  one instance of nb9, nb10, or nb11 at same time.
>
> In other words.
> when running nb9 cannot run nb10 or nb11
> when running nb10 cannot run nb9 or nb11
> when running nb11 cannot run nb9 or nb10;
>
> For all prior versions of netbeans from nb4.1 to nb8.2 can run different
> versions of netbeans at same time - and I have done so many times for
> various reasons.
>
> Wondering where the source code that causes this behavior is located ?
>
> I can run nb82 and nb9 or nb10 or nb11 at same time.
>
> Thanks
> -Gary
>

Re: [DISCUSS] Experimental installers for 11.0

[Wade Chandler]

+1 link for now. Users! Users everywhere!

:-)

Wade

On Fri, Apr 5, 2019, 03:54 Geertjan Wielenga
 wrote:

> Hi all,
>
> Reema has put the installers created from the installer sources in her pull
> request on Apache NetBeans GitHub in her repo:
>
>
> https://github.com/rtaneja1/incubator-netbeans/tree/installer-bin-11vc4/nbbuild/installer/binaries
>
> She also has a process whereby the installers can be generated as part of
> the build.
>
> However, since we have not checked in the sources of the installer into
> Apache NetBeans GitHub and we have not included these convenience binaries
> as part of the vote threads, the installers above can not be seen as
> official Apache NetBeans installers -- though that should be the aim for
> the next releases.
>
> However, as discussed in other threads some time ago, there's nothing wrong
> with explicitly linking to the above on the page below so long as we clear
> state that these are not official Apache NetBeans installers, though that
> they should be seen as experimental installers for the next release:
>
> https://netbeans.apache.org/download/nb110/nb110.html
>
> Do we agree with this? Interested in responses and if everything is
> favorable and no objections, will add the info as described above to the
> page above in 24 hours.
>
> Thanks,
>
> Gj
>

Re: netbeans slack on theasf

[Wade Chandler]

Is there a limitation on the Jira tooling preventing using the current
Slack? Seems easier to keep it in one place at the moment, then have a
bigger discussion about moving it all to Apache Slack otherwise. I don't
know about others, but I am a member of multiple Slack groups, per
different OSS groups even, so don't see adding a group as a limitation.
That part is super easy.

For instance, there are multiple channels on the current Slack group, and
NetBeans covers many technologies. The channel names in Slack have fairly
short char limits, so preceding them all with netbeans- would not work
well. This seems way more difficult that explaining where Slack is and how
to access it for everything NetBeans, but we can see.

I guess I'm just thinking priorities. I'd rather spend time getting more of
the project itself in working order right now unless there is a real
limitation. Initially we had to debate the use of Slack at all as an
example, so some time under the bridge there. But certainly interested in
everyone's opinions.

Thanks

Wade


On Wed, Apr 3, 2019, 05:39 Eric Barboni  wrote:

> Hi folks,
>
>
>
> As part of a request to connect Jenkins build (for maven and apidoc) to our
> netbeans.slack, I was told that we could move/migrate to the slack atasf
> to
> use  their .
>
>  Maybe the more technical channels, like jira,github-repo can be recreated
> at asfslack.
>
>
>
>   It may be easier for people having multiple apache project to be there.
>
>
>
>
>
> Regards
>
> Eric
>
>

Re: Improve indexing and file indentification?

[Wade Chandler]

This specific item would be its own unique topic and request IMO from indexing. 
I'd create a Jira ticket for it (please do); I tend to think this would be a 
“search everything” kind of an item versus specifically a symbol though, but 
hey.

Wade


> On Mar 10, 2019, at 5:59 PM, Jean-Marc Borer  wrote:
> 
> And what about the "omni open" function?
> 
> I know you can find a file, but if it appears among the indices of the
> "open symbol" this would be nice, no?

Re: Improve indexing and file indentification?

[Wade Chandler]

I also allocate a good lot of memory to my IDE (NB & IntelliJ both), and have 
the same experience. That said, there are still times I have to kill NB due to 
the CPU taking off and indexing too much. I think many of the finds which came 
out of the ticket I saw Lazlo working on will be some great improvements; I’d 
seen similar.

Wade

> On Mar 8, 2019, at 12:53 PM, Lars Bruun-Hansen  wrote:
> 
> Regarding performance:  In my experience part of the problem has been
> (historically) that the default -Xmx setting for NB IDE has simply been too
> low. People just don't go to etc/netbeans.conf on their own and change it.
> Anyway, when you compare the two IDEs remember to make sure they have been
> allocated exactly the same amount of memory. Do *not* compare
> out-of-the-box (no tweaking) performance. In short: Once I learned that I
> should always allocate memory handsomely to NB IDE I've never experienced
> problems with performance. I can't remember that I've had 50 projects open
> at the same time, but something like 40 for sure. No probs.
> 
> This is not to say that NB IDE can't be improved in the performance area.
> Above is just my personal/anecdotal experience.
> 


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Improve indexing and file indentification?

[Wade Chandler]

Do the later JDKs now automatically choose a good value or behave more 
automatic (can increase at runtime or something)? Before they did not; the 
defaults differed between platforms, and were not very high, so the only way to 
get them was to set them. I wasn’t sure what you meant by “removed”, so wanted 
to be sure.

Thanks,

Wade

> On Mar 8, 2019, at 12:59 PM, Laszlo Kishalmi  
> wrote:
> 
> Just FYI: In NetBeans 11.0 we have removed the restrictive memory settings.
> 
> On 3/8/19 9:53 AM, Lars Bruun-Hansen wrote:
>> Regarding performance:  In my experience part of the problem has been
>> (historically) that the default -Xmx setting for NB IDE has simply been too
>> low. People just don't go to etc/netbeans.conf on their own and change it.
>> Anyway, when you compare the two IDEs remember to make sure they have been
>> allocated exactly the same amount of memory. Do *not* compare
>> out-of-the-box (no tweaking) performance. In short: Once I learned that I
>> should always allocate memory handsomely to NB IDE I've never experienced
>> problems with performance. I can't remember that I've had 50 projects open
>> at the same time, but something like 40 for sure. No probs.
>> 
>> This is not to say that NB IDE can't be improved in the performance area.
>> Above is just my personal/anecdotal experience.
>> 
>> /Lars
>> 
>> 
>> On Fri, Mar 8, 2019 at 5:08 PM Jean-Marc Borer  wrote:
>> 
>>> Hi guys,
>>> 
>>> In the office we were comparing Netbeans to IntelliJ indexing performances
>>> and I have to admit that IntelliJ performs very well here (I was
>>> impressed). We had about 50 maven projects open at the same time. I wonder
>>> how IntelliJ reaches such performances.
>>> 
>>> Another thing that could be improved in NB would be that when you look for
>>> symbols (CTRL+o), it should also propose file names. This is useful when
>>> you have config files or other assets in your project(s) that are not only
>>> contain code. Does this feature already exist in NB?
>>> 
>>> 


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Question on: Gradle Project Open Defaults

[Wade Chandler]

I prefer it to work and be just like working with Gradle at the CLI; my
tasks and config etc. Not sure other context to your question if there is
any. What happens from a user perspective with either course? If it loads
fast, but doesn't fully work, and I can't be productive, then that would be
bad for me. I work like this personally:

1) something quick to view and maybe make a one line change? Vi or VS Code.

2) Heavy duty coding session? IDE ... Because I know I need all the nice
tools.

Thanks

Wade


On Sat, Feb 2, 2019, 19:08 Laszlo Kishalmi  Dear Gradle Users,
>
> I just would like to ask your opinion what would be the better:
>
>   * Open project fast, but probably with missing dependencies.
>   * Open project slower, but loading the initial set of required
> dependencies (this is the default now)
>
> Laszlo Kishalmi
>
>

Re: State of the Apache NetBeans installers

[Wade Chandler]

On Sat, Feb 2, 2019, 15:43 Emilian Bold <

>
> If Apache gets more lenient / clear on bundling I could also create a
> 'vanilla NetBeans' package with no bits changed except the additional JDK.
> Although I suspect the general idea is for Oracle or Amazon to do some
> JDK+NetBeans bundle release and not smaller projects.
>

What does this mean necessarily? My understanding is you could create a
bundler that is clear to spell out it is a bundler, and is just installing
"Apache NetBeans + AdoptOpenJDK" as an example as long as it is just a
redistribution of unchanged parts.

Too, it seems we could provide an installer that downloads the JDK for the
end user, but that also can create and output a bundled installer for that
end user; they would be building and distributing it. They could then place
that on any server they wish, that isn't Apache's, and share that; even use
it to create their Enterprise installers. We could even have that allow all
headless creation to allow it to work in scripted setups such as something
using Ansible. We could even then have Oracle and Amazon use that, but
certainly others like Pivotal or even an arrangement with AdoptOpenJDK to
distribute could be made.

Thanks

Wade

Are we working from "release" branches or from master ahead of a release? I think Jenkins suggests "release*" is the case. Now wondering processes etc.

[Wade Chandler]

Hey all. I was building from master recently, and had various 
issues/exceptions, and of course know we have a vote on 10 going on. Knowing 
NetBeans past, I looked for the release branches, and saw branch release100 out 
there. I wasn’t sure the current process as I had been out of touch for a while 
(work and all).

Is the idea to create a release branch, and then work there when we get “close” 
to shooting for a release? Too, how are we keeping items synced up between 
master and release* after we we start that process if so? Maybe even a link 
will work if the process is documented. I’m assuming changes in both master and 
release for the near term, so just looking for guidance.

Jenkins suggests yes on the release branch, but not sure the rest 
https://builds.apache.org/view/Incubator%20Projects/job/incubator-netbeans-release/configure
 
<https://builds.apache.org/view/Incubator%20Projects/job/incubator-netbeans-release/configure>
 

Thanks much,

Wade

===

Wade Chandler
e: cons...@wadechandler.com
t: @wadechandler
https://www.linkedin.com/in/wade-chandler

Re: [website] maven artefacts webpages

[Wade Chandler]

On Fri, Oct 26, 2018, 05:28 Eric Barboni  wrote:

>
> Maybe it is possible to have a new "site git repo" for the maven tooling
> site that we can put on a subfolder of netbeans.apache.org so it make at
> the
> end a  big site.
>

This sounds like an idea. I think you are suggesting a job or something
that deploys the changes to a sub-folder on the site from a separate git
repo. Would need to ask infra (Daniel) if possible; seems it would be. Then
would need a request to set that up I think.

Wade

Testing please ignore; having issues

[Wade Chandler]

Testing please ignore; having issues

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Testing my account; please ignore

[Wade Chandler]

Test

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Improving infra @ netbeans?

[Wade Chandler]

This would be great for me as it is easy to fall behind when you have to
come and go in spurts as things are moving so fast in some areas it is hard
to keep up. It would make it easier to contribute further to some things
IMO.

Thanks so much Antonio

Wade


On Wed, Jul 11, 2018, 01:19 Antonio  wrote:

> I'll try to set up some pages with my understanding of how things work.
> Probably by next week. I'll keep you posted of my findings :-)
>
> Cheers,
> Antonio
>
> On 10/07/18 20:10, Geertjan Wielenga wrote:
> > Yes, on the Wiki, this info is needed.
> >
> > Gj
> >
> >
> > On Tuesday, July 10, 2018, Emilian Bold  .invalid>
> > wrote:
> >
> >> Yes, this is so necessary!
> >>
> >> --emi
> >>
> >> ‐‐‐ Original Message ‐‐‐
> >>
> >> On 10 July 2018 8:55 PM, Antonio  wrote:
> >>
> >>> Hi all,
> >>>
> >>> I think we should start documenting how our jenkins jobs / vm box /
> >>>
> >>> update center / etc. are working, so that everybody is able to handle a
> >>>
> >>> problem in a hurry.
> >>>
> >>> Which areas need improvement if any? Do we want a confluence specific
> >>>
> >>> page for documenting stuff? This is: what are we doing wrong and could
> >>>
> >>> be improved?
> >>>
> >>> Thanks,
> >>>
> >>> Antonio
> >>>
> >>>
> >>> 
> >> 
> >> 
> >> 
> >> 
> >> -
> >>>
> >>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> >>>
> >>> For additional commands, e-mail:
> dev-h...@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-unsubscr...@netbeans.incubator.apache.org
> >> For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: [DISCUSS] Merging back netcat@ into the dev@ mailing list

[Wade Chandler]

I think it would be good. We already have dev and user. The same reason we
decided to start with the 2 until we had any real need for more, versus all
the tech specific lists we had at NetBeans.org, seems reasonable, and to
apply here as well. If it is an issue, we'll know/see it, and if not, then
1 less place to look for info. So, +1 from my pov.

That said, it would be good to see the netcat members view on it. One can
certainly contribute there without all the dev@ noise if they like it, so
from their view, it may not be so simple. I really think that should have
some weight.

Either way, it does need to be clear any dev decisions or direction needs
to go to dev@ as netcat is not the place for community votes.

Wade

On Sun, Jun 24, 2018, 17:15 Emilian Bold 
wrote:

> Hello,
>
> I believe all the Apache NetBeans contributors should use the dev@
> mailing list.
>
> The dev@ mailing list is our Apache 'central square' so to speak and even
> if we don't work on the same particular issue, we should get to know
> each-other, at least by name.
>
> The separate netcat@ mailing list is splitting the contributor community.
>
> I think initially netcat@ was created because it might have too much
> traffic. But looking at the archives I see dev@ has an average of 460
> emails per month while netcat@ is much more spiky and reached its maximum
> of 350 emails during March while now it's at 30-40 emails per month.
>
> Of course, emails are grouped into threads / topics so they are easier to
> follow or ignore. Thus, the load is not that much.
>
> Personally, I was surprised a while back how familiar Efrem Mc was on the
> dev@ mailing list and I just didn't know who he was. Turns out, he is
> much more active in NetCAT but I was not subscribed to netcat@ at that
> time.
>
> Enthusiasm is contagious and if people doing NetCAT care a lot about
> something it will spill into development interest too. And a development
> problem might invite some second look from quality acceptance.
>
> So my suggestion is to bring all NetCAT communication onto the dev@
> mailing list.
>
> I would like to hear your opinion and I hope that at the end we'll have a
> VOTE about this.
>
> PS: I'm crossposting this to both the dev@ and the netcat@ mailing list.
>
> --emi
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Next release can be put together, volunteer for next release manager needed.

[Wade Chandler]

Just so everyone knows how semver works (especially semver 2), and if we were 
to need a bigger convo, we can start another thread (just putting out info for 
now):

https://semver.org/ <https://semver.org/>


> On Jun 21, 2018, at 6:58 AM, Wade Chandler  wrote:
> 
> Why not semantic versioning? Asking as it takes care of different meta info 
> such as what we are discussing, and it is quickly becoming an OSS defacto 
> standard from what I can tell anecdotally.
> 
> Thanks,
> 
> Wade
> 
>> On Jun 21, 2018, at 6:06 AM, Neil C Smith  wrote:
>> 
>> On Thu, 21 Jun 2018 at 10:51, Geertjan Wielenga
>>  wrote:
>>> 
>>> But, from my point of view, anything is fine, e.g., candidate-1,
>>> candidate-2, etc.
>> 
>> Yes, or -vote1?!  But something that isn't -rc1 anyway.  In fact,
>> perhaps a tagging / naming strategy that deliberately doesn't look
>> like semantic versioning would be a good idea?
> 

Re: Next release can be put together, volunteer for next release manager needed.

[Wade Chandler]

+1 to Sven, Neil, and Antonio’s suggestions plus Emilian. It will be great to 
have Groovy and JS in play!

Thanks,

Wade

> On Jun 21, 2018, at 5:43 AM, Sven Reimers  wrote:
> 
> I am in the same situation.
> 
> I think Neil's suggestion about we (the newbies) are going for the next
> alphs... releases to setup stuff from our side and learn the process.
> 
> In case Emi will not be able to do it - I am still in - but Emi would be my
> preference.
> 
> Upwards and onwards
> 
> -Sven
> 
> Neil C Smith  schrieb am Do., 21. Juni 2018, 11:14:
> 
>> On Thu, 21 Jun 2018 at 05:34, Antonio  wrote:
>>> I'd like to do this in the future, but I don't think I'd do a good job
>>> right now (this requires setting up things and seeking and reading
>>> documents, and I won't be able to do that right now). So please go ahead.
>> 
>> That pretty much describes where I am right now too!  Also, in some
>> ways it would make sense for Emi to do this, and for us newbies to get
>> our heads around this on pre-releases?
>> 
>>> I can help by preparing up a 9.0 release webpage(s) in draft mode, if
>>> you want, so that we can make it live quickly by changing the
>>> "jbake-status" [1] in the metadata from "draft" to "published".
>> 
>> Sounds a plan!  Let me know if you want me to look at anything.  And,
>> having been a little disconnected the last few weeks, are we all set
>> with inbound links and redirections in/from the IDE now?
>> 
>> Incidentally, I'll be meeting the original JBake developer next week
>> at JManc - we got any questions? :-)
>> 
>> Best wishes,
>> 
>> Neil
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
>> For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Next release can be put together, volunteer for next release manager needed.

[Wade Chandler]

Why not semantic versioning? Asking as it takes care of different meta info 
such as what we are discussing, and it is quickly becoming an OSS defacto 
standard from what I can tell anecdotally.

Thanks,

Wade

> On Jun 21, 2018, at 6:06 AM, Neil C Smith  wrote:
> 
> On Thu, 21 Jun 2018 at 10:51, Geertjan Wielenga
>  wrote:
>> 
>> But, from my point of view, anything is fine, e.g., candidate-1,
>> candidate-2, etc.
> 
> Yes, or -vote1?!  But something that isn't -rc1 anyway.  In fact,
> perhaps a tagging / naming strategy that deliberately doesn't look
> like semantic versioning would be a good idea?


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: NetBeans Slack?

[Wade Chandler]

OK, it looks like Slack has finally made this easier. It looks like anyone can 
use this link I just created, and self invite. Nice!

https://join.slack.com/t/netbeans/shared_invite/enQtMzcyNzM5MjYwMDUxLTg1YmVkMWUxYzlhMTE3NzRiMTM4N2E0Yjc5MDdkYzZkM2Q5ZjI5ZTE5NmE3MTZmNTJlYjBmMGFhOTQwNTM2YmQ

We will get this up on the site.

Wade



> On May 30, 2018, at 9:18 AM, Wade Chandler  wrote:
> 
> Yes, it had a form, on a landing page, and then allowed folks to self invite, 
> and it had a bot you invited to Slack to let it manage it. They had other 
> bots too. Anyways, we could definitely implement it ourselves, but the infra 
> and service was free. We’d have to setup something on the VM at Apache to do 
> it (that or run something in the cloud). There are some OSS packages to do 
> this too. Or, we find some other service. If we do get another service, I 
> think we should give it a CNAME, so if we change it it doesn’t matter going 
> forward; well, CNAME either way.
> 
> Wade
> 
> 
>> On May 30, 2018, at 8:52 AM, Emilian Bold > <mailto:emilian.b...@protonmail.ch>> wrote:
>> 
>> What did this service do? Have some robot that allows people to self-invite? 
>> Does Slack have this API still? Maybe it was removed.
>> 
>> If it's still possible, we could implement something like this.
>> 
>> --emi
>> 
>> ‐‐‐ Original Message ‐‐‐
>> 
>> On 30 May 2018 3:07 PM, Wade Chandler > <mailto:wadechand...@apache.org>> wrote:
>> 
>>> My best guess is that StackToDo has shuttered their doors, but I can’t find 
>>> anything about it online, just their sites are all down, and some others 
>>> asking such questions.
>>> 
>>> I will try to get us a new solution. In the mean time, if anyone would like 
>>> to join the Slack group, just email me the email address you’d like to use, 
>>> and I’ll manually invite you; wadechand...@apache.org 
>>> <mailto:wadechand...@apache.org>.
>>> 
>>> Wade
>>> 
>>>> On May 29, 2018, at 1:02 PM, Wade Chandler wadechand...@apache.org 
>>>> <mailto:wadechand...@apache.org> wrote:
>>>> 
>>>> I will have to look at it. It seems the provider is having issues or 
>>>> something else is happening. I noticed other users of the service sites 
>>>> are down.
>>>> 
>>>> Wade
>>>> 
>>>>> On May 29, 2018, at 12:40 PM, Mike Duigou >>>> <mailto:m...@bondolo.org> mailto:m...@bondolo.org 
>>>>> <mailto:m...@bondolo.org>> wrote:
>>>>> 
>>>>> I've been trying to join the NetBeans slack but the signup site,
>>>>> 
>>>>> https://netbeans.signup.team/ <https://netbeans.signup.team/> 
>>>>> https://netbeans.signup.team/ <https://netbeans.signup.team/>, mentioned 
>>>>> on the wiki
>>>>> 
>>>>> (https://cwiki.apache.org/confluence/display/NETBEANS/How+to+Participate 
>>>>> <https://cwiki.apache.org/confluence/display/NETBEANS/How+to+Participate> 
>>>>> https://cwiki.apache.org/confluence/display/NETBEANS/How+to+Participate 
>>>>> <https://cwiki.apache.org/confluence/display/NETBEANS/How+to+Participate>)
>>>>> 
>>>>> appears to be defunct.
>>>>> 
>>>>> Is there an alternate way to join? Attempting to join netbeans.slack.com 
>>>>> <http://netbeans.slack.com/> http://netbeans.slack.com/ 
>>>>> <http://netbeans.slack.com/>
>>>>> 
>>>>> requires administrator approval of my email address but doesn't suggest
>>>>> 
>>>>> who I should contact.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Mike
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org 
>> <mailto:dev-unsubscr...@netbeans.incubator.apache.org>
>> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org 
>> <mailto:dev-h...@netbeans.incubator.apache.org>
>> 
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists 
>> <https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists>
>> 
>> 
>> 
> 

Re: NetBeans Slack?

[Wade Chandler]

My best guess is that StackToDo has shuttered their doors, but I can’t find 
anything about it online, just their sites are all down, and some others asking 
such questions.

I will try to get us a new solution. In the mean time, if anyone would like to 
join the Slack group, just email me the email address you’d like to use, and 
I’ll manually invite you; wadechand...@apache.org.

Wade



> On May 29, 2018, at 1:02 PM, Wade Chandler  wrote:
> 
> I will have to look at it. It seems the provider is having issues or 
> something else is happening. I noticed other users of the service sites are 
> down.
> 
> Wade
> 
> 
> 
>> On May 29, 2018, at 12:40 PM, Mike Duigou > <mailto:m...@bondolo.org>> wrote:
>> 
>> I've been trying to join the NetBeans slack but the signup site,
>> https://netbeans.signup.team/ <https://netbeans.signup.team/>, mentioned on 
>> the wiki
>> (https://cwiki.apache.org/confluence/display/NETBEANS/How+to+Participate 
>> <https://cwiki.apache.org/confluence/display/NETBEANS/How+to+Participate>)
>> appears to be defunct. 
>> 
>> Is there an alternate way to join? Attempting to join netbeans.slack.com 
>> <http://netbeans.slack.com/>
>> requires administrator approval of my email address but doesn't suggest
>> who I should contact. 
>> 
>> Thanks, 
>> 
>> Mike
> 

Re: NetBeans Slack?

[Wade Chandler]

I will have to look at it. It seems the provider is having issues or something 
else is happening. I noticed other users of the service sites are down.

Wade



> On May 29, 2018, at 12:40 PM, Mike Duigou  wrote:
> 
> I've been trying to join the NetBeans slack but the signup site,
> https://netbeans.signup.team/, mentioned on the wiki
> (https://cwiki.apache.org/confluence/display/NETBEANS/How+to+Participate)
> appears to be defunct. 
> 
> Is there an alternate way to join? Attempting to join netbeans.slack.com
> requires administrator approval of my email address but doesn't suggest
> who I should contact. 
> 
> Thanks, 
> 
> Mike

Re: Contrib repo & Community Plugin Repo

[Wade Chandler]

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  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

[Wade Chandler]

On May 28, 2018, at 10:50 AM, Emilian Bold  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 


The plugin portal also offers an opportunity for this.

Wade

Re: What Coding Conventions Should We Follow Now? What should the IDE default to?

[Wade Chandler]

> On Mar 16, 2018, at 6:46 AM, Emilian Bold <emilian.b...@protonmail.ch> wrote:
> 
>> Rather than discussing the actual conventions, make sure the IDE can read 
>> and apply settings from Eclipse easily and exactly.
> 
> Not sure what this means. Just make sure plugins are able to format the code?
> 
> Still, NetBeans does provide formatting and coding hints. Both should follow 
> /something/ and I assume Wade was wondering what standard to follow.
> 

Exactly, and too, what makes the most sense.

> My angle is that NetBeans, just like Eclipse, *is* a de-facto standard. 

I don’t necessarily agree this makes the most sense, but I understand your 
point. I guess for me this comes up as a source of friction when working on 
projects. Intellij is by far the most used with Eclipse next, and then us. I 
think either choosing some agnostic, and well written standard, or using a real 
de-facto, sort of like how Spring became one over JEE, being used more, makes 
for less friction.

Perhaps the answer is to provide NBs historical one as it is our code base, and 
use that one with our project (NetBeans itself). Then provide some others which 
are largely popular such as IntelliJ, Eclipse, Google, and “Old Sun Java” for 
users of the IDE to use out of the box. It doesn’t seem likely teams are going 
to go, oh, yeah, the few NB IDE users formatting options win out over everybody 
else, and too, other projects are not likely to provide a format which is easy 
to just import without some upfront setup on behalf of the NB users. Too, most 
places in my experience don’t come up with their own formatting. They generally 
pick one which exists and is published. Us providing common ones makes that 
even easier for IDE users.

Thanks for the replies and feedback all. I think I’ll look at this area soon to 
see what can be done.

Wade


===

Wade Chandler
e: cons...@wadechandler.com
t: @wadechandler
https://www.linkedin.com/in/wade-chandler


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Time to branch for the release candidate?

[Wade Chandler]

+1 and even if we don’t have a “dev” branch, I think we should be able to 
release from master without branching. We should be working to stabilize things 
near a release, and perhaps we ask folks not to merge new features to master, 
but only fixes for a period of time. If we could support feature flags, then 
even better, and for new modules and such I think we can through configuration 
and clusters, to not have them enabled and included by default, but not with 
big new features to existing modules. We would need new switches in the config 
file for those. Then new work can be enabled or disabled for a release 
depending on how far along it is.

Either way, I feel master should always build, run, and be as stable as 
possible. Now, in this interim phase where we are still trying to get over to 
Apache all that is NB, it may be harder or nearly impossible since it is so 
much to bring over, but I think that should be our goal going forward once the 
“drop” has happened.

My $0.02,

Wade


===

Wade Chandler
e: cons...@wadechandler.com
t: @wadechandler
https://www.linkedin.com/in/wade-chandler


> On Apr 17, 2018, at 10:09 AM, Christian Lenz <christian.l...@gmx.net> wrote:
> 
> Master shouldn’t be that one, where the wild development is going on. Master 
> should be that one which is already live.
> In General, what gitflow does. Wild development is going on on the dev 
> branch, for the next release. If whatever is finished, there is a release 
> branch. After that, it will merged into master and created a tag.
> 
> If this is not possible, then an other solution is that develop stays clean 
> and always releasable. You only work on Feature branches. After the Feature 
> is finished and ready to go, it will merged into develop. Someday you can 
> create a release branch of develop.
> 


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: IntelliJ IDEA vs Netbeans

[Wade Chandler]

On Fri, Apr 20, 2018, 04:49 Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> Deklunkifyng NetBeans was never a big goal in Oracle though now, in Apache,
> this really seems a doable target and one we can work on together. Many
> deklunkification tasks are probably quite trivial. How best to tackle this
> and who will take the lead in beginning to list these? Any deklunking I am
> able to implement I will implement, just provide a very specific list and
> we’ll form a NetBeans deklunking taskforce.
>

+1 this has been my goal with the move to Apache, and once we get more of
the other bits over plan to try to tackle much of it. I love
"Deklunkification Taskforce"!

My biggest item I plan to look at is the indexing which blocks some things,
and impacts performance. It is really as far as I can tell the main
performance difference as it has impacts on the editor and other UI actions.

I much more prefer the integration of NB with the tools project support
versus rolling our own. The classpath and build differences can really be a
bear sometimes when having differences between the two, and builds or
executions work in one side, but not the other.

So, I find this a strength of NB, as I have helped team members over the
years with such issues in other environments.

I will create a page in the Wiki later if nobody else has; right now I must
get ready for CodeStock!

Wade

Re: How/where exactly to host the NBMs for the 9.0 release

[Wade Chandler]

On Mon, Apr 9, 2018, 05:35 Neil C Smith <neilcsm...@apache.org> wrote:

> On Sun, 8 Apr 2018 at 03:23 Wade Chandler <wadechand...@apache.org> wrote:
> > That stuff will make the site git repo bigger and bigger quite fast will
> it
> > not? That will start to make it a barrier to contribute if so. Are we
> > talking about uploading separate from the git repo to the hosted site?
> >
>
> How do you figure that?  I'm only talking about one XML file.
>

It really depends on release strategy I suppose. The 8.2 file was 1.24MB.
There was a different one for 8.1. Maybe if we have rolling updates for a
longer timeframe it won't create multiple files per year.

Small compared to some things, but if stuff that ages faster like that, and
if separate paths, seems like it would bulk up the site repo over time for
no extra value after a period; 9.0 versus 9.3.

Maybe we could have an updates repository that holds that stuff separately
with some kind of redirects like what happens with updates.netbeans.org
now, which has a similar auto build as main site.

Just thinking about how long it takes to clone the repo as it is just to
add/update docs (especially for newbies). Maybe we do it for now, and later
think about how we can better split up the site repo to allow quicker
cloning and editing. Feels like it should be more nimble than the IDE
repository.

Thanks

Wade

Re: How/where exactly to host the NBMs for the 9.0 release

[Wade Chandler]

On Thu, Apr 5, 2018, 10:57 Neil C Smith  wrote:

> On Thu, 5 Apr 2018 at 15:15 Jan Lahoda  wrote:
>
> > -release the NBMs and the catalog as part of the convenience binaries
> (this
> > will probably need a little tweaking)
> > -have a (NetBeans 9.0-specific) URL setup on the netbeans-vm, like e.g.:
> > http://netbeans-vm.apache.org/updates/9.0
> > which would do a redirect to the Apache release using:
> > http://www.apache.org/dyn/closer.lua?action=download=
> >
>
> Why do we need to put this on the VM at all then?  Couldn't we just
> generate the catalog.xml with those links already?  And then host the
> catalog with the rest of the website?
>

That stuff will make the site git repo bigger and bigger quite fast will it
not? That will start to make it a barrier to contribute if so. Are we
talking about uploading separate from the git repo to the hosted site?

Wade

Re: NetBeans in April 2018 podling report

[Wade Chandler]

Thanks Gj!

Wade

===

Wade Chandler
e: cons...@wadechandler.com
t: @wadechandler
https://www.linkedin.com/in/wade-chandler



> On Mar 30, 2018, at 5:12 AM, Geertjan Wielenga 
> <geertjan.wiele...@googlemail.com> wrote:
> 
> Hi all,
> 
> Added some initial content to the podling report for April 2018 for Apache
> NetBeans (incubating):
> 
> https://wiki.apache.org/incubator/April2018
> 
> Please take a look and provide responses in this thread about anything that
> should be added, changed, etc.
> 
> For your reference, see the previous podling report where we participated,
> i.e., each 4 months this is something we need to do to report progress:
> 
> https://wiki.apache.org/incubator/January2018
> 
> Thanks,
> 
> Gj

Re: [PMC Chairs] Jenkins job permissions

[Wade Chandler]

On Fri, Mar 23, 2018, 05:22 Bertrand Delacretaz 
wrote:

> Before we do that, are other committers willing to get the same
> permissions?
> You need to be familiar with Jenkins of course.
>

I am. I am also familiar with Jenkins.

Wade

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

[Wade Chandler]

Which is funny to me because when I was working most of the time with Swing 
(the IDE and platform apps), I focused mainly on responsive UIs. I think a lot 
of it comes down to specifying specifically what we are talking about. Given a 
specific UI of form components, making a responsive and expansive UI in Swing 
has been fairly trivial from my experience. The same with web UIs with CSS. 
With both you have to know what actually works for the specific items you are 
laying out. For instance, a web UI which hides the wrong components at the 
wrong time isn’t responsive; it will just be a bad UI.

Wade

> On Mar 17, 2018, at 7:38 AM,  
>  wrote:
> 
> Fully agree, and Swing and JavaFX stopped development before the concept of 
> "responsive UIs" became popular. So they have nothing for that.
> 
> I agree that layout via css used to be painful and hard to understand 
> sometimes, but Flow and especially Grid Layout has completely solved this for 
> me. 
> 
> --Toni
> 
> 
> -Ursprüngliche Nachricht-
> Von: Neil C Smith  
> Gesendet: Samstag, 17. März 2018 11:06
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Usability study was: Think Java, not Electron! was: Apache 
> HTML/Java UI
> 
> On Sat, 17 Mar 2018, 07:34 Dmitry Avtonomov, 
> wrote:
> 
>> ​All I'm saying is that with the last N years of unprecedented 
>> attention the web technologies have leaped light years ahead of 
>> everything else in terms of basic UI.
>> ...
>> All I need is a good framework on top of swing that would help me out 
>> with those things. In JS there's probably 100s.
>> 
> 
> You could probably manage all the validation and error display requirements 
> you mention with HTML5's built in form validation without adding any JS at 
> all.
> 
> As someone working heavily with both Swing and HTML/CSS I find the idea that 
> Swing's layouts are better quite amusing, or I would if I didn't have to 
> fight with them so often! ;-) Mig is about the only one I use from code, 
> Matisse is good but I find its output counterintuitive sometimes.
> 
> Best wishes,
> 
> Neil


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: AW: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Wade Chandler]

On Mar 15, 2018 10:59,  wrote:

These things can happen in parallel. I for my part cannot help much with
Python or Groovy features, but I can help with the POCs to improve NB UI
and make it future proof. If for example we manage to replace JavaFX
WebView with something better, contributors like Chris Lenz will be able to
use more HTML5 features for writing their plugins and the performance of
HTML-based plugins will improve.


I agree with that.

Maybe some of the Swing/JavaFX developers will also try it out and realize
that developing with modern ui patterns like MVVM can dramatically speed up
development, and lead to more testable and stable code while reducing the
LOC. This would have the immediate effect of better code that needs less
maintenance.


MVVM is certainly possible now considering the components already have
their own model, so VM there, then other logic is a translation of the
Angular concept of a service, and data models which differ from the
component model is that. Now, one can certainly write better or worse UI
code in a tightly coupled manner. But, and I have seen it, one can also do
that with Angular. So, I get what you are saying here, and only agree in
that there are plenty of people who don't know how to decouple UI logic,
and the Angular style guide does a better job of getting people down the
right path than the Swing tutorials.

But we can also offer them a way to still run their ( in my opinion
horribly archaic  ) Swing code.


Ha...see what you did there. You have gone to the dark side, but it's cool.
I still like you!


As a side effect we could also replace the embedded Browser for debugging
web applications with a real browser and make Web Development in NB even
more attractive. Projects like the Oracle JET support in NetBeans, but also
EE projects could directly benefit from that.


Yeah, as part of the web support, such things sound reasonable for those
purposes no matter what.

You're right these changes are driven by longer term goals, but they will
also create huge short term improvements.


I will wait to see on it then. In the mean time I will work on my parallel
bits :-)

And since there's a lot of confusion here between "web technologies" and
"web applications": I for my part don't want to run NetBeans in a Browser.
I want NetBeans to remain a traditional Desktop application, which can use
modern HTML5 UIs


Got it.

and is prepared for the end of Swing.


Dark man; dark. Lol.

Thanks

Wade

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFXfromOracle JDK

[Wade Chandler]

> On Mar 15, 2018, at 8:54 AM, Neil C Smith  wrote:
> 
> Anyway, this whole thing is going a bit in circles. We need to look at
> improving the POCs in NetBeans to be able to show where (and where not)
> this approach is viable and useful.
> 

Agreed, but I think, so IMO, those just take us off the things that will 
actually have direct and immediate impacts. We can work on NB just as it is, 
and work to fix the index lock issues, add new Java parsing, add better 
language and feature support for some things like Groovy and Python, and 
generally move ahead, even while fixing some issues in Swing/AWT, or bog down 
in all this talk of web UIs which starts to make a lot of work which in the end 
didn’t really move the needle because we’ll still have a desktop IDE, but a lot 
of time would have been spent to just get further behind.

Wade


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: AW: AW: Think Java, not Electron! was: Apache HTML/Java UI instead of

[Wade Chandler]

On Mar 15, 2018 06:19, "Christian Lenz"  wrote:

I break with swing, because of the Mantisse Editor. It is ok but Needs
enhancements. And I’m fast to create UIs and with JS the binding etc.


I think some of the issues with at least some web development is the need
to have pixel perfect design. That doesn't really fit many use cases, and
graphics go out, and responsive layout is the main thing. Matisse and the
GroupLayout is that. So, it needs some improvements. We can do that once
the full donation is done.

I get what you are saying about pluggable views, but even if we support
those, that seems a heavy burden for the IDE itself to have all runtimes
embedded because one wants to use what would seem unrelated plugins to the
underlying technology. That would definitely make the IDE bloated for
unrelated platform work; say I'm just building WordPress stuff with it.

Wade

Re: AW: Think Java, not Electron! was: Apache HTML/Java UI instead of

[Wade Chandler]

On Mar 13, 2018 08:39, "Christian Lenz"  wrote:

There are big players out there. And why I love electron? Because it is
fucking HTML, CSS and JS AND for the Backend too. This eco system was build
for fullstack developers, who wants to create desktop applications with
HTML/CSS/JS still in the background.

You know my example NbScratchFile, this is I think one of the best solution
to promote a plugin for NetBeans, which was written in HTML, SCSS/CSS,
TS/JS with a Framework called Knockout, a buildsystem with webpack and a
communication with Java in the backend. Why I’ve chosen it? Because I
wanted to write a plugin for NetBeans but w/o swing. The Mantisse editor is
cool but far away from perfect, I created a ticket for a big problem to
align checkboxes with labels pixel perfect, inside the Editor:
https://netbeans.org/bugzilla/show_bug.cgi?id=257519

Why I’m not writing the controls in Java? Sry but no, we have Qt, we have
WPF (C# with XAML) and we have WYSIWYG editors to create UIs quick and fast
and sometimes dirty. In HTML I don’t need such editor. It is my daily
business, I have chrome with the powerful and best DevTools ever to see my
progress immediately and I’m fast w/o having an editor.


So why not use Electron and VS Code and contribute to them? Not meant to be
a flame, but those things exist as they are, and are what you say you want.
You don't want to write in Java. They are the thing you want.

I mean, I use NB and contribute to it because of what it is, and it's
unique characteristics and platform. Many of us have an appreciation for
Swing and NB RCP. I can build UIs and components in the technology and love
it. I also build web apps with Angular, but I don't want the IDE I'm
writing to be that, nor NB which I've put a lot of energy into over the
years; it is different, and that's a good thing.

Frankly, were it changing into that, an Electron clone, then as you say,
lots of big players there, why wouldn't I just go to those open source
projects which are already that instead of spending my time changing
something else into essentially that? Seems a better use of my life and
time.

Electron is OK. It also produces some bloatware, and that is just truth.
Look at how much RAM and all Slack and Code use with some simple things
running.

More than Java was compared to the natives we quit building back in the
day. Even on a quad core 16GB Mac they sometimes get weird issues, lock,
and do what software does. That's life, but look at all those running
subprocesses.

Now, NB the IDE does too, but that is the editor index bug. Not the UI. We
at least know those headaches, and where to start looking to address those
issues once moved over. Too, you say it looks like crap, but I disagree.

Given Swing/AWT, what about IntelliJ, Android Studio, Web Storm, etc? All
Swing/AWT. Very popular. I don't think they look like crap either.

They look like IDEs. VS Code looks roughly the same. I also use it with my
other tools. It doesn't jump out to me as something extra pleasing in the
visual department compared to other IDEs and text editors.

It has its pluses and minuses, but it's look compared to a Darkula NB
install isn't necessarily leaps and bounds over anything else. It does let
me edit Dotnet Core quickly on my Mac though.

Wade

Re: Status of the documentation?

[Wade Chandler]

Antonio and Neil,

I was checking out the site today, and you guys have it rocking! Awesome!
The conversion bits you plugged in are sharp too. Great work!

Thanks so much!

Wade

On Mar 14, 2018 17:16, "Antonio"  wrote:

Hi,

Yep. I can see those terrific HTML files out there [1] :-)

Since we now have this "html-cleanse-to-asciidoc-and-markdown" hammer, and
now that everything looks like a nail, I think I'll give it a run and try
to generate some asciidoc.

Who knows, we could even build an ePub with the user guide, or upload it to
the website.

Cheers,
Antonio

[1]
https://github.com/apache/incubator-netbeans/tree/master/
usersguide/javahelp/org/netbeans/modules/usersguide


On 14/03/18 18:24, Geertjan Wielenga wrote:

> Take a look here:
>
> https://github.com/apache/incubator-netbeans/tree/master/usersguide
>
> Gj
>
> On Wed, Mar 14, 2018 at 10:30 AM, Neil C Smith 
> wrote:
>
> Hi,
>>
>> In reverse order ...
>>
>> On Wed, 14 Mar 2018 at 09:13 Antonio  wrote:
>>
>> Also, we have an area for the github wiki pages at [2]. Do we want to
>>> start a wiki there?
>>>
>>>
>> I thought we'd decided on asking for a separate wiki repo (ie.
>> incubator-netbeans-wiki ?)
>>
>> You brought up the issue that we couldn't support pull requests via the GH
>> wikis, and infra confirmed that although they're backed up they don't seem
>> to be visible as a "normal" Apache git repository.
>>
>>
>> I recall talking about the UserFAQ [1], but I thought most content there
>>> was obsolete (mailing list, license agreements, contribution agreements,
>>> plugin portal, update center, blogging) and we decided not to port it.
>>> The UserFAQ is _huge_, by the way.
>>>
>>>
>> OK, that makes sense - losing track of where we got to.  At the same time,
>> we potentially lose some useful information if we don't do something with
>> those pages, and quite a lot that aren't linked in either faq.
>>
>> So, what about bringing all the wiki into a separate repository (where it
>> will still be browse-able on GH) and prune / edit there before bringing
>> any
>> more across to the website?
>>
>> Other option would be a branch for this on the main website repo.  Might
>> help with history?  Could end up a mess!  Depends how wiki-like we want
>> our
>> not-a-wiki to be! ;-)
>>
>> Best wishes,
>>
>> Neil
>> --
>> Neil C Smith
>> Artist & Technologist
>> www.neilcsmith.net
>>
>> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>>
>>
>
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Wade Chandler]

> On Mar 13, 2018, at 3:04 AM,  
>  wrote:
> 
> Hi Wade,
> 
> I agree, desktop isn't going away. At DukeScript we're using HTML4J Apis 
> mainly for desktop applications. The Java Desktop Application is just using a 
> HTML5-Component ("browser") to render the view instead of a native or Java 
> rendering pipeline. 

How are events handled then? If you want to open a file as an example? Are you 
running the JVM as a separate service backend and using web services?

> 
> Since the separation of view and view logic is very clean the view technology 
> can be completely replaced. In some of our commercial projects we used 
> Controls4J to render the view, in others plain HTML and CSS. I've got working 
> prototypes that use native controls instead on iOS and Android. Even one that 
> renders to JavaFX that I sometimes use for debugging. 

That sounds pretty cool.

> 
> And unlike Swing or JavaFX browsers are evolving at great speed and getter 
> better day by day without any investment on our side. That's a great benefit 
> if you compare that to the sluggish development of Swing and JavaFX that 
> we've seen in the past years.  
> 

Perhaps, but I think one has to bind a product to a specific and embeddable 
browser for something like NB and NB RCP, or perhaps some custom Webkit. 
Relying on just anything seems like a lot to support at that level.

I figure if views themselves can be replaced, then technically we could have 
our own native views instead. We could do some things based on OpenGL or Vulkan 
https://www.khronos.org/vulkan/  or stay 
low-level yet remain in Java with LWJGL https://www.lwjgl.org 
, and not have any browser limitations. Here’s an 
example of an OpenGL based UI library https://github.com/wjakob/nanogui 

> I think that the stuff that Sean does with the crippled JavaFX 3D API is 
> amazing, but think about what he could do with a really good 3D API, like the 
> many that exist for WebGL. 
> 

I’ll let him speak more to this, but per his talks he tried different browser 
based 3D APIs, and the performance wasn’t there yet. Personally, I have seen a 
lot of WebGL components get the sad face uh oh in Chrome, and not be that 
stable; this on good hardware.

Wade

Re: Apache HTML/Java UI instead of ... Oracle will remove JavaFX from Oracle JDK

[Wade Chandler]

On Mar 12, 2018 11:59, "Jaroslav Tulach"  wrote:

> "Oracle has begun conversations with interested parties in the Java

> ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
 referenced timeframes."

>>>
>>
The official announcement is here and people are finally starting to
realize the truth: There is no future for JavaFX, AWT and Swing. Nobody
will sponsor development of anything new for these technologies. Even if
they get transfered to their new owners, they will be in maintenance mode:
Bugfixes and little features. No bigger changes - no new rendering
pipelines using new nifty features of graphics cards. Just sustaining. I've
been explaining this would happen since 2012.

To help us out of this situation and save Java as a programming language I
dedicated my days to smoothing out interoperability between Java and
JavaScript with the goal to reuse the most flexible and portable rendering
system of these days: the browser. My work has already been donated to
Apache, see: https://github.com/apache/incubator-netbeans-html4j - let's
use it to build new features of NetBeans and other future Java desktop
applications. Get started by reading Javadoc at
http://bits.netbeans.org/html+java/

Forget about AWT, Swing and JavaFX - the future is HTML. In case you still
care about Java, then your future should be Apache HTML/Java API!


Personally, I feel if that is true, then why all the hodgepodge, and why
not just Electron which is already driving window creation and interacting
with the desktop? Then, why not wasm and a real type safe language, and not
TypeScript nor JS? Or maybe just VS Code plugins?

Why use the browser for all that if there is a desktop need? I mean, is it
just me, or does that all just feel wrong?

Look at how many resources the Slack and VS Code apps need just running a
few simple things, and they exist how they are, and are successful because
people want to use the desktop app, and not tabs in their browsers. Then
there are all the tricks to access the file system indirectly.

I don't see the desktop app disappearing for specific types of
applications, and IMO that includes IDEs. Who wants to do all that work in
browser tabs? Nobody. Electron is a desktop app environment. It isn't a
container or a browser bound environment even if a browser is a component.

So what is the benefit of doing away with better rendering pipelines and
direct resource access just to wind up manipulating a slow and bloated DOM
in its place? Folks should checkout things Sean Phillips is doing with Java
FX inside NB RCP Swing.

I think IntelliJ shows that a successful Swing based product can be a
winner just as NetBeans has, and doesn't seem to be slowing down nor
changing directions. To me it seems more feasible to support Swing itself
for our needs, and continue making NB and NB RCP unique if we can be
involved. Otherwise, isn't it VS Code or Eclipse Che ideas, just far behind?

Wade

Re: Support of Java 10

[Wade Chandler]

On Mar 12, 2018 12:05 PM, "Jaroslav Tulach" 
wrote:

> > do we have an agreement to merge the branch from Jan to have at least

> > basic
> > > support for Java 10?
> > >
> >
> > I hope so, my plan is to send a pull request "sometime soon".
> >
>
> +1
>

+1


+1



> And still +1 for keeping version sync and calling this NB 10! ;-)
>

-1


-1 as well. The LTS versions live longer, and the processes between the
orgs will be different. They are also just different orgs. I don't think it
makes sense to try to align versioning. It was essentially marketing
between Oracle's Java and it's IDE, which made sense considering that, but
isn't the case any longer. It also means we will jump major versions just
for the Java support when NB is so much more than that.

Wade

What Coding Conventions Should We Follow Now? What should the IDE default to?

[Wade Chandler]

I noticed that Oracle has not maintained a convention for the Java language 
like other groups have for their ecosystems. This also has not materialized 
from OpenJDK:
http://www.oracle.com/technetwork/java/codeconvtoc-136057.html 

http://openjdk.java.net/guide/codeConventions.html 

https://wiki.openjdk.java.net/display/OpenJFX/Code+Style+Rules 

http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html 


Contrast this to:
https://www.python.org/dev/peps/pep-0008/ 

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions
 


So, it just seems wrong to follow those links; the Java conventions were a 
great example for years. I think the Google ones seem reasonable myself unless 
we or others in the Java community take that up:
https://google.github.io/styleguide/javaguide.html 


Any thoughts or other information? Am I missing something?

Thanks,

Wade

Re: Oracle will remove JavaFX from Oracle JDK (was: Re: Noticed Oracle is Working to Remove Java FX, AWT, and Swing from Base Java/JDK)

[Wade Chandler]

On Mar 11, 2018, at 7:38 PM, Chuck Davis <cjgun...@gmail.com> wrote:
> 
> That white paper says to me jdk11 is the end of the road for JSE at
> Oracle.  Without Swing/JavaFX I can't think of a single reason to have JSE
> on a computer.

Maybe, but all the more reason for the stewards they mention. One can certainly 
run servers and services as Java applications on those systems too. But, yes, 
not directly making any money for Oracle. But SMBs can definitely make money 
off these things, and if the community wants to keep this stuff going, then 
they’ll have to chip in on the bits they care about. This was the main point of 
my writing in the first place; to figure out what we can do to support it. I 
imagine JetBrains will be involved as well. They are very dependent with their 
current products.

> 
> The message of the white paper was clear: both Apple and Microsoft own
> their platforms and the day is not too distant when both will exclude Java
> from running on their platform.  Apple already stopped shipping Java.
> 

“Exclude” seems overkill considering other environments/runtimes exist on both; 
Node, Qt, Rust, Go, etc.. .Net even exists on Mac. Them not shipping something 
directly is not the same as exclude.


> The message is clear:  migrate to .net for windows or swift for mac.  Java
> will only be running on Linux in the near future and that market is not big
> enough to be attractive to Oracle.  There will be no more cross-platform
> Java (or anything else) development.  Browsers will continue to be
> available on all platforms -- if you want to play on somebody else's
> platform you will abide by their rules.

The browsers everyone is using on those platforms are not written in the 
languages you mention, so I don’t see that as the show stopper.

> 
> It is a sad day but, admittedly, exclusivity is not a new idea to either
> Apple or Microsoft.
> 
> What is the remedy?  Make alternatives so attractive IT managers will
> CHOOSE to leave either MS or Apple for the alternative.

I don’t see that as a goal of the NB community, and it certainly doesn’t do 
anything for all the consumer devices. I do think we can help support desktop 
Java since we highly depend on it.

Wade

===

Wade Chandler
e: cons...@wadechandler.com
t: @wadechandler
https://www.linkedin.com/in/wade-chandler





-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Oracle will remove JavaFX from Oracle JDK (was: Re: Noticed Oracle is Working to Remove Java FX, AWT, and Swing from Base Java/JDK)

[Wade Chandler]

On Mar 9, 2018 18:16, "Neil C Smith"  wrote:

On Fri, 9 Mar 2018 at 22:31 Matthias Bläsing 
wrote:

> Oracle is still committed to Swing and AWT to at least 2026. There is
> no mention of removing it.
>
> So we should keep calm.
>

Calm is good :-)

Still, that particular date is just talking about the end of commercial
support for Java SE 11 isn't it?  Unless I missed something, there isn't
anything about what happens in Java SE 12, which is only ~12 months away.


Exactly, and my original email didn't suggest freaking out. It did suggest
we need to be aware of what this means, and decide how to make sure we can
support "the" core dependency besides Java at this point. Does it mean
other tech, or does it mean getting more involved?

At a minimum the messaging for FX is that it didn't take off, and it has a
niche following, and mobile first and web technology has offset its
original goals.

Given that, other than some developer tools and "niche" applications, who
is using Swing? It's a rhetorical question.

Many today, I suppose most, think apps should be mobile or web, and unless
in the various markets, that have value for applications which aren't web
applications, but not as consumer visible, would think such things are
niche, even though that's a pretty big niche, and apparently an oxymoron,
if one takes the different technologies used to build installed desktop
apps including Qt, .Net, Electron (Slack or VS Code anyone), Natives,
Eclipse, others, and of course Swing (NB RCP) and Java FX along with their
domains/applicable use cases.

Maybe nothing near term to worry about, but I think without other
involvement, AWT & Swing are being looked at for something. This is also in
that document:

"Oracle has begun conversations with interested parties in the Java
ecosystem on the stewardship of JavaFX, Swing and AWT beyond the above
referenced timeframes."

Does anyone know Who? How? Terms? Or, how can we get involved?

Thanks

Wade

Noticed Oracle is Working to Remove Java FX, AWT, and Swing from Base Java/JDK

[Wade Chandler]

All

Sorry if a thread I have missed on this exists here. A friend of mine sent
me this link

http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf


It has interesting consequences for NetBeans. It mentions they have some
interested parties looking to take on those bits of the ecosystem. Does
anyone have any other insight into this? Who are they talking to?

Some of us NB folks have talked in the past about contributing to those
things at OpenJDK once NB was over to Apache. This may mean we will need to
start working on a new technology for the IDE, or get more involved.
Thoughts?

Thanks

Wade

Re: Possible Removal of SVN

[Wade Chandler]

> On Mar 8, 2018, at 11:16 AM, Glenn Holmer <ce...@kolabnow.com> wrote:
> 
> On 03/08/2018 09:44 AM, Geertjan Wielenga wrote:
>> I agree completely Subversion should stay as a standard part of NetBeans.
>> CVS, on the other hand, which has been a separate module for several years
>> now, is IMHO not something we should give high priority.
> 
> +1
> 


+1

===

Wade Chandler
e: cons...@wadechandler.com
t: @wadechandler
https://www.linkedin.com/in/wade-chandler



-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [VOTE] Apache NetBeans Logo (NETBEANS-145)

[Wade Chandler]

Logo ID 2 : +1

Wade


On Mar 1, 2018 07:32, "Antonio"  wrote:

> Hi all,
>
> For popular demand let's vote about the NetBeans Logo in the mailing list,
> that's easier for everybody, right? This will close NETBEANS-145 [1].
>
> The received entries are at [2].
>
> Please state the icon identifer you vote for (only icons count, do not pay
> attention to typography).
>
> Thanks all,
> Antonio
>
>
> [1]
> https://issues.apache.org/jira/browse/NETBEANS-145
>
> [2]
> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+
> NetBeans+Logo+Contest
>
>  Forwarded Message 
> Subject: Re: [ANN] Closing the NetBeans Logo Contest
> Date: Thu, 1 Mar 2018 12:23:50 +
> From: John McDonnell 
> Reply-To: dev@netbeans.incubator.apache.org
> To: dev@netbeans.incubator.apache.org
>
> We should create a vote thread here, or on users.  This is consistent with
> normal apache votes.  All it needs is a link to the confluence page to show
> the images and their option numbers.
>
> It avoids everyone having to have edit writes on the confluence just for a
> vote.
>
> Regards
>
> John
>
>
>
> On 1 March 2018 at 12:21, John Kostaras  wrote:
>
> It's not clear where do we have to add our vote: in confluence
>> > Apache+NetBeans+Logo+Contest>or
>> in jira ?
>>
>> I vote for option 2, too.
>>
>> Regards,
>>
>> John.
>>
>> On 1 March 2018 at 13:16, Neil C Smith  wrote:
>>
>> > On Thu, 1 Mar 2018 at 12:08 Peter Steele  wrote:
>> >
>> > > That means you need to have an account that is approved for editting.
>> > >
>> >
>> > Good catch!  Do we really want to restrict voting to wiki editors?  Or
>> to
>> > dev@?  Or to users@?
>> >
>> > Personally, I'm in favour of at least having a thread on here
>> specifically
>> > for voting, if not one at users@ too.
>> >
>> > Best wishes,
>> >
>> > Neil
>> > --
>> > Neil C Smith
>> > Artist & Technologist
>> > www.neilcsmith.net
>> >
>> > Praxis LIVE - hybrid visual IDE for creative coding -
>> www.praxislive.org
>> >
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: The logo, once and for all? (was AW: Merged to master (was Re: A NetBeans website proposal))

[Wade Chandler]

When we started this, and Chris did his icon, we had the NetBeans cube;
both the blue solid and the red empty sides versions. NB has had those cube
icons for decades at this point.

Webpack, at the time of his drawing, had a cube in a translucent cube. But,
did have the hexgon outline.

Has anyone see the latest Webpack logo? It seems to differ only in color,
as they have added boldness and contrast to the internal cube lines.

I think it would be fair to afford some time for some modification because
of this. Just some ideas: Some extra depth to the layer around the cube
could relate to the pieces from "Fits the pieces together" as well as "into
a new dimension". Maybe even adding some tilt to the hexagon to give it a
distinct shadow.

Wade


On Feb 26, 2018 06:06, "Antonio"  wrote:

> Hi Chris, all,
>
> The situation with the logo is that there was a voting at [1] somewhere in
> 2016, the most voted logo is not the one with colors, so using the one you
> suggest (with colors) instead of the most voted one does not seem to be
> very Apache compliant, as it would be against a voting result.
>
> Also in late 2017 we opened an Apache NetBeans logo contest at [2], which
> has not been closed yet. There has been a submission in early february 2018
> (i.e., a few days ago) from Junichi (see [3]), which is also pretty cool,
> IMHO, and also deserves our consideration.
>
> To end up the logo discussion once and for all I propose:
>
> - Announcing closing the contest within a few days.
> - Announce a voting in the mailing list, as per the Apache way.
>
> I know this is probably lots of bureaucracy, but that's how things are
> expected to work in this Apache world, AFAIK (and please correct me if I'm
> wrong).
>
> Kind regards,
> Antonio
>
> [1]
> https://cwiki.apache.org/confluence/display/NETBEANS/NetBeans+Logo
>
> [2]
> https://issues.apache.org/jira/browse/NETBEANS-145
>
> [3]
> https://issues.apache.org/jira/secure/attachment/12909573/ap
> ache-netbeans-logo.png
>
>  Forwarded Message 
> Subject: AW: Merged to master (was Re: A NetBeans website proposal)
> Date: Mon, 26 Feb 2018 10:58:53 +0100
> From: Christian Lenz 
> Reply-To: dev@netbeans.incubator.apache.org
> To: dev@netbeans.incubator.apache.org 
>
> I would like to Change the logo to the SVG file, because it scales better
> and we don’t have any Problems with Retina and whatever, as you can see it
> here: http://netbeans.apache.org/. I added the SVG too.
>
>
> Cheers
>
> Chris
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: launcher for windows and building c file

[Wade Chandler]

On Feb 26, 2018 17:54, "Scott Palmer"  wrote:

But I still wonder, why doesn’t NetBeans use the standard java launcher
that is produced by javapackager?


NetBeans launcher has been around well before that. NB is in itself an
entire platform with a module management infrastructure. It supports
specific command line arguments etc. Java Packager may be able to do it
now, but someone would need to hash all that out.


(If it isn’t good enough, it should be. We should file an issue with the
JDK if it is inadequate.)


Probably true, but the devil is always in the details. The launchers for NB
work with the specifics of NetBeans, and do some special magic. So, the
java launcher class to do that magic would need to be provided, but too, NB
uses a pluggable JDK, and requires one be provided right now. I think if
you want to put together a PR for what that could look like with
javapackager, nobody will argue with a working solution.

Wade

Re: incubator-netbeans-website, lightbox and issues

[Wade Chandler]

> On Feb 26, 2018, at 1:55 PM, Antonio <anto...@vieiro.net> wrote:
> 
> Hi all,
> 
> I was wondering if anybody is working on the "lightbox" support for the 
> website features page, I may have some spare time during the week and may 
> tackle if, if nobody is already working on that.

Not I.

> 
> Also I thought we could open JIRA tickets for the web as well

There are some tickets already there for some bits of the site. Do you see 
them? Those should use the same component to be accurate. But, yes I favor 
issues in Jira to help track them, and give visibility into who is doing what; 
IMO.

> , and was wondering if we want git<->JIRA integration in the 
> "incubator-netbeans-website" repository, so JIRA issues are related with that 
> repository commits.
> 
> I don't know if it's possible to connect JIRA to two different repos, but I'd 
> be happy to either ask or make a request to INFRA, if you want.

Seems like it does, and it links them by the issue key which contains the 
project code, so it should just work when a repository is added:
https://confluence.atlassian.com/adminjiraserver072/linking-a-bitbucket-or-github-repository-with-jira-828787604.html
 
<https://confluence.atlassian.com/adminjiraserver072/linking-a-bitbucket-or-github-repository-with-jira-828787604.html>

They may already be doing this automatically, but can’t hurt to ask.

Thanks,

Wade


===

Wade Chandler
e: cons...@wadechandler.com
t: @wadechandler
https://www.linkedin.com/in/wade-chandler

Re: launcher for windows and building c file

[Wade Chandler]

+1 on the bits here Emilian covered.

Wade

===

Wade Chandler
e: cons...@wadechandler.com
t: @wadechandler
https://www.linkedin.com/in/wade-chandler



> On Feb 24, 2018, at 5:08 PM, Emilian Bold <emilian.b...@protonmail.ch> wrote:
> 
> I would also like for us to have a 'from scratch' build possible, including 
> native launchers.
> 
> -1 on another repo just for this.
> 
> I also don't believe we need new folders, we could have a ./build/ in  
> o.n.bootstrap/launcher/windows/ just like we have for any other module.
> 
> I see there's a Makefile in there and the sources. So, what's missing is 
> perhaps a task in nbbuild/build.xml?
> 
> Also agree that we can have launcher 'releases' with convenience binaries 
> which we re-use in Platform releases, etc.
> 
> --emi
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On 23 February 2018 6:09 PM, Eric Barboni <sk...@apache.org> wrote:
> 
>> Hi Jan,
>> 
>> I try to make it concrete to me (as I am not sure to understand completely 
>> the workflow).
>> 
>> We may add a folder to nbbuild/buildnatives that contains all the make c 
>> stuff to compile and release (linked to the source we need for example in 
>> o.n.bootstrap and ide/native)
>> 
>> Phase 1 (optional)
>> 
>> clone netbeans-incubator and execute the nbbuild/buildnatives
>> 
>> Phase 2
>> 
>> clone netbeans-incubator ,ant and use the released native
>> 
>> Is it a "possible" workflow ?
>> 
>> Regards
>> 
>> Eric
>> 
>> -Message d'origine-
>> 
>> De : Jan Lahoda \[mailto:lah...@gmail.com\]
>> 
>> Envoyé : vendredi 23 février 2018 13:10
>> 
>> À : dev@netbeans.incubator.apache.org
>> 
>> Objet : Re: launcher for windows and building c file
>> 
>> On Fri, Feb 23, 2018 at 1:02 PM, Eric Barboni sk...@apache.org wrote:
>> 
>>> Hi,
>>> 
>>> I know that Apache Openoffice use buildbot\[1,2\] with cygwin on it.
>>> 
>>> We need ask Apache Infra for that. We also need a new repository.
>> 
>> We can definitely ask for a new repository, but do we need one? I.e. why 
>> can't the sources be part of the main repo, and just produce a release as a 
>> subset of that repo? (We already do that with the NB platform.)
>> 
>> Jan
>> 
>>> Regards
>>> 
>>> Eric
>>> 
>>> \[1\]
>>> 
>>> https://ci.apache.org/builders/aoo-w741x
>>> 
>>> \[2\]
>>> 
>>> https://ci.apache.org/buildbot.html
>>> 
>>> -Message d'origine-
>>> 
>>> De : Jan Lahoda \[mailto:lah...@gmail.com\] Envoyé : vendredi 23 février
>>> 
>>> 2018 12:02 À : dev@netbeans.incubator.apache.org Objet : Re: launcher
>>> 
>>> for windows and building c file
>>> 
>>> On Thu, Feb 22, 2018 at 4:59 PM, Eric Barboni sk...@apache.org wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I setup cygwin64 on windows 10. Thanks to your tips I update to
>>>> 
>>>> i686* tools chain.
>>>> 
>>>> I add to static link libgcc, libstdc++ and also add -static
>>>> 
>>>> lpthread to get it works.
>>>> 
>>>> Artefact are huge now but I was able test some code to check for
>>>> 
>>>> jdk9 compatibility.
>>>> 
>>>> The remaining issue are:
>>>> 
>>>> how to generate the platform-launcher-9.0beta.zip and
>>>> 
>>>> launcher.zip, how to populate the external binaries repository with
>>>> 
>>>> those artefact
>>> 
>>> When I was thinking of this, I was thinking it would be in line with
>>> 
>>> the Apache approach to create a separate release with just the
>>> 
>>> launchers (this wouldn't quite require moving that ouside of the repo,
>>> 
>>> it could be a task to simply pack a piece of the big repo). That would
>>> 
>>> be sources and convenience binaries. Should be reasonably small. And
>>> 
>>> when building the IDE, the convenience binaries for launchers would be
>>> 
>>> downloaded and incorporated to the built IDE. I assume some work will
>>> 
>>> be needed to setup such a release. It would be ideal if the
>>> 
>>> convenience binaries would be uploaded to Maven. Upload to the legacy
>>> 
>>> binary repository requires commit rights to hg.netbeans.org.
>>> 
>>> 

Future Idea - Apache NetBeans ML (Machine Learning) and Kubernetes Extensions

[Wade Chandler]

This week I took a trip to Atlanta to attend DevNexus. It was great. I got to 
see old friends, meet new ones, and attend some really great talks.

A couple of those talks were on Machine learning. Carol McDonald did one using 
Apache Spark, Hadoop HBase, and Zeppelin. It was great.

Another interesting talk was from Oleg Selajev on Graal VM. During the Q we 
discussed some great prospects of being able to run Java, and other JVM 
languages, along with Python and R plus LLVM C/C++ bindings in the same VM, and 
how that could have great implications for machine learning considering the 
ecosystems for those tools.

Pulling those ideas together I couldn’t help but think of how great it would be 
to be able to work with all these tools along with Apache NetBeans in some way 
once we get to a place to start making new things happen.

There were also some great talks on Kubernetes, and being able to run these 
things in clusters, locally or in cloud providers, or even on a single system. 
Merging together some concepts I have seen from Emilian on cloud computing plus 
NetBeans along with the vast Apache Ecosystem make for some interesting 
Kuberrnetes plus Containers and ML scenarios.

This is really just me sharing the concept at the moment to Spark some some 
interest (pun intended).

Thanks,

Wade

===

Wade Chandler
e: cons...@wadechandler.com
t: @wadechandler
https://www.linkedin.com/in/wade-chandler

Re: Apache NetBeans logo

[Wade Chandler]

On Feb 24, 2018 14:48, "Geertjan Wielenga" 
wrote:

Wow, you’ve not only worked on the logo but provided an awesome new slogan
too? :-)

On Saturday, February 24, 2018, Norquay  wrote:
> “Bringing NetBeans into a new dimension”.


I agree this can be the start of a new slogan. Apache plus the new logo as
a 4th dimension as you mentioned!

Nice!

Wade

Re: Apache NetBeans logo

[Wade Chandler]

I believe the credit goes to Christian Lenz :-) He also got us started with
the new site direction, and worked on the Slack setup with Bruno Flavio and
I. A big help on so many things.

Many thanks to Christian and James! Everybodies help makes this great!

Wade

On Feb 24, 2018 14:42, "Norquay"  wrote:

> Besides being artistically lovely, and playing on the original NetBeans
> logo, I liked the fact that it looks like a tesseract (a 4-d cube) <
> https://en.wikipedia.org/wiki/Tesseract> viewed from one corner.
> “Bringing NetBeans into a new dimension”.  Who drew it?
>
> > On Feb 24, 2018, at 8:22 AM, geertjan.wiele...@oracle.com wrote:
> >
> > Hi all,
> >
> > I know we haven’t picked a logo yet, but here’s a mail from James
> Gosling with his input in this discussion. :-)
> >
> > Thanks,
> >
> > Gj
> >
>
>

Re: AW: AW: [news] NetCAT 9.0 proposal

[Wade Chandler]

I agree with this sentiment. I have logic that allows one to run or debug a
single Groovy test that has been in the main NB code since before NB 8.2
was released, and yet I can't get my value and time spent out of that work
yet.

Obviously the move has some to do with the wait right now, but I wouldn't
want to wait half a year for such changes to show up regardless. We had
that as contributors before, and it detracts from the value of contributing
if itches can't be scratched quickly.

I prefer some scheme where changes such as that can make it into the
contributors production IDE as fast as responsibly possible if we can
figure that out.

Thanks

Wade


On Feb 23, 2018 13:31, "Christian Lenz"  wrote:

> I know exactly what you mean, but I don’t mean the release of NB 9, I mean
> all other Releases. Often you have to wait 6 months or more for new
> Features etc. The community you can see it in slack, Twitter, Facebook
> asking for when will it be done, when is JS coming, when will we have
> better release cycles or new Features that other IDEs or Editors already
> have since ages (I know it is a bit exaggerated but it should be clear,
> what I mean). Those Things are real Problems too, not only for the current
> release.
>
> NetBeans often lacks behind Features. No Vue Support, no full real Angular
> 2 Support, a lot of stuff that was not working under Oracle, often this is
> not possible with 3rd Party Plugins, because of the private APIs or
> whatever (See the Angular 2 template stuff inside html files or KendoUI
> Support, what Geertjan started, which is not possible anymore to work with,
> because it is not a friend plugin anymore). And if you compare NetBeans
> with big competitors like IntelliJ/PHPStorm/WebStorm or Eclipse or VS Code,
> we must Change smth, we have to.
>
> I don’t mean, that we have to have this politics like: Get Things done
> fast. But I think if we have a better Pipeline and a better QA process and
> whatever, that we can save 2 months (Remove NetCat) because that is not
> needed. 2 Months that can save time from maybe 6 Months + 2 Months NetCat
> to only 6 or less. I prefer 3 months too, as we can see it now, we have
> some new PRs and sure we will have more and more. People are waiting for
> new stuff, etc. And as I said, it is not only about NB 9.
>
>
> Cheers
>
> Chris
>
> Von: Jiří Kovalský
> Gesendet: Freitag, 23. Februar 2018 19:11
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: AW: [news] NetCAT 9.0 proposal
>
> I share the same opinion. For me personally quality is the most precious
> feature. I know that we all have been waiting for NetBeans 9.0 for more
> than a year now but good things need time. ;)
>
> Regarding release frequency, we should release only when it makes sense
> i.e. when a set of interesting new features is implemented together with
> a handful of critical bug fixes. Let's not follow the modern but insane
> corporate paranoia: "We must get it out quickly otherwise competition
> will be far ahead!" which only leads to frustration and disappointment
> both among development teams and end users.
>
> We are true open source project now! I don't want to go back to date
> driven release trains at all cost.
>
> -Jirka
>
> Dne 23.2.2018 v 17:03 cowwoc napsal(a):
>
> > Same here. Stability first. Once we've got that down, then I'd favor a
> > release schedule of 3-6 months.
> >
> > Gili
> >
> > On 2018-02-23 5:52 AM, Валера Солдатов wrote:
> >> My 2 cents. I wish to use stable and quick IDE. I don't want to update
> >> my working tool too often.
> >>
> >> 23.02.2018 13:01, Christian Lenz пишет:
> >>> Really 10 Weeks? 2 more months? I mean I don’t know it really,
> >>> because it is a huge Code base but im the future, my wish and I think
> >>> from other People too, we want to have more release cycles and less
> >>> time between Releases. My 2 cents.
> >>>
> >>>
> >>> Von: Jan Lahoda
> >>> Gesendet: Freitag, 23. Februar 2018 08:51
> >>> An: dev@netbeans.incubator.apache.org
> >>> Cc: d...@netbeans.apache.org
> >>> Betreff: Re: [news] NetCAT 9.0 proposal
> >>>
> >>> On Thu, Feb 22, 2018 at 11:06 PM, Sven Reimers  >
> >>> wrote:
> >>>
>  +1..
> 
> 
>  Is this only on 10 or with 10 as Platform as well (thinking of var
> ...)
> 
> >>> My personal opinion:
> >>> -NetBeans IDE should run on JDK 10
> >>> -ideally it should be possible to have a (J2SE/Maven) project using
> >>> JDK 10
> >>> as well, including support for var (shouldn't be difficult, see the
> >>> jdk18_3
> >>> branch in the official repository; depends on whether we can add a
> >>> feature
> >>> like this at this stage).
> >>> -the NetBeans IDE itself can't use JDK 9/10 features, as it still
> should
> >>> run on JDK 8.
> >>> -for applications based on NetBeans platform, the build system
> currently
> >>> does not (AFAIK) support JDK 9/10, but if someone wanted to work on
> >>> that, I
> >>> think it would be useful.
> >>>
> >>> 

Re: A NetBeans website proposal

[Wade Chandler]

On Feb 23, 2018 11:16, "Neil C Smith"  wrote:


That has been there for a while.  I'd much prefer Gitter if we're going to
have one (and not sure if it's a good idea or not) because it's visible
without signing up.


You can see the history and all here without signing up:

https://netbeans.slackarchive.io

Too, notice the channel layout for topic separation. We also have IRC and
Slack integration to service both there.

I think if one uses Slack for any period of time they will find it the best
chat experience even over HipChat (and others), but definitely over Gitter.
I am definitely biased having used many of them and finding Slack just does
it right; IMO of course.

Thanks

Wade

Re: Pace of development

[Wade Chandler]

I think my first thought is; Have you contributed to NetBeans sources
before? What about other OSS code? Not Jira issues or mailing lists; code.
If so, why did you do that, and what was your derived value not just from
contributing, but also risk versus reward?

There are a lot of things one just can't do until the baseline is in place
to scratch the itches they care about. At the moment, my time is extremely
valuable. If I can't get turn around on fixes to tools I personally use,
then it becomes too much of a cost to me personally.

As an example, and this didn't make the NB 8.2 patch, I have Groovy changes
to help with running tests. I can't use that right now, and so just keep
going along with 8.2. I feel in other gaps with other tools I also use.
Once enough IP is cleared, which had been broadcast in channels, then I
have a better shot of my time not only helping the community, but me too,
and doesn't over tax me, which wouldn't be good in any form.

So, until I can do that, then I'm trying to contribute where I can best use
my time, for me, such as the web site, as I also used to contribute to that
and the Wiki on netbeans.org.

I agree Jira, the Wiki, and site eventually need to become a place to see
the big picture, and I am sure we will get there, but there is a long way
to go, and for me and IMO, we can't worry about who will or will not use NB
near term. We have to get it moved over, get infra setup, use it, build it,
and then grow it, or we risk burning out or rushing, and it will have the
same result you may be expressing here albeit from a different POV.

Wade

On Feb 15, 2018 05:22, "cowwoc"  wrote:

> Hi,
>
> I don't mean to offend anyone (not trying to point any fingers, really)
> but I want to raise an issue for discussion.
>
> When Netbeans was moved to Apache I saw a lot of activity in the mailing
> list. Everyone was excited and that was great but now I am seeing an
> extremely low rate of participation by non-Oracle employees (see
> https://github.com/apache/incubator-netbeans/graphs/contributors) and the
> overall commit frequency over the past couple of weeks is extremely low
> (see https://github.com/apache/incubator-netbeans/graphs/commit-activity).
>
> I am bringing this to your attention because looking at JIRA's "Created vs
> Resolved" issues for the past 30 days we are seeing an exponential growth
> of bug reports but a flat amount of resolved issues:
> https://issues.apache.org/jira/secure/ConfigureReport.jspa?
> projectOrFilterId=project-12320634=daily&
> daysprevious=30=true=major&
> selectedProjectId=12320634=com.atlassian.jira.
> jira-core-reports-plugin%3Acreatedvsresolved-report_
> token=A5KQ-2QAV-T4JA-FDED%7C113ee1575eff5807f4be21c1f06ce3f9
> 6e46f8b2%7Clout=Next
>
> Speaking from my personal experience as an end-user, I think we've got a
> long way to go in terms of fixing regressions before I would consider
> jumping from version 8.2 to 9.0. I am routinely running into annoying UI
> bugs that were not present in 8.2. Yes, we now have JDK 9 support and this
> is a big deal but this yet relevant in my day-to-day work (my projects use
> Java 8). My primary concern is using the IDE that will make me the most
> productive as a developer. The nightly builds are a step backwards in that
> regard.
>
> Anyway, I just wanted to bring up this issue for discussion. I remember a
> lot of people initially asked to be listed as committers, and I'm wondering
> where they all went, what (if anything) has turned them off from
> contributing at this time, and what can be done to bring them back.
>
> Reminder: As mentioned in the past, I not have the time to commit fixes
> myself. I am intentionally limiting myself to filing bug reports and giving
> you feedback as an end-user. I hope you will respect that scope.
>
> Thank you,
> Gili
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Website repository (was: NetBeans Website Conversion,...)

[Wade Chandler]

On Mon, Dec 11, 2017 at 6:33 AM, Bertrand Delacretaz  wrote:

> On Mon, Dec 11, 2017 at 12:29 PM, Geertjan Wielenga
>  wrote:
> > ...There already is a repo for this:
> > https://github.com/apache/incubator-netbeans-website ...
>
> Which apparently contains the live http://netbeans.apache.org/
> website, in the asf-site branch, so you might need to be careful.
>
>
...sent from wrong address before

I have had some internet issues at my house, and have not been at work, so
just now finally able to get a full push to work even though I was able to
create the full repo some days ago, but the sources can be found here
https://github.com/apache/incubator-netbeans-website-cleanup ... The goal
is to cleanup the repo and get things working, then overwrite, so I did not
want to have to worry about the current repo etc, to Bertand's point, until
we have things working to the point of being deployed. Anyways, we can move
that over, and remove the cleanup repo once done.

Thanks,

Wade

Re: Website repository (was: NetBeans Website Conversion,...)

[Wade Chandler]

On Mon, Dec 11, 2017 at 6:33 AM, Bertrand Delacretaz  wrote:

> On Mon, Dec 11, 2017 at 12:29 PM, Geertjan Wielenga
>  wrote:
> > ...There already is a repo for this:
> > https://github.com/apache/incubator-netbeans-website ...
>
> Which apparently contains the live http://netbeans.apache.org/
> website, in the asf-site branch, so you might need to be careful.
>
>
I have had some internet issues at my house, and have not been at work, so
just now finally able to get a full push to work even though I was able to
create the full repo some days ago, but the sources can be found here
https://github.com/apache/incubator-netbeans-website-cleanup ... The goal
is to cleanup the repo and get things working, then overwrite, so I did not
want to have to worry about the current repo etc, to Bertand's point, until
we have things working to the point of being deployed. Anyways, we can move
that over, and remove the cleanup repo once done.

Thanks,

Wade

Re: NetBeans Website Conversion, Plan, and Call for Help

[Wade Chandler]

> On Dec 10, 2017, at 13:56, Neil C Smith  wrote:
> 
> On Sun, Dec 10, 2017 at 6:20 PM Antonio  wrote:
> 
>> I imagine we'll have to go through all those "*.html" files (5504 to be
>> exact) and clean then up somehow.
>> 
> 
> As I said in the long email with questions for Wade, I still think doing
> this in one go, vs having a working static clone and going folder-by-folder
> / section-by-section is a better approach than trying to fix all the source
> *.html files now, but …
> 

I will get to that one soon; sorry for the delay on it.

> I suggested pulling out the body tag, but an "easier" way might be to build
> it into the pre-processing stage where Wade's code is adding the yml data -
> it shouldn't require a parser for this!?

This is sort of the plan. The plan I am working on is to update the source 
documents with separate Gradle tasks and Groovy logic which we will take out 
after it outlives its use. I needed to get some base setup going such as a 
section and template list. I have narrowed it down to 74 different sections, 
and plan to set those up to share the same base logic, where they can then 
later be changed section by section, to support asides or what ever else is 
needed (maybe some special branding or anything else), but allow them to allow 
be the same at first.

Next, the Groovy scripting will iterate through the file hierarchy looking for 
sub-paths, and if those sub-paths are found, the associated type will be used 
in the output YAML. Along with that, jsoup will allow the keywords, 
description, and other metadata to be extracted from the HTML files, along with 
the body, to get us to some basics.

Following that, or along with it, then we will get into path sanitation for 
things like images as well as content sanitation such as removing CSS and other 
things which are not part of the main/global templates.

Then, I think we’ll be looking at cleanup along with seeing what URL 
redirection we can setup for Apache rules (httpd).

Other than those, the other big ticket items such as supporting a plugin 
portal, update center XML, etc. I’m still not sure where that should really go. 
I do not think they should be in this main static sites repository though. I do 
think we can link to some place where build artifacts are placed for such 
things (maybe that can be the Maven repo, but not sure yet).

Thanks,

Wade

Re: NetBeans Website Conversion, Plan, and Call for Help

[Wade Chandler]

I will have to give more thoughts to the below Neil. Good stuff though.

Thanks

Wade



> On Dec 9, 2017, at 14:21, Neil C Smith <neilcsm...@apache.org> wrote:
> 
> Hi,
> 
> On Sun, Dec 3, 2017 at 4:07 AM Wade Chandler <wadechand...@apache.org>
> wrote:
> 
>> I’m still working on the site planning page, but I think there is enough
>> there to get started and have others chip in, and please feel free to add
>> sections I’m missing, and feel free to ask any questions,
>> 
> 
> Great job so far!  I've cloned and got the build system working from the
> terminal (out of interest, as I don't normally use Gradle, are you using
> the NetBeans Gradle plugin?)
> 
> My initial thought is there's a lot to do!  I'm wondering whether we need a
> more incremental approach?  If I was doing this as a Jekyll conversion
> (which I've done a lot of work with - getting my head around JBake!) I
> would probably use a static clone of the live site as a starting point, and
> progress on a section by section or folder by folder basis.  We could then
> prioritise the main front-facing pages while keeping most existing links
> active while the work progresses - possibly editing the core CSS and logo
> file if necessary.  What are your thoughts on doing that?
> 
> I like your sidecar files suggestion for meta-data - I wonder if that
> preprocessing could be expanded in the following ways
> 
> * if a specific sidecar files does not exist, what about a folder default
> sidecar file? I get the feeling the meta-data for migrated content could
> often be the same?
> * an option to not require the html.gsp file - if a html file doesn't have
> header data, look for a sidecar file or folder default?  This could be
> mixed with extracting the contents of the body tag / removing head tag?  It
> might help with initial conversion?
> * if there's no header meta-data and no sidecar, add whatever header JBake
> requires to copy the file contents intact (effectively Jekyll's behaviour
> of copying verbatim files with no front matter)?
> 
> On another note, I've been wondering whether we can build an entirely
> static replacement for the plugin centre.  What would your thoughts be on a
> separate sub-repo of .yml files that get merged into the main site - both
> pages and the catalog file for the IDE?  Plugin submissions being reviewed
> via pull requests, linked to binaries elsewhere?
> 
> Just my thoughts from an initial look around at what you have - apologies
> if this is covering any old ground.
> 
> Best wishes,
> 
> Neil
> -- 
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
> 
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: NetBeans Website Conversion, Plan, and Call for Help

[Wade Chandler]

On Dec 10, 2017, at 12:29, Antonio  wrote:
> 
> Hi Geertjan,
> 
> What's this "the Java SE Quick Start Guide" link you're talking about? I'm 
> unable to find it.
> 
> Thanks,
> Antonio
> 
> El 08/12/17 a las 17:59, Geertjan Wielenga escribió:
>>> …

Gj,

You may not have pushed that from your repo. You should check to see.

Thanks,

Wade

Re: NetBeans Website Conversion, Plan, and Call for Help

[Wade Chandler]

On Dec 10, 2017, at 15:13, Antonio  wrote:
> 
> 
> 
> El 10/12/17 a las 20:44, Neil C Smith escribió:
>> Hi,
>> On Sun, Dec 10, 2017 at 7:34 PM Antonio  wrote:
>>> I was suggesting a one-pass tool to reach the "working static clone"
>>> state (we're not there yet). Using plain Foundation CSS (not SCSS) is
>>> good enough, IMHO, to reach this "working static clone" state.
>>> 
>>> 
>> I think you misunderstand me - by working static clone, I mean spidering
>> the current live site, not working from the source HTML.  This is then
>> entirely hostable.  With a few tweaks to key files, such as front page and
>> about, etc. , perhaps replacing logo file, we could then start working
>> through the site section by section while it is hosted at Apache.
>> Otherwise we can't easily get the front page up before everything is ready.
> 
> Of course I did.
> 
> So you're suggesting copying "src/content" to "build/bake" before the bake 
> run, right? So we'll end up having the "baked" pages on top of the existing 
> ones.
> 
> That would definitely work, but we'll have to clean-up copyrights et al., as 
> you say.
> 
> I thought this solution was discussed and discarded.

Some of the problem here is platform.netbeans.org 
. Either way, to move that in to the site, will 
require what it will take now I believe; massaging the images and links. I 
think the rest could work (what Neil is suggesting). At the same time, I think 
we can move rather quickly on what we have now once we have the content 
processing, and is what I’m working on.

I think some of those other big ticket items will be needed right off the bat 
though too, such as the Downloads section, and too, figuring out what to do 
with ns, dtds, updates, etc. I’m also wondering if we want samples to be done 
the same way.

> 
>>> I was hoping that "${content.body}" in the YAML companions would do
>>> exactly that, so in our "page.gsp" template we could add just the body
>>> of the original page, but we're getting the whole HTML content, and so
>>> we end up with nested HTML.
>>> 
>> I was thinking of a variant of mergeContentAndMetadata (from
>> buildSrc/src/main/groovy/Utils.groovy) that rather than writing the entire
>> text from the file, writes the section between the body tags - assuming
>> well-formed input, string matching  and  should work fine?
> 
> I think string matching could probably work. I'll find out.

This I’m going to use jsoup. It works great for parsing out HTML, and then 
being able to grab the text of what you want with no string comparisons etc; 
way nicer, and works like a charm regardless of tag and quote oddities. I’m 
also working to grab the keywords, description, and other items, which we can 
then work into the templates to further customize each article and page to 
match an authors intent going forward and the previous authors (probably mostly 
Gj).

Wade

Re: NetBeans Website Conversion, Plan, and Call for Help

[Wade Chandler]

> On Dec 10, 2017, at 23:45, Antonio  wrote:
> 
> 
>> I am working on section names and scripting along with template names. This
>> also merges platform.nb.org in with the other bits; see it as a subfolder
>> now. You can see some I have looked at in the Jira story. As far as the
>> .html.gsp files go, I plan to covert all files to that with scripting, then
>> if we need the processing we will have it without having to rename files. I
>> am also looking at what to do with the .inc.html files. I figure those will
>> become pieces of templates (possibly).
> 
> I think I did a small exercise with a .html.gsp file a while back and it got 
> converted to an .html.html extension. Let me know after you've done the 
> conversion if I can be of help.

The .html.gsp bits come from the fact that JBake doesn’t support any logic in a 
content page at the moment, but only in templates, and .html.gsp will be 
converted into a .html file by Gradle as it processes it with copy using expand 
(as a Groovy template), merging in the .html.gsp.yml file as the metadata/front 
matter, next, during the phase where JBake is called, it will then process the 
generated .html file accordingly. I should probably write this up better in the 
README.md file versus relying on the build script as code as much. I do have it 
documented some however in the section which explains the naming convention.

So, it works like this:

* If you have a file ending in .html.gsp, it will be processed by the Gradle 
build merging the metadata with it into a proper .html file understood directly 
by JBake
* If you have a file ending in .html, with an accompanying .yml file (same name 
+ .yml), then it will be merged into a final .html file understood directly by 
JBake
* The same as above also applies to .md files (in both cases), which will 
hopefully allow us to write new content in MarkDown, such as articles and blog 
like posts (hopefully easier writing and reading)

> 
>> The other heavy lifting with regard to content will be the CSS work and
>> flushing out the different templates for sections as well as their specific
>> page types; what they look like. For instance, certain sections have
>> different asides plus menu options such as PHP and Java tutorial sections;
>> if you browse around netbeans.org.
> 
> I don't think we want to keep those asides. Maybe it's a good idea to have an 
> aside pointing to different parts of an article (some sort of TOC), but not 
> to other parts of the site.
> 
> Maybe a global aside can be set up in some templates, pointing to different 
> parts of a web section. All platform tutorials, for example, may have an 
> aside pointing to different parts of the "platform tutorials web section”.

Yes, the idea is they would be globals, or at least in templates (the asides), 
but will be asides. However we want to do it though.

If you look at the Jira issue you referenced, you’ll see this comment 
https://issues.apache.org/jira/browse/NETBEANS-124?focusedCommentId=16285504=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16285504
 

 and it is a list of 74 possible “sections to have specialized templates” which 
could then have a special aside linking to specialized/relevant content. I’ve 
still to better understand JBake's tagging mechanism, but my understanding is 
those tags can be referenced in different ways 
http://jbake.org/docs/2.5.1/#tags , and we 
may be able to use tagged_documents, along with sorting out the ones with 
different types (specific types) if they have certain tags, so if we tag 
content, we can cause it to show up in an aside for a specific template once 
JBake has done its full rendering. This is an idea I think we can work towards, 
and of course we can work up those templates later.

The main point is if we have specialized templates for sections we know differ 
from that list, then we can always easily adjust those templates without having 
to also refactor the “type” in the metadata of each document. I’m counting on 
the content scraping script I’m working on to do that part for us. I just need 
to set it up to compare whether a given file lies under a specific sub-path, 
then associate the appropriate “type” for it, to allow us to 1) create them and 
2) JBake to be able to link them up.

Thanks,

Wade

Re: NetBeans Website Conversion, Plan, and Call for Help

[Wade Chandler]

Yes, see the Jira issues. One of them is related to scripting out the
content and sections. The sections, we really just need to name, then we
need templates for them. The scripted conversion doesn't need the templates
done nor to be perfect to run however as we can improve those. But, we will
want the conversion to take that into consideration; names, metadata, tags,
etc along with pulling out page titles, desciptions, and keyword and such
into the yaml.

I am working on section names and scripting along with template names. This
also merges platform.nb.org in with the other bits; see it as a subfolder
now. You can see some I have looked at in the Jira story. As far as the
.html.gsp files go, I plan to covert all files to that with scripting, then
if we need the processing we will have it without having to rename files. I
am also looking at what to do with the .inc.html files. I figure those will
become pieces of templates (possibly).

The other heavy lifting with regard to content will be the CSS work and
flushing out the different templates for sections as well as their specific
page types; what they look like. For instance, certain sections have
different asides plus menu options such as PHP and Java tutorial sections;
if you browse around netbeans.org.

On keeping the links, I feel there is some to keep, some to just redirect,
and some to just send to the home page. Some content is so dated it really
just isn't relevant at Apache, such as any platform or plugin stuff pre-6.5
or 6.9 IMO, but open to whatever. Now, some things related to "using" the
IDE, probably still useful. Too, if anyone had anything they specifically
want to add to the wiki feel free.

Too, if there is something that needs more drill down per the yaml,
html.gsp etc, let me know.

I am still trying to catch up on the emails.

Thanks

Wade


On Dec 10, 2017 13:57, "Neil C Smith"  wrote:

> On Sun, Dec 10, 2017 at 6:20 PM Antonio  wrote:
>
> > I imagine we'll have to go through all those "*.html" files (5504 to be
> > exact) and clean then up somehow.
> >
>
> As I said in the long email with questions for Wade, I still think doing
> this in one go, vs having a working static clone and going folder-by-folder
> / section-by-section is a better approach than trying to fix all the source
> *.html files now, but ...
>
> I suggested pulling out the body tag, but an "easier" way might be to build
> it into the pre-processing stage where Wade's code is adding the yml data -
> it shouldn't require a parser for this!?
>
> +1 for the conversion to asciidoc idea, although I still think later and
> section-by-section.
>
> Best wishes,
>
> Neil
> --
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
>
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
>

Re: NetBeans Website Conversion, Plan, and Call for Help

[Wade Chandler]

I imagine we should be able to some how move some of the old wiki bits to
Confluence with scripting. Please feel free to add a section and some jira
issues, and to take on some attempt at it. We probably also want to figure
out which wiki pages are now to become part of the static site; I figure
the dev and user FAQs may go to the static site.

Thanks

Wade


On Dec 3, 2017 13:08, "Ivan Soleimanipour" 
wrote:

Wade, I see no mention of the Wiki

NetBeans Website Conversion, Plan, and Call for Help

[Wade Chandler]

All,

I will try to keep this short as one can read details here 
https://cwiki.apache.org/confluence/display/NETBEANS/New+NetBeans+Web+Site+Planning
 


I’m still working on the site planning page, but I think there is enough there 
to get started and have others chip in, and please feel free to add sections 
I’m missing, and feel free to ask any questions, and I or someone else will try 
to address them. I would also like to get a Kanban board setup for this, and 
will try to get that done soon. Please ask for more details on the plan page or 
let me know what else might be useful for us to organize.

Also, please fully read the docs here 
https://github.com/wadechandler/netbeans-static-site 
 and if anything is 
missing or needs to be more clear, then please add an issue or send an email, 
and I will try to clear it up, and we can work through it.

There is a lot to do to convert the NetBeans website over to Apache. Beyond 
just the static content, we have these other dynamic aspects which I have yet 
to be able to devote any real thought.

I’m currently working on scripting the static content to fit the SSG, and that 
is a pretty big task, and I have more to do. Any help related to the areas I 
have not yet been able to touch is more than welcome.

You’ll notice the page says we're using the repository linked above for now, 
and that its only purpose is to cleanup the content, and shrink it, before 
moving it over to the incubator site repository; imagine how large that history 
will be if all the cruft is left in place. Anyways, it is definitely temporary, 
and then will be pushed to the Apache repository.

If there is an area anyone would like to jump in on, feel free to put your name 
beside an area in the Wiki and/or assign some issues to yourself. I’m taking 
Thur and Fri off through the end of the year, and plan to work diligently on 
the content conversion during that time, and hopefully narrow the plan more too.

Thank you much!

Wade

Re: Committer guidelines

[Wade Chandler]

> On Nov 16, 2017, at 16:42, Antonio  wrote:
> 
> Hi,
> 
> I was wondering if there're any guidelines for new committers. I assume that 
> the ones at https://netbeans.org/community/guidelines/ still apply after the 
> Apache donation. We could update that and add this to our web, right?

That file is in the web site that I’m aggregating. I have sent emails to this 
list about how to contribute in the past, so I assume you can find those. At 
the moment I’m working here 
https://github.com/wadechandler/netbeans-static-site 
 to get things cleaned 
up, and then plan for that to overwrite the Apache NetBeans repository once 
cleaned up “to a point” to keep the repo from bloating due to zips etc in the 
site sources, and to have a clean history. The two sites are being blended. 
There is a component called “website” in Apache NetBeans Jira, and you can see 
the stories here if you have any to add/etc 
https://issues.apache.org/jira/browse/NETBEANS-124?jql=project%20%3D%20NETBEANS%20AND%20component%20%3D%20website
 


There is a good bit to do there, and like I said before when I emailed this 
list, if anyone would like to contribute, you can either send PRs or I can make 
people contributors on github if they get me their GH user ID. Gj is one.

As far as the guidelines go, and as far as I understand, yes, a good bit of 
that is still applicable from the discussions on the list, but of course we are 
now using RTC for things other than small ones (even for committers) or at 
least we have discussed it. If we are not in agreement on that, then we should 
start a new thread and hash that out of course.

The rest, if anyone objects perhaps we need a new thread for each piece or at 
least a small enough chunk of relative areas to discuss.

> 
> Also, would any committer please export & share the code formatting options 
> for NetBeans?
> 

My understanding and as it has worked out throughout my contributions is that 
the NB sources use NBs default formatting. But if wrong, someone please correct 
me.

Thanks,

Wade

Re: Kanban / Scrum / Boards

[Wade Chandler]

John,

Do you know if we can also create Epics?

Thanks,

Wade



> On Nov 16, 2017, at 17:07, John McDonnell  wrote:
> 
> I created a basic Kanban board there to get a starting point, I’ll look to 
> clean it up next week.
> 
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=216 
> 
> 
> I’ll also need to make it visible to others, since its restricted at the 
> moment - Think this needs an INFRA ticket…
> 
> Regards
> 
> John
> 
>> On 16 Nov 2017, at 20:05, Antonio  wrote:
>> 
>> Do we want to try out Jira's Kanban/Scrum boards like these [1] in Apache 
>> Mesos?
>> 
>> Maybe the icon/splash/about dialog set of issues is a small project we could 
>> use to give Jira's boards a spin.
>> 
>> Cheers,
>> Antonio
>> 
>> [1]
>> 
>> - Apache Mesos Kanban
>> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=111
>> 
>> - Apache Mesos Sprint 68
>> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=62
> 

Re: Kanban / Scrum / Boards

[Wade Chandler]

I would very much be in favor of this. See the email I sent in November with 
the Subject “Jira Epics, Boards, and Agile Management, and What Other Projects 
Are Doing”. At the moment, we also can not create Epics, and I think some of 
these big picture things would benefit from them. When we create issues we have 
an option to choose an Epic, but I could not create one. I can help with the 
boards if I have access to manage them too. I prefer Kanban, and I think Kanban 
will suite not only the notion of “flow”, but also the way we work distributed 
and our timelines. Scrum will require sprints, if we are practicing it, and I’m 
not sure that cadence will match our community.

Thanks,

Wade



> On Nov 16, 2017, at 15:05, Antonio  wrote:
> 
> Do we want to try out Jira's Kanban/Scrum boards like these [1] in Apache 
> Mesos?
> 
> Maybe the icon/splash/about dialog set of issues is a small project we could 
> use to give Jira's boards a spin.
> 
> Cheers,
> Antonio
> 
> [1]
> 
> - Apache Mesos Kanban
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=111
> 
> - Apache Mesos Sprint 68
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=62

Re: Need Extra Jira Permissions To Create Components for NetBeans in Jira

[Wade Chandler]

It seems someone has created the “website” component now. Thanks for that. 
Please see my other message on Jira related items.

Thanks,

Wade



> On Nov 5, 2017, at 09:26, Wade Chandler <wadechand...@apache.org> wrote:
> 
> In the NetBeans project in Apache Jira, I need to be able to create at least 
> “website” as a component for managing some issues for that. Who up my 
> permissions to be able to do that, or do we need to ask for that to be 
> created?
> 
> Thanks,
> 
> Wade
> 
> 
> 

Jira Epics, Boards, and Agile Management, and What Other Projects Are Doing

[Wade Chandler]

All

Jira supports agile concepts such as Epics and Kanban boards. What are other 
projects doing in these areas? It seems as best I can tell they are using these 
features in various ways; I see boards and epics etc.

I would like to be able to create some boards for specific purposes or 
components of NetBeans, but it seems I do not have permissions to do so. Also, 
even though we have the option to link “Epics” to newly created stories/tasks, 
it seems the NetBeans project is not configured to be able to create and use 
them. Can we have that setup?

Thanks,

Wade

Need Extra Jira Permissions To Create Components for NetBeans in Jira

[Wade Chandler]

In the NetBeans project in Apache Jira, I need to be able to create at least 
“website” as a component for managing some issues for that. Who up my 
permissions to be able to do that, or do we need to ask for that to be created?

Thanks,

Wade

Re: Gradle

[Wade Chandler]

I think whatever keeps it working the best is the way to go for now. I also
think there are some aspects of the module center plus what is bundled with
NB builds that we should enhance; look at the way Visual Studio Code
handles such things as an example.

Now, that said, I see why some core NB tech makes sense to be in the main
repo, but I am not a big fan of an ever growing monolith repository.
However, I do believe that Gradle is an important and huge part of software
these days, and deserves support as part of the core NB functionality.

Thanks much

Wade


On Oct 24, 2017 17:52, "Attila Kelemen"  wrote:

> Hi!
>
> Geertjan asked me if I could move my Gradle plugin to be part of NetBeans.
> I would gladly do that but there are some problems to overcome as I don't
> know the Ant build of NB at all. Currently the Gradle plugin is built with
> Gradle (suprise, surprise) and does the following non-trivial things:
>
> - There two subprojects: "netbeans-gradle-default-models" and
> "netbeans-gradle-plugin". The latter is relatively trivial and depends on
> "netbeans-gradle-default-models"
> - "netbeans-gradle-default-models" is trickier however: It is separated
> from the core subproject because it is built with a different version of
> Java (Java 6 currently). The reason for using a different version of Java
> is because this jar will later be loaded by Gradle and thus will force
> Gradle to be started with a version of Java able to load
> "netbeans-gradle-default-models". The version of Java used to start Gradle
> is - most commonly - the version of Java used to build the user's project.
> - "netbeans-gradle-default-models" is again split into two source sets
> (not
> counting the tests): One is built using Groovy and the other is Java only.
> The Groovy code is never accessed directly by the plugin, only from within
> the Gradle process (it needs Groovy because it would be *very* inconvenient
> to use pure Java code to read from the Gradle process). Therefore the Java
> sourceset is not permitted to access the Groovy classes (it would cause a
> compile time failure).
> - "netbeans-gradle-default-models" depends on Gradle 1.8 API. Since the
> API
> is not (fully) uploaded to any Maven repository I know of, I download the
> Gradle distribution (1.8), unzip it and use its libs as dependencies (the
> build code does this automatically without any manual process). Note that
> only the Groovy sources are allowed to access the Gradle API as I'm not
> bundling the whole Gradle distribution with the plugin.
> - I run the tests against multiple Gradle versions and I do that by running
> the tests multiple times with the "TESTED_GRADLE_DAEMON_VERSION" system
> property set appropriately.
>
> Is there anyone who knows how this code could be integrated into the NB
> code base?
>
> Also, it would be nice to integrate the plugin in a way to be able to
> release a new version of the plugin (should a change in Gradle require us
> to do so) out of sync with NB updates.
>
> If implementing all these requirements in the Ant build are not feasible,
> would it be ok if the NB build would download the NBM of this plugin from
> JCenter and bundle it that way?
>
> Thanks,
> Attila Kelemen
>

Re: NetBeans 9 release date

[Wade Chandler]

On Oct 13, 2017 05:59, "Neil C Smith"  wrote:

In particular, it's no
secret I think JavaFX is a dead-end.  I'm not sure I foresee a time when
either project moves UI to JavaFX - maybe I'm wrong.


I have been pondering this as well, but I think that is for old projects
like both IntelliJ and NB, but views in them, sounds very reasonable to me.
It may be possible over time if we focus on a base platform set of changes
while supporting Swing too, but not sure it would be worth changing the IDE
itself over.

In the meantime,
while we're both using a UI toolkit that is semi-deprecated, maybe there is
useful collaboration to be done around Swing?


Yes; agree! I have also mentioned this in the NB community. I think we need
to contribute to Swing at OpenJDK. It seems more logical than not to me.

Thanks

Wade

Re: NetBeans 9 release date

[Wade Chandler]

Posting on top here. Regardless of an NB 9 release date, I think 2 things
can be huge factors.

1) That not everything we give users comes from Apache NetBeans, but
instead we make it super easy to link to projects build artifacts from the
idea of the plugin center. IMO, Visual Studio Code is rocking that out.

2) We have a good cadence to our releases and updates at some point. I
think we have to get much further to do it simply because of where we are
in this process, but the pieces we maintain as the core of NB needs to be
releasing fixes and features often. Those things should then better support
#1 which makes it easier for other languages and features to be available
for users without us having to care about the projects specific license,
nor the people writing it needing to buy in fully to our base processes.

I think once we get moved over, and get to where we can release, addressing
some big points first, such as indexing or lockups and slow downs, along
with agreeing on the above or it's alternatives, then we can really move
forward in some great ways. But, we have to do innovative things, and
support others doing them too without our overhead if they perceive things
that way.

We can really start to look at those innovative and better ways to do
things once moved over. It is a definite prerequisite that I think we
cannot worry about, but just do. A new version of NB is important, but
let's not let that get in the way of where we are trying to get to to move
to Apache. Things can and will come roaring back, but only if we get there.

I think the folks already in the queue can make the above a reality, and
IMO the end users will come, come back, or stay. I say this as someone who
uses NB daily to build software other than NB, and as a contributor.

If the contributors are making the IDE and platform awesome, then it will
continue to exist, and get better, and then the user problem will solve
itself even if we have a perceived bump in the road; it really will. The
beauty is there is no company to stop supporting it, so if contributors
keep contributing, it has only an upside. Without that, nothing but a down
side, so let's just keep rallying around it.

Thanks

Wade


On Oct 13, 2017 03:09, "Geertjan Wielenga" 
wrote:

> On Fri, Oct 13, 2017 at 9:49 AM, Bertrand Delacretaz <
> bdelacre...@apache.org
> > wrote:
>
> > Hi,
> >
> > On Fri, Oct 13, 2017 at 1:21 AM, Antonio Vieiro 
> > wrote:
> > > ...Should NetBeans support Apache Spark? Tomcat? The Go programming
> > > language? R? Whatever? Just find a big pool of developers and ask them
> > > what to do next, what they need, what they want...
> >
> > Funding such work is a problem - I could tell you guys that I want to
> > use NetBeans for Go, but why would someone work for free on
> > implementing that?
>
>
>
> Someone has already been working for free on implementing that:
>
> http://tunnelvisionlabs.com/products/demo/goworks
>
> Here's another one:
>
> http://plugins.netbeans.org/plugin/62162/go-project
>
> Here's another one:
>
> http://plugins.netbeans.org/plugin/25606/go
>
> And there's probably more, in various states of usefulness and stability.
>
> Under Apache, what we'll be able to have is a central place where everyone
> working on Go can work together. We've never had such a central neutral
> place before, it's always been various people working on their own outside
> Sun or Oracle and never without an organized structure for interacting and
> co-operating with each other.
>
> There's very few technologies and languages for which some kind of support
> doesn't already exist for NetBeans over the years -- all created for free
> by enthusiastic supporters of one technology or another. In answer to your
> question -- people work for free to create tooling for a technology, such
> as Go, in order to promote that technology, for whatever reason.
>
> Gj
>

Re: Should We Have A Users Email Address Now? (To start moving folks from the other lists who won't do dev, but may just ask questions)

[Wade Chandler]

Sheeesh...how did I miss that? Cool, so we should direct folks to the list
right? I can do that instead of replying on nbus...@netbeans.org.

Thanks

Wade


On Oct 12, 2017 07:19, "Geertjan Wielenga" <geertjan.wiele...@googlemail.com>
wrote:

> We do have a users e-mail address right now, already.
>
> Gj
>
> On Thu, Oct 12, 2017 at 1:11 PM, Wade Chandler <wadechand...@apache.org>
> wrote:
>
> > All,
> >
> > The subject pretty much says it all. What do you think? I prefer being
> > able to sort my email without having to rely on special subject additions
> > by email users myself, and if we want to get folks to start moving here,
> I
> > doubt many of those on nbusers will necessarily want to be on the dev
> list
> > either.
> >
> > Thanks,
> >
> > Wade
> >
> >
> >
>

Should We Have A Users Email Address Now? (To start moving folks from the other lists who won't do dev, but may just ask questions)

[Wade Chandler]

All,

The subject pretty much says it all. What do you think? I prefer being able to 
sort my email without having to rely on special subject additions by email 
users myself, and if we want to get folks to start moving here, I doubt many of 
those on nbusers will necessarily want to be on the dev list either.

Thanks,

Wade

Re: Squashing, Git, PRs, and Maybe Other Processes

[Wade Chandler]

Fair enough indeed. It would be good if someone from infra or a mentor
could tell us if PR merges work well enough from the Github side, unless
you all have already been merging by clicking merge on them there, or if
those merges have to be done through the ASF repositories and locally.
Since I am working on the static site, I have not looked at the other PRs
and repositories to see, but it would be great if we are able to use a flow
driven from the PRs directly through GH IMO.

Thanks much,

Wade

On Oct 11, 2017 2:18 PM, "Emilian Bold"  wrote:

I only like squashing because I'm merging single commits and I don't
want another 'merge' commit.

Sure, if a feature is implemented and it has 20 commits, it does have
some importance to preserve those since, if they are well made, there
is some logical progression there that you will need for future
reference.

Other than this aspect, I think we are doing fine. Our changes so far
are minor. Once we start contributing fixes and features and alter
things deeper then we have to think about how to thread on thin ice
more efficiently.


...snip

Re: Squashing, Git, PRs, and Maybe Other Processes

[Wade Chandler]

Thanks Emmanuel, comments inline...

On Oct 11, 2017, at 12:11, ehsavoie  wrote:
> 
> Hi,
> About squashing : having a single commit makes it easier to
> - backport for maintenance
> - revert

Agree to a point there; it is definitely “easier”, having a single value, but 
cherry picking a range is pretty trivial as well:
https://www.tollmanz.com/git-cherry-pick-range/ 


Revert and other commands can work with a range too, and getting the range from 
a point in time relative to a specific merge is pretty easy (especially if 
there is a PR). The UI for a PR will let one click revert and do the same thing 
if using GH or Bitbucket as an example.

> - review : you don't review some code that might disappear in the next
> commit

I’m not sure I follow here; that seems always like a possibility if it is one.

> Maybe the task should be divided into multiple sub task thus allowing
> multiple PRs

I agree that is always something someone should review and sub-task, but isn’t 
the way that will always work out.

Thanks,

Wade

Re: Who is asfgit?

[Wade Chandler]

Does the Apache process allow merge from the PR itself on the GH side? If
so, that seems a better approach to me. Too, considering a PR, from a
submitters POV is generally an atomic operation, the logic in the PR should
be addressed then merged as a whole. It would keep magic PR closing from
happening when not expected. Too, it will limit folks missing messages in
the PR.

Thanks

Wade


On Oct 11, 2017 06:38, "Matthias Bläsing"  wrote:

> Hey,
>
> asfgit is a bot, that synchronizes the github and Apache git repositories.
>
> There was no automatic merge, I merged your changes, if I saw no problem.
> For problematic changes I added a comment to the PR and die not merge
>
> Greetings
>
> Matthias
>
>
>
> Am 11. Oktober 2017 12:28:35 MESZ schrieb Geertjan Wielenga <
> geertjan.wiele...@googlemail.com>:
> >Hi all,
> >
> >Someone appears to automatically (I guess a bot) be merging PRs after a
> >couple of days of inactivity, i.e., if there are no comments etc, such
> >as
> >this one of mine:
> >
> >https://github.com/apache/incubator-netbeans/pull/103
> >
> >Is that correct and what we want? I.e., nobody reviewed the above nor
> >asked
> >any kind of questions about it.
> >
> >Gj
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.

Re: [legal] [mentors] Incorporating dendencies into the final JAR

[Wade Chandler]

If they are NB specific files that seems exactly like what should happen…the 
files be donated. Is that what you are saying Emi?

Wade



> On Oct 9, 2017, at 12:45, Emilian Bold  wrote:
> 
> Hello,
> 
> For websvc.saas.api/ I see that 2 xsd files, which have the original GPL w/
> CPE + CDDL NetBeans dual license have been moved into an external
> dependency, external/websvc-saas-api-external-resources.zip.
> 
> Then, during the build they are copied back into src/
> https://github.com/emilianbold/incubator-netbeans/blob/master/websvc.saas.api/build.xml#L36
> 
>>  dest="src/org/netbeans/modules/websvc/saas/model"/>
> 
> Two things:
> 
> * why couldn't these two XSD files be donated too? The seem standard Oracle
> / Sun / NetBeans code.
> 
> * assuming Apache elects CDDL (which it has to), what is the legal impact
> on the final resulting JAR which incorporates this "dependency". I assume
> it's fine, but the whole construct is unexpected.
> 
> --emi

Re: Introducing myself & stepping forward

[Wade Chandler]

Great to see you here Antonio!

Wade


On Oct 1, 2017 2:04 PM, "Antonio Vieiro"  wrote:

> Hi all,
>
> This is Antonio Vieiro, an old time NetBeans enthusiast based in Madrid,
> Spain.
>
> I've been keeping an eye on the NetBeans incubator process for a
> while. It seems there's a looong list of modules to review at
>
> https://cwiki.apache.org/confluence/display/NETBEANS/
> List+of+Modules+to+Review
>
> I was wondering if you need a hand on the review process and, if so,
> I'd appreciate some further instructions on how I should proceed.
>
> Kind regards,
> Antonio
>
> P.S.: Yep, I was a NetBeans Dream Team Member a few years ago.
>

Re: README and Blog

[Wade Chandler]

On Sep 30, 2017 5:34 PM, "Geertjan Wielenga" <
geertjan.wiele...@googlemail.com> wrote:

Login there, i.e., create a user and password, tell me what your user name
is and I can give you permission access to https://blogs.apache.org/netbeans


Done. My Roller user name is "wadechandler". By the way, to do this, you
first just login with your main Apache ID; an FYI for others.

Thanks

Wade

Re: README and Blog

[Wade Chandler]

On Sep 29, 2017 05:31, "Geertjan Wielenga" 
wrote:

OK, requested a new blog and ...snip


The worst part about the Apache blogs IMO is the lack of mobile support
when trying to view them on a phone. Undoubtedly the posts will be linked
by Twitter and other mobile platforms, and thus, how can we get the Apache
blog to be mobile friendly?

Can anyone give us some pointers? Is this run with software which we have
the sources, such as an Apache project? If not, are we able to modify the
Apache blog's CSS? How can we get involved with that, to help make it a
responsive experience?

Thanks

Wade

Re: Allow code contributions or focus on release only?

[Wade Chandler]

That all sounds like a good strategy to me.

+1

Wade

On Sep 26, 2017 17:44, "Craig Russell"  wrote:

> I have no dog in this particular hunt, but if it were up to me I'd
> prioritize:
>
> getting code into repositories with clean RAT reports
> getting Netbeans to build and run
> creating release(s) for major platforms
> ...
> serious bug reports
> ...
> features (in branches)
>
> Craig
>
> > On Sep 26, 2017, at 1:16 PM, Sven Reimers 
> wrote:
> >
> > Hi all,
> >
> > I fully agree with Jan..
> >
> > Let's try to get something released first so we know the process..
> >
> > Hope to have some time to review modules real soon now..
> >
> > -Sven
> >
> > Am 26.09.2017 22:13 schrieb "Jan Lahoda" :
> >
> >> +1 (I think that if we want to get some rest and fun, we could use
> branches
> >> to experiment with some new features (and I may do so at some point),
> but
> >> we should limit unnecessary changes to master, and use our code
> >> review/discussion bandwidth as much as possible for working on a
> release)
> >>
> >> I personally even think we could try to release just the platform (e.g.
> >> NetBeans Platform 9.0 beta) once the platform modules are reviewed. That
> >> would help us validate whether the approach we are taking makes sense
> (and
> >> what needs to be improved) and would help us learn about the release
> >> process (and the platform is a useful thing on its own, so releasing it
> >> wouldn't be just an artificial move).
> >>
> >> Jan
> >>
> >>
> >> On Tue, Sep 26, 2017 at 8:23 PM, Michael Nascimento 
> >> wrote:
> >>
> >>> Definitely we should focus on getting an Apache NetBeans release.
> >>> Sincerely, at this point, I think we should maybe have a Apache
> NetBeans
> >>> 9.0 Java edition, so we can have something release and then a full
> Apache
> >>> NB 9.0. Otherwise, sounds like we'll get no release this year, which
> >> would
> >>> be pretty sad.
> >>>
> >>> Regards,
> >>> Michael
> >>>
> >>>  >>> utm_source=link_campaign=sig-email_content=webmail>
> >>> Virus-free.
> >>> www.avg.com
> >>>  >>> utm_source=link_campaign=sig-email_content=webmail>
> >>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >>>
> >>> On Tue, Sep 26, 2017 at 4:17 AM, Geertjan Wielenga <
> >>> geertjan.wiele...@googlemail.com> wrote:
> >>>
>  Hi all,
> 
>  We need to discuss something, I think -- do we begin accepting pull
>  requests, and thereby encourage pull requests to be created -- or do
> we
>  focus very narrowly on preparing Apache NetBeans for its first
> >> incubator
>  release?
> 
>  If we were to focus narrowly on preparing the Apache release, then
> this
> >>> is
>  what we would focus on, nothing else:
> 
>  https://cwiki.apache.org/confluence/display/NETBEANS/
>  List+of+Modules+to+Review
> 
>  At the same time, of course, people want to add their mark to Apache
>  NetBeans. And that means code or an icon, a menu item, a new UI thing
> >> to
>  point at and say -- see, I did that! These kinds of enhancements could
> >> be
>  done at the same time as the above, and would require that some people
>  split their time between doing the module reviews and reviewing pull
>  requests.
> 
>  I'm not stating a preference here, just putting the discussion out
> >> there,
>  since I've seen conflicting opinions about this and I think it would
> be
>  good to discuss this centrally.
> 
>  Thanks,
> 
>  Gj
> 
> >>>
> >>
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
>
>

Re: Form files & manifest files headers was: [Mentors] Review my migration steps was: My first commit

[Wade Chandler]

.form files are related to the Swing designer. They do not necessarily “house” 
the code, though they will overwrite certain code from the .java file if the 
Java is modified outside of NetBeans, causing the files to become out of sync, 
as they maintain some event logic and Swing specific layout information. They 
are very specific to the NetBeans form designer. They can be used to build 
NetBeans itself or used to build your own Swing based UI, including those on 
top of the NetBeans RCP. They are not used at compile time at all, but only 
used when opening the files in the Swing visual editor (Form Editor) inside of 
the IDE.

So, they do represent code to some degree, at least for maintaining code using 
the Form Designer, but they are XML files specifically related to how the 
designer keeps the .java file updated, protected, etc during edits.

Hope it helps,

Wade



> On Sep 7, 2017, at 01:42, Craig Russell <apache@gmail.com> wrote:
> 
> Hi,
> 
> Resolving this issue is important for later but not important to the present 
> task of importing the donated files.
> 
> I'm not familiar enough with the work flow for .form files which makes this 
> thread impossible for me to follow.
> 
> The goal is to have the .form files contain an Apache header when 
> distributing the project. Manually adding the header seems awkward at best.
> 
> The tool creates a .form files. What exactly is the process? Else thread I 
> recall it was said that non-Apache-licensed .form files should also be 
> supported. So always adding the Apache header is clearly inappropriate.
> 
> If I understood better the process for creating and editing the .form files I 
> could make some suggestions.
> 
> Regards,
> 
> Craig
> 
>> On Sep 6, 2017, at 12:49 PM, Wade Chandler <wadechand...@apache.org> wrote:
>> 
>> Either way, I think doing what is suggested in these couple comments, and 
>> what Jarda is saying, are orthogonal. I feel we should take it as it is at 
>> the moment, as Jarda suggested, and if it isn’t supported, it isn’t. There 
>> is a license file for the project as a whole, and there are files in the 
>> Java files one must have for the form file to have any meaning any ways. The 
>> rest, I suggest is a new thread and a Jira issue for a feature; IMHO. 
>> Otherwise the thread will get convoluted.
>> 
>> Thanks
>> 
>> Wade
>> 
>> 
>>> On Sep 6, 2017, at 14:26, Michael Nascimento <mist...@gmail.com> wrote:
>>> 
>>> Jan,
>>> 
>>> The idea would be to add the license only if it's configured for the
>>> project.
>>> 
>>> Regards,
>>> Michael
>>> 
>>> On Wed, Sep 6, 2017 at 3:14 PM, Jan Lahoda <lah...@gmail.com> wrote:
>>> 
>>>> On Wed, Sep 6, 2017 at 7:50 PM, Michael Nascimento <mist...@gmail.com>
>>>> wrote:
>>>> 
>>>>> On Wed, Sep 6, 2017 at 5:56 AM, Jan Lahoda <lah...@gmail.com> wrote:
>>>>> 
>>>>>> For forms, I guess we could (at some point):
>>>>>> -change the form editor to preserve leading comments
>>>>>> -manually add the headers to the form files
>>>>>> -(possibly) change the templates to include the license header when the
>>>>>> form file is created (but if we don't, adding the license header
>>>> manually
>>>>>> for code in Apache NetBeans probably wouldn't be that troublesome).
>>>>>> 
>>>>>> (I don't think we should change the form editor to force add the header
>>>>> on
>>>>>> each save, simply preserving what is there should be enough I think.)
>>>>>> 
>>>>> 
>>>>> If we believe Apache projects will be developed using NetBeans more
>>>> often,
>>>>> they will need to have license headers added to their own .form files
>>>> too.
>>>>> It'd be painful do it manually.
>>>>> 
>>>> 
>>>> If we changed the templates to include the license headers, then newly
>>>> created files would get them (and the headers would then be preserved
>>>> through future saves). I suspect adding the headers to existing files would
>>>> be simpler using a script than by opening them and having them regenerated.
>>>> 
>>>> If we would add the headers on each save, I'd be worried it could cause
>>>> issues for existing files in version controls (for people that don't use
>>>> license headers for forms).
>>>> 
>>>> Jan
>>>> 
>>>> 
>>>>> 
>>>>> And NetBeans would be more consistent about license header handling. But
>>>> as
>>>>> said, for the first release, I'd add them manually just to be compliant
>>>>> with the policy.
>>>>> 
>>>>> Regards,
>>>>> Michael
>>>>> 
>>>> 
>> 
> 
> Craig L Russell
> c...@apache.org
> 

Re: Form files & manifest files headers was: [Mentors] Review my migration steps was: My first commit

[Wade Chandler]

Either way, I think doing what is suggested in these couple comments, and what 
Jarda is saying, are orthogonal. I feel we should take it as it is at the 
moment, as Jarda suggested, and if it isn’t supported, it isn’t. There is a 
license file for the project as a whole, and there are files in the Java files 
one must have for the form file to have any meaning any ways. The rest, I 
suggest is a new thread and a Jira issue for a feature; IMHO. Otherwise the 
thread will get convoluted.

Thanks

Wade


> On Sep 6, 2017, at 14:26, Michael Nascimento  wrote:
> 
> Jan,
> 
> The idea would be to add the license only if it's configured for the
> project.
> 
> Regards,
> Michael
> 
> On Wed, Sep 6, 2017 at 3:14 PM, Jan Lahoda  wrote:
> 
>> On Wed, Sep 6, 2017 at 7:50 PM, Michael Nascimento 
>> wrote:
>> 
>>> On Wed, Sep 6, 2017 at 5:56 AM, Jan Lahoda  wrote:
>>> 
 For forms, I guess we could (at some point):
 -change the form editor to preserve leading comments
 -manually add the headers to the form files
 -(possibly) change the templates to include the license header when the
 form file is created (but if we don't, adding the license header
>> manually
 for code in Apache NetBeans probably wouldn't be that troublesome).
 
 (I don't think we should change the form editor to force add the header
>>> on
 each save, simply preserving what is there should be enough I think.)
 
>>> 
>>> If we believe Apache projects will be developed using NetBeans more
>> often,
>>> they will need to have license headers added to their own .form files
>> too.
>>> It'd be painful do it manually.
>>> 
>> 
>> If we changed the templates to include the license headers, then newly
>> created files would get them (and the headers would then be preserved
>> through future saves). I suspect adding the headers to existing files would
>> be simpler using a script than by opening them and having them regenerated.
>> 
>> If we would add the headers on each save, I'd be worried it could cause
>> issues for existing files in version controls (for people that don't use
>> license headers for forms).
>> 
>> Jan
>> 
>> 
>>> 
>>> And NetBeans would be more consistent about license header handling. But
>> as
>>> said, for the first release, I'd add them manually just to be compliant
>>> with the policy.
>>> 
>>> Regards,
>>> Michael
>>> 
>> 

Re: Please make more public APIs for 3rd-party-plugins available for languages NOT Java

[Wade Chandler]

I think the problem with friend is it gets way over used, and thus those things 
remain closed, and using yenta to work around such things isn’t great if your 
argument that there is a reason for it is the answer as one is just working 
around the reason. So, either the reason isn’t as needed as we often assume, or 
use of workarounds not to be a friend module isn’t the answer for many 
questions. i.e. if there is logic where friend access has become the norm, and 
is used by N number of modules instead of just a couple, and for just a short 
period of time, then the API should not continue to be used in a friend manner, 
and should be flushed out. I feel there are plenty of APIs which have remained 
friend only for some time because it has been easy from the internal NB 
perspective to not support them because “they might change” or there wasn’t 
time to flush them out as public APIs, but they have limited 3rd party access 
to some things. I don’t have specifics up at the moment, but have answered 
enough questions over the years, to have had this gut feeling more than a few 
times.

Wade


===

Wade Chandler
e: cons...@wadechandler.com



> On Jul 19, 2017, at 09:53, Emilian Bold <emilian.b...@gmail.com> wrote:
> 
> Please read about http://wiki.netbeans.org/API_Stability and
> http://wiki.netbeans.org/API_Design
> 
> We can't just make everything well by making everything public APIs.
> Because on the next update a small refactoring will break all the
> modules.
> 
> Note the clever hack this module does
> https://bitbucket.org/jglick/yenta if it's just a matter of "friend"
> access. Still, friend access has a reason and 3rd party modules will
> break if they don't keep up.
> 
> --emi
> 
> 
> On Wed, Jul 19, 2017 at 12:43 PM, Christian Lenz <christian.l...@gmx.net> 
> wrote:
>> Often I see tutorials about how I can add Hints for Java for example or how 
>> I can extend the Java Editor and so on, but when we want to extend 
>> JavaScript (I know the KendoNetbeans repo from Geertjan, which is not 
>> working anymore, because it is not a friend) we can’t extend this Editor. Or 
>> adding hints for CSS (Geertjan tried it too, but it was not possible). So 
>> everlaw, the guys from the TypeScript plugin has Problems to, to extend to 
>> have full power for TS (e.g. adding formatting optiosn to TypeScript, it is 
>> not possible because TS is not a friend of a specific package). So it is 
>> really a pain in the ass. NetBeans is not a Java IDE anymore, it has Support 
>> for a lot of languages so please make the APIs more public to the developers 
>> of 3rd-party-plugins.
>> 
>> 
>> Regards
>> 
>> Chris
>> 

Re: NetBeans and C++

[Wade Chandler]

On Jul 14, 2017 3:23 AM, "Vladimir Voskresensky" <
vladimir.voskresen...@oracle.com> wrote:



On 14.07.2017 04:23, Wade Chandler wrote:

> On Jul 13, 2017 3:19 PM, "Vladimir Voskresensky" <
> vladimir.voskresen...@oracle.com> wrote:
>
>
> On 13.07.2017 22:09, Wade Chandler wrote:
>
> So is the C++ support being removed from Apache NB, and done as 3rd party
>> stuff from Oracle, or is there some way to make this work at Apache?
>>
>> The plan published by Geertjan saying C++ is donated after Java support is
> donated (end of August?).
>
> Just some binary from closed sources doesn’t seem the Apache way per other
>
>> discussions.
>>
>> I hope you misunderstood the other discussion:
> External binaries under Apache-friendly license are OK to be used in Apache
> NetBeans.
>
> Btw, being just binaries with LLVM license might even simplify the current
> process for donation of sources.
> Because Clank source code base is 2.6MLOC...
>
>
> I am not sure closed source binaries are the same thing regardless of the
> license. I may have misunderstood for sure. It read like Clank and the
> other libs sources are in Oracle and not open unlike nbjavac which I
> understand the sources will be available. Have I misunderstood? If so,
> great.
>
You might be right, I could be wrong...
Someone should clarify the case.


We can specifically ask the mentors, but for further clarification, is
Clank closed source? If so, the use of an OSS license means the license
isn't being followed actually; as there are no sources. It all depends on
project setup or packaging and distribution of sources etc I am sure (per
definitions here). But, certainly if the sources are not available, or
there is no contribution model outside of Oracle, that presents problems
for library dependencies, and doesn't follow the spirit of an OSS license.
The difference being library versus tool set users are expected to already
have on their systems such as Clang or GCC.

Hopefully others here, who will choose to spend time on NetBeans, will
agree with me, that we would like to be able to fix issues as they arise
regardless of Oracle's further commitments to the project, and if the
situation is how it sounded/read to me, I think it would be counter to that
and also "The Apache Way". If we can contribute to Clank easily enough,
because the sources are open in a way that aligns with other dependencies,
that is of course a different story.

Thanks

Wade