Jason van Zyl <[EMAIL PROTECTED]> writes: [...]
>> 5. Other project structures. Sometimes I will encounter a project >> where all the source code is in one tree (beginning with com/). I'm >> not saying its any better than one directory per artifact, but I am >> saying I encounter such projects in my career and as such I know I >> wouldn't be able to use maven. >That's a choice you'll have to make. Many people have found making the >switch to our default ways of doing things has numerous benefits. If >it's not something you can do then we understand but we feel coherency, >consistency, and comprehension win out over other concerns. Make a good >plugin and all Maven users benefit. Make a one off script for your own >setup and you've just isolated yourself from a great source of potential >help. Making a decent plugin might take you an extra 20% in time but the >ultimate savings in time has shown itself in our community over and over >again. >We also know that new projects are starting all the time and this is the >ideal time to try Maven. For people who have different structures, you >will probably also find that their build now works and in these cases I >would never recommend switching from Make or Ant unless you are having >serious problems with maintenance. [...] This is something that I've begged to differ with you ever since maven-0.1. If you use maven only in "new projects", then yes, the maven structure does work. It leads to largely spread out docs because projects are cut into pieces held together by the reactor, but yes, the overall project works fine. However, there are two factors that don't seem to be on your radar since day one of maven: - legacy code and code structures - company rules Both of them void the "best possible layout" approach. Because these criterias win in 99% of the use cases with legacy code. If you are a contractor and want to introduce maven and start with "but we have to reorganize our whole 2,000,000 lines enterprise critical EAR application to fit the layout of a build tool", you won't get far. Been there, done that, got burned. Used ant. A simple example: Turbine (I know that you are familiar with it. ;-) ) Turbine consists of a source tree in src/java and some automatically generated classes that are generated at jar build time. Everything ends up in a single jar. The current approach is: - copy everything from src/java to target/src (maven.xml preGoal) - build the autogenerated classes into target/src (maven.xml preGoal) - build the project from target/src (regular java:compile) -> works. But: does not work with Eclipse at the same time, because the subversion controlled tree is at a different location as the actual build tree. Point eclipse at target/src: No Subversion. Point Eclipse at src/java: Missing classes. -> Catch-22 Easiest solution: Tell maven to have a source tree in src/java and another in target/autogenerated. Tailor the build process to compile one jar from two source locations. Impossible (or only possible with a hack as described in http://maven.apache.org/faq.html#multiple-source-directories) with maven 1. Is it technically impossible? I don't think so. My whole point was (and is and I got flamed by a number of maven people because I still insist on it): Maven is a build tool. This means, in architectural terms, it is putty or plaster, intended to keep the parts and bricks together from which I build my house. It is an integral part of the house but it must not dictate the shape in which I build my house. Currently, maven is plaster that contains various small and medium sized rocks. Due to this, I can't put all the parts of my house together in the way that I intend. I have to work around these rocks. Or I switch plaster brands. I've actually looked at ivy some time ago and dismissed it as "yes, it can resolve dependencies. Full stop". Maven is so much more than that. I'm _happy_ that I don't have to write ant build.xml files any more. I would very much prefer m2 to be "real" plaster. :-) Best regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development 4 - 8 - 15 - 16 - 23 - 42 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
