Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why does every ArquillianDescriptor return type extend ArquillianDescriptor? #551

Open
starksm64 opened this issue Jun 15, 2024 · 3 comments

Comments

@starksm64
Copy link
Member

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
Copy link
Member Author

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
Copy link
Collaborator

jamezp commented Jun 28, 2024

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants