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

Reply via email to