You are not logged in.

theuserbl

Intermediate

Posts: 436

Date of registration: Dec 20th 2008

  • Send private message

21

Friday, October 8th 2010, 6:20pm

Quoted

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.


I have now tested around and that is already possible:
Here an output:

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
C:\>dir z
 Volume in Laufwerk C: hat keine Bezeichnung.
 Volumeseriennummer: 54B2-287F

 Verzeichnis von C:\z

06.10.2010  21:53    <DIR>          .
06.10.2010  21:53    <DIR>          ..
06.10.2010  21:50             2.418 Form1.jsrc
06.10.2010  21:50               471 Module1.jsrc
06.10.2010  21:50            19.777 TestPrg.jba
               3 Datei(en)         22.666 Bytes
               2 Verzeichnis(se), 236.778.782.720 Bytes frei

C:\>dir z1
 Volume in Laufwerk C: hat keine Bezeichnung.
 Volumeseriennummer: 54B2-287F

 Verzeichnis von C:\z1

08.10.2010  18:18    <DIR>          .
08.10.2010  18:18    <DIR>          ..
               0 Datei(en)              0 Bytes
               2 Verzeichnis(se), 236.778.782.720 Bytes frei

C:\>dir z2
 Volume in Laufwerk C: hat keine Bezeichnung.
 Volumeseriennummer: 54B2-287F

 Verzeichnis von C:\z2

08.10.2010  18:18    <DIR>          .
08.10.2010  18:18    <DIR>          ..
               0 Datei(en)              0 Bytes
               2 Verzeichnis(se), 236.778.782.720 Bytes frei

C:\>C:\Programme\Jabaco\Jabaco.exe -projectpath=C:\z\TestPrg.jba -d=C:\z1

C:\>C:\Programme\Jabaco\Jabaco.exe -projectpath=C:\z\Form1.jsrc -d=C:\z2

C:\>dir z1
 Volume in Laufwerk C: hat keine Bezeichnung.
 Volumeseriennummer: 54B2-287F

 Verzeichnis von C:\z1

08.10.2010  18:19    <DIR>          .
08.10.2010  18:19    <DIR>          ..
08.10.2010  18:19               333 build.log
08.10.2010  18:19               459 Form1$CommandButton.class
08.10.2010  18:19             2.529 Form1.class
08.10.2010  18:19               890 Module1.class
08.10.2010  18:19               568 Resources.class
               5 Datei(en)          4.779 Bytes
               2 Verzeichnis(se), 236.778.762.240 Bytes frei

C:\>dir z2
 Volume in Laufwerk C: hat keine Bezeichnung.
 Volumeseriennummer: 54B2-287F

 Verzeichnis von C:\z2

08.10.2010  18:19    <DIR>          .
08.10.2010  18:19    <DIR>          ..
08.10.2010  18:19                63 build.log
08.10.2010  18:19               459 Form1$CommandButton.class
08.10.2010  18:19             2.529 Form1.class
08.10.2010  18:19               568 Resources.class
               4 Datei(en)          3.619 Bytes
               2 Verzeichnis(se), 236.778.762.240 Bytes frei

C:\>


So it is already possible to compile only a single file.

theuserbl

Intermediate

Posts: 436

Date of registration: Dec 20th 2008

  • Send private message

22

Friday, October 8th 2010, 11:41pm

JabacoDir\Jabaco.exe -projectpath=ProjectDir\MyJabacoProject.jba -d=BuildDir


I have looked now a little bit more at Jabaco and find more command line options (I hope that are now all):

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Jabaco.exe [-projectpath | -d | -log | -jabacoframework | -javaframework]
  -projectpath : The name of the main project file. It can be either
          a .jba or .jsrc file
  -d : The directory where the binary .class files will be created
  -log : The directory where the logfile "build.log" will be created.
          If it is not set, then the logfile will be in the directory which
          was set with the  "-d" option
  -jabacoframework : Jar-Archive of the Jabaco Framework.
          If it is not set, it is Jabaco.jar in the Jabaco-directory.
  -javaframework : Jar-Archive of the Java Framework.
          If it is not set, it is the default rt.jar in the Java-directory.

To run _not_ the IDE, it is needed that "-projectpath" and
 "-d" are set.
The other options can also be used for the IDE. If you want to use
 an other Jabaco Framework File  you can set it
 with "-jabacoframework" and the IDE will use it.

This post has been edited 1 times, last edit by "theuserbl" (Oct 8th 2010, 11:47pm)


A1880

Intermediate

  • "A1880" is male

Posts: 500

Date of registration: Jan 1st 2009

Location: Hanover, Germany

Occupation: Software Engineer

Hobbies: Hilbert Curves

  • Send private message

23

Saturday, October 9th 2010, 6:56pm

There might be still a misunderstanding.

I am talking of a small number of two, three or four *.jba projects.
Each of them should be compiled independently.
Afterward, the resulting *.class files are copied together in one central *.jar file.
So, the resulting framework looks like today.

In case of a change in a given class, only the respective *.jba has to be recompiled
and the merge repeated. This should always be faster than a complete recompile of today.

Greetings

A1880

Faldegast

Beginner

Posts: 25

Date of registration: Oct 6th 2009

  • Send private message

24

Thursday, October 21st 2010, 3:09pm

Let me clarify what i mean with a stable version.

I mean a version that does not get patched in a way that breaks current code. That makes me able to ship binaries and promise that they will work with future versions of the runtimes.

I have tested the current version of the framework and it is good enough to create real products. But i have to be able to promise the customer that i it is stable (that it works now and forever).

So with Jabaco FrameWork i need a fork that does not get touched unless patches that we really need, and that does not break applications compiled for the previous version.

And for the IDE and compiler i need mostly the same.

Yes new features is and better VB6 compatibility is great. But nothing that cant wait. I can use a branch of the current version to create real commercial grade applications, that does not break when the runtime is upgraded. And if it ever breaks that should be regarded as a critical bug to fix and roll out asap...

Faldegast

Beginner

Posts: 25

Date of registration: Oct 6th 2009

  • Send private message

25

Wednesday, November 17th 2010, 2:57am

I was really hoping that Jabaco would become a solution to the VB problem.

However the vast delays in getting a supported version have made most of my costumers chose full Java, C# or VB.NET ports instead.

There are still customers waiting for a solution that will probably wait until they have to migrate from XP.

Jabaco has been quite useful in getting the VB code running on Java, but in order to offer commercial-grade support i have had to port the code Java, which is a fully supported language.

Rate this thread
WoltLab Burning Board