Quantcast

Good solution for non-osgi jars ?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Good solution for non-osgi jars ?

Max Rydahl Andersen
Hi,

Anyone found a good/tolerable solution for building plugins that includes .jar's that are not osgi jars ?

i.e. today we commit the jars into the plugins but would actually like to just depend on them via pom.xml or similar (Ivy?)
and put them into the plugins at build time.

/max


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Good solution for non-osgi jars ?

David Meibusch
We currently use an awkward pattern like this:

        ...
        <packaging>eclipse-plugin</packaging>

        <!--  These are ignored by Tycho -->
        <dependencies>
                <dependency>
                        <groupId>com.demo.jar</groupId>
                        <artifactId>xxx</artifactId>
                        <version>${xxx-version}</version>
                        <type>jar</type>
                        <scope>compile</scope>
                </dependency>
            ...
        </dependencies>
       
        <build>
                <plugins>
                        <plugin>
       
<groupId>org.apache.maven.plugins</groupId>
       
<artifactId>maven-dependency-plugin</artifactId>
                                <executions>
                                        <execution>
       
<id>copy-dependencies</id>
       
<phase>initialize</phase>
                                                <goals>
       
<goal>copy-dependencies</goal>
                                            </goals>
                                                <configuration>
       
<overWriteIfNewer>true</overWriteIfNewer>
       
<outputDirectory>${project.basedir}/lib</outputDirectory>
       
<markersDirectory>${project.basedir}/lib</markersDirectory>
                                                </configuration>
                                        </execution>
                                </executions>
                        </plugin>
                        <plugin>
       
<groupId>org.apache.maven.plugins</groupId>
       
<artifactId>maven-clean-plugin</artifactId>
                                <executions>
                                        <execution>
       
<id>clean-dependencies</id>
                                                <phase>clean</phase>
                                                <goals>
       
<goal>clean</goal>
                                                </goals>
                                                <configuration>
                                                        <filesets>
       
<fileset>
       
<directory>lib</directory>
       
<includes>
       
