> Q1. Regarding the maven sub-project: Why do build-tools and master-pom > have no parent relationship to the maven-project pom?
There is nothing that needs to really be shared between the two. More importantly, since every other subproject starts out with the master-pom, you would basically require all of those projects to depend on the maven-project pom. This would be another extra artifact that you would have to publish and maintain (for no good reason.) > Q2. What exactly is the build-tools module for? Checkstyle is not used > yet, right? I will let Bernd answer that one. > Q3. Why does the site pom have no parent relationship to the > myfaces-master pom? Seems to contain lots of redundant information > which could be derived from master pom. I want to know the answer to this one too ;-) It did have this reference just a few days ago until things were breaking. Bernd somehow go it to work by removing this ref. I've asked him to explain how this works. We definitely need to go back to using the master-pom though. That was one of the main reasons for having it (so we didn't need to maintain dual lists.) > Q4. What is commons/src/site? Is this zombie code? No. Its the commons portion of the site. There is no description yet but I am writing one up as we speak. > Q5. The module name "wagon-maven-plugin" is a bit confusing IMHO. > Should't we call it "myfaces-maven-wagon-plugin" or something like > that to point out that this is no standard or codehaus sandbox plugin? Maybe but its already released now. Hopefully it can be abandoned eventually once we get the official maven ones to do what we need. Ask Bernd about the name choice. > Q6. Why do assembly sub-modules exist? Is there any issue that > prevents us from adding the assembly configuration into the modules > pom itself? Bernd can answer this one. He is more knowledgeable about maven. > Q7. AFAIK the scm config is not needed within sub-modules. Maven > calculates the right SVN URLs. So, any objections against removing scm > config from core/api, core/impl, tomahawk/core etc. ? Yes I object. It won't work. This only works if your artifacts have the same name as your directories. So we would have to name our directories myfaces/core/myfaces-api instead of myfaces/core/api. > What I currently try to achieve is a simple way to deploy a snapshot > or release version to a corporate maven repository. Therefore I'm > exploring simple ways to make the distributionManagement config > overwritable by the user. Not really difficult with profile > properties. Will check that in soon. I think you can use command line arguments to release to a public repository. Stay tuned to my wiki describing the release procedure. You can use that info for your private efforts. Also, James Mitchell has suggested we use our own repository as a backup to ibiblio. So we may have to deal with this ourselves soon. > Maven rocks and I want to thank all of you guys that helped to > mavenize MyFaces. However, the current numer of POMs in MyFaces is > slaying me. So we should try to simplify things in some places I > think. I will try to help out where I can. Maven likes poms. I don't think you are going to be able to do much better but I'd be happy to see it! When you think about it, there really are a bunch of artifacts in our project and each artifact *must* have a pom. The artifacts also relate to each other so that's what gives you some of the extra ones. > Manfred Sean Sean
