Tidy up the Vaadin OSGi whiteboard component (#9648)
The Vaadin OSGi integration component uses Declarative Services, but it does some odd things:
* It uses the whiteboard service's own bundle context to get hold of the service instance
* It has an asymmetric get/release for the whiteboard service, which could leak instances over time
* It releases service instances that it is still actively using
This change tidies up the service lifecycle by delegating the get/release to the Service Component Runtime managing the container (specifically by injecting the service instance). Using this injection also ensures that the Vaadin whiteboard service is obtained using this component's bundle context.
This change also simplifies the code a little by using the reference as the key to track the registrations. Different references for the same service are required to be equal so there is no issue with doing this.
This change does not alter the fact that the whiteboard service's bundle context is used to register the Http Whiteboard servlet, as this may be the intended behaviour. As a result the component should be prepared for an IllegalStateException when unregistering the service whiteboard service, which may already have been unregistered by the OSGi framework if the target bundle is stopping.
Add scr component to help registering VaadinServlet configurations
This component will detect VaadinServlet configurations, add the static
resource configuration property and then register a servlet using the
HttpWhiteboard specification.
This works with pax-jetty but not pax-http-tomcat. Partly covers #7173
As vaadin-client-compiler dependens on gwt-dev, the gwt-dev dependencies
are either bundled in gwt-dev or specified as transitive dependencies
for it, so there is no need to specify them again for
vaadin-client-compiler
Change-Id: If5d35124765d8606815ec49ec318eaf096de480b
This change removes publishing related Ivy files and Ant targets etc.
Further cleanup will be done in later changesets.
Change-Id: Ibe430495e85a1b0f3538072a4823c627ddac2924
This change also cleans up some redundant POM metaadata.
Even though Maven documentation does not list it, also the organization
section is inherited to the effective POM.
pom-template.xml is still in the project for a longer description and a
repositories section until publishing to staging is cleaned up.
Change-Id: I76b71aec1d2812e2f9ef321c3b4131c613a29cb7
This patch refactors how unpacking of dependencies is handled.
It now uses a more generic configuration on top level as well as
updates the phase where the extraction happens. This way the source
plugin configuration remains small
Change-Id: I952ec84e05eac255f8b44044baceba37e07737c5