Dev environment for 12 release
Kanat Mergenbayev
Hello everyone,
I’m trying to set up a development environment using idempiere-dev-setup (workspace creation + dev environment).
During startup I’m getting the following error:
What I’ve done so far:
-
Using iDempiere 12
-
Created a new empty database
-
Running the standard dev-setup scripts to initialize the workspace
It looks like the system is failing the build/version check even on a fresh database.
Has anyone experienced the same issue with version 12?
Is there an additional step required to initialize or migrate the database before running the dev setup? Maybe I’m missing something obvious.
Any guidance or pointers would be appreciated.
Thank you in advance.
Stack trace
Erick Benivan
you can type bash RUN_SyncDBDev.sh can look on documentation here
https://wiki.idempiere.org/en/Applying_additional_Migration_Scripts
Kanat Mergenbayev
I guess *.qualifier creates this error. 1:49:52.099-----------> Core.getKeyStore: Encryption with legacy key algorithm DES detected - it is recommended to migrate to a stronger algorithm [47]
11:49:52.284-----------> Activator.createHazelCastInstance: Starting hazelcast with configuration from file hazelcast.xml [47]
11:49:52.459-----------> CPSubsystem: [192.168.0.21]:5701 [adempiere.idempiere/localhost:5432] [5.3.7] CP Subsystem is not enabled. CP data structures will operate in UNSAFE mode! Please note that UNSAFE mode will not provide strong consistency guarantees. [47]
11:49:52.572-----------> Node: [192.168.0.21]:5701 [adempiere.idempiere/localhost:5432] [5.3.7] No join method is enabled! Starting standalone. [47]
11:49:52.684-----------> DB.isBuildOK: Build Version Error
The program assumes build version 12.0.0.qualifier, but database has build version 12.0.0.202512310603.
This is likely to cause hard to fix errors.
Please contact administrator. [47]
Excellent question — this goes to the core of how Eclipse / OSGi builds work, and it’s the key to understanding your situation.
Short answer
You did not set qualifier anywhere manually.
It is automatically injected by Eclipse / Tycho when you run iDempiere from source.
Where 12.0.0.qualifier actually comes from1️⃣ In iDempiere source code
Open any core plugin, for example:
org.idempiere.base/META-INF/MANIFEST.MF
You will see something like:
Bundle-Version: 12.0.0.qualifier
This is intentional.
qualifier means:
“This bundle is built in a development workspace”
It is not a real version.
2️⃣ What Eclipse does at runtime
When you:
run iDempiere from Eclipse
or run a PDE launch
or use idempiere-dev-setup
Eclipse does not replace qualifier.
So the runtime version stays:
12.0.0.qualifier
3️⃣ When qualifier becomes a timestamp
qualifier is only replaced when you do a real build, for example:
Tycho / Maven build
Jenkins / CI build
Official iDempiere release
During that build:
12.0.0.qualifier ⬇ 12.0.0.202512310603
That timestamp becomes:
Bundle version
Product version
Stored in lastbuildinfo in DB
Why the DB has a timestamp but code has qualifier
Because:
idempiere-dev-setup can initialize a DB using a built artifact
But you are now running directly from source
So you ended up with:
Component
Version
Eclipse runtime
12.0.0.qualifier
Database
12.0.0.202512310603
🚫 iDempiere forbids this combination.
Where the DB version is written
In the database table:
SELECT * FROM lastbuildinfo;
Column:
buildinfo = 12.0.0.202512310603
This is written when:
DB is initialized from a built distribution
OR migration scripts are applied
Why iDempiere enforces this check
This code exists for a reason:
Running newer DB against older code
Or dev code against prod DB
Can silently corrupt metadata
So iDempiere stops hard instead.
This is good design.
Mental model (important)
Think of it like this:
🔵 qualifier
“I am a developer workspace”
🟢 timestamp version
“I am a built, released system”
You must never mix them.
Correct workflows✅ Development
Source code → *.qualifier
Fresh DB
Eclipse runtime
✅ Production
Built artifacts
Timestamp version
Matching DB
Final takeaway
You didn’t configure qualifier.
It is:
Defined in MANIFEST.MF
Preserved by Eclipse
Only replaced during a real build
Kanat Mergenbayev
I dropped and recreated the idempiere database and then followed these steps:
-
Used idempiere-dev-setup to install iDempiere and configure the Eclipse development environment
-
In Eclipse, used install.app to configure idempiere.properties
-
Navigated to the idempiere directory and ran RUN_ImportIdempiereDev.sh
-
Ran RUN_SyncDBDev.sh
After this, I’m encountering a build/version mismatch at startup.
Is this the correct workflow for initializing a fresh development database, or am I mixing installer/import steps that are not intended for Eclipse dev runtime?
Heng Sin Low
--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/idempiere/8159ba80-e8e6-4cf8-a605-0e80276753e3n%40googlegroups.com.