[ANN] [Play 1.x] [Maven] - Play! Framework versions 1.2.6, 1.2.7-SNAPSHOT and 1.3.0-SNAPSHOT available

[Grzegorz Słowikowski]

Hi

Recently I've released 1.2.6 version and deployed new snapshots:
1.2.7-SNAPSHOT (play 1.2.x git branch) and 1.3.0-SNAPSHOT (play 1.3.x
git branch).
More info here: http://code.google.com/p/maven-play-plugin/

All these versions are affected by
http://play.lighthouseapp.com/projects/57987-play-framework/tickets/1702
bug.

Grzegorz Slowikowski

[Grzegorz Słowikowski]

Hi again

I've deployedďż˝ new 1.2.7-SNAPSHOT and 1.3.0-SNAPSHOT snapshots
for use with Maven plugin for Play! Framework (http://code.google.com/p/maven-play-plugin/):

- 1.2.7-SNAPSHOT built from 1.2.x branch current revision (https://github.com/playframework/play1/tree/68aa95e96bed5bb519b595133dfc1474af04a21d)
- 1.3.0-SNAPSHOT built from 1.3.x branch current revision (https://github.com/playframework/play1/tree/7d9e2dc6abebb8af026c72241bcc4f6ddd60408f)

Bug http://play.lighthouseapp.com/projects/57987-play-framework/tickets/1702 seems to be fixed in both branches.

Regards
Grzegorz Slowikowski

[Israel Tsadok]

Hi Grzegorz, this looks like a really neat project, and I'm thrilled to see you're actively working on it.

I have a couple of questions:

1. If I understand correctly, there's no archetype for mavenized play projects. If I want to use it for something new, I should create a new project with (plain old) play and then copy a pom.xml from one of the example projects and modify it to my needs. Is this correct?

2. Currently we're using a locally-modified version of play 1.2.4. How would you suggest we approach using your plugin but keeping our own patched version of play? I suppose I need to modify your code and deploy it to my local repo, and then use that for my project. Any tips on where I should look first would be appreciated.

Thanks.

[Grzegorz Słowikowski]

Hi Israel

On 2013-08-27 07:39, Israel Tsadok wrote:
> Hi Grzegorz, this looks like a really neat project, and I'm thrilled
> to see you're actively working on it.
>
> I have a couple of questions:
> 1. If I understand correctly, there's no archetype for mavenized play
> projects. If I want to use it for something new, I should create a new
> project with (plain old) play and then copy a pom.xml from one of the
> example projects and modify it to my needs. Is this correct?

Yes, I thought about archetype, but since nobody asked, I didn't create
it. As you write, copy pom contents from one of the example projects.
If you have your own (required corporate) parent pom, copy the contents
of my default parent pom to your project's pom, or better - create parent
between your project and your required parent (stack parents).

>
> 2. Currently we're using a locally-modified version of play 1.2.4. How
> would you suggest we approach using your plugin but keeping our own
> patched version of play? I suppose I need to modify your code and
> deploy it to my local repo, and then use that for my project. Any tips
> on where I should look first would be appreciated.

You can deploy your modified version of Play! without changing anything
in my plugin.
Did you change only framework? No changes in build-in modules (crud,
testrunnet, etc.)?
Answer this question and I will give you appropriate instructions.

> Thanks.
> --
> You received this message because you are subscribed to the Google
> Groups "playone" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to playone+u...@googlegroups.com.
> To post to this group, send email to pla...@googlegroups.com.
> Visit this group at http://groups.google.com/group/playone.
> For more options, visit https://groups.google.com/groups/opt_out.

Greetings
Grzegorz Slowikowski

[Israel Tsadok]

> 2. Currently we're using a locally-modified version of play 1.2.4. How

> would you suggest we approach using your plugin but keeping our own
> patched version of play? I suppose I need to modify your code and
> deploy it to my local repo, and then use that for my project. Any tips
> on where I should look first would be appreciated.

 

You can deploy your modified version of Play! without changing anything
in my plugin.
Did you change only framework? No changes in build-in modules (crud,
testrunnet, etc.)?
Answer this question and I will give you appropriate instructions.

I made a few tweaks to the framework, and I'm also using a forked Security plugin . I've also made some changes to the python startup scripts.

I'd like to have my patches when I do "mvn test" for example, so I don't see how I can make that work without changing your plugin, unless I can configure where to fetch the play jar from.

I don't fully grok your solution yet, so I may be missing something simple.

[Grzegorz Słowikowski]

Hi

I needed some time to prepare my answer :)

This post is mainy about dependencies in Maven and Play! framework.

1. Play!

Play! 1.x has two independent dependency systems.

1.1. The legacy, but working one.

You can use Play! framework's built-in modules (crud, testrunnet, etc.)
by adding:

module.crud=${play.path}/modules/crud

to your project's "conf/application.conf" file

You can use external modules as well. You have to install a module with
"play install"
command. For example:

play install cobertura

and use it by adding:

module.cobertura=${play.path}/modules/cobertura-2.4

More info here: http://www.playframework.com/documentation/1.1/modules

1.2. New one using "dependencies.yml" file

You define your project's dependencies in "conf/dependencies.yml" file

More info: http://www.playframework.com/documentation/1.2.5/dependency

What is the difference between above dependency systems?
In 1.1 dependencies are inside Play! framework's (play home) "modules"
subdirectory.
In 1.2. dependencies are inside application's "modules" subdirectory.

2. Maven and play-maven-plugin

Maven has one dependency system with scopes. play-maven-plugin supports
both above Play! dependency systems.
The question is, how play-maven-plugin knows, if particular module
dependency should be expanded inside
Play! framework's "modules" subdirectory or application's "modules"
subdirectory.

The answer is, if the scope is "provided" it means that module should
be expanded inside framework's
"modules" subdirectory, and for all other scopes - inside application's
"modules" subdirectory.

Why "provided" scope id the key?

When you write servlet web application, you add 'servlet-api' with
"provided" scope.
This scope means that you need this dependency during compilation, but
don't need
in 'war' archive in runtime because your web server provides it.

Because in Play! framework there is no API for applications, whole
Play! framework
with built-in or installed modules is your application's API. If so,
framework and
built-in or installed Play! modules should be added to pom.xml with
"provided" scope.

On the other hand, if you add a module to your application's
'dependencies.yml' file,
this module should be unpacked to subdirectory of application's 'lib'
directory. It's
not part of Play! home content, so it should not have 'provied' scope
in Maven.

Play framework's dependency scope should be "provided" like all
modules' dependency scopes,
but in reality, play-maven-plugin doesn't care about it. Module
dependency scopes,
on the other hand, are very important.


play-maven-plugin does not require an existing Play! installation
directory (play home), but Play! needs one.
In the 'initialize' phase of Maven project build play-maven-plugin
creates on the fly
Play! home directory in 'target/play/home' directory.
Plugin finds framework dependency and unpacks in 'framework'
subdirectory and all
provided-scoped modules and unpacks them in 'modules' subdirectory.

What about non-provided-scoped modules?

There is play:dependencies mojo in play-maven-plugin. It's not bound to
"play" lifecycle.
It has to be invoked manually "mvn play:dependencies" or invocation
should be added to your application's
"pom.xml" file.


3. How framework and modules dependencies are being found by
play-maven-plugin

3.1. Framework

This is simple. Plugin finds dedendency of "zip" type with classifier
"framework" or "framework-min".
For example (from
http://repo2.maven.org/maven2/com/google/code/maven-play-plugin/play-app-default-parent/1.0.0-beta6/play-app-default-parent-1.0.0-beta6.pom):

<dependency>

<groupId>com.google.code.maven-play-plugin.org.playframework</groupId>
<artifactId>play</artifactId>
<version>${play.version}</version>
<classifier>framework-min</classifier>
<type>zip</type>
<scope>provided</scope>
</dependency>

3.2. Modules

Plugin finds all dependencies of "zip" type with "module" or
"module-min" classifier.
For example:

<dependency>

<groupId>com.google.code.maven-play-plugin.org.playframework.modules.testrunner</groupId>
<artifactId>play-testrunner</artifactId>
<version>${play.version}</version>
<classifier>module-min</classifier>
<type>zip</type>
<scope>provided</scope>
</dependency>

What id the difference between framework dependency with "framework"
and "framework-min" classifier?
What id the difference between module dependency with "module" and
"module-min" classifier?

Versions with "-min" suffix contain minimal file set required to work.
No documentation, test projects, etc.
This reduces decompress time during build.

You can declare both dependencies for framework or for the same module.
In this case "min" version is used
for build, and "full" version in full distribution preparing mojos
("dist" and "dist-exploded"). This logic
is hardcoded in play-maven-plugin.

4. How to deploy your own framework or module version.

You can use any groupId and artifactId. You have to prepare "zip" type
dependencies with
"framework" and/or "framework-min" classifier(s) for framework and
"module" and/or "module-min" classifier(s)
for every module.

When using your own framework or built-in modules you cannot use
"com.google.code.maven-play-plugin:play-app-default-parent" parent
because it depends on "default" Play! framework and built-in
"docviewer" and "testrunner" modules distributions.

Regards
Grzegorz Slowikowski

P.S.
I should write it somewhere in the wiki pages of my project.