building the sources & developer studio errors

[crettig]

Hello everyone,

I have been building jberet from the sources and noticed some things I wanted to point out here

jberet-jpa-repository

The ORM file jberet-jpa-repository\src\main\resources\META-INF\orm.xml links to a lot of final classes and attributes

e.g. The Java class for mapped type "JOB_EXECUTION" is final orm.xml /jberet-jpa-repository/src/main/resources/META-INF line 41 JPA Problem

and The Java field for attribute "jobExecutions" is final orm.xml /jberet-jpa-repository/src/main/resources/META-INF line 23 JPA Problem

I think JPA entities and attributes must not be final. Is there some special reason for declaring them final?

inifinispanRepositoryJdbc

I think in the file test-apps/infinispanRepositoryJdbc/src/main/resources/jdbc-infinispan.xml your are missing some schemaLocation; from what I see it should be

<infinispan xmlns="urn:infinispan:config:7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

            xsi:schemaLocation="urn:infinispan:config:7.0 http://infinispan.org/schemas/infinispan-config-7.0.xsd

            urn:infinispan:config:store:jdbc:7.0 http://infinispan.org/schemas/infinispan-cachestore-jdbc-config-7.0.xsd">

scheduleTimer

In the sample wildfly-jberet-samples\scheduleTimer\src\main\resources\META-INF\batch-jobs\timer-scheduler-job1.xml a script is used as a batchlet.

Wouldn't it make sense to provide a JBeret specific version of jobXML_1_0.xsd (http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html)

in project https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/resources/jobXML_1_0.xsd and link it correctly?

I don't want to annoy anyone with such simple things but correcting these thigs would give amuch cleaner developer studio workspace.

regards, chris

[cfang]

Thanks for reporting these problems.

For jberet-jpa-repository issue, these classes are developed first as jberet-core classes, and then later we once had plan to reuse them as JPA entities in jberet-jpa-repository module.  The work on jberet-jpa-repository has been put on hold for a while, and recently in master branch it has been moved to its own separate repo.

Using scripts in job xml is an experimental feature in JBeret, with some extensions to the standard job xml schema.  We will need to look at the future eveolution of bach spec and the standard job xml to determine if we want to have a jberet-specific schema.

We should fix the schema declaration issue.

[crettig]

Hello,

For jberet-jpa-repository issue, these classes are developed first as jberet-core classes, and then later we once had plan to reuse them as JPA entities in jberet-jpa-repository module.  The work on jberet-jpa-repository has been put on hold for a while, and recently in master branch it has been moved to its own separate repo.

Ok, this explainy why the REST api uses only the javax.batch.operations.JobOperator interface and does not rely on any JPA service. Does anyone really use the jberet-jpa-repository?

The reason why I am asking this question is that I want to extend the database schema with some error and monitoring related tables and the existing JPA entities would be a subset of my new entity set classes. If nobody uses the current entity classes

then I could go with a complete entity class set on my own.

Using scripts in job xml is an experimental feature in JBeret, with some extensions to the standard job xml schema.  We will need to look at the future eveolution of bach spec and the standard job xml to determine if we want to have a jberet-specific schema.

Is there is an xml schema for the extensions so that I could have a look at it?

regards, chris

[cfang]

jberet-jpa-repository in its current form is incomplete so I don't think anyone is using it.  No, we don't have the extension job xml schema.