Dusan Zatkovsky wrote:
On Monday 18 of January 2010 08:55:36 you wrote:

  
Hmm, in my opinion is that the binaries that "belongs" to the Qt system
should reside there. However, when building binary releases for the
"public" then you are free to bundle all you want, as we do for assistant,
designer, etc.

I guess what you should do is to make a new binary release for one of the
platforms. Based on the work from Bruno, I have made a script that packages
the necessary components from Qt/QtJambi src compile to a binary release,
you may have a look on this and modify it with the necessary changes.
    

Hmm, maybe you misunderstood thinks ( or maybe not ).
  
Maybe, I'm really quite new to maven.
My qtjambi maven stuff consists from 2 things:

1.	mavenized libraries

	It is qtjambi-VERSION.jar and qtjambi-PLATFORM-VERSION.jar what we are
	working on now.
	This should ( and will ) be created together with qtjambi build.


But my email was about:

2.	qtjambi maven plugin

	Which is maven plugin used to build ( not run ) maven qtjambi applications.
	It requires qt and qtjambi tools such as juic, lupdate, lrelease and some qt
	libs ( core, xml ) to work, one set for each supported platform.
  
Do you need the explicit source of QtJambi to be able to build maven qtjambi
applications?
	
	Yes, that tools should be mavenized together with qtjambi build, but
	this time, when no rock-stable and universal build scripts exists,
	it is impossible to release it and it is much easier to copy that 5
	files manually into source tree. This is the reason why I added all required
	platform binaries manually into repo ( but one maven artifact for each
	platform )
  
Well, there actually do exist a start of a build script that transforms source -> binary
package. If you pull the latest version of the community-port-to-4_6 (master branch)
from the repo, then you will find my script in scripts/packager_linux.sh

I suggest we make a similar script for Windows, Mac OsX already have one, right Bruno?

So i have 3 feasible solutions:

1.	I should continue tracking my sources in private repo until qtjambi 4.6
	will not be stable and release only "binaries" ( maven artifacts ) somewhere.

2.	The same as 1, but I should create separate project on sf.net for this.

3.	I'll wait until 4.6 will be released ( and build scripts will be created
	and stable ) and blahblahblah, but this still need a much of work.


I don't know what is the best, maybe it should be no.2, because sources will 
be public ( instead of 1 ), it will be released shortly ( instead of 3 ) and 
anyone should contribute.

  
I think the optimum solution would be that we stick to the same project, much
easier for a person that want to test the technology. But if you need to isolate it first
for testing purposes before you integrate it, that's fine.

Helge

_______________________________________________
Qt-jambi-interest mailing list
[email protected]
http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest

Reply via email to