Bug 39659

Summary: the webapp build target should not copy the content dir to the build tree if <content-dir/> redirection is used by the publication
Product: Lenya Reporter: J <nettings>
Component: Build SystemAssignee: Lenya Developers <dev>
Status: NEW ---    
Severity: minor    
Priority: P2    
Version: Trunk   
Target Milestone: 2.0.1   
Hardware: All   
OS: All   
Bug Depends on: 39466    
Bug Blocks:    

Description J 2006-05-25 13:03:43 UTC
the build target src/targets/webapp-build.xml always copies the entire content/
subdirectory of all publications over to the build tree, even if those
publications use an external content locating as specified by the <content-dir/>
directive in publication.xconf. this should be fixed, because it wastes space
and confuses users as to where exactly their content is actually stored.
right now, you end up with a "dead" copy under build which never changes after
building, and a "live" copy in your <content-dir/>.

i could not find an example of parsing xml files from withing an ant target
file, but i guess it is possible. what we need is some sort of conditional: if
<content-dir/> exists, don't attempt to copy the content/ directory to the build
tree. additionally, if the src attribute of <content-dir/> does not exist, print
a warning.
Comment 1 J 2006-06-09 16:14:39 UTC
i object to changing the target milestone to after 1.4, for two reasons:

* it's a huuuge waste of diskspace for large publications and needlessly
increases build time.
* it can even lead to data loss when people get confused as to what their actual
"live" dataset is.

so unless this is extremely hard to fix or overly intrusive, please somebody try
to solve it before 1.4.
Comment 2 Andreas Hartmann 2006-06-12 07:49:15 UTC
A hint for fixing it: use the Ant xmlproperty task on publication.xconf.
It's not really nice to access config files directly from the build, though.
Comment 3 J 2006-09-04 17:18:09 UTC
set dependency to bug 39466. it's not quite the same issue, but maybe we can do
away with both issues by implementing a "pubs.copy=false" similar to
"modules.copy=false" and get rid of the <content-dir> setting altogether.

Comment 4 Andreas Hartmann 2007-03-21 10:15:53 UTC
This should be obsolete for the default publication, since the example content
is imported in the build directory. Maybe we should use something similar for
the blog publication?
Comment 5 J 2007-04-02 11:30:49 UTC
(In reply to comment #4)
> This should be obsolete for the default publication, since the example content
> is imported in the build directory. Maybe we should use something similar for
> the blog publication?

i don't understand. the issue is about publications that use a <content-dir/>
outside the standard location in build/... the default publication does not do that.
Comment 6 Andreas Hartmann 2007-04-23 02:20:08 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > This should be obsolete for the default publication, since the example content
> > is imported in the build directory. Maybe we should use something similar for
> > the blog publication?
> 
> i don't understand. the issue is about publications that use a <content-dir/>
> outside the standard location in build/... the default publication does not do
that.

There is no content directory for the default publication in the source tree, so
nothing is copied.
Comment 7 J 2007-04-23 05:37:49 UTC
yes, but that's not the point. my point is that if a publication uses
<content-dir/> to specify a custom content location, the build process still
copies the entire content/ directory of this publication into the build tree,
even though it is never used after that.
this has no direct functional consequences, except that users might get confused
about which tree to back up and lose data...
Comment 8 Andreas Hartmann 2007-04-23 06:05:34 UTC
(In reply to comment #7)
> yes, but that's not the point. my point is that if a publication uses
> <content-dir/> to specify a custom content location, the build process still
> copies the entire content/ directory of this publication into the build tree,
> even though it is never used after that.

IIUC the source tree of a publication usually doesn't contain a content/
directory, does it? So there shouldn't be anything to copy ...
Comment 9 J 2007-04-23 06:18:47 UTC
well. before the <content-dir/> setting was introduced, it was customary to have
one's custom publications in some directory with a complete publication
(including content/) somewhere on the disk, and to add that path to
pub-root-dirs in local.build.properties.
i did not change that when <content-dir/> came up, so yes, i still have a
content tree in my publication source directory. am i the only one?