Comment 1 Lars Vogel 2013-03-13 14:59:20 EDT

(In reply to comment #0)
> Ideally, o.e.e4.tools would use the maven dependency mechanism to resolve
> the parent pom.

How would be do that?

Comment 2 Markus Kuppe 2013-03-13 15:00:57 EDT

(In reply to comment #1)
> How would be do that?

E.g. push o.e.e4.releng artifact to repo.eclipse.org

Comment 3 Lars Vogel 2013-03-13 15:24:00 EDT

+1 from me for this change. Is this something CBI would be doing?

Comment 4 Markus Kuppe 2013-03-13 15:26:52 EDT

To me it rather looks like the owner of o.e.e4.releng has to push it.

Comment 5 Thanh Ha 2013-03-13 15:59:11 EDT

(In reply to comment #4)
> To me it rather looks like the owner of o.e.e4.releng has to push it.

The owner of o.e.e4.releng would have to push it following instructions from http://wiki.eclipse.org/Services/Nexus. In order to do that they would have to request a repo on repo.eclipse.org if one isn't already created.

Is this project part of the eclipse.platform project? 

If so there is already assigned repos. If not please create a Bug under the category Eclipse Foundation > Community > Nexus

Comment 6 Paul Webster 2013-03-13 16:00:25 EDT

We have a problem with maven vs OSGi qualifiers.  The parent pom contains the configuration information for that stream (repos to build against,  compiler to use, etc).

If we change the co-ordinates (update the version) we have to update every bundle pom, which bumps the qualifier for effectively no change.

I wasn't able to get maven to parameterize the parent version, so it's a change that has to be propagate to every pom, unfortunately.

Potential options that I can see:

1) we always publish the snapshot, 1.0.0-SNAPSHOT, that we feel will build the current build ... if you're not in master, all bets are off.

2) We make the parent 0.13.0-SNAPSHOT, 0.14.0-SNAPSHOT reflect the stream.  We never graduate the snapshots.  We configure the timestamp provider to ignore pom.xml, and add a edit.me.to.update.qualifier.txt file of some kind, so that non-source changes can force a qualifier update

3) we create the self contained parent in each repo.  We still follow option #1 as far as the snapshot will never release and then all of the configuration needs to be replicated for each repo parent pom.

More options welcome.

PW

Comment 7 Thanh Ha 2013-03-13 16:08:39 EDT

(In reply to comment #6)
> We have a problem with maven vs OSGi qualifiers.  The parent pom contains
> the configuration information for that stream (repos to build against, 
> compiler to use, etc).
> 

To add to this, I had a quick look at the root pom in org.eclipse.e4.tools and it contains no information regarding where to look for dependencies which means Maven will only check Maven Central (as far as I know). At minimum if the parent pom doesn't exist in this repo then some configuration would need to be added to let Maven know where to check for the additional dependencies (likely to one of the repos on repo.eclipse.org)

Comment 8 Mickael Istria 2013-03-14 03:54:14 EDT

(In reply to comment #6)
> We have a problem with maven vs OSGi qualifiers.  The parent pom contains
> the configuration information for that stream (repos to build against, 
> compiler to use, etc).

This could maybe be resolved with usage of target-platform definition. Target-platform definitions can be versionned and shared on Nexus. So it wouldn't become necessary to change the parent pom to use a new target-platform.

> If we change the co-ordinates (update the version) we have to update every
> bundle pom, which bumps the qualifier for effectively no change.

Aren't you using the git-timestamp provider with the pom.xml ignored?
If yes, it should be fine then.
If not, is this really that important to have new qualifiers on each build? Most other Eclipse projects produce a new qualifier for each build and no-one complains.

> 1) we always publish the snapshot, 1.0.0-SNAPSHOT, that we feel will build
> the current build ... if you're not in master, all bets are off.
> 
> 2) We make the parent 0.13.0-SNAPSHOT, 0.14.0-SNAPSHOT reflect the stream. 
> We never graduate the snapshots.  We configure the timestamp provider to
> ignore pom.xml, and add a edit.me.to.update.qualifier.txt file of some kind,
> so that non-source changes can force a qualifier update

It's better to use different versions instead of 1.0.0-SNAPSHOTs as one will one day want to build old stuff, it would be a pity if he get a "too new" SNAPSHOT for his old stuff.
You could also graduate just before the release, when you're sure you don't need to change them in order to produce the release. With git-timestamp-plugin ignoring pom, projects would have to use a release (and no SNAPSHOT) in order to build their release. This is a general Maven good practice which applies well to Tycho.

