I guess 1.3.19 is already old news by now, but I decided to comment a bit on it, especially on a new support direction that'll start to be adopted in the Pydev development (and I'm still unsure how well that'll work):
Pydev will now try to support Eclipse 3.2, 3.3 and 3.4 (all with the same binaries) -- actually, there are still some known bugs on Eclipse 3.4, but those should be solved for the next release.
Now, while trying to support all those versions with the same binary release, there are some hacks that don't really seem right for me (but I couldn't see another way out for it):
1. Catching Exceptions such as ClassNotFoundException / LinkageError and related and falling back to another version (usually deprecated) of some API
2. When adapting to some interface, instead of having adapter == IElementContentProvider.class, do things as if(adapter.toString().endsWith("org.eclipse.debug.internal.ui.viewers.model.provisional.IElementContentProvider"))
-- because that class still does not exist on a previous version.
3. Using reflection (yes, in languages as Python this would be the default, but Java's not really made for this)
BTW: This wouldn't be possible without using Mercurial locally -- right now I have 4 workspaces, all synched through mercurial -- one for each version of Eclipse and one that's the link to the outside world -- and each of those has some changes to make it compile in that version -- yes, the final code runs in all versions, but it'll only actually compile in 3.3 for now -- the others have classes not defined (which are those cases with ClassNotFoundException), so, the code must be tested later on those versions with the final release.
Could you please describe your Mercurial work-flow, for supporting the different versions of Eclipse?
ReplyDeleteI am very interested to know.
Also, have you using a Mercurial add-on for Eclipse? What would you consider best practices for using Mercurial + Pydev.
I am very happy Pydev Extensions customer, btw!
As for the add-on, I couldn't find one that I considered good to use with Eclipse, so, I use it in the command line (with kdiff3 as the diff tool)
ReplyDeleteAs for the workflow, I'm not really a power user of Mercurial -- I just use what I consider the basics... (pull, push, clone, diff, merge, update, commit, revert)
My workflow is the following:
1. Get the code from cvs and add it into Mercurial... I have a single mercurial repository with all the projects -- one shortcoming is that as there's only one repository, it contains both the extensions and the open source version, so, I cannot make it available because Mercurial (as far as I know of) has no real standard way of getting just a subset clone (there's the forest extension, but as I already started it this way, there's no way to convert it now -- and it doesn't seem right, I wanted to be able to just do a clone with the dirs I wanted).
2. That repository is the connection to the external world, so, it contains both cvs metadata and the mercurial metadata (and is the workspace for eclipse).
So, the metadata structure becomes something like:
/workspace
.hg
.metadata
/org.python.pydev/CVS
3. Clone with mercurial for a new workspace and use it as the workspace in another eclipse version and keep them synched with hg pull/push -- so, when I start working in some version, I pull the changes from the 'main' mercurial repository, do the changes needed, commit and the push back... and later I commit to the cvs where it becomes visible to the external world.
I always like new releases, keeping my thumbs for a profiler :-)
ReplyDeletemanuelg: if you use a project == repository (ie, not multiple projects in one repository as fabio does) then theres is a mercurial eclipse plugin at EPIC which may work well for you. While it does support keeping multiple projects, there are oddities with merging etc.
/Stefan Chyssler (usip) - Also happy pydev extension customer
I am wondering if the information on the Sourceforge page is accurate in that Pydev only supports up to Python 2.4x? I have 2.6 on my machine...
ReplyDeleteIt also supports python 2.5. As for python 2.6, it's whole syntax is still not supported (so, if you don't use the new syntaxes it should be ok, but otherwise, there are some things to be done in that area).
ReplyDeleteThe next release should add support for python 2.6 and 3.0.
-- Fabio