-----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 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] | | | | | | - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDIE1SK3h2CZwO/4URAlnJAJ9BwAuyfhrfkho4xnaL5DUOUS8dpQCeLW3H x5Z+30PQw3pjBPalTtjDDXs= =eDH3 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
