I based this on the official Ignite 3.1.0 documentation and the Ignite 2→3 migration material. One limitation: migration_info.md is not attached to this conversation, so I could not inspect its contents; I’ve explicitly instructed the migration model to treat it as mandatory supplementary context.

Here is the paste-ready steering guide I would give the weaker model:

:::writing{variant="document" id="58321" title="Apache Ignite 2.17 → 3.1 Migration Steering Guide"}

Apache Ignite 2.17 → Ignite 3.1 migration guidance

First principle: this is a port, not a library upgrade

Do not approach Apache Ignite 2.17 → Ignite 3.1 as “change the Maven version, fix imports until it compiles.”

Ignite 3 substantially redesigns configuration, storage, caches/data access, cluster lifecycle, client topology, SQL, transactions, and distributed execution. Apache explicitly states that Ignite 2 application code cannot be directly reused. (Apache Ignite)

Your job is therefore to identify every Ignite 2 concept used by the application, determine its Ignite 3 equivalent, and migrate the application's architecture deliberately.

Mandatory repository-specific input: find and read migration_info.md before making changes. It contains “loose but important” details that may not naturally appear in the main migration checklist. Treat those details as requirements and reconcile them with the Ignite 3.1 APIs and architecture. Do not ignore the file just because some information appears informal or disconnected from the primary migration steps.

The conceptual mapping to keep in mind

Do not mechanically translate names: understand the semantic differences.

1. Inventory the existing application before changing it

Search the entire project—including production code, tests, configuration, Docker/Kubernetes manifests and build files—for Ignite usage.

At minimum, locate occurrences of org.apache.ignite, Ignition, IgniteCache, CacheConfiguration, QueryEntity, DataStorageConfiguration, DataRegionConfiguration, SqlFieldsQuery, ScanQuery, ContinuousQuery, IgniteTransactions, IgniteCompute, IgniteServices, IgniteMessaging, IgniteDataStreamer, BinaryObject, withKeepBinary, CacheStore, affinity APIs/annotations, expiry policies, eviction policies, discovery/communication SPIs, Spring Ignite beans, JDBC URLs and SSL/security configuration.

Classify each occurrence rather than blindly fixing compilation.

This inventory is especially important for less-common Ignite 2 facilities such as near caches, continuous queries, entry processors, CacheStore/read-through/write-through, services, messaging, peer class loading, binary-object manipulation, distributed data structures and custom affinity. Do not assume that an identically behaving Ignite 3 API exists. Verify each feature individually against Ignite 3.1 and redesign where there is no direct equivalent.

2. Replace the cache-centric data model with tables

The most important code change is:

IgniteCache is no longer the main application data abstraction.

Ignite 3 uses tables. Applications access them principally through RecordView or KeyValueView; either can use tuples or mapped application classes. (Apache Ignite)

For cache-like code:

cache.get(key) should normally become a KeyValueView.get(tx, key).

cache.put(key, value) normally becomes KeyValueView.put(tx, key, value).

For objects naturally representing complete rows, prefer RecordView<T>.

For dynamic/schema-oriented code that previously relied heavily on BinaryObject, consider Tuple views.

Do not reproduce CacheConfiguration objects in new Java code. Design actual Ignite 3 tables: columns, primary keys, indexes, colocation keys, distribution zones and storage profiles.

POJO mapping is schema-backed, so carefully compare field names/types with table columns. Ignite 3's Table API supports the Java Time API rather than legacy java.util.Date, java.sql.Date, java.sql.Time or java.sql.Timestamp; migrate domain mappings accordingly. (Apache Ignite)

3. Explicitly redesign affinity, partitions, backups and replication

Do not blindly copy Ignite 2 CacheMode, backups, affinity configuration or data-region settings.

Ignite 3 models storage as:

storage engine → storage profile → distribution zone → table

Distribution zones control partitions, replica count, eligible nodes and storage profiles. Custom Ignite 2 affinity functions are specifically called out as being replaced by distribution zones. (Apache Ignite)

Data locality moves into the table schema through COLOCATE BY. The colocation fields must belong to the primary key, and related tables should be designed around real query/join patterns. (Apache Ignite)

