> Struts is not a maven2 project. Please look at the maven project. > I don't see the advantages of your direction
Its a maven1 project. As I said, ultimately it doesn't matter too much what the other projects are doing. They are useful reference points but we're free to do things our own way as long as we understand the consequences. > I don't favor the short name for IDE reasons. In a IDE I see the > artifactId the long name. When people were saying they preferred the short names, you asked if any of us used an IDE. I figured you were citing that as a reason. It also came up a few times during our ICQ discussion. > One description was a technical one. If myfaces grows I expect more > directories with the same name. If that happens those similar directories will be underneath a top level subproject. So there should be no name clash. My preference is for shorter names with a tight hierarchy. > You don't describe any pro and cons. Everybody without a maven > background would agree you. But many people with a maven background > would prefer the maven conventions. Your vote is not really fair. We're talking about the result (longer directory names) which I think everyone can have an opinion on regardless of their Maven knowledge. So far nobody has presented a maven *requirement* that we use longer names. Wendy has pointed out several times now about how the artifact names and directories do not have to match. Since maven doesn't require it, I prefer to keep the names the way they were before we went down the maven road. We made other changes to our svn to accomodate maven b/c they were not as disagreeable and because using the maven directory layout makes the pom's much cleaner. > For me it is the best outcome. Ok. > But I hope you get some more maven background now and you change your mind. > And please look at the structure of the maven project, maybe you > understand me then. I've looked at the maven project. I find it confusing. Here's what I would expect to see: maven maven/core maven/continuum maven/plugins maven/plugins/foo maven/plugins/bar ... etc. Something like that. But that's not how they chose to organize it. Its their project so they can organize it how they want. > All of adf would be tomahawk? I don't expect it. Some of the parts can > be merge with tomahawk. I think this must be technical decision and not > only discuss internal in the PMC. I agree. Ted Husted and I made this point several times on the PMC mailing list during the early days of the discussion. Oracle wanted to keep things confidential until they had internal approval. I was against any serious discussion that did not take place in public. > Why this discussion is not open? Why we can't participate? What PMC > means Technical Management Committee. Then I should ask the PMC if I > have a technical problems instead asking the community. For the record, very little was decided and very little was discussed on the PMC list. Pretty much everything was deferred until Oracle decided to make the source publicly available. One issue that I raised was that the ADF stuff should make as much use of myfaces-commons as possible (including moving tomahawk and the impl to the ADF way when it made sense.) A bunch of PMC members said "Yes. I agree" to that sentiment. The other issue that I raised was that we should try to consolidate the number of components when there was overlap and that the components should all live in tomahawk. Again, I received a lot of +1's for that statement. So even though nothing has been decided I have a pretty good idea of how myself and other PMC members will vote when it comes down to it. As for the private PMC discussions, I agree with you. This should have been 100% on the dev list but since not everyone wanted to do this, I deferred to the others. > Do you expect a 1.2 api from myfaces? You mean a jsf 1.2 implementation? Yes. Will it be its own subproject? No. That's my personal opinion based on what I know now. The api is already pretty stable now. So we would probably create a branch for the 1.1 implementation once we started work on 1.2. > Is was only an example. > What is your problem with tobago-core? What is your problem with tobago/core? We seem to be going in circles here ... > Sorry, I'm talking about their source repository. They don't have a > different way they implements the maven way. I looked at it. I prefer the shorter names. Again, there is only so many ways to say the same thing. > > Why not a different group id for all of the subprojects? > > > > org.apache.myfaces.core > > org.apache.myfaces.commons > > org.apache.myfaces.tomahawk > > org.apache.myfaces.sandbox > > > Why not, but I would prefer org.apache.myfaces for core > If sandbox depends on tomahawk it should be org.apache.myfaces.tomahawk I'm not against org.apache.myfaces for core but it seems weird for org.apache.myfaces to apply to a subproject when the rest would have their own group ids. What do you think? > I would prefer myfaces-parent > This is not the myfaces-maven project > I would expect it for the the maven plugins and tools in myfaces > > > >>myfaces-project > > > > > > What's this? > > a different suggestion for myfaces-parent I think myfaces-maven makes perfect sense for things that are 100% maven related. Master poms, plugins and archtypes are all maven-related. So I think myfaces-maven is more appropriate/descriptive then myfaces-project. > > > >>myfaces-tomahawk > >>tomahawk > > > > > > +1 tomahawk > > > ok, but which name for the tomahawk master pom? I was wondering the same thing. tomahawk-pom? > >>myfaces-sandbox > >>tomahawk-sandbox > > > > > > > sandbox > > > the master pom of sandbox can't be sandbox because the sandbox src pom > has already this artifactId sandbox-pom for the parent pom. It makes sense doesn't it? Nobody will see these poms anyways so I don't think the names are too important. Whatever we call the jar (myfaces-sandbox, sandbox or tomahawk-sandbox) that artifact id has to be reserved for sandbox/sandbox. > >>myfaces-example-simple > >>tomahawk-example-simple? > > > > > > not sure > > > I'm too > > > > Bernd Sean
