2007/11/14, Craig Setera <craigjunk@xxxxxxxxxx>:
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.
Thanks for raising this up. In fact, one of the strenghts of BitCruncher is its ability to, well, set your project structure as you wish :) Most of the paths are fully configurable and what may be left can be easily made configurable. Also, I don't really care about how directories are named/organized as long as the necessary features are kept.
Also, BitCruncher can already reuse .class files compiled by Eclipse when building JARs.
Having said that, it's to be discussed if it would be best to keep BitCruncher as a set of Ant scripts or rewrite it as a real Java application/Eclipse plugin set. Key feature is that it must be possible to run the tool without Eclipse installed but that doesn't mean it can't be a plugin as well, right?
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.
I'm huge fan of Eclipse 'feel' so I'm all for maintaining it, as you said. What exactly do you mean with regard to JME app building process? Incremental compiling is obvious. Automatic resource assembling would be another thing. Is there anything else that you think should/could be done incrementally? I doubt obfuscation could be done this way, as such preverification and final JAR building is out as well.
Those are just my initial quick thoughts without a lot of digging.
That's ok! Thank you (and Christian) for replies.
BR,
Max
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
>
_______________________________________________
dsdp-mtj-dev mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
