MyFaces Maven structure - a few questions

[Manfred Geiler <ma...@gmail.com>]

A few questions to the MyFaces maven gurus:
(Sorry if some of these questions already have been asked or discussed
- I did what I could to search in my mail archives for the right
answers  ;-)

Q1. Regarding the maven sub-project: Why do build-tools and master-pom
have no parent relationship to the maven-project pom?
Q2. What exactly is the build-tools module for? Checkstyle is not used
yet, right?
Q3. Why does the site pom have no parent relationship to the
myfaces-master pom? Seems to contain lots of redundant information
which could be derived from master pom.
Q4. What is commons/src/site? Is this zombie code?
Q5. The module name "wagon-maven-plugin" is a bit confusing IMHO.
Should't we call it "myfaces-maven-wagon-plugin" or something like
that to point out that this is no standard or codehaus sandbox plugin?
Q6. Why do assembly sub-modules exist? Is there any issue that
prevents us from adding the assembly configuration into the modules
pom itself?
Q7. AFAIK the scm config is not needed within sub-modules. Maven
calculates the right SVN URLs. So, any objections against removing scm
config from core/api, core/impl, tomahawk/core etc. ?

What I currently try to achieve is a simple way to deploy a snapshot
or release version to a corporate maven repository. Therefore I'm
exploring simple ways to make the distributionManagement config
overwritable by the user. Not really difficult with profile
properties. Will check that in soon.

Maven rocks and I want to thank all of you guys that helped to
mavenize MyFaces. However, the current numer of POMs in MyFaces is
slaying me. So we should try to simplify things in some places I
think. I will try to help out where I can.

Manfred

Re: MyFaces Maven structure - a few questions

[Manfred Geiler <ma...@gmail.com>]

> > Q7. AFAIK the scm config is not needed within sub-modules. Maven
> > calculates the right SVN URLs. So, any objections against removing scm
> > config from core/api, core/impl, tomahawk/core etc. ?
>
> Yes I object.  It won't work.  This only works if your artifacts have
> the same name as your directories.  So we would have to name our
> directories myfaces/core/myfaces-api instead of myfaces/core/api.

I remember some discussions regarding the dir names. So, naming all
module dirs after the artifactId would have solved this, right? Ok, no
big deal. Nothing we can't live with.

Manfred

Re: MyFaces Maven structure - a few questions

[Manfred Geiler <ma...@gmail.com>]

> Maven likes poms.

And so do I - but too much of them make me dizzy   ;-)


> I don't think you are going to be able to do much
> better but I'd be happy to see it!  When you think about it, there
> really are a bunch of artifacts in our project and each artifact
> *must* have a pom.  The artifacts also relate to each other so that's
> what gives you some of the extra ones.

Perhaps we could get rid of the assembly poms? Ok, let's wait for
Bernds answers.

Manfred

Re: MyFaces Maven structure - a few questions

[Sean Schofield <se...@gmail.com>]

I actually created the redundancy on purpose.  Its just a few lines
that aren't likely to change soon.  I would rather have the few lines
repeated in two poms instead of creating a new dependency.

The master pom has several reports defined along with the list of
developers and some other useful stuff.  Since the committer/pmc list,
etc. sometimes change and since its so large it makes sense to have it
in a master pom.

Sean

On 2/14/06, Manfred Geiler <ma...@gmail.com> wrote:
> On 2/14/06, Sean Schofield <se...@gmail.com> wrote:
> > > Q1. Regarding the maven sub-project: Why do build-tools and master-pom
> > > have no parent relationship to the maven-project pom?
> >
> > There is nothing that needs to really be shared between the two.  More
> > importantly, since every other subproject starts out with the
> > master-pom, you would basically require all of
> > those projects to depend on the maven-project pom.  This would be
> > another extra artifact that you would have to publish and maintain
> > (for no good reason.)
>
> Well, there is exactly one good reason which is also the reason why
> I'm asking ;-)
> DistributionManagement is currently defined in redundant places which
> shouldn't be so IMHO. The easiest thing would be to eleminate
> distributionManagement info from every pom other than the
> maven-project pom. But this would only work if master-pom and
> build-tools would be derived from maven-project pom.
>
> Manfred
>

