fastconnect / tibco-bwmaven

FastConnect TIBCO Factory - BWMaven, application lifecycle management for TIBCO BusinessWorks projects
http://fastconnect.github.io/tibco-factory/bw-maven-plugin/
Apache License 2.0
13 stars 7 forks source link

Question about dependency order #10

Open moanoit opened 8 years ago

moanoit commented 8 years ago

Hi,

I have a project for which the projlib dependency order is important. And I have several projlib dependecies. But when I launch designer, the DTL order is different from pom order. This might cause problem. I see that the resolved file order is different from pom. Wouldn't it be better to rely on dependency:tree (in this case, I would have the correct order) ?

Regards,

PS : great plugin anyway !

debovema commented 8 years ago

Hi @moanoit and thanks for your interest in this plugin.

Currently, the dependencies are resolved using "dependency:list" goal. Your suggestion is to use "dependency:tree" instead ? In that case how can we deduce the order of dependencies if the tree become complex (with different depth) ?

Can you describe an example where DTL order really matters ? The only situation I can think of is when DTL have some subsets which are not fully disjoint. IMHO a little refactoring should fix the problem.

Regards,

Mathieu

moanoit commented 8 years ago

Hi @debovema, thanks to pay attention to my demand. I saw you were using "dependency:list" goal, but I'm not sure if "dependency:tree" goal would better. I'm just

I agree with you, this case will not happen if the code is clean and the best would be a refactoring. But it can happen (and in my case it does) and the refactoring could be too long and risky to handle.

Let's assume that you have a project A using 2 DTLs, B and C. And you have B that is using a version of C to be built. Then, it is important to be able to choose whether B is loaded before C or the opposite. Because you would have duplicated processes, is the version coming from B or the one coming from C to be used : it depends on the project's (history, use, etc.).

To solve this, I think "dependency:tree" would do the trick. I'll maybe give it a try, and then send you a pull request.

I agree this is a margin case, but I think it would improve the plugin.

Regards, Benoit