Publish latest release to maven repository about closure-templates HOT 29 CLOSED

For anybody wondering there is a deployed artefact here:

parent: https://github.com/nathancomstock/maven-repo/

and

https://github.com/nathancomstock/maven-repo/tree/master/releases/nathancomstock/github/closure-templates/2014-04-22

It is not maven central though, that still remains to be done by a volunteer.

from closure-templates.

Atlassian has more recent builds in their repository: https://maven.atlassian.com/3rdparty/com/google/template/soy/soycompiler/

But sure ideally Google would do it.

@ Google devs: if I can help in any way for that to happen, don't hesitate to poke at me!

from closure-templates.

@Ubehebe Could you bump the priority of this task? The 2014-04-22 "release" (the latest you can find online) breaks with Guava 18. In the mean time I think I'll use https://github.com/nathancomstock/maven-repo/ or compile it myself…

BTW, the doc at developers.google.com still links to code.google.com and the "2012" release (from the "howto" pages).

from closure-templates.

I actually don't think google has any desire to release to maven central, this task has to be carried out by a community member.

from closure-templates.

@matiwinnetou @tbroyer After moving some source code around internally, we're now able to accept PRs (directions). Would either of you like to write a pom.xml?

from closure-templates.

@Ubehebe Sure I'll have a look. Is all you need a pom.xml? or would you also like to have scripts or whatever to ease deployments to Central? (I believe I had started working on it already a while ago)

from closure-templates.

@tbroyer pom.xml would be a good start. Once we have that, we should be able to release to Central with just a mvn deploy.

from closure-templates.

@Ubehebe Do you mean replacing Ant with Maven as the build tool for the project? Or using mvn deploy:deploy-file with a pom.xml file, and the JARs created by the Ant build? (FWIW, we do the later for GWT, still using Ant for now to build the project, and a shell script to deploy to a Maven repository)

from closure-templates.

@tbroyer I'd totally be open to replacing Ant with Maven. My understanding (correct me if I'm wrong) is that Maven is the standard build tool in open-source Java these days. If we host on Maven Central, anyone who still needs to use Ant can just download the JARs manually and keep them.

Switching to Maven would also let us get rid of versioned JARs we currently have in source control, which would be nice.

WDYT? Should we check on closure-templates-discuss to see if anyone cares about Ant?

from closure-templates.

@Ubehebe At least one person asked for a Maven build: https://groups.google.com/forum/#!topic/closure-templates-discuss/B2gHKT0vzAw

But yes maybe there should be some discussion/poll before changing the build tool. Let's move this discussion to the group (I'll let you open the thread if you don't mind)

I'll work on a script to deploy the Ant build output to a Maven repo (similar to what we do for GWT currently), and then maybe move to Maven as a replacement for Ant.

from closure-templates.

@tbroyer Done.

from closure-templates.

I have a fork that uses gradle to integrate with the existing ant file, generate a pom, and presently publish to bintray/jcenter (which could then be synchronized to maven central or I could add direct support for maven central). It may need some tuning (but the major pieces should be done). I can submit a pull request if desired.

https://github.com/mwhipple/closure-templates/tree/mw

from closure-templates.

@mwhipple I'd prefer to get rid of the Ant stuff first and delete our vendored JARs. Gradle has pretty good interop with Maven, right?

from closure-templates.

@Ubehebe It depends on what you mean by interop. Gradle has great support for working with Maven repositories but is mostly a replacement for the build tool itself. It does have some support for interoperability with the Maven tool but I think Maven is a little too opinionated to play overly well with others. Gradle by default has the same convention over configuration approach and dependency management capability but is less restrictive. It does have very strong (bi-directional) Ant integration so the existing build system could be migrated smoothly if that makes more sense than a wholesale uprooting of the current build process. I added a quick rundown next to the build file in the branch: https://github.com/mwhipple/closure-templates/blob/mw/GRADLE.md. I'm also tidying up some of the integration points now so I can generate sources jars, etc.

from closure-templates.

@Ubehebe @mwhipple Building Closure Templates with Maven is (relatively) easy; generating the same JARs will require a bit more work. Running examples would be harder, but is this really needed?

from closure-templates.

@tbroyer By "this" you mean running examples? (not that I have an answer).

I should be able to take on porting to Gradle if there's interest/comfort in that option. All of the existing build logic could be handled without issue.

from closure-templates.

I have a maven config and deployment of maven build. The examples are run using exec plugin. Last I checked the maven build covered everything provided in the ant tasks, but I need to review since latest commits. I personally do not have maven/gradle preference, but would be happy to update/review my existing maven build and submit PR if desired.

from closure-templates.

@nathancomstock The pom.xml looks pretty good. Sure, send a PR.

from closure-templates.

@nathancomstock Looks good!

I notice you run one example during the verify phase; running examples from the CLI wouldn't be as easy as a with Ant though.

from closure-templates.

@tbroyer Good point. I will look into cli options for examples.

from closure-templates.

@Ubehebe,
Opened #23 for this issue.

@tbroyer ,
I did not see great options for running examples as easily as with ant. I looked at an option using the appassembler-maven-plugin which worked, but bloated the pom. In the current state of the PR, mvn verify -DskipTests=true -Dmaven.javadoc.skip=true can be used to run the examples.

from closure-templates.

@nathancomstock Yes, this is why I questioned above whether running the samples (individually, from the CLI) was really needed (they should of course be run during the build as a verification check). I for one am fine with what you did in your PR.

from closure-templates.

@nathancomstock @tbroyer I'd like to push to Maven Central soon. I'm used to using the nexus-maven-staging-plugin to do this via mvn deploy, but the POM doesn't have this plugin. Is there a better way to do this?

from closure-templates.

I never used that plugin. I just mvn deploy for snapshots, and mvn release:prepare and mvn release:perform for releases, followed by manually closing and releasing the staging repo at oss.sonatype.org

from closure-templates.

@Ubehebe , I also have not used the plugin. If you would like me to add the plugin let me know, just cant test it of course...

from closure-templates.

@nathancomstock @tbroyer Okay, I've pushed fresh artifacts to Maven Central. I had to add a few plugins and things to the POM. Can one of you grab the Maven JARs and make sure nothing is broken? Once you do, I'll send you a PR with my POM additions.

from closure-templates.

@Ubehebe A million times thank you!

from closure-templates.

@Ubehebe , missed the previous issue update notification somehow...the 02-10 jars are working for me.

from closure-templates.

@Ubehebe Can you tag the release commits? I'm really only interested in the latest one (4-3-2015).

from closure-templates.