Building Java code: Ant improvements, and better IDE integration

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Building Java code: Ant improvements, and better IDE integration

Damjan Jovanovic
Hi

Building AOO's Java code is currently mostly done with dmake and gbuild.
Both are ugly, unsupported by Java IDEs, and impossibly problematic with
some development I've been doing, so I began looking for an alternative.

It turns out we also have Ant, which is well established, supported by most
Java IDEs, and already a build requirement for AOO. But it's not that
widely used in AOO at the moment, only called from dmake, and used in a
very ugly way: dmake passes lots of properties to Ant to specify build
settings and paths to dependencies, making the build.xml file useless
without dmake - when Eclipse opens it, the dependencies are missing, as the
properties they would be in aren't set.

So I was thinking, why does Ant have to go through dmake? Can't it work out
settings from the ./configure output the way dmake and gbuild do?

Apparently, it can! As of revision 1804591, I've changed main/set_soenv.in
to also write variables into a main/ant.properties file, in addition to the
usual main/LinuxX86Env.Set.sh (which we "source"). The Ant project's
build.xml can then include this file (eg. using <property
file="../ant.properties"/>), and have available all the properties that
normally exist as environment variables. It can then use those properties
to work out build settings and paths to dependencies.

This means:
1. No "source LinuxX86Env.Set.sh" is necessary for Ant to work.
2. Ant operates independently and can build that individual project by
itself, without being called from a parent build tool like dmake.
3. (At least) Eclipse can now cleanly open the Ant build.xml, find all the
JARs it depends on, and successfully compile the project :-).

The only minor problem is that Eclipse writes the .class files into a
"build" directory in the project instead of the module's output directory
where Ant does, but that's probably because the module output directory
isn't a subdirectory of the project directory.

I've only changed main/connectivity/java/sdbc_hsqldb uses these Ant
improvements for now, but I plan to add more.

Damjan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building Java code: Ant improvements, and better IDE integration

Peter Kovacs-3
Soooooo +1 :D

Am 9. August 2017 19:50:42 MESZ schrieb Damjan Jovanovic <[hidden email]>:

>Hi
>
>Building AOO's Java code is currently mostly done with dmake and
>gbuild.
>Both are ugly, unsupported by Java IDEs, and impossibly problematic
>with
>some development I've been doing, so I began looking for an
>alternative.
>
>It turns out we also have Ant, which is well established, supported by
>most
>Java IDEs, and already a build requirement for AOO. But it's not that
>widely used in AOO at the moment, only called from dmake, and used in a
>very ugly way: dmake passes lots of properties to Ant to specify build
>settings and paths to dependencies, making the build.xml file useless
>without dmake - when Eclipse opens it, the dependencies are missing, as
>the
>properties they would be in aren't set.
>
>So I was thinking, why does Ant have to go through dmake? Can't it work
>out
>settings from the ./configure output the way dmake and gbuild do?
>
>Apparently, it can! As of revision 1804591, I've changed
>main/set_soenv.in
>to also write variables into a main/ant.properties file, in addition to
>the
>usual main/LinuxX86Env.Set.sh (which we "source"). The Ant project's
>build.xml can then include this file (eg. using <property
>file="../ant.properties"/>), and have available all the properties that
>normally exist as environment variables. It can then use those
>properties
>to work out build settings and paths to dependencies.
>
>This means:
>1. No "source LinuxX86Env.Set.sh" is necessary for Ant to work.
>2. Ant operates independently and can build that individual project by
>itself, without being called from a parent build tool like dmake.
>3. (At least) Eclipse can now cleanly open the Ant build.xml, find all
>the
>JARs it depends on, and successfully compile the project :-).
>
>The only minor problem is that Eclipse writes the .class files into a
>"build" directory in the project instead of the module's output
>directory
>where Ant does, but that's probably because the module output directory
>isn't a subdirectory of the project directory.
>
>I've only changed main/connectivity/java/sdbc_hsqldb uses these Ant
>improvements for now, but I plan to add more.
>
>Damjan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building Java code: Ant improvements, and better IDE integration

Carl Marcum
In reply to this post by Damjan Jovanovic
On 08/09/2017 01:50 PM, Damjan Jovanovic wrote:

> Hi
>
> Building AOO's Java code is currently mostly done with dmake and gbuild.
> Both are ugly, unsupported by Java IDEs, and impossibly problematic with
> some development I've been doing, so I began looking for an alternative.
>
> It turns out we also have Ant, which is well established, supported by most
> Java IDEs, and already a build requirement for AOO. But it's not that
> widely used in AOO at the moment, only called from dmake, and used in a
> very ugly way: dmake passes lots of properties to Ant to specify build
> settings and paths to dependencies, making the build.xml file useless
> without dmake - when Eclipse opens it, the dependencies are missing, as the
> properties they would be in aren't set.
>
> So I was thinking, why does Ant have to go through dmake? Can't it work out
> settings from the ./configure output the way dmake and gbuild do?
>
> Apparently, it can! As of revision 1804591, I've changed main/set_soenv.in
> to also write variables into a main/ant.properties file, in addition to the
> usual main/LinuxX86Env.Set.sh (which we "source"). The Ant project's
> build.xml can then include this file (eg. using <property
> file="../ant.properties"/>), and have available all the properties that
> normally exist as environment variables. It can then use those properties
> to work out build settings and paths to dependencies.
>
> This means:
> 1. No "source LinuxX86Env.Set.sh" is necessary for Ant to work.
> 2. Ant operates independently and can build that individual project by
> itself, without being called from a parent build tool like dmake.
> 3. (At least) Eclipse can now cleanly open the Ant build.xml, find all the
> JARs it depends on, and successfully compile the project :-).
>
> The only minor problem is that Eclipse writes the .class files into a
> "build" directory in the project instead of the module's output directory
> where Ant does, but that's probably because the module output directory
> isn't a subdirectory of the project directory.
>
> I've only changed main/connectivity/java/sdbc_hsqldb uses these Ant
> improvements for now, but I plan to add more.
>
> Damjan
>

That sounds great !!

Thanks Damjan


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...