Dear all, I'm confusing about the way modules work together. Please take a look in my real experience as below:

a. I want to use Google Maps Library on forge. So started download and install current version (Stable Version 4.1.2 ) into my env. One of its dependencies is JavaScript Utils, version: 2.0.0

b. Service studio downloaded both

c. After install, I used it in my application and some warning message came out, asking to refresh dependencies as 1 has got out-updated. Ignore the warning and publish also didnt work well as it cause error during runtime. The reason seems to be  JavaScript Utils version now is 2.0.1 


Now my questions are:

1. When a module uses some dependencies (producer), does it always store a kind of reference? not an actual clone? (like traditional libraries: jar...)

2. Don't we have ability to define which version we want our module to refer? for example in my case, i want to specify version 2.0.0 instead 2.0.1 of JavaScript Utils.

I saw in below topic: Kilian Hekhuis said: "When you publish a consumer module (that is, an eSpace that references another one), it always uses the most recent version of the producer module (the eSpace that the referenced object like Action/Entity etc. lives in), regardless of whether you've refreshed anything in the Manage Dependencies... pop-up."

https://www.outsystems.com/forums/discussion/26668/dependency-management-what-kind-of-refresh/#Post97822

So it do always point to the latest version?

3. If the answer is true, how can we be confident and use module in forge when the creator can make any change and update any time? Is there any solution or work-around out there?

Thanks,

Hi Giang,

Trying to answer your last point (3).

Whenever you download a component from forge and install it in local environment you have the physical copy in your environment which you refer to other espaces and you also have full control over the component, if you think you want to make changes in the component as per your need yo can do it and it will be limited to your environment.

Meanwhile if there is any change in the forge component it wont impact the component version that you have in your local environment until you update it through forge.


 Regards,

-PJ-

Hi @Pramod,

Thank you so much for your quick support. 

May i ask you about question 1 and 2? Apart from above case, i have faced the same thing so many times, when you download a new branch module from forge into your env but can not use it right away without some kind of "clean up"...


Regards,

Hi Giang,

Usually the version update of a component means that they either added some new feature to the component or improved existing one.

In case of new added feature you don't need any cleanu  ,you will have new feature listed available and if you want to use them you can take reference and use it.

In other case if there is any change in any of the existing feature that you are already referring you application using , for example if added a new parameter or change the data type than you need to change your consumer according to the changed signature.


Regards,

-PJ-


Solution

Hi Giang Nguyen Truong,

Pramod already explained it, but let me add just this, regarding the Forge components and their dependencies' handling by Service Studio:

When different components on the forge depend on each other, (in your case Google Maps Library depends on JavaScript Utils) they will depend on a specific version of the other components (so Google Maps Library 4.1.2 depends on JavaScript Utils 2.0.0). If a dependency component is updated (JavaScript Utils was updated to 2.0.1), but the component wasn't (Google Maps Library 4.1.2 is still the latest version), then there may be some scenarios (like the ones Pramod mentions) where you will need to fix dependencies after installing.

The tricky part here is that when Service Studio downloads a component's dependencies, it will always download the latest stable release for your platform version (in this case, JavaScript Utils 2.0.1) and not the exact version the component depends on. This seems to be an explicit behaviour (to guarantee up-to-date components in a factory perhaps?). If you want, you can explicitly install JavaScript Utils 2.0.0 before installing Google Maps Library 4.1.2 and you wouldn't have any dependency issues... until you updated JavaScript Utils. :-p

Hopefully this clarifies things a little better

Solution

Hi all,

Thanks for all of your explanations, it seems to be more clear to me now. I though a OutSystems module, in some aspects, like a stateless tradition library. But as long as we have entities, resources or even screens, backward compatible and loose coupling seem to be more difficult. Things started to make sense to me..

Just side questions about the solution from Jorge Martins. I tried by below steps:

. Remove both Google Maps Library 4.1.2 and JavaScript Utils 2.0.0  (checked on Service Center)

. Install JavaScript Utils 2.0.0

. Install Google Maps Library 4.1.2  (no extra download happened - as expected)

But when i published and run the follow error appeared:

4. Does this behavior belongs to the platform? forcing us to always use the newest version?

5. In theory, the Google Maps Library is now pointing to JavaScript Utils 2.0.0 in my personal env. But regardless how many time i tried to change and publish my "personal" JavaScript Utils, the "manage dependencies" box always compare with the newest version on Forge ( 2.0.1 ). As my understand, it should show the gap between the original  2.0.0 and my custom version, right !? Like making a new branch in git, apart from the "original" branch in Forge ?

Sorry all, the questions keep flowing out from my mind..

Hi all,

The 5th question was just my mistake.. finally..realizing at this late. 

Thank you all so much for your great support! :)