You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Bernd Bohmann <be...@atanion.com> on 2006/01/13 08:52:31 UTC
Re: svn commit: r368523 - /myfaces/maven/trunk/master-pom/
Hello Sean,
I don't think we need a master pom at this place.
As you described this pom would never released.
In future someone try to checkout an old tag from myfaces-impl to
compile the source, the pom is fetched from the maven/trunk/master-pom.
But the information of the pom is not compatible with the pom in
myfaces-impl nightmare.
I don't maintain this solution.
Until myfaces-core, myfaces-commons and tomahawk have no independ
release cycle the master pom should placed in myfaces-core. But with an
own cycle projets should have an own master pom or no parent ref.
Best Regards
Bernd .
schof@apache.org schrieb:
> Author: schof
> Date: Thu Jan 12 16:10:02 2006
> New Revision: 368523
>
> URL: http://svn.apache.org/viewcvs?rev=368523&view=rev
> Log:
> New directory for master pom file
>
> Added:
> myfaces/maven/trunk/master-pom/
>
>
Re: svn commit: r368523 - /myfaces/maven/trunk/master-pom/
Posted by Bernd Bohmann <be...@atanion.com>.
Hello,
I know I can configure maven to handle dir != artifactId.
But if you look at the adf source and at the tobago source they follow
this convention(please correct me if I'm wrong). If they are a part of
the myfaces project should they go back to the old structure?
We should try to get a unified layout.
Is there a really problem to name the dir == artifactId.
You have tp configure more if you not follow this convention.
We should try to keep all simple.
Is there a real technical reason to keep the dir name?
I don't think so.
Bernd
Wendy Smoak schrieb:
>
> Since I'm not having any trouble with the m2 Struts build where the
> directory names don't match the <artifactId>s, I asked on users@maven:
> http://marc.theaimsgroup.com/?t=113724973700002&r=1&w=2
>
> One person said no problem, another brought up the (unrelated) point
> that if the parent pom isn't directly above the child, you need to use
> <relativePath>.
>
> There are only two things I've found that Maven does *not* want to do,
> and they are 1) dealing with circular dependencies, and 2) building
> multiple artifacts from a single source tree. It's pretty flexible
> about everything else, and the more you conform to its conventions,
> the easier it gets.
>
> --
> Wendy
>
Re: svn commit: r368523 - /myfaces/maven/trunk/master-pom/
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/14/06, Bernd Bohmann <be...@atanion.com> wrote:
> Sean Schofield schrieb:
> > 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.
Since I'm not having any trouble with the m2 Struts build where the
directory names don't match the <artifactId>s, I asked on users@maven:
http://marc.theaimsgroup.com/?t=113724973700002&r=1&w=2
One person said no problem, another brought up the (unrelated) point
that if the parent pom isn't directly above the child, you need to use
<relativePath>.
There are only two things I've found that Maven does *not* want to do,
and they are 1) dealing with circular dependencies, and 2) building
multiple artifacts from a single source tree. It's pretty flexible
about everything else, and the more you conform to its conventions,
the easier it gets.
--
Wendy
Re: svn commit: r368523 - /myfaces/maven/trunk/master-pom/
Posted by Bernd Bohmann <be...@atanion.com>.
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
Re: svn commit: r368523 - /myfaces/maven/trunk/master-pom/
Posted by Sean Schofield <se...@gmail.com>.
> 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
Re: svn commit: r368523 - /myfaces/maven/trunk/master-pom/
Posted by Bernd Bohmann <be...@atanion.com>.
Sean Schofield schrieb:
>
> Why would the information not be compatible. Isn't it just a list of
> developers, mailings lists and misc reports for the website. My
> thinking is that this stuff will work with any version.
>
I'm not sure that this will work with any version,
> Lets come up with a good alternative then. I don't think the master
> pom belongs in api either. First of all, that's not an intuitive
> place to look for it. We saw this already with several of the
> developers not realizing this was the parent pom. Also, this suffers
> from the same criticism that you gave for maven/trunk/master-pom. If
> you checkout an older version of tomahawk, the parent pom is out of
> sync there as well.
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)
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
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.
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.
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.
A release mean a jar in a public maven repository.
>
>
> The core, commons and tomahawk will have their own release cylces.
> That is the plan (as soon as we finish up this maven business.)
>
Fine
> 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.
>
> Sean
>
Bernd
Re: svn commit: r368523 - /myfaces/maven/trunk/master-pom/
Posted by Sean Schofield <se...@gmail.com>.
> In future someone try to checkout an old tag from myfaces-impl to
> compile the source, the pom is fetched from the maven/trunk/master-pom.
> But the information of the pom is not compatible with the pom in
> myfaces-impl nightmare.
Why would the information not be compatible. Isn't it just a list of
developers, mailings lists and misc reports for the website. My
thinking is that this stuff will work with any version.
Lets come up with a good alternative then. I don't think the master
pom belongs in api either. First of all, that's not an intuitive
place to look for it. We saw this already with several of the
developers not realizing this was the parent pom. Also, this suffers
from the same criticism that you gave for maven/trunk/master-pom. If
you checkout an older version of tomahawk, the parent pom is out of
sync there as well.
> I don't maintain this solution.
>
> Until myfaces-core, myfaces-commons and tomahawk have no independ
> release cycle the master pom should placed in myfaces-core. But with an
> own cycle projets should have an own master pom or no parent ref.
The core, commons and tomahawk will have their own release cylces.
That is the plan (as soon as we finish up this maven business.)
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?
> Best Regards
>
>
> Bernd .
Sean