Giters

larshp / abapmerge

Merge ABAP classes/interfaces/INCLUDEs into single file

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support for dependencies

sbcgua opened this issue · comments

commented

Related to abapGit/abapGit#2236

Proposed logic:

  • clone .abapgit dependencies in a special folder e.g. .abapmerge_libs or .abapmerge_modules or .abapmerge_dependencies
  • abapmerge probably should analyse .abapgit of libs to identify source root
  • abapmerge must know which parts to include (not all of them). The idea is to add it directly to the code with pragmas. But the problem is that it may be include or class or ??? (what else ?)
    • includes can be marked in the same line e.g. include zblahblah_from_another_proj. "@@abapmerge lib
    • classes should be marked explicitely e.g. "@@abapmerge lib_class zfoo_class or "@@abapmerge lib zfoo_class.clas (as there may be interfaces, so the extension will explain)
    • in future, ideally, abapmerge can use abaplint (as a parser) to identify external includes/classes automatically and search for them in libs

P.S. currently pragma include is used for JS/CSS. I think it would fit better for the dependencies. And for JS/CSS pragma can be renamed to inline. Hopefully it is safe ... hopefully noone uses abapmerge yet except AG ... or maybe stick with lib, but I would still rename current include to inline to avoid confusion

commented

which parts to include: why? currently abapmerge merges everything, guess it should be the same with dependencies?

commented

I can use just one util class. Or I can include functionality but don't what to include unit tests. Or the package can contain an example-of-usage program. It's just from the top of my head - for sure there can be more scenarios. For sure not all.

I actually think that including all for the main package is also too harsh, but don't have a case yet :) It will certainly come if abapmerge is more widely used

commented

just rm zfile.prog.abap before running abapmerge, with pragmas the source repo will anyhow have to know the objects from the dependency in order to add pragmas

commented
  • there may be more file to remove than to add
  • there may be changes to external library which I don't control - it will be an ordeal to support

But why ? Merging all does not have any benefits, or ? This is just a support heuristic to validate the integrity and quite indirect one by the way - I would better run abaplint over the final file.

Another option is to add abapmerge.json for config of includes. But currently I feel that in-code reference should be better.