I am using a UI component from J2ME Polish. I found a simple bug in the code, and want to quickly fix it but cannot find any build scripts in the download package, although source-code is included.
The problem cannot be solved by extending the class as it involves members with private access.
How should I go about fixing it? Should I simply compile the class in question with Javac or should try to locate build script in their repository?
There is no binary code for J2MEPolish UI library, because these classes are also preprocessed during your application compilation. This is why there is also no build script for J2MEPolish UI part - the resulting binary, if it compiles, would not make any sense :)
If you are using this UI class directly (there is no Polish magic involved) I would suggest to copy it into your own project, make the changes there and you should be just fine.
But there is a small issue. I'm not 100% sure, but Polish build process should be as follows: first your classes are preprocessed and then Polish classes will be preprocessed. If the UI component, that you copied into your project, will stay in the same java package, it could happen that your changes will be overwritten by buggy Polish implementation. You can check it by running the application or looking at the final java code in build directory.
If the overwriting problem happens, then you have two options - move UI class in your project into different package (I'm 99% sure this should be fine if you use it directly) or you need to modify Polish build process, so that it would preprocess Polish classes first and you could overwrite changes done by it.
/JaanusSiim
I know this question has been answered and accepted but an easier method would be to used their built in property (for any one coming here via the magic search engines)
polish.client.source=/projecthome/j2me-polish-source
which is simply a copy of their sources packaged with the installer. You can copy this into your own source tree and thus have version history of your changes.
While JaanusSiim's method might work I would not recommend it as it becomes confusing having de.enough.** packages in your own source tree I normally create a src for my personal source and a src-j2mepolish for their source files this was it is VERY explicit what I have added to the standard versions.
Related
I have two questions about cucumber frame work.
1-My .features files are not converting into feature format and showing as plan text file even though it works fine and I can run my TestRunner.
2- I have saved my all TestRunner files into a package Runner but in TestRunner file I have to give full path of my feature file in order to run TestRunner. e.g features= "Features" not working but
features="C:\Users\FourStar1\eclipse-workspace\com.freeTourTest\src\main\java\Features2\Addusers.feature"
works.
Take a careful look at the casing of your directory and package names. It's important you are consistent with these. It makes it easier to spot mistakes. Using lowercase is recommended.
Additionally tests and test resources should be put under src/test/java and src/test/resources respectively. Feature files are resources and will not be copied over target if you put them under java.
I would suggest learning the maven project layout by heart. It makes everything easier then making up your own organization.
Using the Domino/Notes API, when importing DXL design elements (for example a LotusScript agent), you have the option to either compile LotusScript code at the time of import, with DXLImporter.setCompileLotusScript(boolean flag), or leave the code uncompiled. If you leave the code uncompiled, then Domino will compile the code before first use. This is all fine with LotusScript.
Reading the API, I see no option for Java code. How can you compile Java code for use after importing from DXL programmatically?
(The question is not how you do it manually (like open every Java design element and save it to force compilation) but how it can be done programmatically)
You're going to need to do something along the lines of what the ODP to NSF compiler does https://frostillic.us/blog/thread.xsp?thread=NSF+ODP+Tooling. For obvious reasons (OSGi dependencies, Java library accessibility, builder processes etc) it's not a trivial task.
I am using Liferay 6.2 GA5 Community Edition.
Sample case I have 2 entities in my service.xml, let's say entity A & B.
When I run Service Builder then it will generate many JAVA files in my source code, and also generate JAR file located in
".\my-app\liferay-plugins-sdk-6.2\portlets\my-app-portlet\docroot\WEB-INF\lib\my-app-service.jar"
I open it with 7-zip, and I can see in package com.mycompany.myapp.model contains classes of entity A & B.
Then I try to remove entity A in service.xml, and I have removed the corresponding JAVA files generated in my source code, then I run Service Builder again, but inside my-app-service.jar, entity A is still exist.
How do I completely remove it from JAR file? because in my case, Service Builder will not remove it, although I have remove generated JAVA files manually.
ServiceBuilder is a code generator, thus it only generates new code.
If you want to get rid of the once generated code, there's a lot more than just the java classes to get rid of: Spring configuration, Hibernate configuration etc. are there as well for you to take care of. All of these will have to be deleted manually. And if the code still remains in the jar, good old ant clean (or whatever build environment you use) should get rid of the my-app-service.jar file (which you otherwise also can also just delete manually, so that it will be rebuilt next time a build process or ServiceBuilder runs)
I recommend searching for occurrences of A in all your project's files to see if you still find leftovers, because otherwise some component might complain at runtime that a declarated class can't be found.
Consider a solution has 2 projects: ProjectA and ProjectB (both are MonoTouch apps) and ProjectBase. ProjectBase contains the whole application, but Main.cs file (with the entry point) is located in ProjectA and ProjectB (which reference ProjectBase). This way, running any of A/B projects will boot up the application from ProjectBase.
Now, I want to override something for ProjectA only (it might be XIB file, image or a .NET class). Is there any way I can setup the solution so that the code and resources, produced by ProjectBase, are merged with the ones from ProjectA/ProjectB and the latter wins?
I found (probably a quirky and kinda-undefined-behavior-driven way) of overriding XIBs: I just put a XIB into ProjectA and ProjectB, name it the same as it was named in ProjectBase and them exclude it from ProjectBase. Although MonoDevelop compiles all items, it seems that the startup project's XIBs get priority, so that I see ProjectA-specific XIBs when I launch ProjectA and ProjectB-specific XIBs when I launch ProjectB. However, I am not sure it is the way it should behave, plus, from what I can see from build log, ALL projects get built yielding resources at the end.
P.S. I'm sorry if this has been asked previously, but I was not able to find the similar question on SO.
I was once trying to do this for a bunch of apps. I would have thought build order would be ProjectBase and then ProjectA, and the content copy system would be the same... Guess this means we are wrong.
You could do a few things.
A) Build your own program to copy resources which are marked for content. Would not be very hard, just need to read the .csproj files. XML parsing is easy enough in .NET. Run this program on post build. Would just have to be careful when doing builds such as to zip or to the device as I am not sure how it handles post-build events.
B) [This is what I did instead] If I expect to also make ProjectC, ProjectD ... ProjectN I instead made a program to generate my program... (Programception).
What it does, has ProjectBase, and ProjectTempalte. You enter your new project name into this program, say, "MyNewProject" and it will create the correct folder structure, write the correct csproj files, and update SLN file. ProjectTemplate has various placeholders in .csproj files like {PLACEHOLDER} which Programception would just go through and find/replace with my project name. Image files (and in your case XIB) are then only kept within ProjectA (B..C..N) unless I do not expect to try and override them in which case they would stay in ProjectBase. This is a lot easier with a XIBless application I would assume. I never use XIB's anyway.
Hope that helps!
I have noticed that lately our xpages application build/compilation time has gone drastically up. It can even take almost whole minute to clean application.
It is quite complex app with some controls (custom controls and java controls) and a lot of legacy code (js, ls, java), but similar app build in pure ecplise with the same amout of java code (which is the only part of this app that changes) cleans in less than 3 seconds ...
I have done a bit of research with rcp debug console and noticed that while cleaning there is some insane traffic that sums to 15000 transactions (and this database has only like 300 design elements that contains code at all!)
The log looks like this repeated over and over again:
...
[1240:0007-03E0] (13586-124 [14561]) OPEN_NOTE(REPC12579BB:0033C2FE-NT00003052,00400000): 0 ms. [48+17446=17494]
[1240:0007-03E0] (13587-124 [14562]) OPEN_NOTE(REPC12579BB:0033C2FE-NT00006C12,00400000): 1 ms. [48+32118=32166]
So my question is:
Does this mean that xpages builder is really badly written or maybe I do not know something?
Are you doing Project - Build or Project - Build All. If the latter and you have multiple NSFs open, then the build will run for all apps. You can close the apps in Package Explorer.
When you say there are 300 design elements, is that the number you see in the Applications Navigator? Bear in mind that's just a drop in the ocean of the actual files being built. Package Explorer will show there are additional Java and xsp-config files for each XPage and Custom Control. These are the Java classes compiled down from the XML markup you see in the XPages and Custom Control design elements. But this is not all that gets built. The server or local database cannot run .java files. It needs to run .class files compiled for the relevant platform. In addition, there are other .class files that need incorporating into the application at compile time, which can be seen by selecting Project - Properties in the Package Explorer view. If you have localization, there are still more files for each language for each XPage / Custom Control. And of course there are files like xsp.properties, an activator .java file and .class file.
The XPage builder may seem badly written because these files need creating. But it is actually very clever, because we don't need to write Java and we don't need to define all the relevant Java files the application is dependent on. We don't need to create a new XSPInput or whatever the Java classes are for the various controls. We can just drag and drop, set the properties from pretty panels which give us drop-downs or Boolean selectors etc. Without those the build time for the app after each save would be quicker, but the development time would be slower.
Its appears after all that there is a solution to build time problem - its the new Domino Designer 9. After upgrading to public beta version the build times dropped drastically (to just few seconds)!