[Geoserver-devel] changing build file to compile to 1.4?

GeoServer GeoServer Developer
1

So through a series of silly mistakes (basically not rebuilding my
source tree for java 1.5), I ran across the ant tasks for javac. Two
of them are 'target' and 'source', and they highly recommend using
them, since it just defaults to whatever is the jvm. I'm thinking of
putting them into our build file to 1.4 explicitly, which I think
should catch errors of people who want to compile with 1.5 and
accidentally insert some method that is not in 1.4.

Any objections?

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Holmes wrote:

So through a series of silly mistakes (basically not rebuilding my
source tree for java 1.5), I ran across the ant tasks for javac. Two
of them are 'target' and 'source', and they highly recommend using
them, since it just defaults to whatever is the jvm. I'm thinking of
putting them into our build file to 1.4 explicitly, which I think
should catch errors of people who want to compile with 1.5 and
accidentally insert some method that is not in 1.4.

Hi

Would it not be good to avoid hard code in the build file?
If someone then want to try to compile and test with java 1.5 they need
to change the build file. And when changing the build file they are in
danger of committing the build file to the repository, which could break
compile for other users.

It is possible to use the <property file> target in ant.
This target will create a properties file, with the default entries set
in the target.

<propertyfile comment="Local properties file" file="local.properties">
  <entry default="1.4" key="sourceVersion"/>
</propertyfile>

The file will then be created if it does not exist, and the default
properties will be set ( sourceVersion = 1.4)
If the file exist, it will not be overwritten. This local.properties
file is not in the repository to it can't be committed.
Missing keys will also be added, so it we decide to add another key it
will be added, but leaving the others alone.

The compile target will then be something like this:
<javac source="${sourceVersion}">

To make "assert 1 == 1;" compile the source must be set in the target,
so I agree that it should be set.

I hope this is something to consider at least. :slight_smile:

Magne

Any objections?

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDdig9Djwfc5lfNZcRAgXIAKCvw9I2HK5dT6RuA1yIhADcWQW/cwCgg2tp
wJqpRPGHER2bWXt62aP52rg=
=GaoL
-----END PGP SIGNATURE-----

3

Quoting Magne Skjeret <magne.skjeret@anonymised.com>:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Holmes wrote:
> So through a series of silly mistakes (basically not rebuilding my
> source tree for java 1.5), I ran across the ant tasks for javac.
Two
> of them are 'target' and 'source', and they highly recommend using
> them, since it just defaults to whatever is the jvm. I'm thinking
of
> putting them into our build file to 1.4 explicitly, which I think
> should catch errors of people who want to compile with 1.5 and
> accidentally insert some method that is not in 1.4.

Hi

Would it not be good to avoid hard code in the build file?
If someone then want to try to compile and test with java 1.5 they
need
to change the build file. And when changing the build file they are
in
danger of committing the build file to the repository, which could
break
compile for other users.

Ah, a good thought. I would very much like the 'release' targets to be
sure to be in 1.4, so that we're sure to catch errors there, but it
shouldn't be that hard to do.

It is possible to use the <property file> target in ant.
This target will create a properties file, with the default entries
set
in the target.

<propertyfile comment="Local properties file"
file="local.properties">
  <entry default="1.4" key="sourceVersion"/>
</propertyfile>

The file will then be created if it does not exist, and the default
properties will be set ( sourceVersion = 1.4)
If the file exist, it will not be overwritten. This local.properties
file is not in the repository to it can't be committed.
Missing keys will also be added, so it we decide to add another key
it
will be added, but leaving the others alone.

The compile target will then be something like this:
<javac source="${sourceVersion}">

Oh we're all about setting properties, and I do make use of a
build.properties file for the test.type, see:
http://docs.codehaus.org/display/GEOSDOC/Build+Configuration for more
information, it's nice if you're working heavily with geoserver and
want to switch between several different configurations. Though we
should get the DATA_DIR up to snuff and get rid of the test.type
things.

