Re: [VOTE] Release Apache NetBeans parent pom 1.0

2019-01-30 Thread Antonio

+1

Agreed. The POM looks perfect.

I recall reading somewhere that the ASF requires all maven artifacts to 
be published under the "org.apache" groupID, is this so or not?


Since the netbeans.org domain is now under control of the ASF I imagine 
it's ok to publish Maven artifacts with the "org.netbeans" groupID, 
right? I'd like to verify this before continuing.


Thanks,
Antonio

El 30/1/19 a las 17:38, Emilian Bold escribió:

+1

The pom looks good to me, a list of mailing lists, JIRA, etc.

--emi

On Wed, Jan 30, 2019 at 5:25 PM Eric Barboni  wrote:


Dear members of the Apache Netbeans community.



In order to prepare release of Apache NetBeans maven Artefacts (RELEASE100
and RELEASE090)  as well as Apache Netbeans mavenutilities (incubating)
such as nbm-maven-plugin:



I want to call a vote on releasing Apache NetBeans (incubating) maven parent
version 1.



This is a maven pom containing the basic information needed like mailing
list, licence.





The release is staged at the following place:

https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubator-netbeans
-mavenutils/netbeans-parent/



Staged maven repository exists at the following url:

https://repository.apache.org/content/repositories/orgapachenetbeans-1007/





Vote open for at least 72 hours.



[ ] +1

[ ] +0

[ ] -1



Best Regards

Eric



PS: this will not impact Apache NetBeans 11.0 release.










-
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: [VOTE] Release Apache NetBeans parent pom 1.0

2019-01-30 Thread Jose Ch
+1
I agree about updating the year.

El mié., 30 ene. 2019 a las 11:05, Eduardo Quintanilla (<
equintani...@bnext.mx>) escribió:

> Should the year be updated in the NOTICE file?
>
> Copyright 2017-2019 The Apache Software Foundation
>
> Eduardo Quintanilla
> Software Developer
> Block Networks
>
> -Original Message-
> From: Eric Barboni 
> Sent: miércoles, 30 de enero de 2019 9:25 a. m.
> To: dev@netbeans.incubator.apache.org
> Subject: [VOTE] Release Apache NetBeans parent pom 1.0
>
> Dear members of the Apache Netbeans community.
>
>
>
> In order to prepare release of Apache NetBeans maven Artefacts (RELEASE100
> and RELEASE090)  as well as Apache Netbeans mavenutilities (incubating)
> such as nbm-maven-plugin:
>
>
>
> I want to call a vote on releasing Apache NetBeans (incubating) maven
> parent version 1.
>
>
>
> This is a maven pom containing the basic information needed like mailing
> list, licence.
>
>
>
>
>
> The release is staged at the following place:
>
>
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubator-netbeans
> -mavenutils/netbeans-parent/
> 
>
>
>
> Staged maven repository exists at the following url:
>
> https://repository.apache.org/content/repositories/orgapachenetbeans-1007/
>
>
>
>
>
> Vote open for at least 72 hours.
>
>
>
> [ ] +1
>
> [ ] +0
>
> [ ] -1
>
>
>
> Best Regards
>
> Eric
>
>
>
> PS: this will not impact Apache NetBeans 11.0 release.
>
>
>
>
>
>
>
>
>
> -
> 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: Calling all Gradle users!

2019-01-30 Thread Martin Weißhaupt

Hi Alex,

you are right, the workaround worked for me too so I marked my ticket as 
a duplicate of yours.


That is what I get for not reading the comments on the tickets :D

BTW:
Does anyone know if there is a way to overwrite or select the run and 
debug tasks yet? With my projects they are not enabled but maby this is 
expected at the current stage of development.


Regards,
Martin


Am 30.01.19 um 22:48 schrieb Alessandro:

Hi Martin,
   I noticed that the exception stacktrace you reported is very similar to
the one I faced, the root cause might be the same.

Anyway it seems Laszlo is aware of the problems and willing to solve them.

Regards,
Alex

Il giorno mer 30 gen 2019 alle 22:40 Martin Weißhaupt
 ha scritto:


Hi,

