geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Removing the custom packaging "integration-test"
Date Fri, 03 Nov 2006 02:45:31 GMT
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 <jason@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
>>
>>
>>


Mime
View raw message