arquillian / arquillian-core

Arquillian provides a component model for integration tests, which includes dependency injection and container life cycle management. Instead of managing a runtime in your test, Arquillian brings your test to the runtime.
http://arquillian.org
Apache License 2.0
366 stars 195 forks source link

Why does every ArquillianDescriptor return type extend ArquillianDescriptor? #551

Open starksm64 opened 2 weeks ago

starksm64 commented 2 weeks ago
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 commented 2 weeks ago

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.

jamezp commented 4 days ago

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.

starksm64 commented 3 days ago

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.