[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-mtj-dev] Support for flexible build process
|
Max,
I need to spend a lot more time digesting this note and your project.
With that said, my early reaction is that this is not necessarily the
way that I would want to see MTJ behave. In my mind, one of the
strengths in Eclipse is its incremental builder architecture and its
ability to allow you to (mostly) set up your project structure as you
wish. If I'm understanding BitCruncher correctly, it seems more like a
very cool Antenna-like tool with lots of excellent added features. I
would think we could take lots of concepts and possibly code from from
BitCruncher, but I want to make sure that we maintain the Eclipse
strengths and "feel" as much as possible in regards to the builder.
Those are just my initial quick thoughts without a lot of digging.
Please feel free to set me straight on anything that I'm interpreting
incorrectly.
Thanks,
Craig
EclipseME Project Lead/MTJ Project Member
Max Gilead wrote:
Hello!
I'm an author of a BitCruncher J2ME build system
(http://sourceforge.net/projects/bitcruncher). When I was starting it
I was aware of other efforts in this area but none of them appeared to
be flexible or mature enough for porting needs so I decided to start a
new project. That turned out to be a good decision since the tool
became functional quickly and does exactly what needs to be done. In
its current state BitCruncher is basically feature-complete for what I
had planned for version 1.0 but still there are a number of future
goals to achieve :) Most (or all) of them seems to be compatible with
MTJ goals so I'd like to discuss with you features we need before
volunteering for a project.
Let me describe what BitCruncher is. It's is a build system for J2ME
applications. It supports CLDC with MIDP and DoJa profiles. Project
goal is to be a flexible, easy to customize and easy to work with.
Its directory structure is as below:
build/ - files from each build step are kept here easier debugging.
dist/ - final builds
profiles/ - device profiles. Each profile contains device descriptor
(CLDC/MIDP/DoJa version, used resources, deployment data etc),
preprocessor directives, additional Manifest/Jad/Jam entries,
device-specific source code and resource files.
res/ - base resources. Res/ directory is split into user-defined
groups (by default: base, gfx, lang and sound). Inside each group
there are directories with actual files (eg. res/gfx/128x,
res/gfx/176x etc).
src/ - base source code (with optional parts present in device- and
resource part-specific directories)
A short list of features:
- J2ME projects have to deal with device incompatibilities. For this
reason BitCruncher supports three basic ways of configuring source
code: interfaces (each device profile and resource part may contain
its own Java files; strongly preferred approach), Java preprocessor
(J2MEPolish, compatible with Antenna/NetBeans), C preprocessor (GNU
CPP); preprocessors can process a build-time copy or, at user request,
an editable copy of source code
- can deploy built applications over SSH, IrDA and Bluetooth (standard
and Nokia); FTP with WML/HTML generation is planned
- supported compilers: javac and ecj; configurable character encoding
- contains custom ZIP optimization tool
- each device profile can define its own external libraries (JSRs and
vendor-specific)
- can run applications in MIDP and DoJa emulators
- experimental Eclipse plugin featuring Java preprocessor
- each device profile can be built in a number of language versions
- can build all device profiles in all language versions in one step
- multiple applications can be present in one midlet
- custom jar naming
- each device profile can have a separate version number
- runs on Linux and Windows (some features unavailable on Windows yet,
like IrDA and Bluetooth deployment)
- can generate Manifest, JAD and JAM files with custom entries
- can generate DoJa scratchpad files with Java class describing its
contents
- can build/run applications in normal and remote debugging mode
- each device profile can use an own obfuscator configuration
- fast-fail system -- execution is terminated immediately after
encountering an error (that may sound obvious but is not ;) )
BitCruncher is very flexible system. It's been used while porting a
number of commercial titles with wildly different styles of coding and
resource organization so I'm fairly confident it can handle (as I'm
writing in README) all reasonable and most unreasonably structured
projects :)
I don't want to reinvent the wheel and would be happy to join MTJ
project (of course if you all think I could be useful :) ) but I
believe first thing is to check if we're going in the same direction.
BitCruncher is a tool written to address real-life needs of a porting
company. Features I described above are proven while working with
titles from major game developers and publishers. As such it doesn't
contain any (known ;) ) useless bells and whistles. Do you think that
what I wrote above is what MTJ can and should support? Of course I'm
ready to do the coding to make it happen -- question is about
compatibility of our visions :)
Regards,
Max Gilead
------------------------------------------------------------------------
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
