mikakoivisto / liferay-maven-incubation Goto Github PK

Wouldn't be simpler to remove the theme merger plugin and use the overlay feature from maven ?
The idea will be for Liferay to deploy all official liferay themes on central. That way, developers would be able to reference it from their own project without the need of a specific plugin, maven (and its war plugin) would do the magic.
We used this technique on a project for liferay 6.0 with successful result.

Into util-java-6.1.0, there are classes relative to slf4j :

• org.slf4j.impl.StaticLoggerBinder
• org.slf4j.impl.StaticMarkerBinder
• org.slf4j.impl.StaticMDCBinder
  Is this normal ?

While compiling my project, I get :
SLF4J: The requested version 1.6.4 by your slf4j binding is not compatible with [1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.5.10, 1.5.11]
SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for further details.
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/home/rogon/.m2/repository/com/liferay/portal/util-java/6.1.0/util-java-6.1.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/rogon/.m2/repository/org/slf4j/slf4j-log4j12/1.5.11/slf4j-log4j12-1.5.11.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.

I have to admit that I'm not a big fan of defining classes with the same namespace of well-known framework / toolkit ...

WSDDBuilder has a different signature than the one in 6.1.0-SNAPSHOT. I commented out the doExecute code to get the maven plugin to compile. What effect will this have?

protected void doExecute() throws Exception {
    WSDDBuilder wsddBuilder = new WSDDBuilder();

    wsddBuilder.setFileName(serviceFileName);
    wsddBuilder.setOutputPath(resourcesDir + "/");
    wsddBuilder.setServerConfigFileName(serverConfigFileName);
    wsddBuilder.setServiceNamespace(serviceNamespace);

    wsddBuilder.build();
}

public class WSDDBuilder {
private java.lang.String _serverConfigFileName;
private boolean _portalWsdd;
private java.lang.String _portletShortName;
private java.lang.String _outputPath;
private java.lang.String _packagePath;

public static void main(java.lang.String[] args) { /* compiled code */ }
public WSDDBuilder(java.lang.String fileName, java.lang.String serverConfigFileName) { /* compiled code */ }
private void _createServiceWSDD(java.lang.String entityName) throws java.lang.Exception { /* compiled code */ }

}

Is there any chance to have artefact from later version of 6.0.x on central ?
I'd really like 6.0.11 artefacts =P

Right now, when you use the service builder archetype, you'll have this project structure :

• myproject
  ... - myproject-service
  ... - myproject-portlet

Portlet has a reference to the service, so that the service is built before portlet.

The "liferay-maven-plugin" to build the service is defined into portlet, so that, the src generation is made from portlet. The src generation generates code into portlet, which need to be install before being used into portlet.
The idea is to bind the "liferay-maven-plugin" goal to the "generate-source" phase. If you do so and do a "mvn deploy" on the root module, you'll end with that order :

• myproject-service (which deploy old version of service)
• myproject-portlet (which install new version of service into service module and deploy new version of portlet)
  That is not correct if you want to deploy into a hosted repository. you need to deploy the new service at fiirst, then deploy the new portlet. So, you need to generate src while building the service.

The idea is to move src generation from portlet to service by removing the plugin definition into portlet and create a plugin entry into service's pom.xml :

<properties>
    <project.portlet>${basedir}/../myfoobar-portlet</project.portlet>
</properties>
<build>
    <plugins>
        <plugin>
            <groupId>com.liferay.maven.plugins</groupId>
            <artifactId>liferay-maven-plugin</artifactId>
            <version>${liferay.version}</version>
            <configuration>
                <apiDir>${basedir}/src/main/java</apiDir>
                <hbmFileName>${project.portlet}/src/main/resources/META-INF/portlet-hbm.xml</hbmFileName>
                <implDir>${project.portlet}/src/main/java</implDir>
                <jsonFileName>${project.portlet}/src/main/webapp/html/js/liferay/service.js</jsonFileName>
                <modelHintsFileName>${project.portlet}/src/main/resources/META-INF/portlet-model-hints.xml</modelHintsFileName>
                <ormFileName>${project.portlet}/src/main/resources/META-INF/portlet-orm.xml</ormFileName>
                <resourcesDir>${project.portlet}/src/main/resources</resourcesDir>
                <serviceFileName>${project.portlet}/src/main/webapp/WEB-INF/service.xml</serviceFileName>
                <springBaseFileName>${project.portlet}/src/main/resources/META-INF/base-spring.xml</springBaseFileName>
                <springDynamicDataSourceFileName>${project.portlet}/src/main/resources/META-INF/dynamic-data-source-spring.xml</springDynamicDataSourceFileName>
                <springFileName>${project.portlet}/src/main/resources/META-INF/portlet-spring.xml</springFileName>
                <springHibernateFileName>${project.portlet}/src/main/resources/META-INF/hibernate-spring.xml</springHibernateFileName>
                <springInfrastructureFileName>${project.portlet}/src/main/resources/META-INF/infrastructure-spring.xml</springInfrastructureFileName>
                <springShardDataSourceFileName>${project.portlet}/src/main/resources/META-INF/shard-data-source-spring.xml</springShardDataSourceFileName>
                <sqlDir>${project.portlet}/src/main/webapp/WEB-INF/sql</sqlDir>
            </configuration>
            <executions>
                <execution>
                    <goals>
                        <goal>build-service</goal>
                    </goals>
                    <phase>generate-sources</phase>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

That way, on the root module, if you do "mvn deploy", you'll end up with :

• service building (with service and portlet src generation from the plugin) and service deploy
• portlet building and portlet deploy

In that order, you can remove the invoker in the plugin (which call mvn install for the service part).

By removing the invoker, you'll remove plugin dependency on maven-invoker, and then you can have a working plugin with maven 3 =)

https://github.com/mikakoivisto/liferay-maven-incubation/blob/master/plugins/liferay-maven-plugin/src/main/java/com/liferay/maven/plugins/ThemeMergeMojo.java#L152

Should it be !themeType.equals("ftl")?

BTW. Is the repo in http://svn.liferay.com/repos/public/maven-support/trunk mirror of this? Could not find hardly any info on current status of liferay maven sdk or where to report bugs etc...