[KIEKER-791] Clean up and update libraries

[rju]

JIRA Issue: https://kieker-monitoring.atlassian.net/browse/KIEKER-791 Original Reporter: Jan Waller (JIRA username)

---

The lib/ is very crowded.

We could move some libs into subfolders.

We should also check, if all libs are really needed.

Checklist:

JIRA Comments:

557058:78303123-c689-4415-9945-bb0c79591440 (JIRA username) added a comment on Fri, 15 Mar 2013 19:03:48

Take a look at a first try in 47fa254c738627d5a503128d361a753fd9022680

Some license files are still missing, some libs could be split and some removed.

557058:9e328f65-6e51-4aca-812b-82e63a91a0ae (JIRA username) added a comment on Fri, 15 Mar 2013 20:53:00

hm, looks strange to me and I'm not sure if this helps to build up another directory hierarchy at this place.

Also, wouldn't it be better to test this in a branch?

557058:9e328f65-6e51-4aca-812b-82e63a91a0ae (JIRA username) added a comment on Fri, 15 Mar 2013 20:55:44

What about moving this issue to 1.8?

557058:629db7ce-5cef-419f-82f8-3dcdebf76471 (JIRA username) added a comment on Fri, 15 Mar 2013 21:06:42

Replying to [avh|comment:3]:
> What about moving this issue to 1.8?

I agree. I think we should do this after the release (when we removed the deprecated classes etc). We can then clean up the code and the libs. In my opinion this is not an urgent matter.

557058:9e328f65-6e51-4aca-812b-82e63a91a0ae (JIRA username) added a comment on Fri, 15 Mar 2013 21:19:01

Replying to [nie|comment:4]:
> Replying to [avh|comment:3]:
> > What about moving this issue to 1.8?
>
> I agree. I think we should do this after the release (when we removed the deprecated classes etc). We can then clean up the code and the libs. In my opinion this is not an urgent matter.

Right. I would also have been quite surprised if the nightly wouldn't be broken after such change

557058:78303123-c689-4415-9945-bb0c79591440 (JIRA username) added a comment on Fri, 15 Mar 2013 22:49:51

This was already moved from before the 1.6 release.

The nightly is only broken because of missing license files. (and because of me being hungry and checking in, in order to get something to eat )

I think this can and should be done prior to a release and there is no reason not to do it now.

To the matter of the directory structure:
It makes it much easier to maintain the libraries dir, as now it is easy to see which libraries belong to which part, as especially cfx brings lots of libraries with less than obvious names.

557058:78303123-c689-4415-9945-bb0c79591440 (JIRA username) added a comment on Fri, 15 Mar 2013 23:55:06

As I said, just some minor missing lines and stuff

So, what does look strange? Can you be more specific?

557058:9e328f65-6e51-4aca-812b-82e63a91a0ae (JIRA username) added a comment on Sun, 17 Mar 2013 18:02:20

Replying to [jwa|comment:7]:
> As I said, just some minor missing lines and stuff
>
> So, what does look strange? Can you be more specific?

