I was looking checking the version of my Rubymine recently and noticed that it seems to be using a JVM provided by Jetbrains. What is the purpose of this? Why not use a JDK installed by the user?
A couple of reasons.
It allows them to have the IDEs run in a known, tested environment.
It reduces the number of environments (versions) they have to verify.
It keeps problems in a user's JVM from causing problems in their IDEs.
Related
I am a huge fan of Jetbrains "AppCode". But due to the variety of projects I have some depending on older XCode versions and others can be the latest and greatest. It's great that we can have multiple XCode installations side-by-side. But is this also possible with AppCode? I remember that back a couple of years, the EAP version could be installed side-by-side with the stable release. This would also already help, but I cant even find a separate EAP download anymore.
Anybody any tips for me?
You can use JetBrains Toolbox to install as many product versions as you like side by side with the automatic update (optional) and rollback support.
In Toolbox you can set certain product versions to stick to the specific installed version and do not offer the updates.
Major IDE versions do not share the configuration and can be even run at the same time. Minor version can be also configured to use different folders for config/plugins/caches if needed.
I used top be able to integrate a StarTeam plugin with MyEclipse using this update site URL: http://altd.borland.com/update/eclipse3.6/site.xml
But using newer versions of MyEclipse, this plugin no longer can install, I get this error:
Cannot complete the install because one or more required items could not be found.
Software being installed: StarTeam 2009 R2 Eclipse 3.6 Client 11.0.0.97v20111028-1643 (com.borland.starteam_3.6.feature.group 11.0.0.97v20111028-1643)
Missing requirement: StarTeam 2009 R2 Eclipse 3.6 Client 11.0.0.97v20111028-1643 (com.borland.starteam_3.6.feature.group 11.0.0.97v20111028-1643) requires 'org.eclipse.platform.feature.group [3.6.0,4.0.0)' but it could not be found
Does anyone have the same problem and found a workaround? I am willing to consider any option... so far my best option seems to be to downgrade Eclipse to an older version where the plugin still works. But I want to see if there's a better alternative out there
Found out the answer by a support rep from the group responsible for the plugin.
Firstly, they no longer offer the plugin via that site URL. You download their plugins from their ftp: ftp://ftp.microfocus.com/download/
and Secondly, they do not yet have a plugin that supports the latest verison of Eclipse, they are still working on it...
I would strongly discourage trying to use StarTeam with Eclipse. Ever since StarTeam 5.3, Borland has been trying to play catch-up with Eclipse. In my experience their clients have never worked well with Eclipse even when they did work. Moves in particular were handled very poorly, and resulted in duplicate files in StarTeam. Even worse was trying to use IBM WebSphere/RAD with Eclipse and StarTeam/Eclipse plugin, because IBM and Borland always required different versions of Eclipse and were ultimately incompatible. For a short time there was a time where RAD 6 and StarTeam 2009 (I believe) were both working on the same Eclipse, but the Synchronization was problematic from Eclipse to StarTeam as mentioned. There was a time when Borland had planned on replatforming the StarTeam Client on top of Eclipse, but not sure what ever happened to that plan.
Firstly, I saw some topics about these two but weren't my answer.
I'm looking for a good FPC(Free Pascal Compiler) IDE on GNU/Linux.
There are some IDE's like Lazarus and CodeTyphon. I need suggestion to choose one of those.
I've tried Lazarus once but all windows was separated. It looks messy and not interesting.
I would like to know what are the distinguishes between these two ?
I would like to know advantages / disadvantages each of those. Thank you
CodeTyphon is a distro of Lazarus, like Ubuntu and Debian are distros of Linux.
CodeTyphon comes with a large package of components and plugins, that otherwise you would have to google and download and install.
CodeTyphon have their own idea what are stable versions and what are not stable yet for both of FPC (compiler) and Lazarus(IDE). Whether their assessment is better or worse than upstream's Lazarus Team's, I don't know.
What about one-single-window plugin, it is work-in-progress and it doesn't seems to me it is ready for production use, no matter would you get it as part of CT or download and add it to vanilla Lazarus. However maybe it better works on Linux than on Windows, I don't know.
There were however issues with code legality in CT grande bundle. It is widely believed that Orca (if I remember the name) violates copyrights of glScene/vgScene, which also happened in early Delphi FMX releases but was fixed by EMBA later. There also were disputes in FPC forums/wiki about CodeTyphon pirating some open-source components. See answer by Peter Dunne below.
Your question is akin to asking the difference between Linux and Ubuntu. Lazarus is an IDE/component library, based on FreePascal (FPC). And CodeTyphon is a distribution of Lazarus and FPC. So CodeTyphon is just one way to install a functioning installation of Lazarus.
Lazarus uses the same floating window design as older versions of Delphi. Installing from CodeTyphon won't change that.
Myself and several friends highlighted several licensing issues with codetyphon
most of which could have been corrected by sourcing the included files from known good source and ensuring the correct license headers were included
PirateLogic refused to correct the issues which means they are using code in direct violation of the original license terms
The fact its open source code does not change the fact they are pirating the code by not including the correct license even after the issue was highlighted
I also found several instances of copyright code included which appears to be proprietary and not FOSS at all
They also changed the path & file names on some libraries so that source is no longer compatible with standard lazarus/component installs
This in my view is totally illogical
These 2 factors heavily undermine what was potentially the best FPC/Lazarus distro
Hardly professional
Lazarus can be a daunting installation process due to it's nature as a cross compiling environment. You don't just download an installer and click ok. A typical "installation" is actually a bootstrap FPC compiler doing a three-pass compilation of an "install". There are plenty of good installation scripts/methods from the official Lazarus/FPC team and in the community for a . But, understandably, the installation process is a skill in itself.
CodeTyphon is a a different/separate branch of an installer system, which is more of a utility suite/tools/third party code compilation library. If you want the simplest installation experience go with CodeTyphon. It has the nice graphical front end for managing the compiler. You can conveniently do the fancy stuff like build "cross-compilers" for almost every "target" operating system out there. It also is jam packed with hundreds of the best components/libraries pre-installed. It is a very actively maintained project and very professional. A whole lot of work is done for you.
Even if you want to be learn the low level compiler capabilities, CodeTyphon is a good place to start. It is written in FCP/Lazarus and is open source. Simply study it as "working demo app" and the other info on the compiler details. If you crash it, at least you don't have to learn to climb the hill. You get to get to start from the top and lose control on the way down. Start from scratch (and a three hour reinstallation) Hahaha
Lazarus also has a package "AnchorDock" which allows you to dock all the windows into one. Either install the anchor dock design package after installing Lazarus, or install Lazarus using the script at getlazarus.org which will do it for you.
I'm trying to build an embedded simple web browser for an embedded device and I've decided to use WebKit / WebKitGTK+. However, our device uses a Linux environment somewhat based on CentOS 5.8. I haven't been able to find any RPMS or mention of support for WebKit / WebKitGTK+ for CentOS 5.8 while doing several web searches.
Does anybody know if it's possible to build an older version of WebKitGTK+ such as 1.2.6-2.el6_0 which works well on CentOS 6.3? Are any RPMS available for CentOS 5.8?
The goal here is to be able to run a relatively current, at least 1.2.6 version of WebKitGTk on CentOS 5.8
Note: I was able to sort everything out. Just took a long time compiling all of the dependencies in the correct order with the correct options. I was able to get WebKitGTK 1.6.0 running on Centos 5.8.
You shouldn't have any problems building an old version of webkit if you can install the older versions of libraries that it requires.
If you have older or newer versions of GTK+ etc installed than the old version of webkit requires it may need quite a bit of porting to compile.
I'm not aware of any RPMs that meet your requirements
Depending on the compilation options you should be able to compile the dependencies in an isolated directory. With each library you typically use the --prefix option to specify the destination. Then when compiling something that depends on that library, you typically have an option to specify where to look for that library - something like --with-libraryname=/path/to/library. You want to check ./configure --help of each thing you're compiling to get the correct options.
It'll be quite a bit of work, but you should be able to compile everything you need into an isolated directory without replacing anything on the system. I would highly recommend you avoid doing this in root to ensure you have the right options.
I want to bundle JRE 6.0 together with my java application. All my source code reside in CVS. My client will check-out the code and build it themselves. Should I store JRE in CVS?
I normally advocate putting most everything in source control, but this seems a little excessive. Why ?
the JRE is readily available from http://java.sun.com
it doesn't change that often. I'd expect you to specify a minimum version for your code to run against (e.g. 1.5, 1.6 etc.)
I would not put a JDK or JRE into a source code repository:
It is bad practice to put externally versioned things into your version control because it usually leads to over-constraining, obscuring and/or hard-wiring your app's external dependencies. (Maven or Ivy are good solutions for dealing with external dependencies, though not in this case,)
Putting binaries into version control is a bad idea for some version control systems.
But I think your real problem (actually, your user's organization's problem) is the IT folks who refuse to contemplate upgrading the JRE:
They need to be made aware of the
fact that they can install multiple
JRE versions on the one machine, and
configure apps to launch with the JRE
version they require. (It is trivial
on Linux ...)
They need to be made aware of the fact
that their policy is an impediment to
progress.
They need to be made aware of the fact
that their policy is a potential security
issue. If they force users to deploy their
own copies of JDKs / JREs in random places,
it will be difficult to ensure that JRE security
patches get applied. (Besides, 1.4.2 is due
to be end-of-life'd soonish, and security
patches for it will cease.)
EDIT: and there is also the legal question of whether "redistributing" a JRE out of your source code repository is a violation of Sun's click-through JRE/JDK download license. (I don't know ...)
As best practice, you shouldn't keep any binary files in the source control system. For Java developers there is maven that does it's work better in versioning jar files. The reason is that we want to keep our source repository as small as possible so it is faster for those that checks out our code for the first time.
But if you still want to keep binary files in the source control, it would be best to avoid using CVS, because CVS is bad in versioning binary files. You can search with google, why it is bad. If you use SVN, then it still okay because SVN handles binary files much better than CVS.
I see nothing wrong with storing the JRE in CVS.
However, it's not so important whether you do or not as long as your script can pull it as part of the build. For example, if you want to host a downloadable jre.zip on an HTTP server, or point to it in a Maven repo, that's just as good.
Well won't your client all ready have the JRE if you expect him to compile the code before running it? The JDK contains the JRE.
Depends a lot on what you use to handle dependencies. If you use Maven, then create a maven package with the stuff you need, and host it on a local repository.
If you just have CVS (like we do) then it is fine to create big binary packages (since you will need them) which you can then put in CVS. Just be aware that they should be static for best CVS performance.
ALso note that the jsmooth package can create an EXE file of your jar with an JRE embedded in it. This might solve your deployment problem.
For remote compilation, Eclipse can work with a plain JRE. You just need to tell Eclipse where JRE you already have prepared above is located on the disk. There is also a folder inside the Eclipse distribution where the launcher looks automatically.
I'm wondering about the client building the application themselves. It will require some kind of Java compiler, most probably javac wich is part of the JDK. So your client will not only need a JRE, but a JDK as well (unless they will be using Jikes or another alternative compiler).
javac is capable of generating bytecode for previous versions of Java, so using a newer compiler should not pose any problems.
Personally, I would not include large binaries like a JRE as part of my own repository. The JRE can be considered very stable and just listing the minimum version required should be enough. Installing a JRE is also something quite different than installing a single Java application. The two activities should not be mixed.