[jbosstools-dev] Fwd: Best way to handle 2 code streams

[Rob Cernich]

Yep. That's what I was thinking. As I said, I'm not sure about the upgrade process. My concern is that once one of the child features is installed, you may not be able to update at all (i.e. a wtp upgrade would balk because the e42 plugin isn't compatible). That said, users probably won't be using the update mechanism when updating the platform, so you should be good. 

----- Original Message -----

> Thanks Rob, sounds very interesting indeed. But I need to look how to
> set it up.

> so if I understand correctly that'd give us something like :
> org.eclipse.m2e.wtp.jpa.feature
> |___org.eclipse.m2e.wtp.jpa / contains activator / plugin.xml / m2e
> |xml settings / common classes
> |___org.eclipse.m2e.wtp.jpa.e42.feature (optional)
> |___org.eclipse.m2e.wtp.jpa.e42 : pre-kepler compatible project
> |configurator impl.
> |___org.eclipse.m2e.wtp.jpa.e43.feature (optional)

> |___org.eclipse.m2e.wtp.jpa.e43 : kepler compatible project
> |configurator impl.

> So that means if a juno user installs the JPA feature, only
> org.eclipse.m2e.wtp.jpa.e42.feature will be installed because the
> Dali version restriction range matches what's available in juno?

> IF that's correct AND that scenario supports upgrades from juno to
> kepler, that's most probably the best way to go. Any one else can
> confirm?

> Fred

> On Thu, Jan 10, 2013 at 6:32 PM, Rob Cernich < rcernich at redhat.com >
> wrote:

> > 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).
> 

> > > Any input is welcome.
> > 
> 

> > > ---------- Forwarded message ----------
> > 
> 
> > > From: Fred Bricon < fbricon at 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 at 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 at lists.jboss.org
> > 
> 
> > > https://lists.jboss.org/mailman/listinfo/jbosstools-dev
> > 
> 
> --
> "Have you tried turning it off and on again" - The IT Crowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20130110/e1662976/attachment-0001.html