Smalltalk › Frameworks & Tools › Moose

Re: Moose-dev Digest, Vol 120, Issue 10

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

1 message

Meinert Schwartau

Re: Moose-dev Digest, Vol 120, Issue 10

Hi Tudor,

Very interesting. This is the first time I heard of lombok, and I would have to look into it more closely. What I find strange is that you get to visit the method (this is where you get the unresolved method declaration from) even if the method does not exist. I am sure I do not understand something. Would you like to open an issue for this?

Actually the lombok issue resolved itself. I found out that lombok provides a delombok functionality (https://projectlombok.org/features/delombok.html):

"Delombok [...] allows you to use lombok with these tools by preprocessing your java code into java code with all of lombok's transformations already applied. [...] Delombok's standard mode of operation is that it copies an entire directory into another directory, recursively, skipping class files, and applying lombok transformations to any java source files it encounters."

So I just have analyse my delomboked source files instead of the original source files and everything will be fine.

> The cause of the next problem is that we have multiple smaller applications (e.g. backoffice and frontend) which are separate applications but share a common db. Some of these services have classes with the same class and packagename (e.g. an annotation WebController). This lead to the following error message:
> unresolved annotation type declaration - WebController - c:\data\moose\....\WebController.java - line 12
> I had to start the debugger to find the issue. I found it because AnnotationTypeDeclaration.parent.problems = "Pb(323) The type WebController is already defined"
> If the package names are different the problems disappears. Then I only get the the lombok errors. As a solution I will create unique base package names for my projecfs (which makes sense anyway).

Indeed. The only other solution for this problem is to analyze each sub-project separately. Also, perhaps I can manage to create a better log statement for this case. Would you like to open an issue on github for this?

> Note that you could the following example to you README of jdt2famix to show how to download the dependencies for gradle projects:
>
> task copyDependencies(type: Copy) {
> from configurations.compile
> from configurations.testCompile
> into 'dependencies’
> }

Thanks!

Could you also tell me how to actually add this to a gradle script and invoke it? I tried a variation of this (without configurations.testCompile), but I did not manage to run it. I am likely missing something basic here, and perhaps if you would walk me through a concrete example, I could make some progress :). For example, what steps would you use for downloading the dependencies of https://github.com/spring-projects/spring-framework ?

Cheers,
Doru

Actually I tested it with the spring gradle file and it worked. The spring build file is a little bit more complicated, because it is a multimodule project. Basically an easy way to find the right place is to define it directly after the dependencies of the java projects. I added it as follows to the configure (allprojects) section:

configure(allprojects) { project ->

group = "org.springframework"

version = qualifyVersionIfNecessary(version)

// ....

task copyDependencies(type: Copy) {

from configurations.compile

into 'dependencies'

}

If you have a simple project (not a multi module one), there won't exist such a configure method. Then you can define it directly (e.g. after the dependencies). I attached my spring gradle build file to this mail. In my company project, which is a multi module project too, I added it to a configure method which is used for all java projects (we have some non java projects too). If I added to a configure method which is called for all projects due to the non java projects I would get an error. So it seems as if you always have to change you build files and as if there doesn't exist a general solution (like there exists one for maven). But I'm not a gradle expert, so there might exist a better solution.

Best regards

Meinert

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

build.gradle (69K) Download Attachment