gmane.comp.java.netbeans.modules.ruby.devel

git plugins

Chris Kutler — 2008-10-07T01:55:49

Is there anyway to use the Rails Plugins dialog box to install plugins from git repositories?

Re: typo in error message

Peter Williams — 2008-10-02T23:24:50

I already reported this... Not sure if it can be fixed due to HCF though :( I hate misspellings. -Peter Chris Kutler wrote:

Re: Rails 2.1.0 or 2.1.1 for NetBeans 6.5

Erno Mononen — 2008-10-02T12:58:44

It is quite easy to check in the new Rails project wizard, probably also in the gem manager, but I'll talk to Martin before implementing it there. I have a patch ready for the project wizard, but will need check first whether it is still okay to push it to the main. Erno

Re: Rails 2.1.0 or 2.1.1 for NetBeans 6.5

Tor Norbye — 2008-10-01T19:43:42

Ok, we're back to Rails 2.1.0 (changeset 4b480efccf14). If Rails 2.1.2 comes out in the next couple of days (I've seen some e-mails seeing if it can be expedited) then I'll bring it up on this alias to see what we should do.

Re: Rails 2.1.0 or 2.1.1 for NetBeans 6.5

Chris Kutler — 2008-10-01T17:37:16

Thanks for the clarification. Again, my apologies for not reading your full response the first time. Tor Norbye wrote:

Re: Rails 2.1.0 or 2.1.1 for NetBeans 6.5

Tor Norbye — 2008-10-01T17:17:01

Just to clarify -- version 2.0 to 2.1 is a big deal - dot releases do change features. Dot dot releases, e.g. 2.0.0 to 2.0.1, those are supposed to be only bug fixes. So I'm saying you -should- include the version number, but probably only to the first decimal digit, e.g. 2.0 or 2.1, since the micro number can change as we upgrade bugs. From what I understand, in Rails 2.1.1 they accidentally used a Ruby feature which cannot be supported in JRuby. I believe it has been changed back, but this won't be released until 2.1.2, which probably won't happen in the next couple of days, so I think our only course of action for 6.5 is to go back to 2.1.0. But we also have to worry about people upgrading Rails themselves, so it would be good if we could give them some automatic help, for example in the platform manager (if it detects you are using JRuby, and Rails version == 2.1.1, then print out some kind of warning message somewhere.

Re: Rails 2.1.0 or 2.1.1 for NetBeans 6.5

Chris Kutler — 2008-10-01T17:09:34

My apologies. I did not scroll down to see the other stuff that you wrote. So, thanks for the input and answers. Chris Kutler wrote:

Re: Rails 2.1.0 or 2.1.1 for NetBeans 6.5

Chris Kutler — 2008-10-01T17:06:41

Tor, Yes, I can use 2.1, but I have to disagree with you about leaving version numbers out of the docs or being ambiguous. If the Rails 2.1.1/JRuby problem is not resolved before the tutorials are released, and this combination is not going to work, and I don't tell the users, then I am going to have to deal with a lot of complaints. There is a feed back button at the bottom of the tutorials and people use them. At first I did not put Rails versions in the tutorials and I got tons of emails complaining that the tutorials were not working for them. Now I specifically state which Rails version the tutorial is written for. Even then I get a couple of emails a week complaining that the tutorial isn't working, only to find out they are using a different Rails version. Even the bump from 2.0 to 2.1 breaks the getting started tutorial. What might be helpful is to better understand the bug. Perhaps this bug is just a corner case that most NetBeans Ruby users will not encounter. Can someone explain to me when and how one runs into this bug? How badly is this broken? Tor Norbye wrote:

Re: Rails 2.1.0 or 2.1.1 for NetBeans 6.5

Tor Norbye — 2008-10-01T16:34:42

I think it would be best to leave out specific version numbers in the documentation. It's the kind of thing that can change for example via auto update patches. Dot dot releases contain bug fixes so (especially when there are security bugs) we may choose to bundle those. Can you say "2.1" or "2.1.x" instead? We won't upgrade from say 2.1 to 2.2, but upgrading from 2.1.1 to 2.1.2 to 2.1.3 to 2.1.4 is a possibility. I'm pretty surprised this happened. I did some heartbeat tests on Rails projects with 2.1.1 and didn't see a problem but I suppose the issue is more subtle. In any case, I just IM'ed with some of the JRuby developers and it doesn't sound like this is something which can get resolved in the next couple of days, so I'm going to revert us back to 2.1.0 for now. However, ... we're already pushing people towards updating Rails (for example, in the New Rails wizard it will tell you if your Rails is out of date). If these versions are indeed incompatible, it would be good if we somehow alerted people to this. Erno, how hard would it be to add some logic in a few places to detect that if you're using JRuby, updating Rails (to 2.1.1, not say 2.1.2 when that is released), give some kind of a warning message with a URL pointing to the relevant issue, or perhaps our own wiki page describing the problem?