Re: MyFaces Maven structure - a few questions

[Manfred Geiler <ma...@gmail.com>]

On 2/14/06, Sean Schofield <se...@gmail.com> wrote:
> > Q1. Regarding the maven sub-project: Why do build-tools and master-pom
> > have no parent relationship to the maven-project pom?
>
> There is nothing that needs to really be shared between the two.  More
> importantly, since every other subproject starts out with the
> master-pom, you would basically require all of
> those projects to depend on the maven-project pom.  This would be
> another extra artifact that you would have to publish and maintain
> (for no good reason.)

Well, there is exactly one good reason which is also the reason why
I'm asking ;-)
DistributionManagement is currently defined in redundant places which
shouldn't be so IMHO. The easiest thing would be to eleminate
distributionManagement info from every pom other than the
maven-project pom. But this would only work if master-pom and
build-tools would be derived from maven-project pom.

Manfred

Re: MyFaces Maven structure - a few questions

[Bernd Bohmann <be...@atanion.com>]

First, I don't like the master pom.
Every subproject should have his own pom.
But this is an other question.

Sean Schofield schrieb:
>>Q1. Regarding the maven sub-project: Why do build-tools and master-pom
>>have no parent relationship to the maven-project pom?
> 
> 
> There is nothing that needs to really be shared between the two.  More
> importantly, since every other subproject starts out with the
> master-pom, you would basically require all of
> those projects to depend on the maven-project pom.  This would be
> another extra artifact that you would have to publish and maintain
> (for no good reason.)
> 
> 
>>Q2. What exactly is the build-tools module for? Checkstyle is not used
>>yet, right?

Tobago is using checkstyle and for a multi module setup you need one 
artifact for the common configuration of your checkstyle and pmd and 
maybe other plugins.

> 
> 
> I will let Bernd answer that one.
> 
> 
>>Q3. Why does the site pom have no parent relationship to the
>>myfaces-master pom? Seems to contain lots of redundant information
>>which could be derived from master pom.
> 


If the site is a parent of the master pom it would be distributed to
the url of the master pom plus the artifactId.

For example the site in master pom is 
minotaur.apache.org/www/myfaces.apache.org

the site would be distibuted to 
minotaur.apache.org/www/myfaces.apache.org/${artifactId}

Without a parent the artifactId is not appended to the site url.

> 
> I want to know the answer to this one too ;-)  It did have this
> reference just a few days ago until things were breaking.  Bernd
> somehow go it to work by removing this ref.  I've asked him to explain
> how this works.  We definitely need to go back to using the master-pom
> though.  That was one of the main reasons for having it (so we didn't
> need to maintain dual lists.)
> 
> 
>>Q4. What is commons/src/site? Is this zombie code?
> 
> 
> No.  Its the commons portion of the site.  There is no description yet
> but I am writing one up as we speak.
> 
> 
>>Q5. The module name "wagon-maven-plugin" is a bit confusing IMHO.
>>Should't we call it "myfaces-maven-wagon-plugin" or something like
>>that to point out that this is no standard or codehaus sandbox plugin?
> 
It is a simple wagon wrapper. It has nothing to do with myfaces only it 
copies the content of a dir to an other server per ssh. Maybe 
myfaces-maven-wagon-plugin would be a better name but the plugin is not 
myfaces specific. Maybe we should post it on codehaus but I have not the 
time to support this plugin.
> 
> Maybe but its already released now.  Hopefully it can be abandoned
> eventually once we get the official maven ones to do what we need. 
> Ask Bernd about the name choice.
> 
> 
>>Q6. Why do assembly sub-modules exist? Is there any issue that
>>prevents us from adding the assembly configuration into the modules
>>pom itself?