> 3) we create the self contained parent in each repo.  We still follow option
> #1 as far as the snapshot will never release and then all of the
> configuration needs to be replicated for each repo parent pom.

I might be the most pragmatic solution. Just let projects have and manage their own parent pom containing what they need.


Let's add a #4
4) In parent pom, everything that is specific to the stream is set in properties, so that customer of the parent pom could override those properties in their pom (or CI jobs) to reflect what's meaningful for them.
When starting a new stream. a project has to check whether the current parent pom satisfies his needs; in case it's not, the root pom of project overrides the stream properties to some that are better for it.

Comment 9 Paul Webster 2013-03-14 07:51:53 EDT

(In reply to comment #8)
> > If we change the co-ordinates (update the version) we have to update every
> > bundle pom, which bumps the qualifier for effectively no change.
> 
> Aren't you using the git-timestamp provider with the pom.xml ignored?
> If yes, it should be fine then.
> If not, is this really that important to have new qualifiers on each build?
> Most other Eclipse projects produce a new qualifier for each build and
> no-one complains.

Yes, this is vitally important (anybody that tries to update complains about this all the time :-).  The Platform project produces over 1000 bundles a build, with over 600 per classic SDK.

Even smaller projects contributing to the release train should only update their qualifiers if their bundles change ... the aggregator contains over 4500, and changing qualifiers for no reason kinda negates a lot of the benefit of p2 during upgrades.  If a build produce OSGi bundles with new qualifiers but no changes, well, let's just say that's not one of our best practices.

> 
> Let's add a #4
> 4) In parent pom, everything that is specific to the stream is set in
> properties, so that customer of the parent pom could override those
> properties in their pom (or CI jobs) to reflect what's meaningful for them.

Most of the things that are configured in the parent pom are already defined in the properties section, so in theory one could do this today (and just keep an 1.0.0-SNAPSHOT) but that makes anybody not building against master have to come up with *really* long execution line, or worse, accidentally build against the incorrect targets.

PW

Comment 10 Paul Webster 2013-03-14 07:54:55 EDT

(In reply to comment #8)
> 
> Aren't you using the git-timestamp provider with the pom.xml ignored?
> If yes, it should be fine then.

This would allow us to adopt option #2 from comment #6 (I'm kinda leaning towards this, as it makes the parent co-ordinates match the branch, keeps the versions separate, and just makes sense).

PW

Comment 11 Paul Webster 2013-03-14 09:18:22 EDT

If we adopt option 2 this script will update the pom files:http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/scripts/xsl/xparentVersions.sh

1) fix the <project> element so it has a namespace
2) update all packaging versions: pom and eclipse-repository
3) update all poms containing a parent
4) add forceQualifierUpdate.txt to all bundles and features and test plugins

PW

Comment 12 Paul Webster 2013-03-25 12:03:01 EDT

I've pushed up some change sets.  Lars, could you check out at least tools.
tools: https://git.eclipse.org/r/#/c/11430/


https://git.eclipse.org/r/#/c/11428/
https://git.eclipse.org/r/#/c/11426/
https://git.eclipse.org/r/#/c/11429/

I've run a test build, and it looks like it works fine for our builds.

If you're OK with the tools setup, then we need to push all of the changes at the same time (including releng and search, no Gerrit). 


Then we can get Thanh to push the parent pom to our eclipse-snapshots repo and you guys can look at adding the repo.eclipse.org repository entry to the root pom in all of the repos, similar to how it's done in Bug 403966



PW

Comment 13 Lars Vogel 2013-03-25 13:57:54 EDT

Trying to run the e4tools build, I get the following error:

Caused by: java.lang.RuntimeException: "No solution found because the problem is unsatisfiable.": ["Unable to satisfy dependency from org.eclipse.e4.tools 0.12.0.qualifier to bundle org.eclipse.emf.ecore 2.9.0.", "Unable to satisfy dependency from org.eclipse.e4.tools 0.12.0.qualifier to bundle org.eclipse.emf.ecore.xmi 2.9.0.", "Unable to satisfy dependency from org.eclipse.jdt.core 3.8.1.v_OTDT_r210_201206090452 to org.eclipse.objectteams.otdt.core.patch.feature.group [2.0.0,3.0.0).", "Unable to satisfy dependency from org.eclipse.jdt.core 3.8.2.v_OTDT_r211_201209011847 to org.eclipse.objectteams.otdt.core.patch.feature.group [2.0.0,3.0.0).", "Unable to satisfy dependency from org.eclipse.jdt.core 3.8.3.v_OTDT_r212_201301271217 to org.eclipse.objectteams.otdt.core.patch.feature.group [2.0.0,3.0.0).", "No solution found because the problem is unsatisfiable."]

