[KIEKER-1297] Simplify Build Files

[rju]

JIRA Issue: KIEKER-1297 Simplify Build Files Original Reporter: Nils Christian Ehmke

---

Some months ago we tried to simplify our build.xml file by splitting it into multiple files ( KIEKER-807 Done ). However, this did not really simplify anything, except that we now have about 1000 LOCs spread over five files.

I suggest that we think about using another build tool or that we somehow try to simplify the whole build process. The current build configuration files are
- in my opinion
- unmaintainable.

An older idea was to use Maven, but I recommend not to use it. Our build process is way too complicate to use Maven. Maybe one should take a look into other build tools (e.g., Gradle).

More suggestions or opinions?

[rju]

author nils-christian -- Thu, 19 Jun 2014 11:57:19 +0200

As discussed in meeting: We would prefer ant over other build tools. Maybe we can still try and simplify the whole build process.

[rju]

author nils-christian -- Mon, 7 Jul 2014 12:37:49 +0200

I used the tool Grand to visualize the build process. I added them to this ticket. The first picture shows the build process during "build-all" (the default target), the second picture shows the complete build graph.

[rju]

author nils-christian -- Mon, 7 Jul 2014 12:40:22 +0200

We should also keep KIEKER-1416 Open in mind for this ticket. Maybe even move this ticket to an unknown future version?

[rju]

author nils-christian -- Thu, 31 Jul 2014 09:58:03 +0200

Some possible starting points:
- Is it really necessary to build the Kieker jar files six times during the nightly build?
- Is it really necessary to check the existence of specific files before and after the archiving?
- Is it really necessary to execute each test before and after the archiving?
- Is it really necessary to define the files includes in the zip and tar.gz archives twice in the build files?
- Is it really necessary to call the clean target that often?
- Are there any "dead" targets in the build files?
- Are there any "dead" properties in the properties file?
- We are compiling the single packages of Kieker in a specific order. Is this really necessary for the unit tests as well?
- We are compiling the single packages of Kieker in a specific order. Is it possible to use another tool to ensure this dependency instead?

[rju]

author André van Hoorn -- Thu, 31 Jul 2014 10:57:49 +0200

Replying to [nie|comment:5]:
> Some possible starting points:
>
- Is it really necessary to build the Kieker jar files six times during the nightly build?
>
- Is it really necessary to check the existence of specific files before and after the archiving?
>
- Is it really necessary to execute each test before and after the archiving?

These tests do what otherwise needs to be done manually to check whether a release is correct: for the source release: decompress source archives, release creation from the source archives (ant release) etc. In general, the check-release script is a response to issues that occurred during past releases. In order to reveal these problems automatically immediately after they are introduced (usually by accident), the check-release script has been created.

>
- Is it really necessary to define the files includes in the zip and tar.gz archives twice in the build files?

We could check whether there's a common way for zip and tar.gz in ant.

>
- Is it really necessary to call the clean target that often?

I assume that those calls come from separate ant invocations.

>
- Are there any "dead" targets in the build files?
>
- Are there any "dead" properties in the properties file?
>
- We are compiling the single packages of Kieker in a specific order. Is this really necessary for the unit tests as well?
>
- We are compiling the single packages of Kieker in a specific order. Is it possible to use another tool to ensure this dependency instead?

I get more and more to the feeling that we should give Maven a try. If a Kieker build with Maven is not possible, maybe our build is overcomplicated ...

[rju]

author nils-christian -- Thu, 31 Jul 2014 11:06:31 +0200

Replying to [avh|comment:6]:
> If a Kieker build with Maven is not possible, maybe our build is overcomplicated ...

It is. Although our framework is not that huge.

> I get more and more to the feeling that we should give Maven a try.

I have taken a look at a Maven-Build for Kieker some days ago. It is theoretically possible, but we do a lot of uncommon things during our build. This starts with a specific compilation order of packages (which is, as far as I know, not possible with Maven), continues over copying files all over the workspace, compiling examples and ends with the execution of platform-dependent bash scripts.

I we want to use Maven, we have to make cutbacks.

[rju]

author Jan Waller -- Thu, 31 Jul 2014 11:13:46 +0200

Maybe something competently different, like Buildr, ...?

[rju]

author André van Hoorn -- Thu, 31 Jul 2014 11:16:16 +0200

Replying to [nie|comment:7]:
> Replying to [avh|comment:6]:
> > If a Kieker build with Maven is not possible, maybe our build is overcomplicated ...
>
> It is. Although our framework is not that huge.

Definitely agree!

> > I get more and more to the feeling that we should give Maven a try.
>
> I have taken a look at a Maven-Build for Kieker some days ago. It is theoretically possible, but we do a lot of uncommon things during our build. This starts with a specific compilation order of packages (which is, as far as I know, not possible with Maven), continues over

I'd assume inter-dependent modules to be a common thing in configuration management. Should be supported by Maven.

> copying files all over the workspace, compiling examples and ends with the execution of platform-dependent bash scripts.

Many of the files we are copying around would probably find its place in Maven's resources folder.

> I we want to use Maven, we have to make cutbacks.

[rju]

author rju -- Thu, 31 Jul 2014 11:20:12 +0200

Before we decide on new tooling for the build system, we should find out what our requirements are for the build. For example:
- Code compilation
- Unit tests
- Code style checks
- packaging/bundling

- setting release/version numbers for final releases

- setting release/version numbers for nightly builds

- package validation

[rju]

author André van Hoorn -- Thu, 31 Jul 2014 11:27:33 +0200

Replying to [rju|comment:11]:
> Before we decide on new tooling for the build system, we should find out what our requirements are for the build. For example:
>
- Code compilation
>
- Unit tests
>
- Code style checks
>
- packaging/bundling
>
- setting release/version numbers for final releases
>
- setting release/version numbers for nightly builds
>
- package validation

Right, but I don't see any extraordinary requirements. Also, the build tool should be a common one and ideally be used by Eclipse's build (which is currently not the case for our Ant setup).

[rju]

author nils-christian -- Thu, 31 Jul 2014 16:38:37 +0200

We discussed a part of this here in Kiel. A survey of different Java build tools could be useful, before we decide (maybe even in form of a student work).

[rju]

author André van Hoorn -- Thu, 31 Jul 2014 16:44:58 +0200

Replying to [nie|comment:13]:
> We discussed a part of this here in Kiel. A survey of different Java build tools could be useful, before we decide (maybe even in form of a student work).

That's a good idea! Could be a topic for our Bachelor's "Fachstudien" in Stuttgart as well, because that's exactly in the scope of that type of project (evaluate and recommend tool/approach for specific requirements).

Adding thesis keyword to this tickets.

[rju]

author nils-christian -- Wed, 20 Aug 2014 12:14:34 +0200

Unlikely that this will be done until the 1.10 release.

[rju]

author nils-christian -- Thu, 21 Aug 2014 12:11:56 +0200

Started with this topic in a branch (KIEK-1297-build).

[rju]

author André van Hoorn -- Thu, 23 Oct 2014 16:40:20 +0200

Covered by KIEKER-1170 Done

[rju]

author nils-christian -- Mon, 23 Feb 2015 16:16:34 +0100

Invalid due to our new Gradle scripts.