Re: Rails 2.1.0 or 2.1.1 for NetBeans 6.5

Chris Kutler — 2008-09-30T16:28:28

Do we have an idea of when we will know? I have just a very short window (between now and the 16th) left for the docs and correct wording is essential. If we do not know if we can make a decision by then it will be harder to add the wiggle words to the tutorials and book. Here are some attempts. Please advise. Note The Rails version that is bundled with JRuby (2.1.1) is not compatible with JRuby. You must either upgrade to a patch, if one is available, or you must uninstall Rails 2.1.1 and install Rails 2.1.0. or Note The JRuby and Rails bundle includes Rails 2.1.0. As of the time of this writing, Rails 2.1.1 is not compatible with JRuby. You should not upgrade the Rails gem until this is fixed. Where do they go to learn if a patch is available? Nick Sieger wrote:

typo in error message

Chris Kutler — 2008-09-30T15:43:57

Experience is spelled incorrectly in this error message. I really do not have time to file a bug. INFO: Dynamic pool created. Initial runtimes will be 1, hard minimum is 1, hard maximum is 2. If you experiance out of memory errors, consider increasing the heap size or setting the jruby.runtime.min or jruby.runtime.max Java system properties. If starting GlassFish using java CLI then provide it as system property, such as -Djruby.runtime.min=1 -Djruby.runtime.max=2, otherwise make an entry into $GLASSFISH_INSTALL/domains/domain1/config/domain.xml, such as

-Djruby.runtime.min=1

-Djruby.runtime.max=2

Re: Rails 2.1.0 or 2.1.1 for NetBeans 6.5

Nick Sieger — 2008-09-30T15:31:48

Just a word of warning that 2.1.1 introduced code that breaks Rails when running on JRuby (because JRuby runs with ObjectSpace off by default for performance). http://github.com/rails/rails/commit/6c970d79a064b953d3d9555a362a1ad1e0058d1c We haven't yet decided on a course of action. I need to submit a patch to Rails core, and we'll probably supply an equivalent fix in JRuby, but neither have had a release since then. I'm not necessarily suggesting you back out the change; I don't have a good answer right now. /Nick

Re: Rails 2.1.0 or 2.1.1 for NetBeans 6.5

Chris Kutler — 2008-09-30T15:00:14

This has a doc impact, I am glad I thought to ask. I had checked the recent changes and it wasn't mentioned. (and my last dev build installed still had 2.1.0). I will make the changes in the book and tutorials. I am hoping that it is just a version number change and the tutorials are otherwise unchanged. Tor Norbye wrote:

Re: Rails 2.1.0 or 2.1.1 for NetBeans 6.5

Tor Norbye — 2008-09-30T00:35:38

