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: RE: Netbeans "owning" Maven archetypes
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. In addition, for a give wrapper plug-in, the intent is for the Netbeans wrapper to add additional actions available for use in Netbeans contexts (IDE or Platform) to leverage features provided by the third party dependency. Regarding the dependencies... Am I seeing this right? https://mvnrepository.com/search?q=Mojohaus+ Assume the builds from that maybe getting published to a degree as it seems like newer artifacts are available here. https://mvnrepository.com/artifact/org.codehaus.mojo So do the plug dependencies need to be changed a little to point to some of these coordinates? Are any of the needed external artifact available here? http://netbeans.osuosl.org/ Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On April 23, 2021 at 4:34:34 AM CDT, Eric Barboni (mailto:sk...@apache.org)> wrote: > Hi folks, > > Are the archetype you are looking for over here : > https://github.com/mojohaus?page=3 > > webapp-javaee6 webapp-javaee7 ... and others. > > For me would make sense to migrate to our management. We control release, we > can use with trust and we can also look to new version. > We do this for nbm-maven-plugin we try to get last version on new project > creation instead of sticking with default hardcoded one, we can't do that for > random archetype outside our control for security reason (what if next > version is a unstable, is a virus or whatever) > > > Best Regards > Eric > > > > -Message d'origine- > De : Sean Carrick mailto:s...@pekinsoft.com)> > Envoyé : jeudi 22 avril 2021 21:11 > À : dev@netbeans.apache.org (mailto:dev@netbeans.apache.org) > Objet : Re: Netbeans "owning" Maven archetypes > > Will, > > When looking for old source from websites that are no longer around, I > usually have pretty good luck on The Wayback Machine (http://web.archive.org). > > -SC > > On 4/22/21 11:26 AM, Will Hartung wrote: > > On Thu, Apr 22, 2021 at 8:50 AM Geertjan Wielenga > > > (mailto:geertjan.wiele...@googlemail.com.invalid)> 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 > > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > (mailto:dev-unsubscr...@netbeans.apache.org) > For additional commands, e-mail: dev-h...@netbeans.apache.org > (mailto:dev-h...@netbeans.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.apache.org > (mailto:dev-unsubscr...@netbeans.apache.org) > For additional commands, e-mail: dev-h...@netbeans.apache.org > (mailto:dev-h...@netbeans.apache.org) > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > >
RE: Netbeans "owning" Maven archetypes
Hi folks, Are the archetype you are looking for over here : https://github.com/mojohaus?page=3 webapp-javaee6 webapp-javaee7 ... and others. For me would make sense to migrate to our management. We control release, we can use with trust and we can also look to new version. We do this for nbm-maven-plugin we try to get last version on new project creation instead of sticking with default hardcoded one, we can't do that for random archetype outside our control for security reason (what if next version is a unstable, is a virus or whatever) Best Regards Eric -Message d'origine- De : Sean Carrick Envoyé : jeudi 22 avril 2021 21:11 À : dev@netbeans.apache.org Objet : Re: Netbeans "owning" Maven archetypes Will, When looking for old source from websites that are no longer around, I usually have pretty good luck on The Wayback Machine (http://web.archive.org). -SC On 4/22/21 11:26 AM, Will Hartung wrote: > 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 > - 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 - 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: Netbeans "owning" Maven archetypes
Will, When looking for old source from websites that are no longer around, I usually have pretty good luck on The Wayback Machine (http://web.archive.org). -SC On 4/22/21 11:26 AM, Will Hartung wrote: > 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 > - 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: Netbeans "owning" Maven archetypes
In that case, makes sense to recreate the Maven archetypes and publish them to Maven Central. Gj On Thu, Apr 22, 2021 at 6:27 PM Will Hartung wrote: > 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 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
Probably the archetypes are open source and you'd provide pull requests to them. Gj On Thu, Apr 22, 2021 at 5:37 PM Will Hartung wrote: > 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 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
BTW - looking at the JavaFX archetype resources[1], there's javafx-maven-plugin configured ... ... which could nicely plug into https://issues.apache.org/jira/browse/NETBEANS-5394 that will be probably implemented. Additional action mappings would be then activated by e.g. plugin presence in POM. Seems to me quite similar to changing the archetype itself - but NB IDE would then inject its own actions on the fly, and the user can customize them. If looks interesting, share your requirements in NETBEANS-5394. [1] https://github.com/openjfx/javafx-maven-archetypes/blob/master/javafx-archetype-simple/src/main/resources/archetype-resources/pom.xml Dne 21. 04. 21 v 21:21 Ernie Rael napsal(a): IMHO, NB should "own" that archetype, publish, and maintain it Couldn't agree more. But here's one case study that shows some of the problems that might be faced. When I fixed javafx-maven to "run/debug out of the box", I created a very small independent (not a fork) github project for javafx maven archetypes, published it to maven central, to replace the ones (from gluon) used by NetBeans. I think the PR that used those archetypes was merged somewhat by accident, since there was immediate objection from some senior PMC members (it stayed in, probably because there were frequent posts about it not working; and there's the permission/forgiveness pov). I think the objections primarily came from a desire to depend more on using 3rd party stuff and also to encourage bundlers to customize and include NetBeans. But using 3rd party maven archetypes is not well supported in NetBeans. For example see the issue "Extend ArchetypeWizards.definedArchetype to include optional nbactions" https://issues.apache.org/jira/browse/NETBEANS-3104. Since I provided the maven archetype I was able to include an nbactions. BTW, being able to provide an nbactions.xml is not sufficient; some executions had to be added to the pom.xml. And then I opened a PR on the the 3rd party archetypes. The idea was that if the NetBeans issue 3104 was fixed so that nbactions could be specified *and* the 3rd party had the new executions added to the pom.xml, then NetBeans could stop using my archetype. There was some initial discussion and updates to the PR, then it sat there and was finally merged, as is, after a *year*. And in the meantime, a profile execution was added to the pom used by NetBeans, sigh. FYI: https://github.com/openjfx/javafx-maven-archetypes/pull/10 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. It's understandable that there's a push to get some support from outside the project, considering that NetBeans is such a huge project. It seems it will be years, if ever, that there's a sufficient support team built to really take care of it through apache. I'm glad there's still new stuff going in and it's disappointing that [at times] base 8.2 seems barely supported. -ernie On 4/21/2021 10:56 AM, Will Hartung wrote: 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbe
Re: Netbeans "owning" Maven archetypes
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. Gj On Thu, Apr 22, 2021 at 4:25 PM Will Hartung wrote: > 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 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 Thu, 22 Apr 2021 at 10:26, Johan Vos wrote: > If this can be made easier if the archetype has a nbactions.xml that is not > causing regression for other IDE's or CLI, I think we should consider it, Short term that would be great. The last time this came up, Jaroslav sent me an off-list reply with thoughts on an actions plugin defined in the pom. I thought it was on-list so was just looking it up to share the link here. Anyway, longer term it would be good if there was a tool neutral (ish) way to do this, with Maven CLI support too? Best wishes, Neil - 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: Netbeans "owning" Maven archetypes
Talking about the OpenJFX specifically case: I am personally open to make it as easy as possible to leverage the openjfx javafx-maven-artifact in NetBeans. Actually, it is the main procedure I use whenever I create a new JavaFX project: create a new project from an archetype, specify the org.openjfx... archetype, and then I manually add the javafx:run as a NetBeans action. If this can be made easier if the archetype has a nbactions.xml that is not causing regression for other IDE's or CLI, I think we should consider it, see https://github.com/openjfx/javafx-maven-archetypes/issues/7#issuecomment-824680476 - Johan On Thu, Apr 22, 2021 at 12:28 AM Will Hartung wrote: > 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 >
Re: Netbeans "owning" Maven archetypes
NetBeans is full of references and usages of third party technologies. 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? Gj On Thu, Apr 22, 2021 at 12:28 AM Will Hartung wrote: > 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 >
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
Re: Netbeans "owning" Maven archetypes
IMHO, NB should "own" that archetype, publish, and maintain it Couldn't agree more. But here's one case study that shows some of the problems that might be faced. When I fixed javafx-maven to "run/debug out of the box", I created a very small independent (not a fork) github project for javafx maven archetypes, published it to maven central, to replace the ones (from gluon) used by NetBeans. I think the PR that used those archetypes was merged somewhat by accident, since there was immediate objection from some senior PMC members (it stayed in, probably because there were frequent posts about it not working; and there's the permission/forgiveness pov). I think the objections primarily came from a desire to depend more on using 3rd party stuff and also to encourage bundlers to customize and include NetBeans. But using 3rd party maven archetypes is not well supported in NetBeans. For example see the issue "Extend ArchetypeWizards.definedArchetype to include optional nbactions" https://issues.apache.org/jira/browse/NETBEANS-3104. Since I provided the maven archetype I was able to include an nbactions. BTW, being able to provide an nbactions.xml is not sufficient; some executions had to be added to the pom.xml. And then I opened a PR on the the 3rd party archetypes. The idea was that if the NetBeans issue 3104 was fixed so that nbactions could be specified *and* the 3rd party had the new executions added to the pom.xml, then NetBeans could stop using my archetype. There was some initial discussion and updates to the PR, then it sat there and was finally merged, as is, after a *year*. And in the meantime, a profile execution was added to the pom used by NetBeans, sigh. FYI: https://github.com/openjfx/javafx-maven-archetypes/pull/10 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. It's understandable that there's a push to get some support from outside the project, considering that NetBeans is such a huge project. It seems it will be years, if ever, that there's a sufficient support team built to really take care of it through apache. I'm glad there's still new stuff going in and it's disappointing that [at times] base 8.2 seems barely supported. -ernie On 4/21/2021 10:56 AM, Will Hartung wrote: 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 - 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
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
