RE: [m2] child-level transitive dependency builds?
-Original Message- From: Edwin Punzalan [mailto:[EMAIL PROTECTED] Ah, so you are working with an IDE (of course!)... and its a feature that you want your IDE to do for you, i think. No, I use my IDE for editing. I use maven for building. Besides, maven already has good plugins for eclipse and IDEA. I don't need another IDE plugin. I'm not really familiar with the creation and customization of IDE plugins, but I'd suggest you put your request as a jira issue to the respective IDE plugin. No, I don't think this is an IDE issue. If you use vi with ctags, you will have the same problem. Child-modules are, in a sense, an arbitrary partitioning of project/application. Just because you are building at the child level does not mean that you should suddenly forget about the project as a whole. This issue is that child-project builds are sometimes necessary. And since they are sometimes necessary, they should just work. Not having transitive dependency resolution for child builds mean they don't just work. Maven's concept of everything being a project/module which gets installed to a (local) repository is brilliant. I think what it is lacking is the notion that some of those dependent modules are project siblings and others are from third-parties. The project sibling artifacts should be treated more aggressively than third-party artifacts and should be transitively resolved at build time, even when you are doing a child-level build. - Attention: Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] child-level transitive dependency builds?
On 1/11/06, Christopher Cobb [EMAIL PROTECTED] wrote: -Original Message- From: Edwin Punzalan [mailto:[EMAIL PROTECTED] Although, I have to say, when you did some changes on P4, you should be building it anyway, right? Because you'll need to run the tests, etc. and make sure that everything's still fine. But my IDE thinks this is all one big project. I may not have realized that I was making a change to P4. My smart IDE just took me to that source and I just fixed it. And even if I realized that my change was in a sibling project, well, that's what computers are for! :) The computer should do as much for me as it can. And when you build P4, you can just type mvn install and that would update your local repository. So that when you do try to build P1, mvn will get the latest jar in your local repo. Yes, that's what I do now. It just seems like an extra step that the computer should be able to do for me. It seems like all of the information is there to allow this to happen, we just have to make use of it. Well, uh, I suppose I could write the plugin. Hmmm... 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), transitively building would be a waste of time. For my usage, I can't think of a case I'd ever want this behavior. That's not to say that there's not enough people who do want it to justify the option being added... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] child-level transitive dependency builds?
-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. 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. - Attention: Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] child-level transitive dependency builds?
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]
Re: [m2] child-level transitive dependency builds?
If you're changing directories to a child project just to run a plugin from the command line (therefore one that's not been tied to the build lifecycle), then why would you want to rebuild the dependencies? As long as you did a main build from the top before (mvn install), the other child projects it depends on have been built to the local repository, and you'll use that version. Again, why would you need to rebuild the sibling dependency projects just to run a command-line plugin? -Stephen On 1/10/06, Christopher Cobb [EMAIL PROTECTED] wrote: Is it expected/preferred that (all?) builds are normally be done from the top level? It doesn't seem that this works very well for situations where I have a specific plugin which should only be used for certain children. Even if I configure the plugin at the top level, it may not make sense/not work to invoke it on all the children. So I have been changing into the appropriate child directories to invoke some plugins, which leads to also doing iterative builds in those child directories. If it is expected that we will occasionally/frequently change into child project to invoke parts of the build (like I do now), then it seems like child-level builds should do transitive build dependency resolution. So if I am doing a build in P1, and P1 has some dependencies on P4, and something in P4 has changed, then P4 should also get built/installed when I am building P1. It seems like this could be done by adding something like a relativePathToProject tag within each dependency for which you would like build-time transitive dependency resolution. Or, I suppose it could also be figured out by navigating to the parent pom and examining the children. Then you could figure out which dependencies are actually project siblings and should be transitively built. It looks like sometimes/frequently you need to do child-level builds, and you may want/need dependent project siblings to be build when you do so. Is there a way to handle this now? Is this an enhancement request? - Attention: Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. -- Stephen Duncan Jr www.stephenduncanjr.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] child-level transitive dependency builds?
-Original Message- From: Edwin Punzalan [mailto:[EMAIL PROTECTED] Although, I have to say, when you did some changes on P4, you should be building it anyway, right? Because you'll need to run the tests, etc. and make sure that everything's still fine. But my IDE thinks this is all one big project. I may not have realized that I was making a change to P4. My smart IDE just took me to that source and I just fixed it. And even if I realized that my change was in a sibling project, well, that's what computers are for! :) The computer should do as much for me as it can. And when you build P4, you can just type mvn install and that would update your local repository. So that when you do try to build P1, mvn will get the latest jar in your local repo. Yes, that's what I do now. It just seems like an extra step that the computer should be able to do for me. It seems like all of the information is there to allow this to happen, we just have to make use of it. Well, uh, I suppose I could write the plugin. Hmmm... Christopher Cobb wrote: Is it expected/preferred that (all?) builds are normally be done from the top level? It doesn't seem that this works very well for situations where I have a specific plugin which should only be used for certain children. Even if I configure the plugin at the top level, it may not make sense/not work to invoke it on all the children. So I have been changing into the appropriate child directories to invoke some plugins, which leads to also doing iterative builds in those child directories. If it is expected that we will occasionally/frequently change into child project to invoke parts of the build (like I do now), then it seems like child-level builds should do transitive build dependency resolution. So if I am doing a build in P1, and P1 has some dependencies on P4, and something in P4 has changed, then P4 should also get built/installed when I am building P1. It seems like this could be done by adding something like a relativePathToProject tag within each dependency for which you would like build-time transitive dependency resolution. Or, I suppose it could also be figured out by navigating to the parent pom and examining the children. Then you could figure out which dependencies are actually project siblings and should be transitively built. It looks like sometimes/frequently you need to do child-level builds, and you may want/need dependent project siblings to be build when you do so. Is there a way to handle this now? Is this an enhancement request? - Attention: Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] child-level transitive dependency builds?
Ah, so you are working with an IDE (of course!)... and its a feature that you want your IDE to do for you, i think. I'm not really familiar with the creation and customization of IDE plugins, but I'd suggest you put your request as a jira issue to the respective IDE plugin. ^_^ Christopher Cobb wrote: -Original Message- From: Edwin Punzalan [mailto:[EMAIL PROTECTED] Although, I have to say, when you did some changes on P4, you should be building it anyway, right? Because you'll need to run the tests, etc. and make sure that everything's still fine. But my IDE thinks this is all one big project. I may not have realized that I was making a change to P4. My smart IDE just took me to that source and I just fixed it. And even if I realized that my change was in a sibling project, well, that's what computers are for! :) The computer should do as much for me as it can. And when you build P4, you can just type mvn install and that would update your local repository. So that when you do try to build P1, mvn will get the latest jar in your local repo. Yes, that's what I do now. It just seems like an extra step that the computer should be able to do for me. It seems like all of the information is there to allow this to happen, we just have to make use of it. Well, uh, I suppose I could write the plugin. Hmmm... Christopher Cobb wrote: Is it expected/preferred that (all?) builds are normally be done from the top level? It doesn't seem that this works very well for situations where I have a specific plugin which should only be used for certain children. Even if I configure the plugin at the top level, it may not make sense/not work to invoke it on all the children. So I have been changing into the appropriate child directories to invoke some plugins, which leads to also doing iterative builds in those child directories. If it is expected that we will occasionally/frequently change into child project to invoke parts of the build (like I do now), then it seems like child-level builds should do transitive build dependency resolution. So if I am doing a build in P1, and P1 has some dependencies on P4, and something in P4 has changed, then P4 should also get built/installed when I am building P1. It seems like this could be done by adding something like a relativePathToProject tag within each dependency for which you would like build-time transitive dependency resolution. Or, I suppose it could also be figured out by navigating to the parent pom and examining the children. Then you could figure out which dependencies are actually project siblings and should be transitively built. It looks like sometimes/frequently you need to do child-level builds, and you may want/need dependent project siblings to be build when you do so. Is there a way to handle this now? Is this an enhancement request? - Attention: Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] child-level transitive dependency builds?
This is definitely an enhancement request. Although, I have to say, when you did some changes on P4, you should be building it anyway, right? Because you'll need to run the tests, etc. and make sure that everything's still fine. And when you build P4, you can just type mvn install and that would update your local repository. So that when you do try to build P1, mvn will get the latest jar in your local repo. Just my two cents. ^_^ Christopher Cobb wrote: Is it expected/preferred that (all?) builds are normally be done from the top level? It doesn't seem that this works very well for situations where I have a specific plugin which should only be used for certain children. Even if I configure the plugin at the top level, it may not make sense/not work to invoke it on all the children. So I have been changing into the appropriate child directories to invoke some plugins, which leads to also doing iterative builds in those child directories. If it is expected that we will occasionally/frequently change into child project to invoke parts of the build (like I do now), then it seems like child-level builds should do transitive build dependency resolution. So if I am doing a build in P1, and P1 has some dependencies on P4, and something in P4 has changed, then P4 should also get built/installed when I am building P1. It seems like this could be done by adding something like a relativePathToProject tag within each dependency for which you would like build-time transitive dependency resolution. Or, I suppose it could also be figured out by navigating to the parent pom and examining the children. Then you could figure out which dependencies are actually project siblings and should be transitively built. It looks like sometimes/frequently you need to do child-level builds, and you may want/need dependent project siblings to be build when you do so. Is there a way to handle this now? Is this an enhancement request? - Attention: Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