Does the assembly only contains the artifact of this module you would be 
right. But if is an assembly of a set of artifacts it should an own 
module. And with an own pom you can define the content per dependency 
section.
> 
> 
> Bernd can answer this one.  He is more knowledgeable about maven.
> 
> 
>>Q7. AFAIK the scm config is not needed within sub-modules. Maven
>>calculates the right SVN URLs. So, any objections against removing scm
>>config from core/api, core/impl, tomahawk/core etc. ?
> 
> 
> Yes I object.  It won't work.  This only works if your artifacts have
> the same name as your directories.  So we would have to name our
> directories myfaces/core/myfaces-api instead of myfaces/core/api.
> 


Bernd

Re: MyFaces Maven structure - a few questions

[Sean Schofield <se...@gmail.com>]

> Q1. Regarding the maven sub-project: Why do build-tools and master-pom
> have no parent relationship to the maven-project pom?

There is nothing that needs to really be shared between the two.  More
importantly, since every other subproject starts out with the
master-pom, you would basically require all of
those projects to depend on the maven-project pom.  This would be
another extra artifact that you would have to publish and maintain
(for no good reason.)

> Q2. What exactly is the build-tools module for? Checkstyle is not used
> yet, right?

I will let Bernd answer that one.

> Q3. Why does the site pom have no parent relationship to the
> myfaces-master pom? Seems to contain lots of redundant information
> which could be derived from master pom.

I want to know the answer to this one too ;-)  It did have this
reference just a few days ago until things were breaking.  Bernd
somehow go it to work by removing this ref.  I've asked him to explain
how this works.  We definitely need to go back to using the master-pom
though.  That was one of the main reasons for having it (so we didn't
need to maintain dual lists.)

> Q4. What is commons/src/site? Is this zombie code?

No.  Its the commons portion of the site.  There is no description yet
but I am writing one up as we speak.

> Q5. The module name "wagon-maven-plugin" is a bit confusing IMHO.
> Should't we call it "myfaces-maven-wagon-plugin" or something like
> that to point out that this is no standard or codehaus sandbox plugin?

Maybe but its already released now.  Hopefully it can be abandoned
eventually once we get the official maven ones to do what we need. 
Ask Bernd about the name choice.

> Q6. Why do assembly sub-modules exist? Is there any issue that
> prevents us from adding the assembly configuration into the modules
> pom itself?

Bernd can answer this one.  He is more knowledgeable about maven.

> Q7. AFAIK the scm config is not needed within sub-modules. Maven
> calculates the right SVN URLs. So, any objections against removing scm
> config from core/api, core/impl, tomahawk/core etc. ?

Yes I object.  It won't work.  This only works if your artifacts have
the same name as your directories.  So we would have to name our
directories myfaces/core/myfaces-api instead of myfaces/core/api.

> What I currently try to achieve is a simple way to deploy a snapshot
> or release version to a corporate maven repository. Therefore I'm
> exploring simple ways to make the distributionManagement config
> overwritable by the user. Not really difficult with profile
> properties. Will check that in soon.

I think you can use command line arguments to release to a public
repository.  Stay tuned to my wiki describing the release procedure. 
You can use that info for your private efforts.  Also, James Mitchell
has suggested we use our own repository as a backup to ibiblio.  So we
may have to deal with this ourselves soon.

> Maven rocks and I want to thank all of you guys that helped to
> mavenize MyFaces. However, the current numer of POMs in MyFaces is
> slaying me. So we should try to simplify things in some places I
> think. I will try to help out where I can.

Maven likes poms.  I don't think you are going to be able to do much
better but I'd be happy to see it!  When you think about it, there
really are a bunch of artifacts in our project and each artifact
*must* have a pom.  The artifacts also relate to each other so that's
what gives you some of the extra ones.

> Manfred

Sean

Sean