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 2023/08/31 18:25:23 UTC
Proposed changes for Jena5
Here is the status of </chair> my work on Jena5.
These are changes done on a branch in my development repo. I'm going to
raise issues for each of the these changes and give them all the right
GH-nnnn commit message, then propose a Jena repo branch.
There's a note about the RDF/XML parser below.
==== Completed
== Set version to 5.0.0-SNAPSHOT
== Build set to Java17
Upgrade graalvm dependency (test) GraaVM now requires Java17.
== Rename javax.servlet -> jakarta.servlet
Update to jetty11
== Node clear-up
- general review and simplification
- Remove BlankNodeId as indexing label from Node_Blank
- LiteralLabel
Convert LiteralLabel to a class
Remove use from APIs
(mostly) - RDFDatatype still reference it but
I'm not clear why it doesn't use Node_Literal.
Rework LiteralLabel as term-centric as well as value-centric [1]
== Remove old and partial RDF 1.0 code
(it was used inconsistently)
== Move ModelMaker into ontology area (it is only used in ont)
== Model API and Model impl
- Remove deprecated
- Remove isXML/isWellFormed from APIs (seems to be meaningless)
- Simplify containers iterators (implementation)
- Remove TripleBoundary, StatementBoundary, GraphExtract, ModelExtract
Not used by jena-core.
- Remove Selector (already deprecated and unused)
- Remove deprecated: ResourceF
- RDFReaderF and RDFWriterF
Remove the unnamed language operations which are RDF/XML.
Deprecate the named language forms in Model.
- Remove reification (interface methods were, mostly, deprecated)
== Add Jena BOM module
== Update to SLF4j 2.x
== Remove unused assemblers.
== Remove JSON-LD 1.0 support
==== TO DO:
Update for Jetty12
Switch to term graphs.
==== Desirable
Replace normal usage of the RDF/XML reader with something more
maintainable. [2]
===== Reorgs
Call TDB1 "tdb1"
- Rename artifact jena-tdb as jena-tdb1.
- Move the package tree to org.apache.jenba.tdb1
Leave legacy API at "org.apache.jena.tdb"
"org.apache.jena.tdb.TDBFactory" -> "org.apache.jena.tdb1.TDB1Factory"
Andy
[1] LiteralLabel
The idea of LiteralLabel changes is to keep work off the critical part
of creating and streaming literals and only creating the value if
required. The "value" here is the Model API Java type support and the
current GraphMem indexing value.
Ideally, I'd like to pull LiteralLabel into Node_Literal and not have a
separate class but that may be a step too far.
[2] The jena-core RDF/XML reader (ARP) in oaj.rdfxml.xmlinput and
oaj.rdfxml.xmlinput0 packages are complicated.
PR 1774 changed ARP to use the system IRIx interface, not call jena-iri
directly. And the original ARP is also available. 1774 did some cleanup
but was quite conservative in that.
https://github.com/apache/jena/pull/1774
ARP has lots of features and it is clear it was developed while RDF/XML
was being originally spec'ed. There are features and warnings that
aren't in the spec. It does not integrate with the RIOT parser builder
very well.
I tried to do a clean-up but I've come to the conclusion it is
better/safer to keep ARP as it is after 1774, and write a new RDF/XML
parser (RRX - RIOT RDF/XML parser) with the design goal of being just an
application/rdf+xml parser.
The existing ARP would remain in jena-core. Testing the new parser is
done with "run ARP, runRRX" then test whether the outputs, including
occurrence of warnings, are the same. The W3C test suite has mandated
warnings. ARP goes further. The order of triple output is also the same
(expect reification where the APR output is backwards!)
RRX is actually 2 parsers :-).
One is SAX based, and handles XML entities. The other is StAX based; it
first written as a learning exercise. The StAX API does not support XML
entities. SAX is a stream of parser events and requires the code to have
a coded state machine; StAX uses function call descent to know where in
the grammar it is which is easier to understand.
They should produce identical output, down to triple order and messages.
RRX-SAX would be the one that is normally used from RIOT. RRX-StAX is a
"stay honest".
ARP is 66 java files. Each RRX parser is one file.
RRX should work with any XML parser because they don't make any
assumptions about optional supported XML parsing features. Development
has been with the JDK internal one.
Re: Proposed changes for Jena5
Posted by Andy Seaborne <an...@apache.org>.
On 31/08/2023 19:25, Andy Seaborne wrote:
> RRX is actually 2 parsers :-).
>
> One is SAX based, and handles XML entities. The other is StAX based; it
> first written as a learning exercise. The StAX API does not support XML
> entities.
Correction - the StAX API does support character entities.
It was just that Jena has a default of disabling all DTD and entity
features off for security reasons. External entities must be disabled.
Andy
Re: [Lazy] Jena5 Branch
Posted by Andy Seaborne <an...@apache.org>.
On 22/10/2023 11:50, Bruno Kinoshita wrote:
>>
>> Starting to provide a format, then stopping, is not very helpful.
>> CycloneDX is easier to produce and has more uptake in ASF.
>
>
> I had a look but couldn't find anything conclusive on which format works
> best for the EU Cyber Resilience Act.
CRA is a lot of other issues for open source :-(
> GitHub is exporting SPDX I think:
> https://github.blog/2023-03-28-introducing-self-service-sboms/
>
Useful.
Now we have two to choose between :-)
As indented JOSN they are:
SPDX plugin:
1,516,541 chars
GH generated : gh sbom | jq
626,773 chars
Andy
> You can create one for Jena from
> https://github.com/apache/jena/network/dependencies and that will give you
> an SPDX JSON.
> Combining SPDX with RAT could be useful.
>>
>
> #TIL! I think RAT had/has some older issues (can't recall if in the tool,
> maven plugin, or both) but had a low activity. Maybe with that there will
> be more commits/releases.
>
> Links I have found useful:
>>
>
> Thanks for the links to external and ASF material! Someone shared links in
> the Commons security list too about SBOM discussing VEX files (OSV was also
> mentioned):
>
> - https://www.cisa.gov/sbom
> -
> https://www.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf
> - https://github.com/openvex (
>
> PS SPDX can be RDF!, and in fact the maven plugin uses Jena!
>> Jena 3.10.0 :-(
>>
>
> Maybe we can ping someone that maintains it, or even send a PR to bump it
> to Jena 4, warning that there will be a jena5 soon too.
>
> Cheers,
>
> Bruno
Re: [Lazy] Jena5 Branch
Posted by Bruno Kinoshita <br...@gmail.com>.
>
> Starting to provide a format, then stopping, is not very helpful.
> CycloneDX is easier to produce and has more uoptake in ASF.
I had a look but couldn't find anything conclusive on which format works
best for the EU Cyber Resilience Act. GitHub is exporting SPDX I think:
https://github.blog/2023-03-28-introducing-self-service-sboms/
You can create one for Jena from
https://github.com/apache/jena/network/dependencies and that will give you
an SPDX JSON.
Combining SPDX with RAT could be useful.
>
#TIL! I think RAT had/has some older issues (can't recall if in the tool,
maven plugin, or both) but had a low activity. Maybe with that there will
be more commits/releases.
Links I have found useful:
>
Thanks for the links to external and ASF material! Someone shared links in
the Commons security list too about SBOM discussing VEX files (OSV was also
mentioned):
- https://www.cisa.gov/sbom
-
https://www.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf
- https://github.com/openvex (
PS SPDX can be RDF!, and in fact the maven plugin uses Jena!
> Jena 3.10.0 :-(
>
Maybe we can ping someone that maintains it, or even send a PR to bump it
to Jena 4, warning that there will be a jena5 soon too.
Cheers,
Bruno
On Sun, 22 Oct 2023 at 11:11, Andy Seaborne <an...@apache.org> wrote:
>
>
> On 21/10/2023 22:51, Bruno Kinoshita wrote:
> > Thanks Andy!
> >
> > I had a go at the UI dependencies upgrade, and found some deprecation
> > warnings (from vite I think) and e2e tests that need to be fixed. I'm
> doing
> > those tasks for the jena5 branch.
>
> Great - thank you.
>
> It's time to get 4.10.0 out and switch over.
>
> > Will also try to look at the BOM issues as I may need that for $work
> > (future EU regulations and all).
>
> tl;dr:
>
> Let's publish CycloneDX and hold back on SPDX for now.
> There's a lot going on in ASF and the picture will become clearer.
> UI don't think Jena is special or different in its requirements.
>
> Starting to provide a format, then stopping, is not very helpful.
> CycloneDX is easier to produce and has more uoptake in ASF.
>
> The US gov accepts CycloneDX as well as SPDX and Software Identification
> (SWID) tag.
>
> I'd be surprised if the EU does not align,
>
> ----
>
>
> SPDX is quite detailed. It was originally for license management. I'm
> begining to think it is less useful for simple machine generation and
> expects manual configuration to at least check all it's deductions, and
> probably change them. Having some coverage of license information but
> not full coverage seems like a bad idea for both us and users.
>
> Interestingly, RAT has a class "SpdxBuilder".
> Combining SPDX with RAT could be useful.
>
> In ASF, only Commons is producing SPDX that I can find.
>
> Links I have found useful:
>
>
> https://www.activestate.com/blog/why-the-us-government-is-mandating-software-bill-of-materials-sbom/
>
> IN ASF:
> https://cwiki.apache.org/confluence/display/COMDEV/SBOM
>
> Discussion on
> https://github.com/apache/logging-log4j2/issues/1707
> -- worth tracking
>
> and e.g.
>
> https://github.com/apache/spark/pull/39401
> Dongjoon Hyun has been doing quite a few of the PRs
> for adding CylconeDX to projects so his work is getting
> wide review.
>
> Andy
>
> PS SPDX can be RDF!, and in fact the maven plugin uses Jena!
> Jena 3.10.0 :-(
>
> >
> > Cheers,
> >
> > Bruno
> >
> > On Fri, 20 Oct 2023 at 11:56, Andy Seaborne <an...@apache.org> wrote:
> >
> >>
> >>
> >> On 19/10/2023 22:21, Bruno Kinoshita wrote:
> >>> Great progress Andy!
> >>>
> >>> I saw that you created several issues for Jena5.
> >>
> >> Sorry - because it's a branch, github hasn't closed them when the PR was
> >> merged.
> >>
> >>
> https://github.com/apache/jena/issues?q=is%3Aissue+is%3Aopen+label%3AJena5
> >>
> >> should make things clearer
> >>
> >> There's always a lot of things that would be nice but that then delays
> >> the release.
> >>
> >> I'm going through my notes and I'll raise issues.
> >>
> >> + There is one "must" change: normalization of language tags.
> >>
> >> https://github.com/apache/jena/issues/2039
> >>
> >> because that impacts on-disc data.
> >>
> >> + The SBOM SPDX files don't look very good - too many NOASSERTION.
> >>
> >>
> >>
> https://repository.apache.org/content/groups/snapshots/org/apache/jena/jena-arq/5.0.0-SNAPSHOT/jena-arq-5.0.0-20231018.142515-1.spdx.json
> >>
> >> but maybe that is just how it is. I'm not sure what "good practice" in
> >> ASF is or what "good practice" is generally (e.g. SBOMs for every
> >> artifact is best or are they just clutter?).
> >>
> >> Many projects produce CycloneDX files but not SPDX.
> >>
> >> > Are there any easy ones that you need help with?
> >>
> >> 2048 maybe
> >>
> >> Should we do a general update of dependencies in FusekiUI?
> >>
> >> Andy
> >>
> >>> Cheers
> >>> Bruno
> >>>
> >>> On Wed, 18 Oct 2023 at 17:15, Andy Seaborne <an...@apache.org> wrote:
> >>>
> >>>>
> >>>>
> >>>> On 12/10/2023 10:05, Andy Seaborne wrote:
> >>>>>
> >>>>> On 06/10/2023 11:47, Andy Seaborne wrote:
> >>>>>> There's a large PR for a new branch "jena5"
> >>>>>>
> >>>>>> https://github.com/apache/jena/pull/2029
> >>>>>>
> >>>>>> of what I've managed to do so far.
> >>>>>>
> >>>>>> It's not finished.
> >>>>>>
> >>>>>> Andy
> >>>>>
> >>>>> I'd like to bring the PR in as a branch and setup Jenkins to produce
> >>>>> snapshot artifacts.
> >>>>
> >>>> Branch setup, code merged to branch "jena5"
> >>>>
> >>>> There will be forced pushes due to rebasing to "main".
> >>>>
> >>>> This will end when Jena 4.10.0 is released which makes a nice, clear
> >>>> point at which to create a jena4 and make main jena5 development.
> >>>>
> >>>> There are one or two items that need to go into 4.10.0 ebfore that can
> >>>> be released.
> >>>>
> >>>> Jenkins is deploying 5.0.0-SNAPSHOT to the Apache snapshots
> repository.
> >>>>
> >>>> https://repository.apache.org/content/repositories/snapshots/
> >>>>
> >>>> Andy
> >>>>
> >>>
> >>
> >
>
Re: [Lazy] Jena5 Branch
Posted by Andy Seaborne <an...@apache.org>.
On 21/10/2023 22:51, Bruno Kinoshita wrote:
> Thanks Andy!
>
> I had a go at the UI dependencies upgrade, and found some deprecation
> warnings (from vite I think) and e2e tests that need to be fixed. I'm doing
> those tasks for the jena5 branch.
Great - thank you.
It's time to get 4.10.0 out and switch over.
> Will also try to look at the BOM issues as I may need that for $work
> (future EU regulations and all).
tl;dr:
Let's publish CycloneDX and hold back on SPDX for now.
There's a lot going on in ASF and the picture will become clearer.
UI don't think Jena is special or different in its requirements.
Starting to provide a format, then stopping, is not very helpful.
CycloneDX is easier to produce and has more uoptake in ASF.
The US gov accepts CycloneDX as well as SPDX and Software Identification
(SWID) tag.
I'd be surprised if the EU does not align,
----
SPDX is quite detailed. It was originally for license management. I'm
begining to think it is less useful for simple machine generation and
expects manual configuration to at least check all it's deductions, and
probably change them. Having some coverage of license information but
not full coverage seems like a bad idea for both us and users.
Interestingly, RAT has a class "SpdxBuilder".
Combining SPDX with RAT could be useful.
In ASF, only Commons is producing SPDX that I can find.
Links I have found useful:
https://www.activestate.com/blog/why-the-us-government-is-mandating-software-bill-of-materials-sbom/
IN ASF:
https://cwiki.apache.org/confluence/display/COMDEV/SBOM
Discussion on
https://github.com/apache/logging-log4j2/issues/1707
-- worth tracking
and e.g.
https://github.com/apache/spark/pull/39401
Dongjoon Hyun has been doing quite a few of the PRs
for adding CylconeDX to projects so his work is getting
wide review.
Andy
PS SPDX can be RDF!, and in fact the maven plugin uses Jena!
Jena 3.10.0 :-(
>
> Cheers,
>
> Bruno
>
> On Fri, 20 Oct 2023 at 11:56, Andy Seaborne <an...@apache.org> wrote:
>
>>
>>
>> On 19/10/2023 22:21, Bruno Kinoshita wrote:
>>> Great progress Andy!
>>>
>>> I saw that you created several issues for Jena5.
>>
>> Sorry - because it's a branch, github hasn't closed them when the PR was
>> merged.
>>
>> https://github.com/apache/jena/issues?q=is%3Aissue+is%3Aopen+label%3AJena5
>>
>> should make things clearer
>>
>> There's always a lot of things that would be nice but that then delays
>> the release.
>>
>> I'm going through my notes and I'll raise issues.
>>
>> + There is one "must" change: normalization of language tags.
>>
>> https://github.com/apache/jena/issues/2039
>>
>> because that impacts on-disc data.
>>
>> + The SBOM SPDX files don't look very good - too many NOASSERTION.
>>
>>
>> https://repository.apache.org/content/groups/snapshots/org/apache/jena/jena-arq/5.0.0-SNAPSHOT/jena-arq-5.0.0-20231018.142515-1.spdx.json
>>
>> but maybe that is just how it is. I'm not sure what "good practice" in
>> ASF is or what "good practice" is generally (e.g. SBOMs for every
>> artifact is best or are they just clutter?).
>>
>> Many projects produce CycloneDX files but not SPDX.
>>
>> > Are there any easy ones that you need help with?
>>
>> 2048 maybe
>>
>> Should we do a general update of dependencies in FusekiUI?
>>
>> Andy
>>
>>> Cheers
>>> Bruno
>>>
>>> On Wed, 18 Oct 2023 at 17:15, Andy Seaborne <an...@apache.org> wrote:
>>>
>>>>
>>>>
>>>> On 12/10/2023 10:05, Andy Seaborne wrote:
>>>>>
>>>>> On 06/10/2023 11:47, Andy Seaborne wrote:
>>>>>> There's a large PR for a new branch "jena5"
>>>>>>
>>>>>> https://github.com/apache/jena/pull/2029
>>>>>>
>>>>>> of what I've managed to do so far.
>>>>>>
>>>>>> It's not finished.
>>>>>>
>>>>>> Andy
>>>>>
>>>>> I'd like to bring the PR in as a branch and setup Jenkins to produce
>>>>> snapshot artifacts.
>>>>
>>>> Branch setup, code merged to branch "jena5"
>>>>
>>>> There will be forced pushes due to rebasing to "main".
>>>>
>>>> This will end when Jena 4.10.0 is released which makes a nice, clear
>>>> point at which to create a jena4 and make main jena5 development.
>>>>
>>>> There are one or two items that need to go into 4.10.0 ebfore that can
>>>> be released.
>>>>
>>>> Jenkins is deploying 5.0.0-SNAPSHOT to the Apache snapshots repository.
>>>>
>>>> https://repository.apache.org/content/repositories/snapshots/
>>>>
>>>> Andy
>>>>
>>>
>>
>
Re: [Lazy] Jena5 Branch
Posted by Bruno Kinoshita <br...@gmail.com>.
Thanks Andy!
I had a go at the UI dependencies upgrade, and found some deprecation
warnings (from vite I think) and e2e tests that need to be fixed. I'm doing
those tasks for the jena5 branch.
Will also try to look at the BOM issues as I may need that for $work
(future EU regulations and all).
Cheers,
Bruno
On Fri, 20 Oct 2023 at 11:56, Andy Seaborne <an...@apache.org> wrote:
>
>
> On 19/10/2023 22:21, Bruno Kinoshita wrote:
> > Great progress Andy!
> >
> > I saw that you created several issues for Jena5.
>
> Sorry - because it's a branch, github hasn't closed them when the PR was
> merged.
>
> https://github.com/apache/jena/issues?q=is%3Aissue+is%3Aopen+label%3AJena5
>
> should make things clearer
>
> There's always a lot of things that would be nice but that then delays
> the release.
>
> I'm going through my notes and I'll raise issues.
>
> + There is one "must" change: normalization of language tags.
>
> https://github.com/apache/jena/issues/2039
>
> because that impacts on-disc data.
>
> + The SBOM SPDX files don't look very good - too many NOASSERTION.
>
>
> https://repository.apache.org/content/groups/snapshots/org/apache/jena/jena-arq/5.0.0-SNAPSHOT/jena-arq-5.0.0-20231018.142515-1.spdx.json
>
> but maybe that is just how it is. I'm not sure what "good practice" in
> ASF is or what "good practice" is generally (e.g. SBOMs for every
> artifact is best or are they just clutter?).
>
> Many projects produce CycloneDX files but not SPDX.
>
> > Are there any easy ones that you need help with?
>
> 2048 maybe
>
> Should we do a general update of dependencies in FusekiUI?
>
> Andy
>
> > Cheers
> > Bruno
> >
> > On Wed, 18 Oct 2023 at 17:15, Andy Seaborne <an...@apache.org> wrote:
> >
> >>
> >>
> >> On 12/10/2023 10:05, Andy Seaborne wrote:
> >>>
> >>> On 06/10/2023 11:47, Andy Seaborne wrote:
> >>>> There's a large PR for a new branch "jena5"
> >>>>
> >>>> https://github.com/apache/jena/pull/2029
> >>>>
> >>>> of what I've managed to do so far.
> >>>>
> >>>> It's not finished.
> >>>>
> >>>> Andy
> >>>
> >>> I'd like to bring the PR in as a branch and setup Jenkins to produce
> >>> snapshot artifacts.
> >>
> >> Branch setup, code merged to branch "jena5"
> >>
> >> There will be forced pushes due to rebasing to "main".
> >>
> >> This will end when Jena 4.10.0 is released which makes a nice, clear
> >> point at which to create a jena4 and make main jena5 development.
> >>
> >> There are one or two items that need to go into 4.10.0 ebfore that can
> >> be released.
> >>
> >> Jenkins is deploying 5.0.0-SNAPSHOT to the Apache snapshots repository.
> >>
> >> https://repository.apache.org/content/repositories/snapshots/
> >>
> >> Andy
> >>
> >
>
Re: [Lazy] Jena5 Branch
Posted by Andy Seaborne <an...@apache.org>.
On 19/10/2023 22:21, Bruno Kinoshita wrote:
> Great progress Andy!
>
> I saw that you created several issues for Jena5.
Sorry - because it's a branch, github hasn't closed them when the PR was
merged.
https://github.com/apache/jena/issues?q=is%3Aissue+is%3Aopen+label%3AJena5
should make things clearer
There's always a lot of things that would be nice but that then delays
the release.
I'm going through my notes and I'll raise issues.
+ There is one "must" change: normalization of language tags.
https://github.com/apache/jena/issues/2039
because that impacts on-disc data.
+ The SBOM SPDX files don't look very good - too many NOASSERTION.
https://repository.apache.org/content/groups/snapshots/org/apache/jena/jena-arq/5.0.0-SNAPSHOT/jena-arq-5.0.0-20231018.142515-1.spdx.json
but maybe that is just how it is. I'm not sure what "good practice" in
ASF is or what "good practice" is generally (e.g. SBOMs for every
artifact is best or are they just clutter?).
Many projects produce CycloneDX files but not SPDX.
> Are there any easy ones that you need help with?
2048 maybe
Should we do a general update of dependencies in FusekiUI?
Andy
> Cheers
> Bruno
>
> On Wed, 18 Oct 2023 at 17:15, Andy Seaborne <an...@apache.org> wrote:
>
>>
>>
>> On 12/10/2023 10:05, Andy Seaborne wrote:
>>>
>>> On 06/10/2023 11:47, Andy Seaborne wrote:
>>>> There's a large PR for a new branch "jena5"
>>>>
>>>> https://github.com/apache/jena/pull/2029
>>>>
>>>> of what I've managed to do so far.
>>>>
>>>> It's not finished.
>>>>
>>>> Andy
>>>
>>> I'd like to bring the PR in as a branch and setup Jenkins to produce
>>> snapshot artifacts.
>>
>> Branch setup, code merged to branch "jena5"
>>
>> There will be forced pushes due to rebasing to "main".
>>
>> This will end when Jena 4.10.0 is released which makes a nice, clear
>> point at which to create a jena4 and make main jena5 development.
>>
>> There are one or two items that need to go into 4.10.0 ebfore that can
>> be released.
>>
>> Jenkins is deploying 5.0.0-SNAPSHOT to the Apache snapshots repository.
>>
>> https://repository.apache.org/content/repositories/snapshots/
>>
>> Andy
>>
>
Re: [Lazy] Jena5 Branch
Posted by Bruno Kinoshita <br...@gmail.com>.
Great progress Andy!
I saw that you created several issues for Jena5. Are there any easy ones
that you need help with?
Cheers
Bruno
On Wed, 18 Oct 2023 at 17:15, Andy Seaborne <an...@apache.org> wrote:
>
>
> On 12/10/2023 10:05, Andy Seaborne wrote:
> >
> > On 06/10/2023 11:47, Andy Seaborne wrote:
> >> There's a large PR for a new branch "jena5"
> >>
> >> https://github.com/apache/jena/pull/2029
> >>
> >> of what I've managed to do so far.
> >>
> >> It's not finished.
> >>
> >> Andy
> >
> > I'd like to bring the PR in as a branch and setup Jenkins to produce
> > snapshot artifacts.
>
> Branch setup, code merged to branch "jena5"
>
> There will be forced pushes due to rebasing to "main".
>
> This will end when Jena 4.10.0 is released which makes a nice, clear
> point at which to create a jena4 and make main jena5 development.
>
> There are one or two items that need to go into 4.10.0 ebfore that can
> be released.
>
> Jenkins is deploying 5.0.0-SNAPSHOT to the Apache snapshots repository.
>
> https://repository.apache.org/content/repositories/snapshots/
>
> Andy
>
Re: [Lazy] Jena5 Branch
Posted by Andy Seaborne <an...@apache.org>.
On 12/10/2023 10:05, Andy Seaborne wrote:
>
> On 06/10/2023 11:47, Andy Seaborne wrote:
>> There's a large PR for a new branch "jena5"
>>
>> https://github.com/apache/jena/pull/2029
>>
>> of what I've managed to do so far.
>>
>> It's not finished.
>>
>> Andy
>
> I'd like to bring the PR in as a branch and setup Jenkins to produce
> snapshot artifacts.
Branch setup, code merged to branch "jena5"
There will be forced pushes due to rebasing to "main".
This will end when Jena 4.10.0 is released which makes a nice, clear
point at which to create a jena4 and make main jena5 development.
There are one or two items that need to go into 4.10.0 ebfore that can
be released.
Jenkins is deploying 5.0.0-SNAPSHOT to the Apache snapshots repository.
https://repository.apache.org/content/repositories/snapshots/
Andy
Re: [Lazy] Jena5 Branch
Posted by "Rob @ DNR" <rv...@dotnetrdf.org>.
+1 All sounds like a solid plan to me
Rob
From: Andy Seaborne <an...@apache.org>
Date: Thursday, 12 October 2023 at 21:05
To: dev@jena.apache.org <de...@jena.apache.org>
Subject: Re: [Lazy] Jena5 Branch
On 12/10/2023 10:40, Bruno Kinoshita wrote:
...
> Given that I believe most of the Jena development should now be focused on
> Jena5, wouldn't it make more sense to create a Jena4 branch, merge Jena5
> branch into main, and backport bug fixes to the Jena4 branch as needed?
>
> I think we might even be able to cut releases from that branch.
The maven release plugin should work on a branch.
> That way, I think we could say that the official version under development
> is Jena5, and Jena4 is now in hotfix maintenance, until Jena5 is released
> (plus whatever time we need/can to support it in the future).
Good point about the showing jena5 is the "official version under
development".
Since 4.9.0, there are about 18 closed non-Jena5 issues, and 37 PRs
mostly dependency upgrades.
https://s.apache.org/jena-4.10.0-issues.
I think we should do 4.10.0 as normal (which is "soon"ish), wait a bit
to make sure nothing horrendous turns up, then switch. It creates space
for 5.0.0 in the release cycle.
That becomes the official split point jena4 and jena5. No more rebasing
jena4 onto jena5!
5.0.0 might be a -beta or -M1 or -rc1, though I'm not sure how much take
up they will at our scale. There are changes which will slow switch
over, but other than that it's at the same usability level of 4.x.x.
"main" is protected - no forced pushes - so seeing Jena5 hasn't got some
that it is reasonably stable, has been building SNAPSHOTs and has been used.
Andy
>
> Cheers
>
> Bruno
>
>
>
> On Thu, 12 Oct 2023 at 11:05, Andy Seaborne <an...@apache.org> wrote:
>
>>
>> On 06/10/2023 11:47, Andy Seaborne wrote:
>>> There's a large PR for a new branch "jena5"
>>>
>>> https://github.com/apache/jena/pull/2029
>>>
>>> of what I've managed to do so far.
>>>
>>> It's not finished.
>>>
>>> Andy
>>
>> I'd like to bring the PR in as a branch and setup Jenkins to produce
>> snapshot artifacts.
>>
>> The branch might still liable to force pushes to keep the history
>> comprehensible, such as rebasing it to main, and finally when switching
>> to this branch to be main if we use rebase and merge.
>>
>> I think having a baseline for people to look at and maybe even try out,
>> is better than waiting until the very last minute to become Jena5.
>>
>> Maybe we should use rebase and merge" for PRs from now on?
>>
>> Andy
>>
>
Re: [Lazy] Jena5 Branch
Posted by Andy Seaborne <an...@apache.org>.
On 12/10/2023 10:40, Bruno Kinoshita wrote:
...
> Given that I believe most of the Jena development should now be focused on
> Jena5, wouldn't it make more sense to create a Jena4 branch, merge Jena5
> branch into main, and backport bug fixes to the Jena4 branch as needed?
>
> I think we might even be able to cut releases from that branch.
The maven release plugin should work on a branch.
> That way, I think we could say that the official version under development
> is Jena5, and Jena4 is now in hotfix maintenance, until Jena5 is released
> (plus whatever time we need/can to support it in the future).
Good point about the showing jena5 is the "official version under
development".
Since 4.9.0, there are about 18 closed non-Jena5 issues, and 37 PRs
mostly dependency upgrades.
https://s.apache.org/jena-4.10.0-issues.
I think we should do 4.10.0 as normal (which is "soon"ish), wait a bit
to make sure nothing horrendous turns up, then switch. It creates space
for 5.0.0 in the release cycle.
That becomes the official split point jena4 and jena5. No more rebasing
jena4 onto jena5!
5.0.0 might be a -beta or -M1 or -rc1, though I'm not sure how much take
up they will at our scale. There are changes which will slow switch
over, but other than that it's at the same usability level of 4.x.x.
"main" is protected - no forced pushes - so seeing Jena5 hasn't got some
that it is reasonably stable, has been building SNAPSHOTs and has been used.
Andy
>
> Cheers
>
> Bruno
>
>
>
> On Thu, 12 Oct 2023 at 11:05, Andy Seaborne <an...@apache.org> wrote:
>
>>
>> On 06/10/2023 11:47, Andy Seaborne wrote:
>>> There's a large PR for a new branch "jena5"
>>>
>>> https://github.com/apache/jena/pull/2029
>>>
>>> of what I've managed to do so far.
>>>
>>> It's not finished.
>>>
>>> Andy
>>
>> I'd like to bring the PR in as a branch and setup Jenkins to produce
>> snapshot artifacts.
>>
>> The branch might still liable to force pushes to keep the history
>> comprehensible, such as rebasing it to main, and finally when switching
>> to this branch to be main if we use rebase and merge.
>>
>> I think having a baseline for people to look at and maybe even try out,
>> is better than waiting until the very last minute to become Jena5.
>>
>> Maybe we should use rebase and merge" for PRs from now on?
>>
>> Andy
>>
>
Re: [Lazy] Jena5 Branch
Posted by Bruno Kinoshita <br...@gmail.com>.
(Maybe we can also change the base branch of any existing pull request to
that Jena4 branch, so even in the future after we merge Jena5 into main,
those PR's could be left reviewed for Jena4 if needed?)
On Thu, 12 Oct 2023 at 11:40, Bruno Kinoshita <br...@gmail.com>
wrote:
> Hi Andy,
>
> Maybe we should use rebase and merge" for PRs from now on?
>>
>
> I try to use rebase and merge as it works best for me to keep the git
> commit tree in order, so I'm +1 for that.
>
> I'd like to bring the PR in as a branch and setup Jenkins to produce
>> snapshot artifacts.
>>
>> The branch might still liable to force pushes to keep the history
>> comprehensible, such as rebasing it to main, and finally when switching
>> to this branch to be main if we use rebase and merge.
>>
>
> Given that I believe most of the Jena development should now be focused on
> Jena5, wouldn't it make more sense to create a Jena4 branch, merge Jena5
> branch into main, and backport bug fixes to the Jena4 branch as needed?
>
> I think we might even be able to cut releases from that branch.
>
> That way, I think we could say that the official version under development
> is Jena5, and Jena4 is now in hotfix maintenance, until Jena5 is released
> (plus whatever time we need/can to support it in the future).
>
> Cheers
>
> Bruno
>
>
>
> On Thu, 12 Oct 2023 at 11:05, Andy Seaborne <an...@apache.org> wrote:
>
>>
>> On 06/10/2023 11:47, Andy Seaborne wrote:
>> > There's a large PR for a new branch "jena5"
>> >
>> > https://github.com/apache/jena/pull/2029
>> >
>> > of what I've managed to do so far.
>> >
>> > It's not finished.
>> >
>> > Andy
>>
>> I'd like to bring the PR in as a branch and setup Jenkins to produce
>> snapshot artifacts.
>>
>> The branch might still liable to force pushes to keep the history
>> comprehensible, such as rebasing it to main, and finally when switching
>> to this branch to be main if we use rebase and merge.
>>
>> I think having a baseline for people to look at and maybe even try out,
>> is better than waiting until the very last minute to become Jena5.
>>
>> Maybe we should use rebase and merge" for PRs from now on?
>>
>> Andy
>>
>
Re: [Lazy] Jena5 Branch
Posted by Bruno Kinoshita <br...@gmail.com>.
Hi Andy,
Maybe we should use rebase and merge" for PRs from now on?
>
I try to use rebase and merge as it works best for me to keep the git
commit tree in order, so I'm +1 for that.
I'd like to bring the PR in as a branch and setup Jenkins to produce
> snapshot artifacts.
>
> The branch might still liable to force pushes to keep the history
> comprehensible, such as rebasing it to main, and finally when switching
> to this branch to be main if we use rebase and merge.
>
Given that I believe most of the Jena development should now be focused on
Jena5, wouldn't it make more sense to create a Jena4 branch, merge Jena5
branch into main, and backport bug fixes to the Jena4 branch as needed?
I think we might even be able to cut releases from that branch.
That way, I think we could say that the official version under development
is Jena5, and Jena4 is now in hotfix maintenance, until Jena5 is released
(plus whatever time we need/can to support it in the future).
Cheers
Bruno
On Thu, 12 Oct 2023 at 11:05, Andy Seaborne <an...@apache.org> wrote:
>
> On 06/10/2023 11:47, Andy Seaborne wrote:
> > There's a large PR for a new branch "jena5"
> >
> > https://github.com/apache/jena/pull/2029
> >
> > of what I've managed to do so far.
> >
> > It's not finished.
> >
> > Andy
>
> I'd like to bring the PR in as a branch and setup Jenkins to produce
> snapshot artifacts.
>
> The branch might still liable to force pushes to keep the history
> comprehensible, such as rebasing it to main, and finally when switching
> to this branch to be main if we use rebase and merge.
>
> I think having a baseline for people to look at and maybe even try out,
> is better than waiting until the very last minute to become Jena5.
>
> Maybe we should use rebase and merge" for PRs from now on?
>
> Andy
>
[Lazy] Jena5 Branch
Posted by Andy Seaborne <an...@apache.org>.
On 06/10/2023 11:47, Andy Seaborne wrote:
> There's a large PR for a new branch "jena5"
>
> https://github.com/apache/jena/pull/2029
>
> of what I've managed to do so far.
>
> It's not finished.
>
> Andy
I'd like to bring the PR in as a branch and setup Jenkins to produce
snapshot artifacts.
The branch might still liable to force pushes to keep the history
comprehensible, such as rebasing it to main, and finally when switching
to this branch to be main if we use rebase and merge.
I think having a baseline for people to look at and maybe even try out,
is better than waiting until the very last minute to become Jena5.
Maybe we should use rebase and merge" for PRs from now on?
Andy
Re: Proposed changes for Jena5
Posted by Andy Seaborne <an...@apache.org>.
There's a large PR for a new branch "jena5"
https://github.com/apache/jena/pull/2029
of what I've managed to do so far.
It's not finished.
Andy