Hi Bernd & all,
On Jan 10, 2006, at 6:38 PM, Bernd Bohmann wrote:
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.
It would be great to get rid of the build dir.
If I understand you correctly if the top level pom has been installed
in the snapshot repository then an 'mvn package' from any of the
modules would download the parent pom and just work. I like maven
more and more with each passing revelation ;-)
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.
Can we still get reactor type functionality without the pom that is
currently in build? I'm really concerned about getting Continuum
setup for the automated build so if we can get a good (IOW simple)
automated build setup then I'm all for droping build altogether.
I don't like the structure of api, impl and commons. But this can
only solved by sun.
Or the EG (i.e. Adam et al). Why don't you ping them to join and
fight the good fight :-)
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)
None of this matters if we nuke the build/pom.xml right?
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
I posted a first cut earlier - I'll repost under a new thread.
And we should talk about the process (updating the snapshots,
nightly build and continuum)
Agreed - do you have the bandwidth to write up a proposal now? If not
I can take a crack tomorrow.
And we should use the new site.
Agreed, does any one have a link crawler to at least make sure our
links are all valid before we push?
TTFN,
-bd-
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] http://wiki.apache.org/myfaces/Maven2_Migration
Regards
Bernd
