Please help me to upgrade Adempiere 3.6 to 3.8 version.
Note : my current version has some code changes which is related to different screens.

I need to speak with a consultant in order to get the business suite running on the cloud. I'm in Seattle. Where is the list of consultants?

Why Adempiere community is not that active.

Can we upgrade directly from 360 to 380

¡Hola! Quisiera saber mas de como obtener esta herramienta. ¿Podrian proporcionarme algún contacto de partner en México? Gracias

Post has attachment

Hi, I am looking to move to the ADempiere 380.

Post has attachment
World Announcement for ADempiere new and improved content portal

We are pleased to announce the launch of a new and improved content portal for ADempiere thus reaching another milestone following the release of version 380, which confirms the traction and commitment from our community and all those behind this great Bazaar project.

A group of committed people worked hard for several months to build a professional and informative site for our business solution, a place where people will find all the required information to evaluate our process management tools, breaking dependence from a particular software provider and avoiding high license costs and more important not requiring long term commitments from third parties to install, extend and/or customize it.
The portal offers an overview of the history, functionality, features, benefits and success stories on ADempiere, but also allows to quickly download an installer, swift access to source code, bug tracking and browsing the forums to learn from other organizations using Adempiere worldwide.

A new publishing platform has been adopted that will allow a more effective maintenance and keeping up with the project’s documentation for current and future enhancements on a regular basis.

We also have moved away from the historic SourceForge repository to a more professional and secure version control system thus all code and collaboration platform ADempiere moved to Git: www.github.com/Adempiere, which hosts hundreds of open source projects with thousands of developers working actively and collaboratively for the success of their own projects. We also moved the binaries distribution to http://www.bintray.com/adempiere which also serves many other professional software open source projects and malware free.
We started with a new tool to manage and control the discussion forums where information and knowledge will be managed by the community allowing you to create a knowledge base for the benefit of all those involved. 

On the other hand we are in the process of migrating information from the old sourceforge forums to our platform to protect the knowledge generated by the 10-year project.
We have created a chat room for developers to collaborate on the development of future versions within http://gitter.im/adempiere the channel is public and anyone with github account can access it and free to participate.

An important additional point worth mentioning is that the portal is a place where the interested parties can find business consulting services from professional experts, certified and experienced partners that have successfully deployed Adempiere throughout the years.

We have created a certification program that enables our associates qualify by successfully documented cases of guaranteeing the quality and knowledge of the solution.

Incorporate a training plan to train experts in ADempiere consultants that implement best business practices in the sales process, distribution management, supply chain, manufacturing, production control, financial management and human capital.
We established a very successful contribution process by integrating the best features of business and validated in successful implementations, allowing customers the benefits are not obtained proprietary software manufacturers since this project to be led by the community, customers dictate improvements and functionality for future versions.
For version 4 we will focus on the technological renovation to compete with the demands of today, creating a new UI for mobile devices and the development of a new web interface with support for HTML5 responsive, in the next release ADempiere will support Java 8 consciously decided to wait for the release of Java 9 in particular the Jigsaw project that will become the standard for Java modularization.
We want to thank all contributors who made this great company, I invite anyone who wants to collaborate with this great project.
Victor Perez Juarez
Founder of ADempiere
On behalf of the  Community of ADempiere

Post has attachment

Post has attachment
The Future Of ADempiere as a DDD reactive system

Before I start talking about modularity, I’d like to describe the path to define the most suitable architecture for a software like ADempiere.

During the last years I’ve been reading and analyzing the different approaches and architectures for software development and at the same time figure out which would be the best for ADempiere.

