On 01/22/2015 06:57 PM, Mike
Milinkovich wrote:
I _think_ that what Chuck meant was different than the
interpretation I've seen in several responses. I am pretty that he
did not mean that people use the packages as the basis for a build
which their complete product. But a lot of products are made
available as plug-ins which are installed on top of an existing
Eclipse package. Which means that the creators of such products
will do their testing on top of a specific version of one or more
specific packages.
+1 on that.
When doing IDE related plugins, you definitely get much much more
users by shipping them as plugins that people install on top of
their favourite EPP package, than by shipping yet-another-IDE that
people won't even download. The I of IDE still means integrated,
having tools integrated in their IDE is what they want, not a
multiplication of IDEs.
Technically, here are a few questions/comments that would provide
more flexibility to users of EPP packages:
* Wouldn't using "requires" instead of "includes" in feature allow
updates of sub-features without rebuild of the main one?
* Could EPP products be *very* minimal branded products with
additional features installed on them with regular p2 director?
Instead of being set in the .product or feature.xml, versions would
be set in a pom.xml.
Note that both of them would allow many variations of the packages,
so from a user to another you could get many differences (it's
already the case, but it would be more) and one wouldn't be
guaranteed that Package X in version x.y.z contains feature A in
version a.b.c.
In general, I don't believe this is an issue if project deals
correctly with dependency versioning (in their feature.xml or
MANIFEST.MF), and if it becomes an issue, it's more the issue of 1
project than the issue of the EPP package. So IMO, these
loosely-coupled-to-features approach is acceptable.
To change your delivery options, retrieve your password, or unsubscribe from this list, visit