Publish latest release to maven repository #4
Comments
|
For anybody wondering there is a deployed artefact here: parent: https://github.com/nathancomstock/maven-repo/ and It is not maven central though, that still remains to be done by a volunteer. |
|
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! |
|
@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). |
|
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. |
|
@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? |
|
@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) |
|
@tbroyer pom.xml would be a good start. Once we have that, we should be able to release to Central with just a |
|
@Ubehebe Do you mean replacing Ant with Maven as the build tool for the project? Or using |
|
@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? |
|
@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. |
|
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. |
|
@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? |
|
@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. |
|
@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. |
|
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. |
|
@nathancomstock The |
|
@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. |
|
@tbroyer Good point. I will look into cli options for examples. |
|
@Ubehebe, @tbroyer , |
|
@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. |
This CL creates the PyCodeBuilder class (with some refactoring to shared the JS implementation) and visitor methods necessary to setup imports, the namespace, and the global unicode string configuration. ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=83971563
|
@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 |
|
I never used that plugin. I just |
|
@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... |
|
@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. |
Related Design Doc: [] [] Goal: Implementation of processing placeholder nodes within MsgNode. Code reuses the existed implementation of MsgNode.substUnitInfo to collect (with optimization cache) all "variable nodes" in the subtree and reuses SoyMsgPart to process each nodes. No new visiting behaviors are introduced in this CL to ensure consistence. ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=86812309
|
@Ubehebe A million times thank you! |
|
@Ubehebe , missed the previous issue update notification somehow...the 02-10 jars are working for me. |
|
@Ubehebe Can you tag the release commits? I'm really only interested in the latest one (4-3-2015). |
This checks the individual type of each map literal key first, then checks that the resolved type of all map literal keys is valid. This addresses #4 in [] I confirmed with the RunParser tool that this doesn't break any existing map literal usages. This also has to remove some ImmutableMaps because they can't contain null values. And it adds a flag to the benchmark test to preserve the stack trace so the test can verify the correct error. GITHUB_BREAKING_CHANGES=Key types in map literal are now checked at compile time, so if you're using in invalid key type you'll now get a compile error. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=194424714
I am not sure, who has permissions to publish to maven repository for com.google.template but it would be nice to see latest released published there. I could help with that but I lack permissions.
http://mvnrepository.com/artifact/com.google.template/soy
The text was updated successfully, but these errors were encountered: