On 16/01/2020 11:53, Rémy Maucherat wrote: > On Thu, Jan 16, 2020 at 11:58 AM Mark Thomas <ma...@apache.org > <mailto: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> > > <mailto: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> > <mailto: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 :)
Sorry, I should have been clearer. I'm in favour of keeping the single JAR via the shade plug-in- it makes it easier to work with during development / testing. We can still use the assembly to produce a final release (if we get to the point of formally releasing this). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
