This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
With our growing list of modules (7 webapps/services + 34 libraries/web service clients) it would be a LIFESAVER if I could right click on a project (e.g., top level web application) and have it read the Maven dependency graph and build all open projects, starting with the leaf-most dependencies of the top level project that are matching SNAPSHOT dependency versions. Example: com.mycompany:application1:1.0-SNAPSHOT <---Initiate build - com.mycompany:library1:1.5-SNAPSHOT - com.mycompany:library2:1.2-SNAPSHOT - com.mycompany:library3:8.2-SNAPSHOT - com.mycompany:library4:1.2-SNAPSHOT - com.mycompany:library5:1.2-SNAPSHOT - com.mycompany:library6:5.2.1-SNAPSHOT SNAPSHOT build order above would be: library4 library3 + library6 //possibly in parallel library2 + library5 //possibly in parallel library1 application1 The issue being that after doing a SVN update/GIT pull+merge, there could be dozens of changes in various modules and having to manually find the leaf-most projects and build them in order detracts from development velocity and is error prone. Since most of our libraries are shared by multiple top-level projects, having multi-module projects hasn't been easily viable. THANKS!!
"build with dependencies" action does so using maven's own reactor build, but only within a well defined set of modules that can be traversed by parent<->module relationships. any reasonably well functioning solution should be coming from maven itself, not from IDE composing multiple builds together.
I guess I'm on the fence where it should be... Maven obviously can pull SNAPSHOT dependencies that have previously been built via the local or remote SNAPSHOT repository, even those built locally. The issue is how to trigger those builds in the IDE only for any open projects that are currently being worked on. If not using a multi-module project with a shared parent POM having an explicit parent-child relationship it gets fuzzy if any of those dependencies are under active development on the local system. For loosely coupled, independently released artifacts that are not bound by a common parent POM, Maven would have to be told where these projects are. If done via the command line: e.g., mvn clean install -buildSubModules \workspace\project1,\workspace\project6 then the IDE would still need to parse the dependencies anyway to pass a list of projects. If done via a configuration file, either the IDE must generate it based on opent projects (more dynamic but an extra thing to maintain), or the user must manually configure it. If manually configured, it would create an explicit coupling, introduce a manual process to specify the "build list", and the result is not dynamic. If configured using a static file that includes a list of all dependencies, then it also creates an explicit coupling and can easily get out of sync. It seems the IDE (where active development occurs) would be the ideal place for this since the IDE knows about any open projects and could DYNAMICALLY infer the build chain based on the list of open projects comparede to the main project's SNAPSHOT dependencies. This is similar to how Jenkins/Hudson inspects the POM files of projects it builds and can dynamically trigger downstream jobs or wait for upstream jobs based on dependencies implicitly. It can only do this for projects it is configured to build just as the IDE could do it for any open projects. In fact, the IDE could potentially trigger both upstream and downstream builds as needed based on the project that changed.