struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: [shale] Maven 2 build -- Help Wanted
Date Sat, 03 Jun 2006 18:10:07 GMT
On 6/1/06, Wendy Smoak <> wrote:
> On 6/1/06, James Mitchell <> wrote:
> > Ok, so I had some time this morning to help.
> >
> > I started looking at the apps to see what I could do to get them up
> > to "Maven2" par.  I created a struts-shale-apps-parent (pom.xml under
> > apps/) and added it as a module of struts-shale-parent.  I then
> > created struts-shale-apps-sql-browser (pom.xml under apps/sql-
> > browser) and that almost works fine.
> >
> > With respect to 1.4 vs 1.5 for compilation, I'm not sure what all is
> > going on with profile/activation inheritance and all, but even with
> > this:
> Thanks. :)  The 1.5 profile should be automatically activated if
> you're compiling with JDK 1.5.  You shouldn't have to put anything on
> the command line.  Is that not working?
>         <profile>
>             <activation>
>                 <jdk>1.5</jdk>       <-----
>             </activation>
>             <modules>
>                 <module>tiger</module>
>             </modules>
>         </profile>
> --
> Wendy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Updated status -- we now can successfully compile all of the following
modules using the new Maven build:

  shale-clay, shale-core, shale-remoting, shale-spring, shale-tiles,
shale-tiger, shale-test

However, the following modules still have unit test failures:

 * shale-clay:  It looks like the component definitions for the standard JSF
  are not getting recognized.  Gary, could you take a look at these?

* shale-tiger:  The ant version of the tests builds a mock web application
  structure under "target/test-webapp" that is used to exercise the
configuration loading
  classes.  It doesn't look like we can emulate this by simply copying
resources, because
  it assembles some things out of compiled classes.  Is there a plugin where
we can
  escape out to an actual Ant script when the tests are compiled?  If so, it
would be
  pretty easy to copy just the "test:webapp" target stuff from the original
build.  The POM
  will also need to pass the "basedir" property, if it doesn't already.

I'll be working out the details on the last remaining top-level module
(shale-designtime) late this evening.  In the mean time, I'm going to
comment it out of the parent POM because this module will always require
some special processes at build time, and is not required for anything
else.  That will allow us to start hacking on the Shale sample apps once the
test failure issues above are addressed.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message