myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Bohmann <>
Subject Re: Maven Update - More Questions
Date Wed, 11 Jan 2006 01:38:31 GMT
Hello Sean,

Sean Schofield schrieb:
> I wanted to update everyone on the work done over the weekend on the
> new Maven build.
> First of all, a big "Thank You" to Bernd and Bruno who put in a lot of
> time on this.  Bernd did a lot of the POM work and Bruno put in a lot
> of time converting over most of our website.
> The jars are building fine with a simple mvn install command run from
> myfaces/build.  You will also need Maven 2.0.1 (2.0 gives you a rather
> cryptic NPE.)
I don't like the build dir. We should use a snapshot repository. If we 
are using a snapshot repository we don't need a pom in build anymore.

> Also, several of you have asked about the tests being skipped.  Bernd
> added that intentionally because not all of the unit tests were
> working properly.  A very high priority TODO will be to get these
> working.  I added this to our Committers Wiki[1].  I believe there
> were several problems related to the encryption unit tests.  Perhaps
> we could enable 99% of the tests and just skip these?
A new version of the surefire plugin is available with forking support.
Forking is needed for the StateUtilsTestCases in common.
But the implementation of StateUtils contains some code for testing. 
Code for testing in non test classes is very ugly.
We should change the test to a mocked version.
An other problem is the MessageUtilsTest depends on the Message 
resources in impl, but impl has a dependency to common.
Can we move(copy) the resources from impl to common?

> Now for the questions/issues as I see them ...
> We have two high level POM's.  One is in build.  That is the POM that
> calls all of the modules.  The other is in api.  This one is the
> parent to the rest of the POM's. Bernd thought this was the best place
> to put it b/c the api project has no other dependencies on other
> modules in the project.  I think we should probably reconsider that
> decision now though.  Its not very intuitive.

We don't have two high level POM's please use a snapshot repository!!! 
You don't need to build all the stuff. The pom in build is only for 
reactor and can be removed when we are using the snapshot repository.

I don't like the structure of api, impl and commons. But this can only 
solved by sun.
> I have a few thoughts about the parent POM.  Couldn't we move most of
> the stuff that is inheritable to build/pom.xml?  My thinking is that
> you can do without the mailing lists, etc. in your sites if you are
> just building tomahawk (and only tomahawk) on your local machine (for
> some reason.)  Most of the global information in the parent POM seems
> to be related to the site.  Will a pom build if it cannot find the
> parent pom?  (Say you just checkout tomahawk ...)

The parent pom is fetched from the remote repository(snapshot) and 
installed in the local repository.
> Also, the versions should be defined at the subproject level.  So api,
> impl, commons, etc. all have their own versions defined.  The pom's
> underneath them (like tomahawk/tomahawk/pom.xml) can inherit from the
> subproject pom but they shouldn't inherit from the master pom.  I'm
> thinking the master pom (build/pom.xml) have a version like
> 1.0.0-FINAL or something like that.  We *never* change the version of
> the parent.  So as the versions of the subprojects change and get out
> of sync with each other (on purpose) and as we tag and branch, it
> doesn't matter.  The parent ref is always good.

If you never change the version of the parent you don't get any new 
information from the parent pom if has changed. (then you can delete the 
parent ref)

A version is only one line in the pom. Can we move this decision to a 
release. If we decide tomahawk has his own version I add a version line 
to the pom in tomahawk maybe I remove the parent ref (Then I have to 
copy the inherited information from the parent pom). This is very simple.

What i need is a discussion about reasonable artifact names and 
directory names

And we should talk about the process (updating the snapshots, nightly 
build and continuum)

And we should use the new site.

> One implication is that if we go back in time to generate the website
> for a tagged version it will show the current contributor list, etc. 
> I think that's perfectly fine but its an implication to be aware of. 
> This also seems to be an argument for *not* defining dependencies in
> the master pom.

I don't understand this

> Anyways, we need to get the unit tests back up and running and we need
> to sort out this parent pom business.  Any thoughts?

We don't need to sort out the parent pom's at this point.
We have to define processes.

> Sean
> [1]



View raw message