<div dir="ltr">Hi,<div><br></div><div>Then I am reverting the commit. Avoiding pulling a JRE or even JDK is good practice. There's a problem though that it is sometimes not easy to say a jar should belong to libgradle-core-java or libgradle-plugins-java by judging the file name.</div><div><br></div><div>Cheers,</div><div>Kai-Chung Yan</div></div><br><div class="gmail_quote"><div dir="ltr">Miguel Landaeta <<a href="mailto:nomadium@debian.org">nomadium@debian.org</a>> 於 2015年7月9日週四 下午10:27寫道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jul 09, 2015 at 11:35:41AM +0200, Markus Koschany wrote:<br>
><br>
> I don't mind merging the packages if there are no objections from Miguel<br>
> or Hans. Though I also think that it makes sense to separate the<br>
> libraries from the gradle package because the latter depends on a JRE<br>
> and recommends a JDK which is undesired if an external application is<br>
> only interested in some jar files from libgradle-plugins-java for<br>
> example. If you want to simplify things, I suggest to merge<br>
> libgradle-core-java and libgradle-plugins-java into libgradle-java<br>
> instead but that would require another run through NEW. On the other<br>
> hand perhaps we should wait with restructuring gradle until we have more<br>
> data what applications really expect from gradle in the future.<br>
<br>
Hi,<br>
<br>
In general, I'll not be in favor of unneccesary package merging,<br>
or in this case, of having only one gradle package.<br>
<br>
When I began packaging gradle years ago, I did a mistake and I created<br>
binary packages for gradle and for every plugin. This was not correct and<br>
caused too much work with every new release (having to pass through<br>
NEW, complex dependencies rules, etc).<br>
<br>
IMO, having libgradle-core-java and libgradle-plugins-java is the<br>
right compromise for current gradle usage in Debian.<br>
<br>
If for example, I'm developing something in kotlin, jruby, groovy or<br>
even in java and I need to use a feature availaible in gradle core<br>
library, I don't want to pull a list of unrelated plugins (and their<br>
dependencies) plus a full gradle installation, I'd only want gradle<br>
core jar.<br>
<br>
I think the current package arrangement should not be modified until<br>
we have more data. Currently, gradle doesn't have that many reverse<br>
dependencies so I suspect is very early to do this kind of changes.<br>
<br>
I'd focus on keeping up to date with upstream since that's usually a<br>
challenge by itself.<br>
<br>
Cheers,<br>
<br>
--<br>
Miguel Landaeta, nomadium at <a href="http://debian.org" rel="noreferrer" target="_blank">debian.org</a><br>
secure email with PGP 0x6E608B637D8967E9 available at <a href="http://miguel.cc/key" rel="noreferrer" target="_blank">http://miguel.cc/key</a>.<br>
"Faith means not wanting to know what is true." -- Nietzsche<br>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr"><p dir="ltr">殷啟聰 | Kai-Chung Yan<br>
一生只向真理與妻子低頭<br>
Full-time student of Providence University of Taiwan<br>
LinkedIn: <<a href="https://linkedin.com/in/seamlik">https://linkedin.com/in/seamlik</a>><br>
Blog: <<a href="http://seamlik.logdown.com">seamlik.logdown.com</a>></p>
</div>