Because the target is 3.1, use the 3.1 model rather than imitating Ignite 3.0. New 3.1 clusters use zone-based replication, in which tables sharing a zone can share RAFT groups. This can significantly affect how zones should be grouped. (Apache Ignite)

In other words, choosing zones is an architectural decision, not merely syntax needed to make the tables compile.

4. Rebuild configuration rather than translating XML literally

Ignite 2's Spring/XML bean configuration does not map one-to-one to Ignite 3.

Ignite 3 uses HOCON or JSON and divides configuration among node configuration, cluster configuration and distribution zones. (Apache Ignite)

Apache provides a migration configuration converter, but it only converts a defined subset such as cacheConfiguration, clientConnectorConfiguration, communicationSpi, dataStorageConfiguration, discoverySpi and sslContextFactory; unsupported settings are ignored/warned about. Apache recommends rebuilding advanced configurations rather than relying blindly on automatic conversion. (Apache Ignite)

Therefore use the converter as an aid, not as proof that migration is complete.

Pay special attention to discovery/networking, storage paths/profiles, TLS, authentication, client connector configuration, timeouts, node attributes, metrics and cluster-wide settings.

Ignite 3.1 also renamed a number of configuration parameters so that units are explicit—for example ...Millis timeout properties. (Apache Ignite)

5. Decide whether the application should be a client or embedded node

Do not preserve an Ignite 2 thick-client/server architecture without reconsidering it.

All normal Ignite 3 clients are thin clients: they do not enter the cluster topology, do not own partitions and are not compute destinations. (Apache Ignite)

For a normal application process, strongly consider using the ignite-client dependency and IgniteClient.builder().

If the existing program genuinely starts Ignite server nodes inside the application, migrate to Ignite 3 embedded mode instead. Embedded Ignite 3 uses IgniteServer, requires explicit cluster initialization, and—unlike Ignite 2—embedded nodes are not divided into “client nodes” versus “server nodes”; embedded nodes store data by default. (Apache Ignite)

Also inspect JVM startup options if embedded mode is used: Ignite 3's documented embedded setup requires several --add-opens options. (Apache Ignite)

6. Port SQL deliberately

Ignite 3 uses Apache Calcite and should not be assumed to accept every Ignite 2 query/function unchanged. (Apache Ignite)

Run every production SQL query through tests.

There is an official Ignite 2→3 SQL function comparison. Examples include DAY_OF_MONTH → DAYOFMONTH, ISNULL → NVL, INSTR(a,b) → POSITION(b IN a) and RANDOM_UUID → RAND_UUID; several old bit functions have no direct equivalent. (Apache Ignite)

Also audit SQL types, implicit casts, precision/scale, NULL handling, indexes, quoted identifiers, schemas and date/time fields. Ignite 3 limits implicit conversion largely to members of the same type family. (Apache Ignite)

For 3.1 specifically, check legacy CHAR/BINARY definitions; the 3.1 migration guidance moves DDL usage toward VARCHAR and VARBINARY. (Apache Ignite)

Do not merely make SQL parse. Use EXPLAIN/EXPLAIN MAPPING on important queries and verify that colocation and partition pruning are actually working.

7. Re-evaluate all transaction logic

Transaction behavior deserves a semantic review, not just an API rewrite.

Ignite 3 Table and SQL calls are transactional. Without an explicit transaction, a call runs in an implicit transaction. Explicit transactions can be passed to Table/SQL operations. Read-write transactions are serializable; read-only transactions use a timestamped snapshot and avoid the read-write locking path. (Apache Ignite)

This matters if Ignite 2 code depended on ATOMIC versus TRANSACTIONAL caches, specific isolation/concurrency configuration, several cache calls accidentally being independent, or transaction retries.

Review transaction boundaries method by method. Several operations that happened to be atomic independently in Ignite 2 may need an explicit Ignite 3 transaction to preserve business-level atomicity.

Also note that DDL is not supported inside transactions. (Apache Ignite)

Tests must cover conflicting concurrent writes, transaction retries/failures, node loss during transactions and transaction timeouts—not merely happy-path CRUD.

8. Persistent storage cannot simply be reused

