You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by so...@apache.org on 2007/12/24 23:03:33 UTC
svn commit: r606743 -
/cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Author: solprovider
Date: Mon Dec 24 14:03:31 2007
New Revision: 606743
URL: http://svn.apache.org/viewvc?rev=606743&view=rev
Log:
The build process carefully adds each of the standard files in the webapp directory. New applications are not included in the build process. No files need to be excluded. This change copies the entire directory. (COCOON-2074)
Modified:
cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Modified: cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
URL: http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml?rev=606743&r1=606742&r2=606743&view=diff
==============================================================================
--- cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml (original)
+++ cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml Mon Dec 24 14:03:31 2007
@@ -25,33 +25,9 @@
<target name="prepare-webapp" depends="blocks, package">
<mkdir dir="${build.webapp}"/>
- <copy file="${webapp}/welcome.xml" tofile="${build.webapp}/welcome.xml" filtering="on"/>
- <copy file="${webapp}/not-found.xml" tofile="${build.webapp}/not-found.xml" filtering="on"/>
- <copy file="${webapp}/welcome.xslt" tofile="${build.webapp}/welcome.xslt" filtering="on"/>
- <copy file="${webapp}/sitemap.xmap" tofile="${build.webapp}/sitemap.xmap"/>
-
- <!-- generate sitemap entries
- <sitemap-components sitemap="${build.webapp}/sitemap.xmap" source="${java}"/>
- -->
-
- <copy todir="${build.webapp}/stylesheets" filtering="on">
- <fileset dir="${webapp}/stylesheets">
- <include name="**/*.xslt"/>
- </fileset>
- </copy>
-
- <copy todir="${build.webapp}/resources" filtering="off">
- <fileset dir="${webapp}/resources"/>
- </copy>
-
- <copy todir="${build.webapp}/WEB-INF" filtering="on">
- <fileset dir="${webapp}/WEB-INF">
- <include name="entities/**"/>
- <include name="classes/**"/>
- <include name="*.x*"/>
- <include name="properties/**"/>
- </fileset>
- </copy>
+ <copy todir="${build.webapp}" filtering="on">
+ <fileset dir="${webapp}"/>
+ </copy>
<copy file="${build}/${name}.jar"
tofile="${build.webapp.lib}/${name}-${version}.jar"/>
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Joerg Heinicke <jo...@gmx.de>.
I remember there have often been issues with either encoding or binary
files. I have no idea if that's still the case and I'm ok with the
change. I also looked into the revision log of the file [1] but could
not find anything particular (only last 4 years available).
Joerg
[1]
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml?view=log
On 26.12.2007 6:13 Uhr, Ralph Goers wrote:
> In case you didn't know, people.apache.org/~jim lists solprovider as
> Paul Ercolino, a committer from Lenya. He opened Cocoon-2074 in June and
> listed the change then. No one ever commented on it.
>
> I'm not clear on what you are saying. Does your question "I am
> wondering if a simple filtering="on" statement can replace the previous
> code." mean you are wondering if he has really verified that his change
> works in all cases? Perhaps you could identify some of the things you
> think will cause problems if it is left this way?
>
> Ralph
>
> Antonio Gallardo wrote:
>> Hi solprovider,
>>
>> I am wondering if a simple
>>
>> filtering="on" statement can replace the previous code. I recall
>> issues with files that become broken on the resources if we use
>> filtering. And also some files we don't want on the final webapp.
>>
>> Best Regards,
>>
>> Antonio Gallardo.
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Ralph Goers <Ra...@dslextreme.com>.
In case you didn't know, people.apache.org/~jim lists solprovider as
Paul Ercolino, a committer from Lenya. He opened Cocoon-2074 in June and
listed the change then. No one ever commented on it.
I'm not clear on what you are saying. Does your question "I am
wondering if a simple filtering="on" statement can replace the previous
code." mean you are wondering if he has really verified that his change
works in all cases? Perhaps you could identify some of the things you
think will cause problems if it is left this way?
Ralph
Antonio Gallardo wrote:
> Hi solprovider,
>
> I am wondering if a simple
>
> filtering="on" statement can replace the previous code. I recall
> issues with files that become broken on the resources if we use
> filtering. And also some files we don't want on the final webapp.
>
> Best Regards,
>
> Antonio Gallardo.
>
>
>
Re: Review of patches (was Re: svn commit: r606743)
Posted by Carsten Ziegeler <cz...@apache.org>.
Thorsten Scherler wrote:
>
> Well, yes, the patch should have reviewed. Lately I see in a couple of
> projects that patches are there for ever.
>
> That is really bad, more if you have the "power" to commit it. I
> personally are more motivate by a quick review and if possible commit.
>
> We need to consider that most of us are developing customer projects,
> where we need this fixes. If they are not going relative quick in the
> code base some of are forced to fork for the customer (really bad). If
> you have done this a couple of time and your patches still are not part
> of the code base one tends to stop submitting patches.
>
> However I do not really see the need to have the rule review-then-commit
> for lenya-committer. IMO that highly depends on the change. I lately
> could fix some minor issues (typos, ...) where I did not ask whether or
> not I could commit. Other commits however I asked and got a quick answer
> (thanks again). I can remember that we said this is ok.
>
Yes, that's absolutely fine. Although for non-minor-issues a RTC would
be prefered, there is no problem with doing CTR. But if a commit is
reviewed and if there are comments/problems then the committer should
take responsibility and act accordingly.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Review of patches (was Re: svn commit: r606743)
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Fri, 2007-12-28 at 12:26 +0100, Bertrand Delacretaz wrote:
> On Dec 28, 2007 11:30 AM, Joerg Heinicke <jo...@gmx.de> wrote:
>
> > On 28.12.2007 11:19 Uhr, Bertrand Delacretaz wrote:
> > > ...In other words, commits from non-Cocoon committers who have SVN rights
> > > to our codebase must be review-then-commit, *not* commit-then-review.
> >
> > The suggested patch was to be reviewed since mid of the year ... it has
> > been part of the original issue description [1]....
>
> "To be reviewed", ok but no none looked at it, so in RTC mode this
> doesn't mean one should apply the patch.
>
> We should have looked at it, of course..but that didn't happen, so
> it's not "reviewed".
Well, yes, the patch should have reviewed. Lately I see in a couple of
projects that patches are there for ever.
That is really bad, more if you have the "power" to commit it. I
personally are more motivate by a quick review and if possible commit.
We need to consider that most of us are developing customer projects,
where we need this fixes. If they are not going relative quick in the
code base some of are forced to fork for the customer (really bad). If
you have done this a couple of time and your patches still are not part
of the code base one tends to stop submitting patches.
However I do not really see the need to have the rule review-then-commit
for lenya-committer. IMO that highly depends on the change. I lately
could fix some minor issues (typos, ...) where I did not ask whether or
not I could commit. Other commits however I asked and got a quick answer
(thanks again). I can remember that we said this is ok.
just my 2 cents.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Ralph Goers <Ra...@dslextreme.com>.
solprovider@apache.org wrote:
> Creating the jira posted to the Cocoon Dev ML in June. Nobody
> commented. Should we consider that as no interest or no objections? I
> did not receive notification that nobody looked at the jira. What is
> the proper channel for more review?
>
This list. If you want to advocate for something you can't just sit back
and wait. This is true of any open source project.
> Carsten has reverted the commit and objects to improving creation of
> applications because some method exists that is better than the
> obvious one (that this commit tried to improve). The Cocoon-2.1
> documentation has a hole where the application creation instructions
> belong. Should this discussion continue?
>
>
Yes, unless you feel it isn't worth pursuing. No one is saying they
don't agree with your objective. They just don't agree with the
particular implementation.
Ralph
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by so...@apache.org.
> Now, I'll not comment on all of this, but I still have a few comments:
> a) you still did not come up with a use case or a sample for the need of
> this patch.
> b) all your patches actually broke the build as they copied way too
> much, for instance the samples and test-suit dir should only be copied
> if they are not excluded during the build.
> c) I just applied a patch which should do what you want to do without
> breaking the build.
> d) I guess that there will be more maintenance releases of 2.1.x - so
> 2.1.11 won't be the last.
> e) The timing for applying this patch and the way it was done was
> not...well...optimal.
> f) I'll now continue with preparing the release.
> Thanks
> Carsten Ziegeler
a) The documentation does not explain how to create an application.
The "samples" application is in the src/webapp directory. Placing new
applications in the same directory is a reasonable assumption for
developers not discouraged by the lack of instructions.
- The use case is to add a simple (no Java) Cocoon application, build, and run.
- Would you please link to a good example of what information is
expected with proposed improvements?
- OT: My new application includes Java code. My guesswork did not
discover how the standard build could compile the code, so I wrote a
separate process. This cannot be the expected practice.
b) That is why having an experienced Cocoon Committer involved is a
very good thing.
c) You included my suggestion and improved the existing code. Good job.
d) Good. Cocoon-2.2 is still not officially completed.
e) My apologies. I try to be helpful. I was not ready to commit
other people's patches from Jira, but I felt I should close my own
issues in preparation for the new release. I thought the worst case
was the change would be reverted if someone found a problem.
f) Thank you for your work.
Thank you for your time and patience with me,
solprovider
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Carsten Ziegeler <cz...@apache.org>.
solprovider@apache.org wrote
>
> Having commit rights meant I did not need to sit back and wait. The
> jira gave the project notice of my intentions; nobody objected.
> Controversy requires interest. Nobody cared about this. I would have
> committed this two weeks after the jira if I had time. Committing
> generated more review, but none was constructive.
>
> Fixing the implementation required much less thought than this thread.
> I reopened the jira and added an implementation that solves the
> ant-copy-filtering concerns:
> http://issues.apache.org/jira/browse/COCOON-2074
> Can this be included in 2.1.11?
>
> Killing an OS project is easy -- just create a new version that
> interests developers and chases away users. The old versions die from
> lack of development. The new version dies from lack of use. A
> demonstration is in progress.
>
Now, I'll not comment on all of this, but I still have a few comments:
a) you still did not come up with a use case or a sample for the need of
this patch.
b) all your patches actually broke the build as they copied way too
much, for instance the samples and test-suit dir should only be copied
if they are not excluded during the build.
c) I just applied a patch which should do what you want to do without
breaking the build.
d) I guess that there will be more maintenance releases of 2.1.x - so
2.1.11 won't be the last.
e) The timing for applying this patch and the way it was done was
not...well...optimal.
f) I'll now continue with preparing the release.
Thanks
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by so...@apache.org.
On 12/29/07, Ralph Goers <Ra...@dslextreme.com> wrote:
> solprovider@apache.org wrote:
> > Creating the jira posted to the Cocoon Dev ML in June. Nobody
> > commented. Should we consider that as no interest or no objections? I
> > did not receive notification that nobody looked at the jira. What is
> > the proper channel for more review?
> This list. If you want to advocate for something you can't just sit back
> and wait. This is true of any open source project.
> > Carsten has reverted the commit and objects to improving creation of
> > applications because some method exists that is better than the
> > obvious one (that this commit tried to improve). The Cocoon-2.1
> > documentation has a hole where the application creation instructions
> > belong. Should this discussion continue?
> Yes, unless you feel it isn't worth pursuing. No one is saying they
> don't agree with your objective. They just don't agree with the
> particular implementation.
> Ralph
On 12/29/07, Grzegorz Kossakowski <gr...@tuffmail.com> wrote:
> solprovider@apache.org pisze:
> > We needed a new 2.1 because at least one very annoying bug was
> > patched. When releasing 2.1.11 was first discussed, someone mentioned
> > making this the final release as most of the Cocoon devs are working
> > on 2.2. I hope you are correct that development of Cocoon-2.1 has not
> > ended. I like Cocoon-2.1 and have several patches to contribute.
> > This patch was to make application creation even easier. Cocoon-2.2
> > has progressed in a different direction and requires much more
> > configuration.
> It was me who wanted to kill 2.1.x branch but I was pointed out immediately that in OS world there
> is no way to kill something. As long as there is a community interest 2.1.x branch will be live. You
> may noticed that some people has expressed such an interest.
>
> I understand your motivation to have all your patches included in upcoming release but this one is
> really controversial so you must understand it may generate tensions.
>
> When it comes to reviewing. I think it's fair to say that if there is no response to your JIRA
> report/mail on dev within 2-3 weeks it's wise to send another e-mail to the dev list reminding
> people of your affair. I have done this several times in the past.
> Grzegorz Kossakowski
Having commit rights meant I did not need to sit back and wait. The
jira gave the project notice of my intentions; nobody objected.
Controversy requires interest. Nobody cared about this. I would have
committed this two weeks after the jira if I had time. Committing
generated more review, but none was constructive.
Fixing the implementation required much less thought than this thread.
I reopened the jira and added an implementation that solves the
ant-copy-filtering concerns:
http://issues.apache.org/jira/browse/COCOON-2074
Can this be included in 2.1.11?
Killing an OS project is easy -- just create a new version that
interests developers and chases away users. The old versions die from
lack of development. The new version dies from lack of use. A
demonstration is in progress.
solprovider
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
solprovider@apache.org pisze:
>
> We needed a new 2.1 because at least one very annoying bug was
> patched. When releasing 2.1.11 was first discussed, someone mentioned
> making this the final release as most of the Cocoon devs are working
> on 2.2. I hope you are correct that development of Cocoon-2.1 has not
> ended. I like Cocoon-2.1 and have several patches to contribute.
> This patch was to make application creation even easier. Cocoon-2.2
> has progressed in a different direction and requires much more
> configuration.
It was me who wanted to kill 2.1.x branch but I was pointed out immediately that in OS world there
is no way to kill something. As long as there is a community interest 2.1.x branch will be live. You
may noticed that some people has expressed such an interest.
I understand your motivation to have all your patches included in upcomming release but this one is
really controversial so you must understand it may generate tensions.
When it comes to reviewing. I think it's fair to say that if there is no response to your JIRA
report/mail on dev within 2-3 weeks it's wise to send another e-mail to the dev list reminding
people of your affair. I have done this several times in the past.
--
Grzegorz Kossakowski
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by so...@apache.org.
On 12/28/07, Ralph Goers <Ra...@dslextreme.com> wrote:
> solprovider@apache.org wrote:
> > I committed/closed my Cocoon jiras as soon as I learned a Cocoon
> > release was planned. This may be the final release of Cocoon-2.1 so
> > every change must be committed or discarded.
> I wouldn't get your hopes up on this one. 2.2 is sufficiently different
> enough that I would not be surprised to see a 2.1.12 release even after
> 2.2.0.
> Ralph
We needed a new 2.1 because at least one very annoying bug was
patched. When releasing 2.1.11 was first discussed, someone mentioned
making this the final release as most of the Cocoon devs are working
on 2.2. I hope you are correct that development of Cocoon-2.1 has not
ended. I like Cocoon-2.1 and have several patches to contribute.
This patch was to make application creation even easier. Cocoon-2.2
has progressed in a different direction and requires much more
configuration.
On 12/28/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> On Dec 28, 2007 11:30 AM, Joerg Heinicke <jo...@gmx.de> wrote:
> > On 28.12.2007 11:19 Uhr, Bertrand Delacretaz wrote:
> > > ...In other words, commits from non-Cocoon committers who have SVN rights
> > > to our codebase must be review-then-commit, *not* commit-then-review.
> > The suggested patch was to be reviewed since mid of the year ... it has
> > been part of the original issue description [1]....
> "To be reviewed", ok but no none looked at it, so in RTC mode this
> doesn't mean one should apply the patch.
> We should have looked at it, of course..but that didn't happen, so
> it's not "reviewed".
> -Bertrand
> > [1] https://issues.apache.org/jira/browse/COCOON-2074
Creating the jira posted to the Cocoon Dev ML in June. Nobody
commented. Should we consider that as no interest or no objections? I
did not receive notification that nobody looked at the jira. What is
the proper channel for more review?
Carsten has reverted the commit and objects to improving creation of
applications because some method exists that is better than the
obvious one (that this commit tried to improve). The Cocoon-2.1
documentation has a hole where the application creation instructions
belong. Should this discussion continue?
solprovider
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Carsten Ziegeler <cz...@apache.org>.
In the meantime I reverted the commit.
I'm open to discuss the issue at hand, so there is still a chance to get
it a solution (if required) into the upcoming version.
Carsten
Bertrand Delacretaz wrote:
> On Dec 28, 2007 11:30 AM, Joerg Heinicke <jo...@gmx.de> wrote:
>
>> On 28.12.2007 11:19 Uhr, Bertrand Delacretaz wrote:
>>> ...In other words, commits from non-Cocoon committers who have SVN rights
>>> to our codebase must be review-then-commit, *not* commit-then-review.
>> The suggested patch was to be reviewed since mid of the year ... it has
>> been part of the original issue description [1]....
>
> "To be reviewed", ok but no none looked at it, so in RTC mode this
> doesn't mean one should apply the patch.
>
> We should have looked at it, of course..but that didn't happen, so
> it's not "reviewed".
>
> -Bertrand
>
>> [1] https://issues.apache.org/jira/browse/COCOON-2074
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Dec 28, 2007 11:30 AM, Joerg Heinicke <jo...@gmx.de> wrote:
> On 28.12.2007 11:19 Uhr, Bertrand Delacretaz wrote:
> > ...In other words, commits from non-Cocoon committers who have SVN rights
> > to our codebase must be review-then-commit, *not* commit-then-review.
>
> The suggested patch was to be reviewed since mid of the year ... it has
> been part of the original issue description [1]....
"To be reviewed", ok but no none looked at it, so in RTC mode this
doesn't mean one should apply the patch.
We should have looked at it, of course..but that didn't happen, so
it's not "reviewed".
-Bertrand
> [1] https://issues.apache.org/jira/browse/COCOON-2074
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Joerg Heinicke <jo...@gmx.de>.
On 28.12.2007 11:19 Uhr, Bertrand Delacretaz wrote:
> IIUC (please correct me if I'm wrong), solprovider has commit rights
> on Cocoon by way of being a Lenya committer - that's fine, but we
> expect you guys to ask on list before committing stuff.
>
> In other words, commits from non-Cocoon committers who have SVN rights
> to our codebase must be review-then-commit, *not* commit-then-review.
The suggested patch was to be reviewed since mid of the year ... it has
been part of the original issue description [1].
Joerg
[1] https://issues.apache.org/jira/browse/COCOON-2074
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Dec 27, 2007 1:06 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...If I get no response from Paul (or anyone else on this), I'll revert the
> change for the release....
+1 for reverting: the change introduces risks, and does not introduce
useful functionality that has been agreed upon by Cocoon committers.
IIUC (please correct me if I'm wrong), solprovider has commit rights
on Cocoon by way of being a Lenya committer - that's fine, but we
expect you guys to ask on list before committing stuff.
In other words, commits from non-Cocoon committers who have SVN rights
to our codebase must be review-then-commit, *not* commit-then-review.
-Bertrand
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On Dec 27, 2007, at 10:29 AM, solprovider@apache.org wrote:
> The discussion is that nobody trusts ant to work properly
> so this patch should be reverted because theoretical problems may
> result if the ant developers are poor programmers.
It is not theoretical. Binary files, as well as UTF-8 encoded files,
are corrupted by filtering=on. If you pull history of the build.xml
file, I'm certain you will find relevant commits (you'd have to dig
into C2.0 history though).
> Does Cocoon need the filtering?
Yes, C2.1 needs filtering.
Vadim
> Would filtering=no solve the concerns?
>
> solprovider
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Ralph Goers <Ra...@dslextreme.com>.
solprovider@apache.org wrote:
>
> I committed/closed my Cocoon jiras as soon as I learned a Cocoon
> release was planned. This may be the final release of Cocoon-2.1 so
> every change must be committed or discarded.
>
>
I wouldn't get your hopes up on this one. 2.2 is sufficiently different
enough that I would not be surprised to see a 2.1.12 release even after
2.2.0.
Ralph
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by so...@apache.org.
On 12/27/07, Carsten Ziegeler <cz...@apache.org> wrote:
> solprovider@apache.org wrote:
> > Cocoon-2.1 keeps applications ("samples") in the webapp directory.
> > Newbies would expect to add applications to that directory. The build
> > process chooses specific files and directories to copy so new
> > applications are not copied to the build directory. The patch removed
> > the list of specific files to copy the entire webapp directory. I
> > closed my Cocoon jiras because a release candidate for Cocoon-2.1.11
> > is being prepared.
> >
> > Antonio asked whether ant:copy had the intelligence to understand
> > binary files should not be affected by text replacement. I have not
> > studied ant to discover if the program is sane.
> >
> > This change passed my testing in May. The jira from June survived
> > without comments. None of the comments in this thread mention real
> > problems. The discussion is that nobody trusts ant to work properly
> > so this patch should be reverted because theoretical problems may
> > result if the ant developers are poor programmers. Nobody on the
> > Cocoon project wants to spend five minutes testing.
> >
> > I will test more after somebody spends one minute to define the test
> > expected to fail because of this patch. The potential bug seems to
> > require binary files containing strings on ant's filter list.
> >
> As Vadim has responded again: filtering should not be done on all files,
> otherwise they get corrupted. And this means whenever you copy a
> complete directory tree, you have to copy these files without filtering
> and if you need filtering for specific files, you need to do this in a
> second pass. This has been repeatedly said in this thread, so it would
> be great if you could come up with a solution that honours this.
> And this is independent from the fact, that currently copying all the
> files with filtering on does not corrupt them - it is a potential cause
> of error we would like to avoid.
Ant allowing text filtering to affect binary files should be posted as
a data-damaging bug. If this functionality is that bad, the Cocoon
project is correct to not trust ant.
> Apart from that, I'm still wondering what your patch is trying to
> achieve? I really hope that you are not putting your own webapp into a
> Cocoon src directory and then hope for the cocoon build to pick up your
> files? You claim that newbies want to put their stuff directly into the
> Cocoon src/webapp directory? I never heard of this and actually I would
> strongly suggest against doing so. The old way of copying the webapp
> files actually prevented people from doing this - and I really prefer to
> keep it this way. There are several much better ways of building own
> applications.
I believe software should be easy. The easiest and most common method
of learning a new platform is to copy the demonstration application.
Cocoon's demonstration application is "samples". Copy "samples" to
"myfirstapp". Build. "myfirstapp" application does not work or even
exist. Cocoon seems difficult and loses a customer.
Why would you want to discourage putting applications in the
src/webapp directory. Cocoon clearly recommends that as the proper
directory. That is where the demonstration application is located.
That is the only directory named "app". Where else would anybody
expect applications to be placed?
> Regarding your Jira issue: just because noone commented on it over the
> last months does not mean that this one got happily accepted by
> everyone. I guess it's just an oversight, I - for instance - didn't
> notice this issue until you changed the code.
Nobody does. Don't worry about it.
> And, our build system is a very very fragile piece of code that caused
> way too many problems over the past (one of the reasons why we changed
> this for 2.2) - so it's in general not a good idea to change this
> fragile piece just before a release.
> Carsten
I committed/closed my Cocoon jiras as soon as I learned a Cocoon
release was planned. This may be the final release of Cocoon-2.1 so
every change must be committed or discarded.
solprovider
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Carsten Ziegeler <cz...@apache.org>.
solprovider@apache.org wrote:
> Hi All,
>
> Cocoon-2.1 keeps applications ("samples") in the webapp directory.
> Newbies would expect to add applications to that directory. The build
> process chooses specific files and directories to copy so new
> applications are not copied to the build directory. The patch removed
> the list of specific files to copy the entire webapp directory. I
> closed my Cocoon jiras because a release candidate for Cocoon-2.1.11
> is being prepared.
>
> Antonio asked whether ant:copy had the intelligence to understand
> binary files should not be affected by text replacement. I have not
> studied ant to discover if the program is sane.
>
> This change passed my testing in May. The jira from June survived
> without comments. None of the comments in this thread mention real
> problems. The discussion is that nobody trusts ant to work properly
> so this patch should be reverted because theoretical problems may
> result if the ant developers are poor programmers. Nobody on the
> Cocoon project wants to spend five minutes testing.
>
> I will test more after somebody spends one minute to define the test
> expected to fail because of this patch. The potential bug seems to
> require binary files containing strings on ant's filter list.
>
As Vadim has responded again: filtering should not be done on all files,
otherwise they get corrupted. And this means whenever you copy a
complete directory tree, you have to copy these files without filtering
and if you need filtering for specific files, you need to do this in a
second pass. This has been repeatedly said in this thread, so it would
be great if you could come up with a solution that honours this.
And this is independent from the fact, that currently copying all the
files with filtering on does not corrupt them - it is a potential cause
of error we would like to avoid.
Apart from that, I'm still wondering what your patch is trying to
achieve? I really hope that you are not putting your own webapp into a
Cocoon src directory and then hope for the cocoon build to pick up your
files? You claim that newbies want to put their stuff directly into the
Cocoon src/webapp directory? I never heard of this and actually I would
strongly suggest against doing so. The old way of copying the webapp
files actually prevented people from doing this - and I really prefer to
keep it this way. There are several much better ways of building own
applications.
Regarding your Jira issue: just because noone commented on it over the
last months does not mean that this one got happily accepted by
everyone. I guess it's just an oversight, I - for instance - didn't
notice this issue until you changed the code.
And, our build system is a very very fragile piece of code that caused
way too many problems over the past (one of the reasons why we changed
this for 2.2) - so it's in general not a good idea to change this
fragile piece just before a release.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by so...@apache.org.
Hi All,
Cocoon-2.1 keeps applications ("samples") in the webapp directory.
Newbies would expect to add applications to that directory. The build
process chooses specific files and directories to copy so new
applications are not copied to the build directory. The patch removed
the list of specific files to copy the entire webapp directory. I
closed my Cocoon jiras because a release candidate for Cocoon-2.1.11
is being prepared.
Antonio asked whether ant:copy had the intelligence to understand
binary files should not be affected by text replacement. I have not
studied ant to discover if the program is sane.
This change passed my testing in May. The jira from June survived
without comments. None of the comments in this thread mention real
problems. The discussion is that nobody trusts ant to work properly
so this patch should be reverted because theoretical problems may
result if the ant developers are poor programmers. Nobody on the
Cocoon project wants to spend five minutes testing.
I will test more after somebody spends one minute to define the test
expected to fail because of this patch. The potential bug seems to
require binary files containing strings on ant's filter list.
Does Cocoon need the filtering? Would filtering=no solve the concerns?
solprovider
On 12/27/07, Thorsten Scherler
<th...@juntadeandalucia.es> wrote:
> On Thu, 2007-12-27 at 13:06 +0100, Carsten Ziegeler wrote:
> > If I get no response from Paul (or anyone else on this), I'll revert the
> > change for the release. I'm currently planning to prepare the
> > distribution next monday.
>
> Yes, please revert the commit.
>
> The fix was to have custom components in cocoon and the build will pick
> it up. But this can be done by a custom target as well. COCOON-2074.
>
> The filtering needs to be off for binary stuff like other have been
> pointed out so it is doing more harm then good.
>
> > Carsten Ziegeler wrote:
> > > At least the resources have been copied with filtering "off" before. As
> > > the resources contain images and other binary stuff, this changes
> > > breakes definitly the build as binary files have to be copied with
> > > filtering turned off.
> > >
> > > Apart from that, I'm wondering what this change tries to fix.
> > >
> > > So Paul, please comment on this issue.
> > >
> > > Thanks
> > > Carsten
> > >
> > > Antonio Gallardo wrote:
> > >> Hi solprovider,
> > >>
> > >> I am wondering if a simple
> > >>
> > >> filtering="on" statement can replace the previous code. I recall issues
> > >> with files that become broken on the resources if we use filtering. And
> > >> also some files we don't want on the final webapp.
> > >>
> > >> Best Regards,
> > >>
> > >> Antonio Gallardo.
> > >>
> > >>
> > >> solprovider@apache.org escribió:
> > >>> Author: solprovider
> > >>> Date: Mon Dec 24 14:03:31 2007
> > >>> New Revision: 606743
> > >>>
> > >>> URL: http://svn.apache.org/viewvc?rev=606743&view=rev
> > >>> Log:
> > >>> The build process carefully adds each of the standard files in the
> > >>> webapp directory. New applications are not included in the build
> > >>> process. No files need to be excluded. This change copies the entire
> > >>> directory. (COCOON-2074)
> > >>>
> > >>> Modified:
> > >>> cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
> > >>>
> > >>> Modified: cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
> > >>> URL:
> > >>> http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml?rev=606743&r1=606742&r2=606743&view=diff
> > >>>
> > >>> ==============================================================================
> > >>>
> > >>> --- cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
> > >>> (original)
> > >>> +++ cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml Mon
> > >>> Dec 24 14:03:31 2007
> > >>> @@ -25,33 +25,9 @@
> > >>> <target name="prepare-webapp" depends="blocks, package">
> > >>> <mkdir dir="${build.webapp}"/>
> > >>>
> > >>> - <copy file="${webapp}/welcome.xml"
> > >>> tofile="${build.webapp}/welcome.xml" filtering="on"/>
> > >>> - <copy file="${webapp}/not-found.xml"
> > >>> tofile="${build.webapp}/not-found.xml" filtering="on"/>
> > >>> - <copy file="${webapp}/welcome.xslt"
> > >>> tofile="${build.webapp}/welcome.xslt" filtering="on"/>
> > >>> - <copy file="${webapp}/sitemap.xmap"
> > >>> tofile="${build.webapp}/sitemap.xmap"/>
> > >>> -
> > >>> - <!-- generate sitemap entries
> > >>> - <sitemap-components sitemap="${build.webapp}/sitemap.xmap"
> > >>> source="${java}"/>
> > >>> - -->
> > >>> -
> > >>> - <copy todir="${build.webapp}/stylesheets" filtering="on">
> > >>> - <fileset dir="${webapp}/stylesheets">
> > >>> - <include name="**/*.xslt"/>
> > >>> - </fileset>
> > >>> - </copy>
> > >>> -
> > >>> - <copy todir="${build.webapp}/resources" filtering="off">
> > >>> - <fileset dir="${webapp}/resources"/>
> > >>> - </copy>
> > >>> -
> > >>> - <copy todir="${build.webapp}/WEB-INF" filtering="on">
> > >>> - <fileset dir="${webapp}/WEB-INF">
> > >>> - <include name="entities/**"/>
> > >>> - <include name="classes/**"/>
> > >>> - <include name="*.x*"/>
> > >>> - <include name="properties/**"/>
> > >>> - </fileset>
> > >>> - </copy>
> > >>> + <copy todir="${build.webapp}" filtering="on">
> > >>> + <fileset dir="${webapp}"/>
> > >>> + </copy>
> > >>>
> > >>> <copy file="${build}/${name}.jar"
> > >>> tofile="${build.webapp.lib}/${name}-${version}.jar"/>
> Thorsten Scherler thorsten.at.apache.org
> Open Source Java consulting, training and solutions
Re: svn commit: r606743 -
/cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Thu, 2007-12-27 at 13:06 +0100, Carsten Ziegeler wrote:
> If I get no response from Paul (or anyone else on this), I'll revert the
> change for the release. I'm currently planning to prepare the
> distribution next monday.
Yes, please revert the commit.
The fix was to have custom components in cocoon and the build will pick
it up. But this can be done by a custom target as well. COCOON-2074.
The filtering needs to be off for binary stuff like other have been
pointed out so it is doing more harm then good.
salu2
>
> Carsten
>
> Carsten Ziegeler wrote:
> > At least the resources have been copied with filtering "off" before. As
> > the resources contain images and other binary stuff, this changes
> > breakes definitly the build as binary files have to be copied with
> > filtering turned off.
> >
> > Apart from that, I'm wondering what this change tries to fix.
> >
> > So Paul, please comment on this issue.
> >
> > Thanks
> > Carsten
> >
> > Antonio Gallardo wrote:
> >> Hi solprovider,
> >>
> >> I am wondering if a simple
> >>
> >> filtering="on" statement can replace the previous code. I recall issues
> >> with files that become broken on the resources if we use filtering. And
> >> also some files we don't want on the final webapp.
> >>
> >> Best Regards,
> >>
> >> Antonio Gallardo.
> >>
> >>
> >> solprovider@apache.org escribió:
> >>> Author: solprovider
> >>> Date: Mon Dec 24 14:03:31 2007
> >>> New Revision: 606743
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=606743&view=rev
> >>> Log:
> >>> The build process carefully adds each of the standard files in the
> >>> webapp directory. New applications are not included in the build
> >>> process. No files need to be excluded. This change copies the entire
> >>> directory. (COCOON-2074)
> >>>
> >>> Modified:
> >>> cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
> >>>
> >>> Modified: cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
> >>> URL:
> >>> http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml?rev=606743&r1=606742&r2=606743&view=diff
> >>>
> >>> ==============================================================================
> >>>
> >>> --- cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
> >>> (original)
> >>> +++ cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml Mon
> >>> Dec 24 14:03:31 2007
> >>> @@ -25,33 +25,9 @@
> >>> <target name="prepare-webapp" depends="blocks, package">
> >>> <mkdir dir="${build.webapp}"/>
> >>>
> >>> - <copy file="${webapp}/welcome.xml"
> >>> tofile="${build.webapp}/welcome.xml" filtering="on"/>
> >>> - <copy file="${webapp}/not-found.xml"
> >>> tofile="${build.webapp}/not-found.xml" filtering="on"/>
> >>> - <copy file="${webapp}/welcome.xslt"
> >>> tofile="${build.webapp}/welcome.xslt" filtering="on"/>
> >>> - <copy file="${webapp}/sitemap.xmap"
> >>> tofile="${build.webapp}/sitemap.xmap"/>
> >>> -
> >>> - <!-- generate sitemap entries
> >>> - <sitemap-components sitemap="${build.webapp}/sitemap.xmap"
> >>> source="${java}"/>
> >>> - -->
> >>> -
> >>> - <copy todir="${build.webapp}/stylesheets" filtering="on">
> >>> - <fileset dir="${webapp}/stylesheets">
> >>> - <include name="**/*.xslt"/>
> >>> - </fileset>
> >>> - </copy>
> >>> -
> >>> - <copy todir="${build.webapp}/resources" filtering="off">
> >>> - <fileset dir="${webapp}/resources"/>
> >>> - </copy>
> >>> -
> >>> - <copy todir="${build.webapp}/WEB-INF" filtering="on">
> >>> - <fileset dir="${webapp}/WEB-INF">
> >>> - <include name="entities/**"/>
> >>> - <include name="classes/**"/>
> >>> - <include name="*.x*"/>
> >>> - <include name="properties/**"/>
> >>> - </fileset>
> >>> - </copy>
> >>> + <copy todir="${build.webapp}" filtering="on">
> >>> + <fileset dir="${webapp}"/>
> >>> + </copy>
> >>>
> >>> <copy file="${build}/${name}.jar"
> >>> tofile="${build.webapp.lib}/${name}-${version}.jar"/>
> >>>
> >>>
> >>
> >
> >
>
>
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Thanks Ralph [Was: 2.1.11 release]
Posted by David Crossley <cr...@apache.org>.
Ralph Goers wrote:
> I committed the changes to 2.1.x. I'll try to get trunk done on 1/1/08
Thanks for that extra effort Ralph, in the midst of your preparations.
Your ASF friends wish you well.
-David
Re: 2.1.11 release
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
> I committed the changes to 2.1.x. I'll try to get trunk done on 1/1/08
>
Many thanks Ralph!
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: 2.1.11 release
Posted by Ralph Goers <Ra...@dslextreme.com>.
I committed the changes to 2.1.x. I'll try to get trunk done on 1/1/08
Ralph Goers wrote:
> If I can't get it done in the next 24 hrs go ahead and do that.
> However, I'd really like my changes in 2.1.11 also. It has been an
> outstanding defect for several years.
>
> Grzegorz Kossakowski wrote:
>> Ralph Goers pisze:
>>
>>> I'm currently trying to get the XPathXMLFileModule into trunk. I was
>>> holding off committing until I had that working. However, I will be
>>> heading off to Seattle very early tomorrow until New Year's Eve so if I
>>> don't get it committed today it won't be included in your build - which
>>> is a very bad thing since several JXPath based input modules don't work
>>> right now (i.e - I'd have to vote -1 on the release until I get this
>>> fixed). I may just commit what I have for 2.1 and get trunk done
>>> when I
>>> get back.
>>>
>>> Unfortunately, I am very busy getting things ready for my grandkids
>>> birthday party so I have no idea if I'll get this completed today.
>>>
>>
>> What about reverting my change in 2.1.x branch that broke
>> JXPath-based modules and introducing a new
>> method in JXPathHelper just to make xmodule:flow-attr working properly?
>> It's really not my favorite choice but it was me who broke XMLModule
>> and I don't want to block a
>> release.
>>
>> In trunk I opt for cleaner API at price of breaking back-compatibility.
>>
>> WDYT?
>>
>>
Re: 2.1.11 release
Posted by Ralph Goers <Ra...@dslextreme.com>.
If I can't get it done in the next 24 hrs go ahead and do that. However,
I'd really like my changes in 2.1.11 also. It has been an outstanding
defect for several years.
Grzegorz Kossakowski wrote:
> Ralph Goers pisze:
>
>> I'm currently trying to get the XPathXMLFileModule into trunk. I was
>> holding off committing until I had that working. However, I will be
>> heading off to Seattle very early tomorrow until New Year's Eve so if I
>> don't get it committed today it won't be included in your build - which
>> is a very bad thing since several JXPath based input modules don't work
>> right now (i.e - I'd have to vote -1 on the release until I get this
>> fixed). I may just commit what I have for 2.1 and get trunk done when I
>> get back.
>>
>> Unfortunately, I am very busy getting things ready for my grandkids
>> birthday party so I have no idea if I'll get this completed today.
>>
>
> What about reverting my change in 2.1.x branch that broke JXPath-based modules and introducing a new
> method in JXPathHelper just to make xmodule:flow-attr working properly?
> It's really not my favorite choice but it was me who broke XMLModule and I don't want to block a
> release.
>
> In trunk I opt for cleaner API at price of breaking back-compatibility.
>
> WDYT?
>
>
Re: 2.1.11 release
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Ralph Goers pisze:
> I'm currently trying to get the XPathXMLFileModule into trunk. I was
> holding off committing until I had that working. However, I will be
> heading off to Seattle very early tomorrow until New Year's Eve so if I
> don't get it committed today it won't be included in your build - which
> is a very bad thing since several JXPath based input modules don't work
> right now (i.e - I'd have to vote -1 on the release until I get this
> fixed). I may just commit what I have for 2.1 and get trunk done when I
> get back.
>
> Unfortunately, I am very busy getting things ready for my grandkids
> birthday party so I have no idea if I'll get this completed today.
What about reverting my change in 2.1.x branch that broke JXPath-based modules and introducing a new
method in JXPathHelper just to make xmodule:flow-attr working properly?
It's really not my favorite choice but it was me who broke XMLModule and I don't want to block a
release.
In trunk I opt for cleaner API at price of breaking back-compatibility.
WDYT?
--
Grzegorz Kossakowski
2.1.11 release
Posted by Ralph Goers <Ra...@dslextreme.com>.
I'm currently trying to get the XPathXMLFileModule into trunk. I was
holding off committing until I had that working. However, I will be
heading off to Seattle very early tomorrow until New Year's Eve so if I
don't get it committed today it won't be included in your build - which
is a very bad thing since several JXPath based input modules don't work
right now (i.e - I'd have to vote -1 on the release until I get this
fixed). I may just commit what I have for 2.1 and get trunk done when I
get back.
Unfortunately, I am very busy getting things ready for my grandkids
birthday party so I have no idea if I'll get this completed today.
Ralph
Carsten Ziegeler wrote:
> If I get no response from Paul (or anyone else on this), I'll revert the
> change for the release. I'm currently planning to prepare the
> distribution next monday.
>
> Carsten
>
>
>
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Carsten Ziegeler <cz...@apache.org>.
If I get no response from Paul (or anyone else on this), I'll revert the
change for the release. I'm currently planning to prepare the
distribution next monday.
Carsten
Carsten Ziegeler wrote:
> At least the resources have been copied with filtering "off" before. As
> the resources contain images and other binary stuff, this changes
> breakes definitly the build as binary files have to be copied with
> filtering turned off.
>
> Apart from that, I'm wondering what this change tries to fix.
>
> So Paul, please comment on this issue.
>
> Thanks
> Carsten
>
> Antonio Gallardo wrote:
>> Hi solprovider,
>>
>> I am wondering if a simple
>>
>> filtering="on" statement can replace the previous code. I recall issues
>> with files that become broken on the resources if we use filtering. And
>> also some files we don't want on the final webapp.
>>
>> Best Regards,
>>
>> Antonio Gallardo.
>>
>>
>> solprovider@apache.org escribió:
>>> Author: solprovider
>>> Date: Mon Dec 24 14:03:31 2007
>>> New Revision: 606743
>>>
>>> URL: http://svn.apache.org/viewvc?rev=606743&view=rev
>>> Log:
>>> The build process carefully adds each of the standard files in the
>>> webapp directory. New applications are not included in the build
>>> process. No files need to be excluded. This change copies the entire
>>> directory. (COCOON-2074)
>>>
>>> Modified:
>>> cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
>>>
>>> Modified: cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
>>> URL:
>>> http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml?rev=606743&r1=606742&r2=606743&view=diff
>>>
>>> ==============================================================================
>>>
>>> --- cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
>>> (original)
>>> +++ cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml Mon
>>> Dec 24 14:03:31 2007
>>> @@ -25,33 +25,9 @@
>>> <target name="prepare-webapp" depends="blocks, package">
>>> <mkdir dir="${build.webapp}"/>
>>>
>>> - <copy file="${webapp}/welcome.xml"
>>> tofile="${build.webapp}/welcome.xml" filtering="on"/>
>>> - <copy file="${webapp}/not-found.xml"
>>> tofile="${build.webapp}/not-found.xml" filtering="on"/>
>>> - <copy file="${webapp}/welcome.xslt"
>>> tofile="${build.webapp}/welcome.xslt" filtering="on"/>
>>> - <copy file="${webapp}/sitemap.xmap"
>>> tofile="${build.webapp}/sitemap.xmap"/>
>>> -
>>> - <!-- generate sitemap entries
>>> - <sitemap-components sitemap="${build.webapp}/sitemap.xmap"
>>> source="${java}"/>
>>> - -->
>>> -
>>> - <copy todir="${build.webapp}/stylesheets" filtering="on">
>>> - <fileset dir="${webapp}/stylesheets">
>>> - <include name="**/*.xslt"/>
>>> - </fileset>
>>> - </copy>
>>> -
>>> - <copy todir="${build.webapp}/resources" filtering="off">
>>> - <fileset dir="${webapp}/resources"/>
>>> - </copy>
>>> -
>>> - <copy todir="${build.webapp}/WEB-INF" filtering="on">
>>> - <fileset dir="${webapp}/WEB-INF">
>>> - <include name="entities/**"/>
>>> - <include name="classes/**"/>
>>> - <include name="*.x*"/>
>>> - <include name="properties/**"/>
>>> - </fileset>
>>> - </copy>
>>> + <copy todir="${build.webapp}" filtering="on">
>>> + <fileset dir="${webapp}"/>
>>> + </copy>
>>>
>>> <copy file="${build}/${name}.jar"
>>> tofile="${build.webapp.lib}/${name}-${version}.jar"/>
>>>
>>>
>>
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Carsten Ziegeler <cz...@apache.org>.
At least the resources have been copied with filtering "off" before. As
the resources contain images and other binary stuff, this changes
breakes definitly the build as binary files have to be copied with
filtering turned off.
Apart from that, I'm wondering what this change tries to fix.
So Paul, please comment on this issue.
Thanks
Carsten
Antonio Gallardo wrote:
> Hi solprovider,
>
> I am wondering if a simple
>
> filtering="on" statement can replace the previous code. I recall issues
> with files that become broken on the resources if we use filtering. And
> also some files we don't want on the final webapp.
>
> Best Regards,
>
> Antonio Gallardo.
>
>
> solprovider@apache.org escribió:
>> Author: solprovider
>> Date: Mon Dec 24 14:03:31 2007
>> New Revision: 606743
>>
>> URL: http://svn.apache.org/viewvc?rev=606743&view=rev
>> Log:
>> The build process carefully adds each of the standard files in the
>> webapp directory. New applications are not included in the build
>> process. No files need to be excluded. This change copies the entire
>> directory. (COCOON-2074)
>>
>> Modified:
>> cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
>>
>> Modified: cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
>> URL:
>> http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml?rev=606743&r1=606742&r2=606743&view=diff
>>
>> ==============================================================================
>>
>> --- cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
>> (original)
>> +++ cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml Mon
>> Dec 24 14:03:31 2007
>> @@ -25,33 +25,9 @@
>> <target name="prepare-webapp" depends="blocks, package">
>> <mkdir dir="${build.webapp}"/>
>>
>> - <copy file="${webapp}/welcome.xml"
>> tofile="${build.webapp}/welcome.xml" filtering="on"/>
>> - <copy file="${webapp}/not-found.xml"
>> tofile="${build.webapp}/not-found.xml" filtering="on"/>
>> - <copy file="${webapp}/welcome.xslt"
>> tofile="${build.webapp}/welcome.xslt" filtering="on"/>
>> - <copy file="${webapp}/sitemap.xmap"
>> tofile="${build.webapp}/sitemap.xmap"/>
>> -
>> - <!-- generate sitemap entries
>> - <sitemap-components sitemap="${build.webapp}/sitemap.xmap"
>> source="${java}"/>
>> - -->
>> -
>> - <copy todir="${build.webapp}/stylesheets" filtering="on">
>> - <fileset dir="${webapp}/stylesheets">
>> - <include name="**/*.xslt"/>
>> - </fileset>
>> - </copy>
>> -
>> - <copy todir="${build.webapp}/resources" filtering="off">
>> - <fileset dir="${webapp}/resources"/>
>> - </copy>
>> -
>> - <copy todir="${build.webapp}/WEB-INF" filtering="on">
>> - <fileset dir="${webapp}/WEB-INF">
>> - <include name="entities/**"/>
>> - <include name="classes/**"/>
>> - <include name="*.x*"/>
>> - <include name="properties/**"/>
>> - </fileset>
>> - </copy>
>> + <copy todir="${build.webapp}" filtering="on">
>> + <fileset dir="${webapp}"/>
>> + </copy>
>>
>> <copy file="${build}/${name}.jar"
>> tofile="${build.webapp.lib}/${name}-${version}.jar"/>
>>
>>
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: svn commit: r606743 - /cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi solprovider,
I am wondering if a simple
filtering="on" statement can replace the previous code. I recall issues with files that become broken on the resources if we use filtering. And also some files we don't want on the final webapp.
Best Regards,
Antonio Gallardo.
solprovider@apache.org escribió:
> Author: solprovider
> Date: Mon Dec 24 14:03:31 2007
> New Revision: 606743
>
> URL: http://svn.apache.org/viewvc?rev=606743&view=rev
> Log:
> The build process carefully adds each of the standard files in the webapp directory. New applications are not included in the build process. No files need to be excluded. This change copies the entire directory. (COCOON-2074)
>
> Modified:
> cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
>
> Modified: cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml
> URL: http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml?rev=606743&r1=606742&r2=606743&view=diff
> ==============================================================================
> --- cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml (original)
> +++ cocoon/branches/BRANCH_2_1_X/tools/targets/webapp-build.xml Mon Dec 24 14:03:31 2007
> @@ -25,33 +25,9 @@
> <target name="prepare-webapp" depends="blocks, package">
> <mkdir dir="${build.webapp}"/>
>
> - <copy file="${webapp}/welcome.xml" tofile="${build.webapp}/welcome.xml" filtering="on"/>
> - <copy file="${webapp}/not-found.xml" tofile="${build.webapp}/not-found.xml" filtering="on"/>
> - <copy file="${webapp}/welcome.xslt" tofile="${build.webapp}/welcome.xslt" filtering="on"/>
> - <copy file="${webapp}/sitemap.xmap" tofile="${build.webapp}/sitemap.xmap"/>
> -
> - <!-- generate sitemap entries
> - <sitemap-components sitemap="${build.webapp}/sitemap.xmap" source="${java}"/>
> - -->
> -
> - <copy todir="${build.webapp}/stylesheets" filtering="on">
> - <fileset dir="${webapp}/stylesheets">
> - <include name="**/*.xslt"/>
> - </fileset>
> - </copy>
> -
> - <copy todir="${build.webapp}/resources" filtering="off">
> - <fileset dir="${webapp}/resources"/>
> - </copy>
> -
> - <copy todir="${build.webapp}/WEB-INF" filtering="on">
> - <fileset dir="${webapp}/WEB-INF">
> - <include name="entities/**"/>
> - <include name="classes/**"/>
> - <include name="*.x*"/>
> - <include name="properties/**"/>
> - </fileset>
> - </copy>
> + <copy todir="${build.webapp}" filtering="on">
> + <fileset dir="${webapp}"/>
> + </copy>
>
> <copy file="${build}/${name}.jar"
> tofile="${build.webapp.lib}/${name}-${version}.jar"/>
>
>