<include>**/*</include>
       
</includes>
       
</fileset>
                                                        </filesets>
                                                </configuration>
                                        </execution>
                                </executions>
                        </plugin>
                </plugins>
        </build>


If these dependencies (included jars in the bundle) have to change, the
manual steps are to:
 * change pom file
 * mvn clean initialize
 * manually update the MANIFEST.mf and build.properties files via
Eclipse PDE

Regards,
Dave


-----Original Message-----
From: Andersen Max [mailto:[hidden email]]
Sent: Tuesday, 25 May 2010 9:55 PM
To: tycho-users
Subject: [Tycho Users] Good solution for non-osgi jars ?

Hi,

Anyone found a good/tolerable solution for building plugins that
includes .jar's that are not osgi jars ?

i.e. today we commit the jars into the plugins but would actually like
to just depend on them via pom.xml or similar (Ivy?)
and put them into the plugins at build time.

/max
 
This e-mail and any attachments are confidential and may also be legally privileged and/or copyright material of Intec Telecom Systems PLC (or its affiliated companies). If you are not an intended or authorised recipient of this e-mail or have received it in error, please delete it immediately and notify the sender by e-mail. In such a case, reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Intec Telecom Systems PLC does not represent or warrant that an attachment hereto is free from computer viruses or other defects. The opinions expressed in this e-mail and any attachments may be those of the author and are not necessarily those of Intec Telecom Systems PLC.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Good solution for non-osgi jars ?

Niels B Nielsen
In reply to this post by Max Rydahl Andersen
Well, not exactly, but we use the Felix Bundle plugin to augment the manifest.
So we have a standard maven project, that depends on a non-osgi jar and provide an
osgi jar from it.

Have not tried it with Tycho yet, but I would believe it should work flawlessly.

Regards
/Niels


-----Original Message-----
From: Andersen Max [mailto:[hidden email]]
Sent: 25 May 2010 12:55
To: tycho-users
Subject: [Tycho Users] Good solution for non-osgi jars ?

Hi,

Anyone found a good/tolerable solution for building plugins that includes .jar's that are not osgi jars ?

i.e. today we commit the jars into the plugins but would actually like to just depend on them via pom.xml or similar (Ivy?)
and put them into the plugins at build time.

/max


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Good solution for non-osgi jars ?

Max Rydahl Andersen
yeah, but then the end result would be osgi jars, not non-osgi jars :)

/max

On May 26, 2010, at 08:54, Niels B Nielsen wrote:

> Well, not exactly, but we use the Felix Bundle plugin to augment the manifest.
> So we have a standard maven project, that depends on a non-osgi jar and provide an
> osgi jar from it.
>
> Have not tried it with Tycho yet, but I would believe it should work flawlessly.
>
> Regards
> /Niels
>
>
> -----Original Message-----
> From: Andersen Max [mailto:[hidden email]]
> Sent: 25 May 2010 12:55
> To: tycho-users
> Subject: [Tycho Users] Good solution for non-osgi jars ?
>
> Hi,
>
> Anyone found a good/tolerable solution for building plugins that includes .jar's that are not osgi jars ?
>
> i.e. today we commit the jars into the plugins but would actually like to just depend on them via pom.xml or similar (Ivy?)
> and put them into the plugins at build time.
>
> /max
>
>
> This email is confidential and subject to important disclaimers and
> conditions including on offers for the purchase or sale of
> securities, accuracy and completeness of information, viruses,
> confidentiality, legal privilege, and legal entity disclaimers,
> available at http://www.jpmorgan.com/pages/disclosures/email.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Good solution for non-osgi jars ?

Max Rydahl Andersen
In reply to this post by David Meibusch
well that actually looks like a really good solution IMO.

/max

On May 26, 2010, at 08:53, David Meibusch wrote:

> We currently use an awkward pattern like this:
>
> ...
> <packaging>eclipse-plugin</packaging>
>
> <!--  These are ignored by Tycho -->
> <dependencies>
> <dependency>
> <groupId>com.demo.jar</groupId>
> <artifactId>xxx</artifactId>
> <version>${xxx-version}</version>
> <type>jar</type>
> <scope>compile</scope>
> </dependency>
>            ...
> </dependencies>
>
> <build>
> <plugins>
> <plugin>
>
> <groupId>org.apache.maven.plugins</groupId>
>
> <artifactId>maven-dependency-plugin</artifactId>
> <executions>
> <execution>
>
> <id>copy-dependencies</id>
>
> <phase>initialize</phase>
> <goals>
>
> <goal>copy-dependencies</goal>
>    </goals>
> <configuration>
>
> <overWriteIfNewer>true</overWriteIfNewer>
>
> <outputDirectory>${project.basedir}/lib</outputDirectory>
>
> <markersDirectory>${project.basedir}/lib</markersDirectory>
> </configuration>
> </execution>
> </executions>
> </plugin>
> <plugin>
>
> <groupId>org.apache.maven.plugins</groupId>
>
> <artifactId>maven-clean-plugin</artifactId>
> <executions>
> <execution>
>
> <id>clean-dependencies</id>
> <phase>clean</phase>
> <goals>
>
> <goal>clean</goal>
> </goals>
> <configuration>
> <filesets>
>
> <fileset>
>
> <directory>lib</directory>
>
> <includes>
>
> <include>**/*</include>
>
> </includes>
>
> </fileset>
> </filesets>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
>
>
> If these dependencies (included jars in the bundle) have to change, the
> manual steps are to:
> * change pom file
> * mvn clean initialize
> * manually update the MANIFEST.mf and build.properties files via
> Eclipse PDE
>
> Regards,
> Dave
>
>
> -----Original Message-----
> From: Andersen Max [mailto:[hidden email]]
> Sent: Tuesday, 25 May 2010 9:55 PM
> To: tycho-users
> Subject: [Tycho Users] Good solution for non-osgi jars ?
>
> Hi,
>
> Anyone found a good/tolerable solution for building plugins that
> includes .jar's that are not osgi jars ?
>
> i.e. today we commit the jars into the plugins but would actually like
> to just depend on them via pom.xml or similar (Ivy?)
> and put them into the plugins at build time.
>
> /max
>
> This e-mail and any attachments are confidential and may also be legally privileged and/or copyright material of Intec Telecom Systems PLC (or its affiliated companies). If you are not an intended or authorised recipient of this e-mail or have received it in error, please delete it immediately and notify the sender by e-mail. In such a case, reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Intec Telecom Systems PLC does not represent or warrant that an attachment hereto is free from computer viruses or other defects. The opinions expressed in this e-mail and any attachments may be those of the author and are not necessarily those of Intec Telecom Systems PLC.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Good solution for non-osgi jars ?

