Eclipse Development + Eclipse Headless Build

[maoueh]

Hi,

First of all, this is more some questions then a real issue. I did not find information on where to ask such question. If it's not the right place, I apologize in advance. Now, to the questions.

What would be the best way to enable both an headless build but still be able to develop the plugin within Eclipse IDE directly. For me, there is some open questions to this as to be able to compile the plugin within Eclipse directly, dependencies needs to be either in the workspace or in the target platform.

For this discussion, assume following projects

:api
   :services (depends on Guava and Jackson)
   :platform (depends on :api:services)
:server (depends on :api:services)
:plugin (depends on :api:services)

Now, to correctly compile the :plugin project within Eclipse, what we have currently in our workspace is five projects: :api:platform, :api:services, :plugin, :guava and :jackson (the last two being jar projects). With this, Eclipse is able to resolve dependencies specified in MANIFEST.MF file which contains mainly for example:

Bundle-Version: 1.0.0.qualifier
Bundle-Activator: plugin_test.Activator
Require-Bundle: org.eclipse.ui,
 org.eclipse.core.runtime,
 com.enterprise.api.platform;bundle-version="1.0.0",
 com.enterprise.api.services;bundle-version="1.0.0",
 com.google.common;bundle-version="17.0.0"
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ActivationPolicy: lazy

Now, what I would like is remove the need to have :guava and :jackson projects in my workspace. The only way I see to make it work within Eclipse would be create a customized target platform containing base Eclipse SDK plugins as well as all our needed dependencies (transitively).

So the question are:

• Is Wuff able to work with an Eclipse Target Platform to make the compilation heedlessly?
• Would it be possible to generate this Eclipse Target Platform automatically using for example the unpuzzle plugin (by inspecting resolved dependencies, mavenizing everything, and generate a target platform)?
• If it's not possible right now, would you be willing to accept contributions for this feature(s) (use target platform + generate one)?

In general, any guidelines on how to use Wuff for headless build but make it work so development of plugin can occur in Eclipse is welcome. Do you know any open source projects who are using Wuff in their build pipeline? Such example would be great. If there is none, I'm willing to create one to help people understand how everything needs to be wired to work.

Regards,
Matt

[carlolf]

Hi Matthieu,

I don't know if this helps you - I am not a Wuff user (only interested).

In our RCP application we defined a subproject with no sources, but as a
container for all external dependencies of all UI subprojects. The Jar
of this projects then is a listed in the "Plugin-dependencies" of all UI
/ RCP plugins. All packages needed from those external jars are listed
in the MANIFEST.MF; and the jar also lists it's bundle dependecies.
Like this:
/Bundle-ClassPath: lib/activeio-core-3.1.2.jar,//
// lib/activemq-core-5.5.1-fuse-04-01.jar,//
// lib/aopalliance-1.0.jar,//
// lib/aspectjrt-1.8.4.jar,//
// lib/aspectjweaver-1.8.4.jar,//
//..../
So, these dependencies are defined for Eclipse Osgi. What I don't like
with this is that a defintion like "lib/aspectjrt-1.8.4.jar" forces us
to have all those libs in the "lib"-Directory of this container
subproject - instead of referencing them from Gradle Cache (that we are
using for non-RCP projects). So, this (and also the target platform
jars) is not conform to the Gradle definitions of our build. Until now,
I could not see how Wuff could make this in another way.

This also means: our Gradle Build is a plain Java compiler build (with
some manipulations on the MANIFESTS), not an Eclipse compiler build; it
is based on classpath Jars, not on package dependencies.

But, as development is made with Eclipse - and all Eclipse dependencies
must be right by the definitions of each subprojects MANIFEST.MF, I do
not care very much on this difference.

Regards,
Carlo

Am 17.07.2015 um 15:12 schrieb Matthieu Vachon:

Hi,

First of all, this is more some questions then a real issue. I did not
find information on where to ask such question. If it's not the right
place, I apologize in advance. Now, to the questions.

What would be the best way to enable both an headless build but still
be able to develop the plugin within Eclipse IDE directly. For me,
there is some open questions to this as to be able to compile the
plugin within Eclipse directly, dependencies needs to be either in the
workspace or in the target platform.

For this discussion, assume following projects

|:api :services (depends on Guava and Jackson) :platform (depends on
:api:services) :server (depends on :api:services) :plugin (depends on
:api:services) |

