Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] Building Papyrus with Google Guava

Hi,

I'm not really in favor of adding a new build configuration to check each guava version. However, I do a manual check from time to time (Especially before major releases, and when issues are reported) with each individual Guava version, and with a set of different versions as well (Building + Running; I usually don't execute all tests with each possible version of Guava)

Compilation against each individual version and basic testing with a set of different versions is usually sufficient, because when conflicts occur, they break the core Papyrus components (i.e. almost everything crashes). Hard to miss.

Camille

-----Message d'origine-----
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Ed Willink
Envoyé : jeudi 17 juillet 2014 18:00
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] Building Papyrus with Google Guava

Hi Christian

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=437107

Uses directives are now a viable option. But as yet just about no one uses them so who knows if they work.

Someione needs tio kick some life into this, ideally before RC3.

     Regards

         Ed Willink

On 17/07/2014 15:12, Christian W. Damus wrote:
> Hi, Team,
>
> Yesterday, I pushed a Gerrit review with a bunch of new code, some of it using those handy Google Guava utilities that we all enjoy so much.  The Hudson CI job happily built my new code.
>
> There's a problem, though:  I think it should have failed to compile.
>
> The reason is that my code was using APIs that are in the 11.0 release of Guava but had been removed somewhere in or around the 14.0/15.0 release.  As I understand it, the Luna EPPs generally ship with Guava 15.0, right?
>
> Currently, our various plug-ins that use Guava express a Require-Bundle dependency on a version range [11.0.0, ∞).  If we're going to stick with that, then we need to build Papyrus against every one of those major Guava versions:  11.0, 12.0, 13.0, 14.0, 15.0, and whatever subsequent new version is adopted from time to time by Orbit, to verify that the APIs we are using still exist (and hopefully our test coverage checks that those APIs still behave the way we expect).  Otherwise, we would have to let OSGi protect us from breakage by using upper bounds (e.g., [11.0.0, 12.0.0) etc.).
>
> I know why we've left the upper bound unconstrained, because of the serious integration headaches in the release train, but if this continues, we are going to see Papyrus break on some users' desktops the next time they update.  Even having the build check that we are compatible with every currently available Guava isn't sufficient because there will be new Guavas and Google will break APIs.
>
> Thoughts?
>
> Christian
>
>
> P.S. The reason this question arises now is that I have switched my main development workspace from the painstakingly managed projects and PDE target I've been using for the last two years (with Guava 11) to the Oomph setup.  Oomph naturally brought Guava 15 into my PDE target.
> _______________________________________________
> mdt-papyrus.dev mailing list
> mdt-papyrus.dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit 
> https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev


_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

Back to the top