[
https://issues.apache.org/jira/browse/CAMEL-16429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312913#comment-17312913
]
Claus Ibsen edited comment on CAMEL-16429 at 4/1/21, 6:47 AM:
--------------------------------------------------------------
1)
We could create a goal on the camel-package-maven-plugin, that can discover
from the classpath, all TypeConverterLoader files, and create a combined file,
that camel-core will discover and use. Then any fat-jar packaging approach can
be safely used. This requires to add this plugin to the user project.
2)
We could besides generating TypeConverterLoader, generate another file with
unique name.
And then keep a .java source file in camel-core up to date, with a list of all
those unique names, which camel can then attempt to load on startup.
However this will cause a lot of "FileNotFound" errors that we need to silently
ignore.
3)
We could besides generating TypeConverterLoader, generate another file with
unique name.
And then let Camel do classpath discovery from this folder, to find the unique
file names, and load each converter this way.
However this is a slight slower approach and would require to turn this on (to
avoid enabled by default).
4)
We could create our own fat-jar goal that can package together Camel components
in a safe way. It could extend the assembly jar so users can use its features
out of the box.
5)
Users can turn on loadTypeConverters on CamelContext (2.x style) that does
classpath scanning for annotated classes. However this then uses reflection
based conversion as its not via source code generated Loader classes.
was (Author: davsclaus):
1)
We could create a goal on the camel-package-maven-plugin, that can discover
from the classpath, all TypeConverterLoader files, and create a combined file,
that camel-core will discover and use. Then any fat-jar packaging approach can
be safely used. This requires to add this plugin to the user project.
2)
We could besides generating TypeConverterLoader, generate another file with
unique name.
And then keep a .java source file in camel-core up to date, with a list of all
those unique names, which camel can then attempt to load on startup.
However this will cause a lot of "FileNotFound" errors that we need to silently
ignore.
3)
We could besides generating TypeConverterLoader, generate another file with
unique name.
And then let Camel do classpath discovery from this folder, to find the unique
file names, and load each converter this way.
However this is a slight slower approach and would require to turn this on (to
avoid enabled by default).
4)
We could create our own fat-jar goal that can package together Camel components
in a safe way. It could extend the assembly jar so users can use its features
out of the box.
> camel-core - Can we use unique TypeConverterLoader files for easy fat-jar
> assembly
> ----------------------------------------------------------------------------------
>
> Key: CAMEL-16429
> URL: https://issues.apache.org/jira/browse/CAMEL-16429
> Project: Camel
> Issue Type: New Feature
> Components: build system, camel-core
> Reporter: Claus Ibsen
> Priority: Major
> Fix For: 3.x
>
>
> See CAMEL-16419
> Some users may want to just package their camel apps as a fat-jar via maven
> assembly plugin (shade plugin is ugly to configure for merging files).
> The issue is the type converter loader that uses the same file name per
> artifact.
> We could for camel-core have unique names as its core converters that should
> always be loaded.
> And then. for Camel JARs then we can in fat-jar mode use fallback with
> classpath discovery and have some other way of finding those unique converter
> names.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
