On 1/12/06, Christopher Cobb <[EMAIL PROTECTED]> wrote: > > -----Original Message----- > > From: Stephen Duncan [mailto:[EMAIL PROTECTED] > > > > But if your IDE, or whatever working environment you use, you treat > > each child project as an individual project, not one big project, then > > when building P1, you only want to build P1. For those that work this > > way (and it's how the IDE plugins work by default), > > Well, the IDE plugins don't work this way by default. If you run a maven > ide plugin in the top-level directory, then they generate an IDE project > that encompasses the entire project, including all the child projects. > That's their default behavior. You don't need to do anything special to > make this happen. > > I prefer to have a single IDE project file which encompasses all of the > source in the project than to have ten projects open, each of which does not > know how to navigate to the source of (or see the javadocs of) the other > components of the project.
I'm not sure which IDE plugins work this way. I only use Eclipse, and it only makes useful projects for each subproject. Having them as separate projects is the only way to get a valid classpath for each, helping prevent incorrect dependency specifications. And then dependent sibling projects are set as dependencies in Eclipse properly, which allows source knowledge, etc. > > transitively building would be a waste of time. > > I'm all for not wasting time. > > I also don't like to waste time when I go through an edit, build, stop > container, start container, deploy to container, start application, navigate > to trouble spot, test changes ... only to discover that the changes I made > were not picked up by the build. > > > For my usage, I can't think of a > > case I'd ever want this behavior. > > I can't imagine why. Do you normally depend on transitive dependencies > being built for a top-level build? Or do you manually build every child > when (you think) it is needed (scary thought). The reason to have the > system take care of this to make sure your builds are reliable. > > For me, a *reliable* build comes ahead of a *fast* build (a "fast" build is > inherently useless if it is not reliable). Even so, I think you are > overstating the performance hit of a transitive build. > > First of all, there are project dependencies and then there are third-party > dependencies. A transitive build would only have traverse project > dependencies and not third-party dependencies. This should markedly reduce > the size of the transitive dependency tree. > > Second, although it's true that maven has to "ask each module" to build > itself to see if it is up-to-date, if maven and its plugins implement every > reliable performance optimization to ensure that no unnecessary building > activity is taking place, then the time to build each module would only be > the time needed to do a file-dependency scan. If an artifact (or > intermediate artifact) is already newer than the pieces which are used to > build it, then no "building" should be taking place: and this should not > take an excessive amount of time. > > Given well-optimized plugins, I imagine that the performance hit would be > minimal to process transitive dependencies only for project siblings. > > But for those who really want this (or really don't), this functionality > could be controlled by a command-line switch and make all parties happy. I suppose your right that the performance hit wouldn't end up being too bad ASSUMING all the plugins are optimized to prevent unnecessary building... and unnecessary test running... It just seem like it's going to lead to more complex behavior. First, to determine what transitively build, it has to identify what are sibling projects, then it needs to only build them if you depend on a SNAPSHOT version. It seems to me that if you're dealing with your code from the multi-project level (i.e. you don't know what sub-modules need building), you simply build from the top-level. The benefits of having SNAPSHOT, sibling dependencies built transitively when building from within a child project seem small compared to the likely complexity of implementing it. But since I wouldn't be implementing it, my opinion regarding that doesn't matter much. :) Hopefully for you, somebody capable of implementing it agrees you instead of me. Good luck. -Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
