[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
- From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
- Date: Wed, 19 Jan 2022 22:04:05 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lHz8tEwVHpCsZlL2erw8Rsyz700bEi+bJHSlyM2Xn7g=; b=Ktstkztu6w8XUv2bvfKZR8vGf7yel5JBaVSAkD53TrxumbWDqFmKNvLONd4FkvFwqDB6Vrs11OfzVcfk87IiCatRSJCaAvfG/ZFEv42+k3DzFckUsRn8lP/91MWybzrNI0K9txAB9lDhqHNHErx4ERmArxBGExEB2ZmmFQnOFITLyEb78RPcL61vDrKIrOL4TlJ7Bc26QerLyEvk6a5hEdu7ZbGXrZtFsebMbRC1nBRleTOduyJ4SP08ei2/71IEeC7ts/3EYzAWs/J0vnSq1pMiEMsbDDUEnQeDj9XGKxJLnA25S5+txWdlOHphBxFqwpUz+0Xbcjkt3M9710SdEw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gcDbwgRkbey6aL/nfOu7UGOlu6Q5al1nibjAtm5uljDd1WSwcO0sGR2Ucaswxrv5oO3306iV7H+f4l+eK5UPdl2/kGbKItbSeBgZmekd1OJfqRbl0RkzD/wNvsiT2jEXBrHY8o59bhbOCcYkWUe6n8OxqxDCbjCH2VYpag5HAzwIzDVEbPIg5fdK2b02wtK2gbOinOjIv2LfaIY2zLXKeTeMluC8oZNkHsBxvxJUfHzPhnkVZ7rjGjVF2DM5H+7CricFYOKcBmRklV8tcnCRqEBAjtFrKDRe6TVKuUyA0hs8ojU4hqwCSYc+yfZ33griIARYNvNlzdVOU2odk/h2zQ==
- Delivered-to: cu-dev@xxxxxxxxxxx
- List-archive: <https://www.eclipse.org/mailman/private/cu-dev/>
- List-help: <mailto:cu-dev-request@eclipse.org?subject=help>
- List-subscribe: <https://www.eclipse.org/mailman/listinfo/cu-dev>, <mailto:cu-dev-request@eclipse.org?subject=subscribe>
- List-unsubscribe: <https://www.eclipse.org/mailman/options/cu-dev>, <mailto:cu-dev-request@eclipse.org?subject=unsubscribe>
- Thread-index: AdgNdCNSkFQ/I2XeS2e9aZi/K8TJGAAAu/EAAAHFlwAAAIMiNg==
- Thread-topic: [cu-dev] Release job
I don't think the Jenkins jobs these propertu
changes t
From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Sent: Wednesday, January 19, 2022 9:47:32 PM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: Re: [cu-dev] Release job
Actually I think it might be a problem with the Jenkins build.
I can get it to generate the right version (3.0.0) locally if I change,
<non.final>true</non.final>
<last.spec_version>1.1</last.spec_version>
<next.spec_version>2.0</next.spec_version>
<spec.version>${next.spec_version}</spec.version>
<new.spec.version>3.0</new.spec.version>
to:
<non.final>false</non.final>
<last.spec_version>2.0</last.spec_version>
<next.spec_version>3.0</next.spec_version>
<spec.version>${next.spec_version}</spec.version>
<new.spec.version>3.1</new.spec.version>
The above works an generates correct 3.0.0 versions in the MANIFEST.MF.
However, I know that we shouldn't be changing the versions because that's the responsibility of the Jenkins release build. So I tried changing only the first property (non.final) but then it fails locally
when a normal build is attempted. My conclusion is that probably Jenkins is intended to hard code non.final=false on the release build, but isn't.
What do others think - should/can that be changed in the release build?
From: "Nathan Rauh" <nathan.rauh@xxxxxxxxxx>
To: "cu developer discussions" <cu-dev@xxxxxxxxxxx>
Date: 01/19/2022 02:57 PM
Subject: [EXTERNAL] Re: [cu-dev] Release job
Sent by: "cu-dev" <cu-dev-bounces@xxxxxxxxxxx>
Steve - Awesome! Thanks for all of your hard work getting these Jenkins builds working. I looked over the console output and it's clearly building the TCK jar as well as the API, so hopefully that all ends up going to
staging when we don't select
Steve - Awesome! Thanks for all of your hard work getting these Jenkins builds working.
I looked over the console output and it's clearly building the TCK jar as well as the API, so hopefully that all ends up going to staging when we don't select the dry run option.
One potential minor issue that I did spot probably has nothing to do with Jenkins and is that I see versions of
2.0.99.bnulland
2.0.99.nullbeing reported in the log here,
[INFO] -- spec properties --
[INFO] spec.bundle.symbolic-name = jakarta.enterprise.concurrent-api
[INFO] spec.implementation.version = 3.0.0
[INFO] spec.extension.name = jakarta.enterprise.concurrent
[INFO] spec.bundle.spec.version = 2.0.99.bnull
[INFO] spec.specification.version = 2.0.99.null
[INFO] spec.bundle.version = 2.0.99.bnull
>From past experience with locally built snapshots, I've seen those versions show up in the MANIFEST.MF, for example as,
Bundle-Version: 2.0.99.bnull
Export-Package: jakarta.enterprise.concurrent;version="2.0.99.bnull";u
ses:="jakarta.enterprise.util,jakarta.interceptor",jakarta.enterprise
.concurrent.spi;version="2.0.99.bnull"
...
Specification-Version: 2.0.99.null
While Open Liberty can easily get around this by replacing the manifest with one its own, it would be best to get it right for everyone in the artifact that will end up on Maven.
I'll do some experimenting locally to see if I can correct it within the pom somewhere.
From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To: "cu developer discussions" <cu-dev@xxxxxxxxxxx>
Date: 01/19/2022 02:36 PM
Subject: [EXTERNAL] [cu-dev] Release job
Sent by: "cu-dev" <cu-dev-bounces@xxxxxxxxxxx>
I think I have got the release job into a stage where it may work. I’ve only run a dry run but it is building the tck jar. Jakarta Concurrency - Concurrency API release #61 [Jenkins] (eclipse.org) Steve
I think I have got the release job into a stage where it may work. I’ve only run a dry run but it is building the tck jar.
Jakarta Concurrency - Concurrency API release #61 [Jenkins]
(eclipse.org)
Steve
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev