Re: What NetBeans is on front page

[Ondro Mihályi]

Hi, just my 2 cents: Netbeans is first and foremost an IDE, which means you
can do all the development inside it, including coding, running, debugging,
testing, and even running a terminal. The current page doesn't explain
that, it only stresses that it's more than an editor. Nothing about running
and debugging apps which is the essential difference between IDEs and
editors.

Ondro

ut 19. 2. 2019 o 22:20 Antonio  napísal(a):

> Hi,
>
> Form:
>
> netbeans.apache.org needs some design love, I think.
> http://www.groovy-lang.org/ may be a good source of inspiration. I heard
> there were some design ideas floating around for the website, but we've
> been hearing that since 2017-2018. I can give the design a go during the
> next week (but I'm not very good at that).
>
> Content:
>
> I think Ate meant to explain a little bit more what NetBeans is to all
> users: what you can do with the platform, what you can do with the IDE,
> how is being donated to Apache, etc.
>
> Maybe we can use Confluence to discuss about the content. Let's create a
> web page with the texts that should go into the front page, and then
> subpages in Confluence that expand on that. Screenshots will be
> appreciated. We can users for screenshots, for instance.
>
> What say?
>
> Cheers,
> Antonio
>
>
> El 19/02/2019 a las 20:28, Geertjan Wielenga escribió:
> > Hi all,
> >
> > I noticed this by our mentor Ate:
> >
> > Somehow I don't see this mentioned/used anywhere on the
> > currentnetbeans.apache.org website though.
> >> Nor any other description of what NetBeans is, which seems odd...
> >>
> >>
> > Here:
> >
> >
> https://lists.apache.org/list.html?d...@netbeans.apache.org:lte=1M:After%20again%20checking%20the%20other%20parts
> >
> > So, I tweaked the front page a bit:
> >
> > https://netbeans.apache.org/
> >
> > I added 'Fits the pieces together' as well as the three things that
> > NetBeans is.
> >
> > Thoughts? Comments?
> >
> > Gjk
> >
>
> -
> 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: Re: What to do with features for EARs and EJBs?

[Ondro Mihályi]

Hi Alessandro,

I see, I mentioned SpringBoot as just a hypothetical example. in fact I
think that Netbeans should adopt maven and maybe also gradle as first-class
citizens and stop putting maven and gradle projects into a separate
category. For example, I'd like to go to New Project -> Java Web -> Web
Application -> select build tool (one of Ant, Maven, Gradle) and create a
project. It's very weird that most of the industry uses Maven and Gradle,
but the default in Netbeans is Ant. Newcomers choose Ant projects in
Netbeans most of the time, not knowing that most of the world out there
already uses Maven or Gradle.

If we had Maven and Gradle projects under the same categories as Ant
projects, then a SpringBoot project could be under Java Web category.
That's all what I meant in my previous email.

All the best,
Ondro

st 30. 1. 2019 o 15:28 Alessandro  napísal(a):

> Hi Ondro,
>
> Il giorno mer 30 gen 2019 alle ore 10:08 Ondro Mihályi <
> ondrej.miha...@gmail.com> ha scritto:
>
> >  ...
>
> Although the project creation dialog refers to Java EE in one select box,
>
> it allows choosing Tomcat and only adds dependencies present in Tomcat. In
> > addition, if there was a plugin for generating Ant-based Spring Boot
> apps,
> > it could also be in this category, as it would be a Java Web project,
> > although a separate SpringBoot type packaged as JAR.
> > ...
> > - Ondro
> >
>
> While creating an Ant project using Spring Boot is entirely possible it is
> not recommended as Spring Boot heavily relies on a build tool with
> dependency management capabilities (see
>
> https://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-build-systems.html
> ).
>
> The NB Spring Boot plugin I created intentionally adds items to the Maven
> category for this reason. Now that Gradle support is in master it could be
> worth having a look at supporting Spring Boot Gradle projects too.
>
> Greets,
> Alessandro
>

Re: Re: What to do with features for EARs and EJBs?

[Ondro Mihályi]

Hi,

I agree with Eric. EJB and EAR is still part of Java EE, will be part of
Jakarta EE and there are no plans to deprecate it. I heard some ideas to
create a new "modern" profile in Jakarta EE but it's only ideas and we're
far away from that happening. Therefore all this should be supported by
Netbeans at least via a plugin if we already have that functionality. I
know that a lot of companies still maintain their older applications that
use EJB and EAR and they're not going to remove it even when using Docker
or other modern technology.

I propose (reasoning below):

   - leave "Jave Web" category as is
   - rename "Java EE" category to "Java Enterprise" category (which to many
   would sound like "legacy" anyway)

Reasoning:

I thought that the "Java Web" category is for web apps in general, for WAR
projects, which can be also deployed to servlet containers like Tomcat.
Although the project creation dialog refers to Java EE in one select box,
it allows choosing Tomcat and only adds dependencies present in Tomcat. In
addition, if there was a plugin for generating Ant-based Spring Boot apps,
it could also be in this category, as it would be a Java Web project,
although a separate SpringBoot type packaged as JAR.

On the other hand, the "Java EE" category is for legacy enterprise
constructs in Java EE, like EARs, EJBs and EJB clients. Here the name "Java
EE" for the category is wrong, because Java EE is no longer used only in
enterprise and with EARs. I would rename this category to "Enterprise
Java".This could be extracted into a separate plugin and only installed if
needed. Later if these constructs are deprecated in Jakarta EE we could
just make the plugin deprecated too.

A bonus is we wouldn't need to rename anything to Jakarta EE later.

- Ondro





st 30. 1. 2019 o 5:19 Eric Bresie  napísal(a):

> I’m a little bit of an outsider looking in but give the older technologies
> are still Java EE why confuse things with Vintage and Legacy and just leave
> them there with the new Jakarta EE category when available.
>
> Then just make sure to have a Version attribute to configure the setup of
> the project?
>
> I thought recent Java EE has different profiles ( Web Profiles, Full
> Profiles,etc.). Would linking with these profiles work better? Or is the
> Java Web not necessarily related to Java EE Web Profiles? Is the Java Web
> more of a micro service?
>
> Would having an Enterprise category work better maybe and allowing
> different flavors under that?
>
> Eric Bresie
> ebre...@gmail.com
> > On January 28, 2019 at 11:50:02 PM CST, Josh Juneau 
> wrote:
> > I certainly agree that we need to keep this functionality within the
> IDE. Regarding naming and/or breaking it out into an extension: I would be
> in favor of keeping this functionality under a "Vintage Java EE" category.
> That is what it is, correct? I think we will need a "Jakarta EE" category
> in the near future, and this new category will not contain older
> functionality. I would prefer going straight to "Jakarta EE" as a category,
> rather than use "Modern Java EE". Jakarta EE 8 is due out soon and it will
> be in alignment with Java EE 8.
> >
> > Older (deprecated) functionality should go into the "Vintage Java EE"
> category. As Ken had mentioned, these technologies have not been
> deprecated, but these older EAR wizards would certainly be vintage in my
> opinion. If the day comes where most of the necessary EJB functionality is
> moved into other APIs, then maybe it can be broken off as an add-on
> extension...but not until then.
> >
> > Hope this makes sense. Thanks for all of the work that has gone into
> moving the IDE forward.
> >
> > Josh Juneau
> > juneau...@gmail.com
> > http://jj-blogger.blogspot.com
> > https://www.apress.com/index.php/author/author/view/id/1866
> >
> > > On Jan 28, 2019, at 3:41 PM, Brett Ryan  wrote:
> > >
> > > Geertjan’s article is not about removing EE support it’s what to do
> about the old Java EE which is deprecated in favour of Jakarta EE in the
> future being the modern EE variant.
> > >
> > > For those that do not know, yes; Java EE 8 is the last version of Java
> EE, Jakarta EE while not being a replacement it is the new way forward for
> enterprise web applications. Removing legacy support in favour of new
> technologies is certainly not suicide it is moving with the times.
> > >
> > > Spring support has always been brilliant in NetBeans with bean
> navigation suppirt and now a lot of bootstrap support, but that’s the
> modern current focus.
> > >
> > > > On 29 Jan 2019, at 08:33, Tomas Poledny  wrote:
> > > >
> > > > NetBeans had the best support of JEE from all IDE. Support for
> Spring is
> > > > very poor. I think remove of support part of JEE is suicide for
> NetBeans.
> > > > This is main reason why I am using NetBeans.
> > > > Tomas
> > > >
> > > > > On Mon, Jan 28, 2019, 22:24 Brett Ryan  wrote:
> > > > >
> > > > > It’s always a sensitive topic whenever considering to remove
> something,
> > > 

Re: took about three minutes of use to break netbeans-10-0

[Ondro Mihályi]

Hi,

Another happy user here that switched from Netbeans 8.2 to Netbeans 10
without issues. I had some issues with NB 9 and some preview builds, but
all works very well with NB 10 so far. I don't use it daily though, so time
will show. Thanks to all for your hard work!

st 16. 1. 2019 o 21:39 Michael R. Ryan  napísal(a):

> I know how disheartening it is when users tell you your program isn’t
> working. So, just for the sake of morale, I want to say that I have made
> the transition from NetBeans 8.2 to 10 for Java EE development and it’s
> been working great!
>
> I found the Java EE plugins to be especially easy to add. I was up and
> running very quickly.
>
> Thanks for all the hard work you all have been putting in.
>
> That said, good to know about the IDE log file, as I’ve had a couple of
> hiccups that seem to get fixed with a NetBeans restart.
>
> Full disclosure: I’m on macOS 10.14.2 running Java 1.8.0_181. I’m running
> my Java EE app in Glassfish w/ MariaDB, and using git/GitLab for versioning.
>
> For Mac users: I’ve discovered the logs are in ~/Library/Application
> Support/NetBeans/10.0/var/log as well as the View -> IDE Log menu item
> (obviously, not useful if you can’t get NetBeans started)
>
> I had NetBeans crash this morning after having left it open all night with
> the Mac in sleep mode. But after restarting, I’ve had no problems.
>
> Also, I’ve had the project I’m working on get hung up after making changes
> to the code and then trying to run it again. But, it seems that if I do a
> "Clean and Build" and then Run, I don’t have this problem.
>
> Perhaps my crash this morning was caused by me moving a javascript file to
> a new location? See the chunk from the log below. I’ll let you know if I
> reproduce it.
>
> Best,
>
> Mike Ryan
>
>
> from ~/Library/Application Support/NetBeans/10.0/var/log/messages.log:
>
> INFO [org.netbeans.core.windows.persistence]:
> [PersistenceManager.getTopComponentForID] Problem when deserializing
> TopComponent for tcID:'MultiView-javascript9BE7A9A5text#002Ehistory#007C'.
> Reason:  Object not found:
> /Users/mrr39/NetBeansProjects/nb10/busoffappsuite/web/secure/timesheet/timeEntryNavigation.js@e23efbff:6ae40e9e[invalid].
> It was probably deleted.
>
> msg
> msg
> msg
> msg
> Caused: org.openide.filesystems.FileStateInvalidException:
> /Users/mrr39/NetBeansProjects/nb10/busoffappsuite/web/secure/timesheet/timeEntryNavigation.js@e23efbff
> :6ae40e9e[invalid]
> at org.openide.loaders.DataObject.find(DataObject.java:587)
> Caused: org.openide.loaders.DataObjectNotFoundException:
> /Users/mrr39/NetBeansProjects/nb10/busoffappsuite/web/secure/timesheet/timeEntryNavigation.js@e23efbff
> :6ae40e9e[invalid]
> at org.openide.loaders.DataObject.find(DataObject.java:610)
> at
> org.openide.loaders.DataObject$Replace.readObject(DataObject.java:1246)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1170)
> at
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2178)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069)
> at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2287)
> at
> java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:561)
> at
> org.openide.loaders.OpenSupport$Env.readObject(OpenSupport.java:144)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1170)
> at
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2178)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069)
> at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2287)
> at
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2211)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069)
> at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)
> at
> org.openide.windows.CloneableTopComponent.readExternal(CloneableTopComponent.java:229)
>   

