Gradle project must not be treated as maven

[pranasblk]

$ draft version
&version.Version{SemVer:"v0.14.1", GitCommit:"fdc29c553a45600ac4f795f3485d4bb9a80c7862", GitTreeState:"clean"}

$ ls gradle*
gradle.properties	gradlew			gradlew.bat

gradle:
wrapper

$ ls *.gradle
build.gradle	settings.gradle

But got Docker file:

$ cat Dockerfile
FROM maven:3.5-jdk-8 as BUILD

COPY . /usr/src/app
RUN mvn --batch-mode -f /usr/src/app/pom.xml clean package

FROM openjdk:8-jdk
ENV PORT 4567
EXPOSE 4567
COPY --from=BUILD /usr/src/app/target /opt/target
WORKDIR /opt/target

CMD ["/bin/bash", "-c", "find -type f -name '*.jar' | xargs java -jar"]

[birdayz]

as far as i can see, language detection is performed by github.com/linguist.
I would say we need a more sophisticated detection strategy - the language is only one factor in finding the right pack.
In this case, it's two steps: Detect Java -> Detect Build tool
There might even be more steps, e.g. if you can can derive specifics of the run-time during the create.. (in java's case it's very simple, it always uses the "java" command).
I saw in the commitlog that previously the packs did some detection, which was entirely replaced by linguist.
Just thinking out loud - maybe a combination of both could be necessary - if multiple packs are eligible, the final decision could be deferred to the packs.

[pranasblk]

Gradle may be used for different languages in the same project e.g. one may create project with Java/Groovy or Java/Kotlin files java can be missing e.g. pure Kotlin project. Have you considered just detect Build System -> Set of languages (if required)? It sounds like language -> build system flow is not flexible enough to detect typical JVM projects.

…

On Wed, May 2, 2018 at 11:02 AM, Johannes Brüderl ***@***.***> wrote: as far as i can see, language detection is performed by github.com/linguist. I would say we need a more sophisticated detection strategy - the language is only one factor in finding the right pack. In this case, it's two steps: Detect Java -> Detect Build tool There might even be more steps, e.g. if you can can derive specifics of the run-time during the create.. (in java's case it's very simple, it always uses the "java" command). I saw in the commitlog that previously the packs did some detection, which was entirely replaced by linguist. Just thinking out loud - maybe a combination of both could be necessary - if multiple packs are eligible, the final decision could be deferred to the packs. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/Azure/draft/issues/713#issuecomment-385834681>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADicckKtmcRmKAZ7Jym_xcgLTcYoh2SHks5tuQW2gaJpZM4TsLPr> .

[bacongobbler]

Right; linguist cannot determine the difference between a generic Python 2 app, a generic Python 3 app and a Django app, for example. Once we tackle #593 I think we can start to tackle these more "advanced" use cases for packs and address long-standing issues like #308 as well.

I'm a little concerned that this might end up being something a bit more than we can chew on our own, however, since we'll basically need to maintain a custom naive bayesian classifier that supports every language and every framework. Github stopped at the "detect a programming language" problem which works well for their use case, but it also prevented them from having to re-train their classifier every time a new framework release came out, which as you can imagine is on a significantly quicker release cycle than a programming language.

[birdayz]

I agree that this does not have to be a problem that draft has to solves, at least not directly.

I see two options:

1. Do it in draft directly (that's how it's being done currently, we use a library but it's still done inside draft itself)
2. Delegate back to the detection to build packs; draft merely "orchestrates" the registration of build packs and calling them, as well as interpreting the result (e.g. what happens if multiple packs say they can "do the job").

I prefer 2) due to the reasons you mentioned: it's nothing we should do! Thinking forward, a naive implementation could just ask all registered build packs if they can "do it", and they answer with a probability or something like that. draft could just use the answer with the highest probablity.

I'm sure theres many more options but these come to my mind right now.

[pranasblk]

User's input would be valuable where autodeection fails e.g. select JDK version when runtime must be Java 8, but old code is Java 7

…

On Thu., 3 May 2018, 8:53 pm Johannes Brüderl, ***@***.***> wrote: I agree that this does not have to be a problem that draft has to solves, at least not directly. I see two options: 1. Do it in draft directly (that's how it's being done currently, we use a library but it's still done inside draft itself) 2. Delegate back the detection to build packs; draft merely "orchestrates" the registration of build packs and calling them, as well as interpreting the result (e.g. what happens if multiple packs say they can "do the job"). I prefer 2) due to the reasons you mentioned: it's nothing we should do! Thinking forward, a naive implementation could just ask all registered build packs if they can "do it", and they answer with a probability or something like that. draft could just use the answer with the highest probablity. I'm sure theres many more options but these come to my mind right now. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/Azure/draft/issues/713#issuecomment-386257434>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADicclUGQi-iYVq1eQjWtzdcsIhzKD_9ks5tuuG_gaJpZM4TsLPr> .