Do not point Ignite 3 at an Ignite 2 persistence directory.

Apache states that Ignite 3 persistent storage is not directly compatible with Ignite 2; Ignite 2 caches must be converted into Ignite 3 tables. (Apache Ignite)

Apache provides migration tools that can generate Ignite 3 DDL from Ignite 2 cache configuration and migrate persistent cache data. The persistent-data migration path requires a cleanly stopped Ignite 2 node; Apache specifically recommends allowing a checkpoint to complete before migration. (Apache Ignite)

The migration utility has policies for schema mismatches such as aborting, ignoring columns, skipping records or packing additional fields into an EXTRA JSON column. Do not silently choose a lossy policy. Any mismatch should be understood and documented. (Apache Ignite)

Treat the safest architecture as old 2.17 cluster/work directory → separately provisioned 3.1 cluster → explicit schema/data migration → verification → cutover.

Never assume an Ignite 2→3 rolling binary upgrade.

9. Rewrite compute/deployment integration where used

If the project uses IgniteCompute, closures, affinity-call/run patterns, server-side entry processing or peer class loading, isolate this migration as its own workstream.

Ignite 3 has a new Compute API including node targeting, colocated execution and MapReduce. Server-side user code is handled through Ignite 3 code deployment. (Apache Ignite)

Deployment units are immutable and identified by a unit ID plus version. Updating server-side code means deploying another unit version. (Apache Ignite)

Therefore do not assume an Ignite 2 serialized closure or a JAR merely present on a client will magically execute remotely.

10. Audit streaming and event-driven behavior

If IgniteDataStreamer is used, port it independently. Ignite 3 streaming operates on table views and uses a publisher/subscriber style API with batching, retry and parallelism controls. The documented delivery guarantee is at-least-once, so idempotency matters. (Apache Ignite)

If the application relies on continuous queries, cache entry listeners, Ignite messaging or Ignite services, flag these as migration-risk features. Do not invent an equivalent based on the old class name. Verify exactly what Ignite 3.1 provides and, where necessary, redesign the application around tables, compute, events, or an external messaging/service mechanism.

The same rule applies to Ignite 2 near caches, CacheStore integration and BinaryObject-specific logic.

11. Expiry, eviction and external storage need special attention

Ignite 2 cache policies are not configuration objects that can simply be copied.

In the Ignite 3 migration documentation, eviction is tied to volatile-storage engine configuration, while expiry is table-oriented and represented by a timestamp column used with EXPIRE AT. (Apache Ignite)

Therefore any TTL/ExpiryPolicy behavior should be treated as a possible schema and business-logic change and tested explicitly.

Likewise, custom CacheStore, read-through/write-through and write-behind integrations should be isolated and re-evaluated against Ignite 3's supported external/cache-storage facilities rather than mechanically ported.

12. Security, monitoring and operational behavior are also migrations

Do not stop when application tests pass.

Ignite 3's security/authorization system was rewritten around users, roles and permissions, and security configuration is cluster-wide. (Apache Ignite)

Metrics are disabled by default and are enabled by metric source, so an Ignite 2 monitoring setup can appear “broken” even when the cluster is healthy. (Apache Ignite)

REST and the Ignite 3 CLI are important operational interfaces. Cluster initialization is an explicit lifecycle step before a newly started collection of nodes becomes an operational cluster. (Apache Ignite)

Migrate deployment scripts, health checks, TLS/authentication, dashboards, alerts, startup sequencing, backups/DR assumptions and operational runbooks alongside Java code.

If JDBC is used, retest it separately. Ignite 3.1 provides org.apache.ignite.jdbc.IgniteJdbcDriver, but the driver has documented JDBC feature limitations; do not assume identical Ignite 2 behavior. (Apache Ignite)

Recommended execution order

