On Thu, Jan 16, 2020 at 11:58 AM Mark Thomas <ma...@apache.org> wrote:
> On 16/01/2020 10:27, Rémy Maucherat wrote: > > On Thu, Jan 16, 2020 at 11:06 AM <r...@apache.org > > <mailto:r...@apache.org>> wrote: > > > > This is an automated email from the ASF dual-hosted git repository. > > > > remm pushed a commit to branch master > > in repository > > https://gitbox.apache.org/repos/asf/tomcat-jakartaee-migration.git > > > > > > The following commit(s) were added to refs/heads/master by this push: > > new 86bc4ee Shade and add a main class > > 86bc4ee is described below > > > > commit 86bc4eea2804fa5df6a5089dd4a232847b709c91 > > Author: remm <r...@apache.org <mailto:r...@apache.org>> > > AuthorDate: Thu Jan 16 11:06:25 2020 +0100 > > > > Shade and add a main class > > > > It seems easier to use to me: "java -jar overlylongjarname.jar > src > > dest". The overlylongjarname could be trimmed down a bit. > > > > > > So there's an option between this way and the assembly that was added > > (which I'm not sure how to use). > > If I understand your changes correctly, they create a single "fat" jar. > Is that right? > Yes, so it includes BCEL. > > My thinking with the assembly approach (and I don't think the two > approaches are mutually exclusive) was: > > - looking towards a formal ASF release where we would want bin and > source releases > > - to make it easier to "plug-in" additional convertors for specific file > types. > > I'm just guessing at requirements at this point. Given where things are > right now, I think a single JAR makes most sense. It is much easier to > work with during development: (build, use) rather than (build, unpack, use) > > At the moment the script just sets up the class path. I have no > objection to removing the assembly plumbing for now. We can always add > it back if we need it. > > Well, that's not a bad idea since that's how the releases are done and I didn't think about the plugin idea, I get it better now. I guess I can keep my hack pom :) Rémy
