- 1
- 2
Wednesday, June 23rd 2010, 9:02pm
About new desired features, for Jabaco...
Hello, Manuel,
Wanted to know if you could improve Jabaco to handle mobile development, like was mentioned before ("to support the development for mobile phone devices in Jabaco, the Jabaco compiler needs an additional compiler step: Preverify")
Please send you comments about how could Jabaco be configured to handle this, when possible too...
Regards,
Sven
i'm working on the next version and i'll reconcentrate on this project in near future. the next version will improve the design editor and things like that. suggestions and reports are very welcome in the community.
Wanted to know if you could improve Jabaco to handle mobile development, like was mentioned before ("to support the development for mobile phone devices in Jabaco, the Jabaco compiler needs an additional compiler step: Preverify")
Please send you comments about how could Jabaco be configured to handle this, when possible too...
Regards,
Sven
Wednesday, October 6th 2010, 11:11am
Sure! Just send a CR and a drafted FD to make it happen!
Truly excellent suggestions with an explanation as lucid as yours are always honoured instantaneously ;-)
I think he is referring to todo and issue databases. Perhaps we can "borrow" such modules from Eclipse?
On the other hand i would prefer the IDE to be lightweight and not as bloated as other IDE:s tend to be. Such functionality should possibly be handled outside the IDE.
Also I stand in line for a stable commercial version. What we need is not more beta features, we need a stable version so we can go commercial with the current features.
Wednesday, October 6th 2010, 1:46pm
Hi A1880, Hi Faldegast
you both mentioned the point, we really got to talk about since long ago!
I totally agree with Faldegast:
already here comes the Jabaco-Framework into play!
Tha Jabaco Framework already is *the* huge Jabaco project that can only be maintained with the massive help of the Jabaco IDE.
To stabilise and utilise the work with the Jabaco-project-file should be the starting point for development with the highest priority!
At the moment the Jabaco-Framework contains two projects into one:
* the Jabaco-Framework as is, and
* a project for testing the Jabaco framework.
so the Jabaco project file needs the ability to handle this.
Moreover the Jabaco Framework is made of
* Java and
* Jabaco sourcecode
and it would be best to make it possible to compile Java and Jabaco source together with a single compiler.
regards
OlimilO
you both mentioned the point, we really got to talk about since long ago!
I totally agree with Faldegast:
Quoted
Also I stand in line for a stable commercial version. What we need is not more beta features, we need a stable version so we can go
already here comes the Jabaco-Framework into play!
Tha Jabaco Framework already is *the* huge Jabaco project that can only be maintained with the massive help of the Jabaco IDE.
To stabilise and utilise the work with the Jabaco-project-file should be the starting point for development with the highest priority!
At the moment the Jabaco-Framework contains two projects into one:
* the Jabaco-Framework as is, and
* a project for testing the Jabaco framework.
so the Jabaco project file needs the ability to handle this.
Moreover the Jabaco Framework is made of
* Java and
* Jabaco sourcecode
and it would be best to make it possible to compile Java and Jabaco source together with a single compiler.
regards
OlimilO
Wednesday, October 6th 2010, 5:45pm
sorry, what are you talking about?
Automatic recompilation of Jabaco classes is not feasible for the time being.
Jabaco *is* already runnable by commandline.
A commandline version of the compiler is necessary
to integrate compilation in ant or make scripts
the Jabaco-compiler at Google-Code does already run by an ant-script.
But in my opinion it's simply not comfortable enough, to maintain the Jabaco-Framework in this manner
*schauder*
But OK, ... the situation is like a dragon that bites itself in his own tail
regards
OlimilO
Wednesday, October 6th 2010, 9:18pm
Ant needs a build.xml
You can find it on GoogleCode in the Jabaco-Framework-Sources here:
http://code.google.com/p/jabacoframework…ework/build.xml
the desired information can be found in this section here:
when we extract the useful informations we get:
JabacoDir\Jabaco.exe -projectpath=ProjectDir\MyJabacoProject.jba -d=BuildDir
regards
OlimilO
You can find it on GoogleCode in the Jabaco-Framework-Sources here:
http://code.google.com/p/jabacoframework…ework/build.xml
the desired information can be found in this section here:
|
Source code |
1 2 3 4 5 6 |
<!-- compile the jabaco sourcefiles -->
<echo>Compile the Jabaco sourcefiles to buildpath</echo>
<exec executable = "${jabaco.dir}/Jabaco.exe">
<arg value = "-projectpath=${framework.dir}/src/VB/Framework.jba"/>
<arg value = "-d=${build.dir}"/>
</exec>
|
when we extract the useful informations we get:
JabacoDir\Jabaco.exe -projectpath=ProjectDir\MyJabacoProject.jba -d=BuildDir
regards
OlimilO
Thursday, October 7th 2010, 2:40pm
Commandline compilation with Jabaco.exe
Thanks for this hint! 
I've written the following cmd file "build.cmd":
Compiling a project with a deliberate fault, I get a log file "build.log" in my output directory ".\classes":
Compilation stops at the first error. This is fair enough for compilation of tested components.
The error location is nicely communicated in the log file.
All in all, the commandline mode works quite well.
I've noticed that it takes several seconds to load Jabaco.exe before compilations starts.
Greetings
A1880
I've written the following cmd file "build.cmd":
|
|
Source code |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
@echo on :: we assume that the project name equals the directory name call :doit "%cd%" goto xit ::==================================================================== :doit set project=%~n1 echo %project% c:\Programme\Jabaco\Jabaco.exe -projectpath=%project%.jba -d=.\classes goto :EOF :xit |
Compiling a project with a deliberate fault, I get a log file "build.log" in my output directory ".\classes":
|
|
Source code |
1 2 3 4 5 6 7 8 9 |
2010-10-07 STATE: Please wait ... 2010-10-07 STATE: Load ... 2010-10-07 STATE: Load Projectfile: jbCompileAutomation.jba 2010-10-07 STATE: Load Sourcefile: Module1.jsrc 2010-10-07 STATE: Load Sourcefile: Module2.jsrc 2010-10-07 STATE: Load XML-View: Module1 2010-10-07 STATE: Load XML-View: Module2 2010-10-07 STATE: Init GUI-Editor... 2010-10-07 Compile error. Class: 'Module2' line: 4 => Function or variable not defined! |
Compilation stops at the first error. This is fair enough for compilation of tested components.
The error location is nicely communicated in the log file.
All in all, the commandline mode works quite well.
I've noticed that it takes several seconds to load Jabaco.exe before compilations starts.
Greetings
A1880
Thursday, October 7th 2010, 6:44pm
when we extract the useful informations we get:
JabacoDir\Jabaco.exe -projectpath=ProjectDir\MyJabacoProject.jba -d=BuildDir
Thanks for that info, OlimilO.
I will later have a look at it.
As you can see here:
http://www.jabaco.org/framework.html
the Jabaco-Framework does not completely compile any more. the Jabaco-source part is missing.
Currently it only don't compile with ant. The older way still works. The last revision have had only problems, because Franco addeed files, which wasn't added in the FrameworkTest.jba. So it needs only a minor change, which I have now done.
So, to compile the Framework in the old way is still possible and easy.
If you have problems to compile it, please publish here, what errors comes.
Only the ant-way don't work currently.
And now to A1880:
Would it make sense, as a workaround, to compile the framework in two or more parts and merge the resulting classes afterwards?
What do you mean with it?
Why compiling in parts. Currently there existing two steps to compile:
1. compiling the Java-sources in VBA
2. compiling the Jabaco-sources in VB
thats it.
Friday, October 8th 2010, 6:07pm
What do you think?
It sounds a little bit like Jigsaw in JDK7.
But at the end it is completely different and I think it would have more disadvantages then advantages.
The advantage:
- "This speeds up recompilation of the framework during testing."
- "Another advantage probably is the reduced amount of resources (memory, disk) to
perform a compile step."
The disadvantages:
Instead of one *.jba file to compile you have a lot of them.
This means
- if you have imported a class of the JDK in the class-browser (for example java/awt/event/WindowEvent), it is possible that it is not imported in all *.jba files. So depending on, which *.jsrc is part of which *.jba, you can call WindowEvent direct or you have to write java#awt#event#WindowEvent.
- because there are more then one *.jba files, all have to be loaded successively. This means, the first compile would need longer, then at the current situation.
- Normally you don't write a *.jsrc file in a text-editor. But if the framework is splitted, then you don't have all Jabaco-files of the framwork at once in the Jabaco IDE. Some people want a Java-source support in the Jabaco IDE to have all at the same time together. If one file can't compile, because in the other file is a bug, then its easier to change to the other file. But you want to create more project files.
- If you say "then let us create the mini *.jba projects beside the Framework.jba where still all is in it", then there is the problem to handle multiple *.jba files, which makes use of the same *.jsrc files. And so you have synchronal change some .jba files, which makes the work not easier.
I think it would be easier to write in the complete Framework everytime the full name of classes (for example "java#awt#event#WindowEvent" instead of "WindowEvent". In this case the *.jba file is not needed and it would be possible, that Manuel creates a compiler which compiles a *.jsrc file direct.
So in this case you can compile the framework file by file.Only a Makefile or Ant-file is needed, to compile the *.jsrc files in the right order.
- 1
- 2
Similar threads
-
Tips, Tricks, Samples & Tutorials »-
How to use pointer with Jabaco
(May 10th 2009, 3:37pm)
-
- General topics, questions and discussions »
-
Jabaco for Linux question
(Dec 24th 2008, 6:12am)
-
- Tips, Tricks, Samples & Tutorials »
-
How to use a simple debug class
(May 24th 2009, 12:33pm)
-
- Tips, Tricks, Samples & Tutorials »
-
How to use JavaCOMBridge (JaCoB) with Microsoft Word
(Apr 16th 2009, 10:26pm)
-
- General topics, questions and discussions »
-
New Version
(May 26th 2009, 1:55pm)