Have you thought about breaking out the jpa related code base so that you only need to
branch those bits? You could then have e42 and e43 plugins, included by jpa e42 and e43
features that are declared as optional in the main feature. In that case, all the plugins
and features have the same version and the correct child feature gets installed based on
the wtp version. I'm not sure about the update process (I worry you'd have to
uninstall the previous jpa feature prior to installing the new feature).
----- Original Message -----
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
>
_______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev