Looking for guidance: iDempiere Release 12 + VS Code + teamwork

95 views
Skip to first unread message

Oskillar21

unread,
Oct 3, 2025, 3:41:57 PM (7 days ago) Oct 3
to iDempiere

Hello everyone,

I’m looking for help on several topics, but I feel that the ones I’m going to mention are the most important. To give you some context, I am completely new to using iDempiere, and so is my team. I am mainly seeking help in two areas: using iDempiere with VS Code and collaborative work.

We are currently working with release-12 and have made some progress, but what we’ve tried so far to maintain a functional shared repository hasn’t worked for us. I read a post here on the forum about using VS Code with iDempiere, followed the steps, and it worked, but when I stopped the “Debug” and tried to start it again, I ran into errors. The only solution I found was to manually delete the metadata.

On the other hand, we don’t know how to properly collaborate as a team. We ended up working only through “Pack Out and Pack In” in order to stay in sync, but at times this becomes very tedious.

I would like to know how you approach these situations, and I really appreciate any help you can share. I’m sure I’ll have more questions later on, but I understand it’s all part of the process.

If you need more information or context, I’ll be glad to provide it.

Thanks!!

Jesús Castillo

unread,
Oct 5, 2025, 11:46:12 AM (5 days ago) Oct 5
to idem...@googlegroups.com

Hello,

If you're starting to develop with iDempiere, I recommend using Eclipse, as it's the most recommended editor for this project. Here's the guide on how to set it up: https://wiki.idempiere.org/en/Installing_iDempiere.

On another note, regarding team development, you can use a database hosted on a server that everyone has access to, so multiple people can work on the same functionality. From experience, I suggest that any new column added to existing tables should be nullable or have a default value.

I hope this information is helpful to you.

 
Atte: Jesus Castillo.


--
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/49fa034b-d532-4638-90e6-b44eab6fbac5n%40googlegroups.com.

Oskillar21

unread,
Oct 5, 2025, 9:10:58 PM (5 days ago) Oct 5
to iDempiere

Thanks, Jesús. I now have a better understanding of the workflow you mentioned. I still have a few other questions, if you don’t mind. When developing plugins, since they are subprojects of iDempiere, is it possible to keep them in a separate repository and then import them into the Eclipse workspace so we can have them all together?

Another question I have about plugin development is that, from what I’ve researched, some sources say you need two projects (Plugin + Feature), while others mention that the Feature project isn’t necessary. I’ve tried looking for this information in the Wiki but haven’t been able to find anything conclusive. If you happen to have any references or guides for plugin development, they would be really helpful.

Thanks again for your help, and sorry if I’m being a bit persistent!

Heng Sin Low

unread,
Oct 5, 2025, 11:03:09 PM (5 days ago) Oct 5
to idem...@googlegroups.com
Yes, you can keep it in a separate repository.

Feature is optional.



Heng Sin Low

unread,
Oct 5, 2025, 11:04:41 PM (5 days ago) Oct 5
to idem...@googlegroups.com
Also, it is possible to use intellij too, see https://wiki.idempiere.org/en/Development_With_Intellij

However, as others have posted, Eclipse remains the preferred option for iDempiere development.

Jesús Castillo

unread,
Oct 6, 2025, 9:20:37 AM (4 days ago) Oct 6
to idem...@googlegroups.com

Hello, 


If you want to create a new project with a new repository, it's enough to place them in a folder different from the idempiere folder. You can also follow this guide: https://wiki.idempiere.org/en/Developing_plug-ins_without_affecting_the_trunk

Regarding the Feature project, it's used to compile the plugins. I consider it a very good practice to use it.

 
Atte: Jesus Castillo.


Oskillar21

unread,
Oct 6, 2025, 11:37:19 AM (4 days ago) Oct 6
to iDempiere

Thanks again everyone for the help. However, I’m still not completely clear about the “workflow” we could apply. If we host the database, there’s a chance that I might interfere with another teammate’s work, and there would be no way to “revert” those changes.

I made this small diagram as a proposal, my idea was that each person could have their own local database, and then, using Git and a diff tool, compare the XML files generated when performing “pack outs.” Additionally, we could keep all the plugins we develop in the same repository.

I understand that with a hosted database we could save the extra step of merging pack outs, but it also brings back the issue of interfering with each other’s work. Have you encountered this problem before?

Example_Workflow.png

Martin Schönbeck

unread,
Oct 6, 2025, 5:03:58 PM (4 days ago) Oct 6
to iDempiere
Hi,

I'm not sure, why you are intending to let several people work on the same pack-out. If you really want to do that, than all should indeed work on the same database creating the packout. I you really want to combine several packouts to one, you'll best import the packouts in one database, create a new packout exporting all the data of all packouts. But I don't see a valid use case for this type of work.

Regards,
Martin

Oskillar21

unread,
Oct 6, 2025, 5:27:00 PM (4 days ago) Oct 6
to iDempiere

Hi Martin,

It’s not really that I want several people to work on the same “pack out.” The main issue we’re facing is avoiding interference with each other’s work. As Jesús mentioned earlier, we could use a hosted database, but that brings us back to the same problem.

What I meant about the “pack outs” is that if someone adds something new or edit (like a window, menu, or table) and another person does too, we could merge them later, since from what I’ve studied, the pack outs generate an .xml file, and we could perform a merge from there.

I also want to reiterate that I’m new to this technology, and most of the solutions I come up with are based on my own trial and error. If I’m misunderstanding something or if there are better approaches that I’m not aware of, I’d really appreciate any guidance.

Also, if anyone here has experience working in a team environment, I’d love to know what workflow or methodology you used, so we can get some ideas from that.

Jesús Castillo

unread,
Oct 6, 2025, 7:32:19 PM (4 days ago) Oct 6
to idem...@googlegroups.com
Hello,
In my opinion, the best practice is to manually place the packouts in the develop branch, and once the plugin is finished, perform a packout of the entire functionality. Doing this in Git is not recommended because you'd be adding and removing .zip files.

If the development is done in an organized manner, there shouldn't be any conflicts between them, as new functionalities should work in isolation.
 
Atte: Jesus Castillo.


Reply all
Reply to author
Forward
0 new messages