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? 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