Re: [DISCUSS] Apache NetBeans roadmap updates

[Ondro Mihályi]

I fully agree. There should be no barriers in implementing functionality as
plugins. Before every NB release,  the community could vote on plugins to
include in NB core to add their functionality into core.  That would still
allow updating core plugins to a newer version without waiting for another
NB release.

Dňa št 15. 11. 2018, 11:39 Christian Lenz 
napísal(a):

> Hey,
>
> My 2 cents here again. First I want to know, what you think, how the minor
> Releases should look like. If they also contains Features, I’m fine with
> that two.
>
> I will be more fine to have only 2 releases, if we can have more public
> apis for other languages except Java. This is, IMHO a big Problem that a
> lot of stuff, can’t be done with 3rd-party Plugins for HTML, PHP, JS, CSS,
> etc. because of missing public APIs. If we have more public APIs, we can
> have more Features inside of NetBeans with only 3rd-party Plugins.
>
> We can’t adding hints and Code fixes for JS, CSS/LESS/SCSS, PHP or HTML
> which could make the work easier. And this is only one Little example. We
> can’t adding embedding languages to the mentioned languages.
>
> NetBeans first was build only for Java, this is why the Tokens of Java are
> public, the hints and fixes you can add with 3rd-party Plugins. So this is
> why you can add a lot of stuff to the Java Editor with 3rd-party Plugins.
> If we are open-source, we should open minded too to let the Developers
> decide, whether I want to add my feature into the core and wait 6 month
> after it is relased to the next Version or to add it via a Plugin and can
> bring it up today or tomorrow.
>
>
> Cheers
>
> Chris
>
>
>
> Von: Peter Hull
> Gesendet: Donnerstag, 15. November 2018 09:06
> An: dev.ataur.rah...@gmail.com
> Cc: neilcsm...@apache.org; jiri.koval...@oracle.com; NetCAT team;
> NetBeans Mailing List; d...@netbeans.apache.org
> Betreff: Re: [DISCUSS] Apache NetBeans roadmap updates
>
> The 2 + 2 option makes sense to me. I'd be interested in hearing
> people's thoughts about how this lines up with JDK releases:
> * Is it better to do the NB testing after the general availability of
> the JDK, or aim to have them released about the same time?
> * What versions of JDK does Netbeans need to support, in terms of
> developing/building NB itself, running NB and developing Java
> applications using NB. (since there are alternatives to Oracle JDK I
> suppose we don't need to be influenced by Oracle's support scheme)
>
> -
> 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 IDE for DevOps was: IntelliJ IDEA vs Netbeans