I have had some time to investigate further and I noticed that I just
need to create a project with the inofficial gradle Plugin and Netbeans
8.2 to reproduce the issue.

Therefore I created a repository with a project to reproduce it:
https://github.com/mweisshaupt1988/Netbeans11GradleTest

As well as a Jira Issue since I believe that Alex propably has a
different issue:
https://issues.apache.org/jira/browse/NETBEANS-2030

If not please flag my bug as a duplicate.

Let me know if there is anything else I can do to help. The stuff that
works does look very good for me :)

Regards,
Martin





-
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: Calling all Gradle users!

2019-01-30 Thread Alessandro
Hi Martin,
  I noticed that the exception stacktrace you reported is very similar to
the one I faced, the root cause might be the same.

Anyway it seems Laszlo is aware of the problems and willing to solve them.

Regards,
Alex

Il giorno mer 30 gen 2019 alle 22:40 Martin Weißhaupt
 ha scritto:

> Hi,
>
> I have had some time to investigate further and I noticed that I just
> need to create a project with the inofficial gradle Plugin and Netbeans
> 8.2 to reproduce the issue.
>
> Therefore I created a repository with a project to reproduce it:
> https://github.com/mweisshaupt1988/Netbeans11GradleTest
>
> As well as a Jira Issue since I believe that Alex propably has a
> different issue:
> https://issues.apache.org/jira/browse/NETBEANS-2030
>
> If not please flag my bug as a duplicate.
>
> Let me know if there is anything else I can do to help. The stuff that
> works does look very good for me :)
>
> Regards,
> Martin
>


Re: Calling all Gradle users!

2019-01-30 Thread Martin Weißhaupt

Hi,

I have had some time to investigate further and I noticed that I just 
need to create a project with the inofficial gradle Plugin and Netbeans 
8.2 to reproduce the issue.


Therefore I created a repository with a project to reproduce it:
https://github.com/mweisshaupt1988/Netbeans11GradleTest

As well as a Jira Issue since I believe that Alex propably has a 
different issue:

https://issues.apache.org/jira/browse/NETBEANS-2030

If not please flag my bug as a duplicate.

Let me know if there is anything else I can do to help. The stuff that 
works does look very good for me :)


Regards,
Martin


Am 30.01.19 um 20:08 schrieb Alessandro:

Correction: I opened NETBEANS-2029 'Unloadable Spring Initializr gradle
project'

Il giorno mer 30 gen 2019 alle ore 20:00 Alessandro 
ha scritto:


Hi,
   I stumbled upon the same issue reported by Martin while trying to open a
project generated by the Spring Initializr service (http://start.spring.io
).

I have opened NETBEANS-2024 to track the issue with instructions to
reproduce and an exceptions raised.

The resulting project is unloadable and unbuildable thus a showstopper for
Spring Boot + Gradle users.

Regards,
Alex





-
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: JIRA component for new gradle support

2019-01-30 Thread Alessandro
Hi John,
  Thanks for your swift reaction and for retargeting my issue.

Cheers,
Alex

Il giorno mer 30 gen 2019 alle 20:14 John McDonnell <
mcdonnell.j...@gmail.com> ha scritto:

> Should be there now :)
>
> Regards
>
> John
>


Re: [VOTE] Release Apache Netbeans 10.0 (incubating) [vote candidate 5]

2019-01-30 Thread John McDonnell
Hi,

Check out the readme: https://github.com/apache/incubator-netbeans

I do not believe the entire NetBeans project builds with JDK 11 at the
moment.

Secondly you look to be on Windows, "./nbbuild/netbeans/bin/netbeans" will
run the netbeans unix script to start the application.  you'd want to run
netbeans.exe or netbeans64.exe from that folder to start the application
when the build has completed.

John

On Wed, 30 Jan 2019 at 16:54, mrunalconsult...@gmail.com <
mrunalconsult...@gmail.com> wrote:

