Jump to content
Excelsior Forums

chr1s

Members
  • Content count

    0
  • Joined

  • Last visited

Everything posted by chr1s

  1. I am trying to integrate JET compilation and packaging in our mixed Maven/Ant build environment. I have a couple of questions: 1) in .prj files, is it possible to define classpathentries for all jar files in a given dir? For example, I have a jar file with my own code and a lib dir with third party dependencies, can I just add all the jar files in that directory to the compilation classpath? This saves me some maintenance. Of course, I can generate a temporary prj file on demand, but it is easier if I can define this loop in the compiler script itself. 2) .jpn files are an altogether different story: they contain a lot of references to jar files and also a lot of hardcoded absolute paths that I wasn't able to turn into relative paths. It feels as if this file format wasn't meant to be modified manually. I noticed that when, instead of launching JetPackII from inside the Jet Control Panel, you start a new JetPackII project and give it the compiled exe, it can still generate this jpn file with information about all the jars used, even though all code from all jars are fully compiled into the exe. Apparently, all that info is already in the exe, it is not passed by the Control Panel. Therefore, is it possible to *generate* the jpn file from the .exe on the commandline? This would let me fully automate the process and be able to run it on a different machine without modifications.
  2. compilation and packaging automation

    >> There is a non-documented option that can be used for this goal. The suggested approach works perfectly! Now, my .prj file no longer contains any references to the jars, which is exactly what I want. >> May I ask you, do you plan to change the content of this directory or do you need to create it once? The contents of the dir changes over time, though not very frequently. Just a collection of tens of third party dependencies that are updated and extended now and then. Right now it is a collection of jar files that have been statically checked into our source code repository, but once we integrate the JET compilation with the rest of our Maven-based build system, the dir with dependencies is determined by that system at compile time. So the less I have to meddle with JET project files, the better. >> If you create a JetPackII project with all the paths relative to the root directory, then you will be able to build this project on any machine with the same folder structure. What modifications do you mean? I have been able to turn all paths into relative paths. "Without modifications" means that I can relocate my source code without breaking the project files. This is important as we frequently create branches of our code. Still, I make a temporary copy of the .jpn file that I remove afterwards, as xpack does alter its contents slightly (some last modification dates if I recall correctly). Also, the file contains a lot of references to the jar files that I use, so I probably have to regenerate it once my dependencies change. I see no way to update the file automatically.
  3. My application occasionally encounters an OutOfMemoryError. This is due to having to extract the full-text from arbitrary documents using third party libraries, i.e. not something that I can easily fix, just a fact of life. My application can easily recover from such OOMEs: the thread performing the extraction is killed, but right after it a lot of memory is again available. My application even contains code that measures the amount of memory that is left afterwards, in order to decide whether to inform the user about the OOME through a dialog or just log it and continue. However, my JET-compiled application always shows a dialog with the message "Uncaught Exception: Out of memory". Given that I already have code for handling OOMEs, is there any way I can suppress this dialog? I have read the discussion that led to this feature and I understand and agree with the arguments, but in my case it is a real nuisance.
  4. I invoke Thread.setDefaultUncaughtExceptionHandler, that should do it, right? FYI: the trick with catching the OutOfMemoryError inside the extraction thread worked flawlessly. These OOME's are now caught and logged and are no longer directly noticeable for the end user, all others OOME's are still caught by JET's interception mechanism and result in the error dialog. This is exactly how I want it to work.
  5. The thread does not catch that particular throwable. It currently does a "catch (Exception e)" in the Thread.run method, but OutOfMemoryError is not an Exception. I do have a Thread.UncaughtExceptionHandler registered in my main class that does handle all Throwables and that consumes the OOME when running my app in Eclipse. My assumption is therefore that JET already intervenes with this error dialog before the OOME reaches that handler, is that correct? I will try catching all throwables in the thread that is typically causing the problem.
×