Some times ago, I used Alfresco 5.2 Community Edition. When I needed to develop some kind of customization, I used the Alfresco Maven SDK with three different Maven archetypes, it was:
Alfresco Repository AMP;
Alfresco Share AMP;
Alfresco all-in-one (AIO).
By using this SDK I developed AMP files that overlaid on either the alfresco.war or share.war by using the module management tool.
Now I am using Alfresco 4.2.2 Enterprise Edition and the problem is that all the customizations over the years have been performed directly on the servers in the exploded WAR's.
This approach is described here: Packaging Approaches
Unpackaged Files or ZIP
Many development environments employ a build process that can execute
a script to move unpackaged modified files from source control into
the web application's exploded WAR file. Ant, bash, or some scripting
language can all be good ways to do this ...
Moving unpackaged files has the advantage of being quick and easy to
understand ...
And further:
Deployment Locations
One solution is to use a permanently exploded deployment (instead of
deploying an Alfresco WAR file under /webapps). Create a directory
called alfresco under the webapps directory and extract the contents
of alfresco.war into it. Then copy your files to
../webapps/alfresco/WEB-INF/ and restart Tomcat ...
Thus, I can't use AMP-customizations(otherwise all previous developments will be deleted). As far as I know, I can use an alternative- JAR-customization.
As described in the same document:
JAR
As of v3.4, the Share web application supports overrides that are
packaged as JAR files. This allows multiple customizations to be
isolated from each other, and order of selection can be predicted.
Static files such as JavaScript, CSS, or image files that would
normally be placed in the web root of the Share application can also
be packaged into these JARs ...
While it's possible to avoid the overwriting problem (at least in
Tomcat) by placing these JAR files in tomcat/shared/lib ...
However, I can not take advantage of this approach either. For example, I need to override the FreeMarker template:
/opt/tomcat7/webapps/share/WEB-INF/classes/alfresco/web-extension/site-webscripts/components/form/service-note/service-note-order-things.ftl
I create the appropriate directory structure in IDE, change the template in some way, and build the Jar file. Then I put it in tomcat7/shared/lib (I also placed it in tomcat7/webapps/share/WEB-INF/lib, but also without success) and restart the application server.
After restarting, I don't see my changes - the template remained the same. Moreover, if I try to add another template to the same directory (.../service-note/...), a new template there does not appear.
In my Tomcat installation shared classloader is configured properly.
What am I doing wrong? How to override static resources by using JAR?
I would be very grateful for the information. Thanks to all.
It is necessary to use the SurfBug debugging tool to identify the template file (Template Type property).
Then develop the Spring Surf extension module - "are the preferred way of customizing many of the Alfresco Share user interface features" - and pack it into the Jar.
Then I should use the Module deployment which is available through the web-
script at:
http://host:port/share/service/modules/deploy
The FTL can be customizing as follows:
Place the new content before/ after the certain #region;
Replace the content of the certain #region with the new content;
Remove the certain #region completely.
In the file system, we will have the same unmodified template, because Spring Surf writes to an in-memory model and then allows extensions to manipulate that model before the model is flushed to the output stream.
See also:
Customize Alfresco Share FreeMarker templates
About FreeMarker extensibility directives
Related
I have read the following essay:
Resources (library) in JSF 2.0
It's about versioning of web resources for JSF2 project.
May I know how could I do when my project is Maven-based? What need to be setup or added in the Maven setting?
Thanks a lot.
Effectively your question is a combination of three existing questions in Stackoverflow.
One is already superfluous since you already know how JSF versioning works, you just (unfortunately) referred an external site and not the existing question but from this question you need to 'remember' the format of the version number that needs to be used.
The second part should also not have been to difficult to come up with. JSF is a runtime framework and has no build/deploy time features. But you already use maven, so what is needed to build time copy(move?) the resources to a new location. The source folder can differ, it can be an additional resources folder e.g. src/main/myresources, that you don't treat as a resources (since it would end up in the classes folder then by default) or it can be a folder inside the webcontent and then you need to move (copy/delete). This is all for you to find out.
The third part is that the destination folder needs the version in the right format
1_0
1_1
1_2_3
Since this differs from the project version format, you need to search/replace this
which includes the project version in the right format. There are features for this as well in maven.
So you see, it all boils down to breaking a problem down into manageable parts...
I'm fairly unexperienced and all new to the whole world of build tools so here's my situation: I am developing a webapp with JSF, PrimeFaces and Hibernate on wildfly-9.0.2-final. All java files (incl. ManagedBeans, DAOs, Model classes, etc.) are currently in a regular eclipse java project called MyApp-CORE. There is no html or any other resources in that project, but all the third-party libraries like PrimeFaces, commons-xy, etc. Then I got two dynamic web projects with all the .xhtml files and stuff. Both web projects include the CORE in their build path (all done via eclipse built-in tools). Basically I followed Structure for multiple JSF projects with shared code so far. All projects are versioned using Git. I was now asking myself how to mavenize the whole thing and also how to properly include tests. The final result should be:
I want a build file for each web project that includes the CORE dependency and all of it's transitive dependencies, creates a .war file and deploys it either on the production system or locally (Depending on some parameters I want to be able to maintain).
This buildfile could then for instance test and build the CORE and then the .war file.
Since I'm using JSF, mostly the only option for testing is JSFUnit. Should I test each web project individually and put all the test cases there (which would be highly redundant because they're mostly the same, just a few features are different) or should I rather create a separate web project called MyApp-TEST which tests the CORE.jar and also - depending on some configuration - each web project.
I've already created a structure that makes it possible to include the core in the web project but unfortunately I loose the perks of hot deployment in wildfly when just including it as a dependency from my local maven repository.
So, to summarize it:
What would be a best practice for this setup, eventually leading to a continuous integration scenario?
How should I include the test cases (full integration tests that test actual UI behaviour)?
Which Tool (Maven, Gradle, Ant, etc.) would be best for that task?
Keep using hot deployment for smooth development?
Thanks in advance for any comments, hints or shared experience!
We are using some library that doesn't work for some reason if the WAR is expanded under the apps folder. When the eclipse tooling publishes the WAR to a remote server, the WAR is expanded. How do I prevent the server from unzipping the published WAR?
If an app doesn't work when expanded, but the exact same app works as a binary, then that indicates something wrong in the server. I'm not aware of specific cases where we wouldn't support an expanded EAR instead of an EAR binary.
It sounds like you're this far already, but the first thing to check is if you're using resources inside of the workspace or inside of the server. You can check this by looking at the server on disk and seeing if the apps directory has either something like TestWar.war.xml or TestWar.war (directory).
To move the resources to the server, if you are using something like WDT (the Eclipse tooling you get from dragging the icon on wasdev.net into your Eclipse workspace) you can modify the Liberty server settings to do this.
In the Servers tab, double-click the WebSphere Application Server Liberty entry and you should see the Overview configuration screen. Uncheck Run applications directly from the workspace and now if you look at the server on disk you will see the files directly inside of the server.
But, to answer your question, it's not so much that we're unzipping the published WAR so much as we're not zipping it to begin with. If you right-click the EAR project and go to Export that's a one-off way to make an EAR binary, but otherwise you may want to look at a simple build description system through Ant or Gradle or Maven along with similar standards to build the archives.
I'm developing a plugin for Eclipse (4.2 on windows) that uses a bunch of external files (batch scripts, xml files, ecc).
I'm asking if there is a good method to manage those files inside the project in order to:
keep all the plugin resources inside the project for version control in SVN
possibly have an automated plugin installation (including those files outside the plugin jar)
Edit: Can an additional "Feature Project" be a solution?
Instead of having a project I would manage two: one for the plugin and one for the "feature" that references the plugin and gathers the non-plugin data.
In that case, I see that eclipse "Features" have an "installation" section (in "feature.xml"). How could I specify for each "non-plugin" file the install path location?
I'm using nested projects for this.
Create a parent project that will contain everything. For each sub-project, deactivate the default location when you create it and select the parent project's root folder instead.
Here is an example: http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/tree/
It doesn't have a .project file in the root but having one doesn't hurt.
Just remember to import the sub-projects before you start working on them. Otherwise, you and Eclipse might get confused.
I'm trying to build portlets for websphere in Eclipse Juno. Everything works so far, building and running the WAR files on WPS7 is ok.
But in my JSP editor I get a lot of warnings:
Can not find the tag library descriptor for "/WEB-INF/tld/portal.tld"
In my JSP file I'm using the usual taglib line:
<%#taglib uri="http://java.sun.com/portlet" prefix="portlet"%>
Now I wonder if I have to bring the actual JAR file that defines this tag into my eclipse or if there is something else that I missed.
The reason you are getting this error message has nothing to do with the taglib declaration you had quoted. The latter refers to the standard Portlet tag library (JSR-168), whereas the former has to do with WebSphere Portal's proprietary tags, needed to use WebSphere Portal-specific facilities.
I am guessing that portal.tld is referred-to by your web.xml.
When developing portlets under RAD, IBM's RAD plugins ensure that this TLD file is known to the JSP compiler, by virtue of attaching the WebSphere Portal runtime - in its entirety - to the Dynamic Web Project's classpath.
Under Eclipse Juno, this isn't done for you. You will have to find the JAR file that contains it (which might vary from one WebSphere Portal release to another) and add it to your compile-time classpath.
Having said that, you may want to consider why you need that web.xml declaration in the first place. With Portal 7.0, most of IBM's tag libraries can be referred to by their URI's, rather than having to specifically mention the TLD file.
I'm using a Portal 8 installation but the structure should be similar.
I found a jar containing portal.tld at [Portal Install root]\Portal Server\base\wp.engine.tags\shared\app\wp.engine.tags.jar
Though as a more complete solution you might want to include the whole base folder into your classpath. The server runtime RAD adds to my portlet project include lots of jars from that folder as part of the basic setup. It also includes many jars from [WAS Install root]\App Server\plugins. Since you're just using Eclipse instead of RAD (which would help manage the Portal server jars) you'll probably want to create a user library to manage all these jars.
In RAD/Eclipse, assuming you have the Portal 8 Stubs and Developer Tools installed, you can go to Project->Project Properties -> Java Build Path, to the Libraries tab, Go to Add Library -> Server Runtime , and you should see "Websphere Portal 8" or whichever version you have installed ... once that library is added your URI problems should be resolved.This essentially adds every jar file in the entire portal installation to the build path. If you do not have the stubs and development tools installed, or if you are using another IDE, you will need to add the jar files manually to the build path ....