Perforce Plugin in MacOS X?

You may want to try the PerforceDirectPlugin (and give us some feedback -
both positive or negative is welcome).
r.

"James Waldrop" <sulam@well.com> wrote in message
news:21647856.1051317474959.JavaMail.jrun@is.intellij.net...

Having dug into the internals of the current Perforce plugin a bit, I

wasn't too surprised when it turned out to not work at all under MacOS X
(new 3.0 support has been released). That said, I'd love to see this
working.
>

Currently it NPE's, and debugging plugins is pretty awkward so without

putting some work into it I'm not sure exactly what's failing. The good
thing is that it NPE's in the "Test", so this probably isn't entirely hard
to replicate.
>

I guess I'm wondering at this point if anyone is working on getting

Perforce plugin support working under OS X? I'm as lazy as the next
engineer, so if someone else is doing this work then I'm happy to wait. ;)
That said, I am fairly motivated to get it working, and obviously I have
an OS X machine to work with.
>

I'll be doing the obvious stuff to see if I can make it work tonight, and

will report back if I find it's pretty simple.
>

James

>

Ok, as I suspected, the problem revolves around the property p4.executable. Under MacOS X that property is by default being set to "P4".

1) The P4 executable may be installed almost anywhere under a Unix system. 2) It will most likely be called lowercase "p4" rather than uppercase. 3) Getting the p4 executable into the Runtime.exec() path isn't entirely obvious -- certainly the OS X launcher doesn't get it set since it is launching it from the desktop, not from a shell, and what's more this is the usual case. 4) There's a lot of kinda smelly special-case Windows code surrounding all of this in the current plugin.

I got it working fine, mostly by simplifying that part of the configuration down to a single variable -- the path to your external p4 binary. This disappears all the code/properties for system root and system drive that is specific to Windows. Additionally the p4.executable property should from there simply be set to whatever the person has configured it to be. The fact that the P4Package defaults aren't so hot doesn't matter at that point, since it overrides them nicely.

I'd be happy to provide diffs if they would be useful, but I suspect what I did is pretty obvious and that diffs would simply fail to apply cleanly, whereas doing what I did given my description would probably take about 5 minutes. :)

James

Basically it looks like your plugin should work fine as long as you handle paths cleanly. I'd be happy to test it further if my other post doesn't give you enough info to convince yourself one way or the other that the P4Direct plugin will work. In my particular installation, the p4.executable property must be: "/usr/local/bin/p4" in order for P4Process to do the right thing.

James

It would be nice if you sent me the diff too. As I don't have access to OS
X, that will be something I can cross check against.

Thanks,
Dash.

"James Waldrop" <sulam@well.com> wrote in message
news:2501340.1051323963064.JavaMail.jrun@is.intellij.net...

Ok, as I suspected, the problem revolves around the property

p4.executable. Under MacOS X that property is by default being set to "P4".
>

1) The P4 executable may be installed almost anywhere under a Unix system.

2) It will most likely be called lowercase "p4" rather than uppercase. 3)
Getting the p4 executable into the Runtime.exec() path isn't entirely
obvious -- certainly the OS X launcher doesn't get it set since it is
launching it from the desktop, not from a shell, and what's more this is the
usual case. 4) There's a lot of kinda smelly special-case Windows code
surrounding all of this in the current plugin.
>

I got it working fine, mostly by simplifying that part of the

configuration down to a single variable -- the path to your external p4
binary. This disappears all the code/properties for system root and system
drive that is specific to Windows. Additionally the p4.executable property
should from there simply be set to whatever the person has configured it to
be. The fact that the P4Package defaults aren't so hot doesn't matter at
that point, since it overrides them nicely.
>

I'd be happy to provide diffs if they would be useful, but I suspect what

I did is pretty obvious and that diffs would simply fail to apply cleanly,
whereas doing what I did given my description would probably take about 5
minutes. :)
>

James

>