Hi,Yes, the answers you put are correct.When a new version of the code generator is released, the build.properties gets changed. So the value in build.properties only reflects the codegeneration engine version, not the version of the source code. The codegenerator engine can remain unchanged between EA and GA, like in this case.We could consider changing the version even if there are no changes, but there could be implications. In general we try to not deliver a codegenerator when not needed, since all the files has to be regenerated.Now when this value is used by this Developer Studio check, in combination with downloading the source code files, it becomes more visible, but the value is really related to our internal process.Best Regards Andreas
This is a tool only check that was introduced to remind about the target version property setting on the project.There is one check that checks the project target version against the build.properties file in fndbas, and one check that checks the project target version against the database.For the database, the Service update level is not checked, and it seems we need to ease up on that also for the check against the fndbas folder setting, since it is not updated if the codegenerator has not changed between 2 service updates, eg, 22R2-EA and 22R2-GA.In the meantime, if this check is incorrect, or bothering you in anyway, you can disable it in:Tools -> Options -> IFS Options -> Target Version CheckBest Regards Andreas
Hi,LAA is not supported in java files, but if this is a new projection no custom/additional layer is needed. I think this also applies if this is an existing projection with added fragments in customization, and no previous java impl file exists. A java impl file can just be added.The java impl file has to be there when the codegenerator runs, because it triggers the creation of the interface and abstract class needed to forward the java calls to the included fragment java implementation. A java impl file without any implementation should do, but it has to be committed. The server should find the class by itself.Best Regards Andreas
Ok, just to comment on the input: You should not have to add any “include fragment” lines. When you customize a fragment the layer concept should merge the core fragment parts with the custom fragment parts, so all includes from core should be kept. The override of a group should work, it does when I test. It could be that you placed it in an incorrect place in the fragment file. The fragment is divided in 2 parts, client functionality and projection functionality, and the syntax which is supported is different. The client parts has to be under the divider: ----------------------------- CLIENT FRAGMENTS ------------------------------ Anyway, to sum it up, this functionality should work by design, so problems in this area should be considered as bugs.
Hi, There is too little information here to be able to know, is it possible to provide more details? Are you getting the error when generating the code, or deploying it? Can the error be from the newly added code? If the customized file is added empty, or with just a small modification, does it generate an error then?
Hi, It should be possible by design to do this already. Just choose to Customize This on the fragment and override/overtake the item you are interested in.
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
