I am new to sakai, i want to add my own tool in sakai source code like announcement,syllabus...etc That tool having some my own functionality for this what i have to do, how can i develop my own tool in sakai.
Thanks.
Use one of the archetypes to get you started, then customise it. When you are comfortable you can change the UI layer to be whatever you like.
https://confluence.sakaiproject.org/display/BOOT/Developer+Tools
If you are looking for a solid "base" tool shell to begin with tool development my recommendation would be to start here: "Sakai Wicket Maven Archetype". There are a few other very good archetypes available but are often outdated and may cause you some problems based on my experience. This has been the one I've had the most success with.
This uses Wicket but does not mean you have to use Wicket to develop further with it. Make sure to pull the 1.2 version as last check the binaries for the others were not available yet so replace -DarchetypeVersion=1.4.1 with -DarchetypeVersion=1.2 It will compile and deploy successfully as a tool "as-is" that you can modify as needed. It also allows you to code in Java to directly access the sakai API and pull from its database or even add your own tables. I've successfully used it with NetBeans 8.0.1 and MySQL 5.6 under Windows 7 with Maven 3.2.3 and Sakai 10.1.
The code is well-documented and is no-frills but with enough varied functional use examples to allow you to do "almost" anything you want. The wicket manual is 600+ pages but in my experience you should be able to accomplish a lot just by looking at the code in the archetype.
Microsoft has always been adamant about their use of "dogfooding" in the software development process, and it's made tools like Excel and Visual Studio work pretty well. My question is this: Do Microsoft employees use VSS? Have they ever used it? If not, what do they actually use? It seems to be such a flawed, inadequate version control system that I can't imagine that a competent developer would put up with it!
See the following links for details:
http://www.highprogrammer.com/alan/windev/sourcesafe.html
http://www.developsense.com/testing/VSSDefects.html
http://www.codinghorror.com/blog/2006/08/source-control-anything-but-sourcesafe.html
I believe that nowadays most of the groups either do currently use or are migrating to Team Foundation Server.
It's not clear to me that Microsoft has ever come out and described in detail the tools they use, but I have heard in some deep, dark corners of the internet that the large teams (Windows team, Office team, etc) have, for a long, long time, used what is essentially a custom version of Perforce for version control. I have been led to believe that some teams have (attempted to) made use of SourceSafe, but it's never been widespread there.
They use Teamserver for source control (or so I was told whilst attending a visual studio event at the Reading campus)
Well the topic says it all. Can I use google web toolkit to generate my views to be used in Castle Monorail project and render it through nvelocity view engine. Is it at all possible?
I don't know of anyone that has tried this, but GWT is a server-independent technology so in principle I don't see why it wouldn't work. GWT needs some server-side plumbing which you'll probably have to write yourself (again because I haven't found anyone that has done this before).
You might want to check out Script# which is similar to GWT but you code in .Net, it has MSBuild support, Visual Studio integration, etc.
I would like to be able to create FogBugz cases directly straight from the editor in NetBeans. Specifically, I would like to be able to look at a JUnit run in the IDE, examine the failures and create cases directly using the information that is right in front of me (rather than cutting and pasting into a web browser, etc).
I see that NetBeans 6.5.1 ships with Bugzilla available by default and JIRA connectivity in some sort of beta form. Is there an equivalent FogBugz issue tracker?
PS: I am aware of the new plugin architecture of FogBugz 7. However, I have a realistic appreciation of the time that I would be able to commit to creating my own plugin for either NetBeans and / or FogBugz and I suspect that I would be able to make just enough of a partial solution to make my life worse rather than better.
It appears you may need to write one yourself, as they have plugins for Eclipse and Visual Studio, but not Netbeans.
http://www.fogcreek.com/fogbugz/blog/post/Eclipse-Plugin-For-FogBugz.aspx
I am not aware of such plugin. You're right that it is not trivial effort to write full-featured connector, but getting basic one is not that hard ... especially if you're already familiar with NetBeans plugin architecture. If you decide to go for it, take a look at FogBugz API instead of new FogBugz plugins. FogBugz API is used to talk to remote FogBugz repositories.
I'm trying to implement a version control system, but as most of us know designers don't feel comfortable with version control systems. I'm looking for a solution mostly for our designers using Photoshop, Flash and other design tools.
It's not a big deal to use a version control system, like VSS 2005, with our frontend and backend coders, but we have some serious problems with our designers. They mostly refuse to use version control systems, and they are right at some points, mostly on productivity level. They mostly work on more than one file, and on more than one application like Photoshop and Flash.
I don't know if version controlling is the right answer or not. Maybe we have to implement a backup system, but there has to be a versioning system, I think. I and our designers are very tired of doing the same thing or going back to the previous designs over and over again.
It would be wonderful to know how digital agencies overcome this problem. If version controlling is the answer, please share your tips on how to make designers comfortable with version controlling.
EDIT 1: Maybe it would be great to have a solution like Dropbox, as it doesn't disturb you with check-ins/check-outs. All you have to do is to open up a file, work on it and save it, the rest is handled by Dropbox.
EDIT 2: We are on Windows, so no chance to implement anything other than Windows support :(
Thanks...
I haven't actually ever done this with graphic designers, but is it possible that Subversion's WebDAV support might work for them? You can mount a WebDAV share as a drive under Mac OS X and Windows XP & Vista, I believe. Each save becomes a new revision in the repository.
And as for your second, hidden question: Yes, you do need to implement a backup system. At least if you value your data.
Adobe has it's own version control, Version Cue, which is bundled with the Creative Suite package. http://www.adobe.com/products/creativesuite/versioncue/sdk_overview/ Apparently, Eclipse can plug into this. I haven't tried it extensively, but I know it integrates nicely into the file dialog in Creative Suite.
NOTE: Version Cue has been discontinued by adobe after the release of CS5:
http://www.adobe.com/products/adobedrive/
Adobe Version Cue maybe?
You might want to try subversion because there are plugins for windows explorer and max OS X finder. integration with the filesystem has been a big help for me on projects where non-developers had to work with source control. This includes projects that have had designers.
Another key thing that helped was having a good directory structure for the files the designers and other non-developers worked with.
I just came accross ConceptShare and it's pretty great...it's not automated version control but you could use it for that and it's a great way to collect and document feedback.
You can try Subversion (installed on a local or remote server) plus Adobe Creative Suite plug-in that would face the designers - Pixelnovel Timeline
It's compact, has previews of all versions (submitted via the plug-in), works for Photoshop, Illustrator & InDesign.
If developers also use Subversion, everything (code & design) can be kept in one place.
Instead of trying to integrate a version control system with lots of applications on different operating systems, you might want to have a look at copy-on-write file systems such as http://en.wikipedia.org/wiki/Ext3cow. That way your designers won't even notice a difference; all they will have to do is save their work to a network share on a linux/samba server using ext3cow.
I'm both a designer and coder. I usually version control code (text data) with git, and simply use "save as" with a version name for graphics (binary data). And I run Apple's Time Machine on top of all that, for safety.
To me, version control on graphic files would just be a burden. I'd have to roll back to see changes, and you wouldn't even get one of the great features of version control: see the changes you did in a specific commit just by looking at diffs. The log feature is nice though, to see how you progressed in time, and notes, but to me personally it's not worth it.
Take a look at Perforce - it has a plugin and tools that allow you to use it from within designer tools such as Photoshop, its also super fast and integrates well with Visual Studio - runs on Windows as well as Linux
What I did once was create a "Snapshot" shortcut on the desktop that added and committed everything from a specific directory.
If every designer commits to their own branch (trivial with a DVCS but easy with SVN too) there will be no conflicts, and the cross-branch merging can be done at intervals by someone who isn't afraid of it.
I've been having my eyes on GridIron's Flow for a while now. It looks like a competent version control suite that has some neat asset management features such as visualization on graphics between versions and relationships between different assets. Flow has support for handling files for adobe photoshop, illustrator, flash etc. However as of now (early january) GridIron hasn't released Flow yet other than having to announce the beta program.
Most digital agencies that I know of that mainly do web development use Subversion for version control. To avoid conflicts on image files an artist will lock the files he or she will work on. That way, another artist won't do the mistake of overwriting changes. This requires some coordination among artists and devs so that noone steps on anyone shoes. Also, if someone forgets to unlock, there is the possibility to break locks.
If you're into distributed version control you might want to take a look at Mercurial as it has good support for Windows and has some neat cheat sheets. The Ruby kids are using git but is rather lacking in Windows.
Before using version control with artists, at least make sure they know the basics of version control and let them fool around with it in a sandbox. Also make sure they've set up some basic rules of conduct when collaborating with each other and interacting through version control (i.e. ways to make sure they don't destroy each others works or step on each others toes).