>
>
> On 2018/12/18 04:29:35, Laszlo Kishalmi 
> wrote:
> > Dear all,
> >
> > Please vote on our 5th voting candidate for the 10.0 release of Apache
> NetBeans (incubating).
> >
> > If this voting candidate passes, another similar voting will be started
> ongene...@incubator.apache.org, and if that passes too, then we can
> release this version.
> >
> > Apache NetBeans 10.0 (incubating) constitutes all but the enterprise
> cluster in the Apache NetBeans Git repo, which together provide the
> NetBeans Platform (i.e., the underlying application framework), as well as
> all the modules that provide the Java SE, PHP, JavaScript and Groovy
> features of Apache NetBeans.
> >
> > In short, Apache NetBeans 10.0 (incubating) is a full IDE for Java SE,
> PHP and JavaScript development with some Groovy language support.
> >
> > Build artifacts available here:
> >
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-10.0-vc5/
> >
> > This voting is on the following artifact:
> >
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-10.0-vc5/incubating-netbeans-10.0-vc5-source.zip
> >
> > Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and
> NOTICE files, as well as a README file with build instructions, which are
> the same as these:
> >
> > https://github.com/apache/incubator-netbeans/blob/10.0-vc5/README.md
> >
> > SHA1: 028b47ca10118e616208e4949fb79c2e38d74fd5
> >
> > KEYS file:
> >
> > https://dist.apache.org/repos/dist/release/incubator/netbeans/KEYS
> >
> > Apache NetBeans Git Repo tag: 10.0-vc5 :
> > https://github.com/apache/incubator-netbeans/tree/10.0-vc5
> >
> > Note: NetBeans license violation checks are managed via the
> rat-exclusions.txt file:
> >
> >
> https://github.com/apache/incubator-netbeans/blob/10.0-vc5/nbbuild/rat-exclusions.txt
> >
> > Rat report shows no unknown licenses, except for license files:
> >
> >
> https://builds.apache.org/job/incubator-netbeans-release/380/artifact/rat-release-temp/nbbuild/build/rat-report.txt
> >
> > Included as a convenience binary, not relevant for the voting purposes
> (unzip it, run it and you'll see Apache NetBeans):
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-10.0-vc5/incubating-netbeans-10.0-vc5-bin.zip
> >
> > Release specific wiki page:
> >
> > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+10
> >
> > How (and what) to try out the release:
> >
> > 1. Download the artifact to be voted on and unzip it.
> > 2. Check that the artifact does not contain any jar files,
> > save the:
> platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/empty.jar
> > 3. Verify the cryptographic signatures, the NOTICE and LICENSE file
> > 4. Build it using the README provided by the artifact.
> > 5. Look in nbbuild/netbeans for the NetBeans installation created by the
> build process.
> >
> > C:\Netbeans10>ant
> Buildfile: C:\Netbeans10\build.xml
>
> -jdk-pre-preinit:
>
> -jdk-preinit:
>
> -jdk-warn:
>
> -jdk-presetdef-basic:
>
> -jdk-default:
>
> -jdk-init:
>
> -load-build-properties:
>
> bootstrap:
>  [echo] Bootstrapping NetBeans-specific Ant extensions...
>
> init-tasks:
>
> -check-vanilla-javac:
>
> prepare-vanilla-javac:
>[delete] Deleting directory C:\Netbeans10\nbbuild\build\langtools
> [mkdir] Created dir: C:\Netbeans10\nbbuild\build\langtools
> [unzip] Expanding: C:\Netbeans10\nbbuild\external\langtools-9.zip into
> C:\Netbeans10\nbbuild\build\langtools
> [pathconvert] Warning: Nashorn engine is planned to be removed from a
> future JDK release
> [pathconvert] Warning: Nashorn engine is planned to be removed from a
> future JDK release
> [pathconvert] Warning: Nashorn engine is planned to be removed from a
> future JDK release
> [pathconvert] Warning: Nashorn engine is planned to be removed from a
> future JDK release
> [pathconvert] Warning: Nashorn engine is planned to be removed from a
> future JDK release
> [pathconvert] Warning: Nashorn engine is planned to be removed from a
> future JDK release
> [pathconvert] Warning: Nashorn engine is planned to be removed from a
> future JDK release
> [pathconvert] Warning: Nashorn engine is planned to be removed from a
> future JDK release
> [pathconvert] Warning: Nashorn engine is planned to be removed from a
> future JDK release
> [pathconvert] Warning: Nashorn engine is planned to be removed from a
> future JDK 

Re: JIRA component for new gradle support

2019-01-30 Thread John McDonnell
Should be there now :)

