Any input is welcome.
---------- Forwarded message ----------
From: Fred Bricon <fbricon(a)gmail.com>
Date: Thu, Jan 10, 2013 at 4:29 PM
Subject: Best way to handle 2 code streams
To: M2E-WTP Developers mailing list <m2e-wtp-dev(a)eclipse.org>
Hi,
first of all, let me wish you all a very Happy New Year. I hope it'll see
m2e-wtp graduate from the eclipse incubator next June ;-)
During last call, we decided m2e-wtp would provide a JPA configurator for
both the Kepler and pre-Kepler streams, due to Dali moving its provisional
API, meaning we now need to maintain two branches of code. So I've been
trying to think at the best strategy that would lead to the minimum
maintenance overhead while allowing to provide new cool features for
everybody.
1/ have 2 different JPA features in 1 git repo :
Somethink like org.eclipse.m2e.wtp.jpa.feature (for kepler and onward)
and org.eclipse.m2e.wtp.jpa.e42.feature (pre-kepler). Both features would
be built and appear in the same update site (version 0.17.0). This gives us
all the code easily accessible for maintenance (from my point of view) as
we wouldn't have to switch between branches in order to apply fixes in both
JPA configurators.
The biggest problem though, is we wouldn't be able to provide a way to
upgrade from jpa.e42 to jpa. There's already a p2.inf hack allowing the
upgrade from the jboss tools jpa feature to the eclipse one, that hack
prevents us from adding the jpa (juno) to jpa (kepler) upgrade path (Tycho
breaks seeing the same IU being built twice).
2/ Have 2 m2e-wtp versions in 2 branches of a git repo
We'd provide 2 separate update sites:
* a "pre-kepler" p2 repo with m2e-wtp 0.17.0, built from a git 0.17.0 branch
* a kepler repo with m2e-wtp 0.18.0/1.0, built from master.
This would be easier to build, from a tycho perspective, and we'd still be
able to upgrade from juno to kepler AND from jboss tools. But it would
bring a *huge* overhead in non-JPA maintenance.
3/ Have JPA in a dedicated git repo, use specific qualifiers :
We'd provide 2 separate update sites:
* a "pre-kepler" aggregated p2 repo with m2e-wtp 0.17.0, built from master
and a jpa.0.17.0-e42.timestamp site, built from the e42 branch of the
m2e-wtp-jpa git repo,
* a kepler aggegated p2 repo with m2e-wtp 0.17.0, built from master and a
jpa.0.17.0-e43.timestamp site, built from the master branch of the
m2e-wtp-jpa git repo,
It requires 2 tycho builds and more manual hacking of the aggregated sites,
but would be easier to maintain, from a code perspective. And we'd still be
able to upgrade from 0.17.0-e42 to 0.17.0-e43.
I think I like #3 better (but I haven't tested the approach works yet).
What do you think?
Fred Bricon
--
"Have you tried turning it off and on again" - The IT Crowd
--
"Have you tried turning it off and on again" - The IT Crowd