This list of metadata regards this idea:

http://www.nabble.com/idea%3A-automatic-component-repo-td17979177.html

META-INF/wicket-components.xml:

<components>

  <component class="com.mycomponents.Slider"
             version="0.9.0"
             search-keywords="slider,ui,java">

    <description>
      This text describes the component.
    </description>

    <publisher name="my components" 
               site="http://mycomponents.com/slider" 
               email="support@mycomponents.com"/>

    <legal>
      <copyright>
          Copyright 2009-2010, John Q. Public. All Rights Reserved.
      </copyright>
      <license name="Apache 2.0">
          Full license text goes here so it travels with the JAR.
      </license>
    </legal>

    <requirements>
      <library name="wicket" version="1.3"/>
      <library name="YUI" version="4.0"/>
    </requirements>

    <resources>
      <source-code url="slider-sources.jar"/>
      <screenshots url="slider-screenshots"/>
      <demo class="com.mycomponents.demo.DemoPanel"/>
    </resources>

  </component>

  <component name="component2">

        ...

  </component>

</components>

META-INF/slider-screenshots/1.jpg
META-INF/slider-screenshots/2.jpg

OSGi:
Some of the properties above would be better represented by OSGi (if you still want to use that)

  • import-package: org.wicket;version=1.3.3 (instead of Wicket-Minimum-Version)
  • export-package: com.mycomponent.demo <- by convention, look for 'DemoApplication' : WebApplication here
  • bundle-version: 0.1.1

reference: http://www.javaworld.com/javaworld/jw-03-2008/jw-03-osgi1.html?page=2

Wicket component jars should be fully self-describing, so i think wicket meta information has to be independent of any external technology such as maven or osgi. – Jonathan Locke

  • No labels

1 Comment

  1. Antony Stubbs

    A lot of components have their 'demo' or 'example' apps/panels in separate jars - see some of the wicket-stuff packages.
    I would suggest adding an optional maven artifact identifier to locate the jar containing the demo class.

    The dependencies for the component are going to have to be managed in some automated fashion. Isn't using existing Maven or Ivy dependency resolution /systems viable? (on contrast to your comment regarding maven)