Alex Blewitt
In reply to this post by Max Rydahl Andersen
An OSGi JAR *is* a non-OSGi JAR by definition, since it is a subset.  
There's nothing stopping anyone taking a JAR with OSGi manifest  
entries and then using it as a vanilla JAR in a normal Java application

Alex

Sent from my (new) iPhone

On 26 May 2010, at 08:21, Andersen Max <[hidden email]> wrote:

> yeah, but then the end result would be osgi jars, not non-osgi jars :)
>
> /max
>
> On May 26, 2010, at 08:54, Niels B Nielsen wrote:
>
>> Well, not exactly, but we use the Felix Bundle plugin to augment  
>> the manifest.
>> So we have a standard maven project, that depends on a non-osgi jar  
>> and provide an
>> osgi jar from it.
>>
>> Have not tried it with Tycho yet, but I would believe it should  
>> work flawlessly.
>>
>> Regards
>> /Niels
>>
>>
>> -----Original Message-----
>> From: Andersen Max [mailto:[hidden email]]
>> Sent: 25 May 2010 12:55
>> To: tycho-users
>> Subject: [Tycho Users] Good solution for non-osgi jars ?
>>
>> Hi,
>>
>> Anyone found a good/tolerable solution for building plugins that  
>> includes .jar's that are not osgi jars ?
>>
>> i.e. today we commit the jars into the plugins but would actually  
>> like to just depend on them via pom.xml or similar (Ivy?)
>> and put them into the plugins at build time.
>>
>> /max
>>
>>
>> This email is confidential and subject to important disclaimers and
>> conditions including on offers for the purchase or sale of
>> securities, accuracy and completeness of information, viruses,
>> confidentiality, legal privilege, and legal entity disclaimers,
>> available at http://www.jpmorgan.com/pages/disclosures/email.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Good solution for non-osgi jars ?

Toni Menzel-2
On Wed, May 26, 2010 at 10:47 AM, Alex Blewitt <[hidden email]> wrote:
> An OSGi JAR *is* a non-OSGi JAR by definition, since it is a subset. There's
> nothing stopping anyone taking a JAR with OSGi manifest entries and then
> using it as a vanilla JAR in a normal Java application

Except jars nested in the Bundle-Classpath ..

>
> Alex
>
> Sent from my (new) iPhone
>
> On 26 May 2010, at 08:21, Andersen Max <[hidden email]> wrote:
>
>> yeah, but then the end result would be osgi jars, not non-osgi jars :)
>>
>> /max
>>
>> On May 26, 2010, at 08:54, Niels B Nielsen wrote:
>>
>>> Well, not exactly, but we use the Felix Bundle plugin to augment the
>>> manifest.
>>> So we have a standard maven project, that depends on a non-osgi jar and
>>> provide an
>>> osgi jar from it.
>>>
>>> Have not tried it with Tycho yet, but I would believe it should work
>>> flawlessly.
>>>
>>> Regards
>>> /Niels
>>>
>>>
>>> -----Original Message-----
>>> From: Andersen Max [mailto:[hidden email]]
>>> Sent: 25 May 2010 12:55
>>> To: tycho-users
>>> Subject: [Tycho Users] Good solution for non-osgi jars ?
>>>
>>> Hi,
>>>
>>> Anyone found a good/tolerable solution for building plugins that includes
>>> .jar's that are not osgi jars ?
>>>
>>> i.e. today we commit the jars into the plugins but would actually like to
>>> just depend on them via pom.xml or similar (Ivy?)
>>> and put them into the plugins at build time.
>>>
>>> /max
>>>
>>>
>>> This email is confidential and subject to important disclaimers and
>>> conditions including on offers for the purchase or sale of
>>> securities, accuracy and completeness of information, viruses,
>>> confidentiality, legal privilege, and legal entity disclaimers,
>>> available at http://www.jpmorgan.com/pages/disclosures/email.
>>
>



--
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
[hidden email]
http://www.ops4j.org     - New Energy for OSS Communities - Open
Participation Software.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Good solution for non-osgi jars ?

Alex Blewitt
On 26 May 2010, at 09:55, Toni Menzel wrote:

