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

Improve camel service discovery and filtering #340

Merged
merged 4 commits into from Oct 28, 2019

Conversation

lburgazzoli
Copy link
Contributor

No description provided.

@asf-ci
Copy link

asf-ci commented Oct 28, 2019

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/camel-quarkus-pr/340/

@lburgazzoli lburgazzoli merged commit bf2e3e1 into apache:master Oct 28, 2019
@lburgazzoli lburgazzoli deleted the camel-service branch October 28, 2019 11:06
Copy link
Contributor

@ppalaga ppalaga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two late comments inline.

import java.util.function.Predicate;

@FunctionalInterface
public interface CamelServiceFilter extends Predicate<CamelServiceInfo> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fail to see what value is CamelServiceFilter interface adding. I'd personally prefer using Predicate<CamelServiceInfo> directly because that way I'd immediately see that it is just a Predicate and nothing else.

import io.quarkus.builder.item.MultiBuildItem;
import org.apache.camel.quarkus.core.CamelServiceFilter;

public final class CamelServiceFilterBuildItem extends MultiBuildItem {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like us all to document BuildItems properly. The class level BuildItem JavaDoc should make the extension developers understand what is the purpose of the given BuildItem and when/how they should use it. If we provide no JavaDoc, the extension developers are doomed to click through our BuildProcessors and collect the information investing a lot more effort.

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

Successfully merging this pull request may close these issues.

None yet

4 participants