geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <goyathlay.geron...@gmail.com>
Subject Re: Removing the custom packaging "integration-test"
Date Fri, 03 Nov 2006 03:08:01 GMT
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 <jason@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 <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