Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [imp-dev] SDF, Box (and ASF+SDF Meta-Environment) deployment on Eclipse platform plan 
Jurgen Vinju wrote:

Hi guys,

This our idea of how we are going to deploy the SDF stuff on the
Eclipse platform in the future. The issues are:
  <snip, snip>
So, the plan is:
  1. Make all "packages" Eclipse plugin projects (already done: by
adapting our build environment to generate META-INF and plugin.xml
files for the C packages.)


Sounds good.


  2. For each package, generate a FRAGMENT .jar file that contains the
META-INF and the C binaries and scripts produced by the package


I assume this is a platform-specific fragment, right?


  3. For each package, generate a PLUGIN .jar file that only contains
a META-INF file. This can be empty for C packages, because C packages
only have platform dependant code.
      For Java packages, this will contain the Java class files and
code as usual.


Right.


  4. For each package, generate a feature.jar file that contains the
feature.xml and META-INF that only has one plugin in it, and use our
"package"
      dependencies for the feature dependencies.
This is the part I don't get. Why not include *all* of the platform-specific plugin fragments in the feature, per Eclipse convention? Each plugin fragment identifies the platform it's intended for. Unless you're addressing the issue that the target platform constraints (e.g. "os", "arch", etc.) aren't specific enough. But then, 
regardless, how are inter-feature dependencies going to work wrt platform-
specific fragments? How is the Update Mangler going to figure out what to
install?


  5. Provide a plugin project that has an extension point for
registering C packages with binaries installed in them, which handles
PATH and other settings
      and provides a convenient class for communicating with such
tools via pipes, files or maybe even sockets (can be constructed from
the current SDF Tools class).


Sounds cool. Can you post more details on this?


Drawbacks:
  - none that we see, apart from a rather strange one-to-one mapping
between plugins and features that might surprise some people.

Benefits:
  - The Eclipse update site feature will allow the user to select
parts of SDF as he sees fit, because the feature dependencies reflect
our package dependencies.
The real question is (as mentioned above) how will the dependencies among features work wrt platform-specific fragments? And, in particular, will the Update Manager's 
"Select Required" button be able to do the right thing?


  - The evolving implementation of SDF, and other stuff, will
automatically be reflected in the update site. No overhead for the
maintainers of SDF.
  - It allows for `package by package' reimplementation of C code to
Java (if that is what we would want, but still, it's nice to have the
possibility).


That's definitely nice.


Question:
  - are there any blind spots in our plan; are we missing some kind of
limitation, requirement, or technical detail that might mess up this
little plan?


--
Cheers,
 -- Bob

--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center

IMP Team Lead (http://eclipse-imp.sourceforge.net)
X10: Productivity for High-Performance Parallel Programming (http://x10.sf.net)

Back to the top