!! New development environment !!

[kelvin.glass]

Hi,

I am happy to announce that the Saros project switched to a new development environment:
* JDK 8 for all components
* Gradle as build tool (previous tool: "ant")
* Eclipse Neon 4.6 (previous version: 3.7)

Because of these fundamental changes it is necessary to set-up your eclipse development environment again and adjust your IntelliJ environment. See the new development environment documentation [1] for more information.
If you have any issues with the new set-up, please send me an email (or this group) or open a new issue.
If you want to change the referenced documentation, create a pull request that changes the corresponding markdown file in the "docs" directory [2] in the saros repository. See [3] for more information.

I know that even JDK 8 has "End of Free Public Updates" (for Oracle JDK) at January 2019 and Eclipse Neon is not the
last eclipse version, but the new build environment should simplify the switch to new versions.

Further improvements will follow (e.g. simplify the Travis/Docker setup in order to reduce the build time).

BR,
Kelvin

[1] - http://saros-project.github.io/saros/contribute/development-environment.html
[2] - https://github.com/saros-project/saros/tree/master/docs
[3] - http://saros-project.github.io/saros/contribute/documentation.html

[Chris Jeschke]

Hello Kelvin,
Hello Saros-Developers,

Running prepareEclipse or sarosEclipse produce the following failure:

..
Add plugin: org.w3c.dom.smil
Add plugin: org.w3c.dom.svg

> Task :mavenizeP2Repository_1 FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':mavenizeP2Repository_1'.
> Problem: failed to create task or type pom
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any <presetdef>/<macrodef> declarations have taken
place.

..

I've done all the mentioned steps in the new set Up website. Any hint on how to overcome this?

Greetings,
Christian

[kelvin.glass]

Hi,

did you try to execute the task on the current master branch HEAD or did you changed something?
Have you changed a MANIFEST.MF file?

BR,
Kelvin

[Abdullah Barhoum]

I can also confirm the exact same problem on a windows 10 machine, 64x Windows Java and Eclipse versions.

from what I can tell the problem is some missing dependency (restyled debug output for readability) :

[org.gradle.api.internal.project.ant.AntLoggingAdapter]
parsing buildfile jar:file:/C:/Users/Abdullah/.gradle/wrapper/dists/gradle-4.10.1-bin/4homep1wqei7q35i17vhsr7k8/gradle-4.10.1/lib/ant-1.9.11.jar!/org/apache/tools/ant/antlib.xml
with URI = jar:file:/C:/Users/Abdullah/.gradle/wrapper/dists/gradle-4.10.1-bin/4homep1wqei7q35i17vhsr7k8/gradle-4.10.1/lib/ant-1.9.11.jar!/org/apache/tools/ant/antlib.xml
from a zip file

[org.gradle.api.internal.project.ant.AntLoggingAdapter]
dropping E:\Uni\Abschlussarbeit\New-Saros-git\file from path as it doesn't exist

[org.gradle.api.internal.project.ant.AntLoggingAdapter]
dropping E:\C from path as it doesn't exist

[org.gradle.api.internal.project.ant.AntLoggingAdapter]
dropping E:\Users\Abdullah \.gradle\caches\modules-2\files-2.1\org.apache.maven\maven-ant-tasks\2.1.3\b09be554228d66d208e5fef5266844aacf443abc\maven-ant-tasks-2.1.3.jar
from path as it doesn't exist

[org.gradle.api.internal.project.ant.AntLoggingAdapter]
[ant:taskdef] Could not load definitions from resource org/apache/maven/artifact/ant/antlib.xml.
It could not be found.

a quick search lead me to this [1]
some questions that popped to my mind, is the new build somehow internally using the old ant build method? or are the external dependencies themselves being built using ant? the problem might by OS dependant?

regards,
Abdullah

[1] - http://forum.broadleafcommerce.org/viewtopic.php?t=176

[Tobias Bouschen]

Hello Abdullah,

it looks like you have the same problem Steffan Rossbach had. Your gradle home directory (the .gradle folder) has to be located on the same volume/partition as the repository. From your logs, it looks like gradle home is located in C:\ and the repo is located on E:\.

Please have a look at the solution/workaround mentioned at the end of https://github.com/saros-project/saros/pull/286.

Best regards,
Tobias

[Abdullah Barhoum]

Hey Tobias,

Thank you very much, that actually solved the problem.
The solution (or at least for my case):

add the following line to the beginning of the gradlew script:

set GRADLE_USER_HOME=path/to/any/folder/on/same/partition/as/Saros

I guess for a linux machine you would replace set with export

then run ./gradlew prepareEclipse

thanks again.

[Stefan Rossbach]

The command differs on Unix on depends on the current shell. Not
everyone is using Bash 8-)

[Tobias Bouschen]

Adding this to the gradlew is not a viable option as it is automatically
generated by the gradle wrapper.

But setting gradle home as an environmental variable would mean that it
would apply to all gradle applications. This could (theoretically) cause
problems with other gradle applications that have a similar issue and
are located on a third partition.
This is a somewhat contrived example, but I don't like the idea of
restricting the user to a certain gradle home directory that they would
have to use for all their gradle projects because of our setup.

Kelvin, would it be possible to use a different environmental variable,
like SAROS_GRADLE_HOME, that, if present, is set as GRADLE_USER_HOME
locally as part of our gradle scrips (or something of the same effect)?
Or is it not possible to set gradle home from inside a gradle call?

