Home » Archived » Buckminster » plugin jar dependencies
| | | | | |
| Re: plugin jar dependencies [message #524798 is a reply to message #524793] |
Fri, 02 April 2010 14:56   |
 Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
Hi Alex,
please see comments inline.
Alex schrieb:
> Hi Johannes,
>
> I have couple of questions about the snippet.
>
>
> <dependency name="org.eclipse.equinox.common" componentType="osgi.bundle"/>
> ..
> ..
> <cs:attribute name="bundle.jar" component="org.eclipse.equinox.common"/>
>
>
> Does this mean that org.eclipse.equinox.common has some dependencies,
> and later on they are listed in prerequisites element?
No, it was just an example of an extra dependency of your bundle. You
can replace org.eclipse.equinox.common with foo.jar if you want.
> From the ant script that is being called by fetch.dependency.jars, I
> don't see where it is specified where these jars are being copied from?
That's the good part: The ant script doesn't need to know. Everything
you stated as prerequisite of the 'fetch.dependency.jars action (or
however you would like to call it) will be copied by that script.
> Lastly, if I am not mistaken the fetching will happen during the build
> when all appropriate actions are called. What if I want the fetching
> happen when materialization happens in IDE into my workspace?
>
In the example I declared a public action fetch.dependency.jars and
defined a group buckminster.prebind that contains the action.
buckminster.prebind will be automatically executed when the
materialization occurs, so this is exactly the behaviour you describe.
You resolve your query/mspec, and before buckminster binds your material
to the workspace it will execute the fetch.dependency.jars action and
copy the jars you stated as prerequistes to a folder inside the bundle
(lib in the given example)
Best regards,
Johannes
|
|
|
| Re: plugin jar dependencies [message #524801 is a reply to message #524798] |
Fri, 02 April 2010 15:14 |
Alex Kravets
Messages: 561
Registered: November 2009 |
Senior Member |
|
|
Thanks Johannes,
More questions...
| Quote: |
That's the good part: The ant script doesn't need to know. Everything
you stated as prerequisite of the 'fetch.dependency.jars action (or
however you would like to call it) will be copied by that script
|
Sorry for my lack of understanding this. But where will it copy jars from? In my case the jars that are dependencies are located in a svn folder, so I need to tell script to get jars from there, no? Or, does RMAP needs to be the source of location of these jars?
thanks,
Alex
[Updated on: Fri, 02 April 2010 15:20] Report message to a moderator |
|
| | | | |
| Re: plugin jar dependencies [message #525112 is a reply to message #525059] |
Mon, 05 April 2010 18:49 |
Alex Kravets
Messages: 561
Registered: November 2009 |
Senior Member |
|
|
Thanks Johannes,
I created buckminster.cspex in common plugin that looks like this:
During materialization I see in console fetch.dependecy.jars being executed, however nothing is being copied to the common bundle, what happens was that common bundle was copied to my materialization bundle - so I did something really wrong here.
I am declaring cspex in common bundle that lists all artifacts that this bundle expects, in cspex of my materialization bundle in action fetch.dependecies.jars I list attributes to copyJars.prerequsites (http://pastebin.com/BJcuV01A). Will these attributes become exactly what's in common's cspex? Or did I miss something?
Appreciate your help,
Alex
[Updated on: Mon, 05 April 2010 18:53] Report message to a moderator |
|
| | | | | |
| Re: plugin jar dependencies [message #540420 is a reply to message #540376] |
Wed, 16 June 2010 06:21 |
|
On 06/15/2010 11:29 PM, Alex wrote:
> Hello,
>
> I was preoccupied with other projects and now came back to buckminster
> build. What I thought was working does not, so I have some more
> questions about dependencies.
>
> When I materialize my cquery the jars are being materialized into
> workspace and obviously this is wrong, I expect buckminster.prebind to
> execute but it does not. My questions are:
>
> 1.Does the common plugin, to which jars to be copied need its own cquery
> and rmap, or this only needed by my feature plugin that checks out
> common plugin?
>
No.
> 2. I created a cspex for the common plugin http://pastebin.com/X5LyeHnF,
> but is it really needed because MANIFEST.MF for the plugin contains this
> information Bundle-ClassPath directive and it seems generated CSpec
> already has this information?
>
The dependencies expressed in the bundle manifest does not need to be listed. Buckminster will handle them automatically.
> 3.Is buckminster.prebind part of the common plugin and executed before
> this bundle is materialized or should it be part of the feature plugin
> and is called before common is made into workspace?
>
The cspec extension does not contain a prebind declaration so I'm a bit confused here. What is it that you expect to get
executed?
Please note that you will not need to do anything at all in order to get a normal OSGi setup to build where all
dependencies are expressed as bundle requirements in the manifests. All of that should work out of the box. The prebind
action is normally used when you need to copy non-OSGi jars into a bundle to form a nested jar. Turning all jars into
bundles is the preferred approach.
HTH,
- thomas
|
|
|
| Re: plugin jar dependencies [message #540573 is a reply to message #540420] |
Wed, 16 June 2010 14:39 |
Alex Kravets
Messages: 561
Registered: November 2009 |
Senior Member |
|
|
Thanks Thomas,
This is what I am trying to accomplish. I have a common plugin that is used by other plugins for common functionality, this plugin has some jars that it exports packages from for use by other plugins. In the current build I just copy these jars from svn to the plugin so I was looking for a way to do this in buckminster.
From what Johannes helped me with I was trying to accomplish this but I don't think I understand the whole process correctly.
| Quote: |
The prebind action is normally used when you need to copy non-OSGi jars into a bundle to form a nested jar.
|
My jars are exactly that - non-OSGi jars such as axis.jar, commons-logging-1.1.1.jar, etc. So then prebind is what I need in my case? But if
| Quote: |
The cspec extension does not contain a prebind declaration
|
Then where and how is it used? I thought that using prebind action will be executed before bundles make it into workspace, but since this is an action it is not called during 'Resolve and Materialize' step which I thought was when jars would be copied into the common plugin.
| Quote: |
Turning all jars into bundles is the preferred approach.
|
Do you mean each jar should be a separate bundle?
May be I did explain my requirements correctly the first time, so perhaps you can suggest a solution for this?
thanks,
Alex
[Updated on: Wed, 16 June 2010 14:58] Report message to a moderator |
|
|
| Re: plugin jar dependencies [message #540596 is a reply to message #540573] |
Wed, 16 June 2010 15:40 |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
Hi Alex
please see comments inline.
> My jars are exactly that - non-OSGi jars such as axis.jar,
> commons-logging-1.1.1.jar, etc. So then prebind is what I need in my
> case? But if
> Quote:
>> The cspec extension does not contain a prebind declaration
>
>
> Then where and how is it used?
>
I think you misunderstand. A CSPEX CAN contain an action/group called
buckminster.prebind and this action will be executed before the bundle
is bound to the workspace. Your CSPEX (http://pastebin.com/X5LyeHnF)
however, does NOT contain such action/group and hence, NO action is
executed before the bundle is bound to the workspace. So far all you do
is state some extra dependencies, but what's missing is the declariation
of a prebind action that will actually do something (like copy those
dependencies into your bundle).
Specificily what's missing in your CSPEX is the rest of the example I
posted earlier:
<actions>
<!-- one public action with an ant actor to do the actual
copying -->
<cs:public name="fetch.dependency.jars" actor="ant">
<cs:actorProperties>
<cs:property key="buildFile" value="build/copyJars.xml"/>
<cs:property key="targets" value="copy"/>
</cs:actorProperties>
<cs:prerequisites alias="copyJars.prerequisites">
<!--insert all the extra jars you need here -->
<cs:attribute name="java.binaries" component="com.google.collect"/>
<cs:attribute name="bundle.jar"
component="org.eclipse.equinox.common"/>
</actions>
<groups>
<!-- the prebind group will be executed during materialization -->
<cs:private name="buckminster.prebind" >
<cs:attribute name="fetch.dependency.jars"
alias="action.requirements"/>
</cs:private>
</groups>
And the matching ant script:
<project name="BuckminstersLittleHelperAntScript" basedir=".."
default="copy">
<target name="copy">
<buckminster.copy todir="lib">
<!-- fs:copyJars.prerequisites contains all the stuff
declared in the cspex -->
<buckminster.filesetgroup value="${fs:copyJars.prerequisites}" >
</buckminster.filesetgroup>
</buckminster.copy>
</target>
</project>
> Quote:
>> Turning all jars into bundles is the preferred approach.
>
>
> Do you mean each jar should be a separate bundle?
>
Yes, that is usually the prefered approach in an OSGi environment. All
jars are OSGi bundles. There's also some repositories available that
offer OSGiified versions of many common java libs. Eclipse Orbit is one
of them:
http://download.eclipse.org/tools/orbit/downloads/drops/R201 00519200754/
Springsource offers another:
http://www.springsource.com/repository/app/
However, if for whatever reason you do not want to or cannot turn your
jars into OSGi bundles, then I'd suggest you go with the prebind action
as seen above.
Regards,
Johannes
|
|
| | |
| Re: plugin jar dependencies [message #540616 is a reply to message #540597] |
Wed, 16 June 2010 17:38 |
Alex Kravets
Messages: 561
Registered: November 2009 |
Senior Member |
|
|
Thanks Thomas, Johannes,
Sorry, meant to reply here
Ok, this is clear now. However, there is still something I don't understand. If my common plugin contains CSPEX with prebind action, where do I specify how to get these jars from svn? If I add a provider that points to location of the jars then during materialization these jars are being materialized into workspace which throws errors that jar is a file and not a directory.
If I take approach that you suggested of bundling up jar in the plugin, I get these errors during materialization:
mail.jar:jar: Using resolver Local resolver
iwaeutil.jar:jar: Using resolver Local resolver
axis2-kernel-1.4.jar:jar: Trying provider svn({0}/dependencies/trunk/{1})
iwconfigsm.jar:jar: Using resolver Local resolver
iwresource.jar:jar: Using resolver Local resolver
Errors and Warnings
E [0000] : No suitable provider for component geronimo-stax-api_1.0_spec-1.0.1.jar:jar was found in resourceMap file:/home/akravets2/dev/workspaces/pluto.build/com.iwaysoftware.integration.tools.site/site.svn.rmap
E [0000] : No suitable provider for component geronimo-stax-api_1.0_spec-1.0.1.jar:jar was found in searchPath resources
E [0000] : Rejecting provider svn({0}/dependencies/trunk/{1}): Components of type jar are not supported
E [0000] : Rejecting provider svn({0}/iIT/trunk/features/{1}): Components of type jar are not supported
E [0000] : Rejecting provider svn({0}/iIT/trunk/plugins/{1}): Components of type jar are not supported
E [0000] : Rejecting provider svn({0}/Explorer/trunk/plugins/{1}): Components of type jar are not supported
commons-codec-1.3.jar:jar: Trying provider svn({0}/dependencies/trunk/{1})
j2ee.jar:jar: Using search path resources
axis2-kernel-1.4.jar:jar: Rejecting provider svn({0}/dependencies/trunk/{1}): Components of type jar are not supported
axis2-kernel-1.4.jar:jar: Trying provider svn({0}/iIT/trunk/features/{1})
Does line "mail.jar:jar: Using resolver Local resolver" mean that jar was located correctly?
thanks,
Alex
[Updated on: Wed, 16 June 2010 19:03] Report message to a moderator |
|
|
| Re: plugin jar dependencies [message #540647 is a reply to message #540616] |
Wed, 16 June 2010 20:08 |
|
Hi Alex,
The cspex contains an additional dependency to the jar. During import, the resolver will make an attempt to resolve this
dependency which means that it will consult your rmap in order to find it. Your rmap must contain a provider that is
capable of finding and materializing the jar. I.e. this component is treated just like any other component would.
- thomas
On 06/16/2010 07:38 PM, Alex wrote:
> Thanks Thomas, Johannes,
>
> Sorry, meant to reply here
>
> Ok, this is clear now. However, there is still something I don't
> understand. If my common plugin contains CSPEX with prebind action,
> where do I specify how to get these jars from svn? If I add a provider
> that points to location of the jars then during materialization these
> jars are being materialized into workspace which throws errors.
>
> thanks,
> Alex
|
|
|
Goto Forum:
Current Time: Tue Apr 16 14:23:37 GMT 2024
Powered by FUDForum. Page generated in 0.33290 seconds |
] 
Search
Help
Register
Login
Home
