You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2005/10/09 21:52:45 UTC
new ant build
Hi,
I took some spare time this weekend to go over the build files for ant
and reworking them according to the discussion that we had a few days
ago. The ant build now builds only two targets: jar and jar-dep. Both
jars contain all class files if built on an JDK 1.4+. It will report
big warnings if either the JDBC or the logging dependency are missing.
I also did the following things:
* This is now ant 1.5+ only. No one should really use an older ant.
* The parser part is still ant 1.6+ only
* ant help is gone. Run ant -projecthelp
* New default target: world. Builds the jar, the javadocs and the docs
* Everything is built under bin/. Everything (*). If you nuke out the
bin dir, your distribution is pristine again. Even better, run
"ant clean"
(*) Not really. The examples still put their class files into the
examples directory. ant clean cleans that out, though.
* "ant package" now builds .zip and .tar.gz distribution files.
CAVEAT: .zip gets CRLF endings for DOS/Windows, .tar.gz gets LF
endings for Unix/Linux.
Please _TEST_! I know that all targets work independently for Linux
using JDK 1.4.2 and JDK 1.5. Please test on Windows, on MacOS or
whatever. Report problems!
TODOs:
1) Add automatic download of the jar dependencies from ibiblio, thus allowing
the .jar files to be removed from Subversion. Would reduce the download size
for people pulling the tree from Subversion. (And if you can do that, you will
also have a network connection to pull the jars from ibiblio.org). Similar
to the download targets built by the maven-generated build.xml file
2) move the auto-generated parser tree (.../runtime/parser) out of the main
source tree. This would allow a complete separation of the auto-generated code.
Would also help the various maven reports
3) alternatively: Don't build the parser sources inside src/java. Build into
bin/parser and require manual interaction to copy the changed files back. More
work (however, the parser isn't changed that often... :-) ) but allows us to
keep everything inside bin/
4) Bikeshed painting: Rework the examples to compile and run from bin/examples
I'd really like to put 1) in (if no one objects loudly I will anyway
later this week), would like to see some discussion about 2)/3)
whether this would be sensible and if yes what way to go.
I let 4) to anyone who wants to start contributing to Velocity. This
is an easy thing to do and will help you familiarize with the Velocity
build system.
Best regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: new ant build
Posted by Malcolm Edgar <ma...@gmail.com>.
Thats true, I was thinking of CVS
regards Malcolm Edgar
Re: new ant build
Posted by Will Glass-Husain <wg...@forio.com>.
Good point. I'm ok with the ibiblio approach then.
----- Original Message -----
From: "Henning P. Schmiedehausen" <hp...@intermeta.de>
Newsgroups: hometree.jakarta.velocity.dev
To: <ve...@jakarta.apache.org>
Sent: Monday, October 10, 2005 1:44 AM
Subject: Re: new ant build
> If you can download the source from Subversion (which goes through
> http), you should also be able to download the jars from ibiblio
> (which is also http). I see no firewall issue here.
>
> The bundled distributions (.tar.gz and .zip) will contain all the
> jars. So if you just get the distribution and want to start working,
> there will be no change for you.
>
> Reason for this is to get the size of Subversion checkouts down. This
> is some (relatively minor) strain on the Apache SCM infrastructure
> (disk space, bandwith, CPU) and it is unnecessary.
>
> Best regards
> Henning
>
>
>>regards Malcolm Edgar
>
>>On 10/10/05, Will Glass-Husain <wg...@forio.com> wrote:
>>>
>>> Great! This is a nice improvement.
>>>
>>> Just as a reminder, we should update the "Building Velocity" on the web
>>> page
>>> when this is all done with instructions. We should be sure to note ant
>>> 1.=
>>5
>>> is required.
>>>
>>> I'd like to keep building Velocity as simple as possible. (making it
>>> easy
>>> for new people to get into the source code and to get not-yet-released
>>> versions). That's behind my thoughts on...
>>>
>>> 1) automatic downloads. not convinced. Will this work reliably? I don't
>>> see a big deal in just including the jar files, allowing Velocity to be
>>> built quickly and easily.
>>>
>>> 2 / 3) parser code. I like option 3 better. Again, thinking in terms of
>>> making the code easy to understand for less experienced developers. It
>>> helps to have all required source code in one tree. (therefore, please
>>> leave Parser.java in src/java). I'm ok with moving "Parser.jjt" out as
>>> long
>>> as this is documented in a readme file and the "ant parser" task
>>> automatically copies the files into the right spot.
>>>
>>> 4) Let's put "reworking the examples" into JIRA targeted at 1.6. I
>>> agree,
>>> this is a nice todo for some future volunteer.
>>>
>>> Best,
>>> WILL
>>>
>>> ----- Original Message -----
>>> From: "Henning P. Schmiedehausen" <hp...@intermeta.de>
>>> Newsgroups: hometree.jakarta.velocity.dev
>>> To: <ve...@jakarta.apache.org>
>>> Sent: Sunday, October 09, 2005 12:52 PM
>>> Subject: new ant build
>>>
>>>
>>> > Hi,
>>> >
>>> > I took some spare time this weekend to go over the build files for ant
>>> > and reworking them according to the discussion that we had a few days
>>> > ago. The ant build now builds only two targets: jar and jar-dep. Both
>>> > jars contain all class files if built on an JDK 1.4+. It will report
>>> > big warnings if either the JDBC or the logging dependency are missing.
>>> >
>>> > I also did the following things:
>>> >
>>> > * This is now ant 1.5+ only. No one should really use an older ant.
>>> > * The parser part is still ant 1.6+ only
>>> > * ant help is gone. Run ant -projecthelp
>>> > * New default target: world. Builds the jar, the javadocs and the docs
>>> > * Everything is built under bin/. Everything (*). If you nuke out the
>>> > bin dir, your distribution is pristine again. Even better, run
>>> > "ant clean"
>>> > (*) Not really. The examples still put their class files into the
>>> > examples directory. ant clean cleans that out, though.
>>> > * "ant package" now builds .zip and .tar.gz distribution files.
>>> > CAVEAT: .zip gets CRLF endings for DOS/Windows, .tar.gz gets LF
>>> > endings for Unix/Linux.
>>> >
>>> > Please _TEST_! I know that all targets work independently for Linux
>>> > using JDK 1.4.2 and JDK 1.5. Please test on Windows, on MacOS or
>>> > whatever. Report problems!
>>> >
>>> > TODOs:
>>> >
>>> > 1) Add automatic download of the jar dependencies from ibiblio, thus
>>> > allowing
>>> > the .jar files to be removed from Subversion. Would reduce the
>>> > download
>>> > size
>>> > for people pulling the tree from Subversion. (And if you can do that,
>>> you
>>> > will
>>> > also have a network connection to pull the jars from
>>> > ibiblio.org<http:/=
>>/ibiblio.org>
>>> ).
>>> > Similar
>>> > to the download targets built by the maven-generated build.xml file
>>> >
>>> > 2) move the auto-generated parser tree (.../runtime/parser) out of the
>>> > main
>>> > source tree. This would allow a complete separation of the
>>> auto-generated
>>> > code.
>>> > Would also help the various maven reports
>>> >
>>> > 3) alternatively: Don't build the parser sources inside src/java.
>>> > Build
>>> > into
>>> > bin/parser and require manual interaction to copy the changed files
>>> back.
>>> > More
>>> > work (however, the parser isn't changed that often... :-) ) but allows
>>> us
>>> > to
>>> > keep everything inside bin/
>>> >
>>> > 4) Bikeshed painting: Rework the examples to compile and run from
>>> > bin/examples
>>> >
>>> > I'd really like to put 1) in (if no one objects loudly I will anyway
>>> > later this week), would like to see some discussion about 2)/3)
>>> > whether this would be sensible and if yes what way to go.
>>> >
>>> > I let 4) to anyone who wants to start contributing to Velocity. This
>>> > is an easy thing to do and will help you familiarize with the Velocity
>>> > build system.
>>> >
>>> > Best regards
>>> > Henning
>>> >
>>> > --
>>> > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
>>> > hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>>> >
>>> > RedHat Certified Engineer -- Jakarta Turbine Development -- hero for
>>> hire
>>> > Linux, Java, perl, Solaris -- Consulting, Training, Development
>>> >
>>> > 4 - 8 - 15 - 16 - 23 - 42
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>>> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>>
>>>
>
>>------=_Part_7383_30955477.1128900707778--
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> 4 - 8 - 15 - 16 - 23 - 42
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: new ant build
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Malcolm Edgar <ma...@gmail.com> writes:
>------=_Part_7383_30955477.1128900707778
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>Content-Disposition: inline
>Sounds good.
>Regarding the automatic downloads. I prefer dependencies to be bundled,
>sometimes you get stuck behind corporate firewalls gaining access to online
>resources becomes.
If you can download the source from Subversion (which goes through
http), you should also be able to download the jars from ibiblio
(which is also http). I see no firewall issue here.
The bundled distributions (.tar.gz and .zip) will contain all the
jars. So if you just get the distribution and want to start working,
there will be no change for you.
Reason for this is to get the size of Subversion checkouts down. This
is some (relatively minor) strain on the Apache SCM infrastructure
(disk space, bandwith, CPU) and it is unnecessary.
Best regards
Henning
>regards Malcolm Edgar
>On 10/10/05, Will Glass-Husain <wg...@forio.com> wrote:
>>
>> Great! This is a nice improvement.
>>
>> Just as a reminder, we should update the "Building Velocity" on the web
>> page
>> when this is all done with instructions. We should be sure to note ant 1.=
>5
>> is required.
>>
>> I'd like to keep building Velocity as simple as possible. (making it easy
>> for new people to get into the source code and to get not-yet-released
>> versions). That's behind my thoughts on...
>>
>> 1) automatic downloads. not convinced. Will this work reliably? I don't
>> see a big deal in just including the jar files, allowing Velocity to be
>> built quickly and easily.
>>
>> 2 / 3) parser code. I like option 3 better. Again, thinking in terms of
>> making the code easy to understand for less experienced developers. It
>> helps to have all required source code in one tree. (therefore, please
>> leave Parser.java in src/java). I'm ok with moving "Parser.jjt" out as
>> long
>> as this is documented in a readme file and the "ant parser" task
>> automatically copies the files into the right spot.
>>
>> 4) Let's put "reworking the examples" into JIRA targeted at 1.6. I agree,
>> this is a nice todo for some future volunteer.
>>
>> Best,
>> WILL
>>
>> ----- Original Message -----
>> From: "Henning P. Schmiedehausen" <hp...@intermeta.de>
>> Newsgroups: hometree.jakarta.velocity.dev
>> To: <ve...@jakarta.apache.org>
>> Sent: Sunday, October 09, 2005 12:52 PM
>> Subject: new ant build
>>
>>
>> > Hi,
>> >
>> > I took some spare time this weekend to go over the build files for ant
>> > and reworking them according to the discussion that we had a few days
>> > ago. The ant build now builds only two targets: jar and jar-dep. Both
>> > jars contain all class files if built on an JDK 1.4+. It will report
>> > big warnings if either the JDBC or the logging dependency are missing.
>> >
>> > I also did the following things:
>> >
>> > * This is now ant 1.5+ only. No one should really use an older ant.
>> > * The parser part is still ant 1.6+ only
>> > * ant help is gone. Run ant -projecthelp
>> > * New default target: world. Builds the jar, the javadocs and the docs
>> > * Everything is built under bin/. Everything (*). If you nuke out the
>> > bin dir, your distribution is pristine again. Even better, run
>> > "ant clean"
>> > (*) Not really. The examples still put their class files into the
>> > examples directory. ant clean cleans that out, though.
>> > * "ant package" now builds .zip and .tar.gz distribution files.
>> > CAVEAT: .zip gets CRLF endings for DOS/Windows, .tar.gz gets LF
>> > endings for Unix/Linux.
>> >
>> > Please _TEST_! I know that all targets work independently for Linux
>> > using JDK 1.4.2 and JDK 1.5. Please test on Windows, on MacOS or
>> > whatever. Report problems!
>> >
>> > TODOs:
>> >
>> > 1) Add automatic download of the jar dependencies from ibiblio, thus
>> > allowing
>> > the .jar files to be removed from Subversion. Would reduce the download
>> > size
>> > for people pulling the tree from Subversion. (And if you can do that,
>> you
>> > will
>> > also have a network connection to pull the jars from ibiblio.org<http:/=
>/ibiblio.org>
>> ).
>> > Similar
>> > to the download targets built by the maven-generated build.xml file
>> >
>> > 2) move the auto-generated parser tree (.../runtime/parser) out of the
>> > main
>> > source tree. This would allow a complete separation of the
>> auto-generated
>> > code.
>> > Would also help the various maven reports
>> >
>> > 3) alternatively: Don't build the parser sources inside src/java. Build
>> > into
>> > bin/parser and require manual interaction to copy the changed files
>> back.
>> > More
>> > work (however, the parser isn't changed that often... :-) ) but allows
>> us
>> > to
>> > keep everything inside bin/
>> >
>> > 4) Bikeshed painting: Rework the examples to compile and run from
>> > bin/examples
>> >
>> > I'd really like to put 1) in (if no one objects loudly I will anyway
>> > later this week), would like to see some discussion about 2)/3)
>> > whether this would be sensible and if yes what way to go.
>> >
>> > I let 4) to anyone who wants to start contributing to Velocity. This
>> > is an easy thing to do and will help you familiarize with the Velocity
>> > build system.
>> >
>> > Best regards
>> > Henning
>> >
>> > --
>> > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
>> > hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>> >
>> > RedHat Certified Engineer -- Jakarta Turbine Development -- hero for
>> hire
>> > Linux, Java, perl, Solaris -- Consulting, Training, Development
>> >
>> > 4 - 8 - 15 - 16 - 23 - 42
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>>
>------=_Part_7383_30955477.1128900707778--
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: new ant build
Posted by Malcolm Edgar <ma...@gmail.com>.
Sounds good.
Regarding the automatic downloads. I prefer dependencies to be bundled,
sometimes you get stuck behind corporate firewalls gaining access to online
resources becomes.
regards Malcolm Edgar
On 10/10/05, Will Glass-Husain <wg...@forio.com> wrote:
>
> Great! This is a nice improvement.
>
> Just as a reminder, we should update the "Building Velocity" on the web
> page
> when this is all done with instructions. We should be sure to note ant 1.5
> is required.
>
> I'd like to keep building Velocity as simple as possible. (making it easy
> for new people to get into the source code and to get not-yet-released
> versions). That's behind my thoughts on...
>
> 1) automatic downloads. not convinced. Will this work reliably? I don't
> see a big deal in just including the jar files, allowing Velocity to be
> built quickly and easily.
>
> 2 / 3) parser code. I like option 3 better. Again, thinking in terms of
> making the code easy to understand for less experienced developers. It
> helps to have all required source code in one tree. (therefore, please
> leave Parser.java in src/java). I'm ok with moving "Parser.jjt" out as
> long
> as this is documented in a readme file and the "ant parser" task
> automatically copies the files into the right spot.
>
> 4) Let's put "reworking the examples" into JIRA targeted at 1.6. I agree,
> this is a nice todo for some future volunteer.
>
> Best,
> WILL
>
> ----- Original Message -----
> From: "Henning P. Schmiedehausen" <hp...@intermeta.de>
> Newsgroups: hometree.jakarta.velocity.dev
> To: <ve...@jakarta.apache.org>
> Sent: Sunday, October 09, 2005 12:52 PM
> Subject: new ant build
>
>
> > Hi,
> >
> > I took some spare time this weekend to go over the build files for ant
> > and reworking them according to the discussion that we had a few days
> > ago. The ant build now builds only two targets: jar and jar-dep. Both
> > jars contain all class files if built on an JDK 1.4+. It will report
> > big warnings if either the JDBC or the logging dependency are missing.
> >
> > I also did the following things:
> >
> > * This is now ant 1.5+ only. No one should really use an older ant.
> > * The parser part is still ant 1.6+ only
> > * ant help is gone. Run ant -projecthelp
> > * New default target: world. Builds the jar, the javadocs and the docs
> > * Everything is built under bin/. Everything (*). If you nuke out the
> > bin dir, your distribution is pristine again. Even better, run
> > "ant clean"
> > (*) Not really. The examples still put their class files into the
> > examples directory. ant clean cleans that out, though.
> > * "ant package" now builds .zip and .tar.gz distribution files.
> > CAVEAT: .zip gets CRLF endings for DOS/Windows, .tar.gz gets LF
> > endings for Unix/Linux.
> >
> > Please _TEST_! I know that all targets work independently for Linux
> > using JDK 1.4.2 and JDK 1.5. Please test on Windows, on MacOS or
> > whatever. Report problems!
> >
> > TODOs:
> >
> > 1) Add automatic download of the jar dependencies from ibiblio, thus
> > allowing
> > the .jar files to be removed from Subversion. Would reduce the download
> > size
> > for people pulling the tree from Subversion. (And if you can do that,
> you
> > will
> > also have a network connection to pull the jars from ibiblio.org<http://ibiblio.org>
> ).
> > Similar
> > to the download targets built by the maven-generated build.xml file
> >
> > 2) move the auto-generated parser tree (.../runtime/parser) out of the
> > main
> > source tree. This would allow a complete separation of the
> auto-generated
> > code.
> > Would also help the various maven reports
> >
> > 3) alternatively: Don't build the parser sources inside src/java. Build
> > into
> > bin/parser and require manual interaction to copy the changed files
> back.
> > More
> > work (however, the parser isn't changed that often... :-) ) but allows
> us
> > to
> > keep everything inside bin/
> >
> > 4) Bikeshed painting: Rework the examples to compile and run from
> > bin/examples
> >
> > I'd really like to put 1) in (if no one objects loudly I will anyway
> > later this week), would like to see some discussion about 2)/3)
> > whether this would be sensible and if yes what way to go.
> >
> > I let 4) to anyone who wants to start contributing to Velocity. This
> > is an easy thing to do and will help you familiarize with the Velocity
> > build system.
> >
> > Best regards
> > Henning
> >
> > --
> > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> > hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
> >
> > RedHat Certified Engineer -- Jakarta Turbine Development -- hero for
> hire
> > Linux, Java, perl, Solaris -- Consulting, Training, Development
> >
> > 4 - 8 - 15 - 16 - 23 - 42
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
Re: new ant build
Posted by Will Glass-Husain <wg...@forio.com>.
Great! This is a nice improvement.
Just as a reminder, we should update the "Building Velocity" on the web page
when this is all done with instructions. We should be sure to note ant 1.5
is required.
I'd like to keep building Velocity as simple as possible. (making it easy
for new people to get into the source code and to get not-yet-released
versions). That's behind my thoughts on...
1) automatic downloads. not convinced. Will this work reliably? I don't
see a big deal in just including the jar files, allowing Velocity to be
built quickly and easily.
2 / 3) parser code. I like option 3 better. Again, thinking in terms of
making the code easy to understand for less experienced developers. It
helps to have all required source code in one tree. (therefore, please
leave Parser.java in src/java). I'm ok with moving "Parser.jjt" out as long
as this is documented in a readme file and the "ant parser" task
automatically copies the files into the right spot.
4) Let's put "reworking the examples" into JIRA targeted at 1.6. I agree,
this is a nice todo for some future volunteer.
Best,
WILL
----- Original Message -----
From: "Henning P. Schmiedehausen" <hp...@intermeta.de>
Newsgroups: hometree.jakarta.velocity.dev
To: <ve...@jakarta.apache.org>
Sent: Sunday, October 09, 2005 12:52 PM
Subject: new ant build
> Hi,
>
> I took some spare time this weekend to go over the build files for ant
> and reworking them according to the discussion that we had a few days
> ago. The ant build now builds only two targets: jar and jar-dep. Both
> jars contain all class files if built on an JDK 1.4+. It will report
> big warnings if either the JDBC or the logging dependency are missing.
>
> I also did the following things:
>
> * This is now ant 1.5+ only. No one should really use an older ant.
> * The parser part is still ant 1.6+ only
> * ant help is gone. Run ant -projecthelp
> * New default target: world. Builds the jar, the javadocs and the docs
> * Everything is built under bin/. Everything (*). If you nuke out the
> bin dir, your distribution is pristine again. Even better, run
> "ant clean"
> (*) Not really. The examples still put their class files into the
> examples directory. ant clean cleans that out, though.
> * "ant package" now builds .zip and .tar.gz distribution files.
> CAVEAT: .zip gets CRLF endings for DOS/Windows, .tar.gz gets LF
> endings for Unix/Linux.
>
> Please _TEST_! I know that all targets work independently for Linux
> using JDK 1.4.2 and JDK 1.5. Please test on Windows, on MacOS or
> whatever. Report problems!
>
> TODOs:
>
> 1) Add automatic download of the jar dependencies from ibiblio, thus
> allowing
> the .jar files to be removed from Subversion. Would reduce the download
> size
> for people pulling the tree from Subversion. (And if you can do that, you
> will
> also have a network connection to pull the jars from ibiblio.org).
> Similar
> to the download targets built by the maven-generated build.xml file
>
> 2) move the auto-generated parser tree (.../runtime/parser) out of the
> main
> source tree. This would allow a complete separation of the auto-generated
> code.
> Would also help the various maven reports
>
> 3) alternatively: Don't build the parser sources inside src/java. Build
> into
> bin/parser and require manual interaction to copy the changed files back.
> More
> work (however, the parser isn't changed that often... :-) ) but allows us
> to
> keep everything inside bin/
>
> 4) Bikeshed painting: Rework the examples to compile and run from
> bin/examples
>
> I'd really like to put 1) in (if no one objects loudly I will anyway
> later this week), would like to see some discussion about 2)/3)
> whether this would be sensible and if yes what way to go.
>
> I let 4) to anyone who wants to start contributing to Velocity. This
> is an easy thing to do and will help you familiarize with the Velocity
> build system.
>
> Best regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> 4 - 8 - 15 - 16 - 23 - 42
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: new ant build
Posted by Nathan Bubna <nb...@gmail.com>.
On 10/9/05, Henning P. Schmiedehausen <hp...@intermeta.de> wrote:
> Hi,
>
> I took some spare time this weekend to go over the build files for ant
> and reworking them according to the discussion that we had a few days
> ago. The ant build now builds only two targets: jar and jar-dep. Both
> jars contain all class files if built on an JDK 1.4+. It will report
> big warnings if either the JDBC or the logging dependency are missing.
>
> I also did the following things:
>
> * This is now ant 1.5+ only. No one should really use an older ant.
> * The parser part is still ant 1.6+ only
> * ant help is gone. Run ant -projecthelp
> * New default target: world. Builds the jar, the javadocs and the docs
> * Everything is built under bin/. Everything (*). If you nuke out the
> bin dir, your distribution is pristine again. Even better, run
> "ant clean"
> (*) Not really. The examples still put their class files into the
> examples directory. ant clean cleans that out, though.
> * "ant package" now builds .zip and .tar.gz distribution files.
> CAVEAT: .zip gets CRLF endings for DOS/Windows, .tar.gz gets LF
> endings for Unix/Linux.
>
> Please _TEST_! I know that all targets work independently for Linux
> using JDK 1.4.2 and JDK 1.5. Please test on Windows, on MacOS or
> whatever. Report problems!
all sounds very cool. though as the tiniest of "bikeshed painting"
things, i would have called the default-catch-all target "all". :) i
don't really care though.
> TODOs:
>
> 1) Add automatic download of the jar dependencies from ibiblio, thus allowing
> the .jar files to be removed from Subversion. Would reduce the download size
> for people pulling the tree from Subversion. (And if you can do that, you will
> also have a network connection to pull the jars from ibiblio.org). Similar
> to the download targets built by the maven-generated build.xml file
+1 as long as the bundled distribution(s) have the jars with them.
and then i can copy/hack your ant code for this into velocity-tools.
:)
> 2) move the auto-generated parser tree (.../runtime/parser) out of the main
> source tree. This would allow a complete separation of the auto-generated code.
> Would also help the various maven reports
+1 this would have kept me from some pointless tweaking of generated
files when making my logging patch. i often do
search-then-jump-to-line stuff when editing code. i'm much more
likely to notice that a file is generated if it is in a different
directory than if it merely says (or even screams) that it is
generated in its headers. i also like increasing the usefulness of
the "free" reports we get from maven.
> 3) alternatively: Don't build the parser sources inside src/java. Build into
> bin/parser and require manual interaction to copy the changed files back. More
> work (however, the parser isn't changed that often... :-) ) but allows us to
> keep everything inside bin/
-0 i could live with it, but i prefer #2
> 4) Bikeshed painting: Rework the examples to compile and run from bin/examples
>
> I'd really like to put 1) in (if no one objects loudly I will anyway
> later this week), would like to see some discussion about 2)/3)
> whether this would be sensible and if yes what way to go.
>
> I let 4) to anyone who wants to start contributing to Velocity. This
> is an easy thing to do and will help you familiarize with the Velocity
> build system.
>
> Best regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> 4 - 8 - 15 - 16 - 23 - 42
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org