[JBoss JIRA] (ROASTER-12) Shade the JDT dependencies into Roaster-JDT
by Walter Medvedeo (JIRA)
[ https://issues.jboss.org/browse/ROASTER-12?page=com.atlassian.jira.plugin... ]
Walter Medvedeo commented on ROASTER-12:
----------------------------------------
The following change was done to the shade configuration in order to not shade the "org.eclipse.jdt.core.prefs" file name in the Formater class.
<filters>
<filter>
<artifact>*:*</artifact>
<excludes>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
<exclude>META-INF/*.RSA</exclude>
</excludes>
</filter>
</filters>
<relocations>
<relocation>
<pattern>org.eclipse</pattern>
<shadedPattern>org.jboss.forge.roaster._shade.org.eclipse</shadedPattern>
<excludes>
<exclude>org.eclipse.jdt.core.prefs</exclude>
</excludes>
</relocation>
<relocation>
<pattern>org.osgi</pattern>
<shadedPattern>org.jboss.forge.roaster._shade.org.osgi</shadedPattern>
</relocation>
</relocations>
> Shade the JDT dependencies into Roaster-JDT
> -------------------------------------------
>
> Key: ROASTER-12
> URL: https://issues.jboss.org/browse/ROASTER-12
> Project: Roaster
> Issue Type: Feature Request
> Components: JDT
> Affects Versions: 2.3.0.Final
> Reporter: George Gastaldi
> Assignee: Lincoln Baxter III
> Fix For: 2.3.1.Final
>
>
> The current JDT version used conflicts with ECJ in Drools. We should shade the JDT classes since we don't expect people to use them directly with Roaster.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (ROASTER-12) Shade the JDT dependencies into Roaster-JDT
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/ROASTER-12?page=com.atlassian.jira.plugin... ]
George Gastaldi edited comment on ROASTER-12 at 5/6/14 12:35 PM:
-----------------------------------------------------------------
What if we add this property file in the src/test/resources for the maven tests to run?
was (Author: gastaldi):
What if can have this property file in the src/test/resources for the maven tests to run?
> Shade the JDT dependencies into Roaster-JDT
> -------------------------------------------
>
> Key: ROASTER-12
> URL: https://issues.jboss.org/browse/ROASTER-12
> Project: Roaster
> Issue Type: Feature Request
> Components: JDT
> Affects Versions: 2.3.0.Final
> Reporter: George Gastaldi
> Assignee: Lincoln Baxter III
> Fix For: 2.3.1.Final
>
>
> The current JDT version used conflicts with ECJ in Drools. We should shade the JDT classes since we don't expect people to use them directly with Roaster.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (ROASTER-12) Shade the JDT dependencies into Roaster-JDT
by Walter Medvedeo (JIRA)
[ https://issues.jboss.org/browse/ROASTER-12?page=com.atlassian.jira.plugin... ]
Walter Medvedeo commented on ROASTER-12:
----------------------------------------
The following scenario can give more information to the issue:
When the Roaster library is used form an external project we have this first situation:
1) The shade is shading the following line of code at the class "org.jboss.forge.roaster.model.util.Formatter"
Properties options = readConfig("org.jboss.forge.roaster._shade.org.eclipse.jdt.core.prefs"); <-- Preferencies file invocation was renamed.
so when the Formatter is running we have a NPE because the preferencies file "org.eclipes.jdt.core.prefs" was not renamed by the shade.
Ok, this is not a problem. I've managed the shade configuration in order the keep the line untouched
Properties options = readConfig("org.eclipse.jdt.core.prefs");
and as expected the NPE disappeared. But when I modify a class using the api, etc., the format is not applied.
2) So then I decompiled the following eclipse shaded class that has the formatting constants defintions:
"org.jboss.forge.roaster._shade.org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants"
And we have somethinig like this:
public static final String FORMATTER_ALIGN_TYPE_MEMBERS_ON_COLUMNS = "org.jboss.forge.roaster._shade.org.eclipse.jdt.core.formatter.align_type_members_on_columns";
public static final String FORMATTER_ALIGNMENT_FOR_ARGUMENTS_IN_ALLOCATION_EXPRESSION = "org.jboss.forge.roaster._shade.org.eclipse.jdt.core.formatter.alignment_for_arguments_in_allocation_expression";
public static final String FORMATTER_ALIGNMENT_FOR_ARGUMENTS_IN_ENUM_CONSTANT = "org.jboss.forge.roaster._shade.org.eclipse.jdt.core.formatter.alignment_for_arguments_in_enum_constant";
public static final String FORMATTER_ALIGNMENT_FOR_ARGUMENTS_IN_ANNOTATION = "org.jboss.forge.roaster._shade.org.eclipse.jdt.core.formatter.alignment_for_arguments_in_annotation";
public static final String FORMATTER_ALIGNMENT_FOR_ARGUMENTS_IN_EXPLICIT_CONSTRUCTOR_CALL = "org.jboss.forge.roaster._shade.org.eclipse.jdt.core.formatter.alignment_for_arguments_in_explicit_constructor_call";
public static final String FORMATTER_ALIGNMENT_FOR_ARGUMENTS_IN_METHOD_INVOCATION = "org.jboss.forge.roaster._shade.org.eclipse.jdt.core.formatter.alignment_for_arguments_in_method_invocation";
The shade is basically changing also the value for the defined constants in the Eclipse class. So in runtime, the formatter
is looking for properties in the form "org.jboss.forge.roaster._shade.org.eclipse.jdt.core.formatter.alignment_for_arguments_in_method_invocation".
So I believe that we need to:
2.1) try to configure the shade to not change the constants definitions in Eclipse's DefaultCodeFormatterConstants class.
(but I guess it's not possible)
2.2) try to configure the shade in order to rename the properties in "org.eclipse.jdt.core.prefs" automatically and set the shade prefix.
For this second option I've done several tests but it seems like property names in the file "org.eclipse.jdt.core.prefs" are not renamed by the
shade plugin.
2.3) Rename the properties in "org.eclipse.jdt.core.prefs" manually and set the shade prefix.
2.4) whatever other better option ¿?
So to continue my tests I've basically used option 3) and made a small change in the shade configuration in order to fix 1), and then I've had the following results.
1) External projects that uses Roaster as a third party library works well.
2) But Roaster tests that uses the Formatter don't works. It seems like when a test (e.g. FormatterTest.java ) is being runned with maven the classes that runs are the eclipse original classes, and not the shaded classes. And the original Eclipse classes still have the original property names e.g.
"org.eclipse.jdt.core.formatter.align_type_members_on_columns".
But when a client project uses the Formatter, the Eclipse classes that runs are the shaded ones, and in this cases the formatting constants are in the form
"org.jboss.forge.roaster._shade.org.eclipse.jdt.core.formatter.align_type_members_on_columns";
It seems like we need "two versions" of the property file, one for maven tests, and another version that should be used when Roaster is being used in "client" mode. Or configure the pom.xml/shade in order that the two different invocation scenarios works.
> Shade the JDT dependencies into Roaster-JDT
> -------------------------------------------
>
> Key: ROASTER-12
> URL: https://issues.jboss.org/browse/ROASTER-12
> Project: Roaster
> Issue Type: Feature Request
> Components: JDT
> Affects Versions: 2.3.0.Final
> Reporter: George Gastaldi
> Assignee: Lincoln Baxter III
> Fix For: 2.3.1.Final
>
>
> The current JDT version used conflicts with ECJ in Drools. We should shade the JDT classes since we don't expect people to use them directly with Roaster.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (FORGE-1787) When scaffolding with --webRoot parameter, pageTemplate.xhtml and search.xhtml are not right
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-1787?page=com.atlassian.jira.plugin... ]
George Gastaldi closed FORGE-1787.
----------------------------------
Assignee: George Gastaldi
Fix Version/s: 2.5.1.Final
Resolution: Done
Fixed
> When scaffolding with --webRoot parameter, pageTemplate.xhtml and search.xhtml are not right
> --------------------------------------------------------------------------------------------
>
> Key: FORGE-1787
> URL: https://issues.jboss.org/browse/FORGE-1787
> Project: Forge
> Issue Type: Bug
> Components: Scaffold
> Affects Versions: 2.5.0.Final
> Reporter: Antonio Goncalves
> Assignee: George Gastaldi
> Priority: Blocker
> Fix For: 2.5.1.Final
>
>
> When scaffolding a JSF application, without using a {{--webRoot}} parameter, the navigation in the {{pageTemplate.xhtml}} works as expected :
> {code}
> scaffold-setup ;
> scaffold-generate --targets org.agoncal.training.javaee6adv.model.Author ;
> scaffold-generate --targets org.agoncal.training.javaee6adv.model.CD ;
> {code}
> The template navigation looks like :
> {code}
> <ul>
> <li>
> <h:link outcome="/CD/search" value="CD"/>
> </li>
> <li>
> <h:link outcome="/author/search" value="Author"/>
> </li>
> </ul>
> {code}
> But if I specify the {{--webRoot}} parameter, then the navigation does not work as there is a {{/}} missing :
> {code}
> scaffold-setup ;
> scaffold-generate --webRoot admin --targets org.agoncal.training.javaee6adv.model.Author ;
> scaffold-generate --webRoot admin --targets org.agoncal.training.javaee6adv.model.CD ;
> {code}
> The template :
> {code}
> <ul>
> <li>
> <h:link outcome="admin/CD/search" value="CD"/>
> </li>
> <li>
> <h:link outcome="admin/author/search" value="Author"/>
> </li>
> </ul>
> {code}
> The correct navigation would be :
> {code}
> <ul>
> <li>
> <h:link outcome="/admin/CD/search" value="CD"/>
> </li>
> <li>
> <h:link outcome="/admin/author/search" value="Author"/>
> </li>
> </ul>
> {code}
> The only way to make it work is to add a {{/}} to the {{webroot}}, which is not very intuitive :
> {code}
> scaffold-setup ;
> scaffold-generate --webRoot /admin --targets org.agoncal.training.javaee6adv.model.Author ;
> scaffold-generate --webRoot /admin --targets org.agoncal.training.javaee6adv.model.CD ;
> {code}
> But this trick doesn't work for the {{search.xhtml}} page. The generated code is :
> {code}
> <h:link outcome="/genre/view">
> <f:param name="id" value="#{_item.id}"/>
> <h:outputText id="itemName" value="#{_item.name}"/>
> </h:link>
> {code}
> The {{outcome}} is not right, and should contain a {{/admin}}
> {code}
> <h:link outcome="/admin/genre/view">
> <f:param name="id" value="#{_item.id}"/>
> <h:outputText id="itemName" value="#{_item.name}"/>
> </h:link>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (FORGE-1326) Furnace proxies should attempt to honor Thread interrupted state.
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/FORGE-1326?page=com.atlassian.jira.plugin... ]
Lincoln Baxter III closed FORGE-1326.
-------------------------------------
Fix Version/s: 2.5.1.Final
(was: 2.x Future)
Resolution: Done
Furnace proxy implementations ClassLoaderInterceptor and ClassLoaderAdapterCallback will now check Thread.currentThread().isInterrupted() and throw an exception instead of proceeding, when threads are in interrupted state.
> Furnace proxies should attempt to honor Thread interrupted state.
> ------------------------------------------------------------------
>
> Key: FORGE-1326
> URL: https://issues.jboss.org/browse/FORGE-1326
> Project: Forge
> Issue Type: Feature Request
> Components: Furnace (Container)
> Affects Versions: 2.0.0.Beta3
> Reporter: Lincoln Baxter III
> Assignee: Lincoln Baxter III
> Fix For: 2.5.1.Final
>
>
> Currently, there is no real way to force executed commands or methods to halt. Forge proxies should attempt to make this possible by checking Thread.interrupted() and throwing InterruptedException when appropriate.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months