You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Prasad Kashyap <go...@gmail.com> on 2006/11/02 22:37:26 UTC
Removing the custom packaging "integration-test"
I am going to remove the "integration-test" packaging that we
introduced for the testsuite framework. By having that custom
packaging, we are seeing the following problems
1) running the site goal on that pom
http://www.nabble.com/Are-these-errors-due-to-changes-in-genesis-logging---tf2562523.html
2) generating surefire-reports.html
http://www.nabble.com/HELP%3A-Running-site-goal-on-a-cutom-packaging-tf2539516s177.html#a7122304
This is what I propose we do.
* Go back to the "jar" packaging.
* Configure surefire-plugin to skip tests in the "test" phase and run
tests in the "integration-test" phase.
This will help us achieve our goals. This will also help us move
smoothly to the maven-it-plugin once it comes out of the sandbox.
If I'm missing something else here, please enlighten me.
Cheers
Prasad
Re: Removing the custom packaging "integration-test"
Posted by Prasad Kashyap <go...@gmail.com>.
Thank you for that clarification, Jason. I misread that to mean change
the packaging "definition". Now I see what you meant.
Thanx again
Cheers
Prasad
On 11/2/06, Jason Dillon <ja...@planet57.com> wrote:
> I did not say don't change the packaging, but do not remove the
> components for the packaging in plugin-support... which is what is
> implied by 'Removing the custom packaging "integration-test"'.
>
> I still do not believe that it is worth trying to hack up the build
> to get `mvn site` to function in this case though. Re-using
> surefire's reports was a temporary solution to reporting and as it
> seems is non-trivial to fit into Maven's limited default abilities...
> and its extensibility is severely limited in many cases which prevent
> us from configuring it to produce the desired results.
>
> But feel free to change it so that it works for you, and maybe later
> we can apply a better solution.
>
> --jason
>
>
> On Nov 2, 2006, at 6:14 PM, Prasad Kashyap wrote:
>
> > Hmmm..
> >
> > The surefire-report-plugin executes only in the "test" phase. Since we
> > are skipping it in our custom packaging, it never gets exeucted. So
> > any other packaging we do will have the same problem unless we
> > introduce the 'test' phase.
> >
> > Now, I did hardcode the surefire-report to some other phase. It
> > executes fine and generates the surefire-report.html but that html is
> > not integrated with the other reports after a 'mvn site' is run.
> >
> > Now if we go back to the 'jar' packaging, we can configure the
> > surefire-plugin as described above just once in the top level pom.xml
> > (geronimo/testsuite/pom.xml). I don't see how we will have any more
> > xml in our poms than the # of lines we have for the custom packaging
> > definition in the components.xml. BTW, cargo too is doing the same
> > thing for their integration-test.
> >
> > If you insist that we keep the packaging, then I propose that we
> > introduce a 'test' phase in it during which the surefire-report will
> > execute during the 'mvn site' goal. If we did that, we'd still have to
> > configure the surefire-plugin to skip the tests during the 'test'
> > phase. It kinda defeats the very purpose of creating the custom
> > packaging (removing test phase) but we get to keep it and still
> > generate the surefire-reports.
> >
> > Cheers
> > Prasad
> >
> >
> >
> > On 11/2/06, Jason Dillon <ja...@planet57.com> wrote:
> >> On Nov 2, 2006, at 1:37 PM, Prasad Kashyap wrote:
> >>
> >> > I am going to remove the "integration-test" packaging that we
> >> > introduced for the testsuite framework. By having that custom
> >> > packaging, we are seeing the following problems
> >>
> >> Do not remove the packaging, if you feel that you need to use a
> >> different packaging to hack around Maven problems, then go for it...
> >> but leave the packaging.
> >>
> >>
> >> > 1) running the site goal on that pom
> >> > http://www.nabble.com/Are-these-errors-due-to-changes-in-genesis-
> >> > logging---tf2562523.html
> >> >
> >> > 2) generating surefire-reports.html
> >> > http://www.nabble.com/HELP%3A-Running-site-goal-on-a-cutom-
> >> > packaging-tf2539516s177.html#a7122304
> >> >
> >> > This is what I propose we do.
> >> >
> >> > * Go back to the "jar" packaging.
> >> > * Configure surefire-plugin to skip tests in the "test" phase
> >> and run
> >> > tests in the "integration-test" phase.
> >> >
> >> > This will help us achieve our goals. This will also help us move
> >> > smoothly to the maven-it-plugin once it comes out of the sandbox.
> >> >
> >> > If I'm missing something else here, please enlighten me.
> >>
> >> I think we are spending way to muck effort here to get `mvn site` to
> >> work out of the box. Its probably easier to just make a new profile
> >> for the testsuite modules which hooks up modules per-the normal
> >> mechanism and then hardcode the surefire report to execute.
> >>
> >> Maven is broke in many ways... and we are pushing its limits... and
> >> anything we do is hacking around Maven problems. But we don't want
> >> to revert to a gross hack which will quickly become
> >> unmaintainable... and IMO by removing the custom packaging we will
> >> end up with a lot more xml in our poms to hack this together... which
> >> IMO is not the right direction.
> >>
> >> --jason
> >>
> >>
> >>
>
>
Re: Removing the custom packaging "integration-test"
Posted by Jason Dillon <ja...@planet57.com>.
I did not say don't change the packaging, but do not remove the
components for the packaging in plugin-support... which is what is
implied by 'Removing the custom packaging "integration-test"'.
I still do not believe that it is worth trying to hack up the build
to get `mvn site` to function in this case though. Re-using
surefire's reports was a temporary solution to reporting and as it
seems is non-trivial to fit into Maven's limited default abilities...
and its extensibility is severely limited in many cases which prevent
us from configuring it to produce the desired results.
But feel free to change it so that it works for you, and maybe later
we can apply a better solution.
--jason
On Nov 2, 2006, at 6:14 PM, Prasad Kashyap wrote:
> Hmmm..
>
> The surefire-report-plugin executes only in the "test" phase. Since we
> are skipping it in our custom packaging, it never gets exeucted. So
> any other packaging we do will have the same problem unless we
> introduce the 'test' phase.
>
> Now, I did hardcode the surefire-report to some other phase. It
> executes fine and generates the surefire-report.html but that html is
> not integrated with the other reports after a 'mvn site' is run.
>
> Now if we go back to the 'jar' packaging, we can configure the
> surefire-plugin as described above just once in the top level pom.xml
> (geronimo/testsuite/pom.xml). I don't see how we will have any more
> xml in our poms than the # of lines we have for the custom packaging
> definition in the components.xml. BTW, cargo too is doing the same
> thing for their integration-test.
>
> If you insist that we keep the packaging, then I propose that we
> introduce a 'test' phase in it during which the surefire-report will
> execute during the 'mvn site' goal. If we did that, we'd still have to
> configure the surefire-plugin to skip the tests during the 'test'
> phase. It kinda defeats the very purpose of creating the custom
> packaging (removing test phase) but we get to keep it and still
> generate the surefire-reports.
>
> Cheers
> Prasad
>
>
>
> On 11/2/06, Jason Dillon <ja...@planet57.com> wrote:
>> On Nov 2, 2006, at 1:37 PM, Prasad Kashyap wrote:
>>
>> > I am going to remove the "integration-test" packaging that we
>> > introduced for the testsuite framework. By having that custom
>> > packaging, we are seeing the following problems
>>
>> Do not remove the packaging, if you feel that you need to use a
>> different packaging to hack around Maven problems, then go for it...
>> but leave the packaging.
>>
>>
>> > 1) running the site goal on that pom
>> > http://www.nabble.com/Are-these-errors-due-to-changes-in-genesis-
>> > logging---tf2562523.html
>> >
>> > 2) generating surefire-reports.html
>> > http://www.nabble.com/HELP%3A-Running-site-goal-on-a-cutom-
>> > packaging-tf2539516s177.html#a7122304
>> >
>> > This is what I propose we do.
>> >
>> > * Go back to the "jar" packaging.
>> > * Configure surefire-plugin to skip tests in the "test" phase
>> and run
>> > tests in the "integration-test" phase.
>> >
>> > This will help us achieve our goals. This will also help us move
>> > smoothly to the maven-it-plugin once it comes out of the sandbox.
>> >
>> > If I'm missing something else here, please enlighten me.
>>
>> I think we are spending way to muck effort here to get `mvn site` to
>> work out of the box. Its probably easier to just make a new profile
>> for the testsuite modules which hooks up modules per-the normal
>> mechanism and then hardcode the surefire report to execute.
>>
>> Maven is broke in many ways... and we are pushing its limits... and
>> anything we do is hacking around Maven problems. But we don't want
>> to revert to a gross hack which will quickly become
>> unmaintainable... and IMO by removing the custom packaging we will
>> end up with a lot more xml in our poms to hack this together... which
>> IMO is not the right direction.
>>
>> --jason
>>
>>
>>
Re: Removing the custom packaging "integration-test"
Posted by Prasad Kashyap <go...@gmail.com>.
Hmmm..
The surefire-report-plugin executes only in the "test" phase. Since we
are skipping it in our custom packaging, it never gets exeucted. So
any other packaging we do will have the same problem unless we
introduce the 'test' phase.
Now, I did hardcode the surefire-report to some other phase. It
executes fine and generates the surefire-report.html but that html is
not integrated with the other reports after a 'mvn site' is run.
Now if we go back to the 'jar' packaging, we can configure the
surefire-plugin as described above just once in the top level pom.xml
(geronimo/testsuite/pom.xml). I don't see how we will have any more
xml in our poms than the # of lines we have for the custom packaging
definition in the components.xml. BTW, cargo too is doing the same
thing for their integration-test.
If you insist that we keep the packaging, then I propose that we
introduce a 'test' phase in it during which the surefire-report will
execute during the 'mvn site' goal. If we did that, we'd still have to
configure the surefire-plugin to skip the tests during the 'test'
phase. It kinda defeats the very purpose of creating the custom
packaging (removing test phase) but we get to keep it and still
generate the surefire-reports.
Cheers
Prasad
On 11/2/06, Jason Dillon <ja...@planet57.com> wrote:
> On Nov 2, 2006, at 1:37 PM, Prasad Kashyap wrote:
>
> > I am going to remove the "integration-test" packaging that we
> > introduced for the testsuite framework. By having that custom
> > packaging, we are seeing the following problems
>
> Do not remove the packaging, if you feel that you need to use a
> different packaging to hack around Maven problems, then go for it...
> but leave the packaging.
>
>
> > 1) running the site goal on that pom
> > http://www.nabble.com/Are-these-errors-due-to-changes-in-genesis-
> > logging---tf2562523.html
> >
> > 2) generating surefire-reports.html
> > http://www.nabble.com/HELP%3A-Running-site-goal-on-a-cutom-
> > packaging-tf2539516s177.html#a7122304
> >
> > This is what I propose we do.
> >
> > * Go back to the "jar" packaging.
> > * Configure surefire-plugin to skip tests in the "test" phase and run
> > tests in the "integration-test" phase.
> >
> > This will help us achieve our goals. This will also help us move
> > smoothly to the maven-it-plugin once it comes out of the sandbox.
> >
> > If I'm missing something else here, please enlighten me.
>
> I think we are spending way to muck effort here to get `mvn site` to
> work out of the box. Its probably easier to just make a new profile
> for the testsuite modules which hooks up modules per-the normal
> mechanism and then hardcode the surefire report to execute.
>
> Maven is broke in many ways... and we are pushing its limits... and
> anything we do is hacking around Maven problems. But we don't want
> to revert to a gross hack which will quickly become
> unmaintainable... and IMO by removing the custom packaging we will
> end up with a lot more xml in our poms to hack this together... which
> IMO is not the right direction.
>
> --jason
>
>
>
Re: Removing the custom packaging "integration-test"
Posted by Jason Dillon <ja...@planet57.com>.
On Nov 2, 2006, at 1:37 PM, Prasad Kashyap wrote:
> I am going to remove the "integration-test" packaging that we
> introduced for the testsuite framework. By having that custom
> packaging, we are seeing the following problems
Do not remove the packaging, if you feel that you need to use a
different packaging to hack around Maven problems, then go for it...
but leave the packaging.
> 1) running the site goal on that pom
> http://www.nabble.com/Are-these-errors-due-to-changes-in-genesis-
> logging---tf2562523.html
>
> 2) generating surefire-reports.html
> http://www.nabble.com/HELP%3A-Running-site-goal-on-a-cutom-
> packaging-tf2539516s177.html#a7122304
>
> This is what I propose we do.
>
> * Go back to the "jar" packaging.
> * Configure surefire-plugin to skip tests in the "test" phase and run
> tests in the "integration-test" phase.
>
> This will help us achieve our goals. This will also help us move
> smoothly to the maven-it-plugin once it comes out of the sandbox.
>
> If I'm missing something else here, please enlighten me.
I think we are spending way to muck effort here to get `mvn site` to
work out of the box. Its probably easier to just make a new profile
for the testsuite modules which hooks up modules per-the normal
mechanism and then hardcode the surefire report to execute.
Maven is broke in many ways... and we are pushing its limits... and
anything we do is hacking around Maven problems. But we don't want
to revert to a gross hack which will quickly become
unmaintainable... and IMO by removing the custom packaging we will
end up with a lot more xml in our poms to hack this together... which
IMO is not the right direction.
--jason