Support maven releases

[jbalsas]

We have some users (Liferay Portal, for instance) integrating AlloyEditor in JVM projects. For them, it is very convenient to bring in their dependencies via maven.

For now, we've been manually publishing every release to webjars. We need to have the proper set of tasks in place to be able to test and release these maven artifacts on our own.

We just need to use https://github.com/liferay/liferay-gulp-tasks so some extra tasks will be added to the project:

• maven-install
• maven-publish
• maven-publish-snapshot

[ipeychev]

Hey Chema,

To push AlloyEditor to Webjars is one thing and this is totally fine - it is not different than pushing to NPM or Bower. However, how Liferay's gulp tasks are related to this? Isn't it enough if we push AlloyEditor to Webjars every time there is a new release and Liferay Portal to install it from there?

Thanks,

[ipeychev]

Also, looking on Webjars site, I see here "NPM WebJars". I looked for "alloyeditor", there wasn't any and I just created one. I created it by hand, but I guess there is a way to do it automatically, via some API. In this case, wouldn't it be possible for us to create such NPM WebJar when we publish to NPM and Liferay Portal to use it?

[jbalsas]

Hey Iliyan, I've been publishing AlloyEditor to webjars since 0.6.0, only I was doing it as a Bower Webjar.

There are several reasons why just webjars is not the right solution for us here:

• Webjars needs full bower or npm releases to generate the artifacts. This makes it impossible to try out anything without doing a full release. When we asked about a way to generate them locally, we were basically told to do it ourselves, since building a jar file it's actually trivial.
• Webjars will download the whole project using a Heroku service and then build the artifact. For projects such as AlloyUI, the service times out half of the times, making it a completely unreliable tool to publish.
• In addition, we want to have more fine-grained control over the publish process. The tasks we're adding allow us to:
  • Install a snapshot into the maven local repo. This is incredibly useful while developing to test the integration.
  • Publish a snapshot version to maven. We need this to be able to test on the CIs without having to publish releases (potentially flawed) to the world.
  • Publish a version to a given maven repository. We need this for Support. With this, we can now release from a specific branch without having to make public releases for webjars. The idea we're considering is to provide the fixes (if any) as internal private artifacts. I think this is necessary so Support won't force project releases for every single bug fix as it was happening with AlloyUI.

Maybe the liferay-gulp-tasks is a wrong name... for now, it is just providing the proper set of gulp-maven tasks we need. It may grow bigger or it may stay the way it is, but Maíra considered it would make sense to have it as a common set of tools for all projects.

What do you think?

[jbalsas]

Of course, nothing should stop us from also releasing via webjars. People will just have several ways to grab the editor when using maven.

[ipeychev]

Hey Chema,

I see. From my understanding these are common gulp tasks, and not Liferay specific, aren't they? If so, it is fine to use them, only, add you said, the name shouldn't be prefixed with a company name if it is not company specific.
If they are not general ones, is it possible to make them general purpose for dealing with maven?

The same is valid for metal project, I'm surprised how something which looks like specific for some company was accepted there so easily. Unless the idea is metal to be used only inside the company, it shouldn't be like this.

Thanks,

[jbalsas]

Hey Iliyan, yeah, we're making them configurable so anyone could use them, but the default values are the ones we need for liferay.

In the end, these are just used to publish stuff to a specific platform. In this case, Liferay Nexus Servers which in turn sync with Maven Central (this is the way it works also for webjars, only using a different nexus server). This is probably not any different than having a bower.json file which you use to publish to bower.

I see your point, though, and I think we might be able to turn this set of tasks into a standalone cli tool that people could just install and configure and then run in any project to publish it to maven. The downside being that you probably can't integrate it with your build system as easily.

I'm currently on vacation (and should be away from keyboard), won't be back until tuesday and timeline is quite tight. However, there's no real rush in merging this in. I can just cherry-pick after the release and manually publish myself, so we can give it some more thought.

What do you think?

[ipeychev]

Hey Chema,

If there is no rush, I would say it would be better to release 1.0 without it, and then we can release 1.0.1 with something derived from this. If I understand correctly, we will need to rename this task and to add some file, where the needed values will be specified. Something like this, you should know better.
About the vacation, you know - I've never tried to stay away from the keyboard, so I don't know what's the feeling, but in any case - "Have fun" :)

Thanks,

[jbalsas]

Hey Iliyan,

Yeah, let's release 1.0, that's the important thing here. I'll publish the artifacts as I've been doing so far.

We're not in a rush, but we'll need this sooner rather than later. The thing is, we need these tasks (or whatever form they take) in all of our projects, so they need to work for all of our workflows. I'll coordinate with Nate and Eduardo to see what we can do.

On a related note, this is what I did when I was trying this out (https://github.com/jbalsas/alloy-editor/commit/621c8670ffd0f3b2c5474826158f5b2314339160). What we have now, is just that set of tasks wrapped in a common util...

[jbalsas]

I'm closing this... we will be using npm to bring in the dependencies, and we haven't seen much love about webjars in any case 😢