[Ondro Mihályi]

Hi Jaroslav,

You have my full support for this. Getting rid of Maven indexer and
searching on the fly is exactly what I'd like to do too - in fact I always
set indexing to "never" and run manually from time to time because the
indexer freezes the IDE.

A partial workaround would be to add pauses during unpacking and indexing
artifacts to avoid freezing the IDE. But still, it doesn't make sense to
index whole maven repo and store a couple of GB on disk. I run Netbeans
under 2 different user accounts and I had to point Netbeasn to the same
directory to store the index to save a couple of GB by a redundant index.

Ondro

2018-04-23 8:14 GMT+02:00 Jaroslav Tulach :

> > I just spent the past 2 weeks using IntelliJ IDEA exclusively (having
> used
> > it sporatically before). I'm going to share some brief thoughts in the
> > hopes that it helps.
> >
> > As far as I can tell, IntelliJ's killer feature is their debugger (more
> > broadly, their UI). Our killer feature is our profiler, and Maven
> > integration (more broadly, bundling more functionality standard).
> >
> >  * Netbeans drives development of Maven projects through Maven. This
> >results in better integration than IntelliJ provides (e.g. good luck
> >trying to start a debugging session through Maven)
> >
>
> Yeah, I can confirm setting up debugging (for Maven) in IntelliJ is so
> complicated...
>
> Once I called NetBeans the [IDE for devops and admins](
> http://wiki.apidesign.org/wiki/DevOps) and this is what I meant. If you
> care about your overall project structure, there shall be benefits of using
> NetBeans+Maven. If you just care about the code, the IntelliJ's editor
> focus may give you better experience.
>
> Moreover the NetBeans approach is more fragile. Structures of pom.xml files
> differ wildly and when they get out of expectations, things may get broken
> or slow...
>
> >  indexing and performance levels can be done with the
> > code currently in Apache NetBeans Git. Jaroslav Tulach will have insights
> > as well as gratitude for help in this area
>
> My thought is simple: there should be no Maven index processing on the
> client (by default). There should be a webservice the IDE would query
> instead. However my idea was rejected by last Oracle NetBeans performance
> team last time I proposed it. It was found too complicated. Anybody wants
> to pick that challenge up now?
>
> -jt
>