How best to manage templates?
128 views
Skip to first unread message
Will Sargent
Jul 20, 2016, 1:36:02 PM7/20/16
to play-fram...@googlegroups.com
Hi all,
Then we have some templates in Play itself, under the templates/ directory.
So right now, we have templates which are based in github, which are pulled by doing a git clone (ideally git checkout-index -f -a --prefix=/myproj/ but very few people do that):
as well as some database example templates:
Then we have some templates in Play itself, under the templates/ directory.
which contains play-scala and play-scala-intro (which uses PlaySlick and Slick) and play-java and play-java-intro (which uses JPA).
This means that if you want these templates, you have to use activator to generate the template with "activator new myproj play-scala". However, the benefit to keeping these templates under the templates/directory means that templates can be compiled against the play-master code base.
I'd like to standardize on having github projects for all Play templates and moving play-* / play-*-intro into distinct github projects under https://github.com/playframework. At the same time, I don't want to give up having the template builds work as part of Play's test suite.
The standard solution is to link the projects in their own github repos to "symlinks" that appear like directories under templates/. I think this could work, but we'd need to be careful to distinguish between the "master" branch of Play which is development, and the "master" of each of the templates, which should be the stable released version -- there would need to be a "2.6.0-SNAPSHOT" for development purposes which we would link to.
As far as the underlying mechanism goes, I would prefer not to use git submodules if at all possible. I have heard good things about git subtree and git subrepo:
So, this is where my current thinking is. How does everyone feel about this? Anything that would be a problem or might work better?
Thanks,
Will.
Will Sargent
Jul 20, 2016, 1:46:24 PM7/20/16
to Play framework dev
Another option that comes to mind is that instead of using git subtree / subrepo, we could potentially keep all the templates under templates/ and then "push" the templates out whenever we do a release.
Will.
Will.
James Roper
Jul 20, 2016, 9:39:52 PM7/20/16
to Will Sargent, Play framework dev
There's one issue that you haven't raised, and that's how templates can be maintained - by this I mean the templates, particularly the seed templates, always need to point to the latest Play version, Scala version, sbt version, and there are other dependencies they have such as sbt-web plugins that need to be regularly updated. With the templates in the Play repo, these versions are configured in one place. If they were simply pulled out like the other templates, this maintenance would be manual, tedious, and it would be easy to miss versions. I think there needs to be an automatic solution for this maintenance. This is one of the major reasons that we pulled the templates into the Play repo, so that the templates themselves could be templated.
You'll need to give up having the template builds as part of Plays PR validation if you pull the templates out. If a change is made that requires a change to a template, you won't be able to make the change to the template until the change in Play is merged, otherwise all the other PRs that are testing that template but don't have the changes it needs in Play yet will fail. But you won't be able to merge the change in Play until the template is updated, since PR validation will fail. There is a possible solution - and that is when making such a change, you need to make the change to the templates in a branch, and change the reference from the Play repo to be to that branch, and then after merging it you'll need to merge the change to the templates, and then update the reference in the Play repo back to the original branch. That's a lot of manual tedious work again, especially if there are many templates.
Giving up including templates in PR validation is not that bad if you still include it in some nightly build - the templates rarely change and rarely break, their tests don't test anything very deeply, so there's actually not a lot of value in having them included in PR validation. One solution here is to publish nightly builds of Play, and get each template to do a nightly build against the Play nightlies, there's a service here that allows configuring Travis nightlies:
Travis itself also provides a set of scripts for triggering builds from the command line, and these could be run nightly by AWS Lambda if you need more control. You could also get each template to build Play itself in its validation to ensure it's running against the latest.
--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Greg Methvin
Jul 22, 2016, 3:12:32 PM7/22/16
to James Roper, Will Sargent, Play framework dev
I agree with James that if we give up having the templates in the nightlies in the playframework build, we need some alternative form of validation. Another problem is that the template build and validation takes a significant amount of time in the current build, so at least removing that from the normal PR validation would be helpful, as long as we ran it somewhere else.
Christian Schmitt
Jul 22, 2016, 3:20:50 PM7/22/16
to Play framework dev, ja...@lightbend.com, will.s...@typesafe.com
Actually the same thing happens when we pull something out of Play but that still needs Play as a dependency, consider Joda. It would still need Play-Json for Reads/Writes but we can't actually automatically upgrade the Play version in the subrepo. Not that much of a problem since most stuff won't be maintained for long if we pull stuff out.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
Will Sargent
Oct 11, 2016, 3:58:19 PM10/11/16
to Play framework dev
To follow up on this:
The internal templates have been moved out from playframework/playframework into distinct github repositories.
All of the templates have been enabled with Travis CI build hooks, so they must at least compile and pass their test suite.
Managing all the templates and ensuring they're not out of date is a problem, so we also now have https://github.com/playframework/templatecontrol to do automated search and replace on templates and submit the changes as a pull request for each template. It's driven entirely by application.conf, so it's easy to add new templates and update to new versions. Here's an example:
So, all the templates have a "master" branch which is the default, and which points to the latest release version of Play (i.e. 2.5.9). There will also be a "SNAPSHOT" branch which will point to the latest available "SNAPSHOT" artifact of Play from the nightly build. Travis CI has a cron job available, and so each template can be built nightly against the snapshot, in parallel. This is still ongoing -- the semantics of "SNAPSHOT" in https://oss.sonatype.org/content/repositories/snapshots/com/typesafe/play/play_2.11/maven-metadata.xml are not what you'd expect.
When 2.6.0 is released, here's what happens for each template:
* The "master" branch becomes "2.5.x"
* The "SNAPSHOT" branch becomes "master"
* A new "SNAPSHOT" branch pointing to "2.7.0-SNAPSHOT" is used.
Sound good?
Will.
On Wednesday, July 20, 2016 at 10:36:02 AM UTC-7, Will Sargent wrote:
Will Sargent
Oct 13, 2016, 10:32:07 PM10/13/16
to Will Sargent, Play framework dev
Update: the snapshot works for play-chatroom-scala, and it's clear how to follow it up.
So the key is to download the maven_metadata.xml file, and then replace the latest SNAPSHOT line with the parsed out XML:
addSbtPlugin("com.typesafe.play" % "sbt-plugin" % $SNAPSHOT_VERSION)
i.e. the snapshot comes in with "2.6.0-2016-10-12-cb0d314-SNAPSHOT"
The good and bad news is, there are 20 templates, so either I extend templatecontrol to insert lines of text, or it's time to update 20 templates to add the lines.
Still, after all that is done then we can delete the templates directory from playframework, and we can have builds of all templates against a snapshot any time we want.
--
Reply all
Reply to author
Forward
0 new messages