Sean,
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 ;)
regards,
Martin
On 1/3/06, Sean Schofield <[EMAIL PROTECTED]> 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 www.atanion.com/maven2 as snapshot plugin repository
>
> OK as a temporary solution. Eventually we should figure out the best
> mechanism for hosting our plugins on myfaces.apache.org.
>
> > 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
> > http://jira.codehaus.org/browse/MOJO-203).
> > 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
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
