[JBoss JIRA] (JBRULES-3585) Drools Planner should support JSR-331 too (for those that prefer math equations as constraints over object-orientated constraints)
3:42 a.m.
Geoffrey De Smet created JBRULES-3585:
-----------------------------------------
Summary: Drools Planner should support JSR-331 too (for those that prefer
math equations as constraints over object-orientated constraints)
Key: JBRULES-3585
URL: https://issues.jboss.org/browse/JBRULES-3585
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Priority: Minor
JSR-331 is a constraint programming standardization effort and we could create a
drools-planner-jsr331 to bridge that API.
- Such a module shouldn't pose to many technical difficulties (it's basically
translating the math equations in primitive based rules)
- Such a module is a lot of effort none-the less. There need to be enough users actually
wanting to use JSR 331.
Personally, I doubt many users would prefer math equations to write their constraints
(vote on this issue to prove me wrong). Here's an example why:
In Drools scoreDRL you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of
it's depended services running in it's neighborhood
rule "serviceDependency"
when
$serviceDependency : MrServiceDependency($fromService : fromService, $toService :
toService)
$processAssignment : MrProcessAssignment(service == $fromService, $neighborhood :
neighborhood)
not MrProcessAssignment(service == $toService, neighborhood == $neighborhood)
then
// Constraint broken
end
{code}
In a Java ScoreDirector, you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of
it's depended services running in it's neighborhood
for (MrServiceDependency serviceDependency : serviceDependencyList) { // TODO use Maps
for (MrProcessAssignment processAssignment :
serviceToProcessAssignmentMap.get(serviceDependency.getFromService()) {
if
(!neighborhoodToServiceListMap.get(processAssignment.getNeighborhood()).contains(serviceDependency.toService())
{
// Constraint broken
}
}
}
In JSR-331, which doesn't support Object-Orientation in it's constraints, this
wouldn't look good.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:42 a.m.
[
https://issues.jboss.org/browse/JBRULES-3585?page=com.atlassian.jira.plug...
]
Geoffrey De Smet updated JBRULES-3585:
--------------------------------------
Description:
JSR-331 is a constraint programming standardization effort and we could create a
drools-planner-jsr331 to bridge that API.
- Such a module shouldn't pose to many technical difficulties (it's basically
translating the math equations in primitive based rules)
- Such a module is a lot of effort none-the less. There need to be enough users actually
wanting to use JSR 331.
Personally, I doubt many users would prefer math equations to write their constraints.
Vote on this issue to prove me wrong and request JSR-331 support in Drools Planner.
Here's an example why I think that:
In Drools scoreDRL you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of
it's depended services running in it's neighborhood
rule "serviceDependency"
when
$serviceDependency : MrServiceDependency($fromService : fromService, $toService :
toService)
$processAssignment : MrProcessAssignment(service == $fromService, $neighborhood :
neighborhood)
not MrProcessAssignment(service == $toService, neighborhood == $neighborhood)
then
// Constraint broken
end
{code}
In a Java ScoreDirector, you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of
it's depended services running in it's neighborhood
for (MrServiceDependency serviceDependency : serviceDependencyList) { // TODO use Maps
for (MrProcessAssignment processAssignment :
serviceToProcessAssignmentMap.get(serviceDependency.getFromService()) {
if
(!neighborhoodToServiceListMap.get(processAssignment.getNeighborhood()).contains(serviceDependency.toService())
{
// Constraint broken
}
}
}
{code}
In JSR-331, which doesn't support Object-Orientation in it's constraints, this
wouldn't look good.
was:
JSR-331 is a constraint programming standardization effort and we could create a
drools-planner-jsr331 to bridge that API.
- Such a module shouldn't pose to many technical difficulties (it's basically
translating the math equations in primitive based rules)
- Such a module is a lot of effort none-the less. There need to be enough users actually
wanting to use JSR 331.
Personally, I doubt many users would prefer math equations to write their constraints
(vote on this issue to prove me wrong). Here's an example why:
In Drools scoreDRL you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of
it's depended services running in it's neighborhood
rule "serviceDependency"
when
$serviceDependency : MrServiceDependency($fromService : fromService, $toService :
toService)
$processAssignment : MrProcessAssignment(service == $fromService, $neighborhood :
neighborhood)
not MrProcessAssignment(service == $toService, neighborhood == $neighborhood)
then
// Constraint broken
end
{code}
In a Java ScoreDirector, you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of
it's depended services running in it's neighborhood
for (MrServiceDependency serviceDependency : serviceDependencyList) { // TODO use Maps
for (MrProcessAssignment processAssignment :
serviceToProcessAssignmentMap.get(serviceDependency.getFromService()) {
if
(!neighborhoodToServiceListMap.get(processAssignment.getNeighborhood()).contains(serviceDependency.toService())
{
// Constraint broken
}
}
}
In JSR-331, which doesn't support Object-Orientation in it's constraints, this
wouldn't look good.
Drools Planner should support JSR-331 too (for those that prefer math
equations as constraints over object-orientated constraints)
----------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-3585
URL: https://issues.jboss.org/browse/JBRULES-3585
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Priority: Minor
JSR-331 is a constraint programming standardization effort and we could create a
drools-planner-jsr331 to bridge that API.
- Such a module shouldn't pose to many technical difficulties (it's basically
translating the math equations in primitive based rules)
- Such a module is a lot of effort none-the less. There need to be enough users actually
wanting to use JSR 331.
Personally, I doubt many users would prefer math equations to write their constraints.
Vote on this issue to prove me wrong and request JSR-331 support in Drools Planner.
Here's an example why I think that:
In Drools scoreDRL you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of
it's depended services running in it's neighborhood
rule "serviceDependency"
when
$serviceDependency : MrServiceDependency($fromService : fromService, $toService :
toService)
$processAssignment : MrProcessAssignment(service == $fromService, $neighborhood :
neighborhood)
not MrProcessAssignment(service == $toService, neighborhood == $neighborhood)
then
// Constraint broken
end
{code}
In a Java ScoreDirector, you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of
it's depended services running in it's neighborhood
for (MrServiceDependency serviceDependency : serviceDependencyList) { // TODO use Maps
for (MrProcessAssignment processAssignment :
serviceToProcessAssignmentMap.get(serviceDependency.getFromService()) {
if
(!neighborhoodToServiceListMap.get(processAssignment.getNeighborhood()).contains(serviceDependency.toService())
{
// Constraint broken
}
}
}
{code}
In JSR-331, which doesn't support Object-Orientation in it's constraints, this
wouldn't look good.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:56 a.m.
[
https://issues.jboss.org/browse/JBRULES-3585?page=com.atlassian.jira.plug...
]
Geoffrey De Smet updated JBRULES-3585:
--------------------------------------
Description:
JSR-331 is a constraint programming standardization effort and we could create a
drools-planner-jsr331 to bridge that API.
- Such a module shouldn't pose to many technical difficulties (it's basically
translating the math equations in primitive based rules)
- Such a module is a lot of effort none-the less. There need to be enough users actually
wanting to use JSR 331.
Personally, I doubt many users would prefer math equations to write their constraints.
Vote on this issue to prove me wrong and request JSR-331 support in Drools Planner.
Here's an example why I think that:
In Drools scoreDRL you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of
it's depended services running in it's neighborhood
rule "serviceDependency"
when
$serviceDependency : MrServiceDependency($fromService : fromService, $toService :
toService)
$processAssignment : MrProcessAssignment(service == $fromService, $neighborhood :
neighborhood)
not MrProcessAssignment(service == $toService, neighborhood == $neighborhood)
then
// Constraint broken
end
{code}
In a Java ScoreDirector, you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of
it's depended services running in it's neighborhood
for (MrServiceDependency serviceDependency : serviceDependencyList) { // TODO use Maps
for (MrProcessAssignment processAssignment :
serviceToProcessAssignmentListMap.get(serviceDependency.getFromService()) {
if
(!neighborhoodToServiceListMap.get(processAssignment.getNeighborhood()).contains(serviceDependency.toService())
{
// Constraint broken
}
}
}
{code}
In JSR-331, which doesn't support Object-Orientation in it's constraints, this
wouldn't look good.
was:
JSR-331 is a constraint programming standardization effort and we could create a
drools-planner-jsr331 to bridge that API.
- Such a module shouldn't pose to many technical difficulties (it's basically
translating the math equations in primitive based rules)
- Such a module is a lot of effort none-the less. There need to be enough users actually
wanting to use JSR 331.
Personally, I doubt many users would prefer math equations to write their constraints.
Vote on this issue to prove me wrong and request JSR-331 support in Drools Planner.
Here's an example why I think that:
In Drools scoreDRL you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of
it's depended services running in it's neighborhood
rule "serviceDependency"
when
$serviceDependency : MrServiceDependency($fromService : fromService, $toService :
toService)
$processAssignment : MrProcessAssignment(service == $fromService, $neighborhood :
neighborhood)
not MrProcessAssignment(service == $toService, neighborhood == $neighborhood)
then
// Constraint broken
end
{code}
In a Java ScoreDirector, you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of
it's depended services running in it's neighborhood
for (MrServiceDependency serviceDependency : serviceDependencyList) { // TODO use Maps
for (MrProcessAssignment processAssignment :
serviceToProcessAssignmentMap.get(serviceDependency.getFromService()) {
if
(!neighborhoodToServiceListMap.get(processAssignment.getNeighborhood()).contains(serviceDependency.toService())
{
// Constraint broken
}
}
}
{code}
In JSR-331, which doesn't support Object-Orientation in it's constraints, this
wouldn't look good.
Drools Planner should support JSR-331 too (for those that prefer math
equations as constraints over object-orientated constraints)
----------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-3585
URL: https://issues.jboss.org/browse/JBRULES-3585
Project: Drools
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: drools-planner
Reporter: Geoffrey De Smet
Priority: Minor
JSR-331 is a constraint programming standardization effort and we could create a
drools-planner-jsr331 to bridge that API.
- Such a module shouldn't pose to many technical difficulties (it's basically
translating the math equations in primitive based rules)
- Such a module is a lot of effort none-the less. There need to be enough users actually
wanting to use JSR 331.
Personally, I doubt many users would prefer math equations to write their constraints.
Vote on this issue to prove me wrong and request JSR-331 support in Drools Planner.
Here's an example why I think that:
In Drools scoreDRL you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of
it's depended services running in it's neighborhood
rule "serviceDependency"
when
$serviceDependency : MrServiceDependency($fromService : fromService, $toService :
toService)
$processAssignment : MrProcessAssignment(service == $fromService, $neighborhood :
neighborhood)
not MrProcessAssignment(service == $toService, neighborhood == $neighborhood)
then
// Constraint broken
end
{code}
In a Java ScoreDirector, you say something like this:
{code}
// Dependency constraints: each process of a service must have at least one process of
it's depended services running in it's neighborhood
for (MrServiceDependency serviceDependency : serviceDependencyList) { // TODO use Maps
for (MrProcessAssignment processAssignment :
serviceToProcessAssignmentListMap.get(serviceDependency.getFromService()) {
if
(!neighborhoodToServiceListMap.get(processAssignment.getNeighborhood()).contains(serviceDependency.toService())
{
// Constraint broken
}
}
}
{code}
In JSR-331, which doesn't support Object-Orientation in it's constraints, this
wouldn't look good.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5101
days inactive
5101
days old
2 comments
1 participants
participants (1)
-
Geoffrey De Smet (JIRA)