struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wendy Smoak" <j...@wendysmoak.com>
Subject [shale] Maven build update
Date Thu, 01 Sep 2005 07:18:19 GMT
Shale's Maven build has been reworked to use inheritance and a single
property (with a default value) to choose between the JSF implementations.

     http://www.mail-archive.com/dev%40struts.apache.org/msg11576.html

I had already added 'myfaces-project.xml' just to make it easy to download
the necessary .jar files, and that combined with a suggestion from
maven-user to use a property in the <extend> tag turns out to be the
cleanest solution I've found so far.  To build it:

     $ maven build-all -Dmaven.shale.jsf.impl=myfaces
or
     $ maven build-all -Dmaven.shale.jsf.impl=jsfri

If you leave off the property, right now it will default to MyFaces.  That
can be changed in project.properties, I picked it because it's freely
available on ibiblio.

The easiest way to convince yourself it works is to do 'maven site' with the
property set each way, and check target/docs/dependencies.html to see what's
in the list.  The WEB-INF/lib directory for the use cases app will also
contain the correct .jar files.

What is not working is the script in use-cases/maven.xml to conditionally
comment out the MyFaces listener in web.xml -- I want to take another look
at it after I get some sleep... maybe it's just a simple typo. :)  I haven't
been able to find many resources on Jelly and am just guessing based on JSTL
and some JIRA tickets against various Maven plugins.

Remaining issues are:
 - core-library builds a single artifact (no shale-tiles or shale-spring
.jar files)
 - the tests are skipped in core-library due to the circular dependency with
test-framework.

If we agree that Maven can handle the JSF-RI-or-MyFaces requirements, then
the next step is to decide whether to keep the existing project structure,
which will require some ugly scripting to get around the two issues listed
above, or do a little rearranging to separate out the code for the different
artifacts so that Maven can build them without intervention.

Borrowing heavily (as usual!) from James' recent work on the Struts Ti
build, and the existing Struts build...

/shale
     /core-library
     /core-test
     /spring
     /tiles
     /clay-plugin
     /usecases
     /mailreader
     /blank
     /test-framework

- I think use-cases, mailreader, and blank could go under an 'apps'
directory, but that's not a requirement.

- I'm not sure what Maven is going to think of 'core-test' since it has no 
source code, only unit tests, but I'm not sure where else to put them.

Thoughts?

-- 
Wendy



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message