Provide instructions how to use Wuff without jcenter

[frankgerhardt]

I have a well thought out target platform and I want to use only that for the build.

How can I do that with Wuff?

[frankgerhardt]

I read some of the wiki page. It would be fine to have a local maven repo. Then I should probably put my dependencies (aka target plug-ins) there?

Well, I'm checking out Gradle because I wanted to avoid working with Maven at all. Seem Wuff can only work with Maven. That means, I now have to learn Gradle AND Maven. Any ideas to make it easier?

[akhikhl]

Wuff maintains it's own platform model within the file: https://github.com/akhikhl/wuff/blob/master/libs/wuff-plugin/src/main/resources/org/akhikhl/wuff/defaultConfig.groovy This file is automatically loaded as soon as Wuff plugin is applied to the project. As you see, the file contains description of multiple Eclipse versions and respective configurations for various library types (OSGi, eclipse-bundle, eclipse-rcp, eclipse-ide, swt). All these details are hidden from the application writer (altough you can write completely new configurations in the same syntax in wuff object of your project). Considerations on dependency management:

• you put eclipse bundles and applications in the same project tree (see Chapter 56. Multi-project Builds in gradle documentation).

• eclipse bundles and applications refer each other in usual gradle syntax:

  dependencies {
    compile project(':MyEclipsePlugin1')
  }
  

• Wuff takes care of Require-Bundle, Import-Package, Export-Package declarations. You simply don't have to do it - all is done for you automatically.

• you can mix OSGi and non-OSGi dependencies - Wuff will sort it out automatically. Syntactically, in gradle scripts, OSGi and non-OSGi dependencies are no different.

• Wuff automatically generates RCP/IDE applications for you. You have to configure almost nothing. Just throw in your bundles and applications and put apply plugin: ... in build.gradle files.

Please study the Wuff tutorials: they give clear, constructive way on how to build Eclipse applications with Wuff.

My idea behind Wuff is: eliminate tedious configuration work as much as possible, hide all trivial details, let a programmer focus exclusively on application itself, not on infrastructure.

[akhikhl]

Gradle and Maven - we need to clarify couple of things:

• Gradle supports 4 types of dependencies: project, maven, ivy and file. If all your bundles and apps reside in the same project tree, you need only project dependencies. For more information see Chapter 50. Dependency Management of the official gradle documentation.
• Avoiding working with Maven at all - do you mean avoiding Maven as build-tool or avoiding Maven repositories? There is huge difference here. As for the build-tool: let's say "yes" to Gradle and say "no" to Maven. As for repositories, consider: there are thousands of libraries at jcenter and maven central - simply disregarding such a source may a) cause additional maintenance b) seriously limit ability to upgrade/downgrade/control versions.
• Gradle can use artitrary maven repositories (remote or local), but it is free from Maven complexity. No more XML! Instead - consize and powerful DSL, free choice of declarative/imperative style and many more features. I am convinced, Gradle completely eliminates necessity to use or to learn Maven.
• You'll have to learn Maven - no.
• You'll have to learn Gradle - yes.

Don't worry, future with Gradle is bright. Build scripts are very small, simple, easy to maintain - that is a clear way to reduction of costs and increasing developer's efficiency.

[carlolf]

The thing with a local Maven repository is somehow confusing me. I know that Gradle can use a local Maven respository, but I doesn't need it at all. Either it uses repositories like Maven Central by Internet connection, or it can talk to a remote company repository. Usage is only: to download needed external dependencies. Gradle then writes those Jars into it's own local cache - it never puts downloaded jars into a local Maven repository.

But this is what wuff does with those million Eclipse jars from different Eclipse versions. So it seems to me, you must have Maven installed to use wuff ? (Sure, I have. But I do not want my collegues to have Maven installed just to use a Gradle build).

[akhikhl]

"Maven installed" - no, Wuff does not use Maven at all. It uses Ant (internal packaged version, not required to be installed system-wide) for this. To reduce confusion with $HOME/.m2 folder (another colleague of us already expressed he does not want it to be filled with maven artifacts), I can move Wuff-specific local maven repository out of it into isolated location, like $HOME/.wuff/maven_repository. In this way all things will be kept in one folder, at least. Local maven repository is needed anyway, because of the design decision I took in Wuff: instead of struggling with p2 repositories Wuff mavenizes all eclipse bundles. Thus we gain transitive dependencies and uniformity of dependency representation (OSGi/non-OSGi). Please note that you can (but you don't have to) install your own eclipse bundles in any maven repository. This .m2 thing is obligatory for eclipse-specific bundles only.

[frankgerhardt]

Thanks. I'm still digesting your explanation

[akhikhl]

Wuff version 0.0.13-SNAPSHOT implements it's own maven repository in "$HOME/.wuff/m2_repository". Could you, please, that Wuff interacts with local maven repository the way you expect?

[nedtwigg]

I get that Wuff makes it completely transparent to "mavenize" an Eclipse installation, and then "OSGI-ify" maven artifacts, so that it all just works.

The problem is that I already have a large application which relies on a giant folder full of OSGI bundles (which I think is a common pattern). Until I am able to convert my whole project to the wuff style, I'd like to continue to use this folder (and it sounds like that's what Frank is trying to do as well). Unpuzzler makes it incredibly easy to "mavenize" an Eclipse-installation downloaded from a URL, but there's no easy way to "mavenize" a simple folder of OSGi bundles.

This is compounded by the way that wuff resolves OSGi bundles.

Lines 53-56 of OsgiBundleConfigurer.groovy

        else if(bundleName.toString().startsWith("org.osgi") || bundleName.toString().startsWith("org.eclipse"))
          project.dependencies.add 'compile', "${project.ext.eclipseMavenGroup}:$bundleName:+"
        else
          project.logger.warn 'Bundle name {} could not be found', bundleName

This is currently causing me a problem in getting com.ibm.icu, which is part of the eclipse installation.

btw, I love wuff!

[akhikhl]

I agree, support of flat directory as a source of OSGi plugins would certainly make Wuff more useful. Currently Wuff only understands http://, https:// URLs to zip/tar.gz files as sources. It will be not very difficult to extend Wuff with the following features:

• support of file:// URLs for sources.
• automatic recognition whether the pointed resource is an archive or unpacked directory.
• direct copy and mavenization of OSGi bundles from unpacked directory.

Please criticize.

[nedtwigg]

This would be fantastic for my use case.

[osafi]

Support for file:// URLs for sources would be great! This is the only thing holding me back from moving our projects to wuff.

[akhikhl]

@commandersafi , now "file://..." URLs are supported for sources. Praise the hero - @nedtwigg implemented it :+1: