struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Mitchell <james.l.mitch...@mac.com>
Subject Re: [shale] Maven build update
Date Thu, 01 Sep 2005 21:01:38 GMT
One option that I (sort of) last time we chatted.

You should be able to make Maven happy without actually changing the  
Shale directories, you could do all of this in a separate directory  
structure.  This structure would have nothing in it besides the Maven  
build files.

Proposal:

   /shale
     /maven-build            <- new
        project.xml          <- parent pom
        project.properties   <- same

                 (in project.properties - this is the magic)
                 ...
                 maven.multiproject.jar.includes=jars/*/project.xml
                 maven.multiproject.war.includes=wars/*/project.xml
                 ...

        maven.xml            <- where the reactor kicks off the
                                multiproject:foo

        /jars    <- new (of course this could be named anything)
        /wars    <- new ('apps' or whatever)

          /core-library   <- new (NOTE - this is NOT the
                             directory with source code)

              project.xml    <- core pom (extends above),
                                but src points to
                                 "../../../core-library")

              project.properties



Basically what I'm getting at is a way to make everyone happy.  To  
keep the file structure the same, yet make maven's multiproject  
(maven:reactor) happy.

I've got to head out for about 2 hours, but when I get back, I'll  
show you what I mean....back in a little bit.


--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM:   jmitchtx
Yahoo: jmitchtx
MSN:   jmitchell@apache.org
Skype: callto://jmitchtx





On Sep 1, 2005, at 3:18 AM, Wendy Smoak wrote:

> 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
>
>


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


Mime
View raw message