Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epp-dev] Include versus requires/import 
Thanks David.  I missed this initially.
The p2.inf solution used in the bug was what I was originally looking for. It allows an import with an optional=true tag. The parallel feature already uses this to optionally require some machine-specific features.
Thus, the include of linux tools features in the CPP feature could be removed and moved to be optional imports in the p2.inf file. This would allow the package to build for all the various platforms and also permit updating of these features in the future. A comment could be added in the feature.xml to mention that those features are being imported via the p2.inf. 

Did I miss anything?

-- Jeff J.

On 03/21/2012 10:55 AM, David M Williams wrote:

For what its worth, there's some amount of history/discussion on this topic
in

Bug 345503 - Reconsider patch/update policy for EPP Packages

No answers, per se ... more a "depends on what you want" type of answer.

I think the following bug contains useful "how to do with p2" info (p2.inf,
that is).
(despite the title, the "interesting thing" in this case doesn't have to do
with Tycho, ... but, with how they "fixed" some issues with p2.inf file).

Bug 366430 - Building EPP packages with Tycho


Not to mention this "won't fix" bug:

Bug 329973 - Can EPP packages have more than one top level feature, to make
updates easier?


Bugzilla is your friend ... :)






From:	Markus Knauer<mknauer@xxxxxxxxxxxxxxxxx>
To:	Eclipse Packaging Project<epp-dev@xxxxxxxxxxx>,
Date:	03/21/2012 10:39 AM
Subject:	Re: [epp-dev] Include versus requires/import
Sent by:	epp-dev-bounces@xxxxxxxxxxx



I completely agree.

A) (update R->SR1->SR2) is tested and would be supported by both, includes
and requires

B) and C) only possible with 'requires' but not with 'includes'

D) That's a new one and I think it is worth adding it to the list:
Automated updates. If a project A is part of a package, it is a child of
the package feature. If project A releases a new version with bugfixes on
their p2 repository, there is no automated update of the package content
possible unless (a) the package feature is updated or (b) the user manually
installs the features from project A as root features into the package.

Regards,
Markus

On Wed, Mar 21, 2012 at 15:02, Eric Rizzo<eclipse-mail@xxxxxxxxxxxx>
wrote:
   On 3/21/12 5:09 AM, Markus Knauer wrote:
    There is one subtle difference:

    - includes: The feature is bound to a single version and cannot be
    upgraded unless the parent feature (EPP) is changed.
    - requires: The feature is not upgraded automatically unless the parent
    feature (EPP) is changed, but a newer version can be installed manually
    into the package (i.e. it is not forbidden to install a version with a
    higher version number).

    But I like this discussion... my point is that we all need to understand
    the difference and that I'd like to have all packages defined in an
    equal way.

   There's an important Community impact here that I think merits serious
   consideration. While "includes" might be more convenient for package
   maintainers and releng team, it might produce a product that is
   frustrating or impossible for end-users to update piecemeal. I'm not sure
   if it will or won't, but want the package maintainers to know :-)

   There are several common scenarios that I think we need to make sure will
   work smoothly for users:

   A) I download an EPP package initial release. Later SR1 or SR2 is
   released and I want to easily update to that release of the same package
   I originally installed. I'm pretty sure this is tested already, correct?

   B) I download an EPP package, for example Eclipse for Java Developers.
   Later I realize that I want some other set of features, such as
   JavaScript tooling or modeling tools, but the current version of the new
   features/plugins I want depends on a version of something in my original
   package that is newer than what the package originally included. For
   example, version 25.3 of ECore Tools depends on version 19.3.5 of JFace,
   but my EPP package included JFace version 19.3.0. I should be able to do
   this update smoothly without all of p2's confusing and overwhelming
   "cannot satisfy dependency" errors.

   C) I downloaded an EPP package initial release, but later want to update
   one of the components of that package from it's project's own update site
   (maybe a critical bug fix in between SRs, whatever). Again, I should b
   able to do that update smoothly and easily.

   Since the EPP packages are what most users get (by a large margin), I
   think we should be careful to avoid making those packages difficult to
   update or add on to. At the very least those three scenarios should work
   smoothly. There might be more I haven't though of.

   Eric


   _______________________________________________
   epp-dev mailing list
   epp-dev@xxxxxxxxxxx
   https://dev.eclipse.org/mailman/listinfo/epp-dev
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev


_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev

Back to the top