#32 maven cleanup

[matyesz]

No description provided.

[sbondorf]

I would prefer not to pull dependencies' milestones or release candidates. I wonder if we can achieve this with the mojohaus/versions-maven-plugin; see for example mojohaus/versions#157

[sbondorf]

I think our groupId is in reverse order. We have
<groupId>discodnc.cs.uni-kl.de</groupId>
but I should be
<groupId>de.uni_kl.cs.discodnc</groupId>
like our our package prefix (note the underscore).

[matyesz]

Added the requested changes. For exclude rules, I would like to keep it sepearetd by groupid because ie. rtc is also a beta:). Seems redundant but cleaner.

[sbondorf]

Separation by groupid is ok, makes it more readable.
The rtc will probably never get out of its beta phase :-)

I see the rules are used in <profile> <id>eclipse</id>. Can we use the rules in <dependencyManagement> and remove the version variables in <properties>?

Also, we use two different versions of build-helper-maven-plugin; 1.7 in <profile> <id>ext</id> and 1.9.1 in <profile> <id>tests</id>. Can we add a version variable to <properties>?
The README mentions version 1.7 and needs an update in case we go for 1.9.1 or any newer version.

[sbondorf]

Regarding

(we should decide whether to use the core and extension as dep. from the maven repo or add it as classes to the jar)

I think we should, in the future, get the NumBackend and the core from the Maven repo when they are available there.

[matyesz]

All versions must be in sync. For project dependencies we can use dep management, in eclipse profile most of the dependencies are for the surefire plugin. In that case dep management does not work but fortunatelly these never get connected to the build just used for unit testing. Will have another look. Whatever is in maven we should use that instead of system deps.

[matyesz]

Moved versions to variables and synced them. Let's leave with fix versions at the moment, although [) works in command line it fails within eclipse.
For junit5: only milestone versions exist that work fine at the moment (JUnit5 seems to be something very big mess, I cannot except that they force users to use milestone versions)

[sbondorf]

I converted the DiscoSNC to a Maven project and faced a problem with [) and Eclipse, too. Adding any additional dependency caused Eclipse to complain about all dependencies.

Did we decide on

(we should decide whether to use the core and extension as dep. from the maven repo or add it as classes to the jar)

and can thus remove this comment from the pom.xml?

I also noticed that the mpa profile was renamed to ext and exp to experiments. Before merging the pull request, we need to update README.md with all changes (Please also update the <maven.plugin.versions.version> given in the Eclipse error info there). Changing the Maven profiles included in my Eclipse configuration and running a Maven clean, I got these Warnings. Are they of concern?

[WARNING] 
[WARNING] Some problems were encountered while building the effective model for de.uni_kl.cs.discodnc:DiscoDNC:jar:2.5.0-SNAPSHOT
[WARNING] 'dependencies.dependency.systemPath' for de.uni_kl.cs.discodnc:NumBackend:jar should not point at files within the project directory, ${project.basedir}/lib/NumBackend-1.0.jar will be unresolvable by dependent projects @ line 73, column 16
[WARNING] 'dependencyManagement.dependencies.dependency.systemPath' for ch.ethz.rtc.kernel:rtc:jar should not point at files within the project directory, ${project.basedir}/lib/rtc.jar will be unresolvable by dependent projects @ line 318, column 17
[WARNING] 'profiles.profile[tests].dependencies.dependency.systemPath' for ch.ethz.rtc.kernel:rtc:jar should not point at files within the project directory, ${project.basedir}/lib/rtc.jar will be unresolvable by dependent projects @ line 175, column 18
[WARNING] 'profiles.profile[ext].dependencies.dependency.systemPath' for ch.ethz.rtc.kernel:rtc:jar should not point at files within the project directory, ${project.basedir}/lib/rtc.jar will be unresolvable by dependent projects @ line 218, column 18
[WARNING] 'profiles.profile[eclipse].dependencies.dependency.systemPath' for ch.ethz.rtc.kernel:rtc:jar should not point at files within the project directory, ${project.basedir}/lib/rtc.jar will be unresolvable by dependent projects @ line 290, column 18
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING] 

Maven install with the new pom.xml looks good.
Tests run without errors (executed by Maven as well as in Eclipse). But what is the reason for requiring the JUnit5 Milestone? I am only aware of needing at least 1.2.0 and 5.2.0 due to the use of MethodSource and if I remember correctly there were no JUnit-related changes in the tests? In fact, I tried these latest stable versions and tests still run fine on my machine.

[INFO] Results:
[INFO] 
[INFO] Tests run: 53760, Failures: 0, Errors: 0, Skipped: 0

[matyesz]

Will do the corrections tomorrow:

• rollback the naming to original version by pschon (just wanted to check whether I can use the profile id as variable for jar name)
• do not know what to do with [) dependencies as it works from command line but eclipse just not able to recognize it
• will go away from junit milestones
• remove decided comments

Concerned warning: I also recognized them, I think they are to protect external system dependencies from being commited as part of the lib library within the project (this was usual in old (ant) times. If we move them out of the source folder all developers have to edit the pom file during the import.

[matyesz]

Hope it will work. If branches go to far away, mergeing is nearly impossible:). Just changed the pom.xml.

[sbondorf]

Successfully rebased too v2.5 and merged the changes. See commit 91e5f6e