myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <>
Subject Re: Maven Build (Ongoing Work Thread)
Date Tue, 03 Jan 2006 16:12:24 GMT

I have tried to get the setup working with what Thomas proposed, and
it didn't work.

So there is no way to get the sandbox-examples up and running with
IntelliJ, except with having normal resources (aka belong to one
module alone) separated from the faces-config.xml file.

Tobagos, you are using IntelliJ as well. Do you guys have a
workaround? Do me a favor and try to setup the sandbox-examples with a
module-based structure and tell me that there is one ;)



On 1/3/06, Sean Schofield <> wrote:
> > Hello,
> >
> > please apply this patch to the pom in the build directory to simplfy the
> > build process.
> > Changes:
> > Added default goal
> Good idea
> > Removed tabs
> Sorry.  My fault.  I used UltraEdit instead of my IDE and the setting
> weren't right.
> > Added as snapshot plugin repository
> OK as a temporary solution.  Eventually we should figure out the best
> mechanism for hosting our plugins on
> > Changed list to List in mailingLists
> +1
> > Changed finalname to myfaces-${version}
> Good idea.  I assume this means the version will be inherited from the
> pom?  I have been reading up on the filtering stuff as well.  I think
> we can stop hard coding the versions in the example webapps and use a
> message bundle with ${pom.version}.
> > Skipped the tests until they are stable
> OK hopefully we get those fixed soon.
> >
> > With this patch the xslt-plugin is fetched from the atanion maven
> > repositry, you don't need to install the xslt-plugin to your local
> > repository manualy. I have deployed the xslt-plugin into the atanion
> > maven repository (with the patch for
> >
> > Some other comments on the maven build to improve the build:
> >
> > Please use as much as possible the ${version} instead of hardcoding the
> > version and remove the <version> tag if a parent pom exists(but not in
> > the parent description see tobago poms).
> So 1.1.2 is defined in only the parent POM?  What if you want to build
> tomahawk by itself (without the parent pom?)
> I think this is a tricky problem.  Also, if we ever release different
> version numbers for the subprojects won't this cause a problem?
> > Please move the assembly plugin configuration in the master pom to api
> > or impl otherwise every subproject try to call the assembly plugin.
> Maybe we could have a special module called 'deploy'?  That would have
> the nightly build, assembly and release stuff in it?  I think that
> might be better then picking an arbitrary module like api.  What do
> you think?
> > Can we removed the svn externals. With the maven build they are useless
> > for api, impl, commons, tomahawk, sandbox..
> What do you mean useless?  We did get rid of the externals for the
> build dir which used to be in every subproject.  The only externals
> now are for "current" and a few for the TLD entities.
> I'm +1 for getting rid of them if we can do the same thing a different
> way.  But I think having the "current" external is good and its
> becoming a psuedo-standard.  Other projects (including) Struts adopt
> the same approach and its nice to have.
> Keep in mind under each subproject we have trunk, branches and tags.
> Without an external you would get the entire repository if you checked
> out the top level!  That would definitely confuse/overwhelm users IMO.
> > It would be nice if the master pom is in the root directory of myfaces.
> Yes it would but that would mean no external ;-)  That is the tradeoff.
> > Some plugin (idea) are not working with the current structure.
> Can you elaborate?  Is this because of the master POM not being in the
> top level?
> > Any comments
> >
> > Best Regards
> >
> > Bernd
> Sean


Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

View raw message