[
https://issues.apache.org/jira/browse/CAMEL-26694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-26694:
--------------------------------
Description:
Roaster (with the shaded Eclipse JDT, a 12 MB jar) is used only by build
tooling and one catalog library, not at runtime. Removing it takes four stages,
from small to large.
h3. Where Roaster is used today
||Module||Files||What it is used for||
|camel-package-maven-plugin|8|*javadoc* for the option descriptions
(EndpointSchemaGeneratorMojo, SchemaGeneratorMojo, PackageDataFormatMojo,
UpdateReadmeMojo, PrepareCamelMainMojo, JavadocUtil); only *annotation values*
in PrepareCamelJBangMojo and DstWorldsHelper|
|camel-route-parser|8|the old Java DSL route parser (RouteBuilderParser,
RestDslParser, CamelJavaParserHelper and the other helpers)|
|camel-api-component-maven-plugin|1|JavaSourceParser: the javadoc of API
classes|
|camel-report-maven-plugin|0|declares roaster-api and roaster-jdt, but no code
uses them|
h3. Stage 1: remove the unused dependency
camel-report-maven-plugin declares roaster-api and roaster-jdt but uses
neither: it reads Java routes with {{LwJavaParser}} (camel-java-io), and uses
camel-route-parser only for {{XmlRouteParser}} and its model classes.
h3. Stage 2: read annotations from the compiled classes
PrepareCamelJBangMojo reads only annotation values from the source.
{{@Metadata}} has runtime retention, and the mojo already has the class loader
of the project ({{AbstractGeneratorMojo}}), so it can read the annotations from
the compiled class. (DstWorldsHelper also reads only annotation values, but of
test classes, which are not compiled when the component JSON is generated, and
not at all with {{-Dmaven.test.skip}}: it stays a source reader, in stage 4.)
javac has already joined constants such as {{"a" + "b"}}, so the class of bug
fixed by the quick fix PR #29341 (a {{+}} in a camel-jbang option description)
cannot happen.
h3. Stage 3: deprecate the Java route parser of camel-route-parser
{{LwJavaParser}} (design/java-dsl-parser.adoc) replaced it inside Camel;
nothing in the repository uses RouteBuilderParser, RestDslParser and their
helpers except their own tests. camel-route-parser is a public artifact (in the
BOM) and may have users outside Camel, so: deprecate the Java parsers in 4.24
with an entry in the upgrade guide (pointing at {{LwJavaParser}}), keep
{{XmlRouteParser}} and the model, and remove the Java parsers in a later
release. Then camel-route-parser no longer needs Roaster.
h3. Stage 4: read the javadoc with the JDK's own parser
Replace the javadoc readers in camel-package-maven-plugin, DstWorldsHelper (the
{{@DstWorld}} annotations of test sources) and JavaSourceParser of
camel-api-component-maven-plugin with the javac tree API of the JDK
({{javax.tools}} and {{com.sun.source}} Trees / DocTrees, in the
{{jdk.compiler}} module of every JDK): no third-party dependency, and always
the Java version that builds Camel. JavaParser is an alternative if that API is
awkward, at the cost of another dependency. One mojo at a time: the check of
each PR is that regenerating the whole catalog (components, EIPs, data formats,
Main options) gives no diff. Then remove {{roaster-version}} from
parent/pom.xml.
_Claude Code on behalf of Claus Ibsen_
was:
Roaster (with the shaded Eclipse JDT, a 12 MB jar) is used only by build
tooling and one catalog library, not at runtime. Removing it takes four stages,
from small to large.
h3. Where Roaster is used today
||Module||Files||What it is used for||
|camel-package-maven-plugin|8|*javadoc* for the option descriptions
(EndpointSchemaGeneratorMojo, SchemaGeneratorMojo, PackageDataFormatMojo,
UpdateReadmeMojo, PrepareCamelMainMojo, JavadocUtil); only *annotation values*
in PrepareCamelJBangMojo and DstWorldsHelper|
|camel-route-parser|8|the old Java DSL route parser (RouteBuilderParser,
RestDslParser, CamelJavaParserHelper and the other helpers)|
|camel-api-component-maven-plugin|1|JavaSourceParser: the javadoc of API
classes|
|camel-report-maven-plugin|0|declares roaster-api and roaster-jdt, but no code
uses them|
h3. Stage 1: remove the unused dependency
camel-report-maven-plugin declares roaster-api and roaster-jdt but uses
neither: it reads Java routes with {{LwJavaParser}} (camel-java-io), and uses
camel-route-parser only for {{XmlRouteParser}} and its model classes.
h3. Stage 2: read annotations from the compiled classes
PrepareCamelJBangMojo and DstWorldsHelper read only annotation values from the
source. {{@Metadata}} has runtime retention, and the mojos already have the
class loader of the project ({{AbstractGeneratorMojo}}), so they can read the
annotations from the compiled classes. javac has already joined constants such
as {{"a" + "b"}}, so the class of bug fixed by the quick fix PR #29341 (a {{+}}
in a camel-jbang option description) cannot happen.
h3. Stage 3: deprecate the Java route parser of camel-route-parser
{{LwJavaParser}} (design/java-dsl-parser.adoc) replaced it inside Camel;
nothing in the repository uses RouteBuilderParser, RestDslParser and their
helpers except their own tests. camel-route-parser is a public artifact (in the
BOM) and may have users outside Camel, so: deprecate the Java parsers in 4.24
with an entry in the upgrade guide (pointing at {{LwJavaParser}}), keep
{{XmlRouteParser}} and the model, and remove the Java parsers in a later
release. Then camel-route-parser no longer needs Roaster.
h3. Stage 4: read the javadoc with the JDK's own parser
Replace the javadoc readers in camel-package-maven-plugin and JavaSourceParser
of camel-api-component-maven-plugin with the javac tree API of the JDK
({{javax.tools}} and {{com.sun.source}} Trees / DocTrees, in the
{{jdk.compiler}} module of every JDK): no third-party dependency, and always
the Java version that builds Camel. JavaParser is an alternative if that API is
awkward, at the cost of another dependency. One mojo at a time: the check of
each PR is that regenerating the whole catalog (components, EIPs, data formats,
Main options) gives no diff. Then remove {{roaster-version}} from
parent/pom.xml.
_Claude Code on behalf of Claus Ibsen_
> Remove Roaster from the build tooling and camel-route-parser, in four stages
> ----------------------------------------------------------------------------
>
> Key: CAMEL-26694
> URL: https://issues.apache.org/jira/browse/CAMEL-26694
> Project: Camel
> Issue Type: Task
> Components: camel-catalog, camel-package-maven-plugin, tooling
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Minor
> Fix For: 4.24.0
>
>
> Roaster (with the shaded Eclipse JDT, a 12 MB jar) is used only by build
> tooling and one catalog library, not at runtime. Removing it takes four
> stages, from small to large.
> h3. Where Roaster is used today
> ||Module||Files||What it is used for||
> |camel-package-maven-plugin|8|*javadoc* for the option descriptions
> (EndpointSchemaGeneratorMojo, SchemaGeneratorMojo, PackageDataFormatMojo,
> UpdateReadmeMojo, PrepareCamelMainMojo, JavadocUtil); only *annotation
> values* in PrepareCamelJBangMojo and DstWorldsHelper|
> |camel-route-parser|8|the old Java DSL route parser (RouteBuilderParser,
> RestDslParser, CamelJavaParserHelper and the other helpers)|
> |camel-api-component-maven-plugin|1|JavaSourceParser: the javadoc of API
> classes|
> |camel-report-maven-plugin|0|declares roaster-api and roaster-jdt, but no
> code uses them|
> h3. Stage 1: remove the unused dependency
> camel-report-maven-plugin declares roaster-api and roaster-jdt but uses
> neither: it reads Java routes with {{LwJavaParser}} (camel-java-io), and uses
> camel-route-parser only for {{XmlRouteParser}} and its model classes.
> h3. Stage 2: read annotations from the compiled classes
> PrepareCamelJBangMojo reads only annotation values from the source.
> {{@Metadata}} has runtime retention, and the mojo already has the class
> loader of the project ({{AbstractGeneratorMojo}}), so it can read the
> annotations from the compiled class. (DstWorldsHelper also reads only
> annotation values, but of test classes, which are not compiled when the
> component JSON is generated, and not at all with {{-Dmaven.test.skip}}: it
> stays a source reader, in stage 4.) javac has already joined constants such
> as {{"a" + "b"}}, so the class of bug fixed by the quick fix PR #29341 (a
> {{+}} in a camel-jbang option description) cannot happen.
> h3. Stage 3: deprecate the Java route parser of camel-route-parser
> {{LwJavaParser}} (design/java-dsl-parser.adoc) replaced it inside Camel;
> nothing in the repository uses RouteBuilderParser, RestDslParser and their
> helpers except their own tests. camel-route-parser is a public artifact (in
> the BOM) and may have users outside Camel, so: deprecate the Java parsers in
> 4.24 with an entry in the upgrade guide (pointing at {{LwJavaParser}}), keep
> {{XmlRouteParser}} and the model, and remove the Java parsers in a later
> release. Then camel-route-parser no longer needs Roaster.
> h3. Stage 4: read the javadoc with the JDK's own parser
> Replace the javadoc readers in camel-package-maven-plugin, DstWorldsHelper
> (the {{@DstWorld}} annotations of test sources) and JavaSourceParser of
> camel-api-component-maven-plugin with the javac tree API of the JDK
> ({{javax.tools}} and {{com.sun.source}} Trees / DocTrees, in the
> {{jdk.compiler}} module of every JDK): no third-party dependency, and always
> the Java version that builds Camel. JavaParser is an alternative if that API
> is awkward, at the cost of another dependency. One mojo at a time: the check
> of each PR is that regenerating the whole catalog (components, EIPs, data
> formats, Main options) gives no diff. Then remove {{roaster-version}} from
> parent/pom.xml.
> _Claude Code on behalf of Claus Ibsen_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
