Which is the real ADempiere sourcecode?

[red1]

Good question. As far as I know, it was the Trunk in SVN of http://www.sf.net/projects/adempiere. There the ruling council there has allowed it to be transferred to Mercurial HG repository of the same project space.

However the top coders namely Heng Sin has moved his project to Kenai and Carlos also moved his to kenai. So this makes 3 spots to look at and our eyes have to pay more attention to those Kenai space as there is where the real meat resides.

This is not good. Or easy for newbies.

So i asked Carlos why not he merged his work with Heng Sin's and worked under him. According to Carlos, that was his intention but Heng Sin preferred things remain in their own silos as its possible with GIT style versioning system as granted in HG Mercurial. He said that Heng Sin prefers him to take openly and apply his own patches in his (Carlos') own project space. Carlos also assured me that his is not a fork, and will be open and offered to the ADempierean Community at large. He will also assist the ruling council there to incorporate his work back to the trunk.

Looking at what Carlos Ruiz is all about all this while which is the careful application of patches and upgrading of the sourcecode as well as making stable official releases for the past 4 years of ADempiere, his has the characteristics:

1. It is more stable
2. It is more up to date
3. It is more production ready
4. It is updated more faster
5. It is more receptive to others' work
6. It maintains to be usable as main trunk
7. His support is more expert quality
8. He maintains best practice and documentation included
9. His is always community open source, with no parts hidden for commercial reasons

I thus will use his work as my reference trunk and also try to incorporate any enhancements or bug fixes i have to his project space. This is with the sincere hope that eventually his and Heng Sin's work become mainstream. In fact if we mostly refers to the plan here, that situation will be true!

The better side is that all 3 spaces are in hg mercurial platform and although it will get using to, ironically it is intended to try to avoid conflict within the commit members. And the way it does that is to allow the contributors to work in their own separate silos without bothering about what the others do!

[globalqss]

Thanks Redhuan for raising this question.

Just for understanding of the reasoning behind my maintained 361 branch - this is a branch which is in production in several of my installations - I need to fix the problems that are raised there - and I don't want to fix them privately, I want to share this work and contribute it back for community usage.

On the other hand - this is the present, but if you analyze the future, I think the future is in Heng Sin's OSGi branch - so I'm contributing my time to create a clear migration path from 361 to this new version.

I'm happy to check and fix errors reported on 360 or 361 (I'm doing this in 361 and the count already passed the one hundred). And I'll be happy to provide guidance or instructions to anyone who wants to take this as base for their implementations. In the end the goal is to share the maintenance costs, and provide an usable version to community by default.

Regards,

Carlos Ruiz

[zulqarnainhabib]

Hi Carlos

We are using 361 in production and it is really stable. Thanks for your contributions.

Habib

[globalqss]

Thanks for the feedback Habib - good to know!

Regards,

Carlos Ruiz

[PeanutBlake]

hi Carlos,

i will also follow your branch if i do next implementation.
i am now using 3.6.0lts in real implementation, there are still some bugs which jump out and make trouble.
thank you very much for your priceless contribution!

peanut blake

[demostain]

Hi, im trying to learn to customize adempiere and i started checking out the code, Im using the codebase from https://hg.kenai.com/hg/adempiere361~adempiere361
I too prefer the latest Carlos's patches since the 3.60lts release is still a little buggy.
I already imported the project on Eclipse and made a Build, but im not sure if i still need to apply patches to this build, and if that is the case, what patches should i apply?
GlobalQSS or the Adempiere Patches?
I tried searching in the wiki but i didnt find anything specific about the new codebase so i post the question here.
Thanks in advance.

[globalqss]

Hi Demostain,

There is a simple formula to apply regarding patches:

tags/adempiere360 + branches/globalqss/patches_360 = branches globalqss adempiere361

patches_360 are not released on every commit, but just when considered worthy.

So, if you're running on top of adempiere360 - you need to apply patches and migration scripts.

