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.
Summary: | Allow building of Maven SNAPSHOT dependencies | ||
---|---|---|---|
Product: | projects | Reporter: | predatorvi <predatorvi> |
Component: | Maven | Assignee: | Tomas Stupka <tstupka> |
Status: | NEW --- | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 7.2 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
predatorvi
2012-09-19 15:05:43 UTC
"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. |