Josh Stratton wrote: > I've been using the 4.5 32-bit linux builds in the maven repository, > but recently heard there's an QGLFormat function in 4.7 to get a 3.2 > profile for the QGLWidget. Looking at > http://qt-jambi.org/maven2/net/sf/qtjambi/qtjambi-base-linux32/ it > looks like 4.7 hasn't quite made it into the repositories. Is there a > timetable for this to happen?
The existing Maven artifacts have been contributed adhoc by volunteers overtime and there is a bit of inconstancy between them, due to different people creating then on different systems and not all volunteers have access/interest in all platforms. It is possible for you to build QtJambi and then build your own Maven artifacts (that you could publish to your own repository, check out the maven sub-dir in the main project https://qt.gitorious.org/qt-jambi/qtjambi-community ) I am currently working on a number of changes to reorganise the entire project to facilitate Maven and better release-engineering. It is hoped that the entire QtJambi project will be a collection of Maven projects soon and this will mean that QtJambi can be built, consumed and updated via Maven. This will allow: * One command building and releasing (from a suitably setup system) * End the notion that users need to build QtJambi itself to use an recent C++ Qt version. * To allow the entire collection of QtJambi projects to be loaded in a Maven capable Java IDE so it is possible to work on the QtJambi project itself in this way. * Being IDE friendly (but largely agnostic, since we are to use the Maven paragidm and convention) I can envisage larger contributions * QtJambi to be more modular (possibility to only consume the APIs you use/need in your project). This should at least be tracking the proposed changed to C++ Qt itself in this regard. * To unify the downloads across all platforms (always receiving exactly the same version, at the same time and always release the same formats QtJambi users are used to). * To unify the project source. If QtJambi itself is Maven then those people wishing to get stuck into contributing to it will already be familiar with the conventions being used. So more patches can be received by the project. * To allow Maven artifact attachment, such as the source-code and JavaDoc so debugging and content-assist just works inside an IDE even when stepping through QtJambi code. * It is hoped the awt-bridge will be brought into this scheme (currently a separate gitorious project). * It is hoped to revive (or create) some kind of eclipse integration into a maintainable project. * The ability to create a number of separate projects for such things as archetypes, examples, unit-testing, eclipse all under the same umbrella. There are just too many advantages that I can see to not do this. Even if some parts of the conversion are a little tricky. It is possible to view the project on this at the git repo https://qt.gitorious.org/qt-jambi/qtjambi-community-maven but it is _NOT_ recommend you consider it at this time, as the main function of the git repo is to allow me to share, test and query my changes with the existing developers involved with QtJambi to solicit specific feedback. This repo has only existed for around 2 weeks. At some point in the future I shall declare the whole set of changes to be a viable path for the QtJambi project to migrate and work through the issues/concerns of QtJambi contributors with whom want to make input. Unfortunately there is no timescale since the work is being carried out during spare time. But to provide some ideas of the work done to build up to this. The months of Jan through Mar this year have been spent getting suitable resources to allow consistent builds on all platforms I intend to make releases for: * Linux 32bit (glibc/gcc) * Linux 64bit (glibc/gcc) * Windows 32bit (MSVC2010) * Windows 64bit (MSVC2010) * Windows 32bit (mingw) * Windows 64bit (mingw-w64) * Mac OS X (intel, 10.5 & 10.6) * Mac OS X (universal) This has resulted in some patches to Qt itself and some to OpenSSL also the setup of a mechanism I can build a Qt SDK (for each platform listed above) which is then used to build QtJambi. Also MSVC2010 is not yet a first class citizen in the Qt ecosystem and the mingw-w64 compiler being intensely developed each day. All in all I guess I must have compiled Qt over 200 times, much of this to sort out the automation of that aspect. So now my attention turns to QtJambi project itself over the coming months. Darryl _______________________________________________ Qt-jambi-interest mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-jambi-interest