Comment 14 Lars Vogel 2013-03-25 14:04:49 EDT

The above error message was before pulling in the patch. After pulling in the patch, I get:

[ERROR]     Non-resolvable parent POM: Could not find artifact org.eclipse.e4.releng:eclipse-parent:pom:0.14.0-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 4, column 11 -> [Help 2]
[ERROR]

Comment 15 Lars Vogel 2013-03-25 14:48:12 EDT

(In reply to comment #13)

I had to update the releng repo to solve that:

git clone git://git.eclipse.org/gitroot/e4/org.eclipse.e4.releng.git
# Install the CBI build configuration
mvn -f org.eclipse.e4.releng/cbi/eclipse-parent/pom.xml clean install

I now try the patch again.

Comment 16 Lars Vogel 2013-03-25 14:55:00 EDT

I still get the parent pom not found error if I pull in the change from Gerrit.

I run: git pull git://git.eclipse.org/gitroot/e4/org.eclipse.e4.tools refs/changes/30/11430/1

And running mvn clean install I get:

[ERROR]     Non-resolvable parent POM: Could not find artifact org.eclipse.e4.releng:eclipse-parent:pom:0.14.0-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 4, column 11 -> [Help 2]
[ERROR]

Comment 17 Paul Webster 2013-03-25 15:34:28 EDT

You'll need the releng change to test it, so I've pushed the releng one up to a topic branch:

Pull this into your releng repo and run the regular steps and it should compile.

PW

Comment 18 Paul Webster 2013-03-25 15:35:29 EDT

http://git.eclipse.org/c/e4/org.eclipse.e4.releng.git/log/?h=pwebster/bug403237

It would also help if I included the link.

PW

Comment 19 Lars Vogel 2013-03-25 15:56:12 EDT

Thanks Paul, with the releng patch this works. Would be great if you push it, afterwards we can start to modify the e4 pom files.

Comment 20 Paul Webster 2013-03-25 22:40:09 EDT

(In reply to comment #12)
> I've pushed up some change sets.  Lars, could you check out at least tools.
> tools: https://git.eclipse.org/r/#/c/11430/
> 
> 
> https://git.eclipse.org/r/#/c/11428/
> https://git.eclipse.org/r/#/c/11426/
> https://git.eclipse.org/r/#/c/11429/
> 


I've released these changes, plus e4.releng and e4.search.

The next step is to deploy the parent 0.14.0-SNAPSHOT to repo.eclipse.org

I'll update the bug when it's done.

PW

Comment 21 Lars Vogel 2013-06-05 06:28:17 EDT

@Paul, did you manage to deploy parent 0.14.0-SNAPSHOT to repo.eclipse.org? I just ran into the issue again that "mvn clean instll

Comment 22 Lars Vogel 2013-06-05 06:28:39 EDT

@Paul, did you manage to deploy parent 0.14.0-SNAPSHOT to repo.eclipse.org? I just ran into the issue again that "mvn clean install" required the relang repo to be installed locally.

Comment 23 Paul Webster 2013-06-05 10:08:32 EDT

OK, the snapshot is deployed on repo.eclipse.org.  Someone will need to update the o.e.e4.tools pom.xml to take advantage of it, and let us know.

AFAIK they need to add something similar to http://git.eclipse.org/c/jdt/eclipse.jdt.git/tree/pom.xml#n31

PW

Comment 24 Markus Kuppe 2013-06-17 08:57:51 EDT

(In reply to comment #23)
> OK, the snapshot is deployed on repo.eclipse.org.  Someone will need to
> update the o.e.e4.tools pom.xml to take advantage of it, and let us know.
> 
> AFAIK they need to add something similar to
> http://git.eclipse.org/c/jdt/eclipse.jdt.git/tree/pom.xml#n31
> 
> PW

Hi Paul,

please review https://git.eclipse.org/r/13850

Thanks
Markus

Comment 25 Lars Vogel 2013-06-18 05:56:06 EDT

Fixed with https://git.eclipse.org/r/#/c/13851/