You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Sean Schofield <se...@gmail.com> on 2006/01/10 22:18:01 UTC
Maven Update - More Questions
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.)
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?
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.
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 ...)
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.
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.
Anyways, we need to get the unit tests back up and running and we need
to sort out this parent pom business. Any thoughts?
Sean
[1] http://wiki.apache.org/myfaces/Maven2_Migration
Re: Maven Update - More Questions
Posted by Bernd Bohmann <be...@atanion.com>.
Please replace MessageUtilsTest with the attached file or try to apply
the patch or change MockFacesContext to FacesContext in MessageUtilsTest
Bernd
Sean Schofield schrieb:
> MessageUtilsTest fails b/c it cannot find MockFacesContext. I have
> already renamed one of the files for you in svn. I will commit the
> rest for you tomorrow when you send me the file. Then you should be
> able to commit your own stuff once Manfred grants you the karma!
>
> Sean
>
> ps. Thanks for all of this great Maven work!
>
> On 1/11/06, Bernd Bohmann <be...@atanion.com> wrote:
>
>>I will send you my patches for fixing the tests first
>>
>>Please rename impl/src/test/java/org/apache/myfaces/el/TestBean.java
>>
>>to DummyBean.java
>>
>>see surefire-plugin documentation.
>>
>>Please delete StateUtilsTestCase and add StateUtilsAbstractCase
>>or rename StateUtilsTestCase to StateUtilsAbstractCase and replace it
>>with the attached file.
>>
>>I'm not sure that I send you all required patches.
>>
>>Please test it.
>>
>>Tomorrow I will send you the patches for the tlddoc(and the assembly
>>stuff). Preparing the patches takes some more time :-(
>>
>>Best Regards
>>
>>Bernd
>>
>>Sean Schofield schrieb:
>>
>>>That's great! Do you have a patch for me?
>>>
>>>Sean
>>>
>>>On 1/11/06, Bernd Bohmann <be...@atanion.com> wrote:
>>>
>>>
>>>>Hello Sean,
>>>>
>>>>I have deployed the site with javadoc and tlddoc on
>>>>http://people.apache.org/~bommel/
>>>>
>>>>You find the tlddoc report under 'Project Reports' on the site of the
>>>>project pages.
>>>>
>>>>Regards
>>>>
>>>>
>>>>Bernd
>>>>
>>>>Bernd Bohmann schrieb:
>>>>
>>>>
>>>>>Hello Sean
>>>>>
>>>>>I fixed the other tests except two test cases.
>>>>>Should I open an issue or send you the patches?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>OK this is fixed. I thought it sounded familiar and it was. I had
>>>>>>already fixed one issue with MessageUtilsTest by copying the
>>>>>>Message.properties over to a new test/resources dir. It turns out
>>>>>>that the rest of the properties are needed as well so I copied them
>>>>>>over too.
>>>>>>
>>>>>
>>>>>Is a copy of properties a good idea or should the properties moved to
>>>>>commons/src/main/resources ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Sean
>>>>>>
>>>>>
>>>>>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
>>>>
>>>
>>>
>>--
>>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
>>
>>
>>
>
>
--
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: Maven Update - More Questions
Posted by Sean Schofield <se...@gmail.com>.
MessageUtilsTest fails b/c it cannot find MockFacesContext. I have
already renamed one of the files for you in svn. I will commit the
rest for you tomorrow when you send me the file. Then you should be
able to commit your own stuff once Manfred grants you the karma!
Sean
ps. Thanks for all of this great Maven work!
On 1/11/06, Bernd Bohmann <be...@atanion.com> wrote:
> I will send you my patches for fixing the tests first
>
> Please rename impl/src/test/java/org/apache/myfaces/el/TestBean.java
>
> to DummyBean.java
>
> see surefire-plugin documentation.
>
> Please delete StateUtilsTestCase and add StateUtilsAbstractCase
> or rename StateUtilsTestCase to StateUtilsAbstractCase and replace it
> with the attached file.
>
> I'm not sure that I send you all required patches.
>
> Please test it.
>
> Tomorrow I will send you the patches for the tlddoc(and the assembly
> stuff). Preparing the patches takes some more time :-(
>
> Best Regards
>
> Bernd
>
> Sean Schofield schrieb:
> > That's great! Do you have a patch for me?
> >
> > Sean
> >
> > On 1/11/06, Bernd Bohmann <be...@atanion.com> wrote:
> >
> >>Hello Sean,
> >>
> >>I have deployed the site with javadoc and tlddoc on
> >>http://people.apache.org/~bommel/
> >>
> >>You find the tlddoc report under 'Project Reports' on the site of the
> >>project pages.
> >>
> >>Regards
> >>
> >>
> >>Bernd
> >>
> >>Bernd Bohmann schrieb:
> >>
> >>>Hello Sean
> >>>
> >>>I fixed the other tests except two test cases.
> >>>Should I open an issue or send you the patches?
> >>>
> >>>
> >>>
> >>>>OK this is fixed. I thought it sounded familiar and it was. I had
> >>>>already fixed one issue with MessageUtilsTest by copying the
> >>>>Message.properties over to a new test/resources dir. It turns out
> >>>>that the rest of the properties are needed as well so I copied them
> >>>>over too.
> >>>>
> >>>
> >>>Is a copy of properties a good idea or should the properties moved to
> >>>commons/src/main/resources ?
> >>>
> >>>
> >>>
> >>>>Sean
> >>>>
> >>>
> >>>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
> >>
> >
> >
>
> --
> 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: Maven Update - More Questions
Posted by Bernd Bohmann <be...@atanion.com>.
I will send you my patches for fixing the tests first
Please rename impl/src/test/java/org/apache/myfaces/el/TestBean.java
to DummyBean.java
see surefire-plugin documentation.
Please delete StateUtilsTestCase and add StateUtilsAbstractCase
or rename StateUtilsTestCase to StateUtilsAbstractCase and replace it
with the attached file.
I'm not sure that I send you all required patches.
Please test it.
Tomorrow I will send you the patches for the tlddoc(and the assembly
stuff). Preparing the patches takes some more time :-(
Best Regards
Bernd
Sean Schofield schrieb:
> That's great! Do you have a patch for me?
>
> Sean
>
> On 1/11/06, Bernd Bohmann <be...@atanion.com> wrote:
>
>>Hello Sean,
>>
>>I have deployed the site with javadoc and tlddoc on
>>http://people.apache.org/~bommel/
>>
>>You find the tlddoc report under 'Project Reports' on the site of the
>>project pages.
>>
>>Regards
>>
>>
>>Bernd
>>
>>Bernd Bohmann schrieb:
>>
>>>Hello Sean
>>>
>>>I fixed the other tests except two test cases.
>>>Should I open an issue or send you the patches?
>>>
>>>
>>>
>>>>OK this is fixed. I thought it sounded familiar and it was. I had
>>>>already fixed one issue with MessageUtilsTest by copying the
>>>>Message.properties over to a new test/resources dir. It turns out
>>>>that the rest of the properties are needed as well so I copied them
>>>>over too.
>>>>
>>>
>>>Is a copy of properties a good idea or should the properties moved to
>>>commons/src/main/resources ?
>>>
>>>
>>>
>>>>Sean
>>>>
>>>
>>>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
>>
>
>
--
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: Maven Update - More Questions
Posted by Sean Schofield <se...@gmail.com>.
That's great! Do you have a patch for me?
Sean
On 1/11/06, Bernd Bohmann <be...@atanion.com> wrote:
> Hello Sean,
>
> I have deployed the site with javadoc and tlddoc on
> http://people.apache.org/~bommel/
>
> You find the tlddoc report under 'Project Reports' on the site of the
> project pages.
>
> Regards
>
>
> Bernd
>
> Bernd Bohmann schrieb:
> > Hello Sean
> >
> > I fixed the other tests except two test cases.
> > Should I open an issue or send you the patches?
> >
> >
> >> OK this is fixed. I thought it sounded familiar and it was. I had
> >> already fixed one issue with MessageUtilsTest by copying the
> >> Message.properties over to a new test/resources dir. It turns out
> >> that the rest of the properties are needed as well so I copied them
> >> over too.
> >>
> > Is a copy of properties a good idea or should the properties moved to
> > commons/src/main/resources ?
> >
> >
> >> Sean
> >>
> >
> > 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: Maven Update - More Questions
Posted by Bernd Bohmann <be...@atanion.com>.
Hello Sean,
I have deployed the site with javadoc and tlddoc on
http://people.apache.org/~bommel/
You find the tlddoc report under 'Project Reports' on the site of the
project pages.
Regards
Bernd
Bernd Bohmann schrieb:
> Hello Sean
>
> I fixed the other tests except two test cases.
> Should I open an issue or send you the patches?
>
>
>> OK this is fixed. I thought it sounded familiar and it was. I had
>> already fixed one issue with MessageUtilsTest by copying the
>> Message.properties over to a new test/resources dir. It turns out
>> that the rest of the properties are needed as well so I copied them
>> over too.
>>
> Is a copy of properties a good idea or should the properties moved to
> commons/src/main/resources ?
>
>
>> Sean
>>
>
> 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: Maven Update - More Questions
Posted by Sean Schofield <se...@gmail.com>.
Hmmm. Maybe you are right that they should be moved.
Sean
On 1/11/06, Bernd Bohmann <be...@atanion.com> wrote:
> Hello Sean
>
> I fixed the other tests except two test cases.
> Should I open an issue or send you the patches?
>
>
> > OK this is fixed. I thought it sounded familiar and it was. I had
> > already fixed one issue with MessageUtilsTest by copying the
> > Message.properties over to a new test/resources dir. It turns out
> > that the rest of the properties are needed as well so I copied them
> > over too.
> >
> Is a copy of properties a good idea or should the properties moved to
> commons/src/main/resources ?
>
>
> > Sean
> >
>
> Regards
>
> Bernd
>
>
Re: Maven Update - More Questions
Posted by Bernd Bohmann <be...@atanion.com>.
Hello Sean
I fixed the other tests except two test cases.
Should I open an issue or send you the patches?
> OK this is fixed. I thought it sounded familiar and it was. I had
> already fixed one issue with MessageUtilsTest by copying the
> Message.properties over to a new test/resources dir. It turns out
> that the rest of the properties are needed as well so I copied them
> over too.
>
Is a copy of properties a good idea or should the properties moved to
commons/src/main/resources ?
> Sean
>
Regards
Bernd
Re: Maven Update - More Questions
Posted by Sean Schofield <se...@gmail.com>.
> > 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?
>
> I volunteer for this one.
OK this is fixed. I thought it sounded familiar and it was. I had
already fixed one issue with MessageUtilsTest by copying the
Message.properties over to a new test/resources dir. It turns out
that the rest of the properties are needed as well so I copied them
over too.
Sean
Re: Maven Update - More Questions
Posted by Sean Schofield <se...@gmail.com>.
> 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.
How do you build everything at once? Are you saying you just build
the projects you need one at a time?
> 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.
I added a todo item to the wiki. Does someone want to volunteer?
> 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?
I volunteer for this one.
> 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.
OK so you're saying the only reason for the build POM is to update the
reactor so that the dependencies for a module (ex. tomahawk) are
available to the tomahawk build.
> The parent pom is fetched from the remote repository(snapshot) and
> installed in the local repository.
Interesting. I guess that could be better the build/pom.xml. Is
Maven capable of downloading a parent pom from a snapshot repository?
We would move the "common" parent stuff out of api/pom.xml and into
this new parent pom right?
How do we make a pom an artifact in Maven? Don't we still need a dir
(like build) to store it? Is there another pom to publish the parent
pom?
> 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)
How are snapshot versions handled in m2? Ideally it would check the
snapshot repository and use the newer snapshot if it is more recent
then the one in your local repository. I'm still confused as to how
snapshots work. Maybe someone could give me a good explanation. I
find the maven site to have very little documentation on this,
especially for maven2.
> 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.
Yes. Lots more to discuss here.
> Bernd
Sean
Re: Maven Update - More Questions
Posted by Sean Schofield <se...@gmail.com>.
> Agreed, does any one have a link crawler to at least make sure our
> links are all valid before we push?
IMO we are a little ways off from moving to the new website. We have
a lot more tweaks to do there and we have things like the TLD doc that
are missing.
If we are going to use a snapshot for the parent pom. Lets get that
subproject up and working. (@Bernd: Woudl this go in the "tools" dir
you were proposing earlier?)
> -bd-
Sean
Re: Maven Update - More Questions
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/10/06, Bill Dudney <bd...@mac.com> wrote:
> Can we still get reactor type functionality without the pom that is
> currently in build?
That's my question as well.
--
Wendy
Re: Maven Update - More Questions
Posted by Bill Dudney <bd...@mac.com>.
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
Re: Maven Update - More Questions
Posted by Bernd Bohmann <be...@atanion.com>.
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] http://wiki.apache.org/myfaces/Maven2_Migration
>
Regards
Bernd