Hi
My point is that we should have tests for both EclipseLink and JDBC
(parameterized).
I think it's acceptable to have "longer tests", just to be sure
EclipseLink still works fine (waiting to remove it).
Regards
JB
On Tue, May 6, 2025 at 12:17 AM Dmitri Bourlatchkov wrote:
>
> Good point about
Hi Adnan
I think the documentation on the source distribution/release branch is
fine with the release (it's valid and works imho).
Improvement on the documentation can be included in the next release.
Regards
JB
On Mon, May 5, 2025 at 11:39 PM Adnan Hemani
wrote:
>
> This makes sense to me - bu
Hi
We can see two aspects here:
- the merge of the applications
- gather applications in one package/distribution (tar.gz/zip)
I'm in favor of the later because:
- admin and server distributions share 80% of the same artifacts
- users have to download to "big" packages
We should keep the Quarkus
+1 (non-binding)
1. Verified signature and checksum.
2. Local build and test passed.
- Ajantha
On Tue, May 6, 2025 at 5:11 AM Eric Maynard
wrote:
> +1 (non-binding)
>
> Let’s cherry pick doc & other changes back into 0.10.x as needed rather
> than block the release.
>
> On Mon, May 5, 2025 at
I guess this discussion is becoming bigger than just the merging of admin
and server modules.
I'd like to propose staying on the original narrow topic, so please share
concrete ideas about handling CLI and REST applications in the same module
under Quarkus. It may be possible, I never tried it per
So long as EclipseLink is not completely yanked from the repo I would
prefer to keep the tests running, even if it means the tests take longer to
run. The risk of a regression seems too great.
On Mon, May 5, 2025 at 3:18 PM Dmitri Bourlatchkov wrote:
> Good point about tests!
>
> However, I beli
*> Users already get two artfacts: one for the server, another for the
admin tool. Each one has a specific and distinct purpose. I personally do
not see a usability problem here.*
I definitely see a usability problem here. Consider that every command in
the CLI may have a distinct purpose but we sh
These applications are built by Quarkus using different plugins (CLI vs.
REST API).
The output of a module is normally one jar, hence only one main class.
If we were to add custom code to run both CLI and REST API from the same
jar, we'd be losing most of the benefits of Quarkus plugins that were
I don’t really understand the question. Are you asking how a single gradle
module can contain a CLI and a service? The naive way is just to have two
different main classes but perhaps you mean something else?
In Dropwizard this was seemingly the standard way of doing things, as you
could register
Hi Yufei,
Please note that the admin tool is a CLI application, while the quarkus
"server" is a REST application.
How do you envision supporting both CLI and REST API in the same module?
Thanks,
Dmitri.
On Mon, May 5, 2025 at 2:49 PM Yufei Gu wrote:
> Hi folks,
>
>
>
> I’d like to propose mer
Hi Dmitri,
I need the SKIP_CREDENTIAL_SUBSCOPING_INDIRECTION option for my self-managed
Polaris deployment. Unfortunately, due to company policy, I cannot use
credential vending and must rely on environment variables to provide
credentials. While I would prefer to use credential vending if it w
+1 (non-binding)
Let’s cherry pick doc & other changes back into 0.10.x as needed rather
than block the release.
On Mon, May 5, 2025 at 2:40 PM Adnan Hemani
wrote:
> This makes sense to me - but the 0.10 release tag would not line up with
> the shell scripts included in that release if we only
Good point about tests!
However, I believe it still makes sense to transfer the main body of tests
using a "real database" to JDBC. It should be possible to run one
Integration test on EclipseLink to make sure it works and still not
overload CI.
Cheers,
Dmitri.
On Mon, May 5, 2025 at 1:26 PM Je
SKIP_CREDENTIAL_SUBSCOPING_INDIRECTION
I do not think that this option is a solution for self-managed deployments
at all.
It effectively disables credential vending, which is still a valuable
feature for self-managed cases.
So basically we'd have 2 modes of running Polaris [...]
I'd really li
This makes sense to me - but the 0.10 release tag would not line up with the
shell scripts included in that release if we only changed the docs. But if we
are following up quickly with 1.0 after this release, then that’s also fair.
This is not absolutely critical if we are only waiting another f
I think it's also perfectly fine to change docs after the release. We would
do so if we had better
descriptions or bug fixes, so I don't see why we couldn't do that for
better how-to guides
as long as the information applied to 0.10.
On Mon, May 5, 2025 at 4:31 PM Dmitri Bourlatchkov wrote:
> Hi
Hi Adnan,
I believe the plan is to follow with 1.0 immediately after 0.10.0 is
released (as discussed in the community call last week). We should
certainly include doc changes there... but I do not think they are critical
for another 0.10.0 RC. In fact, making another RC will delay 1.0 under the
c
+1 (binding)
Verified:
* Checksums (binaries and helm)
* Signatures (binaries and helm)
* helm install from tar (
https://dist.apache.org/repos/dist/dev/incubator/polaris/helm-chart/0.10.0-beta-incubating.tar.gz
)
- it works, so I guess the index.yaml issue (below) is minor
- image pull fails
(Non-Binding) -1: I think 0.10.0 release would be very positively impacted by
having the remaining pieces of the Getting Started with Cloud Providers (Using
Blob Storage) - this PR: https://github.com/apache/polaris/pull/1435. I
understand this was committed past the cut-off, but having it part
The helm chart's index appears to be mostly empty... Is that correct?
https://dist.apache.org/repos/dist/dev/incubator/polaris/helm-chart/index.yaml
apiVersion: v1
entries: {}
generated: "2025-05-02T22:14:21.384267+02:00"
Thanks,
Dmitri.
On Sat, May 3, 2025 at 12:39 AM Jean-Baptiste Onofré
wr
Hi folks,
I’d like to propose merging the polaris-quarkus-admin and
polaris-quarkus-server modules. While modularization can bring benefits
like clearer separation of concerns, in this case, the split seems to cause
more friction than value. Here’s why I think merging makes sense:
1. Improve
In general this sigv4 indirection control-flow should mirror the analogous
patterns we apply on the StorageConfigInfo side (and perhaps long-term we
can better consolidate the STS logic for the two), so I'd agree it's not
even necessarily federation-specific.
There's some precedent for the use-cas
+1 (binding)
1. ➜ apache-polaris-0.10.0-beta-incubating shasum -a 512 --check *.sha512
apache-polaris-0.10.0-beta-incubating.tar.gz: OK
polaris-quarkus-admin-0.10.0-beta-incubating.tgz: OK
polaris-quarkus-admin-0.10.0-beta-incubating.zip: OK
polaris-quarkus-server-0.10.0-beta-incubating.tgz: OK
p
Hi
I already commented on the PR and forgot to reply here :)
Yes agree to deprecate eclipselink it makes sense to me and promote
"JDBC" instead.
That said, as said in the PR, I think we should keep the eclipselink
test still (even if deprecated): deprecation gives time for users to
"move to" JDB
+1
1. Verified asc, sha512.
2. Build and test passed.
3. Verified both binary distributions, admin and server. Both worked.
Would suggest putting both binaries in a package. They are easier to use in
that case.
Yufei
On Fri, May 2, 2025 at 9:39 PM Jean-Baptiste Onofré wrote:
> Hi everyone,
>
Congrats, folks!
> On May 5, 2025, at 9:23 AM, Russell Spitzer wrote:
>
> Hurrah!
>
> On Mon, May 5, 2025 at 11:11 AM Neelesh Salian
> wrote:
>
>> Congratulations to all of you!
>>
>> Regards,
>> Neelesh S. Salian
>>
>>
>>
>> On Mon, May 5, 2025 at 09:08 Yufei Gu wrote:
>>
>>> Congrats
Hurrah!
On Mon, May 5, 2025 at 11:11 AM Neelesh Salian
wrote:
> Congratulations to all of you!
>
> Regards,
> Neelesh S. Salian
>
>
>
> On Mon, May 5, 2025 at 09:08 Yufei Gu wrote:
>
> > Congrats everyone!
> >
> > Yufei
> >
> >
> > On Mon, May 5, 2025 at 6:14 AM Dmitri Bourlatchkov
> > wrote:
Congratulations to all of you!
Regards,
Neelesh S. Salian
On Mon, May 5, 2025 at 09:08 Yufei Gu wrote:
> Congrats everyone!
>
> Yufei
>
>
> On Mon, May 5, 2025 at 6:14 AM Dmitri Bourlatchkov
> wrote:
>
> > Congrats and welcome everybody!
> >
> > Cheers,
> > Dmitri.
> >
> > On Sun, May 4, 202
Congrats everyone!
Yufei
On Mon, May 5, 2025 at 6:14 AM Dmitri Bourlatchkov wrote:
> Congrats and welcome everybody!
>
> Cheers,
> Dmitri.
>
> On Sun, May 4, 2025 at 1:53 AM Jean-Baptiste Onofré
> wrote:
>
> > Hi everyone,
> >
> > We are very happy to announce new committers to the Apache Pol
Congrats and welcome everybody!
Cheers,
Dmitri.
On Sun, May 4, 2025 at 1:53 AM Jean-Baptiste Onofré wrote:
> Hi everyone,
>
> We are very happy to announce new committers to the Apache Polaris podling
> !
>
> Please welcome:
> * Ajantha Bhat
> * Jonas Jiang
> * Pierre Laporte
> * Prashant Sing
Congrats everyone! Welcome aboard!
Le lun. 5 mai 2025 à 04:16, Omar Al-Safi a écrit :
> Welcome and congratulations!
>
> On Sun, May 4, 2025 at 7:54 AM Jean-Baptiste Onofré
> wrote:
>
> > Hi everyone,
> >
> > We are very happy to announce new committers to the Apache Polaris
> podling
> > !
> >
Welcome and congratulations!
On Sun, May 4, 2025 at 7:54 AM Jean-Baptiste Onofré wrote:
> Hi everyone,
>
> We are very happy to announce new committers to the Apache Polaris podling
> !
>
> Please welcome:
> * Ajantha Bhat
> * Jonas Jiang
> * Pierre Laporte
> * Prashant Singh
>
> Thanks a lot f
32 matches
Mail list logo