Regards

John

On Wed, 30 Jan 2019 at 18:55, Alessandro  wrote:

> Hi,
>   a component should be created in JIRA for categorizing bugs related to
> the new gradle support.
>
> There is currently 'projects - Ant project' and 'projects - Maven' but no
> 'projects - Gradle' or similar. Some bugs have been filed with a 'gradle'
> label.
>
> Greetings,
> Alex
>


Re: Calling all Gradle users!

2019-01-30 Thread Alessandro
Hi,
  I stumbled upon the same issue reported by Martin while trying to open a
project generated by the Spring Initializr service (http://start.spring.io).

I have opened NETBEANS-2024 to track the issue with instructions to
reproduce and an exceptions raised.

The resulting project is unloadable and unbuildable thus a showstopper for
Spring Boot + Gradle users.

Regards,
Alex

Il giorno mer 30 gen 2019 alle ore 14:52 Martin Weißhaupt
 ha scritto:

> Hello,
>
> I use Gradle mostly for private projects and I have a few to try out.
> My biggest one is a toy project for a web framework which uses Hibernate
> Pojos to render a ui.
>
> This is the first one I have tried and it failed with the following
> exception:
> java.lang.NullPointerException: The file parameter cannot be null
> at org.openide.util.Parameters.notNull(Parameters.java:64)
> at org.openide.filesystems.FileUtil.toFileObject(FileUtil.java:853)
> at
>
> org.netbeans.modules.gradle.queries.GradleSourceForBinary.findSourceRoots2(GradleSourceForBinary.java:59)
> at
>
> org.netbeans.api.java.queries.SourceForBinaryQuery.findSourceRoots2(SourceForBinaryQuery.java:101)
> at
>
> org.netbeans.modules.parsing.impl.indexing.PathRegistry.createResources(PathRegistry.java:728)
> at
>
> org.netbeans.modules.parsing.impl.indexing.PathRegistry.getSources(PathRegistry.java:275)
> at
>
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.getDone(RepositoryUpdater.java:4888)
> at
>
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$InitialRootsWork.getDone(RepositoryUpdater.java:5821)
> [catch] at
>
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:3420)
> at
>
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:6183)
> at
>
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$4300(RepositoryUpdater.java:5834)
> at
>
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2$1.run(RepositoryUpdater.java:6099)
> at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279)
> at
>
> org.netbeans.modules.parsing.impl.RunWhenScanFinishedSupport.performScan(RunWhenScanFinishedSupport.java:83)
> at
>
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:6095)
> at
>
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:6091)
> at
>
> org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
> at
>
> org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
> at
>
> org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
> at
>
> org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
> at
>
> org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.run(RepositoryUpdater.java:6091)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
> at
>
> org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
> at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
> at
> org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
>
> Well failed is not really true.
> It opens, it builds, it runs the targets I have tried but it shows this
> exception in a dialog whenever I open the project or a file in the project.
>
> Since this seems to be related to repository updates here are my configured
> repositories for this project:
> repositories
> {
> flatDir { dirs "lib" }
> mavenCentral()
> maven { url "http://mavensync.zkoss.org/maven2; }
> maven { url "http://mavensync.zkoss.org/eval; }
> }
>
> The project uses a gradle wrapper with gradle version 4.10.2 currently.
>
> I can provide more information if needed.
> I'll try to try out other existing projects as soon as possible.
>
> Regards,
> Martin
>
> Am Sa., 26. Jan. 2019 um 14:07 Uhr schrieb Geertjan Wielenga
> :
>
> > Hi all,
> >
> > If you're using Gradle in any way at all -- and especially if you have
> some
> > Gradle projects of whatever kind lying around -- we need you!
> >
> > Thanks to Laszlo, we have integration with Gradle for the first time in
> the
> > upcoming release scheduled to be released in March. We need as many as
> > possible to try out the Gradle features, i.e., simply open your existing
> > projects into the latest NetBeans builds and see if there are any
> problems
> > so they can be fixed in time.
> >
> > Interested? Please respond to this e-mail indicating your intention to
> try
> > out your existing Gradle projects in the upcoming release of Apache
> > NetBeans and we'll 

Re: Calling all Gradle users!

2019-01-30 Thread Alessandro
Correction: I opened NETBEANS-2029 'Unloadable Spring Initializr gradle
project'

Il giorno mer 30 gen 2019 alle ore 20:00 Alessandro 
ha scritto:

> Hi,
>   I stumbled upon the same issue reported by Martin while trying to open a
> project generated by the Spring Initializr service (http://start.spring.io
> ).
>
> I have opened NETBEANS-2024 to track the issue with instructions to
> reproduce and an exceptions raised.
>
> The resulting project is unloadable and unbuildable thus a showstopper for
> Spring Boot + Gradle users.
>
> Regards,
> Alex
>


JIRA component for new gradle support

2019-01-30 Thread Alessandro
Hi,
  a component should be created in JIRA for categorizing bugs related to
the new gradle support.

There is currently 'projects - Ant project' and 'projects - Maven' but no
'projects - Gradle' or similar. Some bugs have been filed with a 'gradle'
label.

Greetings,
Alex


RE: [VOTE] Release Apache NetBeans parent pom 1.0

2019-01-30 Thread Eduardo Quintanilla
Should the year be updated in the NOTICE file?

Copyright 2017-2019 The Apache Software Foundation

Eduardo Quintanilla
Software Developer 
Block Networks 

-Original Message-
From: Eric Barboni  
Sent: miércoles, 30 de enero de 2019 9:25 a. m.
To: dev@netbeans.incubator.apache.org
Subject: [VOTE] Release Apache NetBeans parent pom 1.0

Dear members of the Apache Netbeans community.

 

In order to prepare release of Apache NetBeans maven Artefacts (RELEASE100 and 
RELEASE090)  as well as Apache Netbeans mavenutilities (incubating) such as 
nbm-maven-plugin:

 

I want to call a vote on releasing Apache NetBeans (incubating) maven parent 
version 1.

 

This is a maven pom containing the basic information needed like mailing list, 
licence.

 

 

The release is staged at the following place:

https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubator-netbeans
-mavenutils/netbeans-parent/

 

Staged maven repository exists at the following url:

https://repository.apache.org/content/repositories/orgapachenetbeans-1007/

 

 

Vote open for at least 72 hours.

 

[ ] +1

[ ] +0

[ ] -1

 

Best Regards

Eric 

 

PS: this will not impact Apache NetBeans 11.0 release.

 
 

 

 


-
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] Release Apache Netbeans 10.0 (incubating) [vote candidate 5]

2019-01-30 Thread mrunalconsultant



On 2018/12/18 04:29:35, Laszlo Kishalmi  wrote: 
> Dear all,
> 
> Please vote on our 5th voting candidate for the 10.0 release of Apache 
> NetBeans (incubating).
> 
> If this voting candidate passes, another similar voting will be started 
> ongene...@incubator.apache.org, and if that passes too, then we can release 
> this version.
> 
> Apache NetBeans 10.0 (incubating) constitutes all but the enterprise cluster 
> in the Apache NetBeans Git repo, which together provide the NetBeans Platform 
> (i.e., the underlying application framework), as well as all the modules that 
> provide the Java SE, PHP, JavaScript and Groovy features of Apache NetBeans.
> 
> In short, Apache NetBeans 10.0 (incubating) is a full IDE for Java SE, PHP 
> and JavaScript development with some Groovy language support.
> 
> Build artifacts available here:
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-10.0-vc5/
> 
> This voting is on the following artifact:
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-10.0-vc5/incubating-netbeans-10.0-vc5-source.zip
> 
> Included in the above are the DEPENDENCIES, DISCLAIMER, LICENSE, and NOTICE 
> files, as well as a README file with build instructions, which are the same 
> as these:
> 
> https://github.com/apache/incubator-netbeans/blob/10.0-vc5/README.md
> 
> SHA1: 028b47ca10118e616208e4949fb79c2e38d74fd5
> 
> KEYS file:
> 
> https://dist.apache.org/repos/dist/release/incubator/netbeans/KEYS
> 
> Apache NetBeans Git Repo tag: 10.0-vc5 :
> https://github.com/apache/incubator-netbeans/tree/10.0-vc5
> 
> Note: NetBeans license violation checks are managed via the 
> rat-exclusions.txt file:
> 
> https://github.com/apache/incubator-netbeans/blob/10.0-vc5/nbbuild/rat-exclusions.txt
> 
> Rat report shows no unknown licenses, except for license files:
> 
> https://builds.apache.org/job/incubator-netbeans-release/380/artifact/rat-release-temp/nbbuild/build/rat-report.txt
> 
> Included as a convenience binary, not relevant for the voting purposes (unzip 
> it, run it and you'll see Apache NetBeans):
> 
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubating-netbeans/incubating-10.0-vc5/incubating-netbeans-10.0-vc5-bin.zip
> 
> Release specific wiki page:
> 
> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+10
> 
> How (and what) to try out the release:
> 
> 1. Download the artifact to be voted on and unzip it.
> 2. Check that the artifact does not contain any jar files,
> save the: 
> platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/empty.jar
> 3. Verify the cryptographic signatures, the NOTICE and LICENSE file
> 4. Build it using the README provided by the artifact.
> 5. Look in nbbuild/netbeans for the NetBeans installation created by the 
> build process.
> 
> C:\Netbeans10>ant
Buildfile: C:\Netbeans10\build.xml

-jdk-pre-preinit:

-jdk-preinit:

-jdk-warn:

-jdk-presetdef-basic:

-jdk-default:

-jdk-init:

-load-build-properties:

bootstrap:
 [echo] Bootstrapping NetBeans-specific Ant extensions...

init-tasks:

-check-vanilla-javac:

prepare-vanilla-javac:
   [delete] Deleting directory C:\Netbeans10\nbbuild\build\langtools
[mkdir] Created dir: C:\Netbeans10\nbbuild\build\langtools
[unzip] Expanding: C:\Netbeans10\nbbuild\external\langtools-9.zip into 
C:\Netbeans10\nbbuild\build\langtools
[pathconvert] Warning: Nashorn engine is planned to be removed from a future 
JDK release
[pathconvert] Warning: Nashorn engine is planned to be removed from a future 
JDK release
[pathconvert] Warning: Nashorn engine is planned to be removed from a future 
JDK release
[pathconvert] Warning: Nashorn engine is planned to be removed from a future 
JDK release
[pathconvert] Warning: Nashorn engine is planned to be removed from a future 
JDK release
[pathconvert] Warning: Nashorn engine is planned to be removed from a future 
JDK release
[pathconvert] Warning: Nashorn engine is planned to be removed from a future 
JDK release
[pathconvert] Warning: Nashorn engine is planned to be removed from a future 
JDK release
[pathconvert] Warning: Nashorn engine is planned to be removed from a future 
JDK release
[pathconvert] Warning: Nashorn engine is planned to be removed from a future 
JDK release

-def-check:

-check-langtools.jdk.home:

-prepare-build:
[mkdir] Created dir: C:\Netbeans10\nbbuild\build\langtools\build\modules
[mkdir] Created dir: C:\Netbeans10\nbbuild\build\langtools\build\toolclasses
[mkdir] Created dir: C:\Netbeans10\nbbuild\build\langtools\build\gensrc
[mkdir] Created dir: C:\Netbeans10\nbbuild\build\langtools\build\bin
[mkdir] Created dir: C:\Netbeans10\nbbuild\build\langtools\build\prevsrc

-def-pparse:
 [copy] Copying 1 file to 
C:\Netbeans10\nbbuild\build\langtools\build\toolclasses\propertiesparser
[javac] Compiling 2 source files to 
C:\Netbeans10\nbbuild\build\langtools\build\toolclasses


Re: [VOTE] Release Apache NetBeans parent pom 1.0

2019-01-30 Thread Emilian Bold
+1

The pom looks good to me, a list of mailing lists, JIRA, etc.

--emi

On Wed, Jan 30, 2019 at 5:25 PM Eric Barboni  wrote:
>
> Dear members of the Apache Netbeans community.
>
>
>
> In order to prepare release of Apache NetBeans maven Artefacts (RELEASE100
> and RELEASE090)  as well as Apache Netbeans mavenutilities (incubating)
> such as nbm-maven-plugin:
>
>
>
> I want to call a vote on releasing Apache NetBeans (incubating) maven parent
> version 1.
>
>
>
> This is a maven pom containing the basic information needed like mailing
> list, licence.
>
>
>
>
>
> The release is staged at the following place:
>
> https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubator-netbeans
> -mavenutils/netbeans-parent/
>
>
>
> Staged maven repository exists at the following url:
>
> https://repository.apache.org/content/repositories/orgapachenetbeans-1007/
>
>
>
>
>
> Vote open for at least 72 hours.
>
>
>
> [ ] +1
>
> [ ] +0
>
> [ ] -1
>
>
>
> Best Regards
>
> Eric
>
>
>
> PS: this will not impact Apache NetBeans 11.0 release.
>
>
>
>
>
>
>
>

-
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





[VOTE] Release Apache NetBeans parent pom 1.0

2019-01-30 Thread Eric Barboni
Dear members of the Apache Netbeans community.

 

In order to prepare release of Apache NetBeans maven Artefacts (RELEASE100
and RELEASE090)  as well as Apache Netbeans mavenutilities (incubating)
such as nbm-maven-plugin:

 

I want to call a vote on releasing Apache NetBeans (incubating) maven parent
version 1.

 

This is a maven pom containing the basic information needed like mailing
list, licence.

 

 

The release is staged at the following place:

https://dist.apache.org/repos/dist/dev/incubator/netbeans/incubator-netbeans
-mavenutils/netbeans-parent/

 

Staged maven repository exists at the following url:

https://repository.apache.org/content/repositories/orgapachenetbeans-1007/

 

 

Vote open for at least 72 hours.

 

[ ] +1

[ ] +0

[ ] -1

 

Best Regards

Eric 

 

PS: this will not impact Apache NetBeans 11.0 release.

 
 

 

 



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

2019-01-30 Thread Geertjan Wielenga
Feel free to add thoughts on this topic in the related PR:

https://github.com/apache/incubator-netbeans/pull/1038

Gj


On Wed, Jan 30, 2019 at 4:01 PM Ondro Mihályi 
wrote:

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

2019-01-30 Thread 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?

2019-01-30 Thread Alessandro
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: Calling all Gradle users!

2019-01-30 Thread Martin Weißhaupt
Hello,

I use Gradle mostly for private projects and I have a few to try out.
My biggest one is a toy project for a web framework which uses Hibernate
Pojos to render a ui.

This is the first one I have tried and it failed with the following
exception:
java.lang.NullPointerException: The file parameter cannot be null
at org.openide.util.Parameters.notNull(Parameters.java:64)
at org.openide.filesystems.FileUtil.toFileObject(FileUtil.java:853)
at
org.netbeans.modules.gradle.queries.GradleSourceForBinary.findSourceRoots2(GradleSourceForBinary.java:59)
at
org.netbeans.api.java.queries.SourceForBinaryQuery.findSourceRoots2(SourceForBinaryQuery.java:101)
at
org.netbeans.modules.parsing.impl.indexing.PathRegistry.createResources(PathRegistry.java:728)
at
org.netbeans.modules.parsing.impl.indexing.PathRegistry.getSources(PathRegistry.java:275)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.getDone(RepositoryUpdater.java:4888)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$InitialRootsWork.getDone(RepositoryUpdater.java:5821)
[catch] at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:3420)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:6183)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.access$4300(RepositoryUpdater.java:5834)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2$1.run(RepositoryUpdater.java:6099)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279)
at
org.netbeans.modules.parsing.impl.RunWhenScanFinishedSupport.performScan(RunWhenScanFinishedSupport.java:83)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:6095)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task$2.call(RepositoryUpdater.java:6091)
at
org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
at
org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
at
org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
at
org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
at
org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.run(RepositoryUpdater.java:6091)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)

Well failed is not really true.
It opens, it builds, it runs the targets I have tried but it shows this
exception in a dialog whenever I open the project or a file in the project.

Since this seems to be related to repository updates here are my configured
repositories for this project:
repositories
{
flatDir { dirs "lib" }
mavenCentral()
maven { url "http://mavensync.zkoss.org/maven2; }
maven { url "http://mavensync.zkoss.org/eval; }
}

The project uses a gradle wrapper with gradle version 4.10.2 currently.

I can provide more information if needed.
I'll try to try out other existing projects as soon as possible.

Regards,
Martin

Am Sa., 26. Jan. 2019 um 14:07 Uhr schrieb Geertjan Wielenga
:

> Hi all,
>
> If you're using Gradle in any way at all -- and especially if you have some
> Gradle projects of whatever kind lying around -- we need you!
>
> Thanks to Laszlo, we have integration with Gradle for the first time in the
> upcoming release scheduled to be released in March. We need as many as
> possible to try out the Gradle features, i.e., simply open your existing
> projects into the latest NetBeans builds and see if there are any problems
> so they can be fixed in time.
>
> Interested? Please respond to this e-mail indicating your intention to try
> out your existing Gradle projects in the upcoming release of Apache
> NetBeans and we'll work on this together from there initially via this mail
> thread.
>
> For example, without any problems at all, I was able to open and work with
> this random project I found on GitHub:
>


Re: Git Toolbar into NetBeans

2019-01-30 Thread Geertjan Wielenga
Great idea, this would be excellent.

Gj

On Wed, Jan 30, 2019 at 8:35 AM Benno Markiewicz
 wrote:

> Hi.
>
> The plugin code is already licensed as Apache 2.0. So feel free to
> integrate it as a plugin for the official plugin center, fork it or
> integrate the layer entries into the layer.xml of the git plugin.
>
> And yes, it is only a layer.xml. This type of a layering filesystem
> registry is very mighty - thanks to the original authors
>
> Best regards
> Benno
>
> On Wed, Jan 30, 2019, 7:40 AM Tomas Poledny 
> > Hi, Why this git actions (create branch ...) are not simple available in
> > customize toolbar?
> >
> > On Wed, Jan 30, 2019, 07:34 Laszlo Kishalmi  > wrote:
> >
> >> Dear Benno, Team,
> >>
> >> I'm wandering if we can add the Git Toolbar Plugin to the 11.0 release.
> >> https://github.com/markiewb/nb-git-toolbar
> >>
> >> I find this plugin quite useful, as even the most common Git actions are
> >> 2-3 level deep in submenu-s, so for me most of the times it is easier to
> >> deal with the command line tools, rather than using the IDE Git
> >> integration. This plugin changes that.
> >>
> >> The original author announced that the project is dead and seeking for
> >> maintenance takeover. Well, actually the essence of this plugin is a
> >> simple layer.xml which we can easily put into our existing Git module
> >> without any hustle.
> >>
> >> Can we simply do that, mentioning Benno somewhere?
> >>
> >>
> >> Laszlo Kishalmi
> >>
> >>
> >> -
> >> 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?

2019-01-30 Thread David Heffelfinger
I agree that things get a bit confusing with the renaming of Java EE to
Jakarta EE. If this wasn't the case I wouldn't like any renaming at all. As
far as I can tell the current separation of "Java Web" and "Java EE" hasn't
caused any confusion among NetBeans users.

I'm not sure I like the words "Legacy" or "Vintage", as some may interpret
these as having negative connotations. There are still many projects out
there that use EAR files and EJBs. EJBs in particular suffer from the bad
rep EJB 2 had, where EJB 3 is a whole different beast, very easy and simple
to use. Moving EJBs to a "Legacy" or "Vintage" category may reinforce the
bad reputation from EJB 2. Additionally, I still see a fair amount of
projects using EAR Files (mostly maintenance of existing code).

I like Ondro's idea of using "Java Enterprise", which would cover both Java
EE and Jakarta EE.

On Wed, Jan 30, 2019 at 4:08 AM Ondro Mihályi 
wrote:

> 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 <
> juneau...@gmail.com>
> > 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:
> > 

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

2019-01-30 Thread 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,
> > >