Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support custom scalaTag (e.g _2.11, _2.12, _2.13) instead of _? #80

Closed
borissmidt opened this issue Jun 13, 2020 · 1 comment · Fixed by #94
Closed

Support custom scalaTag (e.g _2.11, _2.12, _2.13) instead of _? #80

borissmidt opened this issue Jun 13, 2020 · 1 comment · Fixed by #94
Milestone

Comments

@borissmidt
Copy link
Contributor

Hey I might have a hacky solution for a complex problem this plugin doesn't compose well with the play plugin.

So we have a project like

root
-- app (play plugin)
-- api (needs crossbuilding) 

But because i need to tag the dependencies as _? then the app sub project tells me hey i cannot resolve this dependency with _?. Because your plugin doesn't apply to the old play plugin.

So i simple solution would be to set the archive.appendixPattern to _2.11 and be done with it. But then the plugin complains that it cannot resolve the _2.11 for a 2.12 build.

So currently i resolved it by doing:

compile "com.company:commons-lib_2.11:${commonGrpcVersion}"
crossBuildV211CompileOnly "com.company:commons-lib_2.11:${commonGrpcVersion}"
 crossBuildV212CompileOnly "com.company:commons-lib_2.12:${commonGrpcVersion}"

But if this 'feature' was supported the i could just change a project to a cross compiled lib by just applying the plugin and no need to switch dependencies to the dependency with _? notation.

I tried play-framework but that disabled the tests for some weird reason (and it is out of the scope of this ticket)

@borissmidt
Copy link
Contributor Author

:api
[{
    "name": "V211",
    "scalaVersion": "2.11",
    "archive": {
        "appendixPattern": "_2.11",
        "appendix": "_2.11"
    },
    "scalaVersionInsights": {
        "baseVersion": "2.11",
        "compilerVersion": "2.11.12",
        "artifactInlinedVersion": "2.11",
        "strippedArtifactInlinedVersion": "211",
        "underscoredBaseVersion": "2_11",
        "underscoredCompilerVersion": "2_11_12",
        "underscoredArtifactInlinedVersion": "2_11"
    }
},
{
    "name": "V212",
    "scalaVersion": "2.12",
    "archive": {
        "appendixPattern": "_2.11",
        "appendix": "_2.11"
    },
    "scalaVersionInsights": {
        "baseVersion": "2.12",
        "compilerVersion": "2.12.11",
        "artifactInlinedVersion": "2.12",
        "strippedArtifactInlinedVersion": "212",
        "underscoredBaseVersion": "2_12",
        "underscoredCompilerVersion": "2_12_11",
        "underscoredArtifactInlinedVersion": "2_12"
    }
}]

aha if i put appendixPattern to _2.11 then it changes the pattern for 2.12 also to _2.11.

borissmidt added a commit to borissmidt/gradle-crossbuild-scala that referenced this issue Jun 13, 2020
Fix Archive appendix problem
Found undocumented weird behavior
borissmidt added a commit to borissmidt/gradle-crossbuild-scala that referenced this issue Jun 15, 2020
Added a setting to allow for a 'scalaTag' so you can set something else than _? to mark scala dependencies.
borissmidt added a commit to borissmidt/gradle-crossbuild-scala that referenced this issue Jun 15, 2020
removed some prints.
@borissmidt borissmidt changed the title Support to set archive.appendixPattern to ScalaLangVersion (_2.11) Support to custom scalaTag instead of _? Jun 16, 2020
borissmidt added a commit to borissmidt/gradle-crossbuild-scala that referenced this issue Jun 16, 2020
removed some prints.
borissmidt added a commit to borissmidt/gradle-crossbuild-scala that referenced this issue Jun 16, 2020
removed some prints.
borissmidt added a commit to borissmidt/gradle-crossbuild-scala that referenced this issue Jun 17, 2020
moved the tag to extension
@prokod prokod added this to the v0.11.0 milestone Jun 18, 2020
@prokod prokod mentioned this issue Jun 25, 2020
@prokod prokod changed the title Support to custom scalaTag instead of _? Support mixing cross built modules with plain modules in a multi module projects (Support to custom scalaTag instead of _?) Jun 25, 2020
prokod added a commit that referenced this issue Jun 25, 2020
@prokod prokod mentioned this issue Jun 25, 2020
@prokod prokod changed the title Support mixing cross built modules with plain modules in a multi module projects (Support to custom scalaTag instead of _?) Support custom scalaTag (e.g _2.11, _2.12, _2.13) instead of _? Jul 27, 2020
@prokod prokod modified the milestones: v0.11.0, v0.12.0 Jul 30, 2020
This was referenced Aug 13, 2020
prokod added a commit that referenced this issue Aug 23, 2020
@prokod prokod mentioned this issue Aug 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants