- bunch of projects representing various maven artifacts (two wars, a couple of jars)
- projects depending upon each other in a non-obvious way, so along with the amount of components rebuilding everything
is not trivial
- Opening a project in the IDE and browsing to "Libraries" makes the IDE display artifacts represented by "local"
projects with an "m2 project" icon, other artifacts as a "normal" jar icon, so obviously the IDE has a clue which are
"local" projects and which aren't.
- After dealing with standard NetBeans (ant) projects: Dependencies, if changed, will be rebuilt before building the
- The IDE tries to build the project chosen to be built and, then, will complain about required jar artifacts missing.
- By then the user will go out trying to manually build all the dependent projects in the "right" order to satisfy
- This is likely to be done each time rebuilding such a "chain" of transitively depending projects if having done
changes on that way.
This has been discussed on the nbusers alias before, and reasons have been outlined why creating such an "automated"
build mechanism is possibly a difficult and/or bad idea. However I am filing an enhancement request against this hoping
to get some discussion on it goin', both because this feature would drastically ease dealing with larger maven project
collections and because IMHO this is required to make maven2 behaviour comply with ant-project behaviour.
proposed solution idea for that (no matter whether possible or how difficult to be done):
- allow for automatically creating a "pom" artifact including a "modules" section
- allow for adding local projects (<module>../whatever</module>) to that
- provide some way to support user eventually getting modules sort in the "right" order in terms of how they depend upon
So far, I see that while opening a maven2 project the IDE "sees" other maven2 projects that could be opened as
"required" projects, so the idea of having "required" project opened yet not automatically built along with the main
project seems somewhat counter-intuitive... ;)
not for 6.5 I guess. The problems to solve include:
1. how to keep track of "changed" projects.
2. how to actually rebuild the changed projects in the right order.
please note that Compile on Save feature (not for maven projects in 6.5) might help with some scenarios. But at the same
time whenever a maven build is involved local repository needs to have the right dependencies in store.
Okay, reasonable. From that point of view, so far I consider using a custom pom artifact having the projects added to it
in the "right" order as modules seems to be the easiest way to go. Is there a way to enhance IDE tooling to provide more
support for that (i.e. "add module and dependent project to pom modules section" via context menu or drag-and-drop)?
This would help a lot definitely. :)
not sure I understand you proposition correctly, but the <modules> section can only be added to projects with "pom"
Yes, I am aware of that. :) But given this rebuild-of-transitive-dependencies has been bugging me for quite a while now,
I eventually chose to create an empty "build-helper" artifact, packaging pom, to manually add my modules in the right
order and use this to quickly rebuild everything in times of need (see http://wiki.netbeans.org/TaTMavenBuildAllProjects
). Though somewhat of a "hack", I wonder whether something like this might be a feasible solution to be quickly
implemented and easily usable... ?
Adding to that, another idea: Couldn't the "Enterprise Application" tooling be abused for that in order to, say, be
allowed to create an umbrella "maven2 application" to which other "maven2 artifacts", be that war or jar or whatever,
easily could be added? This would feel / look / be homogenous compared to EAR tooling and possibly be the cleanest way
of handling things looking at it from a maven2 point of view...
it seems to have been solved at least partially on the maven side itself.
AFAIK the functionality shall become part of the maven core in the future as cmdline switches.
WikiName got changed sometime back;
I consider this fixed by introduction of "build with dependencies" action that relies on maven-reactor-plugin to perform
the build of projects the current one depends on. The scope of what gets built along is defined the the reactor root