Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] [jakartabatch-dev] Jakarta Batch - need to do Service Release 2.1.1 after all for failure to update OSGi bundle headers !
Right, the tck needs to be promoted, but I don't see where the zip file is staged. This has always been an issue with the current process in that we use the future, promoted and signed tck link in the spec PR. Once I know where to get the staged batch tck zip file I can promote it.

As far as I know, the only time we have created a project service release record was if that was the only activity on the project within the past year. The 2.1 project page should refer to the latest api/javadoc and tck artifacts.

A separate question is whether they should list all associated artifacts that have been released under a given spec major/minor version.

On Jun 17, 2022 at 4:42:15 PM, Scott Kurz <skurz@xxxxxxxxxx> wrote:

OK, I’m back to end the week with another take on this and a couple quick questions:

 

  1. It looks like the Batch 2.1 spec page  https://jakarta.ee/specifications/batch/2.1/   has been updated to link to the 2.1.1 TCK update (https://download.eclipse.org/jakartaee/batch/2.1/jakarta.batch.official.tck-2.1.1.zip) (thank you Scott S. for merging) but the content is not there; the links don’t work.     Browsing through an old comment from Kevin Sutter https://github.com/jakartaee/specifications/issues/321#issuecomment-763172738  it looks like someone maybe needs ”to run the Jenkins promote-release job to get the TCKs promoted to the proper location. https://ci.eclipse.org/jakartaee-spec-committee/job/promote-release/”    And maybe this is already running right now for all I know.  If not can I please request that?

 

  1. I think now that I was wrong (again) when I said on June 10 “now we do need to do a Batch 2.1.1 SR after all” (after thinking we didn’t have to do one when just updating the TCK).    Though we did find a bug in the API JAR bundle manifest, it dawned on me that this is not part of the specification (it is sort of an “implementation detail” of the API JAR artifact maintained and released to Maven Central by the Jakarta Batch Spec/API project).   And indeed the SR PR template says:  “….Only the associated API (limited to JavaDoc updates), JavaDoc, and TCK artifacts can have service releases.”   So, unless I am corrected again, I will go ahead and delete the Eclipse service release record https://projects.eclipse.org/projects/ee4j.batch/releases/2.1.1  and we don’t need any further updates on the specifications project.   In particular, it’s fine that https://jakarta.ee/specifications/batch/2.1/  references the 2.1.0 API JAR, which is completely valid and up-to-date from the spec perspective, even though there is a newer v2.1.1 at similar Maven coordinates existence.   Are we OK with that?

 

  1. Thinking ahead, if we did say need to update the Jakarta Batch API Javadoc in a future SR, we would probably call it v2.1.2 so as to avoid collision in Maven Central with the v2.1.1 API JAR.  This is maybe just a bit odd from the Jakarta spec perspective, to go from 2.1.0 to 2.1.2, so worth noting the implication here.

 

Hopefully I got it right this time.   Once this is all settled I’ll go ahead and do PRs to Glassfish, and jakartaee-api, (and jbatch).

Thanks,

Scott Kurz

 

From: Scott Kurz
Sent: Friday, June 10, 2022 2:52 PM
To: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Cc: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Subject: Jakarta Batch - need to do Service Release 2.1.1 after all for failure to update OSGi bundle headers !

 

Just after I sent out my last email (to the jakarta.ee-spec ML), I happened to learn that I failed to update the version-related OSGi bundle headers in the Batch 2.1.0 API JAR (e.g. Bundle-Version).

So.. for a completely separate reason (than the TCK update).. we actually will need to do a 2.1.1 service release after all !

 

I will begin work on that.  

 

Sorry for the confusion.    Hopefully the quick reply here helps clarify.

 

Scott Kurz

_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev

Back to the top