arquillian-core icon indicating copy to clipboard operation
arquillian-core copied to clipboard

Why does every ArquillianDescriptor return type extend ArquillianDescriptor?

Open starksm64 opened this issue 1 year ago • 3 comments

Issue Overview

Looking at the org.jboss.arquillian.config.descriptor.api.ArquillianDescriptor interface:

package org.jboss.arquillian.config.descriptor.api;

public interface ArquillianDescriptor extends Descriptor {
    EngineDef engine();

    DefaultProtocolDef defaultProtocol(String var1);

    DefaultProtocolDef getDefaultProtocol();

    ContainerDef container(String var1);

    GroupDef group(String var1);

    ExtensionDef extension(String var1);

    List<ContainerDef> getContainers();

    List<GroupDef> getGroups();

    List<ExtensionDef> getExtensions();
}

I see that every single interface type returned by the methods also extend the ArquillianDescriptor:

package org.jboss.arquillian.config.descriptor.api;

public interface EngineDef extends ArquillianDescriptor {
...
}

public interface DefaultProtocolDef extends ArquillianDescriptor {
...
}

public interface ContainerDef extends ArquillianDescriptor {
}

etc.

I can't understand what the purpose is or how it could effectively be used.

Expected Behaviour

I would expect each type to only extend the org.jboss.shrinkwrap.descriptor.api.Descriptor

Current Behaviour

Seems recursive for no practical reason.

starksm64 avatar Jun 15 '24 02:06 starksm64

The usecase seems to be to navigate from a container to the default protocol for example, but this could be done via just parent/child relationships. I don't see that all methods are usable from a given point in the descriptor graph, but maybe I am missing something.

starksm64 avatar Jun 15 '24 06:06 starksm64

I'd agree this doesn't make much sense. I don't really know the reason, but my guess would be because the return type for each method on the interface is a ApplicationDescriptor so the implementations could just return this.

jamezp avatar Jun 28 '24 15:06 jamezp

Yes, I guess it was an attempt at a fluid API, but it is not logical. I guess we need a proper proposal to update the interface and think about supporting other descriptor formats.

starksm64 avatar Jun 29 '24 22:06 starksm64