> I know it sounds weird at first, but having a POM dependency is not that > strange in the land of Maven. :-)
OK I think we have general agreement on this. @Bernd: We can always change this approach later if it doesn't work out. > I agree with Bernd, my preference would be for these to match as well. > > When you svn checkout with TortoiseSVN, the local directory name defaults > to the last part of the checkout path. > > So, if folks are checking out just "api", then there's not enough context > in the "api" name for their default local directory name. This is easily fixed by checking out to myfaces-api instead of api. I think the most common use case is to checkout out "current" to "myfaces" in which case you will have the myfaces parent directory. > Similarly, if folks are checking out trunk, and leave the default name > "trunk" for the local directory, then subdirectories of "api", "impl", etc > do not provide sufficient context. I've seen this "trunk" checkout > technique many times among my colleagues, especially as they were starting > out with SVN. > > ADF Faces uses the following directory structure: > > trunk/ > pom.xml > adf-faces-api/ > adf-faces-impl/ > adf-faces-demo/ > adf-faces-build/ Most seem to prefer the shorter names so I think we should leave them as short names for now. Since the short names do not affect what goes into the maven repo there is no harm in doing an svn change later it we want to. > Note: this last module, "adf-faces-build" contains metadata that is used at > build time, so it's a little different from the "build" module in MyFaces. Would this be the same as my proposed myfaces-master? This would be where the master pom lives. Also, because each module could potentially be on its own release track, we can't really have a meaningful top level pom (myfaces/pom.xml). Continuum is going to build everything for us anyways so big deal. Perhaps users could keep a myfaces/pom.xml in their own *local* checkout dir and we can add it to SVN ignore. This was you can do 'mvn install' on myfaces/pom.xml and build everything real quick. > > 3.) Establish a core module. So we have myfaces/core/trunk/api and > > myfaces/core/trunk/impl. Bernd and I had started down this road and > > stopped at his request. I think the issues that concerned us then can > > be addressed now. So can we agree to do this? > > What is the purpose of having such a core module? Because it will include both api and impl. We need two separate jars yet they will always be released together. So we have myfaces/core/trunk/api and myfaces/core/trunk/impl instead of myfaces/api/trunk and myfaces/impl/trunk. Tagging and branching is also simplified. Finally, we can have a myfaces/core/assembly which assembles everything into a single tarball. Since the final release product needs to contain both, this seems to make the most sense. > I would be concerned about releasing code in the same package for both the > runtime and the component libraries, where each is versioned and released > independently. > > Upgrading to a new version of a component library needs to guarantee zero > impact on the runtime and having code in overlapping packages violates that > principle when both are executed in the context of the same ClassLoader, as > only one copy of the overlapping packages can take precedence. > > Does this problem get any better or worse in JavaEE 5, where the container > is required to include a JSF 1.2 implementation? Would the ClassLoader of > the JSF 1.2 implementation be sufficiently isolated from the ClassLoader of > each Web Application to not be impacted by having two versions of the > overlapping packages? Not sure what you mean by this. Hopefully my explanation of core will address your concerns. If not, please clarify. > Kind Regards, > John Fallows. Sean
