[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-3705?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov updated WFLY-3705:
---------------------------------
Description:
The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
{noformat}
final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
{noformat}
The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
The proper implementation should be:
{noformat}
final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
(!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
{noformat}
was:
The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
{noformat}
final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
{noformat}
The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
The proper implementation should be:
{noformat}
final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
(!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
{noformat}
> read-resource recursive-depth has no effect
> -------------------------------------------
>
> Key: WFLY-3705
> URL: https://issues.jboss.org/browse/WFLY-3705
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> Reporter: Arcadiy Ivanov
> Assignee: Brian Stansberry
>
> The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
> {noformat}
> The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
> recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
> The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
> The proper implementation should be:
> {noformat}
> final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
> final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
> (!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-3705) read-resource recursive-depth has no effect
by Arcadiy Ivanov (JIRA)
Arcadiy Ivanov created WFLY-3705:
------------------------------------
Summary: read-resource recursive-depth has no effect
Key: WFLY-3705
URL: https://issues.jboss.org/browse/WFLY-3705
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.1.0.Final
Environment: Linux aimobile-sm.servicemesh.com 3.15.7-200.fc20.x86_64 #1 SMP Mon Jul 28 18:50:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Arcadiy Ivanov
Assignee: Brian Stansberry
The code inside ReadResourceHandler.doExecuteInternal(OperationContext context, ModelNode operation) goes as follows:
{noformat}
final int recursiveDepth = operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).asInt(0);
final boolean recursive = recursiveDepth > 0 || operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false);
{noformat}
The [documentation|https://docs.jboss.org/author/display/WFLY8/Global+operations] states:
recursive-depth – (int) – The depth to which information about child resources should be included *if recursive is {{true}*. If not set, the depth will be unlimited; i.e. all descendant resources will be included.
The logic, however, as implemented goes - either recursive-depth is greater than zero OR recursive is true.
The proper implementation should be:
{noformat}
final boolean recursive = operation.get(ModelDescriptionConstants.RECURSIVE).asBoolean(false) &&
(!operation.get(ModelDescriptionConstants.RECURSIVE_DEPTH).isDefined() || recursiveDepth > 0);
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (WFLY-2627) EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior
by Norbert Bumm (JIRA)
[ https://issues.jboss.org/browse/WFLY-2627?page=com.atlassian.jira.plugin.... ]
Norbert Bumm updated WFLY-2627:
-------------------------------
Attachment: wildfly-src-7.2.0.Final-TransactionBug.patch
Patch for wildfly 7.2.0.Final to fix this bug and WFLY-67
> EJB container-transaction configuration with ejb-jar.xml leads to wrong transaction behavior
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-2627
> URL: https://issues.jboss.org/browse/WFLY-2627
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, Transactions
> Environment: jdk1.7.0_45_x64, Windows 7
> Reporter: Norbert Bumm
> Assignee: David Lloyd
> Attachments: arquillian-jpa.zip, wildfly-src-7.2.0.Final-TransactionBug.patch
>
>
> If there is a global transaction declaration for “Supports” and a “Required” declaration for a specific Method the “Required” gets ignored. I first encountered the problem with an old 2.1 EJB, but the problem is also there with a 3.1 EJB with deployment descriptor. It works correct with annotations.
> ejb-jar.xml snippet
> {code:xml}
> <container-transaction>
> <method>
> <ejb-name>UserDAOImpl</ejb-name>
> <method-name>*</method-name>
> </method>
> <trans-attribute>Supports</trans-attribute>
> </container-transaction>
> <container-transaction>
> <method>
> <ejb-name>UserDAOImpl</ejb-name>
> <method-intf>Local</method-intf>
> <method-name>createUser</method-name>
> </method>
> <trans-attribute>Required</trans-attribute>
> </container-transaction>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114)
by Vsevolod Minkov (JIRA)
[ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin... ]
Vsevolod Minkov edited comment on DROOLS-329 at 8/2/14 5:49 AM:
----------------------------------------------------------------
The workaround is using newer version of org.eclipse.jdt.core.compiler:ecj (4.4 works fine)
was (Author: vsevolod.minkov):
The workaroung is using newer version of org.eclipse.jdt.core.compiler:ecj (4.4 works fine)
> ClassFormatException when compile template with latest JDK8 (b114)
> ------------------------------------------------------------------
>
> Key: DROOLS-329
> URL: https://issues.jboss.org/browse/DROOLS-329
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final, 6.0.0.CR5
> Environment: Ubuntu linux, latest JDK1.8 (b114) downloaded from https://jdk8.java.net/download.html
> Reporter: Marek Posolda
> Assignee: Mark Proctor
> Fix For: 5.5.1.Final, 6.2.0.Beta1
>
>
> When trying to run code for compile templates with latest JDK8 (For instance this example https://github.com/droolsjbpm/drools/blob/master/drools-examples/src/main... )
> it will throw an exception like this:
> {code}
> Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: wrong class format
> at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:148)
> at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:62)
> at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74)
> at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:95)
> at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:81)
> at org.drools.examples.templates.SimpleRuleTemplateExample.buildKBase(SimpleRuleTemplateExample.java:84)
> at org.drools.examples.templates.SimpleRuleTemplateExample.executeExample(SimpleRuleTemplateExample.java:49)
> at org.drools.examples.templates.SimpleRuleTemplateExample.main(SimpleRuleTemplateExample.java:43)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.RuntimeException: wrong class format
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:263)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:203)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
> at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1188)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1244)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1031)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1193)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:495)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:577)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:327)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:640)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:619)
> at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:133)
> at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:465)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:519)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:368)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:444)
> at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:752)
> at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:464)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:389)
> at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:371)
> at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46)
> at org.drools.compiler.PackageRegistry.compileAll(PackageRegistry.java:102)
> at org.drools.compiler.PackageBuilder.compileAll(PackageBuilder.java:1006)
> at org.drools.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:842)
> at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:831)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:441)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:419)
> at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:139)
> ... 12 more
> Caused by: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
> at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258)
> ... 45 more
> {code}
> Workaround, which worked for me is to switch to Janino compiler (See Workaround description)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114)
by Vsevolod Minkov (JIRA)
[ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin... ]
Vsevolod Minkov commented on DROOLS-329:
----------------------------------------
The workaroung is using newer version of org.eclipse.jdt.core.compiler:ecj (4.4 works fine)
> ClassFormatException when compile template with latest JDK8 (b114)
> ------------------------------------------------------------------
>
> Key: DROOLS-329
> URL: https://issues.jboss.org/browse/DROOLS-329
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final, 6.0.0.CR5
> Environment: Ubuntu linux, latest JDK1.8 (b114) downloaded from https://jdk8.java.net/download.html
> Reporter: Marek Posolda
> Assignee: Mark Proctor
> Fix For: 5.5.1.Final, 6.2.0.Beta1
>
>
> When trying to run code for compile templates with latest JDK8 (For instance this example https://github.com/droolsjbpm/drools/blob/master/drools-examples/src/main... )
> it will throw an exception like this:
> {code}
> Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: wrong class format
> at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:148)
> at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:62)
> at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74)
> at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:95)
> at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:81)
> at org.drools.examples.templates.SimpleRuleTemplateExample.buildKBase(SimpleRuleTemplateExample.java:84)
> at org.drools.examples.templates.SimpleRuleTemplateExample.executeExample(SimpleRuleTemplateExample.java:49)
> at org.drools.examples.templates.SimpleRuleTemplateExample.main(SimpleRuleTemplateExample.java:43)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.RuntimeException: wrong class format
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:263)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:203)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102)
> at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1188)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1244)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1031)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1193)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:495)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:577)
> at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:327)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:640)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:619)
> at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295)
> at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:133)
> at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:465)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:519)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:368)
> at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:444)
> at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:752)
> at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:464)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:389)
> at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49)
> at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:371)
> at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46)
> at org.drools.compiler.PackageRegistry.compileAll(PackageRegistry.java:102)
> at org.drools.compiler.PackageBuilder.compileAll(PackageBuilder.java:1006)
> at org.drools.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:842)
> at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:831)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:441)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:419)
> at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:139)
> ... 12 more
> Caused by: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException
> at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287)
> at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258)
> ... 45 more
> {code}
> Workaround, which worked for me is to switch to Janino compiler (See Workaround description)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (DROOLS-553) Build does not build on maven 3.2.2 with an empty repository
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-553?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet commented on DROOLS-553:
-----------------------------------------
See https://plus.google.com/114843822427522708527/posts/fFmqTkH53pa
> Build does not build on maven 3.2.2 with an empty repository
> ------------------------------------------------------------
>
> Key: DROOLS-553
> URL: https://issues.jboss.org/browse/DROOLS-553
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
> Priority: Blocker
>
> Our community contributors should be able to just build our stuff with the latest maven version. Currently that doesn't work.
> Building with maven 3.0.5 works.
> To reproduce:
> - Use maven 3.2.2
> - Build droolsjbpm-build-bootstrap
> - Do not build uberfire first
> - rm ~/.m2/repository/org/uberfire
> => this will force droolsjbpm-build-bootstrap to download the uberfire-bom 6.2.0-SNAPSHOT, which fails with maven 3.2.2:
> {code}
> $ mvn clean install -Dfull -DskipTests -U
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project org.kie:kie-parent-with-dependencies:6.2.0-SNAPSHOT (/Users/.../OptaPlanner/droolsjbpm-build-bootstrap/kie-parent-with-dependencies/pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not find artifact org.uberfire:uberfire-bom:pom:0.4.2-SNAPSHOT @ org.kie:kie-parent-with-dependencies:[unknown-version], /Users/.../OptaPlanner/droolsjbpm-build-bootstrap/kie-parent-with-dependencies/pom.xml, line 137, column 19 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months
[JBoss JIRA] (DROOLS-553) Build does not build on maven 3.2.2 with an empty repository
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-553?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet commented on DROOLS-553:
-----------------------------------------
[~skipcole] I feel your pain, but our readme is already pretty long:
https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/READ...
And most users don't read it (have you read it completely?).
Now, I understand that you'd like that warning to be the first line in that readme:
- but so does anybody else who encounters a pitfall: they all want that their pitfall is the first warning in the readme
- this pitfall only have a very short window of existence: maven 3.2.2 is just out, the regression is already fixed and they implied to release 3.2.3 really soon (TM) now.
- googling the error message brings a user to this jira issue which often happens sooner than the user actually reading the readme...
The root cause needs to fixed, that's the only efficient way to stop wasting people's time (including mine), so I'll add some extra, *polite* pressure on maven to release 3.2.3 (feel free to do the same), that will actually help.
> Build does not build on maven 3.2.2 with an empty repository
> ------------------------------------------------------------
>
> Key: DROOLS-553
> URL: https://issues.jboss.org/browse/DROOLS-553
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
> Priority: Blocker
>
> Our community contributors should be able to just build our stuff with the latest maven version. Currently that doesn't work.
> Building with maven 3.0.5 works.
> To reproduce:
> - Use maven 3.2.2
> - Build droolsjbpm-build-bootstrap
> - Do not build uberfire first
> - rm ~/.m2/repository/org/uberfire
> => this will force droolsjbpm-build-bootstrap to download the uberfire-bom 6.2.0-SNAPSHOT, which fails with maven 3.2.2:
> {code}
> $ mvn clean install -Dfull -DskipTests -U
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project org.kie:kie-parent-with-dependencies:6.2.0-SNAPSHOT (/Users/.../OptaPlanner/droolsjbpm-build-bootstrap/kie-parent-with-dependencies/pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not find artifact org.uberfire:uberfire-bom:pom:0.4.2-SNAPSHOT @ org.kie:kie-parent-with-dependencies:[unknown-version], /Users/.../OptaPlanner/droolsjbpm-build-bootstrap/kie-parent-with-dependencies/pom.xml, line 137, column 19 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 2 months