As we all know too well, the design of our program is based on a two-layer combination [Client/serve](http://en.wikipedia.org/wiki/Client–server_model) (1) Swing, which in the nineties of the last century was one of the best adopted because it used the network and the PCs in a way that the main server was freed from heavy load by leaving certain tasks on the client. The main focus was to have the core of the software being executed on a central server while clients connect to it to access data and do the business logic locally.

Ironically think have swung back to where they originally started, as there was a mainframe with dumb terminals which only displayed data to users without any kind of complex data processing.

I was not present at the age where it was needed a white coat to access to big data centers consisting of several IBM 390s or Systems 36 with hundreds of terminals (ATMs). But today, the context is in a way similar to these former times: there are big data centers which by the way have helped to reduce costs with rented servers accessed on a virtual way for a couple of hundreds dollars a month (Amazon, Google Cloud, Heroku to name a few). The main difference now is that applications have to service thousands or even millions of users, the capability of being able to scale up horizontally is an usual requirement nowadays; these new context demands that applications are designed differently as the requirements are totally different.

The access to these servers is made by gadgets which though not totally dumb, they execute client applications run on a web browser whose only task is to interpret java script or HTML code, where the highest value is standardization and integration of multiple operating systems and platforms.

In the next decade the main focus was in developing applications based on the model view controller paradigm [MVC](http://en.wikipedia.org/wiki/Model–view–controller) (2), which allowed code separation.

The model layer allows the access and updating of data, mostly saved in a relational database. On the other side it allows to work with Object-relational mapping (ORM) which consist of an abstraction on the database and persistency, replacing the usage of SQL sentences depending on the implementation of a motor implemented on every database.

The view layer separates the code for displaying and for user interaction via an user interface, which is implemented according to the access gadget.

The controller layer is in charge of linking the view layer with the data model, and implements the code that responds to the actions needed.

When we analyze the code of ADempiere in retrospective, we can see the course of time and evolution of underwent. It went from the original client/server based on Java swing with direct database access via pure SQL sentences to the current own ORM combined with SQL to access the data and the MVC application based on te AJAX web client.

Even though technology has moved on, our domain model has persisted; that is why we can infer that the most important asset of ADempiere is the Application Dictionary which preserves the domain model and the business logic.

Thanks to the fact that ADempiere was drafted and developed on a Model Driven Architecture [MDA](http://en.wikipedia.org/wiki/Model-driven_architecture) (3), the domain model is protected of obsolescence by the Application Dictionary

As a voluntary person, responsible for the future architecture of beloved ADempiere, we will adopt the DDD approach as the main line of development.

### Now: what is a software development guided by the  [Domain Driven Design DDD](http://en.wikipedia.org/wiki/Domain-driven_design) (4)?

_DDD_ is an approach for developing software with complex requirements and having a deep linkage to a model that defines the core of the business logic being developed.
The most important commandments to develop and maintain a domain model are:

* Place the main focus of the project in the core and the business logic of the domain.
* All complex designs are based on a domain model.
* Initiate a creative collaboration between technicians and domain model experts to define iteratively a model that addresses the particular problems of the domain.

The [Domain Driven Design](http://domainlanguage.com/ddd/patterns/DDD_Reference_2011-01-31.pdf) (5) is not a technology nor a methodology. It is a set of patterns towards the building of business applications starting from the domain model, which provides an useful, practical structure with consistent terminology for decision-making in the course of designing software. 

_Domain_ : a knowledge sphere (ontology), influence or activity. The area where an user applies a program is the software domain.

_Model_ : a set of abstractions describing sections of a selected domain than can be used to solve problems or tasks related to that domain.

_Ubiquitous language_: a structured language in the context of a domain model and used by all team members to interconnect all team activities.

_Context_ : the scenario in which a word or statement defines her meaning.

A purely technical vision for the software development could be the migration to a multiple layer application (persistency layer, access data layer, service layer and presentation layer).

_DDD_ is not quarrel with any technology or design pattern for example [Dependency Injection DI](http://en.wikipedia.org/wiki/Dependency_injection) (6), 

but without change there is a very important premise The domain model should remain isolated from the outer layers! since any technological change should not affect my core business.

###Important Premise: 

* The model must be kept isolated from the external layers! The reason: no technological change should affect the core of the business.
* Each layer is a concentric circle which defines a software area; while moving from the center to the outer levels the software evolves. The outer circles are mechanisms, while the inner circles are the conditions.
* The most important rule for this architecture is the dependency rule.
* As a rule, dependencies within the source code can point only towards the center. Nothing in an inner circle can know about anything in an outer circle. Moreover, any declared name in an outer circle cannot be mentioned by the code of an inner circle. This includes function calls, classes, variables or any other software entity.
* Due to the same reason, the data formats used in an outer circle cannot be used by an inner circle, especially if these formats are generated in a ORM from an outer circle. It is our intention that nothing from an outer circle affects the inner circles.
* This way, for interacting between circles or layers is paramount to establish an API which allows the communication between inner and outer layers by means of adapters or messages

There are some architectures based on this view; they are similar and differ in some points, but coincide in the importance of a domain model  [Hexagonal architecture](http://alistair.cockburn.us/Hexagonal+architecture) (7), [Onion Architecture](http://www.infoq.com/news/2014/10/ddd-onion-architecture) (8), [The Clean Architecture](http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html) (9).

As the way of defining how we will build the software around ADempiere is crucial, we will adopt the clean/Onion architecture, where the main focus is to keep clean the domain model interacting with the outer layers by means of contracts (APIs or interfaces) which allow to conveniently separate the domain model of the implementations  (API or contract). This will provide for an ordered evolution avoiding technological obsolescence.

On the other hand, we will define a [Domain Specific Language DSL](http://en.wikipedia.org/wiki/Domain-specific_language)  (10) for ADempiere focussed on the business, allowing the building of our ubiquitous language and clearly delimiting  the contexts. This helps a more natural development of the business logic.
As stated before, every decision has to be authorized by the benefits to be gained; moving towards DDD will allow us to obtain the following benefits:

###The Benefits:

* Decoupled code
* Reduce spaghetti code
* Traversal Services independent of the domain model (Log , Transactions , Security ).
* Code easy to maintain
* Software adaptable to changes
* Design based on components
* Contexts delimited by the business process
* Build our own testing sets (functional, integration, regression test) 
* Better handling of dependencies and modularity.
* Create a DSL (Domain-specific language) (9) for the business
* Build to Adempiere as a [Reactive System](http://www.reactivemanifesto.org)  (11) __(Responsive , Resilient , Elastic , Message Driver)__ 
* An application designed for the demands of today

It is important that developers interested in participating in this big project become familiar with concepts and terminology.

In the next months and weeks, I will continue writing more articles with concrete examples permitting discussion.

[Victor Perez](http://www.adempiere.com/User:Vpj-cd)
An ADempiere founder


* (1) http://en.wikipedia.org/wiki/Client–server_model
* (2) http://en.wikipedia.org/wiki/Model–view–controller
* (3) http://en.wikipedia.org/wiki/Model-driven_architecture
* (4) http://en.wikipedia.org/wiki/Domain-driven_design
* (5) http://domainlanguage.com/ddd/patterns/DDD_Reference_2011-01-31.pdf
* (6) http://en.wikipedia.org/wiki/Dependency_injection
* (7) http://alistair.cockburn.us/Hexagonal+architecture
* (8) http://www.infoq.com/news/2014/10/ddd-onion-architecture 
* (9) http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
* (10) http://en.wikipedia.org/wiki/Domain-specific_language
* (11) http://www.reactivemanifesto.org
Wait while more posts are being loaded