How to clean up old artifacts of Liferay Service Builder? - liferay

Based on service.xml, Liferay's Service Builder generates Java files, directories, other files and database tables. It also extracts interfaces from code written after this generation.
When I rename a method or delete a class, Liferay does not clean up anything, the methods/classes/tables just stay there.
How to clean these old artifacts from a portlet project, with the same effect as if I re-wrote it from scratch again?

Warning: First make backups.
Clean the filesystem
Exit any IDE like Liferay IDE, Liferay Studio, Eclipse.
run ant clean to clear out generated artifacts so you can ensure the only thing left is your code after following the rest of the steps below.
Temporarily move your implementation files from docroot/WEB-INF/src/yournamespace/service/impl out of the way, for instance move it to your home folder.
Delete the following folders (and all of their sub-folders) from your portlet project:
docroot/WEB-INF/service
docroot/WEB-INF/sql
docroot/WEB-INF/src/yournamespace (make sure again that you have moved your implementation files to a safe place)
Clean the database
Open your service.xml
Take note of the content of the <namespace> tag, for instance MyNamespace
In your Liferay database, drop all tables that start with that namespace plus an underscore, for instance MyNamespace_.
Re-generate
Run the Service Builder
Move your implementation files back to docroot/WEB-INF/src/yournamespace/service/impl
Run the Service Builder again
Feel free to add your tips and more things to clean!

Related

Publish Web App files to different locations

