I'm putting together generic Deployment APIs both for AS7 and also AS6/EAP5. These will have 2 interfaces:
We've talked a lot about this over the years, and this time I want to be sure all invested parties have clearly communicated their use cases and requirements.
In all likelihood, the REST component will be a protocol we design which merely delegates to the underlying Java API.
I'll seed the discussion with input from Max and the Tooling house.
1) no binary dependencies to a changing runtime API such as Profile service (suggestion: provide HTTP REST style API for it or something invokable via pure JDK JMX API)
2) Provide a way to deploy via full archives (i.e. here is myapp.ear all zipped up please deploy)
3) Provide a way to update archives "incrementally" (i.e. here is /css/style.css and /WEB-INF/classes/org/whatever/BrokenCrap.class, please put it into mywar.war note when I say archives that is just the term I use for identifiying the "root" elements.
4) provide API to get error information asynch.I deploy myapp.war when the bytes have been serialized i assume that request is done and I should be able to query later on if there were any errors doing the actual deployment.is also relevant when starting up the IDE and users want to know if the archives it deployed some hours ago are still looking good...
5) query for already deployed "archives"
6) archives can also be single files (i.e. -ds.xml files)
Not currently implemented. To be formalized as a requirement.
Right now the Containers SPI of Arquillian, from which the deployment API is to be extracted, assumes a ShrinkWrap/Archive structure for all deployables.
- Should we support deployment of N deployables in a single call?
- If so, must this be atomic?
- If so, how to provide status/error reporting per deployable?