-----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 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] |> |> | | | --------------------------------------------------------------------- | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDIEWyK3h2CZwO/4URAjjOAKCYeGvLgXvdV04t0uD4qHkdMcJNugCglIAY QC49okp7j2TQn0wyXPKiVec= =u4sA -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