Having jars organized in subdirs under lib (currently framework-libs; note that I'm not talking about the static-analysis libs and the sigar natives). My expectation was that you will continue organizing all jars into subdirectories. Or wasn't this the plan? This is what I concluded from comment:1 ("Take a look at a first try").

557058:78303123-c689-4415-9945-bb0c79591440 (JIRA username) added a comment on Sun, 17 Mar 2013 18:06:52

I mostly wanted to sort cfx and spring away. They are very cluttery (does this work exist?) and only needed in special cases (when monitoring these technologies or running our tests for these monitoring probes).

Now, these libraries for special monitoring probes are separate from the more general purpose libraries.
There is no intention of further sorting (expect maybe aopalliance.jar which is part of spring if I remember correctly).

557058:9e328f65-6e51-4aca-812b-82e63a91a0ae (JIRA username) added a comment on Sun, 17 Mar 2013 18:09:17

Replying to [jwa|comment:9]:
> I mostly wanted to sort cfx and spring away. They are very cluttery (does this work exist?) and only needed in special cases (when monitoring these technologies or running our tests for these monitoring probes).
>
> Now, these libraries for special monitoring probes are separate from the more general purpose libraries.
> There is no intention of further sorting (expect maybe aopalliance.jar which is part of spring if I remember correctly).

Ok, I see; I really thought you wanted to create a complete organization structure for all libs (and nie probably, too). What about removing the additional framework-libs layer and simply putting them into spring and cxf.

557058:78303123-c689-4415-9945-bb0c79591440 (JIRA username) added a comment on Sun, 17 Mar 2013 18:52:04

Fine with me

557058:78303123-c689-4415-9945-bb0c79591440 (JIRA username) added a comment on Mon, 18 Mar 2013 09:22:58

fixed for now

[rju]

author Jan Waller -- Fri, 15 Mar 2013 19:03:48 +0100

Take a look at a first try in 47fa254c738627d5a503128d361a753fd9022680

Some license files are still missing, some libs could be split and some removed.

[rju]

author André van Hoorn -- Fri, 15 Mar 2013 20:53:00 +0100

hm, looks strange to me and I'm not sure if this helps to build up another directory hierarchy at this place.

Also, wouldn't it be better to test this in a branch?

[rju]

author André van Hoorn -- Fri, 15 Mar 2013 20:55:44 +0100

What about moving this issue to 1.8?

[rju]

author nils-christian -- Fri, 15 Mar 2013 21:06:42 +0100

Replying to [avh|comment:3]:
> What about moving this issue to 1.8?

I agree. I think we should do this after the release (when we removed the deprecated classes etc). We can then clean up the code and the libs. In my opinion this is not an urgent matter.

[rju]

author André van Hoorn -- Fri, 15 Mar 2013 21:19:01 +0100

Replying to [nie|comment:4]:
> Replying to [avh|comment:3]:
> > What about moving this issue to 1.8?
>
> I agree. I think we should do this after the release (when we removed the deprecated classes etc). We can then clean up the code and the libs. In my opinion this is not an urgent matter.

Right. I would also have been quite surprised if the nightly wouldn't be broken after such change

[rju]

author Jan Waller -- Fri, 15 Mar 2013 22:49:51 +0100

This was already moved from before the 1.6 release.

The nightly is only broken because of missing license files. (and because of me being hungry and checking in, in order to get something to eat )

I think this can and should be done prior to a release and there is no reason not to do it now.

To the matter of the directory structure:
It makes it much easier to maintain the libraries dir, as now it is easy to see which libraries belong to which part, as especially cfx brings lots of libraries with less than obvious names.

[rju]

author Jan Waller -- Fri, 15 Mar 2013 23:55:06 +0100

As I said, just some minor missing lines and stuff

So, what does look strange? Can you be more specific?

[rju]

author André van Hoorn -- Sun, 17 Mar 2013 18:02:20 +0100

Replying to [jwa|comment:7]:
> As I said, just some minor missing lines and stuff
>
> So, what does look strange? Can you be more specific?

Having jars organized in subdirs under lib (currently framework-libs; note that I'm not talking about the static-analysis libs and the sigar natives). My expectation was that you will continue organizing all jars into subdirectories. Or wasn't this the plan? This is what I concluded from comment:1 ("Take a look at a first try").

[rju]

author Jan Waller -- Sun, 17 Mar 2013 18:06:52 +0100

I mostly wanted to sort cfx and spring away. They are very cluttery (does this work exist?) and only needed in special cases (when monitoring these technologies or running our tests for these monitoring probes).

Now, these libraries for special monitoring probes are separate from the more general purpose libraries.
There is no intention of further sorting (expect maybe aopalliance.jar which is part of spring if I remember correctly).

[rju]

author André van Hoorn -- Sun, 17 Mar 2013 18:09:17 +0100

Replying to [jwa|comment:9]:
> I mostly wanted to sort cfx and spring away. They are very cluttery (does this work exist?) and only needed in special cases (when monitoring these technologies or running our tests for these monitoring probes).
>
> Now, these libraries for special monitoring probes are separate from the more general purpose libraries.
> There is no intention of further sorting (expect maybe aopalliance.jar which is part of spring if I remember correctly).

Ok, I see; I really thought you wanted to create a complete organization structure for all libs (and nie probably, too). What about removing the additional framework-libs layer and simply putting them into spring and cxf.

[rju]

author Jan Waller -- Sun, 17 Mar 2013 18:52:04 +0100

Fine with me

[rju]

author Jan Waller -- Mon, 18 Mar 2013 09:22:58 +0100

fixed for now