Hi I have source code that ant builds into a javaSE jar, and we ship that, ant also at the same time builds the source for a JavaME project.
which I currently then open netbeans and let it compile the jars for JavaME, i'd like to do this last bit in ant and wondered if its possible and if so how?
Sure, but you'll have to add tasks for pre-verification etc.
Have a look at
Antenna An Ant-to-End Solution For Wireless Java
User's Guide for J2ME Ant Tasks
From the webpage of Antenna:
Antenna provides a set of Ant tasks suitable for developing wireless Java applications targeted at the Mobile Information Device Profile (MIDP). With Antenna, you can compile, preverify, package, obfuscate, and run your MIDP applications (aka MIDlets), manipulate Java Application Descriptor (JAD) files, as well as convert JAR files to PRC files designed to run on the MIDP for PalmOS implementations from Sun and IBM.
Related
electron-builder and its electron-updater dictate that program must have semver
https://github.com/electron-userland/electron-builder/blob/v23.0.3/packages/electron-updater/src/AppUpdater.ts#L331
electron's default autoUpdates does not support linux
electron-updater will only work on macOS if code is signed
yet golang's .mod and clojure's deps.edn - clearly show that using source directly without intermidiary pa like npm or maven is a growing trend
question
how to release electron program as files - what electron-builder calls dir and zip targets?
how to auto-update by simply looking at github tags and downloading the new version of files and replacing them?
does such file-based no-singing any-url solution already exist?
change heavy electron for light entirely jvm clojure .jar dekstop programs with swing ui
one .jar for all operating systems by design
lack of powerful web ui is not an issue - as programs do not need the most powerful ui - swing is plenty to connect user to data and to render on canvas
I'm new to J2ME application development, I want to write an ANT script to build and run the application in the emulator. Assuming that I'm going to use JAVA_ME_Platform_SDK,
My main doubt is how do I can create the JAD file using ANT
apart from other building activities.
You can use Antenna http://antenna.sourceforge.net/.
"There are several sample build.xml files in the "samples" subdirectory of the Antenna source distribution. These files show how to build the default demo MIDlets contained in the Wireless Toolkit and some others. Running the samples is a good way to test your setup as well as a good starting point for your own build.xml files."
Finally I wrote the script to all the J2ME processes. For creating the JAD I've written the follwoing
**<target name="makeJAD">
<length file="${prototype}/bin/${PROGRAM_NAME}.jar" property="jarSize"/>
<echo file="${prototype}/bin/${PROGRAM_NAME}.jad">MIDlet-Jar-Size: ${jarSize}
MIDlet-1: ${PROGRAM_NAME},,${PACKAGE_NAME}.${PROGRAM_NAME}
MIDlet-Jar-URL: ${PROGRAM_NAME}.jar
MIDlet-Name: ${MIDLET_NAME}
MIDlet-Vendor: ${MIDLET_VENDOR}
MicroEdition-Configuration: ${CONFIG}
MicroEdition-Profile: ${PROFILE}
MIDlet-Version: ${MIDLET_VERSION}
</echo>
</target>**
Apache Maven is a very popular build and dependency management tool in the Java open source ecosphere. I did some tests to find out if it can handle compiled Free Pascal / Delphi units and found it easy to implement. So it would be possible to
release open source libraries precompiled for Free Pascal (or Delphi) in a public Maven repository
include metadata in this repository which contains dependency information
use Maven on the command line to download the open source library from the public repository, and automatically resolve all dependencies
local repositories, working as proxies, could be used to cache frequently used binaries
automatic checksum generation and verification (provided by Maven) would reduce the risk of downloading corrupted binaries
source code and even documentation files could be provided with the binaries
binaries can be provided with or without debug information
continuous integration servers like Hudson, TeamCity or CruiseControl can be used to build projects whenever changes have been submitted to the source control system and notify developers about build errors
This way of dependency management could be very beneficial for open source projects which use many third party libraries with complex dependencies. It would avoid typical conflicts caused by using wrong versions.
For the developer, the workflow for editing and building a project would be reduced to a minimum:
checkout the project source from internal version control system
edit source file(s)
run mvn package to automatically download all required third party libraries (precompiled units) if they are not yet in the workstation's local repository
compile and run
The only additional file for Apache Maven which is required in the project folder is the POM.XML file containing the project information.
Edit: while Maven is usable for some of the required tasks, implementing a solution like Maven in native Free Pascal would have some advantages: no Java SDK required, support for all development platforms where Free Pascal is available, maintenance and plugin development in Pascal.
Usage of a Maven-like tool would not be helpful for open source projects only - commercial projects could access and use the artifacts in public Maven repositories in the same way as well.
Maven features are listed at http://maven.apache.org/maven-features.html
Update:
one use case could be the build of Lazarus, where Maven would download all required libraries and invoke the compiler with the necessary build path arguments. Changes in the dependencies on lower levels would be propagated automatically up to the parent build.
Possible benefits:
less time needed to set up a new work
station, no manual installation of
third party libraries required
less errors caused by wrong library
versions, detection of version
conflicts (for example if two
libraries depend on different
versions of a third library)
artifacts which are created inhouse
can be added to the local maven
repository and shared between
developers and project, central
storage of all artifacts with
metadata
builds are reproducible, just by
using the same source and project
metadata file (pom.xml)
can reduce development time and
increase project stability
Update #2: FPMake
the FPMake build system for Free Pascal seems to be a tool with much potential, in many details it is quite similar to Maven:
FPMake is a pascal based build system developed for and distributed with FPC
FPMake standardizes the building by defining some limits like standard directories
the command fppkg <packagename> will look in a database for the package, extract it, and then compile fpmake.pp and run it
it has standard build targets (clean, build, install, ...)
it can create a 'manifest' file suitable for import into a repository (like mvn deploy or mvn install), the manifest is an XML file which looks very similar to a pom.xml in Maven:
FPMake manifest file:
<packages>
<package name="my-package">
<version major="0" minor="7" micro="6" build="1"/>
<filename>my-package-0.7.6-1.zip</filename>
<author>my name</author>
<license>GPL</license>
<homepageurl>http://www.freepascal.org/</homepageurl>
<email>myname#freepascal.org</email>
<description>this is the package description</description>
<dependencies>
<dependency>
<package packagename="rtl"/>
</dependency>
</dependencies>
</package>
</packages>
Freepascal has been working on a package system of its own in a cross between apt-get and freebsd ports style. (download source/build/install automatically), called fppkg.
However work has stalled. People investing time are the bottleneck, not people wanting to choose tools.
As far as Maven goes, I don't like auxilary tools that need installation of huge external runtimes. It might be fine for a big major app (like Open Office), but not for an util.
I also prefer a tool that is designed to the FPC reality and workflow.
Documentation tools, build tools, download systems, testsuite systems are already all there, it just need a person that dedicates a lot of time into it to make it happen.
Some typical problems when introducing a new technology in a project as FPC, and why it has a tendency to make its own tools:
need to train 20+ committers in parttime.
The only COMMON programming language you can assume is Free Pascal. Even Delphi inner workings can't be taken for granted to be known (many committers came directly to FPC or even still via TP or a Mac Pascal)
Obviously that makes something with plugins in a different language annoying.
Bash script is a close second. (g)make third, but already a magnitude less.
All servers are *nix-like (FreeBSD, OS X, Linux), but not all run Apache. (e.g. my FreeBSD mirror runs XSHTTPD)
somebody most knowledgable must be dedicated maintainer for a long time. Fix problems, update/ do migrations etc. Perferably more than one for obvious reasons.
a major pain are Linux distributions (and FreeBSD to a lesser degree), most maintainers of *nix packages are not capable of more than "./configure;make;make install", and must be spoonfed with a near buildable repository and auxilary files.
In-distribution packaging of FPC/Lazarus has always been important, and is still increasing
All distributions have their own special rules about metadata, depedancies, and how sources must be published. Particularly Debian/Ubuntu is very bureaucratic and slow.
Most don't like third party auto-installers on top of their systems (since that bypasses their dependancy control)
This all leads to the effective practice that own tools in Pascal with minimal scripting work best. Some tools used:
Gmake is mainly used to parameterise the build process on a per directory level, a successor, fpcmake (not really a make derivative despite the name) has begun, but the migration hasn't completed.
Latex and a latex to html conversion (tex4ht, but debian uses hevea) are used in the documentation building (the non library documentation)
The community site (netscape community server which uses TCL scripting, a heavy complex application server) has been a trouble ever since it started, but specially lately since the maintainer became less active.
Mantis has been a problem (specially the email module would crash or lame the server due to the volume), but it has been whipped into shape during successive updates and hard work of several lazarus devels. Currently it is a decent workhorse.
lazarus.freepascal.org PHPBB forum OTOH is relatively painless since a lot of younger people know how to deal with it.
The same goes for subversions (though the more advanced scale needs some adjusting, not everybody is deep into the ins and outs of mergetracking)
If somebody was really serious about Maven, I usually would ask him:
to CRITICIALLY investigate the use for the project. In a very concrete way, with schedule and time estimates. Birds-eye level "everything's possible" overviews are essentialy worthless.
Give some thought on future change of used technologies. Every technology is eventually replaced, even the in-house ones, in 18 year+ projects. A new technology must not make migrations of other infrastructural components hard or involved. The new technology to end all new technologies doesn't exist.
Make a migration plan. Migration is often underrated and underestimated.
And in the end, there is always the 1000000 Euro question, who will do the daily maintenance?
Keep in mind that in a company you just kick the person responsible for the application server. But in an informal environment this is way harder, specially long term, since people's lives, occupations and time spent on the project vary.
Sounds like an interesting plan, but the Delphi community (and FPC even more so, I'd imagine!) values libraries as source far more than precompiled libraries. The general consensus is that anyone who uses a binary-only library is a fool, for two reasons: You can't fix any bugs you find in it, and compiler changes will break compatibility.
After a recent juggling with our ant scripts I've started to wonder if something better is possible.
I need a builder that will know to recompile all required .java files for me.
For ex. for this structure
public class A { ]
public class B extends A {}
public class C {
B b;
}
For: Compile('C') Will know to compile A, B, C.
For: B changed, Compile('C') will know to recompile just B.
I know of several alternatives, Ivy which seems like an extension of ant which is our current java builder. Scons which we are currently using for building C++ code, scons is excellent in doing the above described behavior for C code. Then there are reports of Maven being almost but not quite there.
What would you suggest? What tools are you using Free Software / Commercial for you build system?
Thank you,
Maxim.
Ant, with 'depend' task and with 'closure' option turned on
'make', from IDEA ide
None of ivy, scons or maven will help you with your problem as stated.
What do you mean by "for Compile('C')"? I don't think this is what you have in your ant file.
For this case, Ant should be working as desired: you have described its default behaviour. In the same javac element, Ant will only recompile changed classes. See the Ant manual entry for the javac task, especially the 'includeDestClasses' attribute.
You should probably post an example ant file that you are finding inadequate.
maven, both for my personal and my commercial products
In your question you describe inter-class dependencies. Most build systems, in particular Maven, are aimed more at inter-project dependencies. I believe most systems just recompile all the classes in a project and most of the benefits of these build systems is in building as few projects as possible.
Both Maven and Ivy will allow you to easily specify both external and internal dependencies of your project, including which version of the project you depend on. They will both also automatically download external libraries (such as apache commons) to your local machine as part of the build process if they are not already locally cached, saving a lot of work manually downloading and organizing third party jar files.
Ivy is an extension of ant, like you mention. I recommend Maven. It is a convention oriented build system that I've used successfully and feel is quite mature. Maven requires far less up front effort to start using and is quite extensible.
I am using JDom jar and I want to add to my blackberry project. I am using eclipse plugins for blacberry. while building blackberry app from eclipse the error is displayed on the console as
"JDOMAbout$info:error!missing stack map #label.... "
rapc falied for the project along with this several warnings are also displayed ...so any body have came across this ?
The stack map is part of what's generated when a jar file is preverified. Sounds like your jar is not J2ME ready. Assuming it's compatible with J2ME, the standard way is to create a .cod file from the .jar, and reference that in your project. Unfortunately you can't do that with the Eclipse plugin, but once you have the .cod, you can reference it in your Eclipse project.
You have to create a Blackberry archive or library project (or whatever it's called) and add your library to that, then reference it from your application project. You may or may not have to use the Blackberry JDE to do some hackery with the jdp file as well, but I can assure it works in Eclipse. We had the kSOAP library included in ours and Eclipse would 'build' it with rapc and generate the proper files (you sort of have to do it manually, by telling the project to build).
I unfortunately don't have an environment to check things right now, but the basic idea was have a second project, include the jar, and then reference that.
All that, and the jar has to be J2ME compatible.
Maybe You can find something useful and more J2ME friendly in kDom package of kXML project
Tutorial: How To Use 3rd Party Libraries in your Applications