I already upgraded us to 2.1.1 ( http://hg.netbeans.org/main/rev/da9d165de790 ) 2.1.1 is just a bugfix release over 2.1.0, including an important security bug fix, which is why I made the upgrade. I hope this doesn't cause problems for anyone. There should be no feature changes or incompatibility that should require updating of descriptions.

Rails 2.1.0 or 2.1.1 for NetBeans 6.5

Chris Kutler — 2008-09-29T18:35:50

Hi, I just want to verify that NetBeans Ruby 6.5 will be bundled with Rails 2.1.0 and not 2.1.1, which came out 9/4 Chris

Re: What does Default JRuby Platform do in GlassFish server properties panel

Chris Kutler — 2008-09-26T22:13:42

Thank you Peter. I think I have the information that I need. Peter Williams wrote:

Re: How to make -J-Druby.interpreter work.

Tor Norbye — 2008-09-26T21:03:24

I think ruby.interpreter is a flag to bypass the ruby platform manager completely. It's used primarily from preindexing scripts and such.

Re: What does Default JRuby Platform do in GlassFish server properties panel

Peter Williams — 2008-09-26T20:08:15

Chris Kutler wrote: Well, GlassFish only requires a JRuby reference at startup if an existing Rails has already been deployed previously (and thus will be loaded when the server starts). The path to a JRuby platform can only be supplied to GlassFish on startup. Even if the server is not started with Rails in mind, if a Rails app is subsequently deployed, the JRuby platform had better be defined or the deploy will fail. There is no way to query a running server to determine if a JRuby platform was defined when that server was started. Yes. If the server is not running and you "Run" your Rails application, the JRuby platform specified by that project will be the one used by GlassFish. No. This is part of the question where the answer is a description of what happens "under the hood". Hypothetically speaking, lots of things could happen. In practice, probably nothing. I really don't expect this particular setting to come into play that much. If I'm mistaken, I'll revisit how things work because it *shouldn't* come into play very often, if ever. It sounds like the import code could use a little more thought then. I don't believe this is the only solution to this problem. But that's a topic for another discussion. Anyway, from the perspective of the end users, most of whom will only install the release version, how often do you expect they will install a new version of the IDE? I don't think it will happen very often, but I could be wrong. I don't know if we've ever computed statistics on this. Given the way the debugger is designed (around gems, including native gems, not withstanding matching the versions of those gems the IDE was compiled against), this bothers me. I hope it doesn't become a support problem. I tend to be averse to shipping software we don't expect people to use in real life to do real work. It just adds clutter and wastes disk space. The included distribution ought to be usable and maintainable. If it's not, then it's broken and we should fix it. But again, this is a topic for another discussion. I understand. This area could use some more polish. But there are other areas of the product that need more polish right now, at least from what's on my plate. -Peter

Authentication for GlassFish V2 Failed message when ran MRI Ruby on Rails app in WEBrick

Chris Kutler — 2008-09-26T17:30:20

I am curious to know why when I ran my MRI Ruby on Rails app (which is configured to use the WEBrick server) in the NetBeans debugger, I got a dialog box that said that Authentication for GlassFish V2 Failed (this is with the 9/24 dev version) Any clue?

How to make -J-Druby.interpreter work.

Chris Kutler — 2008-09-26T16:18:41

Hello, In my platform manager, I have a JRuby platform entry with the Interpreter set to C:\jruby\jruby-1.1.4\bin\jruby.bat. I would like this to always be the default interpreter when I create new projects. So, I started up NetBeans with this option: -J-Druby.interpreter=C:\jruby\jruby-1.1.4\bin\jruby.bat Now, when I create a new project, the Ruby Platform drop-down list says There are no other entries on the drop-down list. And the Platform Manager, the Platforms List no longer shows all my registered platforms, it only shows What am I doing wrong? Or perhaps this option is obsolete and needs to be removed or marked as 6.0 only (or whatever it used to work in).

Re: What does Default JRuby Platform do in GlassFish server properties panel

Chris Kutler — 2008-09-26T15:04:53

I am very dense and thus I keep needing to ask questions so that I make sure that I am understanding you. I am sure everyone else finds the above clear but you need to be more patience with the non-technical like me. If Idon't understand it, I won't be able to tell the truth I think this is saying that GlassFishes uses the JRuby platform on startup for some reason. Or do you mean this is the JRuby platform that GlassFish uses when it runs its deployed JRuby applications (if no other platform is specified)? Does "at that time" mean at the time that GlassFish is started? How does one specify a different platform at startup (other than the checkbox of course)? Can one specify a platform other than at startup, and how? Peter, I am rarely interested in under the hood stuff. It might be helpful for you to know that my questions asked in terms of user perspective. If you are thinking I am asking differently, ask me to rephrase the question. I want to know why a customer would check this box, when they should check this box, how the behavior changes, and what bad or wierd things can happen to an app when the box is checked or cleared. Especially when the UI is a hack. Those need the most attention or else the users can bang their heads for hours. It will be written in the newest NetBeans Ruby Installation documentation. This is what those of us who use the product over time are in agreement about because of many reasons, foremost of which are the complications that happen when you install a new version of the IDE. If you import your old settings the the Platform Manager will point to the bundle in the older version (which you may have deleted). All your apps will try to run this older version. If it is still around, and it is an older version of JRuby, you will get odd behavior that you didn't expect because you think the IDE is using the JRuby that is bundled with it, not the older one. If you don't import your settings, and you have apps dependent on older version things might not work until you install the older JRuby version and make it the platform for those apps. Then there is the issue with gems. You get NB 6.1, install all your gems into the JRuby under the installation. When you install the new NB, you have to reinstall all your gems. And you have to remember to install the older rails for your older apps. We will also recommend that people maintain gems repositories outside of the bundled JRuby subdirs, if they do choose to use the Bundled JRuby instead of their own separate installs. Or, JRuby 1.1.4 was patched after it was bundled with NB6.5 so you want to use the patched version. Or you want to start with the latest JRuby, if you happen to install NB after 1.1.5 comes out. Now we can write up all sorts of work arounds for each of these common cases (I see these issues in the forums). But we find the easiest and stableist thing to do is to install a JRuby installation, maintain you gems in that stable environment. And take control of your JRuby versions and upgrades. I believe it is so that people can use the product out of the box for a good quick experience. I can't take that chance An interesting thing to ponder. I will ask our users over on the users-n3CzLFQkLgrXWKka9uoeGti2O/JbrIOy< at >public.gmane.org alias