1. Read migration_info.md and preserve every project-specific requirement from it. Inventory every Ignite 2 API/configuration touchpoint and classify it by data, SQL, transactions, compute, streaming, topology, storage, security or operations.
2. Decide the target architecture: ordinary applications should normally become Ignite 3 thin clients unless there is a concrete reason to run an embedded database node.
3. Provision a clean Ignite 3.1 environment and make cluster initialization/startup reproducible before porting application code.
4. Redesign the storage model: storage profiles, distribution zones, replica counts, partition counts, node filters, tables, primary keys and colocation keys. Use 3.1 zone-based replication intentionally.
5. Convert/rebuild Ignite configuration. Use Apache's migration converter only as a starting point and manually review every warning/unconverted Ignite 2 property.
6. Create the Ignite 3 schema and indexes, then port IgniteCache usage into KeyValueView/RecordView/Tuple APIs. Convert legacy Java date/time mappings and BinaryObject-dependent code.
7. Port SQL and transaction logic. Run every important query and concurrency workflow, not just compilation tests.
8. Port Compute, data streaming and any advanced Ignite 2 facility as separate migration tasks rather than hiding them inside CRUD changes.
9. Perform data migration using the official Ignite migration tooling or another explicitly validated export/import path. Never reuse Ignite 2 persistence files directly.
10. Validate row counts and representative records, primary keys, types, nullability, indexes, TTL behavior, transactions, query plans, colocation, node failure behavior, authentication/TLS and monitoring. Then load/performance-test the result before declaring the migration complete.

Definition of done

The migration is not done merely because the application compiles.

It is done only when the application no longer relies on accidental Ignite 2 semantics; its tables/zones/storage model is intentionally designed for Ignite 3.1; all important SQL and transactional workflows have been tested; data migration is verified; compute/streaming/advanced cache functionality has either been ported or explicitly redesigned; and deployment, security, monitoring and failure/recovery procedures work against a clean Ignite 3.1 cluster.

Whenever uncertain, consult the Ignite 3.1 documentation, not an Ignite 2 example and not an early Ignite-3-beta/3.0 example. APIs and even some configuration/zone syntax changed between Ignite 3.0 and 3.1. :::

The most important official references for the other model are the Ignite 2 → Ignite 3 migration overview, persistent-data migration guide, Table API documentation, and the Ignite 3.1-specific migration guidance.

A particularly useful tactic with a primitive coding model is to give it the guide above and require it to produce the Ignite-usage inventory before editing anything. That prevents it from fixing the obvious IgniteCache compiler errors while silently overlooking affinity, TTL, persistence, transaction, BinaryObject, compute, or operational semantics.

I’m GPT-5.6 Sol.

Sim — pelo que descreves, acho que há uma confusão entre autenticação npm e resolução Maven, e isso pode estar a mandar-te na direção errada.

Para o Ignite 3.1, os artifacts Java oficiais estão no Maven Central. Por exemplo, org.apache.ignite:ignite-client:3.1.0 existe lá oficialmente. (Maven Central) Portanto, se o Maven te diz que não existe no Artifactory gpfwise, o mais provável não é o artifact ser privado: é o Artifactory interno não estar a fazer proxy de Maven Central para esse artifact/repository, ou o teu Maven estar obrigado a usar um virtual repo específico.

Eu investigaria nesta ordem:

1. Corre:

bash
mvn help:effective-settings

Procura algo como:

xml
<mirrors>
    <mirror>
        <id>...</id>
        <url>https://...gpfwise.../artifactory/...</url>
        <mirrorOf>*</mirrorOf>
    </mirror>
</mirrors>

Se houver mirrorOf=*, isso é muito importante: significa que mesmo que metas Maven Central no pom.xml, o Maven pode continuar a mandar tudo através do Artifactory da empresa.

Depois corre:

bash
mvn -U clean compile

ou, para veres exatamente que repo está a tentar usar:

bash
mvn -X -U clean compile

Procura a linha:

text
Could not find artifact org.apache.ignite:...
in <repo-id> (<repo-url>)

Onde procuraria no Artifactory

No UI do Artifactory, pesquisa diretamente por:

text
org/apache/ignite/ignite-client/3.1.0

ou:

text
ignite-client-3.1.0.pom

O artifact que esperarias encontrar é:

xml
<dependency>
    <groupId>org.apache.ignite</groupId>
    <artifactId>ignite-client</artifactId>
    <version>3.1.0</version>
</dependency>