But I didn't know about the propertyfile ant task, it sounds really
cool, I'll have to play with it some. Right now we just include a
build.property file and leave the values blank. I don't think I'll
have time to look into it soon, if you want to take a shot and
improving our build file then go for it. Add in the propertyfile task,
default to 1.4 for the source, and maybe put some of the other config
options in there. And then for release-common I think don't have it
depend on 'all', but rather set the source property to 1.4, and then
have it antcall 'all', so the compile happens with 1.4 for sure.

To make "assert 1 == 1;" compile the source must be set in the
target,
so I agree that it should be set.

Not sure I understand what you're saying, why does the source need to be
set for this to compile?

I hope this is something to consider at least. :slight_smile:

Definitely, indeed I'll ask you to do it :wink: You have a very good point,
and this is how we should be doing things. Indeed looking at the build
file, there's some other things that would be good to go in the
build.properties, like the NSIS_PATH, instead of making users set an
environmental variable, I think the build.properties is the way to do
it. Unless, Brent, does installing nsis automatically create that env
variable? Or are you relying on users to set it? If the latter then
we should put it in the sample build.properties.

Chris

Magne

>
> Any objections?
>
>
> ----------------------------------------------------------
> This mail sent through IMP: https://webmail.limegroup.com/
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
Download
> it for free - -and be entered to win a 42" plasma tv or your very
own
> Sony(tm)PSP. Click here to play:
http://sourceforge.net/geronimo.php
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDdig9Djwfc5lfNZcRAgXIAKCvw9I2HK5dT6RuA1yIhADcWQW/cwCgg2tp
wJqpRPGHER2bWXt62aP52rg=
=GaoL
-----END PGP SIGNATURE-----

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

4

Chris Holmes wrote:

Hi

I am not sure how things are going with java 5 with you(us) guys, but I have compiled my own geoserver war with java 5, and is also running in java 5. I have not yet found any errors that was due to java 5. In fact hardly any errors at all. So be proud of yourselves. :slight_smile:

I will certainly have a look at the properties file sometime soon. I have fiddled with build files for the last 4 years, and I think of myself as experienced. Still I find new targets and features that I have never realised existed. So don't feel down about the <propertyfile> target. (he he)

I really need to sit down and learn about all the code in the geoserver, and where all the bits and pieces comes to play. I see no better way of doing that than actually do work in the codebase.

Magne

Quoting Magne Skjeret <magne.skjeret@anonymised.com>:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Holmes wrote:
   

So through a series of silly mistakes (basically not rebuilding my
source tree for java 1.5), I ran across the ant tasks for javac.
     

Two
   

of them are 'target' and 'source', and they highly recommend using
them, since it just defaults to whatever is the jvm. I'm thinking
     

of
   

putting them into our build file to 1.4 explicitly, which I think
should catch errors of people who want to compile with 1.5 and
accidentally insert some method that is not in 1.4.
     

Hi

Would it not be good to avoid hard code in the build file?
If someone then want to try to compile and test with java 1.5 they
need
to change the build file. And when changing the build file they are
in
danger of committing the build file to the repository, which could
break
compile for other users.
   

Ah, a good thought. I would very much like the 'release' targets to be
sure to be in 1.4, so that we're sure to catch errors there, but it
shouldn't be that hard to do.

It is possible to use the <property file> target in ant.
This target will create a properties file, with the default entries
set
in the target.

<propertyfile comment="Local properties file"
file="local.properties">
<entry default="1.4" key="sourceVersion"/>
</propertyfile>

The file will then be created if it does not exist, and the default
properties will be set ( sourceVersion = 1.4)
If the file exist, it will not be overwritten. This local.properties
file is not in the repository to it can't be committed.
Missing keys will also be added, so it we decide to add another key
it
will be added, but leaving the others alone.

The compile target will then be something like this:
<javac source="${sourceVersion}">
   

Oh we're all about setting properties, and I do make use of a
build.properties file for the test.type, see:
http://docs.codehaus.org/display/GEOSDOC/Build+Configuration for more
information, it's nice if you're working heavily with geoserver and
want to switch between several different configurations. Though we
should get the DATA_DIR up to snuff and get rid of the test.type
things.

