yes, it should be added.

here's some argumentation for this:

if the job thread servlet and the other servlets are all separate war files as you propose, it's going to be a nightmare for people to get that set up right.

i want to provide to our users the simplest and best possible evaluation platform out of the box. developers must be able to get up and running quickly.

that is where i think your proposed solutions differ from my position. from a design standpoint, i think you're right. but has turned out not easy for people to start managing a bunch of deployment files.

the more artifacts they encounter, the more difficult it gets.

the suite distribution should be as integrated as possible. then the docs should explain how the different pieces can be decoupled and configured.

1) a sar is not portable and 2) it doesn't provide an easy evaluation distribution.

i want 2 distributions out of the box:

1) a war distribution with configurations for standard java and everything inside this one single jar

2) a .ear enterprise application with configurations for enterprise java usage and everything inside this one single .ear file.


there are *lots* of ways on how we could split up things that might potentially be deployed separate. it creates a combinatorial explosion of possibilities, which is not possible to document or maintain. at least not with the resources we have now.

that is why my focus is first on creating the 2 nice integrated easy-evaluatable packages as mentioned above.

once we have those and within the constraints sketched above, we should think of how we can make it easier for people to undeploy certain parts or tweak those deployment packages.

it will never be as easy as just deleting a file. it will always involve updating configuration files (which means unzip/update/re-zip). but that is due to the fact that the java standards are all based on zipping configuration files in the packages. anything else becomes less portable.