I'm start to develop modules for DotNetNuke. I followed different tutorials(most by Chris Hammond) but there is something i don't like, and I'm searching a different way to do so.
He recommends to put a DotNetNuke installation, with IIS and SQL Server, on the developer PC and put your Project into the DesktopModules folder. I don't like it because i want to separate my project from DotNetNuke.
Is there a way to split the build/publish to different location like dll into folder x and all other stuff into folder y?
You could, but I don't really see the point. I see where you're coming from because it seemed awkward to me at first as well, but it really is the most efficient way to develop on the DNN platform. I have mine set up so all of my modules are in the same solution and branched in source from the root DNN folder. We don't keep the DNN core in source so the developer is responsible for that, although that may change at some point to keep versioning consistent.
By keeping your project located where it's installed, you can develop your modules the same way you'd develop any other web app you're building. If you make a change in markup you just have to save the file and refresh your page. If you change something in code just build and refresh.
If you really must keep them separate, you can absolutely do so (really the only benefit of this that I can see is that if you uninstall a module and accidentally click the checkbox to delete files - it happens - you don't have to worry about it). Create your project where you want it, change the Output Path to your DNN bin folder, and create post-build events to copy all of your .js, .ascx, and .css files (plus any others you may need - images, HTML files, XML files, etc.) to appropriate folder(s) in the DesktopModules folder. Just remember that you have to build the project every time you make ANY changes to test them, and you have to write/change your post-build events every time you add a new type of resource, change/add a directory, etc.
Either that or you can build an install package and uninstall/reinstall the module every time you change some padding in your stylesheet ... but I'd stick with keeping the project in the DesktopModules folder.
Sure you can do that.
Set up your solution and module projects anywhere, build the projects and copy the appropriate parts (such as the *.ascx , *.ascx.resx, *.dnn files) back to your website folder -
website/ DesktopModules/Your_module_name
Copy the module dll to the website's bin and you good to go.

Large solution ClickOnce distribution

I have a larger solution that I desire to distribute via ClickOnce. It consists of one main shell executable that directly references only a small subsection of libraries and processes that constitute the solution.
The solution consists of a few other processes and several libraries (some C++). I need to be able to include all of these libraries and processes in one ClickOnce distribution for both local builds and TFS server builds.
I cannot reference every other library and process form the shell project. And I do not wish to push these files into a MSI to be treated as a prerequisite as it would defeat the purpose of using ClickOnce to distribute/update the product.
What is the correct method to incorporate all of our necessary files/projects into a single ClickOnce distribution?
The IDE won't detect native DLLs as dependencies when publishing, but you can run the SDK tools directly to include them manually in your ClickOnce distribution. You can either use mage.exe in your post-build script or run MageUI.exe to have a wizard to guide you through the package generation.
Suggested reading:
Walkthrough: Manually Deploying a ClickOnce Application
Understanding Dependencies of a Visual C++ Application
There is an alternative to Visual Studio for this kind of situation. You could try using Mage, but it can be a little tricky to use. My company wrote an alternative called ClickOnceMore.
ClickOnceMore is a ClickOnce build tool for when you don't want or can't use Visual Studio to do ClickOnce builds.
There is a specific page on the UI for including files (using rules to include anything from a single file to an entire directory trees) so you should be able to do exactly what you need with it.
This is what I have done in a similar situation. I use TFS at work, so convert the terms to whatever you may use (or not use) for source control.
I have a main workspace that I use for all development of my application, I keep this workspace pristine.
I then created another workspace with a proper name (ex: solution-deploy) and in this workspace I do the following:
Get latest and merge everything from source-control into the deployment workspace
I build a Release build of my application
I r-click on the root (I put them in the root, because I need to access them from there, put them in whatever folder you want) project folder for my deployment project and select "Add -> Existing Item"
I browse in the file selector to the Release directory of the assemblies I want to add to my deployment package, select them, then I use the arrow next to the Add button and drop down to "Add As Link", do this for all of the assemblies you want to add and place them wherever you want them to be organized in your deployment
In the Solution Explorer, select the added assemblies and in the Properties window set the Build Action to "Content", this should be all you have to do, but others have had to also set the "Copy to Output Directory" to "Copy Always", I don't do that
Run a Release Build
Go to the Properties view for your deployment Project
Go to the Publish Tab and Click on the Application Files button
Your files should all be available and added to the Deployment
Set up your ClickOnce settings however you need them to be
Publish your ClickOnce package
Your published package should contain all of the assemblies you need now.
Keep your separate Deployment workspace set up this way and never check it in. Do your work in your development workspace. Whenever a new deployment is needed, open your solution in your Deployment workspace and get the latest code, build, then publish.

How to generate a javadoc in XPages

When I try to generate a javadoc, using the menu command Project\Generate Javadoc, the following warnings and error are produced for my custom classes in XPages:
javadoc: warning - No source files for package net.focul.utilties
javadoc: warning - No source files for package net.focul.workflow
javadoc: error - No public or protected classes found to document.
The packages are in the WebContent/WEB-INF/src folder which is configured in the build path and are selectable in the Generate Javadoc wizard. The classes are public with public methods.
Javadocs are generated for all of the Xpage and Custom Control classes if I select these.
You're experiencing this behavior because javadoc doesn't understand the Designer VFS (Virtual File System). It assumes that your project consists of a bunch of separate files in some folder structure on your local hard drive, not self-contained inside a single NSF. On the whole, the Designer VFS successfully tricks Eclipse into believing it's interacting with local files by intercepting read/write requests for project resources and importing/exporting DXL or CD records, etc. But apparently they haven't applied this sleight of hand to javadoc as well.
The Java source files corresponding to each XPage and Custom Control are processed successfully because, ironically, they are never stored in the NSF. During every project build, Designer discards any of these it has already generated and re-creates them based on the current contents of the various .xsp files. It then compiles those Java files into .class files, which are stored as design notes inside the NSF. At runtime, it's these files that are extracted from the VFS and executed... the source code no longer matters at this point, so there's no reason to ever bother including the .java files in the NSF, so they're just kept on the hard drive. One indication of this behavior is that the folder is named "Local" when viewed in Package Explorer / Navigator.
If you're using the built in (as of 8.5.3) version control integration (see this article for a great explanation of how to use this feature), you can tweak the Build Path to include the copy of the src folder stored in the on-disk project as a "linked source folder". This causes javadoc to consider the duplicate copies valid source files, and therefore includes them in the generated documentation. On the downside, it also causes Designer to consider them valid source files, which causes compilation errors due to the duplication. So this approach is only viable if you only need to generate the documentation on an infrequent basis, and can therefore break the Build Path temporarily just to run javadoc, then revert to the usual settings.
An alternative is to actually maintain your custom Java code this way on an ongoing basis: instead of creating the folder in WEB-INF inside the NSF, just create a folder on your hard drive that stores the source, then include that location as a linked source folder indefinitely. That way Designer can still find the source, but so can javadoc. NOTE: if you go this route, then you definitely need to use SCM. Because your source code no longer lives inside the NSF, providing the convenient container we're used to for getting the source code to other developers and ensuring inclusion in whatever backup schedule you use, the only place your source code now lives is on your local hard drive. So make sure you're regularly committing those files to Git / Subversion / Mercurial, etc., or, at the very least, storing them on some file server that is backed up regularly and, if applicable, accessible to all other members of the project team.
When you expand the net.focul.utilties in Designer, you will see all the methods and properties. But when you click on on of the methods, you will see neo source code.
So this is where javadoc fails to generate the documentation. I guess that the author of the application has not provided you with the source code. If you have the source somewhere, you can attach this code and then javadoc will be able to generate the documentation.
I run into the same situation and I have found the most straightforward method is to export the source to an external folder and then use regular Eclipse to generate the JavaDoc. Not sure my process is any less of a hassle than Tim's suggestions but for me it just feels less risky than trying to deal with the VFS vagaries.

Need to change template styles in Liferay

I want to change look and feel of liferay using css. i am very new to liferay. Can any give me any idea to do the changes. Thanks in advance
The step-by-step seems complicated, but it's not that bad .....
1a) download and unpack the plugins sdk for the version of liferay you want to use. All the downloads are on the sf page http://lportal.sourceforge.net/
1b) make sure you have the latest version of ant and the JDK version that matches your liferay version (1.5.x or 1.6.x)
2) there are a few main folders in the kit. Change into the "themes" folder and run the create script there in this format (on linux or mac you'll need to make the .sh files executable)
c:\liferay\plugins\themes >create my-name "My Theme Description"
linux/mac $>./create.sh my-name "My Theme Description"
This will create a skeleton theme in a folder called my-name-theme and a folder within it called _diff.
Make whatever modifications you want WITHIN THE _diff FOLDER. (except changes to the properties file within WEB-INF)
Once you've made changes run "ant compile" from within the my-name-theme folder and the sdk will run through it's paces and spit out a .war file to the "dist" folder in the sdk root. You can upload this to the site using the plugin installer
OR ... if you configure the sdk to know where your development server is you can run "ant deploy" from the theme's folder and let the autodeploy magic in liferay do the work.
Once the theme is installed just assign it using the "look and feel" tab in the "manage pages" tool.
TIP : Make most of your changes to the custom.css file .... keeps things easy to upgrade.
TIP : Development is really slow for CSS if you do this for every change .... so if you're running a dev server add a style tag just before the end of the head tag that points into your _diffs/css folder. href="file:///...../_diffs/custom.css". This way whatever edits you make will be compiled into the next version of the war and will override the currently installed version without reuploading. make sure to remove the link before you put it on a live server.
The liferay.com documentation is great and there's a "themer's guide" i can't find the link to right now that got me started.
We've done a number of LifeRay customizations for various companies but your question is too vague for us to answer. If you are just looking to change a few colours and fonts then editing the CSS is fine, but if you are looking to completely change the layout then you need to delve in to the template files and start working with the XHTML.
Provide more details and we might be able to prod you in the right direction :D
IMO theme development for liferay can be quite slow to start with. I have found two different approach quite useful. It works for me, might work for you as well.
If you edit files inside _diff folder AFAIK you have to deploy every
time two see the changes , which can be quite frustrating for
front-end developers. An approch can be edit the css file directly
in tomcat/themename folder. Copy the changed every couple of hours
or so in the _diff folder and deploy. In my case the CSS stays in
C:\liferay-portal-6.1.0\tomcat-7.0.23\webapps\\css\
Also if you are aware liferay supports Sass now. So it you are writing Sass "deploy" may be you most likely option. But I have also figured out a way to speed up that process. Install ruby (if you are in windows, in Mac its preinstalled) > Install Compass > and create a blank compass project. Start "compass watch" . Open bothe scss file and the compiled css file in your IDE. "compass watch" will poll for changes in your scss file and put the compiled output in the css file. Every while you may copy the css output in the css file in theme folder or directly in firebug or web-inspector in chrome/safari.
I have found these are faster dev practice than deploying everytime or completely developing on firebug/web-inspector.
Also if anyone know of better method, specially things like only CSS/JS deploy (or simple copy for that matter if one is not writing Scss), please let us know.
You can make your custom style with the liferay plugins sdk, which can be found here: http://www.liferay.com/downloads/liferay-portal/additional-files
There is a themes folder included, in which you can create a new theme. Liferay generates here a basic theme as a boilerplate, which then you can customize and deploy to your liferay installation.
You can
mvn archetype:generate
then select “liferay-theme-archetype (Provides an archetype to create Liferay themes.)” et voilà you are ready tu customize your theme.
Best practice recommends that you make all your custom themes using only the custom.css file, and that you not override any of the templates unless absolutely necessary. This will make future upgrades far easier, as you won't have to manually modify your templates to add support for new Liferay features.
Deploy the newly created theme using
mvn clean package liferay:deploy

how to modify SubSonic 2.1 code generation

I would like to add basic logging and make some other minor changes to the classes generated by SubSonic 2.1 (I'm not using SubSonic 3.0 t4 templates).
Is there a way to do this without modifying the SubSonic source code?
You have two choices. You can modify the default templates or create your own. I suggest making your own templates which will lives side-by-side with the original and then generate your code via the following instructions.
Note that these steps assume you ran the default SubSonic installation. In other words, Sonic.exe and the default templates can be found under c://program files/. If not, you'll find your SubSonic files/templates in an alternative installation location, of course.
Make a copy of the default templates folder as found in C:\Program Files\SubSonic\SubSonic 2.1 Final\src\SubSonic\CodeGeneration\Templates. I might recommend naming the copied folder "TemplatesWithLogging.”
Open the aspx files in Visual Studio and modify to your heart’s content. For example, I wanted an alternate C# class template so I modified CS_ClassTemplate.aspx. If you want to merely alter the default templates, you can but I suggest making a backup first.
I am going to assume you are already familiar with code generation with SubSonic. I personally like to setup a Visual Studio External Tool to allow for quick, pre-configured regeneration. Otherwise, the following can be ported over to the command line. Here’s the External Tool setup instructions:
Tools > External Tools > Add Title: TemplatesWithLogging
SubSonic Classes Command: C:\Program Files\SubSonic\SubSonic 2.1 Final\SubCommander\sonic.exe Arguments: generate /out Generated /namespace NAMESPACE /server SERVER/db DATABASE where NAMESPACE, SERVER and DATABASE are replaced accordingly.
Initial Directory: $(ProjectDir)
Check “Use Output window” and “Prompt for arguments.”
Select Apply or OK
4.Select the project which will contain the “Generated” folder and auto-generated files. Select Tool > TemplatesWithLogging.
You can find more here.
Yes you can modify the templates that version 2 uses, they're just aspx files. The templates are stored in src\SubSonic\CodeGeneration\Templates under your installation directory.
This blog post goes into more detail:
http://johnnycoder.com/blog/2008/06/09/custom-templates-with-subsonic/

Resources