You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2014/07/21 18:08:16 UTC
Jena 2.12.0 release?
Is it time for the Jena 2.12.0 (first release requiring at least Java7)?
It seems to be stable after the Java7 updates at the end of June and I
the Windows issue (with TDB LocationLocks) got fixed today (not that the
code it's testing is active yet?).
What needs to be done? [*]
(What's the status of the schemagen plugin?)
Andy
[*] For me, ideally, JENA-749 as it's not a pure maintenance release but
if this in anyway needs discussion/consideration, then I would not want
it to block the release.
Rob - as far as I can see, hadoop-rdf seems to only use triples/quads
aspects (e.g. TrackedPipedTriplesStream, TrackedPipedQuadsStream for
input, and RDF formats for output).
Re: Jena 2.12.0 release?
Posted by Andy Seaborne <an...@apache.org>.
Build./release in progress ...
During the build part, I got:
*jena-core*
java8 - spurious warnings from javadoc production - it seems confused by
some names.
(I used java7 for the real build by setting JAVA_HOME)
There are about 100 warnings from OntProperty and OntResource --
[WARNING] /home/afs/Jena/jena-core/src/main/java/com/hp/hpl/jena/ontology/OntProperty.java:483: warning - @propertyDescription is an unknown tag.
which is the line:
public boolean isFunctionalProperty();
which also causes:
[WARNING] /home/afs/Jena/jena-core/src/main/java/com/hp/hpl/jena/ontology/OntProperty.java:483: warning - Tags @propertyGetter, @propertySetter and @propertyDescription can only be used in JavaFX properties getters and setters
and apparently "*Property" is the idiom for a setter in JavaFX. Not that
we are using the tags; it's triggered from the name.
Bother.
*jena-tdb*
3 warnings about there being no lock.
Ignored.
*jena-security*
[INFO] Transforming 'Apache Jena - Security'...
[INFO] Ignoring artifact version update for expression ${project.version}
[INFO] Ignoring artifact version update for expression ${project.version}
and
[INFO] Running org.apache.jena.security.contract.graph.SecuredGraphListenerTest
[INFO] 10:35:42 WARN riot :: [line: 7, col: 43] {W106} Unknown rdf:parseType: 'daml:collection' (treated as 'Literal'.
[INFO] 10:35:42 WARN riot :: [line: 7, col: 43] {W106} Unknown rdf:parseType: 'daml:collection' (treated as 'Literal'.
[INFO] 10:35:42 WARN riot :: [line: 7, col: 43] {W106} Unknown rdf:parseType: 'daml:collection' (treated as 'Literal'.
[INFO] 10:35:42 WARN riot :: [line: 7, col: 43] {W106} Unknown rdf:parseType: 'daml:collection' (treated as 'Literal'.
[INFO] Tests run: 54, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.268 sec - in org.apache.jena.security.contract.graph.SecuredGraphListenerTest
which look like they should be removed (daml:collection has been removed
completely from jena-core)
Re: Jena 2.12.0 release?
Posted by Rob Vesse <rv...@dotnetrdf.org>.
Andy
Yes these should be safely ignorable
The warning means that when the StoreConnection.expel() happened it
detected that it was eligible to lock the location and for whatever reason
didn't. As for how this happens I am not sure, there are a number of
possible race conditions that could occur though in a single process
environment most of these are unlikely.
In the debugger these all look to be originating from test cases which are
calling StoreConnection.release() or StoreConnection.reset() but I don't
see why - TS_Store, TS_TransactionTDB and TS_Factory are the culprits from
what I see. However running the individual test class that the debugger
stops on when I set a breakpoint on the warning does not reliably
reproduce the problem.
Rob
On 25/07/2014 21:21, "Andy Seaborne" <an...@apache.org> wrote:
>Rob,
>
>I'm getting warnings from the build in jena-tdb:
>
>
>21:11:21 WARN TDB :: Location
>/home/afs/Jena/jena-tdb/target/tdb-testing/DB/ was not locked, if
>another JVM accessed this location simultaneously data corruption may
>have occurred
>21:12:18 WARN TDB :: Location
>/home/afs/Jena/jena-tdb/target/tdb-testing/DB/ was not locked, if
>another JVM accessed this location simultaneously data corruption may
>have occurred
>21:13:55 WARN TDB :: Location
>/home/afs/Jena/jena-tdb/target/tdb-testing/DB/ was not locked, if
>another JVM accessed this location simultaneously data corruption may
>have occurred
>
>Are they ignorable (for now) warnings?
>
> Andy
Re: Jena 2.12.0 release?
Posted by Andy Seaborne <an...@apache.org>.
Rob,
I'm getting warnings from the build in jena-tdb:
21:11:21 WARN TDB :: Location
/home/afs/Jena/jena-tdb/target/tdb-testing/DB/ was not locked, if
another JVM accessed this location simultaneously data corruption may
have occurred
21:12:18 WARN TDB :: Location
/home/afs/Jena/jena-tdb/target/tdb-testing/DB/ was not locked, if
another JVM accessed this location simultaneously data corruption may
have occurred
21:13:55 WARN TDB :: Location
/home/afs/Jena/jena-tdb/target/tdb-testing/DB/ was not locked, if
another JVM accessed this location simultaneously data corruption may
have occurred
Are they ignorable (for now) warnings?
Andy
Re: Jena 2.12.0 release?
Posted by Andy Seaborne <an...@apache.org>.
OK - so no block on a 2.12.0 release. Cool.
(2) is definitely a "big thing" as it'll break existing app code.
Off the top of my head, sorting out the models-across-transaction
boundaries is going to be related.
It might be better to do together with all datasets being transactional.
There are two general schemes that can be used for places where
transactionality needs to be externally applied (e.g. in-memory): either
RDF patches, which are reversible for abort(), or a MRSW locking. Fuseki
uses the latter currently unless it's a TDB dataset.
Andy
On 24/07/14 14:13, Rob Vesse wrote:
> The LocationLock functionality is now enabled and working. I have also
> updated the staging documentation to reference this new functionality.
>
> I haven't closed JENA-648 as the description talks about two things:
>
> 1 - LocationLock
> 2 - Transactions on by default + upgradeable transactions
>
> Probably what needs to be done is a new JIRA filed for 2 which references
> back to the current JIRA and then JENA-648 can be resolved and closed
>
> The only other thing I wanted to do is send a message to the developer
> list to ask for people to test snapshots
>
> Rob
>
> On 24/07/2014 13:32, "Andy Seaborne" <an...@apache.org> wrote:
>
>> On 22/07/14 10:19, Rob Vesse wrote:
>>> +1
>>>
>>> Yes I think we are probably about ready
>>>
>>> I would like to get JENA-648 (TDB LocationLock's) enabled, thanks for
>>> spotting and fixing the cause of the Windows failures. I will enable
>>> that
>>> shortly and make sure everything builds nicely now
>>
>> Is that OK now? It looks like from JIRA but is it open still so I was
>> wondering if there is still work to do. Anything I can help with?
>>
>> Andy
>>
>
>
>
>
Re: Jena 2.12.0 release?
Posted by Rob Vesse <rv...@dotnetrdf.org>.
The LocationLock functionality is now enabled and working. I have also
updated the staging documentation to reference this new functionality.
I haven't closed JENA-648 as the description talks about two things:
1 - LocationLock
2 - Transactions on by default + upgradeable transactions
Probably what needs to be done is a new JIRA filed for 2 which references
back to the current JIRA and then JENA-648 can be resolved and closed
The only other thing I wanted to do is send a message to the developer
list to ask for people to test snapshots
Rob
On 24/07/2014 13:32, "Andy Seaborne" <an...@apache.org> wrote:
>On 22/07/14 10:19, Rob Vesse wrote:
>> +1
>>
>> Yes I think we are probably about ready
>>
>> I would like to get JENA-648 (TDB LocationLock's) enabled, thanks for
>> spotting and fixing the cause of the Windows failures. I will enable
>>that
>> shortly and make sure everything builds nicely now
>
>Is that OK now? It looks like from JIRA but is it open still so I was
>wondering if there is still work to do. Anything I can help with?
>
> Andy
>
Re: Jena 2.12.0 release?
Posted by Andy Seaborne <an...@apache.org>.
On 22/07/14 10:19, Rob Vesse wrote:
> +1
>
> Yes I think we are probably about ready
>
> I would like to get JENA-648 (TDB LocationLock's) enabled, thanks for
> spotting and fixing the cause of the Windows failures. I will enable that
> shortly and make sure everything builds nicely now
Is that OK now? It looks like from JIRA but is it open still so I was
wondering if there is still work to do. Anything I can help with?
Andy
Re: Jena 2.12.0 release?
Posted by Rob Vesse <rv...@dotnetrdf.org>.
+1
Yes I think we are probably about ready
I would like to get JENA-648 (TDB LocationLock's) enabled, thanks for
spotting and fixing the cause of the Windows failures. I will enable that
shortly and make sure everything builds nicely now
The Hadoop RDF stuff has some basic infrastructure for arbitrary tuples
but it isn't really fully implemented, certainly the current input stuff
only needs triple and quad support
Rob
On 21/07/2014 17:08, "Andy Seaborne" <an...@apache.org> wrote:
>Is it time for the Jena 2.12.0 (first release requiring at least Java7)?
>
>It seems to be stable after the Java7 updates at the end of June and I
>the Windows issue (with TDB LocationLocks) got fixed today (not that the
>code it's testing is active yet?).
>
>What needs to be done? [*]
>
>(What's the status of the schemagen plugin?)
>
> Andy
>
>[*] For me, ideally, JENA-749 as it's not a pure maintenance release but
>if this in anyway needs discussion/consideration, then I would not want
>it to block the release.
>
>Rob - as far as I can see, hadoop-rdf seems to only use triples/quads
>aspects (e.g. TrackedPipedTriplesStream, TrackedPipedQuadsStream for
>input, and RDF formats for output).