I have a Liferay 6.1 instance with a custom classic theme, but trying to upgrade it to 7.0 is being so painful that I decided to take Liferay 7's classic theme (downloaded from here).
To bring it into Eclipse - Liferay IDE I created a new module (theme) project and imported files, but trying to deploy it was sending errors (for example, no init.ftl, stuff like that, unexpected given I am using the repo source).
When I arrived to this error, solved it and tried to deploy, it again said there's no init.ftl... Then I searched for it into the war and it actually wasn't there! No idea about what but... I noticed a portal_pop_up.ftl that doesn't exist in my source code!!! What is going on? I'm pretty confused.
Thanks!
Ok, the problem was with code downloaded from Github.
If you want to use classic-theme, just create an "empty" theme in the IDE and then overwrite it's files with the ones from auto"deployed" classic-theme in the L7 instance, in /opt/liferay/osgi/wabs.
Related
I deployed a portlet in liferay 7 and it got deployed successfully and was available for use. I want to replace the jsp file, in earlier version I could see my application in tomcat/webapps folder and replace it quickly.
Now I am unable to locate the exploded war in liferay 7. I can only see the war in osgi/war folder.
Can someone help me with that.
Thanks in advance.
While I mostly agree with what Olaf wrote, I do understand the need to be able to make changes in JSP files and try them quickly during development. I'm afraid I don't have the solution for that yet.
However, let me answer the question you asked:
where is war exploded in Liferay 7 tomcat after getting copied in osgi folder
It is NOT (at least not the way it was done by application servers)! When you deploy a WAR file in Liferay 7, it will automatically (on the fly) convert it into OSGi bundle and install it in OSGi runtime. This way now Liferay is fully in charge of deploying plugins and does not need to rely on various application servers.
PLEASE NOTE: Every bundle has it's own state folder. In Liferay those are in <LIFERAY_HOME>/osgi/state. If you know the bundle ID you can easily find it. It may be (I haven't checked) that you'll find some JSP files there. The reason I'm writing this is to warn you (in case you figured it yourself) to NEVER modify bundle's state folder manually. Doing so may brake the whole environment. In worse case scenario you may have to redeploy everything in clean environment.
You should not rely on behavior like this. In previous versions it was the task of the application server to compile changed JSPs at runtime. However, this is bad practice in production systems and totally screws up your maintainability. If you need to update some UI code frequently, I'm suggesting you change your implementation to utilize ADT (Application Display Templates), e.g. through Freemarker or Velocity. Those are meant to be updated at runtime, where the JSP updates were a side effect of Tomcat's default (development friendly, production hostile) configuration
I'm trying to set up a development project in vs 2012 with nuget and Umbraco. I am aware of the several recipe's, amongst the better Umbraco for beginners: Setup Umbraco on localhost together with VS 2012 and uSiteBuilder.
When I am using this procedure I install Umbraco with nuget and build it without problems, but when I hit F5 I get the same error continously: "Could not load type Umbraco.Web.UmbracoApplication" which global.asax inherits from!
What is wrong, what am I missing here...? Thanks in advance /Finn
A bit late, but I had the same problem and the reason for that are missing dll's. Referenced libraries weren't copied to bin folder.
It is not the best or easiest way of setting the project up.
Instead of creating a WebForm project, create an empty MVC4 project and then install the Umbraco CMS from NuGet. This way you won't have to remove anything. It will also by default use IIS Express, so there is no need to change the project properties.
You don't even have to use the NuGet console. You can use the package manager and just search for Umbraco.
Well it seems like an unprofessional oversight from my point! I just forgot to give security access to the relevant folders to network service.
You might have to build and clean the solution a couple of times if you get exposed to the YSOD error: "Cannot create/shadow copy 'filename' when that file already exists" when you hit F5! This error might occur if you hit F5 too quickly after a build, in this case asp.net is probably not finished with whatever it has to complete, and the file is locked.
#Digbyswift: I do not agree with you! Whether you set up your project as an MVC or Webforms application, it doesn't matter. What is important though, is that you use empty applications, as if you don't there will probably be some references/dependencies that you have to delete in order to get the application running! And default server will be the vs dev server, which in my opinion is by far the best and easiest to use untill you are ready to deploy your application. I agree thouhg that using the package-manager from visual studio is the easiest way to come around installing Umbraco.
Following these steps and hints you should use no more than a couple of minutes from installing Umbraco untill you have the wellcome screen and is ready to set up db etc...
Cheers Finn...
I'd like to ask you for best practices with developing with Liferay SDK.
I have the SDK downloaded, I have Eclipse ready, it works, I can create new portlets and run local Liferay instance to test it.
Here is my situation - all the source code I have is in the Eclipse workspace, currently it is only portlets what I'm working on.
Liferay SDK I have in completely different location than workspace. Let's say ~/dev/liferay_sdk.
Eclipse workspace is located in ~/workspace.
At the beggining, it was not working like that. Eclipse from some reason can't find or use Liferay SDK. When I changed "Project validation" in Eclipse/Liferay configuration to "Ignore" the "Liferay Plugin SDK is not valid", it started to work without problems.
Next problem happend when it comes to need to build a WAR for example.
In the portlet directory in the workspace is present "build.xml" file. But inside it refers to another xml file, which should be located one directory up, and this one refers to more thing in relatively location and so on.
In short, it assumes that you have the portlets etc, inside the Liferay SDK.
Like "~/dev/liferay_sdk/portlets".
My question is, Am I wrong completely, or could you suggest me the best practices with this?
I don't want to mix SDK and the code, it sounds wrong to me.
Thanks for help!
I think, the best practice is still when your portlet projects are located inside the Liferay Plugins SDK directory. That way you can take all the advantages of the Liferay IDE plugin for Eclipse, for example. Because as far as I understand Liferay IDE will not allowed you to have portlet projects in another location. It's pretty easy to import projects to Eclipse from inside the Liferay SDK directory, and that's not problem.
But I also faced the same sort of problem when tried to save portlet project to the Git repository. Possible solutions with symbolic links didn't work correctly on every system. Thus I slightly modified the build.xml file to be able to run ant tasks from any directory. For portlets it was something like that:
<project name="your-portlet" basedir="." default="deploy">
<property file="build.properties" />
<property name="project.dir" value="${liferay.sdk.home}" />
<import file="${project.dir}/build-common-plugin.xml" />
</project>
Notice that you should define property "liferay.sdk.home" in build.properties and it should be path to the Liferay Plugins SDK.
As for other types of Liferay plugins (themes, hooks, etc.) you should import another build file for building that type of plugin. For example, for themes it will be:
<import file="${project.dir}/themes/build-common-theme.xml" />
Hope you'll get the idea. :) But think twice before doing something like that.
Liferay plugins are developed inside the Liferay Plugins SDK, its called SDK for a very good reason.
I don't find anything wrong with the plugins-SDK and the code tied togather, below are few reasons why:
If you see the liferay repository of plugins on github, you would find all the sample portlets and other plugins are stored in their respective folders inside plugins-SDK.
So if you want to develop liferay plugins (with or without IDE), the best practice (the only efficient way I think) is to have the projects created inside the respective folders of plugins SDK like portlet projects inside portlets folder, hook project inside hooks folder etc.
If you have used Liferay IDE when you create a plugin project (Liferay project) in this IDE you specify the SDK and the server runtime and what it does is it creates the project inside your Plugins SDK and copies the .settings, .classpath & .project file inside the project created. It does not create the project inside your workspace as eclipse normally does for other projects.
Hope I have managed explain it clearly and this was what you wanted.
I'm already quite happy with the other answers, this could have been distributed through comments at those, but a separate answer gives some more structuring options:
As Prakash says, it's not really bad to do that. In addition to his answer, you do not need to have your code in the workspace directory. Eclipse is happy to put it anywhere in the filesystem - thus while you work with Eclipse you don't even care where exactly your code is (and as you check it into version control - right? - you actually never need to care.
If you want to use Liferay's OOTB ant scripts: They are geared towards exactly the setup you describe: Work in the SDK directory. It's actually not bad, but if you don't like it, you just have to accept that you can't work with build.xml without changing it (like Artem suggests).
Another option is to use maven - this also bypasses the sdk (and the Liferay IDE integration), so you're again free to put your sourcecode whereever you like and let maven do the rest.
I can imagine some rather esoteric and rare issues with Artem's suggestion (like referring to custom parent themes when you imply some relative position) but I consider that as extremely minor, so if that works for you: Go ahead. Just keep in mind that you don't fulfill the basic assumptions that the SDK makes, so you might have to change things that violate the assumptions. I can't imagine this being too hard if you keep this in mind.
Of course, what you miss with that solution is the neat handling of including build.${username}.properties - you'll have to have your own build.properties that define ${liferay.sdk.home}. If you're not working in a team, that's ok. Otherwise you'll have to invent this yourself (and code it) or rely on global parameters to be configured with every team member.
I'm building a new Liferay theme and being crushed by this problem.
When I make changes to the init_custom.vm, the only possible way for me to see the changes is to restart Tomcat. When I make other changes to my theme, such as editing my CSS or adding images, I can see the changes after deploying the theme via the Ant Deploy target. No such luck with the templates.
I checked the $CATALINA_HOME/webapps/my-theme/init_custom.vm after deploying, and that file does reflect my changes.
I cannot continue to develop if this is going to be the cycle. I must be able to make changes to the velocity template without requiring a restart. Any suggestions?
I'm using the Eclipse Liferay IDE and the Ant build to deploy my theme when I make changes. I'm using the Liferay 6.0.6 Tomcat bundle. I've also already added include-and-override=portal-developer.properties to my portal-ide.properties file.
Thanks!!!
(also asked this in the Liferay Forums, and I'll make sure to copy back any answers I get: http://www.liferay.com/community/forums/-/message_boards/message/11292911)
Liferay also caches everything Velocity related which sometimes can present itself in the way you describe: changes to templates don't seem to show unless you restart Liferay. You can turn off this behavior if you set the following property in your portal-ext.properties file:
velocity.engine.resource.manager.cache.enabled=false
I switched to the 6.1 Beta and do not have the problem on that release, so it was just with 6.0.6.
Also: I've seen How to edit a velocimacro without restarting velocity? and Testing JSON API in Rails 3.2 using rspec using exact PUT/POST bodies as Backbone would send and they did not work for me. Upgrading to 6.1 beta did, for some reason, work.
Please note. Before anyone tells me about how I should compile the code for performance etc... this is just for a personal project and I want to be able to edit the code in a regular text editor and then it just works.
I usually code in C#, but this would be VB:
I have three files in a Virtual Directory
test.aspx
test.aspx.vb
web.config
I have copied the .Net 3.5 web.config line for line from a File > New Project.
It's not recognizing the XDocument class. Says, it's not defined Since this is a .Net 3.5 class, I figure it has to do with .Net 3.5
So, here's the question: Is this even possible to run a single page without compiling? Asp.Net should compile on the fly. It works with 2.0. Is there something I'm missing?
Just add the assemblies to the web.config file (sorry cant recall the exact place to put it, but a normal VS generated one should have a few entries already).