But I didn't know about the propertyfile ant task, it sounds really
cool, I'll have to play with it some. Right now we just include a
build.property file and leave the values blank. I don't think I'll
have time to look into it soon, if you want to take a shot and
improving our build file then go for it. Add in the propertyfile task,
default to 1.4 for the source, and maybe put some of the other config
options in there. And then for release-common I think don't have it
depend on 'all', but rather set the source property to 1.4, and then
have it antcall 'all', so the compile happens with 1.4 for sure.

To make "assert 1 == 1;" compile the source must be set in the
target,
so I agree that it should be set.
   

Not sure I understand what you're saying, why does the source need to be
set for this to compile?

I am not sure, but it wont. Unless I have done something horrible wrong in my build files.
The assert feature was new in java 1.4. And to turn it on, there needs to be source="1.4" or higher.

I hope this is something to consider at least. :slight_smile:
   

Definitely, indeed I'll ask you to do it :wink: You have a very good point,
and this is how we should be doing things. Indeed looking at the build
file, there's some other things that would be good to go in the
build.properties, like the NSIS_PATH, instead of making users set an
environmental variable, I think the build.properties is the way to do
it. Unless, Brent, does installing nsis automatically create that env
variable? Or are you relying on users to set it? If the latter then
we should put it in the sample build.properties.

Chris

Magne

Any objections?

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
     

Download
   

it for free - -and be entered to win a 42" plasma tv or your very
     

own
   

Sony(tm)PSP. Click here to play:
     

http://sourceforge.net/geronimo.php
   

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
     

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDdig9Djwfc5lfNZcRAgXIAKCvw9I2HK5dT6RuA1yIhADcWQW/cwCgg2tp
wJqpRPGHER2bWXt62aP52rg=
=GaoL
-----END PGP SIGNATURE-----

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

5

Chris Holmes wrote:

Hi

I am not sure how things are going with java 5 with you(us) guys, but I
have compiled my own geoserver war with java 5, and is also running in
java 5. I have not yet found any errors that was due to java 5. In fact
hardly any errors at all. So be proud of yourselves. :slight_smile:

Really? Do you already have xalan on your classpath somewhere? Because I
consistently get errors if it's not on the classpath, and many users do as
well.

I will certainly have a look at the properties file sometime soon. I
have fiddled with build files for the last 4 years, and I think of
myself as experienced. Still I find new targets and features that I have
never realised existed. So don't feel down about the <propertyfile>
target. (he he)

:slight_smile: No, I agree, there's almost no way to know the depth of targets,
indeed even if you're to master _all_ the core ant tasks, which is no mean
feat, there'sstill tons of user ones, like the NSIS one that Brent found.
Send an email with your findings, don't commit right away, so you give
developers a bit of warning for things being different.

I really need to sit down and learn about all the code in the geoserver,
and where all the bits and pieces comes to play. I see no better way of
doing that than actually do work in the codebase.

Definitely.

best regards,

Chris

Magne

