Set JMS clients scope runtime to include required dependencies in the package

[fvaleri]

Not sure if there is a better way to do this, but it works and it is much more convenient. What do you think?

[oscerd]

This will make all the connectors packaging jms client and artemis jms client, even where not needed at all

[fvaleri]

Yeah, this was my concern. Is there a better way to do this automatically?

[oscerd]

The only way I see is making the deps explicit in the connector pom of the single connectors.

[fvaleri]

This commit should be better.

[oscerd]

Seems ok. Lets see the other reviewers @valdar and @orpiske

[valdar]

Mmm should have been enough to have them as dependencies... not sure why the runtime scope is needed, pretty sure they ended up in the packaged zip at sone point...

[oscerd]

Both of them are declared in parent pom as test dependencies https://github.com/apache/camel-kafka-connector/blob/master/parent/pom.xml#L292-L302

So when it's time to build the packaged connector they will be excluded, because of the scope.

[fvaleri]

Both of them are declared in parent pom as test dependencies https://github.com/apache/camel-kafka-connector/blob/master/parent/pom.xml#L292-L302

So when it's time to build the packaged connector they will be excluded, because of the scope.

Yeah. They were in the final package in 0.3, but not anymore. Adding the scope to the fix-dependencies property file seems to work fine and the same technique could be used for other connectors as needed.

[orpiske]

@oscerd @valdar I believe you both have better understanding of the ramifications of this than I do. At first sight I have no objections with the approach, but I would kindly ask for one more thing.

Do we have to update the missing dependencies part of the troubleshooting guide as part of this?

My understanding is that we do need to update the note there. Therefore, I would probably just put a note saying "From version 0.x.x and forward the JMS dependencies are packaged along w/ sjms2 and this should not be a problem. Should you need to use other JMS clients, you need to repackage or use the legacy/regular/etc JMS component".

[fvaleri]

@oscerd @valdar I believe you both have better understanding of the ramifications of this than I do. At first sight I have no objections with the approach, but I would kindly ask for one more thing.

Do we have to update the missing dependencies part of the troubleshooting guide as part of this?

My understanding is that we do need to update the note there. Therefore, I would probably just put a note saying "From version 0.x.x and forward the JMS dependencies are packaged along w/ sjms2 and this should not be a problem. Should you need to use other JMS clients, you need to repackage or use the legacy/regular/etc JMS component".

+1 for this, thanks @orpiske.

In general I think that trying to avoid the need to repackage is the best strategy for a great user experience.

Let me know if you want me to add this note to the commit.

[orpiske]

@fvaleri thanks. Yes, please. I think it would be better to have that note added now that the discussion is fresh. Thanks!

[valdar]

tnx @fvaleri !