Deployer ClassLoader dependencies and OSGi

[adrian.brock]

For the "version" of a deployment/module I'm currently using the
OSGi version class.

See deployers-structure-spi/org.jboss.deployers.structure.spi.classloading.helpers.VersionImpl

Doing this will make it easier to interoperate with OSGi in the future,
but it does introduce a dependency of the OSGi core jar into the bootstrap classloader.

Can anybody think of alternate way to do this?

The basic problem is if we want multiple Version implementations
then they will like have to understand each other to implement:

Comparator<Version>.compareTo(Version other)

[alesj]

Can anybody think of alternate way to do this?

I already introduced VersionRange interface (osgi-int\src\main\org\jboss\osgi\spi\metadata) on top of Scott's VersionRangeImpl in osgi-int module.

Could we just use this one?

[alesj]

"alesj" wrote:

I already introduced VersionRange interface (osgi-int\src\main\org\jboss\osgi\spi\metadata) on top of Scott's VersionRangeImpl in osgi-int module.

Could we just use this one?

Eh, this one also uses Version from OSGi API. :-(
I guess we'll have to introduce our own Version interface.

[starksm64]

Let's add this to the common core lib then as I have another duplicate impl in org.jboss.profileservice.spi.repository.Version. Something like:

package org.jboss.util.id;

public interface VersionFactory
{
 public Version parseVersion(String version);
 public Version newVersion(int major, int minor, int micro, String qualifier);
 public Version emptyVersion();
}

public class Version implements Comparable, Serializable
{
 public int getMajor();
 public int getMinor();
 public int getMicro();
 public String getQualifier();
 public String toString();
 public int hashCode();
 public boolean equals(Object object);
 public int compareTo(Object object);
}

Default osgi like implementations could be in org.jboss.util.id.osgi