[m2] single source tree problems
Ok, I had some problems with source:jar plugin yesterday where because the pom was in the same directory as the source files, the com/... was ignored thus making the java source files top level in the source.jar file. Yes I could branch the plugin locally and make it accept the package to prepend, but this is obviously less than ideal, and I'm noticing this sort of problem elsewhere. But this is just part of a bigger problem for me and so I have some questions to the maven community. I work with many projects that are based around a single source tree - by that I mean no matter how many modules and jars are build, there is just one directory called com with all the code underneath it. I'm not saying this is better or worse than the structure expected by Maven 2 out the box (don't want to sign up for that war!!), but I still need to find some practical solutions 1. The big one: is Maven 2 ever going to provide deliberate support projects that are based around a single source tree? Or is it deemed that the single source tree customers are too few to bother with. 2. Has anyone else gone through the same difficulties as I seem to be having - I'd love to hear of your strategies. I can think of two styles for tackling this problem. Firstly start off with a single source tree and then use a cunning system of drive mapping to make it look as though there are several source trees. Don't know how I'd filter just on the package of interest, but I probably don't care as I hate the idea of using the file system like this. Or persuade Maven to just see a certain package, maybe with an Ant style includes filter. I think I've seen something like this in the docs, but I'm hoping I don't have to repeat it for all plugins - ie compiler jar etc. I'd like to tell a particular pom that: here is the filter, that is the world that you can see. In fact I have written an eclipse plugin that creates an eclipse project with an includes filter that successfully reduces eclipse's view of my code, but I've based it on the pom being in the same directory as the code. I wonder if a better structure might be as follows: com [foo.pom, bar.pom, baz.pom, foo.eclipse, bar.eclipse, baz.eclipse] acme foo [MyApp.java, MyAppTest.java] resources [pic.gif] webapp [you know] bar [MyApp.java, MyAppTest.java] resources [pic.gif] webapp [you know] baz [MyApp.java, MyAppTest.java] resources [pic.gif] webapp [you know] My first attempt had the eclipse and pom files in the package itself, but neither eclipse or maven play nicely with that. So I think to stand any chance they would need to occupy the same namespace, top level or com. Before I spend time on it, would this work?? Apologies for the long winded post, especially if there is a simple answer that says: 'here's what you should do' but I haven't seen anything in the docs that offers any clues. Thanks AW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] single source tree problems
At 07:09 AM 9/8/2005, Ashley Williams wrote: I work with many projects that are based around a single source tree - by that I mean no matter how many modules and jars are build, there is just one directory called com with all the code underneath it. I'm not saying this is better or worse than the structure expected by Maven 2 out the box (don't want to sign up for that war!!), but I still need to find some practical solutions 1. The big one: is Maven 2 ever going to provide deliberate support projects that are based around a single source tree? Or is it deemed that the single source tree customers are too few to bother with. 2. Has anyone else gone through the same difficulties as I seem to be having - I'd love to hear of your strategies. Ashley, For what its worth, I've been porting a number of projects to M1 and M2 by breaking up single source trees into the multiple subprojects expected by Maven. So far I've found that to work very nicely and from my perspective it actually makes the code much easier to think about and manage. I can't speak for the Maven developers, but I would think that the likelihood of Maven's being reworked to support multiple artifacts from a single source tree is low, unless for some reason a group decides to fork the code. I think that if I were you, and I wanted to get at least some of the advantages of Maven but retain a non-compliant single tree layout, I would scale back my expectations of using many of Maven's features and use the M2 provided Ant integrations to take advantage of as many Maven capabilities as were easy to access. Fighting one's toolset sounds like a most unpleasant task to me. You might want to take a look at Javagen Jam, as it provides what I have found to be a really nice Maven to Ant integration, and it uses the Ant import task to create importable, reusable chunks of Ant code, which are not as expressive as Jelly, but can be very powerful. In addition you could look at using the Ant tasks presetdef and macrodef in concert with the import task to create higher level wrappers around existing Ant tasks. You mentioned drive mapping, so I imagine that you are developing on Windows. I realize that it is pretty ridiculous of me to suggest that you move your development to a Unix box, but Unix supports soft links, which ought to make the task of simulating multiple source trees from a single source tree much easier. As a possibility for the future, Trygve Laugstol is working on creating an embedded M2 implementation. M2 is much faster than M1, and Maven supports a -f alternate-pom.xml flag, so it might be possible to break your required processing into a set of poms and invoke them serially. Again, I would want to caution you, very few people ever win fighting city hall. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] single source tree problems
Thanks for your response. In fact I'm equally comfortable working with single or multiple source trees and see the benefits for both. However. As a contractor I don't have the luxury of going into any given project and demanding that a budget be allocated to start splitting up the existing usually massive source structure - so therefore I'm trying to find a way of using Maven on such projects. It's the difference between saying: There's this great build tool that we should be using, but we do have to smash up the existing source structure. Somebody on the maven mailing list said it's easy so I don't mind sticking my neck on the block. vs There's this great build tool that we should be using and the good news is that we can keep the single source tree and continue using the existing build tools in the meantime BTW the only reason I mentioned mapping drives because that's what we did on a previous project - no I use Mac OS X at home and we're very happy thanks ;) In defence of single source trees, it's maybe easier to peruse the code. I'm trying to understand the maven project itself and am faced with maybe 100 different folders each with their own src trees. Will the eclipse plugin make a project out of all of that for example so that I can peruse and refactor the code? (Not rhetorical, I really don't know) At the moment I have to do a mdfind filename (spotlight search, MAC OS X ;) ) to locate a maven file and then quickly build the eclipse:eclipse project just there. ** I do understand that Maven can't support every file structure out there but I would have thought the single source tree is a very important and standard one. I suppose also that most maven users here will be sold on multiple source trees by the definition of maven user. Anyway I believe I'm having some success and I will definitely post up my findings for anyone who might be interested. Probably take a while though. -AW On 8 Sep 2005, at 14:07, Andy Glick wrote: At 07:09 AM 9/8/2005, Ashley Williams wrote: I work with many projects that are based around a single source tree - by that I mean no matter how many modules and jars are build, there is just one directory called com with all the code underneath it. I'm not saying this is better or worse than the structure expected by Maven 2 out the box (don't want to sign up for that war!!), but I still need to find some practical solutions 1. The big one: is Maven 2 ever going to provide deliberate support projects that are based around a single source tree? Or is it deemed that the single source tree customers are too few to bother with. 2. Has anyone else gone through the same difficulties as I seem to be having - I'd love to hear of your strategies. Ashley, For what its worth, I've been porting a number of projects to M1 and M2 by breaking up single source trees into the multiple subprojects expected by Maven. So far I've found that to work very nicely and from my perspective it actually makes the code much easier to think about and manage. I can't speak for the Maven developers, but I would think that the likelihood of Maven's being reworked to support multiple artifacts from a single source tree is low, unless for some reason a group decides to fork the code. I think that if I were you, and I wanted to get at least some of the advantages of Maven but retain a non- compliant single tree layout, I would scale back my expectations of using many of Maven's features and use the M2 provided Ant integrations to take advantage of as many Maven capabilities as were easy to access. Fighting one's toolset sounds like a most unpleasant task to me. You might want to take a look at Javagen Jam, as it provides what I have found to be a really nice Maven to Ant integration, and it uses the Ant import task to create importable, reusable chunks of Ant code, which are not as expressive as Jelly, but can be very powerful. In addition you could look at using the Ant tasks presetdef and macrodef in concert with the import task to create higher level wrappers around existing Ant tasks. You mentioned drive mapping, so I imagine that you are developing on Windows. I realize that it is pretty ridiculous of me to suggest that you move your development to a Unix box, but Unix supports soft links, which ought to make the task of simulating multiple source trees from a single source tree much easier. As a possibility for the future, Trygve Laugstol is working on creating an embedded M2 implementation. M2 is much faster than M1, and Maven supports a -f alternate-pom.xml flag, so it might be possible to break your required processing into a set of poms and invoke them serially. Again, I would want to caution you, very few people ever win fighting city hall. :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: [m2] single source tree problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems to me that there was a JIRA filed for sourceModifications in m2, but I think it's been pushed for now...maybe until 2.1, I dunno for sure. I understand the position you're in, and that you don't really have the power to dictate a mass reorganization of your contractee's project code. I believe we have some other use cases for this functionality, where it's simply not practical to modularize the source tree in the near- to medium-term. However, these sorts of features are doomed to lag behind the core functionality a bit, as they really are stop-gap solutions that are only suitable for the short term. I won't lecture you on the ins and outs of modular source trees - I'm sure you know already - but I will mention one specific point, for clarity. Having a monolithic source tree has a rather dramatic ownership cost. It means that everyone working on it must be concerned with regressions across the tree, and it hides what would otherwise be reusable and generally useful functionality from groups outside the team members that maintain that codebase. Therefore, for the longer term, it's better to chop this stuff up and make a series of finer grained artifacts that encapsulate some coherent, sane set of functionality. It's a thin line to walk between the utility and coherence of artifacts we build on the one hand, and pragmatism on the other. We've simply chosen to promote the former as a priority, with functionality related to the latter lagging slightly behind. I assure you, we are interested in making our product as generally applicable as possible, but we're only a few people, and that means we have to set some priorities. I hope you can be patient, and keep making good suggestions. Thanks, john Ashley Williams wrote: | Thanks for your response. In fact I'm equally comfortable working with | single or multiple source trees and see the benefits for both. | | However. | | As a contractor I don't have the luxury of going into any given project | and demanding that a budget be allocated to start splitting up the | existing usually massive source structure - so therefore I'm trying to | find a way of using Maven on such projects. It's the difference between | saying: | | There's this great build tool that we should be using, but we do have | to smash up the existing source structure. Somebody on the maven | mailing list said it's easy so I don't mind sticking my neck on the | block. | | vs | | There's this great build tool that we should be using and the good | news is that we can keep the single source tree and continue using the | existing build tools in the meantime | | BTW the only reason I mentioned mapping drives because that's what we | did on a previous project - no I use Mac OS X at home and we're very | happy thanks ;) | | In defence of single source trees, it's maybe easier to peruse the | code. I'm trying to understand the maven project itself and am faced | with maybe 100 different folders each with their own src trees. Will | the eclipse plugin make a project out of all of that for example so | that I can peruse and refactor the code? (Not rhetorical, I really | don't know) At the moment I have to do a mdfind filename (spotlight | search, MAC OS X ;) ) to locate a maven file and then quickly build the | eclipse:eclipse project just there. | | ** | | I do understand that Maven can't support every file structure out there | but I would have thought the single source tree is a very important and | standard one. I suppose also that most maven users here will be sold on | multiple source trees by the definition of maven user. | | Anyway I believe I'm having some success and I will definitely post up | my findings for anyone who might be interested. Probably take a while | though. | | -AW | | On 8 Sep 2005, at 14:07, Andy Glick wrote: | | At 07:09 AM 9/8/2005, Ashley Williams wrote: | | | I work with many projects that are based around a single source tree | - by that I mean no matter how many modules and jars are build, there | is just one directory called com with all the code underneath it. I'm | not saying this is better or worse than the structure expected by | Maven 2 out the box (don't want to sign up for that war!!), but I | still need to find some practical solutions | | 1. The big one: is Maven 2 ever going to provide deliberate support | projects that are based around a single source tree? Or is it deemed | that the single source tree customers are too few to bother with. | | 2. Has anyone else gone through the same difficulties as I seem to be | having - I'd love to hear of your strategies. | | | Ashley, | | For what its worth, I've been porting a number of projects to M1 and | M2 by breaking up single source trees into the multiple subprojects | expected by Maven. So far I've found that to work very nicely and | from my perspective it actually makes the code much easier to think | about and manage. | | I can't
Re: [m2] single source tree problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Actually, now that I think about it, I believe we made that modification already...it'd be in the maven-compiler-plugin configuration, probably in an includes/ excludes/ pair (sub-elements must currently be of the form: include implementation=java.lang.String../include for what that's worth). Admittedly, this will not tackle the issue of creating a source jar that reflects only the sources that were built. This would require a POM-level property to specify includes/excludes and a configuration for the source-artifact plugin to use that property, which in turn might be better specified as a DOM structure in the POM properties...but, baby steps. :) We'll get there eventually. In the meantime, try that modification to the maven-compiler-plugin configuration. Cheers, john P.S. My memory might be faulty on this one, but I *think* it's been added...if not, it's on the list. John Casey wrote: | It seems to me that there was a JIRA filed for sourceModifications in | m2, but I think it's been pushed for now...maybe until 2.1, I dunno for | sure. | | I understand the position you're in, and that you don't really have the | power to dictate a mass reorganization of your contractee's project | code. I believe we have some other use cases for this functionality, | where it's simply not practical to modularize the source tree in the | near- to medium-term. However, these sorts of features are doomed to lag | behind the core functionality a bit, as they really are stop-gap | solutions that are only suitable for the short term. | | I won't lecture you on the ins and outs of modular source trees - I'm | sure you know already - but I will mention one specific point, for | clarity. Having a monolithic source tree has a rather dramatic ownership | cost. It means that everyone working on it must be concerned with | regressions across the tree, and it hides what would otherwise be | reusable and generally useful functionality from groups outside the team | members that maintain that codebase. Therefore, for the longer term, | it's better to chop this stuff up and make a series of finer grained | artifacts that encapsulate some coherent, sane set of functionality. | | It's a thin line to walk between the utility and coherence of artifacts | we build on the one hand, and pragmatism on the other. We've simply | chosen to promote the former as a priority, with functionality related | to the latter lagging slightly behind. I assure you, we are interested | in making our product as generally applicable as possible, but we're | only a few people, and that means we have to set some priorities. | | I hope you can be patient, and keep making good suggestions. | | Thanks, | | john | | Ashley Williams wrote: | | Thanks for your response. In fact I'm equally comfortable working with | | single or multiple source trees and see the benefits for both. | | | | However. | | | | As a contractor I don't have the luxury of going into any given project | | and demanding that a budget be allocated to start splitting up the | | existing usually massive source structure - so therefore I'm trying to | | find a way of using Maven on such projects. It's the difference between | | saying: | | | | There's this great build tool that we should be using, but we do have | | to smash up the existing source structure. Somebody on the maven | | mailing list said it's easy so I don't mind sticking my neck on the | | block. | | | | vs | | | | There's this great build tool that we should be using and the good | | news is that we can keep the single source tree and continue using the | | existing build tools in the meantime | | | | BTW the only reason I mentioned mapping drives because that's what we | | did on a previous project - no I use Mac OS X at home and we're very | | happy thanks ;) | | | | In defence of single source trees, it's maybe easier to peruse the | | code. I'm trying to understand the maven project itself and am faced | | with maybe 100 different folders each with their own src trees. Will | | the eclipse plugin make a project out of all of that for example so | | that I can peruse and refactor the code? (Not rhetorical, I really | | don't know) At the moment I have to do a mdfind filename (spotlight | | search, MAC OS X ;) ) to locate a maven file and then quickly build the | | eclipse:eclipse project just there. | | | | ** | | | | I do understand that Maven can't support every file structure out there | | but I would have thought the single source tree is a very important and | | standard one. I suppose also that most maven users here will be sold on | | multiple source trees by the definition of maven user. | | | | Anyway I believe I'm having some success and I will definitely post up | | my findings for anyone who might be interested. Probably take a while | | though. | | | | -AW | | | | On 8 Sep 2005, at 14:07, Andy Glick wrote: | | | | At 07:09 AM 9/8/2005, Ashley
Re: [m2] single source tree problems
Hi John, Looking forward to the properties code btw I don't expect Maven to provide me with something out of the box, because I do understand it's priorities. In fact I don't think any features are required (hopefully), just some way of puzzling how to use the properties that are already there. As long as the plugins are 100% consistent in the way they use those properties, eg outputDirectory, sourceDirectory etc, then hopefully there shouldn't be any problem. Like you said it's just coming up with a use case, if we mean the same thing. I've added a few comments below... On 8 Sep 2005, at 15:07, John Casey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems to me that there was a JIRA filed for sourceModifications in m2, but I think it's been pushed for now...maybe until 2.1, I dunno for sure. I understand the position you're in, and that you don't really have the power to dictate a mass reorganization of your contractee's project code. I believe we have some other use cases for this functionality, where it's simply not practical to modularize the source tree in the near- to medium-term. However, these sorts of features are doomed to lag behind the core functionality a bit, as they really are stop-gap solutions that are only suitable for the short term. I won't lecture you on the ins and outs of modular source trees - I'm sure you know already - but I will mention one specific point, for clarity. Having a monolithic source tree has a rather dramatic ownership cost. It means that everyone working on it must be concerned with regressions across the tree, and it hides what would otherwise be reusable and generally useful functionality from groups outside the team members that maintain that codebase. Therefore, for the longer term, it's better to chop this stuff up and make a series of finer grained artifacts that encapsulate some coherent, sane set of functionality. Not sure I agree with your original assumptions. The java package namespace is one thing and the carving up into component jar files etc is another. The package namespace is monolithic whichever way you look at it, ie it's always going to be one package tree. Having one or many filesystem trees won't affect the source code authors one jot, but it will have an impact how the deployment team go about their business. Eg they will dictate that a certain file structure convenient for the jar command (multiple fs trees), or they will apply some filtering rules (single fs tree). Yeah I know, the deployer is just the coder in a different hat ;) For me I don't care whether the code is in a database, single fs tree or multiple fs trees or even accessed through jndi, but I do disagree that splitting up your filing system along the lines of your component distribution is automatically a wise thing to do for any given project. It's a thin line to walk between the utility and coherence of artifacts we build on the one hand, and pragmatism on the other. We've simply chosen to promote the former as a priority, with functionality related to the latter lagging slightly behind. I assure you, we are interested in making our product as generally applicable as possible, but we're only a few people, and that means we have to set some priorities. I hope you can be patient, and keep making good suggestions. I will aim for a 0.5 s/n ratio, but I can't promise anything! Thanks, john Ashley Williams wrote: | Thanks for your response. In fact I'm equally comfortable working with | single or multiple source trees and see the benefits for both. | | However. | | As a contractor I don't have the luxury of going into any given project | and demanding that a budget be allocated to start splitting up the | existing usually massive source structure - so therefore I'm trying to | find a way of using Maven on such projects. It's the difference between | saying: | | There's this great build tool that we should be using, but we do have | to smash up the existing source structure. Somebody on the maven | mailing list said it's easy so I don't mind sticking my neck on the | block. | | vs | | There's this great build tool that we should be using and the good | news is that we can keep the single source tree and continue using the | existing build tools in the meantime | | BTW the only reason I mentioned mapping drives because that's what we | did on a previous project - no I use Mac OS X at home and we're very | happy thanks ;) | | In defence of single source trees, it's maybe easier to peruse the | code. I'm trying to understand the maven project itself and am faced | with maybe 100 different folders each with their own src trees. Will | the eclipse plugin make a project out of all of that for example so | that I can peruse and refactor the code? (Not rhetorical, I really | don't know) At the moment I have to do a mdfind filename (spotlight | search, MAC OS X ;) ) to
Re: [m2] single source tree problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Comments inline. Cheers, john Ashley Williams wrote: | Hi John, | | Looking forward to the properties code btw It's in. Good luck! :) snip/ | I won't lecture you on the ins and outs of modular source trees - I'm | sure you know already - but I will mention one specific point, for | clarity. Having a monolithic source tree has a rather dramatic ownership | cost. It means that everyone working on it must be concerned with | regressions across the tree, and it hides what would otherwise be | reusable and generally useful functionality from groups outside the team | members that maintain that codebase. Therefore, for the longer term, | it's better to chop this stuff up and make a series of finer grained | artifacts that encapsulate some coherent, sane set of functionality. | | | Not sure I agree with your original assumptions. The java package | namespace is one thing and the carving up into component jar files etc | is another. The package namespace is monolithic whichever way you look | at it, ie it's always going to be one package tree. Having one or many | filesystem trees won't affect the source code authors one jot, but it | will have an impact how the deployment team go about their business. Eg | they will dictate that a certain file structure convenient for the jar | command (multiple fs trees), or they will apply some filtering rules | (single fs tree). Yeah I know, the deployer is just the coder in a | different hat ;) Have you ever looked at the Spring source tree? Or the Eclipse one? While it might make complete sense browsing the class hierarchy in any of the jars created by either of these projects, trying to understand where these jars come from the source tree is an exercise in frustration. While the package namespace is monolithic, splitting these projects into pieces would provide a clear, targetted way of finding, building, and maybe patching/fixing the source code for a given jar. It makes parallel release cycles simpler, too, since the whole monolithic project doesn't have to pass tests in order to release a revision on one subset of the functionality. This isn't just a deployment issue, it's about the entire development approach. If you have multiple teams working on multiple deadlines which will result in releases of their respective code - potentially at different times - why would you want that code to reside in the same monolithic codebase? If you're assuming a single release cycle for all artifacts produced from that codebase, isn't it reasonable to assume that some of that huge codebase could be reused in different projects, and that that reuse might uncover patch scenarios and a separation of the release cycle for that artifact? If you don't have separate release cycles per artifact, the only other scenario I can think of for producing multiple artifacts is separation across a client/server type boundary...which is the only long-term legitimate use case for filtered compiles that I've heard, IMO. Short-term practicality notwithstanding, of course. :) | | For me I don't care whether the code is in a database, single fs tree | or multiple fs trees or even accessed through jndi, but I do disagree | that splitting up your filing system along the lines of your component | distribution is automatically a wise thing to do for any given project. Splitting of a codebase has the same pro- arguments as splitting up the java packaging structure. There may be reasons for putting all classes in the default package '.' but I haven't heard them...beyond the ever-present short-term need to just get it working. I'm not making any assertion about automatic or absolute, just arguing from my own experiences. snip/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDIFiNK3h2CZwO/4URAoxLAJ9uxhERzVelnCubCYQ+scfPxZ83qQCeLQlZ iRxxX7F1s5x/hA1fsIWaFm8= =Lsbu -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] single source tree problems
Ah, I think I see what your reading from my comments and I don't mean what you're thinking, ie not producing separate patchable jars and having one monolithic build file. That would be suicide! Just to be clear what I'm saying, those single file system projects I have worked on are absolutely split up into components that can be used in other projects and build and tested separately and self contained- they are just jar files. However this is achieved solely by the package name, ie everything under that package is one component eg com acme gui (gui.jar) model (model.jar) util (util.jar) So only the deployers know that their jar files map onto the above packages, but the developers don't even care. They're just worried about the code tree. I don't know the experiences of folk here, but the details of the build files are of little consequence to about 90% of developers on a project, other than the fact that there is this funny build file that has to complete successfully before you are allowed to check in. Relative to Maven I'm the same: I really don't care which jar file contains the plugin class that's throwing an exception, I just want to find it quickly by pressing (shift+apple+n) so that I can see what the problem is. What I've been trying to do is to place a pom where you see a jar so that you could instantly see which packages correspond to deployable elements at a glance. A horror story for you: I worked on one project where the build.xml file was autogenerated by velocity and was over 3000 line long and growing. Every time you added a top level package to your source tree it would grow some more by copying a set of tags at the end. Eventually there was noone on the project left that knew much about how it worked! Honestly though I don't wish to advocate one way over the other. On 8 Sep 2005, at 16:28, John Casey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Comments inline. Cheers, john Ashley Williams wrote: | Hi John, | | Looking forward to the properties code btw It's in. Good luck! :) snip/ | I won't lecture you on the ins and outs of modular source trees - I'm | sure you know already - but I will mention one specific point, for | clarity. Having a monolithic source tree has a rather dramatic ownership | cost. It means that everyone working on it must be concerned with | regressions across the tree, and it hides what would otherwise be | reusable and generally useful functionality from groups outside the team | members that maintain that codebase. Therefore, for the longer term, | it's better to chop this stuff up and make a series of finer grained | artifacts that encapsulate some coherent, sane set of functionality. | | | Not sure I agree with your original assumptions. The java package | namespace is one thing and the carving up into component jar files etc | is another. The package namespace is monolithic whichever way you look | at it, ie it's always going to be one package tree. Having one or many | filesystem trees won't affect the source code authors one jot, but it | will have an impact how the deployment team go about their business. Eg | they will dictate that a certain file structure convenient for the jar | command (multiple fs trees), or they will apply some filtering rules | (single fs tree). Yeah I know, the deployer is just the coder in a | different hat ;) Have you ever looked at the Spring source tree? Or the Eclipse one? While it might make complete sense browsing the class hierarchy in any of the jars created by either of these projects, trying to understand where these jars come from the source tree is an exercise in frustration. While the package namespace is monolithic, splitting these projects into pieces would provide a clear, targetted way of finding, building, and maybe patching/fixing the source code for a given jar. It makes parallel release cycles simpler, too, since the whole monolithic project doesn't have to pass tests in order to release a revision on one subset of the functionality. This isn't just a deployment issue, it's about the entire development approach. If you have multiple teams working on multiple deadlines which will result in releases of their respective code - potentially at different times - why would you want that code to reside in the same monolithic codebase? If you're assuming a single release cycle for all artifacts produced from that codebase, isn't it reasonable to assume that some of that huge codebase could be reused in different projects, and that that reuse might uncover patch scenarios and a separation of the release cycle for that artifact? If you don't have separate release cycles per artifact, the only other scenario I can think of for producing multiple artifacts is separation across a client/server type boundary...which is the only long-term legitimate use case for filtered compiles
Re: [m2] single source tree problems
On Thu, 8 Sep 2005, Ashley Williams wrote: Just a short comment on this: your developers don't care about which artifacts are produced and what's in them. But they don't see that each package is a separate jar, and has specific dependencies on other packages, usually versioned (probably not in your case..?) The risk of having 1 big sourcetree for different artifacts is that you can't see the dependencies between the packages easily; i.e. if you're working in an IDE you can just use any class available, so dependencies can become spaghetti easily. In eclipse you can't even create multiple projects that share the same sourcetree with an includes/excludes filter. By splitting the packages up into standalone source trees you can force dependencies between them. Plus you can't freeze a version for one team when the other team is working on a package, unless you check out different versions for each package subtree. But all this is probably not a concern :) Just my 2 cents, -- Kenney Ah, I think I see what your reading from my comments and I don't mean what you're thinking, ie not producing separate patchable jars and having one monolithic build file. That would be suicide! Just to be clear what I'm saying, those single file system projects I have worked on are absolutely split up into components that can be used in other projects and build and tested separately and self contained- they are just jar files. However this is achieved solely by the package name, ie everything under that package is one component eg com acme gui (gui.jar) model (model.jar) util (util.jar) So only the deployers know that their jar files map onto the above packages, but the developers don't even care. They're just worried about the code tree. I don't know the experiences of folk here, but the details of the build files are of little consequence to about 90% of developers on a project, other than the fact that there is this funny build file that has to complete successfully before you are allowed to check in. Relative to Maven I'm the same: I really don't care which jar file contains the plugin class that's throwing an exception, I just want to find it quickly by pressing (shift+apple+n) so that I can see what the problem is. What I've been trying to do is to place a pom where you see a jar so that you could instantly see which packages correspond to deployable elements at a glance. A horror story for you: I worked on one project where the build.xml file was autogenerated by velocity and was over 3000 line long and growing. Every time you added a top level package to your source tree it would grow some more by copying a set of tags at the end. Eventually there was noone on the project left that knew much about how it worked! Honestly though I don't wish to advocate one way over the other. On 8 Sep 2005, at 16:28, John Casey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Comments inline. Cheers, john Ashley Williams wrote: | Hi John, | | Looking forward to the properties code btw It's in. Good luck! :) snip/ | I won't lecture you on the ins and outs of modular source trees - I'm | sure you know already - but I will mention one specific point, for | clarity. Having a monolithic source tree has a rather dramatic ownership | cost. It means that everyone working on it must be concerned with | regressions across the tree, and it hides what would otherwise be | reusable and generally useful functionality from groups outside the team | members that maintain that codebase. Therefore, for the longer term, | it's better to chop this stuff up and make a series of finer grained | artifacts that encapsulate some coherent, sane set of functionality. | | | Not sure I agree with your original assumptions. The java package | namespace is one thing and the carving up into component jar files etc | is another. The package namespace is monolithic whichever way you look | at it, ie it's always going to be one package tree. Having one or many | filesystem trees won't affect the source code authors one jot, but it | will have an impact how the deployment team go about their business. Eg | they will dictate that a certain file structure convenient for the jar | command (multiple fs trees), or they will apply some filtering rules | (single fs tree). Yeah I know, the deployer is just the coder in a | different hat ;) Have you ever looked at the Spring source tree? Or the Eclipse one? While it might make complete sense browsing the class hierarchy in any of the jars created by either of these projects, trying to understand where these jars come from the source tree is an exercise in frustration. While the package namespace is monolithic, splitting these projects into pieces would provide a clear, targetted way of finding, building, and maybe patching/fixing
Re: [m2] single source tree problems
Kenney, see my comments inline. Slight change of topic: I definitely think there is a big black hole that lies between an IDE and Maven - really push the integration aspect hard and I think Maven adoption would accelerate. As if you guys aren't working hard enough already! Thanks - AW On 8 Sep 2005, at 19:10, Kenney Westerhof wrote: On Thu, 8 Sep 2005, Ashley Williams wrote: Just a short comment on this: your developers don't care about which artifacts are produced and what's in them. But they don't see that each package is a separate jar, and has specific dependencies on other packages, usually versioned (probably not in your case..?) The risk of having 1 big sourcetree for different artifacts is that you can't see the dependencies between the packages easily; i.e. if you're working in an IDE you can just use any class available, so dependencies can become spaghetti easily. In eclipse you can't even create multiple Yes I have definitely experienced this phenomena! However we did get round this on my most recent project. I remember working away in intellij on a bugfix (all was fine) then going to check my code in only to find there was a build failure. I was soon put straight by the experienced members of the team since I was importing a class from an illegal jar file. The build files were such that the classpath only included legal dependencies. ie the filtering and dependencies were enforced by the ant scripts and not by the filing system. projects that share the same sourcetree with an includes/excludes filter. By splitting the packages up into standalone source trees you can force dependencies between them. I've written a plugin that does just that. Each project points to the source root and just adds an includes filter for the specified artifact package. Plus you can't freeze a version for one team when the other team is working on a package, unless you check out different versions for each package subtree. Not sure what you're describing here, but if my team isn't ready for the latest jar file I just stick at a dependency right? I probably don't understand your point though. But all this is probably not a concern :) Just my 2 cents, -- Kenney Ah, I think I see what your reading from my comments and I don't mean what you're thinking, ie not producing separate patchable jars and having one monolithic build file. That would be suicide! Just to be clear what I'm saying, those single file system projects I have worked on are absolutely split up into components that can be used in other projects and build and tested separately and self contained- they are just jar files. However this is achieved solely by the package name, ie everything under that package is one component eg com acme gui (gui.jar) model (model.jar) util (util.jar) So only the deployers know that their jar files map onto the above packages, but the developers don't even care. They're just worried about the code tree. I don't know the experiences of folk here, but the details of the build files are of little consequence to about 90% of developers on a project, other than the fact that there is this funny build file that has to complete successfully before you are allowed to check in. Relative to Maven I'm the same: I really don't care which jar file contains the plugin class that's throwing an exception, I just want to find it quickly by pressing (shift+apple+n) so that I can see what the problem is. What I've been trying to do is to place a pom where you see a jar so that you could instantly see which packages correspond to deployable elements at a glance. A horror story for you: I worked on one project where the build.xml file was autogenerated by velocity and was over 3000 line long and growing. Every time you added a top level package to your source tree it would grow some more by copying a set of tags at the end. Eventually there was noone on the project left that knew much about how it worked! Honestly though I don't wish to advocate one way over the other. On 8 Sep 2005, at 16:28, John Casey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Comments inline. Cheers, john Ashley Williams wrote: | Hi John, | | Looking forward to the properties code btw It's in. Good luck! :) snip/ | I won't lecture you on the ins and outs of modular source trees - I'm | sure you know already - but I will mention one specific point, for | clarity. Having a monolithic source tree has a rather dramatic ownership | cost. It means that everyone working on it must be concerned with | regressions across the tree, and it hides what would otherwise be | reusable and generally useful functionality from groups outside the team | members that maintain that codebase. Therefore, for the longer term, | it's better to chop this stuff up and make a series of finer grained | artifacts that encapsulate some coherent, sane set of functionality. | |
