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

[Fred Bricon]

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/351bc13d/attachment.html