> On Wed, May 26, 2010 at 10:47 AM, Alex Blewitt <[hidden email]> wrote:
>> An OSGi JAR *is* a non-OSGi JAR by definition, since it is a subset. There's
>> nothing stopping anyone taking a JAR with OSGi manifest entries and then
>> using it as a vanilla JAR in a normal Java application
>
> Except jars nested in the Bundle-Classpath ..

Touche :-)

Seriously, do people still use Bundle-Classpath? It hits performance on the startup since the OSGi runtime needs to extract out the JAR and put it somewhere on the filesystem to be able to load the classes from it anyway. Using anything other than . for the default  - or possibly a 'patch.jar' to be supplied by a fragment - is pretty much an OSGi anti-pattern.

Alex
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Good solution for non-osgi jars ?

Niels B Nielsen
In reply to this post by Max Rydahl Andersen
Ok, let me elaborate then.

We build our system with maven, but do not use tycho. We have grown something similar over the last few years that is quite adequate for us, and we also use osgi for other things than eclipse RCP.

We take initially a lot of non-osgi jars and give them OSGI manifest entries using Felix Bundle plugin, and deploy to our local repository. These include apache commons projects et al. If we do not upgrade versions, we do not need to build them again.
These are then used in non-osgi builds as well as osgi-builds, without any problems.
We do not rely on Bundle-Classpath etc as all our dependencies resolve inside the container.
When transitive dependencies are a problem, we fix this manually. We prefer this over having too eager dependency loading anyway.

In our client we have a lot of commons libraries and other technologies separately, so we can reference them normally from the manifest, i.e. having non-osgi jars is not something we think about at all.

If I were you I would probably give it a try too. Just add an extra project which bundles, and then you can reference that project from your tycho build. I wouldn't think of this as any extra overhead. Mainly because the OSGI resolver will not work clean with a non-osgi jar, and embedding jars (the other example of copying dependencies is quite good for this) is not a viable solution anyway if you use any shareable library.

Regards

/Niels

-----Original Message-----
From: Andersen Max [mailto:[hidden email]]
Sent: 26 May 2010 08:22
To: [hidden email]
Subject: Re: [Tycho Users] Good solution for non-osgi jars ?

yeah, but then the end result would be osgi jars, not non-osgi jars :)

/max

On May 26, 2010, at 08:54, Niels B Nielsen wrote:

> Well, not exactly, but we use the Felix Bundle plugin to augment the manifest.
> So we have a standard maven project, that depends on a non-osgi jar and provide an
> osgi jar from it.
>
> Have not tried it with Tycho yet, but I would believe it should work flawlessly.
>
> Regards
> /Niels
>
>
> -----Original Message-----
> From: Andersen Max [mailto:[hidden email]]
> Sent: 25 May 2010 12:55
> To: tycho-users
> Subject: [Tycho Users] Good solution for non-osgi jars ?
>
> Hi,
>
> Anyone found a good/tolerable solution for building plugins that includes .jar's that are not osgi jars ?
>
> i.e. today we commit the jars into the plugins but would actually like to just depend on them via pom.xml or similar (Ivy?)
> and put them into the plugins at build time.
>
> /max
>

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Good solution for non-osgi jars ?

Max Rydahl Andersen
In reply to this post by Alex Blewitt
I agree its an antipattern but I also believe exposing these embedded jars in the same osgi installation
would not work well in case of overlapping jars/versions.

I know that we should fix this eventually by using the same dependencies, but want to take one step at the time right now
since to use same dependencies I would need to add custom entries to the manifest.mf and find a different name space
to use to not collide with other OSS plugins that might be using them.

/max

On May 26, 2010, at 11:08, Alex Blewitt wrote:

> On 26 May 2010, at 09:55, Toni Menzel wrote:
>
>> On Wed, May 26, 2010 at 10:47 AM, Alex Blewitt <[hidden email]> wrote:
>>> An OSGi JAR *is* a non-OSGi JAR by definition, since it is a subset. There's
>>> nothing stopping anyone taking a JAR with OSGi manifest entries and then
>>> using it as a vanilla JAR in a normal Java application
>>
>> Except jars nested in the Bundle-Classpath ..
>
> Touche :-)
>
> Seriously, do people still use Bundle-Classpath? It hits performance on the startup since the OSGi runtime needs to extract out the JAR and put it somewhere on the filesystem to be able to load the classes from it anyway. Using anything other than . for the default  - or possibly a 'patch.jar' to be supplied by a fragment - is pretty much an OSGi anti-pattern.
>
> Alex

Loading...