>Quoting Magne Skjeret <magne.skjeret@anonymised.com>:
>
>
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Chris Holmes wrote:
>>
>>
>>>So through a series of silly mistakes (basically not rebuilding my
>>>source tree for java 1.5), I ran across the ant tasks for javac.
>>>
>>>
>>Two
>>
>>
>>>of them are 'target' and 'source', and they highly recommend using
>>>them, since it just defaults to whatever is the jvm. I'm thinking
>>>
>>>
>>of
>>
>>
>>>putting them into our build file to 1.4 explicitly, which I think
>>>should catch errors of people who want to compile with 1.5 and
>>>accidentally insert some method that is not in 1.4.
>>>
>>>
>>Hi
>>
>>Would it not be good to avoid hard code in the build file?
>>If someone then want to try to compile and test with java 1.5 they
>>need
>>to change the build file. And when changing the build file they are
>>in
>>danger of committing the build file to the repository, which could
>>break
>>compile for other users.
>>
>>
>Ah, a good thought. I would very much like the 'release' targets to be
>sure to be in 1.4, so that we're sure to catch errors there, but it
>shouldn't be that hard to do.
>
>
>
>>It is possible to use the <property file> target in ant.
>>This target will create a properties file, with the default entries
>>set
>>in the target.
>>
>><propertyfile comment="Local properties file"
>>file="local.properties">
>> <entry default="1.4" key="sourceVersion"/>
>></propertyfile>
>>
>>The file will then be created if it does not exist, and the default
>>properties will be set ( sourceVersion = 1.4)
>>If the file exist, it will not be overwritten. This local.properties
>>file is not in the repository to it can't be committed.
>>Missing keys will also be added, so it we decide to add another key
>>it
>>will be added, but leaving the others alone.
>>
>>The compile target will then be something like this:
>><javac source="${sourceVersion}">
>>
>>
>Oh we're all about setting properties, and I do make use of a
>build.properties file for the test.type, see:
>http://docs.codehaus.org/display/GEOSDOC/Build+Configuration for more
>information, it's nice if you're working heavily with geoserver and
>want to switch between several different configurations. Though we
>should get the DATA_DIR up to snuff and get rid of the test.type
>things.
>
>But I didn't know about the propertyfile ant task, it sounds really
>cool, I'll have to play with it some. Right now we just include a
>build.property file and leave the values blank. I don't think I'll
>have time to look into it soon, if you want to take a shot and
>improving our build file then go for it. Add in the propertyfile task,
>default to 1.4 for the source, and maybe put some of the other config
>options in there. And then for release-common I think don't have it
>depend on 'all', but rather set the source property to 1.4, and then
>have it antcall 'all', so the compile happens with 1.4 for sure.
>
>
>
>>To make "assert 1 == 1;" compile the source must be set in the
>>target,
>>so I agree that it should be set.
>>
>>
>Not sure I understand what you're saying, why does the source need to be
>set for this to compile?
>
>
I am not sure, but it wont. Unless I have done something horrible wrong
in my build files.
The assert feature was new in java 1.4. And to turn it on, there needs
to be source="1.4" or higher.

>
>
>>I hope this is something to consider at least. :slight_smile:
>>
>>
>Definitely, indeed I'll ask you to do it :wink: You have a very good point,
>and this is how we should be doing things. Indeed looking at the build
>file, there's some other things that would be good to go in the
>build.properties, like the NSIS_PATH, instead of making users set an
>environmental variable, I think the build.properties is the way to do
>it. Unless, Brent, does installing nsis automatically create that env
>variable? Or are you relying on users to set it? If the latter then
>we should put it in the sample build.properties.
>
>Chris
>
>
>
>>Magne
>>
>>
>>
>>>Any objections?
>>>
>>>
>>>----------------------------------------------------------
>>>This mail sent through IMP: https://webmail.limegroup.com/
>>>
>>>
>>>-------------------------------------------------------
>>>SF.Net email is sponsored by:
>>>Tame your development challenges with Apache's Geronimo App Server.
>>>
>>>
>>Download
>>
>>
>>>it for free - -and be entered to win a 42" plasma tv or your very
>>>
>>>
>>own
>>
>>
>>>Sony(tm)PSP. Click here to play:
>>>
>>>
>>http://sourceforge.net/geronimo.php
>>
>>
>>>_______________________________________________
>>>Geoserver-devel mailing list
>>>Geoserver-devel@lists.sourceforge.net
>>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.2.2 (MingW32)
>>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>>
>>iD8DBQFDdig9Djwfc5lfNZcRAgXIAKCvw9I2HK5dT6RuA1yIhADcWQW/cwCgg2tp
>>wJqpRPGHER2bWXt62aP52rg=
>>=GaoL
>>-----END PGP SIGNATURE-----
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by:
>>Tame your development challenges with Apache's Geronimo App Server.
>>Download
>>it for free - -and be entered to win a 42" plasma tv or your very own
>>Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
>>_______________________________________________
>>Geoserver-devel mailing list
>>Geoserver-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>>
>
>
>
>
>----------------------------------------------------------
>This mail sent through IMP: https://webmail.limegroup.com/
>
>

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--