Now, to correctly compile the |:plugin| project within Eclipse, what
we have currently in our workspace is five projects: |:api:platform|,
|:api:services|, |:plugin|, |:guava| and |:jackson| (the last two
being jar projects). With this, Eclipse is able to resolve
dependencies specified in |MANIFEST.MF| file which contains mainly for
example:

|Bundle-Version: 1.0.0.qualifier Bundle-Activator:
plugin_test.Activator Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime,
com.enterprise.api.platform;bundle-version="1.0.0",
com.enterprise.api.services;bundle-version="1.0.0",
com.google.common;bundle-version="17.0.0"
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ActivationPolicy: lazy |

Now, what I would like is remove the need to have |:guava| and
|:jackson| projects in my workspace. The only way I see to make it
work within Eclipse would be create a customized target platform
containing base Eclipse SDK plugins as well as all our needed
dependencies (transitively).

So the question are:

• Is Wuff able to work with an Eclipse Target Platform to make the
  compilation heedlessly?
• Would it be possible to generate this Eclipse Target Platform
  automatically using for example the |unpuzzle| plugin (by
  inspecting resolved dependencies, mavenizing everything, and
  generate a target platform)?
• If it's not possible right now, would you be willing to accept
  contributions for this feature(s) (use target platform + generate
  one)?

In general, any guidelines on how to use Wuff for headless build but
make it work so development of plugin can occur in Eclipse is welcome.
Do you know any open source projects who are using |Wuff| in their
build pipeline? Such example would be great. If there is none, I'm
willing to create one to help people understand how everything needs
to be wired to work.

Regards,
Matt

—
Reply to this email directly or view it on GitHub
#84.

---

heute schon etwas /Kritisches/ gelesen?

http://www.heise.de/tp/default.html oder: http://www.nachdenkseiten.de

[maoueh]

@carlolf Thanks for the heads-up. That definitely an interesting idea. I see this as an intermediate level between multiple "third-party" projects and a full-blown target platform containing everything I need (Eclipse + non-Eclipse dependencies).

On the first migration phase, my goal is to remove those "third-party" projects and convert non-Eclipse projects to Gradle. Using your trick of a single big third-parties project would be a good compromise until I find something better.

I could even see some automation here by having a Gradle script in this "meta" project that would:

1. Depends on all other projects.
2. Gather dependencies transitively via Gradle API.
3. And then updates/creates new dependencies on the "meta" project automatically (copying from cache, updating stuff, etc).

For information, I started some discussion on Buildship forums (Gradleware official Eclipse plugin for Gradle inside Eclipse) about externalizing what they used for their Eclipse based development here. I hope it will be possible to integrate what they have done within Wuff directly.

Again, thanks for the information on your own setup, I appreciate it.

Regards,
Matt

[maoueh]

@carlolf I'm currently trying some stuff around Wuff, Eclipse development and those kind of stuff. I implemented what you suggested/have in my single-vendor branch on a test repository.

If you have a few minutes, maybe you could take at look at the vendors project to check if it fits what you described in your previous comment. I think I got it right but just to be sure.

From there, I will check if I could easily transformed the vendors project into a target platform. I have hope that I could make Wuff learn how to use a target platform instead of a pure Eclipse SDK project.

[carlolf]

Hi Matt,

I don't know if I can give you more useful input on your goals. Note that the idea of our fat third party project which just acts as a container for libraries understandable for Eclipse OSGI was constructed long before we went to Gradle as the build tool.

Converted Gradle project the main job of it's build script is to create the expected container jar and to do some manipulations on the existing MANIFEST.MF; another task is to generate the eclipse ".classpath" file. (Note: at the moment I have problems with Buildship importing this project; see https://discuss.gradle.org/t/buildship-problem-with-an-eclipse-bundle-project/10488)

This all works sufficiently for us - the main developer work is done within Eclipse (working with MANIFEST.MFs, plugin.xml and the like). I'm not very interested using Gradle as a build tool WITHIN Eclipse. The only thing I'm very interested in: Eclipse seen dependencies and Gradle seen dependencies should match. And of course, I do not have any problems if Gradle "sees" much more in the build because using straight Java classpathes instead having the narrower concept of Eclipse/OSGI. To become this right is the Job of the developer working with Eclipse.

That said, my interest here was to find a way how the used Eclipse target platform (which is pretty old in our project (3.7.2!) can be used as Gradle build dependencies. At the moment we still use them from a "file repository" - jars are stored in svn, and checked out to a directory within the workspace - this is what I want to change.

regards Carlo