I have the same problem that has already been documented on GitHub here. ui-tinymce references a number of dependencies which cannot be reached in my application.
GET http://localhost:8080/jspm_packages/github/tinymce/tinymce-dist#4.3.12/themes/modern/theme.min.js # angular.js:6084
tinymce.js:9426 Failed to load: /jspm_packages/github/tinymce/tinymce-dist#4.3.12/themes/modern/theme.min.js
I am able to use the workaround suggested in the github issue above, which changes the baseURL. This works fine in my development environment. However, when I run jspm bundle-sfx it does not pick up these dependencies and I am left in the same situation without templates or plugins.
What is the best way to address this? Can angular-ui-tinymce be broken down so that the dependent files are available in separate packages? Or should I just use gulp to get around this problem?
I tried using Gulp to concatenate the missing files, however this will not work because by default tinymce still expects the files to be at the relative locations which it uses in its own internal file structure.
I still think it would be helpful for Tinymce to provide separate packages for the most common themes, however I admit that there are a lot of themes and plugins so this would be a fair amount of work.
In the end the simplest thing to was to copy the theme and plugin files into the "correct" relative directories within my own source code. This way I can change the relative baseURL for tinymce and it will be correct when I run it in production as well as development environments.
This way I can run jspm bundle-sfx and it will bundle these files along with everything else. However you may have to import the files explicitly if you do not serve the area statically in your application. For example:
import 'sysadmin/app/tinymce/themes/modern/theme';
I am having difficulty getting a new version of a 3rd party SDK to import into Android Studio.
In the earlier version they released .jar and .so files which I copied into /lib and /jniLibs and then added the lib files into the Android Studio app and everything worked. The app ran, used the libraries and all was good in the world. Recently a new version of this SDK was released but in this new release they have resource files (but they are not compiled into the jar/so files; there is a $Rstring.class files that they say I should import. I've now spent days copying into various locations in the app project with no luck and the missing strings result in crashes when calling their SDK.
OK, I figure I'd try to import their SDK folder (which is how they document to do it if you are using Eclipse). Well, no matter what I've tried and after selecting the folder or SDK's project file I get a dialog asking for the Eclipse workspace and a list of what appears to be source file names. I can't get past this dialog because obviously I don't have their files.
Has anyone run into this and found a solution; perhaps I'm missing something in the process but after spending the better part of 3-4 days trying and searching and trying more things I'm hopeful for help from the community.
OK, I found the answer and it was a combination of issues in how this particular 3rd party distributed the SDK and not fully understanding the menu.
The 3rd party in question packaged the SDK with the output files of the build as well as files that needed to be imported making an import alone to not work.
Combine this with menu confusion: File->Import Module is NOT the same as New->Modules->Import Existing Project only added to the confusion.
The solution ended up being to use the File->Import Module which appears to be a very different operation and once done most of the issues where solved. It solved the main issues I asked above which was missing resourced.
Still missing was the library (.jar) files which had to me copied into the app's lib folder and "added as library" but the .SO files did not need to be copied and in fact doing that resulted in a duplicate files warning.
I'm not sure I can fully explain what happened but what I think happened is that the "module" was where the app read the .so and string resources from but was unable to load the .jar files because (I suspect) these files where not part of the module but rather where outputs of building the source and it was removing the source files which caused the inability of the new->Module->Import to fail.
Hopefully this makes sense or at least give someone an idea of what to look for when/if they run into a similar issue.
I'm looking for a way to make a project build and run as part of the build process in a solution.
Here's what I need:
First it compiles the "Generator Project", and in case of errors, it stops compiling.
Then it runs the "Generator Project", which creates some .cs files in other projects.
Then it compiles the rest of the projects.
I can see two ways of solving this.
Create and manually run the "Generator Project" when changes are made.
Construct a custom MSBuild script to do what I need.
While those two solutions work, I was hoping it might be possible to do it some easier/simpler way?
It occurs to me that you might solve your problem by using T4 Templates in the generator project (GP), then include the target .cs files generated by the templates as links into the other projects (OTP), and finally add a reference to the GP on each of the OTP so that the custom build order gets honored. I hope it makes sense.
I'm using Orchard 1.6 and have a question regarding the build batch file.
When run, some default modules (Lucene, Content Permissions, Messages) do not get published. I cannot see any difference in file permissions between these modules and the modules that are included in the publish.
Dropping the DLL's in the dependencies folder works, but, I'd like to fix this issue with the build script. No errors are reported by the build script.
If it makes a difference, I'm using TFS 2010 for version control.
Really appreciate any pointers...
Open the orchard.proj file. That's what the build script is using.
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.