Make WiQuery OSGi ready

[GoogleCodeExporter]

Since wicket is very popular framework among the OSGi community it would be 
great if WiQuery was OSGi ready.

For that purpose I am contributing the attached patch.

The patch uses maven bundle plugin in order to create a proper Manifest file 
and also uses maven shade plugin in order to merge rhino js inside the wiquery 
bundle (this is required since rhino js doesn't ship as an OSGi bundle).

Original issue reported on code.google.com by ioca...@gmail.com on 21 Mar 2011 at 4:18

Attachments:

• osgi-ready-patch.txt

[GoogleCodeExporter]

Many thanks for your patch.

I will put it in the trunk and in the branch for the wicket 1.5 adaptation

Best regards

Julien Roche

Original comment by roche....@gmail.com on 21 Mar 2011 at 4:34

• Changed state: Accepted
• Added labels: Milestone-Release1.2.4, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Thanks for the immediate actions.

Please note that OSGi bundles for rhino exist in public repositories 
(servicemix provides one), so embedding it inside the wiquery bundle is 
optional. 

An updated version of the patch that does not embeed rhino is attached.

Original comment by ioca...@gmail.com on 21 Mar 2011 at 9:52

Attachments:

• osgi-ready-patch.txt

[GoogleCodeExporter]

At first glance it looks like you put dependency versions in the 
maven-bundle-plugin configuration section.

Is it possible to use the properties there instead of the versions? We try to 
stay updated as much as possible but only update properties. This could mean 
that the bundle plugin uses different versions as the maven build.

Original comment by hielke.hoeve on 22 Mar 2011 at 8:37

[GoogleCodeExporter]

The ranges defined in the maven bundle plugin configuration, define the version 
ranges that our bundle will support (defines the osgi runtime dependency). If 
we narrow it to a single version, we will loose in modularity because our 
bundle will be only able to work with a single version of each of its 
dependencies.

So the answer to your question is yes we can, but do we want to (considering 
the side effects)?

What we could do in order to keep the versions in properties without loosing 
modularity would be to define in properties version ranges and have both the 
dependencies and the bundle configuration use the properties. As far as I know 
maven supports ranges in dependency version.

Let me work on it and I will upload a new patch.

Original comment by ioca...@gmail.com on 22 Mar 2011 at 8:56

[GoogleCodeExporter]

Ok, it was quite simple. I pushed the version ranges in properties so that its 
easier to maintain and the whole build is referring to the properties.

The maven build will use the latest version that was found inside the defined 
range and the OSGi imports will use the whole range.

Please have a look at the updated patch and tell me what you think. If you are 
not fond of using ranges, then I will investigate the possibility of removing 
range declarations from the bundle configuration. This would mean that in an 
OSGi environment we won't be able to constrain the version that our bundle will 
work with (can be a problem).

Original comment by ioca...@gmail.com on 22 Mar 2011 at 9:22

Attachments:

• osgi-ready-patch.txt

[GoogleCodeExporter]

I tried to apply the patch (to revision 734) but maven now gives me an error 
when deploying. I have no idea what could be wrong, the error only appears for 
slf4j-log4j12 with the range specified and not with a fixed version. so I have 
committed the patch without a range for${ slf4j.version}.

Do you have any idea to fix this?

[INFO] Failed to resolve artifact.

No versions are present in the repository for the artifact with a range 
[1.5.0,1.6.1]
  org.slf4j:slf4j-log4j12:jar:null

from the specified remote repositories:
  topicus-snapshot-repository (http://repo-onderwijs.topicus.local/artifactory/repo),
  central (http://repo1.maven.org/maven2),
  maven2-repository.dev.java.net (http://download.java.net/maven/2/),
  maven repo 1 (http://repo1.maven.org/maven2/),
  maven.atlassian.com (https://maven.atlassian.com/3rdparty)

Path to dependency:
        1) org.odlabs.wiquery:wiquery:jar:1.2-SNAPSHOT

Original comment by hielke.hoeve on 6 Apr 2011 at 2:17

[GoogleCodeExporter]

Original comment by hielke.hoeve on 6 Apr 2011 at 2:24

• Changed state: Started

[GoogleCodeExporter]

I will have a look and send you feedback later today.

Original comment by ioca...@gmail.com on 7 Apr 2011 at 6:37

[GoogleCodeExporter]

I don't have any issues building it, even with a version range on slf4j. 
However, it troubles me that the build is error prone.

If we totally remove the version ranges from the bundle plugin configuration, 
the plugin will assign version ranges it self (e.g. wicket 1.4.x and slf4j 
1.6.x). 

Let's summarize the possible solutions:
a) Have version ranges on the plugin configuration
   Pros: Give us the maximum control
   Cons: We have version related information in 2 places
b) Use maven version ranges and reuse them in the bundle configuration
   Pros: All the configuration is in one place
   Cons: The build becomes somehow unstable & we have less control
c) Do not use ranges at all in the bundle configuration
   Pros: Configuration is all in a single place
   Cons: The version ranges are autogenerated and in some case are not as wide as we would like. Example: for slf4j the version range will be 1.4.x. Ideally we could use here [1.4,1.6].

WDYT?

Original comment by ioca...@gmail.com on 7 Apr 2011 at 9:16

[GoogleCodeExporter]

It seems that using the ranges as so [1.4,1.4.16] works while [1.4.0,1.4.16] 
does not. Atleast Jenkins/Hudson seems to hate ranges like that. Local mvn 
command doesn't care.

I assume that the 2 1.4 < 1.4.0?

I want the version to be in the properties tag and not lingering around in the 
pom.xml. This has proven to be too error prone, if [1.4,1.4.16] works then 
we'll stick to that for the time being.

Original comment by hielke.hoeve on 10 May 2011 at 2:47

• Changed state: Fixed