Re: Any reason ant should compile faster?
Memory parameters maybe ? On Wed, Jul 24, 2013 at 4:28 PM, Russell Gold r...@gold-family.us wrote: Hi, Maybe somebody else has run into this. I'm converting a really messy 200-ant-script build to maven, and some steps seems to run a lot slower, now. The case I'm wondering about now is one where we have over 10,000 source files in a directory, and compile them bit-by-bit. One step specifies about 300 files, and thanks to javac dependency logic, actually compiles about 4000 files in ant. I have converted this to maven by moving the 4000 files into the maven project src/main/java tree. Maven, of course, tells javac to compile all 4000 files. In ant, this step takes about 20 seconds. In maven, it takes about 90 seconds. Any ideas why? Thanks, Russ - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! -- Adrien Rivard
Re: Any reason ant should compile faster?
On Wed, Jul 24, 2013 at 4:28 PM, Russell Gold r...@gold-family.us wrote: Hi, Maybe somebody else has run into this. I'm converting a really messy 200-ant-script build to maven, and some steps seems to run a lot slower, now. The case I'm wondering about now is one where we have over 10,000 source files in a directory, and compile them bit-by-bit. One step specifies about 300 files, and thanks to javac dependency logic, actually compiles about 4000 files in ant. I have converted this to maven by moving the 4000 files into the maven project src/main/java tree. Maven, of course, tells javac to compile all 4000 files. In ant, this step takes about 20 seconds. In maven, it takes about 90 seconds. Any ideas why? Maybe just because the staleness check used by the maven-compiler-plugin (or is it plexus-compiler?) now scans the 4000 files whereas your Ant script only scanned 300 files. The way the compiler is invoked might play a role too, the default depends on the version of the maven-compiler-plugin (and plexus-compiler) you're using. -- Thomas Broyer /tɔ.ma.bʁwa.je/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Any reason ant should compile faster?
The case I'm wondering about now is one where we have over 10,000 source files in a directory, and compile them bit-by-bit. One step specifies about 300 files, and thanks to javac dependency logic, actually compiles about 4000 files in ant. Is there any way you can break that into 10 projects with 1k files each, or 20 projects with 500 files each, etc? I have found dramatic improvements in (Java compiling) speed as a result of breaking huge projects like this into a series of much smaller projects with dependencies between the projects etc as needed. Having said that, 20 seconds for 4k files sounds pretty quick! Sorry but I'm not sure how to explain the 20 sec vs 90 sec results you're experiencing. I'd check versions of everything and flags sent to compilers etc via -X. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Any reason ant should compile faster?
I wish I could break it up. Among the problems with this code is the extreme bit of coupling. The scripts list 300 files to compile because that's all that we would have wanted, but they pull in other files, which pull in yet others. Trying to compile this fairly small subsystem winds up building about a third of the entire project. But I will definitely look at the options and see what I can learn from them; thanks for the suggestions. Russ On Jul 24, 2013, at 12:31 PM, Wayne Fay wayne...@gmail.com wrote: The case I'm wondering about now is one where we have over 10,000 source files in a directory, and compile them bit-by-bit. One step specifies about 300 files, and thanks to javac dependency logic, actually compiles about 4000 files in ant. Is there any way you can break that into 10 projects with 1k files each, or 20 projects with 500 files each, etc? I have found dramatic improvements in (Java compiling) speed as a result of breaking huge projects like this into a series of much smaller projects with dependencies between the projects etc as needed. Having said that, 20 seconds for 4k files sounds pretty quick! Sorry but I'm not sure how to explain the 20 sec vs 90 sec results you're experiencing. I'd check versions of everything and flags sent to compilers etc via -X. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html!
Re: Any reason ant should compile faster?
On 24/07/2013 12:35 PM, Russell Gold wrote: I wish I could break it up. Among the problems with this code is the extreme bit of coupling. The scripts list 300 files to compile because that's all that we would have wanted, but they pull in other files, which pull in yet others. Trying to compile this fairly small subsystem winds up building about a third of the entire project. Pulling in classes does not mean recompiling them. Once you have compiled the dependencies and aggregate them into jars, they can be referenced without recompiling them. This will speed things up tremendously. Do you at least have packages to use as a starting point? Ron But I will definitely look at the options and see what I can learn from them; thanks for the suggestions. Russ On Jul 24, 2013, at 12:31 PM, Wayne Fay wayne...@gmail.com wrote: The case I'm wondering about now is one where we have over 10,000 source files in a directory, and compile them bit-by-bit. One step specifies about 300 files, and thanks to javac dependency logic, actually compiles about 4000 files in ant. Is there any way you can break that into 10 projects with 1k files each, or 20 projects with 500 files each, etc? I have found dramatic improvements in (Java compiling) speed as a result of breaking huge projects like this into a series of much smaller projects with dependencies between the projects etc as needed. Having said that, 20 seconds for 4k files sounds pretty quick! Sorry but I'm not sure how to explain the 20 sec vs 90 sec results you're experiencing. I'd check versions of everything and flags sent to compilers etc via -X. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Any reason ant should compile faster?
Oh, you underestimate the coupling of this code. Yes, there are packages, but the classes in those packages reference one another willy-nilly. It's not a problem with recompiling - it's that there don't appear to be any good, sensible subset of classes in this group of 10,000 or so which can be compiled on their own. This set of 4000 appears to be the minimum of what's left. And worse, it appears that we published the main classes responsible for doing the coupling - and our customers use them in their own scripts. The architect responsible for this mess left the company ten years ago, shortly after putting it in place over the objections of most of the senior staff, and we haven't been able to remove it. Russ On Jul 24, 2013, at 3:28 PM, Ron Wheeler rwhee...@artifact-software.com wrote: On 24/07/2013 12:35 PM, Russell Gold wrote: I wish I could break it up. Among the problems with this code is the extreme bit of coupling. The scripts list 300 files to compile because that's all that we would have wanted, but they pull in other files, which pull in yet others. Trying to compile this fairly small subsystem winds up building about a third of the entire project. Pulling in classes does not mean recompiling them. Once you have compiled the dependencies and aggregate them into jars, they can be referenced without recompiling them. This will speed things up tremendously. Do you at least have packages to use as a starting point? Ron But I will definitely look at the options and see what I can learn from them; thanks for the suggestions. Russ On Jul 24, 2013, at 12:31 PM, Wayne Fay wayne...@gmail.com wrote: The case I'm wondering about now is one where we have over 10,000 source files in a directory, and compile them bit-by-bit. One step specifies about 300 files, and thanks to javac dependency logic, actually compiles about 4000 files in ant. Is there any way you can break that into 10 projects with 1k files each, or 20 projects with 500 files each, etc? I have found dramatic improvements in (Java compiling) speed as a result of breaking huge projects like this into a series of much smaller projects with dependencies between the projects etc as needed. Having said that, 20 seconds for 4k files sounds pretty quick! Sorry but I'm not sure how to explain the 20 sec vs 90 sec results you're experiencing. I'd check versions of everything and flags sent to compilers etc via -X. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html!
Re: Any reason ant should compile faster?
On 24/07/2013 4:40 PM, Russell Gold wrote: Oh, you underestimate the coupling of this code. Yes, there are packages, but the classes in those packages reference one another willy-nilly. It's not a problem with recompiling - it's that there don't appear to be any good, sensible subset of classes in this group of 10,000 or so which can be compiled on their own. This set of 4000 appears to be the minimum of what's left. And worse, it appears that we published the main classes responsible for doing the coupling - and our customers use them in their own scripts. This does not mean that they require recompiling in a single Maven project. The architect responsible for this mess left the company ten years ago, shortly after putting it in place over the objections of most of the senior staff, and we haven't been able to remove it. You could start by breaking the whole mess into packages that live in a single project. If you get down to 80-100 Maven projects, you will at least have a start on a cleanup and a way to reduce the need to compile 4000 classes at once. Our biggest application was made up of 90 Maven projects but most major revisions only required changes to 10-20 Maven projects and we edited, compiled and tested each project individually even if it depended on other jars. We had designed it from the start as a layered stack so our initial packaging into Maven projects made sense but we did many refactoring over the years as we went through major revisions and changed our views about how to structure the application. Maven is designed to support multi-project applications. Ron Russ On Jul 24, 2013, at 3:28 PM, Ron Wheeler rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com wrote: On 24/07/2013 12:35 PM, Russell Gold wrote: I wish I could break it up. Among the problems with this code is the extreme bit of coupling. The scripts list 300 files to compile because that's all that we would have wanted, but they pull in other files, which pull in yet others. Trying to compile this fairly small subsystem winds up building about a third of the entire project. Pulling in classes does not mean recompiling them. Once you have compiled the dependencies and aggregate them into jars, they can be referenced without recompiling them. This will speed things up tremendously. Do you at least have packages to use as a starting point? Ron But I will definitely look at the options and see what I can learn from them; thanks for the suggestions. Russ On Jul 24, 2013, at 12:31 PM, Wayne Fay wayne...@gmail.com mailto:wayne...@gmail.com wrote: The case I'm wondering about now is one where we have over 10,000 source files in a directory, and compile them bit-by-bit. One step specifies about 300 files, and thanks to javac dependency logic, actually compiles about 4000 files in ant. Is there any way you can break that into 10 projects with 1k files each, or 20 projects with 500 files each, etc? I have found dramatic improvements in (Java compiling) speed as a result of breaking huge projects like this into a series of much smaller projects with dependencies between the projects etc as needed. Having said that, 20 seconds for 4k files sounds pretty quick! Sorry but I'm not sure how to explain the 20 sec vs 90 sec results you're experiencing. I'd check versions of everything and flags sent to compilers etc via -X. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org mailto:users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org mailto:users-h...@maven.apache.org - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org mailto:users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org mailto:users-h...@maven.apache.org - Come read my webnovel,/Take a Lemon/http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Any reason ant should compile faster?
On Jul 24, 2013, at 8:36 PM, Ron Wheeler rwhee...@artifact-software.com wrote: On 24/07/2013 4:40 PM, Russell Gold wrote: Oh, you underestimate the coupling of this code. Yes, there are packages, but the classes in those packages reference one another willy-nilly. It's not a problem with recompiling - it's that there don't appear to be any good, sensible subset of classes in this group of 10,000 or so which can be compiled on their own. This set of 4000 appears to be the minimum of what's left. And worse, it appears that we published the main classes responsible for doing the coupling - and our customers use them in their own scripts. This does not mean that they require recompiling in a single Maven project. What am I missing? If I compile the classes I want, I get the others because of compile dependencies. If I compile some of the others instead, I still get them all. How do I not compile them in a single maven project? Essentially, there is a backbone of classes, all of which refer to a certain few classes - and those few classes refer to all the rest. The comment about customers using them was just an explanation of why we can't just refactor out the dependencies. The public classes are the ones that contain the dependencies. The architect responsible for this mess left the company ten years ago, shortly after putting it in place over the objections of most of the senior staff, and we haven't been able to remove it. You could start by breaking the whole mess into packages that live in a single project. If you get down to 80-100 Maven projects, you will at least have a start on a cleanup and a way to reduce the need to compile 4000 classes at once. We do use multiple projects. This blob (which is actually what we call it) represents about half the system, and a third of those participate in the tight coupling. Beyond that, we have about 100 separate project that are currently in ant, and are due to convert. Our biggest application was made up of 90 Maven projects but most major revisions only required changes to 10-20 Maven projects and we edited, compiled and tested each project individually even if it depended on other jars. We had designed it from the start as a layered stack so our initial packaging into Maven projects made sense but we did many refactoring over the years as we went through major revisions and changed our views about how to structure the application. Maven is designed to support multi-project applications. Ron Russ On Jul 24, 2013, at 3:28 PM, Ron Wheeler rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com wrote: On 24/07/2013 12:35 PM, Russell Gold wrote: I wish I could break it up. Among the problems with this code is the extreme bit of coupling. The scripts list 300 files to compile because that's all that we would have wanted, but they pull in other files, which pull in yet others. Trying to compile this fairly small subsystem winds up building about a third of the entire project. Pulling in classes does not mean recompiling them. Once you have compiled the dependencies and aggregate them into jars, they can be referenced without recompiling them. This will speed things up tremendously. Do you at least have packages to use as a starting point? Ron But I will definitely look at the options and see what I can learn from them; thanks for the suggestions. Russ On Jul 24, 2013, at 12:31 PM, Wayne Fay wayne...@gmail.com mailto:wayne...@gmail.com wrote: The case I'm wondering about now is one where we have over 10,000 source files in a directory, and compile them bit-by-bit. One step specifies about 300 files, and thanks to javac dependency logic, actually compiles about 4000 files in ant. Is there any way you can break that into 10 projects with 1k files each, or 20 projects with 500 files each, etc? I have found dramatic improvements in (Java compiling) speed as a result of breaking huge projects like this into a series of much smaller projects with dependencies between the projects etc as needed. Having said that, 20 seconds for 4k files sounds pretty quick! Sorry but I'm not sure how to explain the 20 sec vs 90 sec results you're experiencing. I'd check versions of everything and flags sent to compilers etc via -X. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org mailto:users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org mailto:users-h...@maven.apache.org - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com skype: ronaldmwheeler
Re: Any reason ant should compile faster?
Or let me rephrase that. In simple terms, I have dependency graphs like this: A B C ^ | \--- D / How do I put these classes into separate modules? On Jul 24, 2013, at 10:28 PM, Russell Gold r...@gold-family.us wrote: On Jul 24, 2013, at 8:36 PM, Ron Wheeler rwhee...@artifact-software.com wrote: On 24/07/2013 4:40 PM, Russell Gold wrote: Oh, you underestimate the coupling of this code. Yes, there are packages, but the classes in those packages reference one another willy-nilly. It's not a problem with recompiling - it's that there don't appear to be any good, sensible subset of classes in this group of 10,000 or so which can be compiled on their own. This set of 4000 appears to be the minimum of what's left. And worse, it appears that we published the main classes responsible for doing the coupling - and our customers use them in their own scripts. This does not mean that they require recompiling in a single Maven project. What am I missing? If I compile the classes I want, I get the others because of compile dependencies. If I compile some of the others instead, I still get them all. How do I not compile them in a single maven project? Essentially, there is a backbone of classes, all of which refer to a certain few classes - and those few classes refer to all the rest. The comment about customers using them was just an explanation of why we can't just refactor out the dependencies. The public classes are the ones that contain the dependencies. The architect responsible for this mess left the company ten years ago, shortly after putting it in place over the objections of most of the senior staff, and we haven't been able to remove it. You could start by breaking the whole mess into packages that live in a single project. If you get down to 80-100 Maven projects, you will at least have a start on a cleanup and a way to reduce the need to compile 4000 classes at once. We do use multiple projects. This blob (which is actually what we call it) represents about half the system, and a third of those participate in the tight coupling. Beyond that, we have about 100 separate project that are currently in ant, and are due to convert. Our biggest application was made up of 90 Maven projects but most major revisions only required changes to 10-20 Maven projects and we edited, compiled and tested each project individually even if it depended on other jars. We had designed it from the start as a layered stack so our initial packaging into Maven projects made sense but we did many refactoring over the years as we went through major revisions and changed our views about how to structure the application. Maven is designed to support multi-project applications. Ron Russ On Jul 24, 2013, at 3:28 PM, Ron Wheeler rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com wrote: On 24/07/2013 12:35 PM, Russell Gold wrote: I wish I could break it up. Among the problems with this code is the extreme bit of coupling. The scripts list 300 files to compile because that's all that we would have wanted, but they pull in other files, which pull in yet others. Trying to compile this fairly small subsystem winds up building about a third of the entire project. Pulling in classes does not mean recompiling them. Once you have compiled the dependencies and aggregate them into jars, they can be referenced without recompiling them. This will speed things up tremendously. Do you at least have packages to use as a starting point? Ron But I will definitely look at the options and see what I can learn from them; thanks for the suggestions. Russ On Jul 24, 2013, at 12:31 PM, Wayne Fay wayne...@gmail.com mailto:wayne...@gmail.com wrote: The case I'm wondering about now is one where we have over 10,000 source files in a directory, and compile them bit-by-bit. One step specifies about 300 files, and thanks to javac dependency logic, actually compiles about 4000 files in ant. Is there any way you can break that into 10 projects with 1k files each, or 20 projects with 500 files each, etc? I have found dramatic improvements in (Java compiling) speed as a result of breaking huge projects like this into a series of much smaller projects with dependencies between the projects etc as needed. Having said that, 20 seconds for 4k files sounds pretty quick! Sorry but I'm not sure how to explain the 20 sec vs 90 sec results you're experiencing. I'd check versions of everything and flags sent to compilers etc via -X. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org mailto:users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org mailto:users-h...@maven.apache.org - Come read my webnovel, Take a
Re: Any reason ant should compile faster?
On 25 July 2013 12:06, Russell Gold r...@gold-family.us wrote: Or let me rephrase that. In simple terms, I have dependency graphs like this: A B C ^ | \--- D / How do I put these classes into separate modules? Short answer is: Break the graph. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Any reason ant should compile faster?
Exactly. Which I cannot do because these classes are public and our customers rely on them. If I break the graph, that means changing a behavior that a customer might be using, and that would be a serious problem. I am pushing to deprecate the entire graph and provide a completely different api that won't have these problems, but even if I get that approved, we have to support this for several releases. If there's an alternative, I'm all ears. On Jul 24, 2013, at 10:38 PM, Barrie Treloar baerr...@gmail.com wrote: On 25 July 2013 12:06, Russell Gold r...@gold-family.us wrote: Or let me rephrase that. In simple terms, I have dependency graphs like this: A B C ^ | \--- D / How do I put these classes into separate modules? Short answer is: Break the graph. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html!
Re: Any reason ant should compile faster?
Hi Russell, Is the circular dependency in the API itself (i.e., method signatures) or merely in usage of the classes in implementation? If only usage, one strategy to break compile-time dependencies is the java.lang.reflect API. It's not ideal -- your modules will still have a runtime circular dependency -- but it will give you a compile-time DAG for easier Maven modularization. Regards, Curtis On Jul 24, 2013 9:58 PM, Russell Gold r...@gold-family.us wrote: Exactly. Which I cannot do because these classes are public and our customers rely on them. If I break the graph, that means changing a behavior that a customer might be using, and that would be a serious problem. I am pushing to deprecate the entire graph and provide a completely different api that won't have these problems, but even if I get that approved, we have to support this for several releases. If there's an alternative, I'm all ears. On Jul 24, 2013, at 10:38 PM, Barrie Treloar baerr...@gmail.com wrote: On 25 July 2013 12:06, Russell Gold r...@gold-family.us wrote: Or let me rephrase that. In simple terms, I have dependency graphs like this: A B C ^ | \--- D / How do I put these classes into separate modules? Short answer is: Break the graph. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html!
Re: Any reason ant should compile faster?
On 24/07/2013 10:56 PM, Russell Gold wrote: Exactly. Which I cannot do because these classes are public and our customers rely on them. If I break the graph, that means changing a behavior that a customer might be using, and that would be a serious problem. I am pushing to deprecate the entire graph and provide a completely different api that won't have these problems, but even if I get that approved, we have to support this for several releases. If there's an alternative, I'm all ears. On Jul 24, 2013, at 10:38 PM, Barrie Treloar baerr...@gmail.com wrote: On 25 July 2013 12:06, Russell Gold r...@gold-family.us wrote: Or let me rephrase that. In simple terms, I have dependency graphs like this: A B C ^ | \--- D / How do I put these classes into separate modules? I am not sure how you build them now! If you can build this now, you can break the graph in the same way and put them in dependent projects. How many of these cyclical graphs do you have? Once you break the graph you should be able to end up with a set of modules that the customers can continue to use as A,B,C and D even if D no longer depends on A or C no longer depends on D. A--B--C--X D--A or A--B--C--D--X or A implements X and depends on B--C--D D--X Ron Short answer is: Break the graph. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Any reason ant should compile faster?
Hi Curtis, sadly, it's in the API. I've oversimplified. In general, one of the classes in the chain actually has direct API references to hundreds of others. It turns out that at least some of the links are through deprecated classes. I am hoping that in the next version, we can remove them - and then see if that makes things more manageable. I'm not hopeful, though. - Russ On Jul 24, 2013, at 11:03 PM, Curtis Rueden ctrue...@wisc.edu wrote: Hi Russell, Is the circular dependency in the API itself (i.e., method signatures) or merely in usage of the classes in implementation? If only usage, one strategy to break compile-time dependencies is the java.lang.reflect API. It's not ideal -- your modules will still have a runtime circular dependency -- but it will give you a compile-time DAG for easier Maven modularization. Regards, Curtis On Jul 24, 2013 9:58 PM, Russell Gold r...@gold-family.us wrote: Exactly. Which I cannot do because these classes are public and our customers rely on them. If I break the graph, that means changing a behavior that a customer might be using, and that would be a serious problem. I am pushing to deprecate the entire graph and provide a completely different api that won't have these problems, but even if I get that approved, we have to support this for several releases. If there's an alternative, I'm all ears. On Jul 24, 2013, at 10:38 PM, Barrie Treloar baerr...@gmail.com wrote: On 25 July 2013 12:06, Russell Gold r...@gold-family.us wrote: Or let me rephrase that. In simple terms, I have dependency graphs like this: A B C ^ | \--- D / How do I put these classes into separate modules? Short answer is: Break the graph. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html!
Re: Any reason ant should compile faster?
It builds now because Javac is able to handle this case - as long as it all happens in the same compile. For those of us used to older languages that compiled one class at a time under the covers, and proceeded in order through each source file, it sounds odd, but javac has been doing this since at least 1.02. Short answer: I cannot break the graph at present, so it all has to happen in one compile - and that's really unfortunate as the coupled classes include half of two major subsystems, a third of another, and bits and pieces of a dozen more. It's very frustrating. On Jul 25, 2013, at 12:34 AM, Ron Wheeler rwhee...@artifact-software.com wrote: On 24/07/2013 10:56 PM, Russell Gold wrote: Exactly. Which I cannot do because these classes are public and our customers rely on them. If I break the graph, that means changing a behavior that a customer might be using, and that would be a serious problem. I am pushing to deprecate the entire graph and provide a completely different api that won't have these problems, but even if I get that approved, we have to support this for several releases. If there's an alternative, I'm all ears. On Jul 24, 2013, at 10:38 PM, Barrie Treloar baerr...@gmail.com wrote: On 25 July 2013 12:06, Russell Gold r...@gold-family.us wrote: Or let me rephrase that. In simple terms, I have dependency graphs like this: A B C ^ | \--- D / How do I put these classes into separate modules? I am not sure how you build them now! If you can build this now, you can break the graph in the same way and put them in dependent projects. How many of these cyclical graphs do you have? Once you break the graph you should be able to end up with a set of modules that the customers can continue to use as A,B,C and D even if D no longer depends on A or C no longer depends on D. A--B--C--X D--A or A--B--C--D--X or A implements X and depends on B--C--D D--X Ron Short answer is: Break the graph. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html!
Re: Any reason ant should compile faster?
I suppose that at this time the best that you can do is break out the clean bits into small projects and leave the rest as one big compile. Ron On 25/07/2013 12:43 AM, Russell Gold wrote: It builds now because Javac is able to handle this case - as long as it all happens in the same compile. For those of us used to older languages that compiled one class at a time under the covers, and proceeded in order through each source file, it sounds odd, but javac has been doing this since at least 1.02. Short answer: I cannot break the graph at present, so it all has to happen in one compile - and that's really unfortunate as the coupled classes include half of two major subsystems, a third of another, and bits and pieces of a dozen more. It's very frustrating. On Jul 25, 2013, at 12:34 AM, Ron Wheeler rwhee...@artifact-software.com wrote: On 24/07/2013 10:56 PM, Russell Gold wrote: Exactly. Which I cannot do because these classes are public and our customers rely on them. If I break the graph, that means changing a behavior that a customer might be using, and that would be a serious problem. I am pushing to deprecate the entire graph and provide a completely different api that won't have these problems, but even if I get that approved, we have to support this for several releases. If there's an alternative, I'm all ears. On Jul 24, 2013, at 10:38 PM, Barrie Treloar baerr...@gmail.com wrote: On 25 July 2013 12:06, Russell Gold r...@gold-family.us wrote: Or let me rephrase that. In simple terms, I have dependency graphs like this: A B C ^ | \--- D / How do I put these classes into separate modules? I am not sure how you build them now! If you can build this now, you can break the graph in the same way and put them in dependent projects. How many of these cyclical graphs do you have? Once you break the graph you should be able to end up with a set of modules that the customers can continue to use as A,B,C and D even if D no longer depends on A or C no longer depends on D. A--B--C--X D--A or A--B--C--D--X or A implements X and depends on B--C--D D--X Ron Short answer is: Break the graph. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
