You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Wendy Smoak <ja...@wendysmoak.com> on 2005/09/01 09:18:19 UTC
[shale] Maven build update
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
Re: [shale] Maven build update
Posted by Wendy Smoak <ja...@wendysmoak.com>.
Shale's Maven build has undergone yet another transformation. James' idea
of keeping all the build files in a separate directory worked beautifully,
it was just a matter of sorting out all the relative directory paths.
If you have time, please take a look at the shale/build/README.txt file,
(which lists a few remaining issues,) and try out 'maven' in shale/build.
When that finishes, you should have the five .jar files installed in your
local repository, and the shale-usecases.war file in build/use-cases/target.
I'm open to suggestions for additional goals, and of course, general
improvements. James, is there anything in Ti that I should adopt?
earlier, Craig wrote:
> I was talking about the other JAR files that MyFaces ships in its lib
> directory, like commons-el.jar and commons-codec-1.2.jar, which MyFaces
> needs but the RI doesn't.
I missed that... I've been comparing against the nightly builds which use
the RI. The usecases app must not do anything that makes MyFaces need those
libraries, though, because it works fine without them.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Maven build update
Posted by Craig McClanahan <cr...@gmail.com>.
On 9/8/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
>
> From: "Craig McClanahan" <cr...@gmail.com>
>
> > This one is likely to become a non-issue, now that MyFaces 1.0.10 is
> out.
> > My understanding is that the MyFaces folks are eliminating the
> requirement
> > for registering a listener explicity, which will mean that Shale can
> dump
> > this particular bit of bit-twiddling.
>
> There's no 1.0.10 release yet, but I'm working with the MyFaces 20050904
> nightly and the Listener is no longer required in web.xml.
>
> > We'll still have to deal with the fact that the external dependencies
> > differ between the RI and MyFaces versions, but that should be,
> > I hope, simpler to deal with.
>
> Are you talking about myfaces-extensions.jar here, or something else? That
> was renamed tomahawk.jar and is not necessary unless you want to use the
> extensions, (additional components?) which Shale does not.
I was talking about the other JAR files that MyFaces ships in its lib
directory, like commons-el.jar and commons-codec-1.2.jar, which MyFaces
needs but the RI doesn't. That doesn't matter for compiling (unless the app
wants to use one of those apis directly), but it matters when you are
assembling a war's WEB-INF/lib directory.
Craig
I have the Maven build working in a separate directory structure as James
> suggested, and can reproduce all of the artifacts from the Ant build.
> (Finally!) I just need to get it to see the xdocs for the website, which
> should be a property or two, and look again at the .zip/.tar.gz files in
> "dist" to see what it's putting in those. Then if all goes well I'll check
> in the changes this weekend.
>
> Maven2 promises to make things easier with "profiles" for different sets
> of
> dependencies, though I haven't had a chance to try it yet.
>
> --
> Wendy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [shale] Maven build update
Posted by Wendy Smoak <ja...@wendysmoak.com>.
From: "Craig McClanahan" <cr...@gmail.com>
> This one is likely to become a non-issue, now that MyFaces 1.0.10 is out.
> My understanding is that the MyFaces folks are eliminating the requirement
> for registering a listener explicity, which will mean that Shale can dump
> this particular bit of bit-twiddling.
There's no 1.0.10 release yet, but I'm working with the MyFaces 20050904
nightly and the Listener is no longer required in web.xml.
> We'll still have to deal with the fact that the external dependencies
> differ between the RI and MyFaces versions, but that should be,
> I hope, simpler to deal with.
Are you talking about myfaces-extensions.jar here, or something else? That
was renamed tomahawk.jar and is not necessary unless you want to use the
extensions, (additional components?) which Shale does not.
I have the Maven build working in a separate directory structure as James
suggested, and can reproduce all of the artifacts from the Ant build.
(Finally!) I just need to get it to see the xdocs for the website, which
should be a property or two, and look again at the .zip/.tar.gz files in
"dist" to see what it's putting in those. Then if all goes well I'll check
in the changes this weekend.
Maven2 promises to make things easier with "profiles" for different sets of
dependencies, though I haven't had a chance to try it yet.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Maven build update
Posted by Craig McClanahan <cr...@gmail.com>.
On 9/1/05, Wendy Smoak <ja...@wendysmoak.com> wrote:
>
>
> 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.
This one is likely to become a non-issue, now that MyFaces 1.0.10 is out. My
understanding is that the MyFaces folks are eliminating the requirement for
registering a listener explicity, which will mean that Shale can dump this
particular bit of bit-twiddling. We'll still have to deal with the fact that
the external dependencies differ between the RI and MyFaces versions, but
that should be, I hope, simpler to deal with.
Craig
Re: [shale] Maven build update
Posted by Wendy Smoak <ja...@wendysmoak.com>.
James Mitchell wrote:
> 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.
>
> 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.
This makes perfect sense... at least at this point, before I've actually
tried it. :) So, don't spend too much time on an example-- when I have a
chance I'll move the build files around, add the few new ones, and see what
happens.
(It also has interesting possibilities for "trying out" a Maven2 build,
because the files are completely separate.)
Thanks,
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Maven build update
Posted by James Mitchell <ja...@mac.com>.
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