added tomcat.executable property
by Tom Baeyens
Hi,
in the hudson properties, i added a tomcat executable property
it was set fixed to catalina.sh. the property allowes to set it to catalina.bat on
windows
--
regards, tom.
17 years
Re: excluding ejb-scheduler-test from tests against non-xa datasources
by Thomas Diesler
Hi Alejandro,
Our QA environment is a three dimensional matrix: jdk,container,database
Ideally, we would be able to exclude a test based on these three
parameters. This however is currently not supported, instead we can only
exclude tests based on database.
In your specific case, would it not be sufficient to exclude the
EjbSchedulerTest for postgresql?
What should be clear however is, that if a certain test/functionality is
excluded we document that jBPM does not support that functionality in
the environment it is excluded in.
cheers
-thomas
Alejandro Guizar wrote:
> Thomas,
>
> I've been trying several ways to prevent EjbSchedulerTest from being run
> against databases that do not have XA support. In my current approach I
> have a property named datasource.xa that is set in the corresponding
> database profiles in the base POM file. For instance, the postgresql
> profile is:
>
> <profile>
> <id>postgresql</id>
> <activation>
> <property>
> <name>database</name>
> <value>postgresql</value>
> </property>
> </activation>
> <properties>
> <datasource.xa />
> </properties>
> </profile>
>
> In modules/enterprise/jar/pom.xml, I have defined two separate profiles
> with different exclude sets, based on the presence of the datasource.xa
> property, as follows.
>
> <profile>
> <id>no-xa-datasource</id>
> <activation>
> <property>
> <name>!datasource.xa</name>
> </property>
> </activation>
> </profile>
>
> <profile>
> <id>xa-datasource</id>
> <activation>
> <property>
> <name>datasource.xa</name>
> </property>
> </activation>
> </profile>
>
> However, the no-xa-datasource always gets activated, unless I pass
> -Ddatasource.xa on the command line. Isn't a property defined in a
> profile visible to other profiles?
>
> I'd appreciate your help here.
>
> -Alejandro
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
BPM Product Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years
[Design of JBoss jBPM] - Re: Future of jBPM???
by KrisVerlaenen
anonymous wrote : I regret that the drools guys put so much effort in duplication. We have had a couple of meetings on this topic. But we couldn't come to a joint PVM strategy yet. Hopefully that will still happen.
The Drools team has always been asking for collaboration with the jBPM team from the start. We presented specific recommendations on how to improve the design of a the current jBPM PVM model in several areas, more than a year ago. We also suggested broadening the scope to make it not process-centric but knowledge-centric, allowing unification and a tight integration (and still loosely-coupled as well of course) between rules and processes.
What you call duplication (and we consider improvement !) was the only option to move forward at that point. The Drools team will continue to actively add new exciting features to the Drools Flow engine. We believe that at this point we already offer most of the features supported by the jBPM engine (and much more), using a superior design.
But we hope the jBPM team would reconsider collaborating with us and we are still open for any type of discussion and collaboration, as it'll allow us to combine our strengths and resources in the most efficient way ...
anonymous wrote : One of the main things I don't see [in Drools Flow] yet is the whole persistence and support of long running processes.
Drools Flow does offer persistence of your runtime process state, by providing JPA-based persistence of process instances, adding support for long-living processes as well.
Kris
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184282#4184282
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184282
17 years
