We know all that JGraph is a very powerful graphic library and now we are in version 6 (JGraphx).
Me I have an application (by the way I am newbye in JGraph) coded in JGraph 5 and I want to migrate it to Graphx.
Is there any tut to know what is the main differences between these two versions?
That migration, is it easy to do (in general)?
JGraph (the last version of which was version 5) and JGraphX (which was originally going to be called JGraph 6) are completely different code-bases. JGraphX was a complete rewrite from scratch, which is why we made the naming change to avoid the idea you could upgrade from 5 to 6.
So no, there is no migration route, you'd need to re-write your part of the application that interfaces with JGraph(X).
Related
Trying to test some code in Pharo 2.0 and it depends on BlockContext which was dropped, what can I do?
You can download Pharo 4 and run Magritte 3 and Seaside 3.1, as that are the stable versions. The major change in Magritte 3, introduced and explained early 2012, is the moving of the descriptions to the instance side, and renaming description to magritteDescription. You can find sample code of Seaside & Magritte in a QCMagritte image you can download from CI, in addition to the plain magritte builds
Otherwise, just check the pharo, seaside and pier mailing lists of 4 years ago and the monticello repositories to see what changed. There have been lots of little changes because of the improvements in Squeak and Pharo in the past 4 years.
If you need to use Magritte 2 to migrate legacy code you might want to take a look (with Pharo 5) at my experimental MonticelloProjects code on Smalltalkhub. That builds a data structure of all source code in the Monticello packages in a project repository, allowing you to more easily see what changed when.
we are planning to migrate our codebase from xI50 to xI52. Could anyone please let me know, how xI52 is different from XI50 ?I am just tryingt to figure out what kind of changes will need to be done to our existing codebase on xI50 to make it compatible on xI52?
Also, I have below two questions:
1) Is Xi52 the best hardware to which we should migrate from Xi50? What are the advantage of Xi52 from others?
2) What are the best practices to migrate the configuration from Xi50 to Xi52?
Regards,
Rahul
Good question Rahul!
As a rule of thumb, the compability of the codebase is essentially an aspect of the running firmware, not the model in itself.
So, figure out the firmware version of your XI50 and your target firmware, which probably is the latest. If you upgrade to the same firmware version (such as version 5), there should be no issues.
Here is a list of all firmwares.
http://www-01.ibm.com/support/docview.wss?uid=swg21237631
The release notes to look for information in each firmware, so go through the list (you may have to aggregate through several firmwares, such as 4.x to 5.x, 5.x to 6.x).
Sometimes, you have to look into individual technotes for info.
In general, DP contains compability rather well, and breaking changes resides mainly in details.
http://pic.dhe.ibm.com/infocenter/wsdatap/v5r0m0/index.jsp?topic=%2Fcom.ibm.dp.xi.doc%2FrelnotesXI.html
http://pic.dhe.ibm.com/infocenter/wsdatap/v6r0m0/index.jsp?topic=%2Fcom.ibm.dp.xi.doc%2FrelnotesXI.html
I am trying to build a visualization tool for Decision Trees (and several refinements in the algebraic decision diagram world, once that works) using JgraphT to support the underlying data structures, and JgraphX to throw the structure onto the screen. (I'm new to both packages.)
I gather JgraphX has quite a history-- it seemed as though the Facade and TreeLayout classes from Jgraph 5.13 would be a step in the right direction, but I can't find anything similar in the more recent JgraphX packages. (If I understand the history, Jgraph was renamed to JgraphX sometime after the 5.13 version was released, and the version numbers started over-- is that correct?) Nor can I find the legacy Jgraph 5.13 jar files anywhere.
Specific questions:
Does Jgraph 5.13 exist anywhere, and can someone point me to it?
Does JgraphX support the same tree layout features under a different name or paradigm?
Any help will be appreciated, otherwise I'm going to have to manhandle JgraphT/JgraphX until I have a tree layout tool from scratch, which does not fit my definition of "fun."
JGraphX was a completely rewrite from scratch, which is why we didn't call it JGraph 6 and the versioning started from 1.0.
JGraphX does have tree/hierarchical layouts in it.
Obviously, JGraphT is not a related project to us, so it's unfortunate they didn't update. There is a post on our forum relating to this. I haven't tested the bridge, but the idea is right.
JGraphX does have its own analysis package too, btw. You might want to check whether that meets your needs and whether you need JGraphT at all.
We do provide downloads of the later version of JGraph 5 here.
My suspicions seem to be correct: Jgraph changed significantly in its evolution to JgraphX, and JgraphT hasn't (or won't) catch up to it. Exporting from JgraphT to a Jgraph format works much better if an older version of Jgraph (not more than 5.xx) is used-- then the facades, layout tools, etc, interface properly.
And an older version of Jgraph, version 5.13.00, is found here.
I'm migrating the data layer of our application to NH version 2.1.0 (from 2.0.1) and noticed the use of LinFu. I discovered that framework and want to use it in other pieces of the application, especially I want to use the LinFu.Reflection.dll, which requires a reference to LinFu.DynamicProxy and here comes the trouble, the 1.0 final version of LinFu that I can find on google.code is not the same version used by NHibernate itself. Do I need to rebuild NHibernate.ByteCode.LinFu.dll changing the reference to the available version? If not, what else?
I have faced the same problem a few days ago. There's a tool named ILMERGE that merges .NET DLL-files, and that way you should be able to have several versions of the same DLL in your application.
Unfortunately I haven't tested the tool yet, I didn't get around to it, but I'll test in the next week.
But Rhino Mocks for example, has a binary with all dependencies included: http://ayende.com/projects/rhino-mocks/downloads.aspx, so it seems doable.
I use Intellij Idea 7 for Java dev. My dev is 'limited' to all J2SE features plus light JSP, Servlets, and super light usage of JPA. No J2EE, no massive use of random frameworks, etc.
Is it worth upgrading to ver 8? "Worth it" to me means better "core functionality" in terms of speed (ESPECIALLY startup speed), memory utilization (seems like it starts having serious problems with four or more projects open), and auto bug-finding.
More frameworks supported and more languages supported (other than perhaps Haskell and C++), and more refactorings don't interest me at this time.
A while back, I installed a preview version of 8 and it seemed -exactly- the same as 7, as far as my needs were concerned.
Anyone loving the upgrade to 8, and if so, why?
Thanks
It also seems to be easier to configure a new project over top of a complex collection of existing code.
For example, something that you would naturally configure into 5 or more modules.
There is a really beautiful go to/create test wizard that is bound to ctrl-shift-T. Worth the upgrade by itself
The best way to tell is to check out the list of new features and decide for yourself. I haven't discovered any single feature so far that by itself is worth upgrading - the simplified UML view is quite nice, as is the improved Maven integration. The UI feels a bit more streamlined and faster. It seems like most of the attention has gone into non-Java features like better Flex support (which I am really thankful for as I don't like FlexBuilder but I haven't had a chance to use yet).
IntelliJ 8 has a configure plugins feature that allows you to disable plugins with dependencies. Nothing trial and error couldn't replicate, but it is nice.
Startup is only marginally slower. But indexing once opened is a lot faster than before, even unnoticeable for most projects, except after a commit to Subversion. It seems a commit to subversion triggers the indexing twice.
I am working on the Diana-EAP build - but 8 has git integration built in. The EAP has better git integration than the 8.0.1 release - it looks like that is something they are really focusing on.
Definitely not! Seems that the variables defined in our custom taglibs are no longer able to be used in the jsp (worked in 7.0.4). All red. No auto complete.
Oh, and the new settings menu is horrendous!
Some benefits of IntelliJ IDEA 8:
IDEA 8 supports Subversion 1.5 new functionality - e.g. merge tracking, which may be useful especially if your team (like ours) uses a lot of development branches and thus merging is frequent.
One detail I appreciated about IDEA 8: As you probably know, IDEA has had changelists for pretty long now, built on top of any underlying version control system - this is a really useful feature. So, now that Subversion itself supports changeslists, IDEA's changelist implementation has been changed so that it is perfectly compatible with Subversion's native changeslists. (For example, you'll be able to work with any changelists created in IDEA also when using svn command line tools directly.)
Edit: in your case, perhaps it is not worthwhile to upgrade. For me, at least, startup and file indexing seems to be somewhat slower in 8 than 7. [But for me personally the upgrade was definitely worth it, because it solved a long-standing VCS problem with IDEA 7 - it could hang "waiting for VCS sync to finish" for an hour or whatever after hitting Ctrl-K.]