unify common-util code with fabric-utils so we have a single core util library with no dependencies about fabric8 HOT 7 CLOSED

we've lots of Strings / Objects helper classes all over the place really; would be nice to have a 'no dependencies' util library we can use anywhere; then an OSGi/Fabric one?

e.g. just spotted org.fusesource.fabric.internal.Objects too

from fabric8.

I feel bad - I copy/pasted Strings.java from common-util to fabric-utils to avoid mucking with bundle / features just yet ;) so would be nice to tidy things up at some point :)

from fabric8.

+1

I had also added some helper stuff in the JMX package that could really stand to be in fabric-utils/common-utils, think there's some functions in fabric-commands and fabric-boot-commands that could be moved too. So should we keep common-utils or fabric-utils?

from fabric8.

embedding will not work in non-osgi envs. normal, osgi import package would work

from fabric8.

I had a look.

fabric-utils has a mix of clean util classes that can be in common-utils. And some utils that uses OSGi / Fabric etc, and should be left as is.

But the clean util methods for string / objects / crc32 etc could be moved to common-utils.

from fabric8.

Just a heads up that a PR is on the way, that moves some util classes from fabric-util to common-util.

There is still some util in fabric-util as they are either karaf or osgi dependent. Ideally we may want to move the osgi and karaf utils into fabric-karaf, and leave the general fabric util methods in fabric-utils, which can be used by docker / tomcat / also

from fabric8.

Okay moved as much we can do now, to common-util.

from fabric8.