Hi everyone,
We have been reported of a critical bug in KieSession serialization that has
been fixed with this commit
https://github.com/apache/incubator-kie-drools/commit/f3179021b7e97499e77a79ddceec483f5d568449
For this reason we decided to backport this fix to the 8.x streams and drop a
+1
Mario
On 2024/03/19 14:11:30 Alex Porcelli wrote:
> With all the feedback from the proposal discussion [1], I am starting
> this official vote to accept the amended proposal to unblock Apache
> KIE 10.0.0 Release.
>
> Here [2] is the link for the final amended proposal.
>
> Please cast your
Huge +1 on this.
Mario
On 2024/02/27 03:32:09 Toshiya Kobayashi wrote:
> Hi,
>
> The current DRL parser is Antlr3 based and contains lots of hard-coded
> logic in generated java codes, so it's hard to maintain.
>
> for example)
>
Hi Alex,
Just to clarify the purposes of this effort and from where this originate,
consider that the development of this new ANTLR v4 based parser for the DRL
started even before the migration to Apache and its main goal was to support
the implementation of an LSP server that could allow to
> drools has `drools-reliability` component which persistence is pluggable.
> We have infinispan persistence and h2 persistence at the moment. If we want
> to make the version 10 release "minimal", shall we keep only the h2
> persistence and then move the infinispan persistence to another repo
>
Hi all,
It seems that we are finally ready to conclude the migration to Quarkus 3 and
the jakarta namespace. We're about to merge some last fixes in these hours, so
the plan is to wait the next nightly build and target tomorrow morning to start
finalizing the migration.
In particular what we
+1 on removing the .Final suffix.
Mario
On 2023/11/28 14:03:30 Alex Porcelli wrote:
> We already have defined that all projects/artifacts will be aligned on
> 10. However, we must still determine if we should use 10.0.0 or
> 10.0.0.Final.
>
> I might be ahead, but as we progress towards the
> * Quarkus version
>
> Tibor, Alex and Jason give +1 for LTS 3.2.
>
> Mario, WDYT?
>
> A) Complete Quarkus 3.5.2 migration anyway. After the migration done,
> create a Quarkus 3.2 LTS branch, too.
> B) Recreate the current migration PRs to meet Quarkus 3.2.
I just had a meeting with Alex
to specify that.
>
> 3) Spring Boot version
>
> Pere mentioned
>
> > my guts say that we should upgrade if we have the oportunity but I'm
> affraid it could add more pain.
>
> https://kie.zulipchat.com/#narrow/stream/381961-drools-dev/topic/Quarkus.203.2
> It would be best to agree on a branch name - if it's quarkus3 - and
> generate special pipelines for that branch. So that we have clear
> separation. It would require branching of whole groups of repositories
> (similarly as above - incubator-kie-kogito-apps and others).
Hi Jan,
I agree on
Hi all,
Sorry if I try to rush this, but weeks and months are passing and we really
really need to finalize the migration to Quarkus 3 asap.
Yesterday I created a branch of Drools that bumps it to the latest Quarkus
(3.5.2), see https://github.com/apache/incubator-kie-drools/compare/quarkus3
Hi all,
I just have a call with Tibor and he told me that at the moment we are able to
produce and deploy nightly builds but still we cannot drop a stable release.
Regardless of this latest issue if possible I'd move forward branching 8.x and
applying to main the openrewrite migration scripts
Hi all,
I wrote a first draft of the communicate for the new version numbering on which
we agreed:
https://docs.google.com/document/d/1UV79KnyhayF60pi67vG8sKUHHXLmWaRaH7mIji-n4GE/edit?usp=sharing
Anybody with that link should be able to view and add comments to that
document, then if you
+1 also for me. If we communicate this clearly this will give us a fresh start
that is totally coherent with the apache migration.
If it's ok for you, I can take care of starting writing down a short article to
explain the situation. For now I'll put it on a shared Google docs so everybody
> Well, Kogito 1.x depends on Drools 8.x, so there was already some disparity
> in versions...
Disparity in versions is incidental and doesn't imply a different lifecycle in
this case. Actually what we did so far is always releasing Drools and Kogito in
parallel every 3 weeks at the end of each
eady existing 9.44 release. (It’s my
> understanding that the impact is for users that would use -LATEST - which
> is already considered a deprecated format anyway)
>
> On Mon, Oct 16, 2023 at 9:11 AM Mario Fusco wrote:
>
> > > To me, it feels messy that we have a 8.45
> To me, it feels messy that we have a 8.45.0 release, followed by a 9.45
> release in our first Apache release, and immediately after put 8.x (1.x for
> Kogito) in maintenance.
>
> I think we could step back and re-evaluate our strategy.
>
> Why not reset and focus only on Jakarta10 (and
Hi all,
As mentioned during last Friday's meeting, I believe that we should move
any forward upstream development to Quarkus 3 and Jakarta namespace. That's
because the effort of developing against both Quarkus 2.x and 3.x will be
hardly bearable and the current setup that automatically migrates
Hi Alex,
Sorry if I'm reading and replying to this email with so much delay.
> • The other is from a PPMC member.
In all honesty this specific constraint seems unnecessarily and excessively
restrictive to me. I'm afraid that waiting for an approval from a so small
group of persons for all
Hi David,
sorry but it's impossible for us to figure out what's going wrong in your
case just looking at the stack trace you sent. Have you been able to
consistently reproduce this problem? If so could you open a ticket on jira
and share your reproducer there?
Thanks,
Mario
--
View this
Hi Matteo,
it's honestly virtually impossible to figure out what's causing that NPE
just looking at that stack trace. Do you think you could be able to develop
a reproducer or at least provide us a bit more information?
Thanks,
Mario
--
View this message in context:
Hi,
your last test case evidenced that there was something not covered by my fix
of DROOLS-516.
I resolved this issue with this further commit:
https://github.com/droolsjbpm/drools/commit/a833097b4
Thanks a lot for having reported this and regards,
Mario
--
View this message in context:
Hi Mike,
I merged your test case and fixed the bug with this commit
https://github.com/droolsjbpm/drools/commit/283ba1d94
Thanks a lot for having reported this problem,
Mario
--
View this message in context:
Thanks for your clarifications.
The problem was in mvel. I reproduced and fixed it (
https://github.com/mvel/mvel/commit/874b03a8c5700661b503d96ad5d2ce1397cde18a
). The fix will be available when we will drop another mvel release and
integrate it. For now I can only confirm that field names
Hi,
This seems more a problem of the drools compiler. I'll try to reproduce it
and check what happens. Just one more question: is the field public or is it
accessed through a getter method in your Java class? In case you're using a
getter did you named it get_id or get_Id ?
Thanks,
Mario
--
Hi Jinghai,
I reproduced the problem you reported and pushed a fix for it:
https://github.com/droolsjbpm/drools/commit/83f80c83f
Your reproducer have been very very helpful.
Thanks a lot,
Mario
--
View this message in context:
Hi,
I don't think your problem is caused by that. More likely this is caused by
the issue reported here https://issues.jboss.org/browse/DROOLS-335 that I
fixed with this commit
https://github.com/droolsjbpm/drools/commit/f8f721056e36f8e0370c2783875ff0c26ef0629e
Can you check if your code base
Hi Dominik,
I'm honestly not understanding why you're creating a kieModule and most
important why you're deploying it on maven in a ServletContextListener, but
I am guessing you're doing this only to demonstrate the problem. Also be
aware that for doing so you're using some drools internal API
Hi,
for sure this is not a known issue, so can you please open a jira and attach
your reproducer there?
I'll investigate this problem asap.
Thanks a lot,
Mario
--
View this message in context:
Hi Jinghai,
I cannot reproduce the last issue you're reporting. Every time I introduce
an error both in the java and in the drl code it is reported correctly.
Can you be a bit more explicit about this or even better attaching to the
jira ticket a simple project reproducing this issue?
Thanks,
Hi,
I fixed this issue on master with this commit:
https://github.com/droolsjbpm/droolsjbpm-tools/commit/6bc54748e
This fix will be also backported to 6.0.x branch asap.
Mario
--
View this message in context:
Hi,
I didn't receive any personal email on this issue or at least I cannot find
it at the moment. Anyway sending personal emails complaining for a certain
defect or missing feature isn't of course a good idea.
I'll try to fix this issue asap.
Thanks for having reported it,
Mario
--
View
Hi Josep,
as I anticipated the propName vs. getPropName() issue was only a red herring
and totally unrelated with the actual bug. Investigating in more detail your
test case I found that the problem is that in some circumstances, when using
fireUntilHalt, a single working memory action
Hi Jan,
what you did looks correct and at the moment I have no idea of why you're
experiencing 2 different behaviours when running your code on 2 different
machines. Which version are you using exactly? Can you reproduce this
difference consistently, the 100% of times? Also, since you think the
Hi Josep,
probably there are 2 different issues here, but I am not sure because I
haven't run your test case yet. I'll do it asap.
The first issue could be something similar to what has been already reported
here https://issues.jboss.org/browse/DROOLS-311
As for the different behaviour you
Hi Alex,
sorry but I am not fully understanding your use case.
You wrote that “drools_jar” is a kjar (i.e. is a project containing a
kmodule.xml file) but project_jar” isn't.
Nevertheless in your code snippet you're creating a KieContainer against
project_jar” that actually isn't a kproject. Of
Alex,
sorry but what you're saying is just NOT possible and it doesn't depend on
kie-ci. If your project_jar doesn't contain a kmodule.xml file, you CANNOT
do something like:
ReleaseId releaseId = ks.newReleaseId( com.study, project_jar,
0.0.1-SNAPSHOT );
KieContainer kContainer =
Oops, sorry Mohit (and sorry Alex). I didn't check the sender of the last
email and I thought it was sent by the guy who opened this thread.
However I confirm that it is not possible to create a KieContainer out of a
project that doesn't contain a kmodule.xml file. Do you agree, Mohit?
Mario
Our Jira is here: https://issues.jboss.org/browse/DROOLS
Can you please open a ticket there and also attach your sample projects so I
can be sure that I am reproducing your issue?
Thanks,
Mario
--
View this message in context:
Hi,
I developed a test case almost identical to the one you suggested and I am
pasting it at the end of this email.
In the last months we did a few fixes on the event processing part and
indeed this test works as expected, i.e. the assertion at the end of the
test is true meaning that all the 10K
Hi again,
I've been able to reproduce the last issue with CronTrigger that you
reported (even if not as frequently as you wrote) and I just pushed a very
minor change that should fix also this:
https://github.com/droolsjbpm/drools/commit/94b0c4588
Let me know if you'll have a chance to test
Hi,
I am sorry but I am not sure I am understanding your last email. You wrote:
Namely, when usic the basic pattern for counting (i.e. no CronTrigger),
from time to time the cron triggered rules won't trigger.
What do you mean with no CronTrigger? Can you paste test case you're using
to
Hi again,
I reviewed all our events related code and I just pushed a commit (
https://github.com/droolsjbpm/drools/commit/f415b17cff696136fa83eb9e7837629f5542b24f
) that should fix all the issues you reported. The test cases you provided
have been really precious by the way. Thanks a lot for
Hi,
I am trying to reproduce the issue you reported, but so far I couldn't. This
is drl I am using:
import org.drools.test.SynthEvent
import java.util.Date
declare SynthEvent
@role( event )
@timestamp( timestamp )
end
declare
Hi Jarkko,
where does that ValidationError class come from? Is it a declared type?
How can I reproduce this issue?
Thanks for your help,
Mario
--
View this message in context:
http://drools.46999.n3.nabble.com/NullPointerException-with-factType-get-fact-fieldname-tp4028688p4028735.html
Sent
Hi Dominik,
what you're reporting is not 100% clear to me. Could you also show me the
pom.xml file of de.test.package:artifact:1.0.1?
This is indeed the actual KieProject and then the pom file that our embedded
maven/aether is trying to parse.
Apparently also that pom declares
Hi,
I am not sure I completely agree with what you wrote.
In general all the classes defined in all transitive dependencies could
potentially be used in your domain and then should be indexed by the
KieModuleMetaDataImpl. I'd say that something like: provided scoped modules
could be included,
Ok Dominik,
now the problem is clearer and I can explain you why it is also trying to
parse the pom of the running project (I must admit I forgot this detail): it
is just trying to figure out if you declared some additional repository in
that pom so it could try to download the KieProject also
Joe,
as said by Mark the DummyKieScanner acts only as a placeholder to avoid
tons of null checks inside the code. But you're right when you wrote that
it should fail fast when requested to load an artifact. I'll make the
DummyKieScanner.loadArtifact methods to throw a more meaningful Exception
You're right Wolfgang. The problem is that kie-ci has been mistakenly left
out from the drools-distribution.
I fixed this issue last week, so it will be packaged in the distribution
together with other jars from next release.
In the meanwhile you can download it from the maven repository, for
Wolfgang,
that class is part of the kie-ci.jar. Do you have it on your classpath?
Mario
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-KieRepositoryScannerImpl-missing-in-6-0-0-tp4028533p4028534.html
Sent from the Drools: User forum mailing list archive at
Hi,
I suggest to use a persisted session instead of doing the marshalling on
your own. Find documentation about it here:
http://docs.jboss.org/drools/release/5.5.0.Final/drools-expert-docs/html_single/#d0e3961
Note that it is strongly discouraged (and in the next releases will be
totally
Ciao Matteo,
I tried the test case attached to DROOLS-419 and it works for me.
To be more precise what I tried it is simply installing the kjar you
provided on my local maven repo and check that the main class of your second
project is able to retrieve the kjar and build the drools project
I downloaded your zip file and reproduced the problem you reported (even on
master branch).
I'll start investigating it in a bit and I'll keep you updated with my
findings.
Thank you,
Mario
--
View this message in context:
I just fixed this issue on master with this commit:
https://github.com/droolsjbpm/drools/commit/fb7c8858f
Thank you for having reported it,
Mario
--
View this message in context:
Hi,
I'd like to reproduce and verify your performance claims.
If you found a performance regression it would be very interesting for me to
investigate it.
Could you please send a small self-contained project with the benchmarks you
tried?
Personally I believe that The tests also show that
brachi wrote
1. does exist an option to dismiss this error, even if it says to disable
this mvel constraints optimizations?
It is just an harmless log statement and if you want to silent it you just
have to configure your logback.xml file accordingly (i.e. raising the log
level of
Hi,
I am one of the core developer of Drools and I am trying to debug and fix a
problem reported by one of our user in this email
http://drools.46999.n3.nabble.com/Drools-6-0-1-xstream-marshaling-via-camel-config-not-working-td4027607.html
I can reproduce the issue he reported, but not being a
Hi,
the MinimalPomParser is an xml parser we developed internally to cover the
most common and straightforward cases, but very likely it is unable to parse
the multi-module pom you're using.
However adding the kie-ci module to your dependencies (
Hi Vimal,
By default maven reads 2 settings.xml files: the one located in your M2_HOME
and the one in your local repository that usually is under ${user_home}/.m2,
so yes, to make this works you should set the M2_HOME environment variable.
However you can override this default using the
Hi Loïc,
That MvelConstraint class is part of the new constraint evaluation mechanism
I started developing with Drools 5.4 and further improved in the subsequent
releases.
However I've never had a similar problem. I'll try to reproduce this issue
based on what you wrote, but it could be very
Hi,
unfortunately you're right. I reproduced the problem regarding the need of
the duplicate dependencies declarations inside the plugin. I opened a ticket
on jira to report this issue ( https://issues.jboss.org/browse/DROOLS-373 )
and already pushed a fix on the master branch for it (
Hi,
the problem with the last code you pasted is that you're passing to the
KieContainer a ReleaseId with a fixed non-snapshot version. Version 1.0.0
can be installed only once in a maven repository so the KieScanner assumes
there's no need to do a further scan. To overcome this problem you
Hi,
I think there's a bit of confusion here and I agree this is caused by not
exhaustive documentation (we are trying to improve it).
The permgen threshold option is used for constraint jitting and that one
works exactly in the same way regardless of the dialects. However when using
the java
Raphael,
the option to disable jitting is in the class PermGenThresholdOption and the
property name is drools.permgenThreshold.
The idea there was that the main problem that jitting could cause is the
PermGen occupation, so we decided to provide an option to set the percentage
of PermGen space
I agree with Davide when he wrote that very likely your issue is totally
unrelated with property reactivity.
I will try to reproduce the CCE you're reporting, but I suspect it could be
related with the use of Janino as Java compiler. Is there any particular
reason why you're using it? If not I
There's only a technical reason: we need to map each property with a bit in a
bitmask to implement that feature and we are using a long as bitmask. We
could use a BitSet to overcome this limitation but this will come with a
performance cost and at the moment we don't want to pay this price for
Hi,
due to generic erasure we cannot figure out that the outer map contains a
second map as value. That's why you have to explicitly downcast the value
returned by the first map. For instance this should work:
((Map) field[ parentKey ])[ childKey ]
I hope this helps,
Mario
--
View this
Hi all,
we are about to finalize Drools 5.6 and we would like to complete this
process as soon as possible.
However we would also like to be sure that we are not leaving any important
fix out, so please, if you want to signal any outstanding issue, report it
with a proper reproducer within one
Hi all,
we are about to finalize Drools 5.6 and we would like to complete this
process as soon as possible.
However we would also like to be sure that we are not leaving any important
fix out, so please, if you want to signal any outstanding issue, report it
with a proper reproducer within one
Something in the middle. That warning is saying that for some reason drools
isn't able to jit a constraint, i.e. to create a compiled constraint from an
interpreted one. This is harmless in the sense that when this happens the
compiled constraint gets automatically discarded and it continues being
I tried to reproduce this issue on both the 6.x and on the 5.6.x branches and
it works for me
https://github.com/droolsjbpm/drools/blob/ba41255fecb48614e6ef6b67843548777a8a6193/drools-compiler/src/test/java/org/drools/compiler/integrationtests/CustomOperatorTest.java#L177
Let me know if I am
I am not sure if you can republish it somewhere else but I don't think so.
You could just link it from your blog if you want.
I will ask to the Dzone guy I am in touch with if it can be published in a
blog, but I am quite skeptical about it.
Mario
--
View this message in context:
:36, Mario Fusco wrote:
... I am realizing we are not providing a way in kie-api to create a
KieBaseConfiguration or KieSessionConfiguration programmatically. ...
OptaPlanner needs to be in the kie-api too, because it uses:
KieBaseConfiguration kieBaseConfiguration
Hi Daniel,
thanks for having reported this ... as you can imagine we don't have many
Windows machines here :)
Anyway I just fixed this issue and the fix will be available starting from
the 6.0-Beta4 version that will be released during this week.
Thanks again and regards,
Mario
--
View this
Quotes from Javadoc of 6.0.0 Beta 3
(1)
org.kie.api.builder Interface KieBuilder
Sets the other KieModules from which the KieModule that has to be
built by this KieBuilder depends on
Sets the other Resources from which the KieModule that has to be
built by this KieBuilder depends on
I
Wolfgang,
this is a really good point. Of course, the preferred way in Drools 6 to
configure both KieBases and KieSessions should be through the kmodule.xml.
Anyway I am realizing we are not providing a way in kie-api to create a
KieBaseConfiguration or KieSessionConfiguration programmatically.
Thanks for clarifying this issue Wolfgang.
I will check if I can fix this issue ( I am also skeptical about it ),
otherwise I will at least generate a more proper compilation failure.
Mario
On Wed, Feb 27, 2013 at 11:03 AM, Wolfgang Laun wolfgang.l...@gmail.comwrote:
PLEASE READ CAREFULLY, AND
Hi Wolfgang,
thanks for having reported this.
I fixed it in mvel and as usual the fix will be available with the next
mvel release.
Cheers,
Mario
On Sun, Feb 17, 2013 at 5:32 PM, Wolfgang Laun wolfgang.l...@gmail.comwrote:
Below is a fully self-contained DRL that compiles correctly but runs
Hi Wolfgang,
thanks for having reported this.
I fixed it in mvel and as usual the fix will be available with the next
mvel release.
Cheers,
Mario
On Sun, Feb 17, 2013 at 5:32 PM, Wolfgang Laun wolfgang.l...@gmail.comwrote:
Below is a fully self-contained DRL that compiles correctly but runs
Magnus,
I just fixed this on the master and backported it to the 5.5.x branch.
Thanks again for your precious help,
Mario
On Tue, Feb 12, 2013 at 11:42 AM, magnusv
magnus.vojba...@digitalroute.comwrote:
Hi Mario, sorry for the delay!
Attached is the reference chain between
Hi Magnus,
thanks for having reported this. What you found is quite interesting and I
will give a look at this issue asap.
In the meanwhile it would be great if you could open a ticket about it
here: https://issues.jboss.org/browse/DROOLS
Thanks again and regards,
Mario
On Mon, Feb 11, 2013 at
Magnus,
I am giving a look at this ticket just now but honestly cannot find where
that MarshallerReaderContext is referenced inside the ReteooStatefulSession.
It would be very helpful if you could send me the complete reference chain
from the ReteooStatefulSession to the MarshallerReaderContext
Hi Michael,
This time I didn't it by mistake but intentionally (well, kind of): for
some reason my Intellij Idea didn't like the pom when I wrote it without
specifying the version of that dependency. I spent a while to figure out
why, but in the end the only way I found to make Idea eating the
Hi all,
after a (quite long) discussion with Mark, Edson and Michael we realized
that, to support the guided editor roundtrip without dropping our current
DSL features, we need a new format allowing to mix plain DRL and DSL
sentences but delimiting these last ones in a clear (and easy to
I am starting working to the similar (mvel?) bug you reported last week
just now.
Hopefully the fix will solve even this further problem, anyway I will add
it to our test suite.
Mario
On Tue, Jan 22, 2013 at 12:24 PM, Wolfgang Laun wolfgang.l...@gmail.comwrote:
Below is a self-contained DRL
Wolfgang,
in the end I found that this issue and the one you reported last week were
not related.
Anyway I fixed both, but as usual the fixes will be available when I'll
deploy the next mvel release.
Thanks again for your help,
Mario
On Tue, Jan 22, 2013 at 12:24 PM, Wolfgang Laun
I am starting working to the similar (mvel?) bug you reported last week
just now.
Hopefully the fix will solve even this further problem, anyway I will add
it to our test suite.
Mario
On Tue, Jan 22, 2013 at 12:24 PM, Wolfgang Laun wolfgang.l...@gmail.comwrote:
Below is a self-contained DRL
Wolfgang,
in the end I found that this issue and the one you reported last week were
not related.
Anyway I fixed both, but as usual the fixes will be available when I'll
deploy the next mvel release.
Thanks again for your help,
Mario
On Tue, Jan 22, 2013 at 12:24 PM, Wolfgang Laun
I just fixed this bug on the master and backported it on the 5.5.x branch.
Wolfgang, thanks again for your help.
Mario
On Sun, Jan 20, 2013 at 9:23 AM, Wolfgang Laun wolfgang.l...@gmail.comwrote:
Below is another couple of test cases, showing that the problem is not due
a getter that isn't
I just fixed this bug on the master and backported it on the 5.5.x branch.
Wolfgang, thanks again for your help.
Mario
On Sun, Jan 20, 2013 at 9:23 AM, Wolfgang Laun wolfgang.l...@gmail.comwrote:
Below is another couple of test cases, showing that the problem is not due
a getter that isn't
The NoSuchMethodError makes me think that you're using the wrong mvel
version.
The correct one is 2.1.3.Final. Can you check if you're running with that
one?
Thanks,
Mario
--
View this message in context:
Thank you Wolfgang,
your bug report is crystal clear as usual ;)
I'll try to reproduce and fix this asap.
Mario
On Thu, Jan 17, 2013 at 7:29 AM, Wolfgang Laun wolfgang.l...@gmail.comwrote:
The error occurs when the following rule fires ;-)
rule error occurs
$fact1: Fact( $class: class )
I'll give a look at it asap.
Thanks for reporting this.
On Sun, Jan 13, 2013 at 7:27 PM, Wolfgang Laun wolfgang.l...@gmail.comwrote:
5.5.0. This simple DRL does not compile unless dialect mvel is
removed. insert is not recognized within a for loop body.
rule demo
dialect mvel
when
then
Hi Wolfgang,
thanks for having pointed this out.
I reproduced this issue and, with Mark's help, fixed it. I just pushed the
fix on the master and backported it to both the 5.5.x and 5.4.x branches.
Mario
On Mon, Dec 17, 2012 at 12:29 PM, Wolfgang Laun wolfgang.l...@gmail.comwrote:
package
Hi Paul,
sorry for the delay in my reply. The issue you're reporting looks very weird
at least because it seems to depend on the specific values you put in that
expression. It would be great if you could open a ticket on jira and
possibly attach to the ticket a test case to reproduce the bug.
FYI, here is Brian's summary of the situation about Optional in Java 8.
Hopefully, this will provide some background on why things are the way they
are.
I have already seen that email but It doesn't clarify my doubts at all. I
wonder how it clarifies yours.
The problem is with the
A lot of failing tests probably due to merging in the UberFire integration
changes.
I have asked Geoffrey to take a look for us.
http://hudson.qa.jboss.com/hudson/job/droolsjbpm-tools/
A lot of failing tests that possibly relate to something Mario fixed (the
tests fail after a commit he
ok, the Brian Goetz responded to these concerns:
http://mail.openjdk.java.net/pipermail/lambda-dev/2012-October/006365.html
The JDK perspective makes sense now. These guys are definitely super smart
guys.
Probably I am missing something, but what I read is just: the goal is NOT
to
This is the important question of this thread and it's not a technical
issue that a typical developer such as myself would have much utility with.
Ideally, this is where the more well connected and influential members of
the group, or even the Java Posse themselves, should comment.
This
1 - 100 of 216 matches
Mail list logo
