Luther,

I think you are hitting a development environment issue.  Does this just not
work for developing in the IDE?  In other words, if you use "mvn clean
compile package" to generate a war file, verify that the war file contains
everything it should, and then deploy that war file to tomcat or jetty or
whatever, does it work?

How are you launching your server? If using eclipse, have you added
src/main/resources as a source directory?

I put all .tml files under src/main/resources and everything works great.
Maven, by default, if you are building a war, will copy all of those files
alongside the .class files resulting from compiling the src/main/java tree.

I initially found putting files there (rather than in webapp) cumbersome,
but it feels like the correct place.

Jonathan



> -----Original Message-----
> From: Luther Baker [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 05, 2008 11:30
> To: Tapestry users
> Subject: Re: AW: Advantages of various .tml storage locations?
> 
> Assuming this:
> 
> src/main/java/*com/X/app*/pages/Home.java
> 
> 
> This doesn't work for me:
> 
> src/main/resources/*com/X/app*/pages/Home.tml
> 
> 
> Wherease, this works just fine:
> 
> src/main/webapp/Home.tml
> 
> 
> Do I need to do something special to drop my pages in the resources dir or
> does this just work and I am overlooking something.
> 
> Thanks,
> 
> -Luther
> 
> 
> 
> On Fri, Dec 5, 2008 at 10:05 AM, Christian Edward Gruber <
> [EMAIL PROTECTED]> wrote:
> 
> > It's not a fix, it's a design.  Code goes in /src/main/java. Resources
> go
> > in /src/main/resources.  It's part of having a place for everything, and
> > everything in its place.
> >
> > You could hack it by a custom execution of the resources plugin pointing
> to
> > your "alternative resources location" (ie, src/main/java) but this isn't
> > something that needs a solution - it's how the tool works.
> >
> > Actually, i think you could set the resources location to src/main/java
> > anyway... one sec...
> >
> > Yep.
> >
> > Use the <build><resources>...</resources></build> section of the pom to
> > point at resources in /src/main/java.  eg:
> >
> > <resources>
> >        <resource>
> >                <targetPath>/</targetPath>
> >                <filtering>true</filtering>
> >                <directory>${basedir}/src/main/java</directory>
> >                <includes> <include>**/*.tml</include> </includes>
> >        </resource>
> > </resources>
> > This should pick up .tml files in /src/main/java.  Not maven best
> practice,
> > but if it works for you, have fun.  I still expect it will only work for
> > components, not pages.  Howard?  True?
> >
> > Christian.
> >
> >
> > On 5-Dec-08, at 06:05 , Maximilian Weißböck wrote:
> >
> >  I would much prefer solution number 1. as it keeps things
> >> on the same place that belong together.
> >>
> >> Sadly maven build does not work with this solution.
> >> Is there any maven guru how knows how to "fix" this?
> >>
> >> Thanks, Max
> >>
> >>  -----Ursprüngliche Nachricht-----
> >>> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von
> James
> >>> Hillyerd
> >>> Gesendet: Donnerstag, 4. Dezember 2008 23:06
> >>> An: Tapestry users
> >>> Betreff: Advantages of various .tml storage locations?
> >>>
> >>> What are the pros/cons of keeping page .tml in:
> >>>
> >>> 1. src/main/java
> >>>
> >>>  vs
> >>>
> >>> 2. src/main/resources
> >>>
> >>>  vs
> >>>
> >>> 3. src/main/webapp
> >>>
> >>> ?
> >>>
> >>>
> >>> I see JumpStart uses #1, and the tutorial uses #3.  Seems like it
> would
> >>> easier to use #1 or #2 so at least the components and pages .tml are
> in
> >>> the
> >>> same directory tree.
> >>>
> >>> Thanks.
> >>>
> >>> -james
> >>>
> >>> --
> >>> James A. Hillyerd <[EMAIL PROTECTED]>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to