Re: carriage return newlines in MacOS installer
On Tue, Apr 5, 2022 at 11:57 AM Todd Stevenson wrote: > The config file is only read by the netbeans platform code. I guess the big question is are you doing these builds on a macOS system, and not a Windows system?
Iterating and debugging netbeans
I'd like to work on, hopefully, some small bit of functionality within the IDE. There's instructions on building from the raw source. But once you've done that, and found the little bit of code that you want to work with, how to you iterate the code-build-test/debug rinse/repeat cycle? I'm sure you don't just continually rebuild from the root, right? Is this process written up somewhere? And while I'm sure I've seen a "debug netbeans from netbeans" document somewhere, doing a web search on that is pretty much useless to get that specific concept. (You just get generic debugging java with netbeans links). So, how is that best set up? Thanks. Regards, Will Hartung
Maven WAR build fails in 12.5
If you create a Java With Maven -> Web Application, the generated project does not build. it's some kind of maven issue. Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.3:war (default-war) on project nbwartest: Execution default-war of goal org.apache.maven.plugins:maven-war-plugin:2.3:war failed: Unable to load the mojo 'war' in the plugin 'org.apache.maven.plugins:maven-war-plugin:2.3' due to an API incompatibility: org.codehaus.plexus.component.repository.exception.ComponentLookupException: null After some poking about, it seems that the 2.3 WAR plugin is not compatible with JDK 16. It works fine with JDK 11. If you upgrade the maven war plugin in the pom to 3.3.2: org.apache.maven.plugins maven-war-plugin 3.3.2 Then it works in Netbeans. This seems to be an issue with the combination of JDK 16 and that plugin. So whomever is maintaining the maven prototype that NB is using should either update their prototype, or push a new version and a change to NB to use the new version. Regards, Will Hartung
Re: [DISCUSS] Let's require NetBeans to be built with JDK11 was: reviving old thread
This will probably be heresy, but any reason to not bump up to v13 so that it's blatantly obvious something dramatic has changed? (Base JDK is kind of dramatic)
Re: Compile time for NB
Modern Intel iMac. 3.8GHz 8-Core Intel Core i7 72GB of RAM internal SSD 8:30 first build. 7:48 second build, after an ant clean. On Thu, Jul 29, 2021 at 2:54 AM Michael Bien wrote: > BUILD SUCCESSFUL > Total time: 6 minutes 4 seconds > > on an old i7-6700k (with hyperthreading disabled, otherwise its stock if > i remember correctly). > > However i cheated. I built on a ramdisk and also redirected the console > output to a file. The NB build prints so much that this alone can be a > bottleneck on some shells. > > Ramdisks are an old habit from back when SSDs were unreliable (and HDDs > slow) while RAM was one of the cheapest components in my workstation. > Got a bit out of fashion when NVMe arrived, but its still often the > fastest way you can build things. > > > have a nice retirement and may the builds never fail :) > > best regards, > michael > > > On 28.07.21 23:19, Kenneth Fogel wrote: > > Just for my curiosity I'd like to know how long it takes you to compile > NB using AdoptOpenJDK-11.0.11+9 and Ant 1.10. I compiled what I found at > https://github.com/apache/netbeans. Here are my results: > > > > System 1: > > 4th gen i7-4770 @3.4GHz > > 16 GB RAM > > 768 GB SSD drive w/ SATA interface > > 18 minutes > > > > System 2 (my retirement present to myself): > > 11th gen i9-11900 @2.5GHz (increases to 5.0GHz on demand) > > 32 GB RAM > > NVMe 1TB drive > > 11 minutes > > > > In both cases the folder where the code was being compiled was excluded > from the anti-virus software, Windows Security. On system 2 leaving the > anti-virus turned on for the folder, it added just under 3 minutes. The > disk access and I/O in general is considered slower in Windows as compared > to other operating systems. One of those "Everyone knows this" that I'd > like to prove or disprove. > > > > I'd be curious about performance on Linux and on m1 Macs with and > without anti-virus software running. > > > > Thanks, > > > > Ken > > > > > > > > > > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: Fwd: NB and JDK 17 - OpenJDK Quality Outreach
On Sun, Jul 11, 2021 at 2:18 PM Ty Young wrote: > Maybe a bit too negative, even for me. Netbeans has seen various > improvements over the years although it does feel slow and small. I > suppose that's just because of it being purely Open Source and not > having a paid for version with which full time people can be paid to > work on it. Although, ironically, despite being a paid product, intellij > still has worse Maven support integration than Netbeans from what I've > experienced. > Honestly, this is as much an issue with the JDK as it is with NB. Nobody wants JDK 6 for 10 years, but the current crazy pace means that NB folks have to spend a whole bunch of time maintaining the status quo, much less add anything new, or bring older stuff up to date. Obviously this is a "small team" syndrome, and perhaps could be mitigated somewhat if the NB team said "We're only supporting LTS versions", to give them some breathing room, but I think that's not really what the community or the developers are looking for. Which is why it's even more important for the community to step up on the fringes to help keep the system current. Regards, Will Hartung
Re: FXGL samples to be built into NetBeans
On Sat, May 29, 2021 at 1:16 AM Geertjan Wielenga wrote: > ...we should do this and replace all our JavaFX game samples, that mostly > don't work anyway, with FXGL. > I didn't even know we had FX game samples, nor have I ever heard of FXGL. But, I agree! FXGL looks pretty cool. Regards, Will Hartung
Re: [VOTE] Release Apache NetBeans 12.4 (vote candidate 1)
On Mon, May 17, 2021 at 4:15 AM Neil C Smith wrote: > +1 (binding) > > Verified hashes, signing, files, etc. > > Built with JDK 8 on Ubuntu 20.04, tested with JDK 16. > > Verified binary zip, including module versions match release git hash. > > The change between rc3 and vc1 in Java platform downloader seems a > little flaky? Few exceptions and possibly missing info? Not a reason > to hold up. > > As Tomáš mentioned, we should include these additional JARs in the > allowed list - > contents verified as OK. > > ./java/maven/test/unit/data/mavenmock/2.2/lib/fake221.jar > ./java/maven/test/unit/data/mavenmock/3.3.1/lib/fake331.jar > ./java/maven/test/unit/data/mavenmock/source.jar > ./java/maven/test/unit/data/mavenmock/3.0.5/lib/fake305.jar > ./java/maven/test/unit/data/mavenmock/4.0.0/lib/fake400.jar > > I find extra jars $ find . -name "*.jar" ./java/java.lsp.server/nbcode/branding/core/core.jar ./java/java.lsp.server/nbcode/branding/modules/org-netbeans-modules-gradle.jar ./java/java.lsp.server/nbcode/branding/modules/org-netbeans-core-windows.jar ./java/java.lsp.server/nbcode/branding/modules/org-netbeans-modules-projectui.jar ./java/java.lsp.server/nbcode/branding/modules/org-netbeans-modules-maven.jar ./java/java.lsp.server/nbcode/branding/modules/org-netbeans-modules-maven-indexer.jar ./java/java.lsp.server/nbcode/branding/modules/org-openide-loaders.jar ./java/java.lsp.server/nbcode/branding/modules/org-netbeans-modules-java-j2seplatform.jar ./java/java.lsp.server/nbcode/branding/modules/org-openide-text.jar The SHA matched, it built w/JDK 11, it launched. I don't know how to vet the keys. +1 from me. Regards, Will Hartung
Re: RE: Netbeans "owning" Maven archetypes
On Fri, Apr 23, 2021 at 5:06 AM Eric Bresie wrote: > Just to understand the problem being discussed > > There are Netbeans wrapper plugins (I.e. Netbeans specific artifacts) like > the JavaFX or Java EE plugins > These plug-ins have dependencies on third party libraries which (possibly > depending on licenses) are or are not included in the wrapper plug-in. > If included then the wrapper may need updating to reflect newer version > when developing or packaging the plug-in artifact (to be published > someplace like maven central) > If not included then they may need to be retrieved from a location in the > process (either development or runtime) which may no longer be available. > Specifically for the JEE ones. There is no "official" source of the original artifacts any more, the assets of codehaus have been mirrored across several repositories. And those are just mirrors, I don't know if anyone is actively maintaining them. For the new JEE, notably Java EE 8 and Jakarta EE 9, new artifacts need to be created. The JEE Wizard also needs to be updated back to what it originally did with orchestrating these artifacts. NB can readily create projects from archetypes, and that's not the issue I'm seeing. What I'm seeing is that there's hard coded behaviour that's dependent on the archetypes, so, potentially, if the archetype changes, the code and functionality breaks. Thus there's a tighter coupling between the two. I think the work is straightforward to restore the functionality for the EJB, I just don't know where the archetypes would be committed, or how they would be published. Would I just commit them to the NB source tree and publish them myself to Maven central? How and where is the process documented? Ostensibly it's a one shot, published once and done thing, so it's not like it needs a CI pipeline to back it up. It's more procedural than anything else. Regards, Will Hartung
Re: Netbeans "owning" Maven archetypes
On Thu, Apr 22, 2021 at 8:50 AM Geertjan Wielenga wrote: > Probably the archetypes are open source and you'd provide pull requests to > them. > The problem is that the ones we used in the past have vanished. That's why the NB 8.x wizards are failing, the archetypes were hosted by codehaus, and they've gone off line. I'm trying to locate the original sources, but currently they have no home so even if they're found, they need a new one. Is there any reason that NB can be the new home for these? Regards, Will Hartung
Re: Netbeans "owning" Maven archetypes
On Thu, Apr 22, 2021 at 7:29 AM Geertjan Wielenga wrote: > There's so much we don't own. We integrate. Yes, that has disadvantages, > but also the advantage that we can help users with actually existing, e.g., > Maven archetypes, rather than those made specifically for NetBeans. > > On the other hand, there's nothing stopping anyone from providing pull > requests for any Maven archetype, including their own custom ones, e.g., > there's a new Micronaut project template in the upcoming 12.4 using the > publicly available Micronaut Maven archetype. > Well if I were to fix some of the JEE wizards, how should I go about publishing the archetypes? It just seems odd to me to have, perhaps, NB specific archetypes outside of the NB project. Now, I could just update the wizards to not use the archetypes at all, and code up the code generation internally. That, sorta, solves the problem, but maybe that's not the best idea. I just wanted to more bring what we have up to date. Regards, Will Hartung
Re: Netbeans "owning" Maven archetypes
On Wed, Apr 21, 2021 at 11:39 PM Geertjan Wielenga wrote: > Indeed, if there's a particular technology that isn't supported correctly > in NetBeans or is outdated, just create an issue and let's work on it. > > Can we do that, point to a specific problem that needs to be fixed? > I would take a stab at fixing the JEE project wizards, but I'm not willing to do that if NB can't own the maven archetypes. The archetypes and the wizards are intertwined, it does not appear to be a simple wrapper around just invoking the archetype, so one can't be changed without the other. If we can come up with a mechanic for hosting/publishing the archetypes, then I'll open an issue and dig in to it further. Regards, Will Hartung
Re: Netbeans "owning" Maven archetypes
On Wed, Apr 21, 2021 at 12:22 PM Ernie Rael wrote: > The point is that depending on a 3rd party project for functionality > that NetBeans provides is a problem. But there is push back to provide > even simple maven archetypes. And, at least possibly until now, little > interest in supplying archetypes from NetBeans project. > Then, quite frankly, the baby should be tossed out with the bathwater. If there's going to be this clash between the NB project and 3rd parties, then NB should abandon anything related to third parties that they're unwilling to maintain. Using your Java FX example, if the Java FX new project functionality is that tied to a 3rd party artifact(s) that NB is unwilling/unable to maintain, then the "New FX Project" functionality should be ripped out, and let the FX project perhaps be aware of it. Then the FX project, should they so desire, can create a NB plugin that can be installed by users that then enable "New FX Project" functions, plus whatever else they want to add. It's a disservice to everyone to go half way. Again, here's something the IDE is providing that the NB team and contributors can not fix. To quote Dr. Venkman: "That's bad." Now it would be a nice gift to wrap up the current FX tech in to a nice project bundle that could be handed off to a/the 3rd party, to lower the barrier to entry to get this going. But, it's just not right to leave stuff dangling, ramshackled and broken with no real path to fix them. I think having these broken things makes the project look bad. NB used to be very polished. It was known for it's "one stop shopping". Download it, and shazam, you got all of this stuff and functionality. No crawling the internet, following blogs, downloading jars from who knows where. But instead a nice, integrated "look at all the stuff that can be done". That agenda and mission has clearly changed, however formal or informally it's been stated. I don't have any experience really with the other IDEs. I don't know if OpenFX is doing addons for Eclipse or IDEA or, well, anything. I don't know if it's necessary. But having these options in the IDE that flat out don't work, doesn't do anyone any good. They give the wrong impression that the IDE supports something. They don't work when used, and issues to fix them fall on deaf ears, which also looks bad. The ecosystem is bitrotting around us. There should also be a conversation about what functionality the team is willing to maintain, and which it feels should be up to 3rd parties and should be yanked out, and perhaps how that transition could be accomplished. Regards, Will Hartung
Netbeans "owning" Maven archetypes
I touched on this talking about the EJB new project support and how it's currently broken. Fundamental to this is that the IDE relies on the Maven archetype templating system to generate project artifacts. It also wraps that process up in some wizard code, and it may well do some other things, I haven't gone into it that deeply. However, the archetype ownership is, to me, a core issue. It seems untoward for the IDE to have "core" functionality that depends on external artifacts. Simply put, if someone wanted to change the archetype for a project, in this case, an Apache/NB committer can not do that. The actual owner of the archetype has to do that. It's kind that they share that with the NB community, but IMHO, NB should "own" that archetype, publish, and maintain it, rather than relying on an external source. But I do not know what or if there is a process for accepting these kinds of artifacts and getting them published to the maven repositories. Many apache projects certainly publish to Maven Central, I don't know if NB does or not (is the Lookup library published, for example?). I'm hardly an expert on archetype authoring or publishing. Just curious what others feel about this and what perhaps a path forward would be. Regards, Will Hartung
Re: Maven Archetypes
On Thu, Jan 28, 2021 at 7:49 PM Josh Juneau wrote: > Sorry, but there must be something incorrect with the Java EE 8 project > archetype that you are using. When I use Apache NetBeans to create a Java > EE 8 project, I select the following: > > - New: "Java with Maven" -> "Web Application" > > This creates a single WAR project with a working JAX-RS web service. I am > not sure which archetype you are referring to that creates 4 related > projects, so we need to figure that out. > Then we've been talking past each other. Since way back in the day, we've had "Servlet" containers, i.e. Tomcat, and "Java EE Containers", i.e. Glassfish, Welogic, WebSphere, JBoss. The Servlet containers came first, of course. The JEE specification is a composite of several different specifications, including the Servlet, EJB, JTA, JCA, and other specs. Tomcat is not a "JEE Container". TomEE is a modern JEE Container that happens to bundle Tomcat. The web tier of Glassfish was originally a fork of Tomcat long ago. So, when I talk about a "JEE Application", I'm not talking about a simple WAR, suitable for Tomcat. I'm talking about something suitable for a JEE Container. Historically, there's been a demarcation between the web tier of a JEE app and the application, i.e. the EJB, tier. And they were packaged separately in individual artifacts that were then combined in to an overarching Enterprise Application aRchive, the EAR. Today, this demarcation is not absolutely necessary, since Session Beans can be part of a WAR today (on a JEE Container, not in Tomcat). But Message Driven Beans (among other things) can not be part of a WAR. The "Java with Maven" -> "Enterprise Application" is that project type that I'm referring too, along with "Java with Maven" -> "Enterprise Module" (which is NOT a WAR). The NB Enterprise Application wizard prompts for the JEE version, for the name of the mother project and child overarching EAR project, and then whether you want an EJB, WAR, or both modules for that EAR. Internally, it's 4 Archetypes orchestrated together by the internal NB code. Bases on the options, you will end up with 2, 3, or 4 related projects. The JEE 7 part uses the 4 archetypes. The JEE 8 version, does not. The code in the wizard for JEE 8 is completely ignorant of the JEE module relationships. However, the JEE 7 part is also broken, it seems to have some issue properly invoking Maven. Historically, I've always been clear when I talk about JEE to mean the "Enterprise Application", I never conflate "web apps" or "tomcat" with JEE (not that you'd know that, of course). Many historically have not made the distinction. So, from an "Enterprise Application" POV, NB 12.2 is unusable in terms of actually creating a skeleton application, or module, via the wizard. Given a proper existing project, it seems to work fine. But it can not create one on its own. If you have a NB 11 instance hanging around, creating an Enterprise Application for JEE 7 works fine in NB 11. I hope this clarifies the issues that I'm encountering and have been discussing. Best regards, Will Hartung
Re: macOS launcher changes, NETBEANS-5004, comments, testing, etc.
On Thu, Jan 28, 2021 at 8:50 AM Neil C Smith wrote: > It's not invoking Java directly though, just the next script in the > chain at > https://github.com/apache/netbeans/blob/master/platform/o.n.bootstrap/launcher/unix/nbexec > So, was there any specific tech reason to not use the bin/netbeans script? or did you just happen to find yourself at nbexec when you were done? Do you think there might be a problem later with switching over to bin/netbeans? Regards, Will Hartung
Re: macOS launcher changes, NETBEANS-5004, comments, testing, etc.
On Thu, Jan 28, 2021 at 5:57 AM Neil C Smith wrote: > While I understand we likely need a native executable to fix this > issue, I remain of the view that it probably should be a stub calling > bin/netbeans, not duplicating its function and directly calling > platform/lib/nbexec I have deep reservations about that approach. > Philosophically, this makes sense to me. Simply, the "official" way to launch Netbeans is bin/netbeans, anything else is an implementation detail. And any wrapper used to facilitate the launching of Netbeans should rely on the script, rather than the internal workings of the script. This allows any changes to the start up behavior to be propagated globally through the bin/netbeans script, vs scattered in to other artifacts. This better leverages the community with a common code base rather than having specialty knowledge about the mac, and swift and whatever. THAT SAID, we should also be cognizant that there are "others" calling bin/netbeans, rather than just typing it in to the CLI or using some other windowing shortcut. So, it's important to keep that perspective as well. Being ignorant of the details of the overall issue, it seems that if the Swift wrapper can safely invoke the java command line code and pass on the appropriate rights, it should as well be able to invoke the bin/netbeans script with the same assurances. So, ideally, a "quick switch" away from invoking java directly to calling the bin/netbeans should work. On that note, though, if this wrapper works, and works now, and we're that close to 12.3, I would think it's worth having this capability in 12.3 now, and fix it for bin/netbeans after the release, rather than removing the capability from 12.3, or holding it up. IMHO, of course. Regards, Will Hartung
Re: Collaborative Editing with Netbeans
On Wed, Jan 27, 2021 at 2:08 PM Eric Bresie wrote: > I was wondering if it was possible to embedded a “jabber server” as part > of it, then the host (of the session) would fill the roll of the server. > Not saying this wouldn't be useful, but, especially in today's world of remote development, not ideal. The simple problem is it's difficult for most people to open up ports and get them routed to the world wide internet. Machines sharing a common network don't necessarily have this problem. Perhaps machine sharing the same corporate VPN network may not have this problem, but as with all networking, "it depends". So, hosting a server within the tool would probably work for local cases and maybe proof of concept, but in the big picture it's problematic. And hosting a public Jabber server may or may not be a good idea, since it's "just Jabber", nefarious elements may piggy back on it to move traffic you may not like. It should be straightforward for a company to set up a Jabber server and credential it properly for their employees. OpenFire is an Apache Licensed Java XMPP server. I think my company has used it in the past, so it at least functioned at a fundamental level. We didn't do much with it as I recall. Should be straightforward for whoever publishes the team add-ons to have instructions for using something like this, even publish docker scripts with instructions on standing one up on a cheap cloud service. But managing this at the Apache level, as some kind of public service, seems too much to ask. Regards, Will Hartung
Re: Maven Archetypes
On Tue, Jan 26, 2021 at 8:23 PM Josh Juneau wrote: > Thanks for the great feedback on the Java EE 8 archetype that is being > used with Apache NetBeans. When I created the archetype, it was not meant > to become a standard. Rather, it was meant as a starting point for Java EE > 8 projects and to get Java EE 8 project support into Apache NetBeans. I > was hoping that it would be built upon by the community over time, and even > that a better and more standardized Maven archetype be put into place. > The biggest issue with the archetype is that it's not designed for the NB JEE wizard at all, which actually creates 4 related projects instead of one. And there seems to be some regression that has crept in to the JEE 7 project builder that's making it fail. So, the greenfield JEE experience in Netbean right now is pretty rough. However, there is keen insight here that I think there is room for different JEE project types as well. A simple example that you have is a microprofile skeleton. That certainly doesn't need multiple projects, and I think it is a popular path forward. And, naturally, I think there should be support for Java EE 8 and Jakarta EE 9. Though functionally identical, the simple renaming would be helpful moving forward. If we can get the JEE 8 one fixed, the JEE 9 one will come "for free". Although I wonder if they had to rename all of their schemas as well, that would be a deeper issue when the IDE generates things like a persistence.xml or an ejb-jar.xml. What I don't know is what are the tell tales to the IDE that tell it that we're working with a "JEE" project, where it wants to hook up a deployment server, etc. Is it simply the detecting a packaging style of war, vs ejb, vs ear instead of jar that informs the IDE what to do? Does it look for the plugin in the pom? Consider a microprofile project. That would likely just be a standalone jar, bundling the microprofile runtime with the application code to make a fat jar...I guess. It has different deployment options. > All that said, I think it would be great to have the Apache NetBeans > projects generated by Maven archetypes that are all hosted under a standard > namespace. We should also be updating the archetypes as time goes on, as > needed. These are community supported, just like Apache NetBeans, so they > should continue to evolve. > I just don't know that once an archetype is checked in to the source base, when and how are those published to something like Maven Central. In theory, Apache also has its own repository, and I guess it routinely and automatically forwards up to Maven central? I don't think we'd need to install the archetypes locally as part of the module deployment, but that's certainly an option. Regards, Will Hartung
Maven Archetypes
The JEE Maven archetypes are a bit of a disaster right now, there's relevant issues in JIRA already. But it brought up a question. Historically, and currently, the archetypes used for these projects (I don't know about others) are not part of Netbeans. They're external archetypes used by Netbeans. For example, originally, there were several from org.codehaus.mojo.archetypes. I don't know the original relationship between Sun/Oracle and codehaus. The current ones, for JEE 8, are from io.github.juneau001. Now, barring the detail that the JEE 8 ones are just flat out wrong given the structure of the JEE Maven Application Wizard (honestly, I don't know how these were committed -- this isn't even a subtle failure), I'm curious whether these should be "owned" by the Netbeans project, rather than a kind contributor. By own, I simply mean they're under the netbeans.apache.org name space, and the archetype templates are checked in to the NB source tree and, somehow, they're distributed to an appropriate Maven Repo to ideally get picked up by Maven Central. Does Netbeans already have a mechanism for publishing and managing archetypes? Any reason that NB can't or shouldn't do that? Regards, Will Hartung ]
Re: Collaborative Editing with Netbeans
On Sat, Jan 23, 2021 at 4:05 PM Eric Bresie wrote: > > DId it have a "host" functionality (using jabber) to initiate as a > makeshift server with invites and joining by clients? > > The big question is what, if any, central services Kanai provided to empower the team aspects. Even with something like Jabber, out of the box you can't connect peer to peer, it needs to be routed through something. It would not surprise me if the collaborative editing also streamed over Jabber to leverage a central server hosted at Kanai. Now, given that, if there WERE to be some central service necessary, is that something that Apache would be comfortable with hosting or is that out of scope. Since they can't host the code, (i.e. assuming you can get your hands on the source, Apache can't import it due to licensing), Apache would have essentially no involvement at all, so there would be no impetus for Apache to host any central infrastructure for such a facility. But, even if there were an aspect delivered by Apache Netbeans, I don't know if hosting something like the Jabber (or whatever) infrastructure is something that they would want to do. Regards, Will Hartung
Re: nb-javac
On Tue, Sep 1, 2020 at 2:52 AM Neil C Smith wrote: > * Drop full Java editing support on JDK 8 now (it still works as a > text editor). Recommend running on JDK 14+, but support 11. Probably > lose Compile on Save? > > So the suggestion is not to drop support for EDITING and MAINTAINING a Java 8 project, rather to drop support for the IDE to run on the JDK 8. If it's simply the runtime requirement for the IDE itself, it's much less of an issue. If it's dropping "full" support for JDK 8 PROJECTS, then, I think that would be an issue.
Re: nb-javac
On Fri, Aug 28, 2020 at 10:41 AM Neil C Smith wrote: > On Fri, 28 Aug 2020 at 18:23, Ernie Rael wrote: > > functionality was > > on par. > > Not with Java 11 it isn't. Not sure about the current state, exactly. > Personally I was in favour of dropping in 12.1 when this last came up, > but that would lead to no Java editing support on Java 8, and problems > on 11. I would think dropping support for Java 8 would be a real show stopper. It's LTS and not due to lose support for another 3 years.
Re: Speed of Maven build
On Tue, Aug 25, 2020 at 4:37 AM Jeff Jensen < jeffjen...@upstairstechnology.com> wrote: > In case this helps, Jason Dillon has a "Maven Shell" that does what you > seek for CLI - launches a Maven instance and runs interactive commands with > it, saving the startup time. > https://github.com/jdillon/mvnsh > > Is this really where the runtime for Maven goes? I always felt it was loading the POMs, walking the dependencies, plus all the network hits (which can be mitigated with the -o flag).
Re: Maven - ignore dependency is project?
On Wed, Aug 19, 2020 at 8:10 AM Neil C Smith wrote: > Hi, > > Anyone know if we have a feature somewhere to ignore that a Maven > dependency is a project and force use of the repository JARs? Either > that or feature to not ignore automatic module names would be great - > error badges are frustrating me. Not sure if I'm missing something > obvious. > I imagine if he dependency is not actually a part of your project, then maven will do the right thing. But then I question doesn't it do the right thing anyway if the version is correctly specified as the dependency? If your project is XYZ-SNAPSHOT, and you depend on JAR-1.2.3, it should ignore what's in the project and use the absolute versioned one from the repo. Because in the end, maven just copies everything to the repo anyway, I didn't think it did any actual short circuiting. Rather it simply copied to the repo then immediately pulls it back out. But I'm not positive.
Re: Status of Ant vs Maven
On Thu, Aug 13, 2020 at 1:36 AM Neil C Smith wrote: > We've already made a decision in terms of wizard layout to make all 3 > options more clearly visible, and I hope we don't revisit that. We > did talk about prioritising Maven as the preferred tool for new users, > which makes some sense in terms of how the IDE can support. But on > tutorials, maybe parallel tracks or alternative sections on one page > for at least Maven and Gradle makes sense? eg. if you look at the > getting started in NetBeans in the OpenJFX documentation (as JavaFX > was mentioned), it talks you through all 3 options. > Well, my question has been answered. It seems that were I to go through and update the NB Platform tutorials, modernizing them for NB 12 and Maven should be on the list of TODOs for them. I likely would not do a parallel path for any of the other build environments, especially not right out the gate. I don't know if the NB Platform wizards have any aspirations to support Gradle projects or not (I don't know if the build system is abstract enough internally to where something like a wizard cares about it or not, honestly).
Re: Status of Ant vs Maven
On Wed, Aug 12, 2020 at 4:56 PM Scott Palmer wrote: > I agree. Though it should be “hg clone foo”, Why make things harder than > they need to be :-) > Do-the-build should be one of: > “ant” > “make” > “mvn install” > “gradle” > I can't speak to gradle, but the distinct difference, most of the time, between "mvn install", and the rest, is that "mvn install" includes all of the dependencies. Type "mvn install" and the internet downloads automagically. Honestly, this is the primary reason I use maven on my projects. Being able to add a single dependency and have maven suck down all the rest. I tolerate it for that reason. I find it unwieldy, I find it slow, I find it expensive. But it works for my lazy gene, and I can send a pom.xml and a 10 line sample java file to a friend, and they can build it quickly even if it needs to pull down half the internet in dependencies. That said, we shant discuss the crushing expense of downloading the Maven index and unpacking it...
Re: Status of Ant vs Maven
On Wed, Aug 12, 2020 at 8:00 AM Jack W. wrote: > Jaroslav is probably correct, so by all means, do make NB's generator favor > Maven, if that's the community sentiment. > One of the things that prompted this for me was I was considering running through and updating the NB Platform tutorials, which can all use some work. And one of the considerations I was having was whether to simply clean it up, or whether they perhaps should be "redone" using the Maven projects as a baseline rather than the Ant projects. And, also, simply, to make sure that they even worked under Maven. I agrees with others, Ant is much faster day to day. But the pom.xml has become the universal project file for Java, since all of the IDEs support it, helping ensure that a single source base can work across multiple IDEs. And Maven has become more and more a first class citizen within the NB system, which is why I wanted to know what the community view was on the Ant project system and any visions for it in the future.
Status of Ant vs Maven
Ant has been the historic underlying build tool for Netbeans projects, but over the years, not only has NB been a very good companion with Maven, Maven is also much more popular industry wide. There was a comment on the user list recently about Java FX, and one reply was, paraphrasing, "the best way to use Java FX was to use Maven". I was also looking at the legacy NB Platform tutorials, which use Ant, but certainly need some updating. But that brought the question. Should one style of build be promoted over the other, are both systems "faithfully and fully supported", or is Ant going to perhaps slowly die on the vine of disinterest? Is there any internal mandate of ensuring compatibility between the two build system, especially in terms of ensuring high level things like wizards and whatnot work for both systems? If someone adds a new feature, contrived, "Create a Microprofile web service", is the project obligated (as much as it's obligated to do anything) to create a wizard for both Ant and Maven, or is it acceptable to only use one mechanism? Just curious if there's any formal position on the two systems and their status within the NB environment today.
