~$ lessc base.less -bash: /usr/local/bin/lessc: No such file or directory ~$ sudo npm -g install less /usr/local/bin/lessc -> /usr/local/lib/node_modules/less/bin/lessc less@1.3.0 /usr/local/lib/node_modules/less ~$ lessc base.less #header { ... }Why on earth can't we do this in Java? Now, installing npm might be painful? Nope:
curl http://npmjs.org/install.sh | shIt is terribly frustrating that these javascript kiddies (kidding, node.js is very interesting!) can do this and we the enterprise Java developers can't! Something I ran into when I tried to launch my image on Amazon EC2.
At Amazon EC2 you can use a standard image with their variation of Linux. They provide one mechanism to customize the start-up to add your software, this goes through the user-data, that is specified during instance configuration. For the standard Amazon Linux image, this user data can also be a shell script that is run after the end of a reboot; the perfect place to initialize or synchronize your system. How would my user-data shell script look like in a perfect world?
#!/bin/sh jpm || (curl http://jpm4j.org/install.sh | sh) jpm libsync http://www.example.com/system/config.jpm jpm schedule --hourly mywatchdog jpm start myservice myappThis jpm (abbreviation of Just another Package Manager) command should store the files in an appropriate place, it should be able to add commands to the shell path, install services, and schedule. Obviously, all these things are different today in MacOS, Linux, IBM mainframes, Windows, and other places where Java is running. The jpm command should therefore know about these differences and act as a good guest in the host environment. For example, on the Mac it should store the repository in
/Library/Java/PackageManager
but on Linux /var/jpm
seems more appropriate. Same as user local files should be stored in Library on the Mac and not in the common Unix ~/.jpm directory. Daemons should follow the local rules and be manageable from the native management tools.It should provide the following requirements:
- Applications should not require special knowledge of the platform or jpm
- Act, look, and feel native
- Manage a local repository of jars (either apps or libs)
- Allow (limited) use without being the admin or root
- Install command line apps written in Java
- Install services/daemons written in Java
- Schedule services or apps in time
- Monitor the Java services
- Install as GUI app (with proper icon and clickable)
- Install from the web
- Support at least any system with a basic *nix shell, MacOS, and Windows
- Allow others to contribute new platforms
- Support JAR signing
- Full uninstall
- Simple & small
Peter Kriens
what type of repository does jpm use? Maven, osgi bundle repo? How does it know where to deploy? What types of artifacts does it know of?
ReplyDeleteLocal repository is file system based, same as bnd(tools) uses.
ReplyDeleteIt can make command and services out of any JAR that has a Main-Class manifest header.
Remote repository is still open but will absolutely support OSGi and maven repos.
Looks awesome!
ReplyDeleteAny chance you put it to github or somewhere so we can look, play & contribute?
I think that jpm is something way "wider" than bndtools. So I think that it would be better if it was an independent project.
Found similar problems at the opposite pole: embedded appliances using standard images. In the project I used a Debian Live boot and Deployment Admin for wrapping up my application specific stuff. But that in between stuff was the hassle - I still needed the prerequisite infrastructure added to the image - Java and OSGi.
ReplyDeleteWill jpm be Java based and require a JRE be present?
@iocanel: yes it will be on github, but it is still very immature, need a few weeks to make it presentable. So unless you really wan to spent significant time on it and help me out, wait a bit.
ReplyDelete@John: jpm will be java based. Currently I require java to be installed but can of course install it from the install script. However, nowadays Java being open source it is usually present in *nix envs.
Peter, it's clear to me that jpm is still very immature, but I don't mind having a look at something not very presentable. To be honest I don't have "significant" time, but I'd gladly spend some time playing with it, whenever you feel like sharing it.
ReplyDelete@iocanel: I learned the hard way that showing immature products often backfires, but just follow the blog and you'll see when I make it available.
ReplyDeleteHi Peter, thanks for the initiative. I make myself available to also help on that.
ReplyDeleteAre you considering to enable upgrades like apt?
Cheers
@B.B: Yes, it should grow into a full blown package manager for java. It should also start supporting full dependency management which it does not yet do.
ReplyDeleteNeat.
ReplyDeleteWhy did you start your own project (apart from it being frightfully interesting and rewarding to write); the name alludes to the other package managers you could start with and adapt/decorate, e.g. puppet, Buckminster.
@willr: jpm is focused on doing what npm does and does ... Allowing Java to be used for simple applications that are easy to combine. Puppet seems to be much more ambitious and buckminster was not in this league last time I looked (many years ago)?
ReplyDelete