What's missing from my setup?

[merks]

The Oomphed setup comes up like this:

I have a feeling that something that's generated is missing. If the src-gen folder is needed for the builder to work, it should probably contain an empty .ignit ignore, but the root .gitignore already has src-gen/. Is something suppose to create that folder? Is there something that should be installed that would generate the missing things?

[HannesWell]

Your feeling is right. Unfortunately since M2E-2.0 the connector for the modello-maven-plugin is broken and has not yet been adjusted. Therefore the missing source files are not generated.
I already looked into commanding m2e to just execute the plugin during builds, but didn't succeed (in general I think this is something that should be fixed). I hope it can be made working with some little rework.

In the meantime, as a workaround you can run the m2e-core--build Maven build launch up to the o.e.m2e.core plugin, that should generate the sources. Then you only have to refresh the o.e.m2e.core project.

[merks]

I copied it from a *.source jar but then later I noticed that the full m2e build did generate it...

[HannesWell]

That would work as well.
But this situation is bad, I'll try to fix it soon.

[HannesWell]

Created #1072 to fix it.

[merks]

Another question but I'll reuse this thread...

Are you guys interested in generating a structured update site? I don't want to do a bunch of work and then folks don't want it or don't like this.

Basically this involved adding an additional "promotion" pom.xml like this one:

https://git.eclipse.org/c/oomph/org.eclipse.oomph.incubator.git/tree/simrel-extras/releng/org.eclipse.oomph.simrel.extra.parent/promotion/pom.xml

The build is then parameterized like this:

https://git.eclipse.org/c/oomph/org.eclipse.oomph.incubator.git/tree/simrel-extras/releng/org.eclipse.oomph.simrel.extra.parent/SimRelExtras.jenkinsfile

It is used in this build:

https://ci.eclipse.org/oomph/job/simrel/job/simrel-extras/

So the build is launched like this:

In your case I'd make the PROMOTE default to true, but also take account the branch such that you only can promote a master branch build.

It produces an update site like this:

https://download.eclipse.org/oomph/simrel-extras/

The syncing of the generated update site to and from the download.eclipse.org is done by the application itself, eliminating this part of your Jenkins script as well as other jobs you have for copying update sites from one place to another.

The number of nightly builds in the nightly composite is limited and the limit is configurable; there is a nightly/latest. The milestone builds must be kicked off manually at the time of your choosing. Old milestones are automatically cleaned up from the milestone composite when a new higher version is detected. For the final release build (also manual kick-off), the most recent milestone is copied to the releases. Both milestone and release have a p2 mirror property and both have a latest composite.

With this approach, the whole process is pretty much automated, self maintaining, and the sites are self-documenting, including details about the features and bundles available.

But again, I do not want to invest time on this if this is not what you folks want so please as a group decide whether this is worth my time.

[HannesWell]

In general I think it would be nice to get a structured p2-repo site generated. 👍🏽

But I have a few questions:

• How is archiving handled? Will I still be able to archive releases (manually), via download.eclipse.org? If yes they are probably removed as displayed content? In general a hint like "Looking for an older release, see the archives ", would probably be good as well.
• At the moment the overall current release/release-under-development 'branding' version is directly derived from the o.e.m2e.sdk feature. Would that still be possible?
• Could we keep the milestones at least until the next release? And maybe even a bit longer, which probably means one has to delete them manually. The reason I ask are cases like in Requesting 2.0.6 for Issue 924 (ConcurrentModificationException fix) #999 (comment), where some people use the milestones since we have no release yet and I would like to be gentle to them and give them a little bit more time for the transition.
• Can the URLs use the same path 'style' like it is used now: https://download.eclipse.org/technology/m2e/releases/<release-version>?

@laeubi, @fbricon what's your opinion?
@mickaelistria from past discussions I know that you only care about retaining releases, so I assume you would be fine as well?

[merks]

You can look at the underlying structure via this URL

https://download.eclipse.org/justj/?file=oomph/simrel-extras/release

Yes, you will still be able to move a URL to archive.eclipse.org, but I don't know how the 404 handler page can be forced to appear when there is an index.* file in the folder. The next time the site is composed, the reference will be removed from the links. A moved site continues to work via the down.eclipse.org URL because the server automatically uses archive.eclipse.org as mirror/redirection.

Yes, the -version-iu argument can be used to control the branding version number.

Milestones persist until you build a milestone for a higher version number. So say you are build 1.0.1 and then release it. So you increment to 1.0.2 later, do nightly builds, and then eventually (maybe a month later) do a milestone build, all the 1.0.1 milestones are then removed and replaced with the first new 1.0.2 milestone. Clients can used milestone/latest to always get your more recent milestone build, regardless of the version number.

The release does use the version number:

https://download.eclipse.org/oomph/simrel-extras/release/1.0.1/

But I don't think it's good to maintain the set of sites (including the root index.html) right at the project root because you have other things at the root:

https://download.eclipse.org/technology/m2e

Of course you could point /releases/x.y.z to /updates/release/x.y.z via a composite...