If you're running on top of a self-built version from 361 - you don't need to apply patches (indeed you'll be more up to date than applying patches) - and you must take care of applying the migration scripts when they appear.

Regards,

Carlos Ruiz


PD: There is also a spanish forum here:
viewforum.php?f=34

[demostain]

THanks Carlos,
i have other questions and i will put them on the spanish forum,

Greetings.

[hardmax]

Hi Carlos,

I have the lastest 360 + globalqss patches in production use.

Now I want to use your source code.

I download it with mercurial, and i configure it to build in my system(I make my.build.properties), but I don't see the migration scripts in migration folder. Do I need something to make the scripts?

How make patches.jar to only move this file and not all install directory?

Thanks a Lot

[globalqss]

Hi Max,

I don't see the migration scripts in migration folder

migration/360lts-360lts.010
migration/360lts.010-release

as shown here:
http://kenai.com/projects/adempiere361/ ... 0?rev=6073
http://kenai.com/projects/adempiere361/ ... e?rev=6073

How make patches.jar to only move this file and not all install directory?

To make a patches.jar I do something like:
- extract the classes from 361 that changed since 360
- compile and export those classes as patches.jar
this can be seen here:
http://adempiere.svn.sourceforge.net/vi ... tches_360/

The script getlistmodsrc.sh was intended to bring the modified classes - it was working in svn, but I have not adapted to work with mercurial.

The generaJar.jardesc is the descriptor to create patches.jar - and correspondingly the generazkJar.jardesc to generate zkpatches.jar

I also packed some changed libraries like poi in the installer.

_________________

Now, if you're compiling directly from adempiere361, I think you can replace directly Adempiere.jar (copy it to AdempiereOriginal.jar) and webui.war (copy it to webuiOriginal.war)

Regards,

Carlos Ruiz

[hardmax]

There isn't those folders in migration folder (In mycomputer).. only there are 360lts-release.. but in kenay I view this folders...

I use

--> hg clone https://hg.kenai.com/hg/adempiere361~adempiere361 svn_adempiere

Why i don't see thats folder?

[red1]

Migration folder is a sub-folder in there.

[globalqss]

Sorry Max, forgot to give a final instruction.

When you clone a mercurial repository the clone is sit at default branch. In this case you must move the cloned to globalqss_adempiere361 branch.

This is simple, you just need to change to the cloned directory and execute the command:

hg update globalqss_adempiere361

And then you must see this branch.

Regards,

Carlos Ruiz

[hardmax]

Thanks Carlos,

With this I view all files, thanks.
Now you say:
"if you're compiling directly from adempiere361, I think you can replace directly Adempiere.jar (copy it to AdempiereOriginal.jar) and webui.war (copy it to webuiOriginal.war)"
Then, have I to delete patches.jar and zkpatches.jar too? Because they change AdempiereOriginal.jar, and made Adempiere.jar. Is it correct?

Thanks a lot..

[globalqss]

Yes, correct, with such new method of deployment you must replace (not delete) patches.jar and zkpatches.jar with empty jars (I mean jar files with just the manifest like those that originally install adempiere).

Regards,

Carlos Ruiz

[Derek]

There are two questions I confuse with, would you pls help to explain?

1.There is a folder 'migration\360lts-release' in 360lts original branch, at present, we have
migration/360lts-360lts.010
migration/360lts.010-release
The script number is duplicated in migration\360lts-release and migration/360lts-360lts.010 but scripts are not the same.

2.There is also a branch name 'adempiere_361lts.010'.
any diff between 'globalqss_adempiere361' and 'adempiere_361lts.010' ?

[globalqss]

Hi Derek - the .010 is just to sync with an intermediate version I released on feb-23.

> The script number is duplicated in migration\360lts-release and migration/360lts-360lts.010
> but scripts are not the same.

Nope, 360lts-360lts.010 has scripts numbered from 738 to 780v and 360lts.010-release is numbered 781 to 787 until now.

360lts-release is not part of this branch - it must be in trunk and the numbering is maintained there in a different way.

Regards,

Carlos Ruiz

[Derek]

Hi Carlos, Thanks for your explaination.

>360lts-release is not part of this branch - it must be in trunk and the numbering is maintained there in a different way

You mean those scripts only belong to the trunk(360lts), may be just used for some extended function, but no need to apply to the branch you currently maintained?

[globalqss]

Hi Derek,

> You mean those scripts only belong to the trunk(360lts),
> may be just used for some extended function, but no
> need to apply to the branch you currently maintained?

If they are in trunk and not in branch globalqss adempiere361 - then yes, must not be applied here.

I made peer review on all trunk scripts - took the correct and required, and rejected those that have quality issues. If you're interested in any specific script I can explain you the cause of rejection.

Regards,

Carlos Ruiz

[azzamahmad]

Hi Carlos ,

I have some questions :

1. Are the patches here :http://sourceforge.net/projects/adempiere/files/GlobalQSS_Patches/360lts/patches_360lts_20110607_GlobalQSS.tgz/download

Included here http://kenai.com/projects/adempiere361/ ... re361/show

2. Can we find migration scripts for the source here :http://kenai.com/projects/adempiere361/sources/adempiere361/show ?

3. Is the Fixed assets ( maintained by Red1 ) included in the source here :http://kenai.com/projects/adempiere361/sources/adempiere361/show

Thanks & Best Regards,

Azzam

[azzamahmad]

Hi Carlos,

I am trying to download from here :hg clone https://hg.kenai.com/hg/adempiere361~adempiere361

But, I am getting this error "certificate error : certificate for kenai.com ( use --- insecure to connect insecurely )

Please, advise.

Thanks & Best Regards,

Azzam

[red1]

Hi Azzam,
Is this the first time you are trying this? Try to do it from your root terminal:
hg clone -U https://hg.kenai.com/hg/adempiere361~adempiere361

Or google for help from HG sites. We won't support such issues here and only focus on the ERP. Such as your earlier questions on the Fixed Assets and other code changes i can answer that here:

Fixed Assets and other changes will be studied eventually by Carlos Ruiz for inclusion. We consult each other among the top contributors such as HengSin and Adaxa.

We may be slower but it is more important to be open and stable at the same time. For example the tests done are just the beginning. Alot of QA is really needed. The progammable tests made are very important as they can quickly root out impact within seconds. The ADempiere trunk for example is not moving much because it needs real good contributors. Secondly even if there is, how do you know if the code is stable and where is the QA?

To speed things up here is our future. I am constantly meeting new interested contributors to coach them to contribute accordingly and in compliance with the best practice. We need discipline in order to progress well.

[red1]

Carlos,
I also tried to hg pull and update from your repo but i got conflicts due to my Fixed Asset changes. Should i raise tracker in HengSin's kenai and assign to you and submit the patches? They are as developed in viewtopic.php?f=29&t=1251

[hengsin]

Hi red1,

Please open new bug report at jira.idempiere.com instead.

Regards,
Low

[azzamahmad]

Hi Red1,

Thanks for the detailed reply. I am new here . I am studying iAdempiere and rules in this forum.

"We may be slower but it is more important to be open and stable at the same time" : Being open and stable is the best practice in building ERPS.

Thanks again ,

Azzam