On 6/1/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
On 6/1/06, James Mitchell <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
components
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
directory
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.
Craig
