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

Include native gen with plugin #19

Open
mperry opened this issue Sep 17, 2015 · 5 comments
Open

Include native gen with plugin #19

mperry opened this issue Sep 17, 2015 · 5 comments

Comments

@mperry
Copy link
Contributor

mperry commented Sep 17, 2015

Currently needs explicit native gen library in client project

@Dierk
Copy link
Member

Dierk commented Sep 17, 2015

I'd say that an explicit dependency is not so bad

  • keeps native-gen optional with smaller download size if not needed
  • avoid version conflict in the transitive dependencies
    (Same for repl)
    This has to be weighed against convenience of course. I'm not sure what is best.

@mperry
Copy link
Contributor Author

mperry commented Sep 17, 2015

I think to help people get started it would be better to include everything by default. They can then override or exclude what they wish.

The problem is the tasks are defined in the plugin, but running the tasks will fail without the extra explicit dependencies. Not a pleasant suprise!

Version conflict is something that has to be watched of course, but as a user I want the primary library authors to sort that out. I don't want to have to do this with every library I consume.

@Dierk
Copy link
Member

Dierk commented Sep 17, 2015

Agreed.

We should explain in the docs how to opt out.

Cheers
Dierk

sent from:mobile

Am 17.09.2015 um 07:16 schrieb Mark Perry [email protected]:

I think to help people get started it would be better to include everything by default. They can then override or exclude what they wish.

The problem is the tasks are defined in the plugin, but running the tasks will fail without the extra explicit dependencies. Not a pleasant suprise!

Version conflict is something that has to be watched of course, but as a user I want the primary library authors to sort that out. I don't want to have to do this with every library I consume.


Reply to this email directly or view it on GitHub.

@mperry
Copy link
Contributor Author

mperry commented Sep 17, 2015

This is my argument for including the frege artifact with the plugin too, but I remember a few people wanted that explicit. Not sure what other language plugins do by default, I have always made explicit reference to versions for Groovy and Scala in the dependencies, so I am guessing the primary language artifact is not included with the plugin.

@Dierk
Copy link
Member

Dierk commented Sep 17, 2015

For the compiler/runtime it is often so that one wants to change/upgrade to a version different than the "bundled" one. Change should be simple and obvious.

Dierk

sent from:mobile

Am 17.09.2015 um 07:34 schrieb Mark Perry [email protected]:

This is my argument for including the frege artifact with the plugin too, but I remember a few people wanted that explicit. Not sure what other language plugins do by default, I have always made explicit reference to versions for Groovy and Scala in the dependencies, so I am guessing the primary language artifact is not included with the plugin.


Reply to this email directly or view it on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants