[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Marco Rietveld edited comment on DROOLS-355 at 8/24/16 9:19 AM:
----------------------------------------------------------------
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
-- as well as OSGi problems, I suspect
-- and the jar is also 2.7M..
-- and it's broken (if you try to go around the {{com.sun.javadoc.*}} imports)
- {{JIBX}} might be usable, but I really don't like it, because:
-- {{JIBX}} uses it's "own" ({{org.jibx}}) version of eclipse compiler/parser jars, which is not nice given that {{drools-compiler}} uses {{org.eclipse.jdt.core.compiler:ejc}}
-- Also Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
was (Author: marco.rietveld):
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
-- as well as OSGi problems, I suspect
-- and the jar is also 2.7M..
-- and it's broken (if you try to go around the {{com.sun.javadoc.*}} imports)
- {{JIBX}} might be usable, but I really don't like it, because:
-- {{JIBX}} uses it's "own" ({{org.jibx}}) version of the eclipse jars, which is not nice given that {{drools-compiler}} uses {{org.eclipse.jdt.core.compiler:ejc}}
-- Also Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Marco Rietveld
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Marco Rietveld edited comment on DROOLS-355 at 8/24/16 9:18 AM:
----------------------------------------------------------------
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
-- as well as OSGi problems, I suspect
-- and the jar is also 2.7M..
-- and it's broken (if you try to go around the {{com.sun.javadoc.*}} imports)
- {{JIBX}} might be usable, but I really don't like it, because:
-- {{JIBX}} uses it's "own" ({{org.jibx}}) version of the eclipse jars, which is not nice given that {{drools-compiler}} uses {{org.eclipse.jdt.core.compiler:ejc}}
-- Also Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
was (Author: marco.rietveld):
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
-- as well as OSGi problems, I suspect
-- and the jar is also 2.7M..
-- and it's broken (if you try to go around the {{com.sun.javadoc.*}} imports)
- {{JIBX}} uses it's "own" ({{org.jibx}}) version of the eclipse jars, which causes problems
-- {{drools-compiler}} uses {{org.eclipse.jdt.core.compiler:ejc}}
-- Also Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Marco Rietveld
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6995) Upgrade to WildFly 10.1.0.Final
by Leandro Kersting de Freitas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6995?page=com.atlassian.jira.plugin.... ]
Leandro Kersting de Freitas updated WFLY-6995:
----------------------------------------------
Description: Sorry. this Issue for keycloak. (was: WildFly 10.1.0.Final (
http://wildfly.org/news/2016/08/19/WildFly10-1-Released/)
Major new features include:
Out of the box HTTP/2 support with no JVM flags required !
TLS cert auto-generation
Load-balancing profile is now in our default domain.xml config
Support for clustering node discovery on Azure (jgroups AZURE_PING)
Additionally there was a massive 324 issues resolved in this release!
Out of the Box HTTP/2 and TLS
Unique to WildFly, is that HTTP/2 now works without any special JVM flags (even on Java 8!), configuration changes, or keystore changes. You simply point your browser at port 8443 and WildFly will automatically generate a self-signed TLS cert for you, and negotiate HTTP/2 if your browser supports it (most do). When you are ready to deploy in production, you simply update the keystore with whatever cert you would like to present to your users.
Load-balancing Profile
In order to make it even easier to get started with load-balancing, we added a profile to the default domain.xml file, called "load-balancer". You can now build a fully clustered topology using just our default profiles in domain mode, creating a server with the "load-balancer" profile, and a set of backend servers using the "full-ha" profile.
Upgraded:
Infinispan 8.2.4.Final
JGroups to 3.6.10.Final
HAL to 2.8.27.Final
RESTEasy to 3.0.16.Final
Narayana to 5.3.3.Final
Hibernate Search 5.5.2.Final
Hibernate Validator to 5.2.4.Final
Hibernate ORM 5.0.9.Final
IronJacamar 1.3.4.Final
mod_cluster to 1.3.2.Final
Apache CXF 3.1.6
JBossWS from 5.1.4.Final
JBoss Negotiation 3.0.2.Final
Jira Release Notes (325 Issues)
The full list of issues resolved is available (https://issues.jboss.org/projects/WFLY/versions/12331186).
)
> Upgrade to WildFly 10.1.0.Final
> -------------------------------
>
> Key: WFLY-6995
> URL: https://issues.jboss.org/browse/WFLY-6995
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Leandro Kersting de Freitas
> Assignee: Jason Greene
>
> Sorry. this Issue for keycloak.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6995) Upgrade to WildFly 10.1.0.Final
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6995?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-6995:
-----------------------------------
???
> Upgrade to WildFly 10.1.0.Final
> -------------------------------
>
> Key: WFLY-6995
> URL: https://issues.jboss.org/browse/WFLY-6995
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Leandro Kersting de Freitas
> Assignee: Jason Greene
>
> WildFly 10.1.0.Final (
> http://wildfly.org/news/2016/08/19/WildFly10-1-Released/)
> Major new features include:
> Out of the box HTTP/2 support with no JVM flags required !
> TLS cert auto-generation
> Load-balancing profile is now in our default domain.xml config
> Support for clustering node discovery on Azure (jgroups AZURE_PING)
> Additionally there was a massive 324 issues resolved in this release!
> Out of the Box HTTP/2 and TLS
> Unique to WildFly, is that HTTP/2 now works without any special JVM flags (even on Java 8!), configuration changes, or keystore changes. You simply point your browser at port 8443 and WildFly will automatically generate a self-signed TLS cert for you, and negotiate HTTP/2 if your browser supports it (most do). When you are ready to deploy in production, you simply update the keystore with whatever cert you would like to present to your users.
> Load-balancing Profile
> In order to make it even easier to get started with load-balancing, we added a profile to the default domain.xml file, called "load-balancer". You can now build a fully clustered topology using just our default profiles in domain mode, creating a server with the "load-balancer" profile, and a set of backend servers using the "full-ha" profile.
> Upgraded:
> Infinispan 8.2.4.Final
> JGroups to 3.6.10.Final
> HAL to 2.8.27.Final
> RESTEasy to 3.0.16.Final
> Narayana to 5.3.3.Final
> Hibernate Search 5.5.2.Final
> Hibernate Validator to 5.2.4.Final
> Hibernate ORM 5.0.9.Final
> IronJacamar 1.3.4.Final
> mod_cluster to 1.3.2.Final
> Apache CXF 3.1.6
> JBossWS from 5.1.4.Final
> JBoss Negotiation 3.0.2.Final
> Jira Release Notes (325 Issues)
> The full list of issues resolved is available (https://issues.jboss.org/projects/WFLY/versions/12331186).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6995) Upgrade to WildFly 10.1.0.Final
by Leandro Kersting de Freitas (JIRA)
Leandro Kersting de Freitas created WFLY-6995:
-------------------------------------------------
Summary: Upgrade to WildFly 10.1.0.Final
Key: WFLY-6995
URL: https://issues.jboss.org/browse/WFLY-6995
Project: WildFly
Issue Type: Feature Request
Reporter: Leandro Kersting de Freitas
Assignee: Jason Greene
WildFly 10.1.0.Final (
http://wildfly.org/news/2016/08/19/WildFly10-1-Released/)
Major new features include:
Out of the box HTTP/2 support with no JVM flags required !
TLS cert auto-generation
Load-balancing profile is now in our default domain.xml config
Support for clustering node discovery on Azure (jgroups AZURE_PING)
Additionally there was a massive 324 issues resolved in this release!
Out of the Box HTTP/2 and TLS
Unique to WildFly, is that HTTP/2 now works without any special JVM flags (even on Java 8!), configuration changes, or keystore changes. You simply point your browser at port 8443 and WildFly will automatically generate a self-signed TLS cert for you, and negotiate HTTP/2 if your browser supports it (most do). When you are ready to deploy in production, you simply update the keystore with whatever cert you would like to present to your users.
Load-balancing Profile
In order to make it even easier to get started with load-balancing, we added a profile to the default domain.xml file, called "load-balancer". You can now build a fully clustered topology using just our default profiles in domain mode, creating a server with the "load-balancer" profile, and a set of backend servers using the "full-ha" profile.
Upgraded:
Infinispan 8.2.4.Final
JGroups to 3.6.10.Final
HAL to 2.8.27.Final
RESTEasy to 3.0.16.Final
Narayana to 5.3.3.Final
Hibernate Search 5.5.2.Final
Hibernate Validator to 5.2.4.Final
Hibernate ORM 5.0.9.Final
IronJacamar 1.3.4.Final
mod_cluster to 1.3.2.Final
Apache CXF 3.1.6
JBossWS from 5.1.4.Final
JBoss Negotiation 3.0.2.Final
Jira Release Notes (325 Issues)
The full list of issues resolved is available (https://issues.jboss.org/projects/WFLY/versions/12331186).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Marco Rietveld edited comment on DROOLS-355 at 8/24/16 9:08 AM:
----------------------------------------------------------------
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
-- as well as OSGi problems, I suspect
-- and the jar is also 2.7M..
-- and it's broken (if you try to go around the {{com.sun.javadoc.*}} imports)
- {{JIBX}} uses it's "own" ({{org.jibx}}) version of the eclipse jars, which causes problems
-- {{drools-compiler}} uses {{org.eclipse.jdt.core.compiler:ejc}}
-- Also Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
was (Author: marco.rietveld):
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
-- as well as OSGi problems, I suspect
-- and the jar is also 2.7M..
-- and it's broken (if you try to go around the {{com.sun.javadoc.*}} imports)
- {{JIBX}} uses an incompatible version of eclipse (jars)
-- {{drools-compiler}} uses {{org.eclipse.jdt.core.compiler:ejc}}
-- Also Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Marco Rietveld
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ]
Marco Rietveld edited comment on DROOLS-355 at 8/24/16 9:07 AM:
----------------------------------------------------------------
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
-- as well as OSGi problems, I suspect
-- and the jar is also 2.7M..
-- and it's broken (if you try to go around the {{com.sun.javadoc.*}} imports)
- {{JIBX}} uses an incompatible version of eclipse (jars)
-- {{drools-compiler}} uses {{org.eclipse.jdt.core.compiler:ejc}}
-- Also Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
was (Author: marco.rietveld):
Notes:
- {{Castor}} is not a viable alternative because of licensing issues
- {{XStream}} can not handle XSDs
- {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8
-- as well as OSGi problems, I suspect
-- and the jar is also 2.7M..
-- and it's broken (if you try to go around the {{com.sun.javadoc.*}} imports)
- {{JIBX}} is possible, but it doesn't look good because
-- Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8)
--- Having `bcel` in the dep tree is a big minus in the first place..
-- internal XSD compilation infrastructure does not like it would lend itself to being used in this use case
--- no easily used points for substituting an in-memory filesystem instead of the real filesystem
> Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-355
> URL: https://issues.jboss.org/browse/DROOLS-355
> Project: Drools
> Issue Type: Task
> Affects Versions: 6.0.0.Final
> Reporter: Geoffrey De Smet
> Assignee: Marco Rietveld
> Priority: Blocker
>
> By importing com.sun.tools.xjc, 3 problems arise:
> * OSGi and Karaf trip over it.
> {code}
> [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final)
> {code}
> * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013.
> * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this?
> Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now.
> Where do we use it?
> {code}
> Targets
> String 'com.sun.tools.xjc'
> Found usages (38 usages found)
> drools-compiler (7 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found)
> pom.xml (1 usage found)
> (246: 15) com.sun.tools.xjc.*;resolution:=optional,
> org.drools.compiler.builder.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (18: 8) import com.sun.tools.xjc.Options;
> org.drools.compiler.runtime.pipeline.impl (5 usages found)
> DroolsJaxbHelperProviderImpl.java (5 usages found)
> (77: 8) import com.sun.tools.xjc.BadCommandLineException;
> (78: 8) import com.sun.tools.xjc.ErrorReceiver;
> (79: 8) import com.sun.tools.xjc.ModelLoader;
> (80: 8) import com.sun.tools.xjc.Options;
> (81: 8) import com.sun.tools.xjc.model.Model;
> drools-core (2 usages found)
> org.drools.core.builder.conf.impl (2 usages found)
> JaxbConfigurationImpl.java (2 usages found)
> (28: 8) import com.sun.tools.xjc.Language;
> (34: 8) import com.sun.tools.xjc.Options;
> kie-internal (6 usages found)
> /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found)
> pom.xml (1 usage found)
> (27: 15) com.sun.tools.xjc;resolution:=optional,
> org.kie.internal.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (23: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.kie.internal.builder.help (2 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (1 usage found)
> (30: 8) import com.sun.tools.xjc.Options;
> knowledge-api (8 usages found)
> org.drools.builder (3 usages found)
> JaxbConfiguration.java (1 usage found)
> (21: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactory.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderFactoryService.java (1 usage found)
> (24: 8) import com.sun.tools.xjc.Options;
> org.drools.builder.help (3 usages found)
> DroolsJaxbHelperProvider.java (1 usage found)
> (29: 8) import com.sun.tools.xjc.Options;
> KnowledgeBuilderHelper.java (2 usages found)
> (32: 8) import com.sun.tools.xjc.Language;
> (33: 8) import com.sun.tools.xjc.Options;
> org.drools.impl (1 usage found)
> KnowledgeBuilderFactoryServiceImpl.java (1 usage found)
> (16: 8) import com.sun.tools.xjc.Options;
> org.drools.impl.adapters (1 usage found)
> JaxbConfigurationAdapter.java (1 usage found)
> (3: 8) import com.sun.tools.xjc.Options;
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months