Sean Schofield schrieb:
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 can't ensure this constraint.
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?
You should not have a dependency to a unreleased pom.
Maven has not only a development view. If you release a version with a
parent ref that is not released this would not work with maven.
If you add a dependency to myfaces-common in your project pom (not in
myfaces an other user of myfaces in an other project) maven downloads
the pom and the artifact from a public repository(ibiblio) and then it
try to download the parent pom but this is not released. This ended in
an error.
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.
A normal user of myfaces doesn't include the myfaces snapshot
prepository in his repository section of the pom. This only works if you
released the master-pom (one more external i don't like it is unuseful
it is only for mailinglists repository issuemanagement cimanagement
licenses organization and developer section of the pom)
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.
You have to copy if you don't release the master pom on a public
repositoy. A snapshot repository is not a repository for a released version.
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.
I'm a little confused by this. Doesn't sandbox already have a ref to
tomahawk?
I don't get a clear answer is the sandbox the tomahawk sandbox.
If the sanbox is the tomahawk sandbox it should 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.
One more external for only one file??????
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.
please name it myfaces-api and myfaces-impl
if you don't like it, you should not use maven I know it is possible to
configure maven to handle it. But if you configure to much in maven you
are going the wrong way and should stay with ant.
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?
I like the idea of the core, too.
I try to explain:
The core should reactor aware building myfaces-api and myfaces-impl.
But impl has a dependency to common. Then you try to build common oh
common has a dependency to api it doesn't build.
One possible solution would be, common has a dependency to the
myfaces-api-1.1.1.jar (Is the api changing so much?)
Then we can build commons and the core.
But I'm not sure that this is a really good solution. Maybe we should
ask the others.
Sean
Why you like the idea of the master pom in a different place so much.
You have to release one more component. It is not to much content in the
master pom. One more external...
Regards
Bernd
--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
