To have browsable javadocs in a project hosted at Google-code, I got from here the recipe: set the correct mime-type property (text/html) when Subversion commits HTML pages.
Does anyone knows how to configure that in Subclipse?
This related question gives the pointer to do it in Subversive (there is a Preference tab for that). I couldn't find anything similar for Subclipse.
Someone comments about doing a Team->SetProperty for the whole javadocs dir (recursively), but that is not extension specific (I'd want text/css for stylesheets, for example); and further, I guess, if when new files are created I must remember to do it again...
Is there an alternative?
Update (2001-06-11): In case somebody is interested: I couldn't find a way to accomplish this, so I ended switching to Subversive.
To configure the MIME types information, edit the following file:
Windows 7/Vista: C:\Users[YOUR_USER]\AppData\Roaming\Subversion\config
In the config file, locate the property enable-auto-props and uncomment it. It should be set to yes. Make sure there is no space at the beginning of the line:
enable-auto-props = yes
The last section will be [auto-props] and by default everything will be commented out. Add your required file type with the appropriate config.
It's possible to do part of the work in the shell, by setting mime-type via script.
Related
our BE-website-panel is looking kind of strange.
And we can't use the filter or add-new-element functions which are shown.
(We are clicking through to the sites themselves)
I didn't find anything regarding this bug so here's a screenshot:
backend
Also here's a list of the extensions:
extensions
I fixed the problem, altough i can't tell you where the error originated.
I downloaded the typo3_src-8.7.2 source files and overrode all my files via ftp, because i compared the whole folder with phpstorm beforehand and some files were empty on my side.
Confluence version: 5.5.2.
I need to know how I can see the actual source code of a macro in Confluence. I tried adding macros, then right-clicking the page to view the source code, but that doesn't really help.
What I am trying to do:
With the existing macro, task list (the checkboxs), I need to modify the code in a way such that changing the value from true to false (pretty sure it is the onClick() function) or vice versa will send an e-mail to all "Watchers" of that page.
Would this even be possible? The changes I make need to be recognized on the server so that the changes don't only take place on my computer. Also, I don't even know if I can view the actual source without downloading an external plug-in (which won't work for certain reasons). Has anyone done something like this?
The source code for Confluence macros can be found either in the User Macro section of the Administration panel for inhouse macros or in the plugin code. The first port of call is bitbucket.org for Atlassian plugin code.
To view the code for Atlassian plugins you will need to access the source from Atlassian. E.g. Tasklist Plugin in BitBucket.
You can also download the jar installer for this plugin from the Atlassian Marketplace Dynamic Tasklist 2 page, change the extension from .jar to .zip and then unzip the plugin to view the plugin contents.
Found a work around. If you go into settings (under profile pic), then go to e-mail and select all the checkboxes provided, it will solve my problem. Any small cahnge made in the document will be e-mailed to all watchers.
This thread is very useful for finding out which files in Netbeans should go into source countrol, but it doesn't cover all files.
In particular I'm wondering whether the following files should go into source control. Here are my assumptions/guesses:
nb-configuration.xml - easiest - the file itself in the comment says it should go into source control.
nbactions.xml - from what I see this file stores information typical to running the application. I.e. JVM arguments etc. So I suppose it is a question of taste - if you want other developers to have a "suggested" Run configuration - include it. Otherwise - don't. Correct?
catalog.xml - not sure what this does (I GUESS it's used by the editor to find out xml schemas and such to enable syntax coloring, but it's just a guess). Anyway - I see that this file has system-specific information (path) - so it shouldn't go into source control.
Can anyone confirm the above?
Thanks,
Piotr
I never put my IDE configuration files in the repository, for several reasons:
other colleagues may want to use theirs;
other colleagues may want to use other IDEs (such as Eclipse) and seeing those files (or even have to exclude them from the checkout) could be annoying for them;
some of these files are generally not related to a single project, others automatically generated, so no need to store them in the source code of every project.
In order to exclude them, our first solution was the .svnignore, but it was still logically wrong to modify some shared content for the specific needs of a single user, so we decided to be more strict:
in my ~/.subversion/config I have:
[miscellany]
global-ignores = nbactions.xml nbproject
Hope this helps,
Marcello
In my Maven based projects I put nbactions.xml into source control. Just make sure to change absolute paths to relative ones.
I put nbactions.xml into source control BUT there is a caveat: it's internal format can change so if your developers, for any reason, use different versions of NetBeans you could have to remove it because sharing it becomes nasty.
Recently I upgraded from NetBeans 7.3.1 to 7.4 and the "Run" action was giving a strange error message. I solved the problem by deleting and regenerating nbactions.xml: the old one had a custom Maven goal for the "Run" and "Debug" actions; it was org.codehaus.mevenide:netbeans-deploy-plugin:1.2.4:deploy it was not visible in the IDE v7.3.1 (perhaps it has been generated by an even older version for internal usage) and was generating a class not found for org.openide.util.Lookup in v7.4. I'm documenting the problem here because I found the solution by myself after an unsuccessful search on the Net. I hope this can help someone else.
I am SOOOOO discouraged. This seems so simple, but being a complete novice in Drupal and Eclipse PDT I have absolutely no idea where to look. My DAYS of searching seems to indicate that I am the only person on the planet with this problem.
Eclipse IDE for PHP Developers (1.2.1.20090918-0703)
WampServer Version 2.0
Apache 2.2.11
PHP 5.2.9-2
MySQL 5.1.33
Drupal 6.15
xDebug php_xdebug-2.0.5-5.2.dll
I setup my project in Eclipse to point to my Drupal directory (C:\wamp\www\drupal-6.15). I start the debugger (xdebug) and I stop at the first line of code. I can step through the code line by line -- so I think I am in the debugger, and when I terminate the app, I see the xdebug termination message in the tab heading.
But I cannot set a breakpoint in any of the PHP code files -- specifically a new .module file.
When I right click in the breakpoint column on the left in index.php (main) I see "toggle breakpoint" and the little blue circle next to the line of code...so I think I know how to set a breakpoint. But when I try to set a breakpoint in my .module, I see a menu that asks me to "add a bookmark" and no option to set a breakpoint.
Why can I not set a breakpoint in this file? Is my project path not set up correctly? Do I need to amend my include path? I can't get Eclipse to recognize even core modules not just site/all modules. I've seen posts about "importing" files into the project, and making sure the correct php.ini file is used for configuring xdebug. I'm lost.
There are so many posts about using Eclipst PDT and xDebug and they all end with "have fun debugging" or "just set some breakpoints and off you go" -- but what if you CAN'T set a breakpoint? Any ideas about where Eclipse is lost? Where in Eclipse can you get a list of files it has included in its build?
I think I just need to know understand why Eclipse cannot find these modules within the project (i.e. drupal application) path to allow me to set breakpoints. Then I think I can carry on. So discouraging...
Thanks to anyone listening.
Thanks for the tip. I think I had seen your similar response in another post somewhere.
Actually, the solution for me was to make sure to include all of the standard Drupal file extensions in the Eclipse file associations preferences: Preferences->General->Content Types->Text->PHP Content Type. The defaults are various *.php, *.phpX, *.phtml extensions, but not the extensions used in Drupal modules -- *.info, *.inc, *.module, *.install, etc.
Simple and obvious once you figure it out. I'm surprised with all the Eclipse-xDebug-Drupal setup instructions out there that this had not shown up. Lots of details about matching project paths with server paths, but nothing about this.
I hope my struggle helps someone. I did learn a lot about Eclipse PDT along the way :-). Good luck.
Breakpoints are tricky in PDT projects:
for php files, you need to be careful
One thing that gets me a lot is that there a lot of "invalid" places where you set breakpoints. You can put the dot there in the IDE, but the debugger won't stop at it:
blank/non-code lines
on switch statements
in some types of callbacks (for example, preg_replace)
But for breakpoints in .module files, this should be related to a setup issue.
I made the following changes to my setup:
Upgraded from php 5.2.1 to php 5.2.3
Installed the Zend debugger client in Eclipse/PDT (theoretically not necessary from what I understand, but I decided to give it a try)
Made sure that the Drupal files were fully imported into my project, not just referenced as include libraries.
I did that last step after I created a tiny test case and discovered that I could get the debugger to stop on a breakpoint in an externally included file only if that file was imported into the project, not if it was referenced as part of an include library directory.
To my mind this seems like a bug - the debugger could certainly see that the files in the include library directories were source files and it let me set breakpoints in them, so it seems that it should stop on them.
(For comparison from a separate (java) IDE, IntelliJ will let you define breakpoints in jar files as long as you tell it where the source is. Once you've defined it, it will stop on it.)
I think it was principally that last step that did the trick, so I'd suggest that anyone else with a similar problem make sure that isn't an issue in their setup first, and then try the other steps.
check whether you opened your java file in java editor mode.
ie ctrl+shift+R, in this popup check the button beside OPEN option and select java editor.
The problem of not being able to set a breakpoint can occur if you have recently created a file. You must close and re-open the file for it to be recognised as a source file that can be debugged, and to enable the code highlighting.
Within the Netbeans 6.5's Tools -> Options -> Fonts & Colors -> Syntax dialog, you have the ability to change the look and feel of the Netbeans text editor. When you select a language, you are presented with a preview of your font/color scheme. However, when I preview Java, there are far more options for syntax changes than are being displayed in that preview window. If I were able to view a more robust piece of code, I'd be able to see the immediate effect of more of the options.
How can I supply a preview document to view my font/color changes?
UPDATE:
After looking into this some more, I've been able to narrow down the problem a bit. From what I can tell, everything in Netbeans is considered a plugin. The GUI editor is a plugin, and even the text editor is a plugin. This means that what ever piece of Netbeans that actually analyzes Java code and does syntax highlights is also a plugin (since Java is just one of many languages Netbeans highlights, it makes sense this is a plugin).
I think fromvega is on the right track with his suggestion. The tutorial for creating a manifest file editing plugin pointed me in the right direction. The tutorial eludes to a file used as a sample document used for font/color previews. It tells you how to create one inside this new plugin project. (Located in "Registering the Options in the NetBeans System Filesystem", part 4. About 4/5 of the way down the page.)
My next line of thought was to look for the Java syntax editing mode plugin and find this file and update it with a richer example file. I looked in the installation directory and came up empty, but I found what looks like the appropriate files within my user settings directory. There is a config directory with a lot of subfolders within my user directory (Windows: C:\Documents and Settings\saterus.netbeans\config).
I've been poking around inside this directory a bit, but have only found the xml files the manifest tutorial talks about. I have been unable to find the extensionless sample file for the Java plugin that I believe should be there.
Since I've hit a brick wall for the moment, I thought I'd toss it back to the SO community and see if you guys might make the last leap and find the solution.
Just for anyone who wants to alter this themselves it is possible on a unix machine to use grep to locate the file i.e.
grep -lr "some part of the current sample code" /path/to/netbeans
I used this method to locate the ruby example filename and from that identified that it is kept in org-netbeans-modules-ruby.jar as a file called RubyExample. By simply altering that file I was able to construct a better sample file for my own use.
Hope this helps someone!
The document which is displayed (for each mime type) is specified in a particular folder in the "system file system" (which is a NetBeans concept which is a virtual file system composed from contributions from individual modules; this is how functionality is dynamically registered in NetBeans).
Modules typically specify their system file system contributions in a file named "layer.xml" in the plugin. The create plugin templates typically offer to create this for you.
For example, here's how the Python example is registered:
<filesystem>
...
<folder name="OptionsDialog">
<folder name="PreviewExamples">
<folder name="text">
<file name="x-python" url="PythonExample.py"/>
</folder>
</folder>
...
Here, PythonExample.py is a sample file in the same directory as the layer file.
Therefore, what you need to do is create a plugin which overrides the existing registration(s) for the mime type(s) you care about and provide alternate sample documents. You may need to hide the existing registration first (see the _hidden
part from http://doc.javanb.com/netbeans-api-javadoc-5-0-0/org-openide-filesystems/org/openide/filesystems/MultiFileSystem.html ).
Hopefully this guides you in the right direction.
However, in thinking about it, we probably ought to make the preview area editable - so people can cut & paste whatever codefragment they care about right in there. This wouldn't be persistent, so whenever you change languages you get the original samples back - but it provides a quick way to see your own code. This shouldn't be just for the Fonts & Colors customization, but for the Formatting preview panels as well.
I've filed an issue against NetBeans for this:
http://www.netbeans.org/issues/show_bug.cgi?id=155964
-- Tor
I think you can only accomplish that with a new plugin, since you need somekind of parsing to define what is what.
Give a look a these tutorials, I haven't read them in details but they seem to show you how to do what you want:
http://platform.netbeans.org/tutorials/nbm-mfsyntax.html
http://www.antonioshome.net/kitchen/netbeans/nbms-coloring.php