[Stefan Rossbach]

I have the same issue now.

Some *cool stuff*

14:20:30.184 [DEBUG]
[org.gradle.api.internal.project.ant.AntLoggingAdapter] dropping Z:\C
from path as it doesn't exist14:20:30.184 [DEBUG]
[org.gradle.api.internal.project.ant.AntLoggingAdapter] dropping
Z:\Users\Stefan\.gradle\caches\modules-2\files-2.1\org.apache.maven\maven-ant-tasks\2.1.3\b09be554228d66d208e5fef5266844aacf443abc\maven-ant-tasks-2.1.3.jar

from path as it doesn't exist

My user directory is on C: not on Z: and my Environment is

GRADLE_HOME=Z:\gradle

ECLIPSE_HOME=Z:\eclipse-neon

[kelvin.glass]

You have the same issue, but your setup worked before? This is strange.
Does the workaround with GRADLE_USER_HOME also work for you? It seems as if it is a common issue with windows and multiple drives.

The path in GRADLE_HOME specifies the location of the gradle distribution, but the path in GRADLE_USER_HOME specified the location of caches and compiled build scripts [1].

It is possible to add custom properties in the gradle wrapper. We could add the property "-Dgradle.user.home=$SAROS_GRADLE_USER_HOME" (if SAROS_GRADLE_USER_HOME is set) in the gradle wrapper. This allows us to set the GRADLE_USER_HOME just for saros.

Would this solution help you?

BR,
Kelvin

[1] - https://docs.gradle.org/current/dsl/org.gradle.api.invocation.Gradle.html

[Stefan Rossbach]

Ok that worked. You really have to set GRADLE_USER_HOME instead of
GRADLE_HOME.

What really concerns me is the build time and space wasted. On my
machine this took over 20 minutes and produced about 1.5 GB data. So why
must I download a full IntelliJ SDK when I only want to work with the
Eclipse stuff ?

Also the mavenizing of the P2 repo is a complete overkill. Ant4Eclipse
can resolve the whole classpath in under 10 seconds. Gradle/Maven first
transforms the whole P2 repo (which can be quite big depending on your
Eclipse installation) to POM before actually resolving the classpath.
The whole setup reminds me more like some enterprise stuff when in
reality you simply work with a really small plugin that can be compiled
in under 10 seconds.

BR

Stefan

[Tobias Bouschen]

Hello Steffan (and Kelvin),

That's weird that it is taking so long on your machine. I didn't have
any such problems when building the gradle project. Do you know whether
it was a processing power or download capacity bound issue?

You don't really "need" the other IDE version. But the gradle task
overview will complain that it is missing libraries otherwise (at least
in IntelliJ). Furthermore, if you still import the packages for the
other IDE part (this is only an option in Eclipse anyway with the
current setup as you don't import the project into IntelliJ, you just
open it) and ever open a file of other packages, your IDE will complain
as it will notice that it is missing the libraries.

Did you set the environmental variable for the local IntelliJ
installation? Otherwise, gradle will automatically download a bundled
one. This would explain the large gradle cache size as the bundle is
about 450mb and the zip is not deleted, meaning it actually takes up
about 1Gb of disk space.
When thinking about this, I noticed that you don't really have an option
not to have a local IntelliJ installation. This is not the case for
Eclipse (which does not have the automatic download feature). You could
avoid this by setting an incorrect path in the environmental variables,
but this seems like a dirty workaround.

@Kelvin Maybe it would be nice provide a setting to allow users not to
have a local IntelliJ instance. (Whether it is on or off by default is a
separate discussion).

As to why having both IDEs is set as a default requirement: If you
*really* only work on the IDE part of Saros for a certain IDE, it would
be unnecessary to include the different IDE. But as soon as you also
change the CORE, it would be better to also have access to the other IDE
parts to also automatically build and test them to ensure that the core
changes don't break something in one of the implementations. And yes, I
get that wasting disk space isn't great, but 1-1.5GB isn't *that* much
in the whole scheme of things in my opinion.

I can't speak to the mavenize stuff.

Best regards,
Tobias

[kelvin.glass]

Hi,

I did not found an option in the gradle-intellij-plugin to deactivate the automatic intellij download if no installation is provided.

Another approach is to avoid the whole intellij configuration:
Our project is organized into multiple subprojects. The gradle execution process is divided into three stages [1]:
*initialization*: determine which subprojects are in the project
*configure*: configure all subprojects
*execute*: execute tasks to be executed

It is possible to hook into the initialization stage (with modifying the settings.gradle) and add conditional subproject excludes (and exlude intellij/eclipse) if environment var XY is set.
I want to avoid this, because this would extremely increase the complexity of our build process and gradle build description. If you exclude the project in the initialization the project is totally unknown by gradle and you have to wrap all configurations in the main build.gradle in a corresponding check whether the project is included. If the current state really hurts we can think about it.

The mavenizeP2Repository task takes ~2min, but you have only to execute the task in order to initialize the eclipse setup. If you build always via gradle the task is always execute, but we could add a check whether the execution is necessary.

I know that the solution with converting the P2Repository is not perfect. I would prefer a solution that parses the MANIFEST.MF and only converts artifacts that are required (or even better the dependency can be resolved in a P2Repository).
I tried a lot of approaches to build the whole project and the current approach was the only one which also supports all IDE workflows.

BR,
Kelvin

[1] - https://docs.gradle.org/current/userguide/build_lifecycle.html