Calendars may be rarely used but nonetheless I've seen several
inquiries about them on the user list. Using calendars is well enough
documented in Drools Expert, and it hyperlink-points you to
State-of-the-art dependency handling may require me to download
additional packages (as, e.g., in does CPAN), but it does tell me that
something else is required. Release information isn't about
requirements for building; but it sure ought to include (or refer to)
all a user needs to construct a complete runtime.
What you have in the pom is deprecating if not already deprecated, see
On 07/03/2012, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com> wrote:
quartz is optional in droolsjbpm-knowledge, because most people don't
<scope>provided</scope><!-- This should really be scope:compile with
the version is inherited from the droolsjbpm-parent:
The pom's actually have all the dependency information. Just the maven
tools to expose that visually is pathetic to what it could be.
Trying to keep a ReadMe up to date with that is a maintenance nightmare
because a dependency tree is a tree, not a list.
We would need to include a tree per artifact, making one big unreadable
readme file :)
I do agree, that the documentation on how to use quartz with drools (do
we have any?)
should state you require to add a quartz dependency too to be able to
use that functionality.
Op 07-03-12 10:41, Wolfgang Laun schreef:
> Is there a standard procedure for Drools releases, regulating whether
> they contain 3rd party jars that are essential for core (!) functions
> of Drools?
> For example: After downloading and installing 5.3.0, I tried to use a
> rule calendar, but there's no "quartz" to be found in all the *.jar
> files in /drools-distribution-5.3.0.Final/binaries.
> Downloading quartz is no problem, but it would be NICE if there were a
> hint in the ReadMeDrools.txt. (And what else is required but not
> rules-dev mailing list
With kind regards,
Geoffrey De Smet
rules-dev mailing list