Kenney, I am in violent agreement with you in that the source code structure I'm trying to deal with is evil and must be destroyed.
And yes, my use case is exactly "I cannot change the repository structure" but not so much for technical reasons. I could move the stuff around quite easily, and then break all kinds of people depending on that source structure. So it's on our roadmap, but getting the build working is on the roadmap sooner. My read of "the maven principles" a-la convention over configuration is "leave it alone and your life is easier" but not "thou shalt not depart from the convention". I think this sticks to the principles in that you have to go out of your way to hang yourself. If you just do it the "normal" way, i.e., without giving weird names to your poms, without having a non-standard directory structure, the purity of your build is maintained. You have to already know you're doing something weird in order to run into these issues. Just my thoughts... But since it looks like there was already a jira issue posted against this... I may just send in the patch on it and we can 'rassle for it. :) B -----Original Message----- From: Kenney Westerhof [mailto:[EMAIL PROTECTED] Sent: Saturday, June 09, 2007 3:57 AM To: Maven Developers List Subject: Re: Idea for <modules> enhancement I'm basically against this idea. It can result in polluted jars very easily. Even if you have 2 poms in the same dir, both specifying different source directories, the files in target/ will overlap. the second executed pom will also contain the files from the first executed pom. Unless the target directory is changed too. So you'd have to change _all_ configuration elements in both poms that point to directories. It's much cleaner to split things up into two trees. I think I'll only vote +0/+1 on this feature if someone can show me a good usecase for this. And 'corporate policy' or 'I cannot change the repository structure' aren't good arguments since they go against maven principles. A module has always been a subdirectory tree with a pom; all of the subdirectories in the directory containing the pom belong to the module. The java+dotnet in 1 module is just bad practice - they have to very distinct packagings and cannot even have compile-time dependencies AFAIK. src/java/ src/dotnet/ could become src/main/java src/main/dotnet or even src/m1/main/java/ src/m2/main/dotnet/ or m1/src/main/java m2/src/main/dotnet, which solves the problem. -- Kenney Brett Porter wrote: > > On 07/06/2007, at 10:11 AM, Deacon, Brian wrote: > >> But does the Maven Jedi Council have any problem in principal with >> allowing the <module> element to specify the name of the pom file? > > Thought of it already someone has, mmmm? > http://jira.codehaus.org/browse/MNG-1493 > > I'd actually be happy with treating a file reference in the manner you > described these days (despite what I said in the issue). > > Cheers, > Brett > > --------------------------------------------------------------------- > 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]
