[ https://issues.apache.org/jira/browse/NETBEANS-6163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474694#comment-17474694 ]
Thomas Schapitz edited comment on NETBEANS-6163 at 1/12/22, 6:41 PM: --------------------------------------------------------------------- [~sworisbreathing] How this should be configured is actually shown on the projects property page: !image-2022-01-12-16-50-02-502.png! So, yes, this is a standard. What is more, this isn't just a Netbeans invention, but relates to the Maven best practices, how the directory structure within a Maven project should be organized. Note, that the openapi-generator is in fact a multi purpose library, able to parse swagger swagger/open-api schemata, and then generating arbitrary output using plugable generators. This library is then wrapped into several hosting environments, among others a CLI application and the Maven plugin, the later is mainly passing through the various configuration options, that haven't been devised with Maven in mind. One of the generation options is to generate a complete Maven or Gradle project containing the code to implement a client for that API. This could be build, installed, and deployed, to be consumed by an other project as dependency, which is a sensible solution in many use cases, as it avoids duplicating the source and classes. It might also provide sort of a starting point, if you use it to generate server side stubs, e. g. in place of a Maven archetype. But it certainly not intended, to spam a whole project infrastructure into target/generated-sources, if you just want to pick the model classes and the API interfaces, which you might want to use in a customized Spring Boot build. This is indeed an abomination, causing unnecessary waste of time, diskspace and energy. It is equivalent to uprooting and carting off a tree, because you want to eat the apples. You asked: 'What's wrong with having NetBeans pick up the generated sources from maven instead of making an assumption about how plugins are going to behave?' Nothing, You cited the idea back to me, that I mentioned earlier on, didn't I? I'm just a bit reluctant, to drop something as "Major Bug" into the lap of Netbeans, if the work around for this "bug" consists in properly adhering to Mavens standards. Netbeans already has a really big codebase. It might pay to curb the growth a bit. BTW.: if you look into the discussion of the linked PR here: [https://github.com/apache/netbean/pull/3285#discussion_r741711876] the impression is, that Netbeans is already doing this. If I was to vote for this issue, I would downgrade it to it to "Minor Improvement", since it is not exactly stopping the world from turning. was (Author: taps): [~sworisbreathing] How this should be configured is actually shown on the projects property page: !image-2022-01-12-16-50-02-502.png! So, yes, this is a standard. What is more, this isn't just a Netbeans inventions, but relates to the Maven best practices, how the directory structure within a Maven project should be organized. The problem here is due to the fact, that the openapi-generator is in fact a multi purpose library, able to parse swagger swagger/open-api schemata, and then generating arbitrary output using plugable generators. This library is then wrapped into several hosting environments, among others a CLI application and the Maven plugin. One of the generation options is to generate a complete Maven or Gradle project containing the code to implement a client for that API. This could be build, installed, and deployed, to be consumed by an other project as dependency, which is a sensible solution in many use cases, as it avoids duplicating the source and classes. It might also provide sort of a starting point, if you use it to generate server side stubs, e. g. in place of a Maven archetype. But it doesn't make sense, to spam a whole project infrastructure into generated-sources, if you just want to pick the model classes and the API interfaces, which you might want to use in a customized Spring Boot build. This is indeed an abomination, causing unnecessary waste of time, diskspace and energy. It is equivalent to uprooting and carting off a tree, because you want to eat the apples. You asked: 'What's wrong with having NetBeans pick up the generated sources from maven instead of making an assumption about how plugins are going to behave?' Nothing, You cited the idea back to me, that I mentioned earlier on, didn't I? I'm just a bit reluctant, to drop something as "Major Bug" into the lap of Netbeans, if the work around for this "bug" consists in properly adhering to Mavens standards. Netbeans already has a really big codebase. It might pay to curb the growth a bit. BTW.: if you look into the discussion of the linked PR here: [https://github.com/apache/netbean/pull/3285#discussion_r741711876] the impression is, that Netbeans is already doing this. If I was to vote for this issue, I would downgrade it to it to "Minor Improvement", since it is not exactly stopping the world from turning. > Maven does not set generated source roots correctly > --------------------------------------------------- > > Key: NETBEANS-6163 > URL: https://issues.apache.org/jira/browse/NETBEANS-6163 > Project: NetBeans > Issue Type: Bug > Components: projects - Maven > Reporter: Martin Entlicher > Assignee: Martin Entlicher > Priority: Major > Labels: pull-request-available > Fix For: Next > > Attachments: image-2022-01-12-16-50-02-502.png > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Clone and build [https://github.com/dsyer/native-image-debug] > Open the project in NetBeans and see that under {{Generated Sources}} there > are packages like: {{src.main.java.org.springframework.aot}}, etc. > The initial {{src/main/java}} should not be included in the source root. -- This message was sent by Atlassian Jira (v8.20.1#820001) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists