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.
I have a subversion repository with a layout like this:
/trunk/<projectname>
/branches/<projectname>/<branchname>
/tags/<projectname>/<tagname>
It is this way for historical reasons, which aren't really up for debate and so I won't go into here.
I'm trying to use this layout with Eclipse (Juno) using the Subversive plug in. The .project file lives in /trunk/<projectname>, and I can check out a project from trunk with no problem. However if I try to create a new branch for a project using subversive, I seem to get into trouble. Creating a branch with a path /branches/<projectname>/<branchname>, it gets transformed into a branch /branches/<projectname>/<branchname>/<projectname>.
The repository properties dialog has no visible options which allow for this layout - although the Advanced tab has fields for "Resource names" which default to as "trunk", "branches" and "tags", these evidently cannot contain a path separator without being rejected as an "invalid resource name"
I've read the documentation for Subversive. It talks about a "Repository Location project layout", and states that with this "the user is free to change this layout by any way he wish" [sic] - but it doesn't really explain how.
In short What's the correct, or most expedient way to use this layout within Eclipse?
Note, I really need a way which will appease those users uncomfortable with the command line subversion client, so dropping to the command line won't be a very satisfactory solution.
I have not used it, and I'm not using eclipse for branching/merging operations, but in Window/Preferences/Team/SVN > project structure, you can modify project structure.
Not sure exaclty what it do , but you can try playing with structure settings and manual specification.
Command line subversion don't really assume a structure, given a tag/branch is only a simple (remote preferably) copy, so you may be able to just copy from Eclipse (IIRC it's possible in the repositories view).
This has been answered on the Eclipse Subversive forum here:
http://www.eclipse.org/forums/index.php/mv/msg/674039/1274614/#msg_1274614
To quote:
It is not the one of recommended layouts, so the automation is not available for it. In order to use such a layout you should open plug-in preferences and change the following option: Window->Preferences->Team->SVN->Project structure->Branch and Tag settings from "Respect project structure" to "Manual specification"
I have checked and it does seem to work, although unfortunately it is a global setting and not a per-project setting.
right now we are using svn to share code for our force.com/visualforce project. It works great controllers, components, pages and static resources.
The problem is it seems the salesforce.schema file is not really a local file, its a placeholder that checks your server and tells you your current schema.
We want to baseline our schema changes/updates to a file so we can share in svn.
I found this:
http://boards.developerforce.com/t5/General-Development/Custom-Objects-in-Force-com-IDE/td-p/445363
But we cant seem to figure out what do do/how to get it to work.
So in a nutshell, we are looking for a way for Developer A to create a custom schema object in their own SF Sandbox, somehow get this info into a file in svn (ideally through the force.com ide), then check it in so developer B can check it out and apply it to their server. (the same way we do for code).
Any help would be great!
thanks
Joel
Ok, we finally figured this out through trial and error:
To make this work:
right click on project, click "Force.com/Add Remove Metadata Components"
go down to custom ojbjects, open that up, make sure all your custom objects are checked, click apply, then say "NO" to dialog
then right click on src and click "Force.com/Syncronize with Server, find your objects, and click "Apply Server to Project"
now your files will be local, check them into SVN and you are golden.
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 spend some time customizing the colors for syntax highlighting in Eclipse (Java, JSP, HTML, CSS, etc.) but whenever I try to export these settings via File|Export|General|Preferences and reimport them, the settings never completely get imported back. Some colors are restored and others are left unchanged, leaving me in an 'in between' state - very frustrating.
I'm using Eclipse 3.4 Ganymede, by the way.
Has anyone found a reliable way to save and restore Eclipse syntax highlighting settings?
I finally figured out how to do this.
I just wanted to mention beforehand that I did try to start with a fresh Eclipse install, export the preferences to a .epf file, change just one single setting, export again, and compare the files. To my surprise, trying to import settings from a minimal .epf file did not work reliably either.
The solution that worked for me was to copy these files: {Eclipse workspace directory}/.metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs
I tried a fresh Eclipse install on another machine and after copying those files over, all my settings were restored perfectly.
The solution was to copy SOME - not all - of the files from {workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs into my other workspace.
In particular (per the https://stackoverflow.com/questions/96981/color-themes-for-eclipse thread):
org.eclipse.jdt.ui.prefs = Syntax Coloring
org.eclipse.ui.editors.prefs = Text Editors
Copying other files caused things to break.
There are a couple of notes to add:
I had to copy the aforementioned pair of files several times before I got the correct syntax coloring.
Be sure to close the workspace, if it's open in Eclipse, before copying the files.
This worked with Eclipse Helios.
If you want to be a little more fine grained on what you migrate, the syntax highlighting rules are the lines starting with semanticHighlighting on workspace-indigo/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs
Doing this, I was able to migrate my syntax highlighting from Helios to Indigo
I'm using JBoss Developer Studio 10 with the Eclipse Neon 4.6 engine.
All .prefs files are inside this path:
/workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings
Update: I found a similar structure on this path too:
\RedHat\JBossDev\studio\configuration\.settings
It's my IDE folder plus \configuration\.settings
I recommend search for org.eclipse.*ui*.prefs instead *.prefs to refine your result.
The principal config files are:
org.eclipse.jdt.ui.prefs
Java Syntax Color Settings
org.eclipse.ui.editors.prefs
Text Editor Settings
org.eclipse.cdt.ui.prefs
Formatter Settings
org.eclipse.wst.jsdt.ui.prefs
JavaScript Syntax Color Settings
org.eclipse.jst.jsp.ui.prefs
org.eclipse.wst.css.ui.prefs
org.eclipse.wst.html.ui.prefs
org.eclipse.wst.json.ui.prefs
org.eclipse.wst.dtd.ui.prefs
org.eclipse.wst.xml.ui.prefs
org.eclipse.wst.xsl.ui.prefs
If have a problematic workspace:
Copy the files above
Create a new workspace
Copy and Replace that files in your new workspace
This will recover perfectly your custom editors color settings. For me worked very well.
Eclipse CDT stores 'Syntax coloring' in the file org.eclipse.cdt.ui.prefs
This is located for example here: C:\eclipse\workspace.metadata.plugins\org.eclipse.core.runtime.settings\
Copy and paste over the top of the one in your new eclipse instance. This worked for me when moving from 3.4 to 3.5
I would export the preference before modifying the color, and then after.
That way, you would be able to isolate the specific rules of an eclipse preference file into one smaller file and:
check if some colors not restored are indeed represented by a rule
the import of a smaller preference has any effect on the previously unchanged settings.
That kind of strategy can be further refined into several small settings files (one for Java, one for JSP, HTML, CSS, ...), in order to better analyzing the potential side-effects when re-importing those settings.
I have had success in importing Eclipse Helios's syntax highlighting rules by copying the file:
.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs
from the source workspace to the target workspace. It seems this file also contains Eclipse's code formatter profiles and code templates.
Environment:
Version: Helios Release
Build id: 20100617-1415
(on linux)
Once Michael Bosworth's answer helped me to some extend and I voted up. But now I see some obligation to answer it myself, because copying these two files are not enough. Let me explain why.
First, these files contains lines irrevelente to syntax coloring.
Second, syntax coloring for other editors are located elsewhere, for example, those of XML files are in
org.eclipse.wst.xml.ui.prefs
and those of HTML files:
org.eclipse.wst.html.ui.prefs
JSP pages?
org.eclipse.jst.jsp.ui.prefs
, etc.
Third, when we change font colors, usually we change background colors, line highlighting colors, etc. to get a clearer view of codes. This involves more files.
If we search *.pref files in path
/workspace/.metadata/.plugins
we can find all preferences files where we can locate all lines of coloring settings. But by copy-pasting all these files to another workspace can also trigger problems, for they are not exclusively syntax-coloring-related. Moreover, when we are switching between two versions of Eclipse, unexpected problems may arise.
So, the safest way is:
Create a new workspace if you don't have one.
Open all *.pref files we find in the workspace one by one,
Copy those lines containing color codes,
Find the same file in your new workspace,
Replace the color part by existing one. Or, set the colors in Eclipse, by assuming the corresponding options according to properties' name. All color codes are RGB based.
EDIT: (2017.02.24)
Eclipse Mars has a plugin Oomph, which can record your preference settings to provide seamless transmission of your preferences. When you activate it, every time you change a value, it prompts to ask you if you want to record it in Oomph, providing you the exact line in the corresponding file where your new value is stored. So, when you install Oomph, you can:
Change the settings of your font face, font size, background color, etc.
In the prompt windows of Oomph, take note of the location of your new settings. (Because if you tell Oomph to remember your settings, it will not prompt never again, so you may only see this windows once.)
I have deleted recently changed *.prefs file from the following dreictory \myworkspace.metadata.plugins\org.eclipse.core.runtime.settings\ and imported existing exported preference.
I am the first person, who answer for this question as per my knowledge :), Cause even I struggled lot.
Thanks
I faced the same problem few days ago.
The easiest way to restore the defaults is to import the default theme again, which you can find under:
http://eclipsecolorthemes.org/?view=theme&id=790