Interesting problem. In many build environments, the rule is usually
that check-ins must be consistent, whole, build-able and testable. If
your designers can check in modified templates independently of the
java that will work with them, then the build process rules would be
violated.
Perhaps the designers need a separate repository that doesn't involve
builds. It would then be up to the developers to merge the templates
into the build-able repository?
On 20/06/2008, at 7:55 PM, Blower, Andy wrote:
Our web designers will be using a subversion repository directly
(although I've not figured out the processes yet..) so I think
having non-java in a resources sub-tree is very desirable.
Loom is a nice plugin, although it seems to open the tml's from my
classes directory and it's not very useful until this is fixed.
-----Original Message-----
From: Geoff Callender [mailto:[EMAIL PROTECTED]
Sent: 19 June 2008 22:43
To: Tapestry users
Subject: Re: Putting templates together with the java
Yeah I assumed we're doing it for the web designers, too, which is a
good reason. But perhaps the better alternative is simply to filter
out the java files as we copy the project to them?
On 20/06/2008, at 12:27 AM, Blower, Andy wrote:
I've always assumed (apart from being more correct in some vague
way) that the main practical reason is to keep the web designers
away from Java code - so they only see the templates, properties,
javascript & css.
Pure assumption on my part though.
-----Original Message-----
From: Geoff Callender [mailto:[EMAIL PROTECTED]
Sent: 19 June 2008 15:02
To: Tapestry users
Subject: Putting templates together with the java
Perhaps I've lost my mind, but I'm struggling to find a good reason
why we keep our templates and properties separate from our java
source. I find it causes nothing but pain having to incessantly
jump
between these disconnected parts of the source tree. Is it purely
to
appease some Maven convention?
What makes it even stranger is that the java classes end up
together
with the templates and properties anyway - my build process puts
classes, templates and properties all together in WEB-INF/classes/
regardless of where they come from. Live class reloading loves it
that way and it keeps them secure from prying hackers.
So why not mix the source together into the following structure
src/
main/
java/ <-- or perhaps some other name like "t5/"
myproject/
base/
components/
css/
images/
META-INF/
mixins/
pages/
services/
WEB-INF/
and let the build coax it into the WAR file correctly?
Cheers,
Geoff
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
