Status

[Pavel Tavoda]

Hello guys,

we are using now 3.0-SNAPSHOT for more than 4 projects. Everything works fine. Do we have some urgent/critical bugs which we have to close before release?

Torsten, I see some 'patches' for 3.0-RELEASE, are they working? Can you release to central?

Have a nice day

Pavel

[Ron Smith]

None I know of.  I'm using it on 1 real project.

[Torsten Juergeleit]

Torsten, I see some 'patches' for 3.0-RELEASE, are they working?

No. I just tried to use the Maven release plugin (MRP) to cut a release but to no avail. This is due to the fact that Sculptor internally uses disparate technologies: Eclipse / OSGi bundles for the DSL parser / text editor and Maven for the generator plugin. The Eclipse stuff (MANIFEST.MF, feature.xml, site.xml) has to be handled within the same Maven release process as well.

But MRP only cares about the Maven artifacts (mainly the POMs). The OSGi artifacts (e.g. the MANIFEST.MFs) are completely ignored by MRP. And MRP isn't flexible enough to mix-in the OSGi house-keeping from Eclipse Tychos version plugin. How to release a maven-built Eclipse project manually is shown here. 

Can you release to central?

I've managed to deploy snapshots to Sonatype OSS Forge (with the permissions granted in OSSRH-5507) at http://oss.sonatype.org/content/repositories/snapshots/org/sculptorgenerator/.

But without being able to cut a release I've nothing to deploy to the staging area at https://oss.sonatype.org/service/local/staging/deploy/maven2.

We have to come up with our own version of a release process for Sculptor (combination of Eclipse Tycho tools and Maven "standard" release).

Maybe we should adopt Gitflow Workflow and use the corresponding JGitFlow Maven plugin for doing releases. Maybe the JGitFlow plugin is easier to combine with Eclipse Tycho.

Unluckily I've currently only a limited amount of spare cycles left.

/Torsten 

[Torsten Juergeleit]

After adopting the Gitflow Workflow and using the corresponding JGitFlow Maven plugin I managed to upload Sculptor version 3.0.0 to the staging repository http://oss.sonatype.org/content/repositories/orgsculptorgenerator-1001/

/Torsten

On Tuesday, 5 November 2013 10:51:08 UTC+1, Pavel Tavoda wrote:

[Pavel Tavoda]

Thanks Torsten, now we have to wait till it get approved to normal repo?

[Torsten Juergeleit]

I've to fix a few glitches with the release process first, e.g.

 - Right now after deployment of the Maven artifacts to the Sonatype staging repository the development branch isn't merged with master, tagged and the new development version changed in the POMs and Eclipse XML config files within the development branch.

 - The Eclipse stuff isn't released together with the Maven stuff.

 - We don't need the separate GitHub repositories for the snapshots and release artifacts anymore. For the Eclipse stuff we can use a single one with separate branches for the releases and snapshots.

 - The Sculptor examples are using the wrong version of the Sculptor Maven plugin.

 - The Sculptor Maven archetypes are generating POMs which holding the wrong version of the Sculptor Maven plugin.

And I would like to rewrite the history of our Sculptor GitHub repository to get rid of all of these commits created by the maven release plugin.

After this I'm cutting a new release and deploying it to Sonatypes staging repository. Then we should check this staged release and after this we can propagate this release to Central.

/Torsten

[Pavel Tavoda]

Thanks for explanation.

Pavel

[Torsten Juergeleit]

A few of the glitches in the release process are fixed:

 - The examples and the Mave archetypes are fixed.
 - The Eclipse plugin will be deployed to the folder "updates/" in the GitHub repository with the Sculptor web site. So we will get a nice URL for the Eclipse update site: http://sculptorgenerator.org/updates/

One major issue is still open: During the release build the Maven source plugin is forking a separate process which calls the Maven clean plugin which deletes the stuff from the target folder.

Btw. to use the JGitFlow Maven plugin we have to adopt the Gitflow Workflow. So the branches in the Sculptor GitHub source code repository are used differently, e.g. "master" is used by the JGitFlow plugin only. The developers are working in separate feature/hotfix branches which are merged in the "develop" branch, releases are cut from the "develop" branch, ...

So please check the blog post Why aren't you using git-flow? and prepare your local git installation with the git flow extension (the unix guys should install the git flow extension for bash as well). Don't forget to configure your favourite Git client GUI as well. To see the jgitflow plugin in action within Atlassian watch this presentation from the plugin author.

And please hold on with pushes to the Sculptor repo on GitHub because I've already migrated my local repository to git flow and didn't push these changes yet. After this push you should pull the migrated repo and start working within your own feature/hotfix branches which are merged into the "develop" branch.

/Torsten

[Pavel Tavoda]

Wonderful Torsten. Thanks for useful links. Again some reading for weekend ;-).

Can we somehow really protect 'master' against pushes?

[Torsten Juergeleit]

Can we somehow really protect 'master' against pushes?

Nope, this is one of the shortcomings of a DVCS. But with currently 6 committers this should be doable via conventions :-P
For contributions from non-committers a pull request for a feature branch in a fork will be used. This feature branch is merged by one of the committers into the develop branch.

I'm updating the development documentation accordingly.

/Torsten

[Torsten Juergeleit]

I'm updating the development documentation accordingly.

Done. The development process and the release process are described here.

/Torsten