Essa é precisamente a dependency recomendada pela documentação do Ignite 3.1 para uma aplicação cliente. (Apache Ignite)

Se a aplicação estiver a arrancar um Ignite node embedded, então provavelmente estás a falar de coisas como:

text
org.apache.ignite:ignite-api:3.1.0
org.apache.ignite:ignite-runner:3.1.0

que também existem no Maven Central. (Maven Central)

Eu procuraria outro Maven virtual repo

É bastante plausível que gpfwise não seja o repo certo para essas dependências novas.

Num Artifactory empresarial costuma haver repos com nomes deste género:

text
maven-virtual
maven-public
maven-all
libs-release
libs-release-virtual
central
maven-central-remote

Os nomes reais da vossa empresa podem ser completamente diferentes, obviamente.

O que interessa é encontrares um Maven virtual repository que inclua um remote repository apontado para Maven Central.

Ou seja, conceptualmente:

text
maven-virtual
 ├── company-maven-local
 ├── other-internal-repos
 └── maven-central-remote
         ↓
    repo.maven.apache.org

Se gpfwise só agrega determinados repos internos ou um remote Maven limitado, explica perfeitamente porque Ignite 2.17 compilava e Ignite 3.1 não.

A parte importante: .npmrc provavelmente não resolve isto

Se estamos a falar de artifacts definidos no:

text
pom.xml

o Maven não usa .npmrc para os ir buscar.

.npmrc serve npm/pnpm/yarn.

Para Maven, normalmente precisas do:

text
~/.m2/settings.xml

As credenciais são definidas num <server> cujo id tem de corresponder ao id do repository ou mirror. Isso é comportamento standard do Maven. (Apache Maven)

Por exemplo:

xml
<settings>
    <servers>
        <server>
            <id>gpfwise</id>
            <username>${env.ARTIFACTORY_USER}</username>
            <password>${env.ARTIFACTORY_TOKEN}</password>
        </server>
    </servers>
</settings>

E algures no settings poderias ter:

xml
<mirror>
    <id>gpfwise</id>
    <mirrorOf>*</mirrorOf>
    <url>https://SEU-ARTIFACTORY/artifactory/MAVEN-VIRTUAL-REPO</url>
</mirror>

Repara que:

text
<id>gpfwise</id>

tem de bater certo nos dois lados.

Eu não colocaria uma nova key aleatoriamente no .npmrc para tentar resolver um erro Maven.

Se o projeto também faz build de frontend e por isso realmente precisa do .npmrc, aí sim é outra configuração.

O formato JFrog atual é tipicamente:

ini
registry=https://<artifactory-host>/artifactory/api/npm/<npm-virtual-repo>/

//<artifactory-host>/artifactory/api/npm/<npm-virtual-repo>/:_authToken=${ARTIFACTORY_TOKEN}

É o formato documentado pela JFrog. (JFrog Docs)

Mas isto resolve:

bash
npm install

não:

bash
mvn compile

E não metas a token diretamente no .npmrc versionado no Git.

O cenário que me parece mais provável no teu caso

Diria que tens algo parecido com:

text
ANTES

Ignite 2.17
   ↓
Maven
   ↓
gpfwise Artifactory
   ↓
artifact já disponível/proxy permitido
   ✓

Agora:

text
Ignite 3.1
   ↓
Maven
   ↓
gpfwise Artifactory
   ↓
org.apache.ignite:*:3.1.0
   ✗ não está nesse virtual repo

Mas os artifacts existem publicamente no Maven Central. (Maven Central)

Portanto eu tentaria descobrir qual é o Maven virtual repo corporativo que faz proxy de Maven Central, em vez de começar por gerar uma nova npm key.

Uma coisa que me ajudaria imenso a dizer-te exatamente o que mudar é a parte do erro que diz:

text
Could not find artifact ...

mais o teu:

xml
<repositories>...</repositories>

do pom.xml, se existir, e os blocos:

xml
<mirrors>
<servers>
<profiles>

do ~/.m2/settings.xml sem passwords/tokens.

Com isso consigo dizer-te quase diretamente: “este repo está errado / falta este server id / a autenticação está aqui / precisas de pedir que este virtual repo inclua Maven Central.”