You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2004/02/15 13:06:15 UTC
Re: cvs commit: cocoon-2.1/legal LICENSE.ant
On 15.02.2004 11:15, antonio@apache.org wrote:
> antonio 2004/02/15 02:15:56
>
> Modified: . status.xml
> tools/lib ant-launcher.jar ant-trax.jar ant-junit.jar
> tools/bin complete-ant-cmd.pl ant.bat antRun.bat antRun
> antRun.pl runant.pl ant runant.py lcp.bat
All the Windows files you touched now seem to have a line ending issue.
> src/blocks/ojb/lib db-ojb-1.0.rc5-20040203.jar
What happened here?
> legal LICENSE.ant
This file does not reference Ant in any way, it's just the common Apache
license. Should this be correct?
> Added: . local.blocks.properties1 local.build.properties1
These both files should not be here I guess.
> tools/lib ant.jar
Version?
> tools/bin antenv.cmd runrc.cmd ant.cmd envset.cmd
Do we need them now? Furthermore they seem to have the wrong
license/copyright hint now.
> Removed: tools/lib ant-1.6.0.jar
> tools/bin create-repository-jars.sh
Why this? It was added only short time ago.
Joerg
Re: whitespace cleanup and efficiency drive
Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.02.2004 06:17, David Crossley wrote:
> I have a big list of what should be a text file extension in the
> binarytext.pl script. Perhaps we need to change our license files
> to have a .txt filename extension.
What about ${lib}.legal instead of current legal.${lib}?
> Thanks Joerg, for your important discovery and follow-up work.
> Yes i would rather work on "real" features, but i think that it
> is very important to have an efficient CVS, so i do not mind doing
> this type of work too.
But if there is no need for the one type of work you can do more of the
other type :)
Joerg
Re: whitespace cleanup and efficiency drive
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Bertrand Delacretaz wrote:
> Le Mercredi, 3 mars 2004, à 11:16 Europe/Zurich, David Crossley a écrit :
>
>> ...I wonder if it is true that almost every committer uses Eclipse?
>> I use command-line cvs.
>
>
> FWIW, I use IDEA, and often command-line CVS as well.
> The transparency of the command-line makes me feel safer ;-)
I have IDEA but had not time yet to try its CVS client (...it requires
to change cvsroot...), so I'm using command line.
Vadim
Re: whitespace cleanup and efficiency drive
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mercredi, 3 mars 2004, à 11:16 Europe/Zurich, David Crossley a écrit
:
> ...I wonder if it is true that almost every committer uses Eclipse?
> I use command-line cvs.
FWIW, I use IDEA, and often command-line CVS as well.
The transparency of the command-line makes me feel safer ;-)
-Bertrand
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@apache.org>.
Joerg Heinicke wrote:
> Vadim Gritsenko wrote:
> >David Crossley wrote:
> >>
> >> The recent commit of all the *.license files proved that Eclipse
> >> is the culprit. Until their Bug 15119 is fixed (please vote for it),
> >> the Eclipse users should use the workaround to add the unknown
> >> text types.
> >>
> >> The find_binary_text.pl script reports these problems:
> >> .ai
> >> .css
> >> .dtd
> >> .gt
> >> .in
> > ...
> >
> > You know that you can use cvs admin to change keyword substitution, right?
>
> Of course, but you *have* to do it as Eclipse uses binary as default and
> not text like the command line cvs client. We never took care about it
> as it probably never was a problem. But since almost everybody seems to
> use Eclipse also for committing and especially adding files we had some
> issues in our CVS.
Thanks Vadim, yes we know that we can use 'cvs admin' - Joerg and i
have been doing that to manually fix the mess that people create by
using Eclipse in its current state.
I wonder if it is true that almost every committer uses Eclipse?
I use command-line cvs.
--David
Re: whitespace cleanup and efficiency drive
Posted by Joerg Heinicke <jo...@gmx.de>.
On 02.03.2004 14:34, Vadim Gritsenko wrote:
>>> We have quite a number of these problem files in cocoon-2.1
>>> I noticed a new one come in today with Carsten's commit
>>> of portal.samplesxconf
>>>
>>
>>
>> The recent commit of all the *.license files proved that Eclipse
>> is the culprit. Until their Bug 15119 is fixed (please vote for it),
>> the Eclipse users should use the workaround to add the unknown
>> text types.
>>
>> The find_binary_text.pl script reports these problems:
>> .ai
>> .css
>> .dtd
>> .gt
>> .in
>>
>>
> ...
>
> You know that you can use cvs admin to change keyword substitution, right?
Of course, but you *have* to do it as Eclipse uses binary as default and
not text like the command line cvs client. We never took care about it
as it probably never was a problem. But since almost everybody seems to
use Eclipse also for committing and especially adding files we had some
issues in our CVS.
Joerg
Re: whitespace cleanup and efficiency drive
Posted by Vadim Gritsenko <va...@reverycodes.com>.
David Crossley wrote:
>David Crossley wrote:
>
>
...
>>We have quite a number of these problem files in cocoon-2.1
>>I noticed a new one come in today with Carsten's commit
>>of portal.samplesxconf
>>
>>
>
>The recent commit of all the *.license files proved that Eclipse
>is the culprit. Until their Bug 15119 is fixed (please vote for it),
>the Eclipse users should use the workaround to add the unknown
>text types.
>
>The find_binary_text.pl script reports these problems:
>.ai
>.css
>.dtd
>.gt
>.in
>
>
...
You know that you can use cvs admin to change keyword substitution, right?
Vadim
[1] http://blog.reverycodes.com/archives/000007.html
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> Joerg Heinicke wrote:
> > Joerg Heinicke wrote:
> >
> > > I might be wrong but today I had the feeling that Eclipse just ignores
> > > the default -kkv set in Eclipse itself and adds every file with unknown
> > > file ending as binary. You maybe have to add your file endings at
> > > "Window > Preferences > Team > File Content".
> >
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=52333
>
> I made a better script which detects such problems in
> our CVS. It is now in the "committers" module:
> cvs/committers/tools/find_binary_text.pl
>
> We have quite a number of these problem files in cocoon-2.1
> I noticed a new one come in today with Carsten's commit
> of portal.samplesxconf
The recent commit of all the *.license files proved that Eclipse
is the culprit. Until their Bug 15119 is fixed (please vote for it),
the Eclipse users should use the workaround to add the unknown
text types.
The find_binary_text.pl script reports these problems:
.ai
.css
.dtd
.gt
.in
.jar-lincense
.jdo
.jj
.js
.jx
.license
.mod
.pagesheet
.samplesxconf
.svg
.template
.xconf
.xhtml
.xmap
.xmi
.xroles
.xsamples
.xsl
.xslt
.xsp
.xtest
.xweb
.xwelcome
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@apache.org>.
Joerg Heinicke wrote:
> Joerg Heinicke wrote:
>
> > I might be wrong but today I had the feeling that Eclipse just ignores
> > the default -kkv set in Eclipse itself and adds every file with unknown
> > file ending as binary. You maybe have to add your file endings at
> > "Window > Preferences > Team > File Content".
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=52333
I made a better script which detects such problems in
our CVS. It is now in the "committers" module:
cvs/committers/tools/find_binary_text.pl
We have quite a number of these problem files in cocoon-2.1
I noticed a new one come in today with Carsten's commit
of portal.samplesxconf
--David
Re: whitespace cleanup and efficiency drive
Posted by Joerg Heinicke <jo...@gmx.de>.
On 18.02.2004 02:32, Joerg Heinicke wrote:
> I might be wrong but today I had the feeling that Eclipse just ignores
> the default -kkv set in Eclipse itself and adds every file with unknown
> file ending as binary. You maybe have to add your file endings at
> "Window > Preferences > Team > File Content".
https://bugs.eclipse.org/bugs/show_bug.cgi?id=52333
Joerg
Re: whitespace cleanup and efficiency drive
Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.02.2004 07:09, Bertrand Delacretaz wrote:
>> The -k option is only for 'add' and 'update' etc.
>>
>> The default with the command-line client is to do ASCII and you
>> need to explicitly do 'cvs add -kb' for images, and jar files, etc....
>
>
> Note also that the binary -kb flag is set automatically when adding
> certain file types, based on patterns defined in CVSROOT/cvswrappers
> (which we cannot change, belongs to the cvsadmin group).
I knew this setting, but this is not the problem of our binary adds as
only few and really binary file endings are set there.
I might be wrong but today I had the feeling that Eclipse just ignores
the default -kkv set in Eclipse itself and adds every file with unknown
file ending as binary. You maybe have to add your file endings at
"Window > Preferences > Team > File Content".
Joerg
Re: whitespace cleanup and efficiency drive
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 17 fév 2004, à 06:17 Europe/Zurich, David Crossley a écrit :
> ...
> The -k option is only for 'add' and 'update' etc.
>
> The default with the command-line client is to do ASCII and you
> need to explicitly do 'cvs add -kb' for images, and jar files, etc....
Note also that the binary -kb flag is set automatically when adding
certain file types, based on patterns defined in CVSROOT/cvswrappers
(which we cannot change, belongs to the cvsadmin group).
See
http://cvs.apache.org/viewcvs.cgi/CVSROOT/cvswrappers?rev=HEAD
-Bertrand
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@apache.org>.
[Changing the subject and hopefully appending this good stuff
to the whitespace thread.
Was: Re: cvs commit: cocoon-2.1/legal LICENSE.ant]
Joerg Heinicke wrote:
> David Crossley wrote:
> >
> > Every time a UNIX-based committer receives files from somewhere
> > else (for example Buzgilla Patch or another project) then they
> > need to ensure that they do not have a Windows problem. Do a
> > 'dos2unix' on the files to fix them.
> >
> > For a Windows-based committer, they may need to do the opposite
> > (i do not know) and they definitely need to ensure that they
> > have a proper CVS client that converts the line endings to the
> > UNIX-style on commit.
>
> From the latest commit messages I found another reason for a line
> ending issue: many text files were committed as binary files and are so
> an almost guaranteed source of line endings problems. When committed
> from Unix David's line endings test is passed, but you can't view the
> files in Windows in little editors like notepad. When committed from
> Windows David's test fails, he fixes it and you can again not view the
> files in Windows. The problem is that binary files remain untouched when
> committed to CVS and so the line endings that the CVS client should
> handle in theory.
>
> What's the stuff in CVS? It's called keyword substitution and for
> binaries the value is set to -kb, for ASCII you have different
> possibilities (keyword replacement, keyword expansion, keywords
> untouched and some more), I simple chose the Eclipse default -kkv
> (expansion). I don't know how to do this from command line, but I guess
> simply by committing with the additional -kkv.
The -k option is only for 'add' and 'update' etc.
The default with the command-line client is to do ASCII and you
need to explicitly do 'cvs add -kb' for images, and jar files, etc.
> I chose Eclipse (Team >
> Change ASCII/Binary Property) and it was a bit of manual work (I felt
> like in the game Diablo: click & fight, but here where no monsters, only
> binary files ;). When adding 'CVS' to the label decorations (which I
> have done to see easily which files are locally modified) you also see
> whether the files are ASCII or binary - you only have to open and close
> all directories. It would be good to get this work done automatically,
> or at least the list of all binary files.
I had started a Perl script for another job and changed it to
deal with this. It operates on the output from 'cvs log'.
See the script on apache.org in my home directory
~crossley/bin/binarytext.pl
I have run it on the "woody" block and cannot see any problems.
Someone with more bandwidth could run it on the whole cocoon CVS.
> What can be done in future: Configure your CVS client correctly. From
> the blocks and their initial committers you see problem candidates:
>
> woody > htmlarea Ugo
> taglib
> portal, portal-fw Carsten
> ojb Antonio
> linotype Stefano
> eventcache Geoff
>
> We must not add files with (for the server unknown) file endings add
> "automatically", you must add them ASCII style (I know WinCVS has this
> explicitely, but I don't know about Eclipse). Another option is of
> course to set the file styles server side, but I don't know if we can do
> it for every file ending (imagine the files in legal), but at least for
> CSS, JS, XMAP, XROLES, XCONF, etc.
I have a big list of what should be a text file extension in the
binarytext.pl script. Perhaps we need to change our license files
to have a .txt filename extension.
> If David has observed the commits more deeper I guess many files were
> known to him for dos2unix commits. When paying attention to the
> ASCII/binary issue we will exempt him from this work to a certain extent
> and he can invest his time on real Cocoon or Forrest features :)
>
> Joerg
Thanks Joerg, for your important discovery and follow-up work.
Yes i would rather work on "real" features, but i think that it
is very important to have an efficient CVS, so i do not mind doing
this type of work too.
--David
Re: cvs commit: cocoon-2.1/legal LICENSE.ant
Posted by Joerg Heinicke <jo...@gmx.de>.
On 16.02.2004 07:55, David Crossley wrote:
>>>All the Windows files you touched now seem to have a line ending issue.
>>
>>How I can solve this?
>
> Every time a UNIX-based committer receives files from somewhere
> else (for example Buzgilla Patch or another project) then they
> need to ensure that they do not have a Windows problem. Do a
> 'dos2unix' on the files to fix them.
>
> For a Windows-based committer, they may need to do the opposite
> (i do not know) and they definitely need to ensure that they
> have a proper CVS client that converts the line endings to the
> UNIX-style on commit.
From the latest commit messages I found another reason for a line
ending issue: many text files were committed as binary files and are so
an almost guaranteed source of line endings problems. When committed
from Unix David's line endings test is passed, but you can't view the
files in Windows in little editors like notepad. When committed from
Windows David's test fails, he fixes it and you can again not view the
files in Windows. The problem is that binary files remain untouched when
committed to CVS and so the line endings that the CVS client should
handle in theory.
What's the stuff in CVS? It's called keyword substitution and for
binaries the value is set to -kb, for ASCII you have different
possibilities (keyword replacement, keyword expansion, keywords
untouched and some more), I simple chose the Eclipse default -kkv
(expansion). I don't know how to do this from command line, but I guess
simply by committing with the additional -kkv. I chose Eclipse (Team >
Change ASCII/Binary Property) and it was a bit of manual work (I felt
like in the game Diablo: click & fight, but here where no monsters, only
binary files ;). When adding 'CVS' to the label decorations (which I
have done to see easily which files are locally modified) you also see
whether the files are ASCII or binary - you only have to open and close
all directories. It would be good to get this work done automatically,
or at least the list of all binary files.
What can be done in future: Configure your CVS client correctly. From
the blocks and their initial committers you see problem candidates:
woody > htmlarea Ugo
taglib
portal, portal-fw Carsten
ojb Antonio
linotype Stefano
eventcache Geoff
We must not add files with (for the server unknown) file endings add
"automatically", you must add them ASCII style (I know WinCVS has this
explicitely, but I don't know about Eclipse). Another option is of
course to set the file styles server side, but I don't know if we can do
it for every file ending (imagine the files in legal), but at least for
CSS, JS, XMAP, XROLES, XCONF, etc.
If David has observed the commits more deeper I guess many files were
known to him for dos2unix commits. When paying attention to the
ASCII/binary issue we will exempt him from this work to a certain extent
and he can invest his time on real Cocoon or Forrest features :)
Joerg
Re: cvs commit: cocoon-2.1/legal LICENSE.ant
Posted by David Crossley <cr...@apache.org>.
Antonio Gallardo wrote:
> Joerg Heinicke dijo:
<snip/>
> > All the Windows files you touched now seem to have a line ending issue.
>
> How I can solve this?
Every time a UNIX-based committer receives files from somewhere
else (for example Buzgilla Patch or another project) then they
need to ensure that they do not have a Windows problem. Do a
'dos2unix' on the files to fix them.
For a Windows-based committer, they may need to do the opposite
(i do not know) and they definitely need to ensure that they
have a proper CVS client that converts the line endings to the
UNIX-style on commit.
--David
Re: cvs commit: cocoon-2.1/legal LICENSE.ant
Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke dijo:
> On 15.02.2004 11:15, antonio@apache.org wrote:
>> antonio 2004/02/15 02:15:56
>>
>> Modified: . status.xml
>> tools/lib ant-launcher.jar ant-trax.jar ant-junit.jar
>> tools/bin complete-ant-cmd.pl ant.bat antRun.bat antRun
>> antRun.pl runant.pl ant runant.py lcp.bat
>
> All the Windows files you touched now seem to have a line ending issue.
How I can solve this?
>
>> src/blocks/ojb/lib db-ojb-1.0.rc5-20040203.jar
>
> What happened here?
I think it is OK. No problem using this file. Just the date must be 20040214.
>
>> legal LICENSE.ant
>
> This file does not reference Ant in any way, it's just the common Apache
> license. Should this be correct?
Is OK if I fill the file instead of ant people? Is here somebody that can
alert ant people about this issue?
>
>> Added: . local.blocks.properties1 local.build.properties1
>
> These both files should not be here I guess.
Fixed in CVS.
>
>> tools/lib ant.jar
>
> Version?
I think it is OK to let it as is now. If you not agree please tell me to
make the change.
>
>> tools/bin antenv.cmd runrc.cmd ant.cmd envset.cmd
>
> Do we need them now? Furthermore they seem to have the wrong
> license/copyright hint now.
What we can do here?
1. Remove the files
2. Change the header distributed by Ant
3. Leave them as they are now.
Please comment.
>
>> Removed: tools/lib ant-1.6.0.jar
>> tools/bin create-repository-jars.sh
"Undeleted" in CVS.
Best Regards,
Antonio Gallardo
Re: cvs commit: cocoon-2.1/legal LICENSE.ant
Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.02.2004 02:23, Antonio Gallardo wrote:
>>>>> src/blocks/ojb/lib db-ojb-1.0.rc5-20040203.jar
>>
>>Oh, that's an important issue! We will never get the correct source from
>>CVS if you switch the binary, but not the date! Please don't start with
>>such a Bad Thing (TM).
>
>
> Don't worry. It is just an internal approach. When I update the lib in the
> Cocoon CVS the normal procedure is also change the date of the lib:
Yes, I remember those changes. The more I was feared when the file was
changed.
> But because I was too sleepy I committed not desired files. Sorry again
> for my mistake.
So it was just another consequence of your tiredness and will never
happen again :)
Joerg
Re: cvs commit: cocoon-2.1/legal LICENSE.ant
Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke dijo:
> On 15.02.2004 13:30, Antonio Gallardo wrote:
>
>>>> src/blocks/ojb/lib db-ojb-1.0.rc5-20040203.jar
>>>
>>>What happened here?
>>
>> Locally I mantain a builded copy of ojb with the lastest changes. To
>> avoid
>> every day changing the name in libs.xml I rename it to the lastest
>> updated
>> version in Cocoon. Evidently it was my fault to send them. Anyway it is
>> a
>> working copy already tested of the jar.
>
> Oh, that's an important issue! We will never get the correct source from
> CVS if you switch the binary, but not the date! Please don't start with
> such a Bad Thing (TM).
Don't worry. It is just an internal approach. When I update the lib in the
Cocoon CVS the normal procedure is also change the date of the lib:
See line 954 in:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/lib/jars.xml?r1=1.159&r2=1.160&diff_format=h
See line 946 in:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/lib/jars.xml?r1=1.149&r2=1.150&diff_format=h
etc.
But because I was too sleepy I committed not desired files. Sorry again
for my mistake.
>
> File endings, local.*.properties1, deleted shell script - FIXED, thanks,
> ok.
>
>>>> legal LICENSE.ant
>>>
>>>This file does not reference Ant in any way, it's just the common Apache
>>>license. Should this be correct?
>>
>> I got this file from the root of the new Ant distribution. Seems like
>> they
>> did an error while updting the License.
>
>> Is OK if I fill the file instead of ant people? Is here somebody that
>> can
>> alert ant people about this issue?
>
> I don't know how to go on. I guess they should know it to have it fixed
> in their CVS also.
I will check and import it if they already did it. AFAIK, we cannot change
3rd party distribution. But can we change it in Ant case? I mean from the
legal side of the thing.
>
>>>> tools/lib ant.jar
>>>
>>>Version?
>>
>>
>> Last time I updated Ant. I noted some troubles in the scripts (.sh .bat)
>> used to run Ant. This time I tried to avoid this problem by simply
>> coping
>> the files without any internal change. Also the ant version is presented
>> as usual when we run the build.sh command. Knowing this I decided to not
>> rename the ant.jar. Note that this file is not copied in the Cocoon
>> distribution so the jar name validator does not check it.
>
> Ok, I can live with it. What do others think?
>
>>>> tools/bin antenv.cmd runrc.cmd ant.cmd envset.cmd
>>>
>>>Do we need them now? Furthermore they seem to have the wrong
>>>license/copyright hint now.
>>
>> I decided to include them because AFAIK, there are for Win NT/2000/XP
>> environment. Those files are included in ant. But if we don't need them
>> I
>> can remove it from the distribution.
>
>> What we can do here?
>>
>> 1. Remove the files
>> 2. Change the header distributed by Ant
>> 3. Leave them as they are now.
>>
>> Please comment.
>
> From what I can see these are new scripts and so simple starters for
> Ant. As we include Ant in our dist and provide our own ant scripts we
> can remove the files. For the licensing issue it's the same like above.
> I guess they confirm themselves before their next release that every
> licences are ok.
>
>> Thanks for pointing out all the errors I did, seems like I am too
>> sleepy. :-D
>
> You seemed to been so tired that you sent two different mails :)
Yep. I sleeped for 5 minuts before posting this second mail.
Best Regards,
Antonio Gallardo
Re: cvs commit: cocoon-2.1/legal LICENSE.ant
Posted by Joerg Heinicke <jo...@gmx.de>.
On 15.02.2004 13:30, Antonio Gallardo wrote:
>>> src/blocks/ojb/lib db-ojb-1.0.rc5-20040203.jar
>>
>>What happened here?
>
> Locally I mantain a builded copy of ojb with the lastest changes. To avoid
> every day changing the name in libs.xml I rename it to the lastest updated
> version in Cocoon. Evidently it was my fault to send them. Anyway it is a
> working copy already tested of the jar.
Oh, that's an important issue! We will never get the correct source from
CVS if you switch the binary, but not the date! Please don't start with
such a Bad Thing (TM).
File endings, local.*.properties1, deleted shell script - FIXED, thanks, ok.
>>> legal LICENSE.ant
>>
>>This file does not reference Ant in any way, it's just the common Apache
>>license. Should this be correct?
>
> I got this file from the root of the new Ant distribution. Seems like they
> did an error while updting the License.
> Is OK if I fill the file instead of ant people? Is here somebody that can
> alert ant people about this issue?
I don't know how to go on. I guess they should know it to have it fixed
in their CVS also.
>>> tools/lib ant.jar
>>
>>Version?
>
>
> Last time I updated Ant. I noted some troubles in the scripts (.sh .bat)
> used to run Ant. This time I tried to avoid this problem by simply coping
> the files without any internal change. Also the ant version is presented
> as usual when we run the build.sh command. Knowing this I decided to not
> rename the ant.jar. Note that this file is not copied in the Cocoon
> distribution so the jar name validator does not check it.
Ok, I can live with it. What do others think?
>>> tools/bin antenv.cmd runrc.cmd ant.cmd envset.cmd
>>
>>Do we need them now? Furthermore they seem to have the wrong
>>license/copyright hint now.
>
> I decided to include them because AFAIK, there are for Win NT/2000/XP
> environment. Those files are included in ant. But if we don't need them I
> can remove it from the distribution.
> What we can do here?
>
> 1. Remove the files
> 2. Change the header distributed by Ant
> 3. Leave them as they are now.
>
> Please comment.
From what I can see these are new scripts and so simple starters for
Ant. As we include Ant in our dist and provide our own ant scripts we
can remove the files. For the licensing issue it's the same like above.
I guess they confirm themselves before their next release that every
licences are ok.
> Thanks for pointing out all the errors I did, seems like I am too sleepy. :-D
You seemed to been so tired that you sent two different mails :)
Joerg
Re: cvs commit: cocoon-2.1/legal LICENSE.ant
Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke dijo:
> On 15.02.2004 11:15, antonio@apache.org wrote:
Opps. Seems like to many erros at all. Try to explain...
I just copied the files from apache-ant-1.6.1-bin.tar.gz.
>> antonio 2004/02/15 02:15:56
>>
>> Modified: . status.xml
>> tools/lib ant-launcher.jar ant-trax.jar ant-junit.jar
>> tools/bin complete-ant-cmd.pl ant.bat antRun.bat antRun
>> antRun.pl runant.pl ant runant.py lcp.bat
>
> All the Windows files you touched now seem to have a line ending issue.
>
>> src/blocks/ojb/lib db-ojb-1.0.rc5-20040203.jar
>
> What happened here?
Locally I mantain a builded copy of ojb with the lastest changes. To avoid
every day changing the name in libs.xml I rename it to the lastest updated
version in Cocoon. Evidently it was my fault to send them. Anyway it is a
working copy already tested of the jar.
>
>> legal LICENSE.ant
>
> This file does not reference Ant in any way, it's just the common Apache
> license. Should this be correct?
I got this file from the root of the new Ant distribution. Seems like they
did an error while updting the License.
>
>> Added: . local.blocks.properties1 local.build.properties1
>
> These both files should not be here I guess.
Yep. Same as the OJB issue. Sorry. Already fixed in CVS.
>
>> tools/lib ant.jar
>
> Version?
Last time I updated Ant. I noted some troubles in the scripts (.sh .bat)
used to run Ant. This time I tried to avoid this problem by simply coping
the files without any internal change. Also the ant version is presented
as usual when we run the build.sh command. Knowing this I decided to not
rename the ant.jar. Note that this file is not copied in the Cocoon
distribution so the jar name validator does not check it.
>
>> tools/bin antenv.cmd runrc.cmd ant.cmd envset.cmd
>
> Do we need them now? Furthermore they seem to have the wrong
> license/copyright hint now.
I decided to include them because AFAIK, there are for Win NT/2000/XP
environment. Those files are included in ant. But if we don't need them I
can remove it from the distribution.
>
>> Removed: tools/lib ant-1.6.0.jar
>> tools/bin create-repository-jars.sh
>
> Why this? It was added only short time ago.
Sorry, it was my mistake. I will retrieve it and send it again.
Thanks for pointing out all the errors I did, seems like I am too sleepy. :-D
Best Regards,
Antonio Gallardo