search

akhikhl / wuff

Gradle plugin for automating assembly of OSGi/Eclipse bundles and applications
MIT License
152 stars 51 forks source link

Eclipse Development + Eclipse Headless Build #84

Open maoueh opened 9 years ago

maoueh commented 9 years ago

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:

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 commented 9 years ago

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 https://github.com/akhikhl/wuff/issues/84.

heute schon etwas /Kritisches/ gelesen?

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

maoueh commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

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