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.
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.
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.
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.
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?
(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.
(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.
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...
(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 ...
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?