> I'm not sure that this will work with any version, Well what is in the master pom that would break an older version. As long as we don't use it for dependencies the rest is just reports and site stuff.
> I try to describe it with a possible release cycle. > First we should release commons. Commons has a parent ref to the master > pom in myfaces/api/trunk or any other pom. None release should have a > dependency to a unreleased version. How we can solve this? > I put all the related content of the master pom in the pom of common > define a version and remove the parent ref. > NOTE: the first release of commons has a dependency to > myfaces-api-1.1.1.jar (not any dependency to a unreleased version) I agree commons is released first. I'm not suggesting moving the stuff from the parent pom to the commons pom. Is that what you are suggesting? Or you suggesting this is a consequence of my approach? > > The next release whould be core. The core hasn't a dependency to any > unreleased version. Fine can release. > NOTE: the first release of commons and the core are really close together I agree core comes after commons and its close together. Any time you release tomohawk or core you should have a release of commons first. > Then I would release tomahawk. Tomahawk has a parent ref to the master > pom maybe this is an unreleased version this is not allowed ok put all > the related content to pom of tomahawk. > > Now we don't have any ref to a real master pom. My thinking was that each release references the *snapshot* of the master pom. If there is no chance of breaking backwards compatability this isn't an issue. > This is the reason why I don't see any need for a master pom in a > different place. I don't want to copy all this stuff now. But this must > be done for a release. I don't think we should copy for the release. I agree with you about that. But I am not suggesting we copy. I'm suggesting we use a snapshot. If we think we're going to break backwards compatability we could consider versioning the master pom right before we release. Make the master pom a dependency for tomahawk, etc. just like they depend on commons. So tomahawk has a ref to the snapshot pom. Then just before we release commons we "release" the master pom. It doesn't have to be a release with an announcement. Just tag it in SVN and then update the refs in the poms that need it as a parent. > The sandbox and the site are never released they can contain a ref to > any other pom. Sandbox should have a ref to tomahawk and the site to the > pom in the core. I'm a little confused by this. Doesn't sandbox already have a ref to tomahawk? > A release mean a jar in a public maven repository. Why can't a master pom be part of the "release." IMO if its acceptable in a snapshot repository its acceptable in a public repository. > > I wanted to ask you about myfaces-core. With a snapshot repository > > why can't we have a top level pom for api and impl? > > The top leven pom for api and impl is in > > myfaces/api/trunk > > maybe we should rename the dir api to core. That's not what I was thinking. I was thinking about your original idea of core/trunk/api, core/trunk/impl, core/trunk/core-assembly. You changed your mind when we were doing the SVN move. I just wanted to understand why we couldn't do this. What do you think? Sean
