Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

updating non-abapGit & non-SAPLink installation of abap2xlsx

abo
Active Contributor
0 Kudos

Recently, there was a question regarding the update of an abap2xlsx installation originally made with SAPLink. My recommendation, there, was to clear out the whole package and reinstall. In the end, local modifications aside, you'd still be getting the whole shebang so that's ok.

Now I am facing a somewhat similar problem, but this this abap2xlsx belongs to a subpackage of ZMONSTERS, from bfeeb8ed7fa64a7d95efc21f74a8c135 's book "ABAP to the Future". As far as I know, no one is using that package at the moment.

Should I...

  1. clear out the whole main package? (that would take a while and it isn't really necessary)
  2. clear out only the subpackage and then install as local package?
  3. adopt ZMONSTERS_C10_ABAPS2XLSX as abapGit package name?

Just in case someone is interested in using those examples in the future, I'd rather not go route no; also no. 3 is out, the installation is so old that it predates the split between main library and demo repositories so a separate local demo package would be needed.

What are your thoughts on this?

1 ACCEPTED SOLUTION

hardyp180
Active Contributor

From edition four onwards in my code samples I use APACK to enforce a clear separation between my Z code and separate projects like ABAP2XLSX. That is my code is in my repository and the ABAP2XLSX code is in its official repository, and in my code in one of my packages I declare a dependency on the ABAP2XLSX repository.

In earlier editions I often had the ABAP2XLSX code in my repository and in one of my packages hence the problem above. Presumably the way forward is to change the package of the existing ABAP2XLSX code in your system to the same package name(s) as on the official ABAP2XLSX repository and then use ABAPGIT to bring ABAP2XLSX up to date.

4 REPLIES 4

Jelena
Active Contributor

Maybe bfeeb8ed7fa64a7d95efc21f74a8c135 has some answers. 🙂

Sorry, I'm not quite clear what exactly is the issue and what are you trying to achieve as a result... Is the problem that someone created the whole bunch of separate ZMONSTER... packages instead of just having one with subpackages? Are you wanting to synchronize all these "monsters" with GitHub?

I'd definitely keep all this stuff in a single local package instead of multiple but not sure I understand the rest of the question...

abo
Active Contributor
0 Kudos

I'd like to update abap2xlsx and leave the rest alone as much as possible. I guess the original transport came with the book, you're right that only Paul knows 😄

(also, the current version of abap2xlsx is split in two repos, library and demos, so two packages are required)

hardyp180
Active Contributor

From edition four onwards in my code samples I use APACK to enforce a clear separation between my Z code and separate projects like ABAP2XLSX. That is my code is in my repository and the ABAP2XLSX code is in its official repository, and in my code in one of my packages I declare a dependency on the ABAP2XLSX repository.

In earlier editions I often had the ABAP2XLSX code in my repository and in one of my packages hence the problem above. Presumably the way forward is to change the package of the existing ABAP2XLSX code in your system to the same package name(s) as on the official ABAP2XLSX repository and then use ABAPGIT to bring ABAP2XLSX up to date.

abo
Active Contributor
0 Kudos

Good idea, it had not occurred to me to change the package before trying to upgrade!

Also, please be aware that we got rid of APACK in abap2xlsx: it was a short-lived experiment 😄