search

searls / jasmine-maven-plugin

Maven plugin to execute Jasmine Specs. Creates your HTML runners for you, runs headlessly, outputs JUnit XML
http://searls.github.io/jasmine-maven-plugin
Other
290 stars 163 forks source link

Could be released more often. Jasmine 1.3.0, and 1.3.1 are out #153

Closed SebTardif closed 11 years ago

SebTardif commented 11 years ago

Compared to other projects, it looks like this one doesn't often release even if we see activities/commits. It's odd. Usually, with Maven, doing release is not that much work.

searls commented 11 years ago

I disagree emphatically. Releasing to maven is easily the most arduous deploy process of any dependency repository I've dealt with.

In ruby:

  1. gem push

In node:

  1. npm publish

In maven:

  1. Run mvn release:prepare
  2. Usually, fix whatever didn't work because the git support is so hacky, and Maven's insistence on touching your source control so presumed.
  3. Reset hard to the prior commit and clear our the erroneous tag caused by #2
  4. Run mvn release:clean to clear the recollection of the failed release
  5. Run mvn release:prepare again
  6. Run mvn release:perform
  7. Dig up my GPG key and paste it in.
  8. Wait, then paste in the key again because apparently the build needs to sign things twice but can't keep my key in memory.
  9. Log into the OSS nexus repo via the web(!)
  10. Find the deployed release, click it, hunt the UI for the "stage" button
  11. Enter a reason for staging, which is required. You'd think the default reason would be "I wrote new stuff".
  12. Now, re-perform steps 10 & 11 verbatim, but this time with a "close" command instead. (Presumably this step exists so that you can integration test your deployment before it hits the wild, but after steps 1-11 I couldn't imagine having the time to.)
  13. Finally, wait 1-2 hours for the dependency to become available, the coup de grâce to this procedure's enterprise heartiness.
  14. In the case of projects that include an archetype like this one, wait two hours for the dependency to become available on Nexus central and then update it to the latest version and verify that it works.
  15. Deploy the archetype to a local nexus instance to generate the artifacts maven needs to use it.
  16. Push the updated nexus workspace to google code (I host it statically there because I don't have the energy to imagine going through steps 1-13 again)
  17. Update the documentation with the latest version, because there's no way to tell maven to just assume you want to create a new project with the latest version of a project template (this is really handy for people who prefer to start new projects from outdated dependencies however.)

The whole nexus central process is an absolute nightmare and is fraught with long build times, error-prone manual steps, and indeterminate multi-hour waits for packages to become available. Sometimes I get away without needing to do steps 2-4, but I release so rarely (for obvious reasons), that I usually hit a snag.

So I don't intend this missive to direct any vitriol towards you, OP. I just needed an excuse to document how inane Maven's open source release process is. If anyone knows a way to completely automate it, I'm sure @klieber would appreciate it.

interlock commented 11 years ago

@searls “:+1:”

klieber commented 11 years ago

@SebTardif There are plenty of issues that are currently being worked on. Concerned about the release schedule? Then chip in and submit a pull request. Don't want to or don't have the time? Then watch the milestones and wait patiently. These kind of "issues" are simply not helpful and just take away from the real work currently being done.

@searls right on