It seems to me that the builds of the distributions should account for
dependencies in a way that all the required versions of the required
modules are bundled into the distribution. If it so happens that
modules in the same distribution depend on different versions of the
some other module X, it seems reasonable - at least at this stage - to
package all required versions of module X into the distribution. At
least that way the software will run.
Ideally the packaging would detect such cases and log a warning during
the build, with an easy way to have that treated as a build error
(instead of a warning) during later builds or builds targeted for
milestones when we definitely would not want multiple versions of X in
the distribution.
- Tim
Lloyd L Chambers wrote:
> Why don't we just use X.0-SNAPSHOT until such time as the api settles
> down? Why are we trying to use fixed version numbers so early?
>
>
> On Jun 18, 2008, at 9:25 PM, Tim Quinn wrote:
>
>> Everyone,
>>
>> I am afraid I have been responsible for two recent bumps in the
>> glassfish-api version.
>>
>> I did not know it would have this sort of impact because of the
>> dependency of the GUI on the gf-api. Now I do know. My apologies.
>>
>> We definitely need to figure out how to make range dependencies work
>> for us.
>>
>>
>> - Tim
>>
>> Anissa Lam wrote:
>>>
>>> Marina,
>>> Yes, you are right. This glassfish-api version is changing too
>>> fast :) Everytime it changes, even though the bits will be fine,
>>> the ResolveError still comes up. Thats why we need to be able to
>>> specify a range of version as dependency. An email has sent out
>>> to the alias and Sahoo, (as attached) on how to specify it, we
>>> haven't heard anything and are still struggling on this.
>>>
>>> Anissa.
>>>
>>> Marina Vatkina wrote:
>>>> It's on the latest and greatest ws.
>>>>
>>>> console-plugin-service can't start because it depends on the old
>>>> (i.e. rev4) glassfish-api version.
>>>>
>>>> Regards,
>>>> -marina
>>>>
>>>> Anissa Lam wrote:
>>>>>
>>>>> This has been fixed couple days ago. Please make sure you update
>>>>> distributions/web/pom.xml and rebuilt.
>>>>> Anissa.
>>>>>
>>>>> Marina Vatkina wrote:
>>>>>
>>>>>> Admin GUI has its own dependency: ResolveError: Failed to start
>>>>>> org.glassfish.admingui:console-plugin-service:1.0
>>>>>>
>>>>>> :(
>>>>>> -marina
>>>>>>
>>>>>> Marina Vatkina wrote:
>>>>>>
>>>>>>> Bhakti,
>>>>>>>
>>>>>>> You probably needed to change the jruby-connector's version as
>>>>>>> well. I needed to remove that part of my local repository to get
>>>>>>> the changed version.
>>>>>>>
>>>>>>> thanks,
>>>>>>> -marina
>>>>>>>
>>>>>>> Bhakti Mehta wrote:
>>>>>>>
>>>>>>>> Marina,
>>>>>>>> QL are failing too.We are having a discussion about this .
>>>>>>>> Vivek has rebuilt the jruby-connector with rev5 version and
>>>>>>>> pushed it out on maven , see if the latest would help. I
>>>>>>>> agree this is definitely an issue if we need to republish
>>>>>>>> artifacts if the version of some other component changes
>>>>>>>> Regards,
>>>>>>>> Bhakti
>>>>>>>>
>>>>>>>> Marina Vatkina wrote:
>>>>>>>>
>>>>>>>>> On the latest ws (don't know how QL passes), I'm getting the
>>>>>>>>> following error
>>>>>>>>> that is caused by the wrong version ref for the
>>>>>>>>> org.glassfish.common.glassfish-api (either from deploying a
>>>>>>>>> web+JPA example or trying to access admingui):
>>>>>>>>>
>>>>>>>>> ResolveError: Failed to start
>>>>>>>>> org.glassfish.scripting:gf-jruby-connector:1.0
>>>>>>>>> ...
>>>>>>>>> Caused by: org.osgi.framework.BundleException: Unresolved
>>>>>>>>> package in bundle 8: module;
>>>>>>>>> (&(bundle-symbolic-name=org.glassfish.common.glassfish-api)(bundle-version>=10.0.0.rev4)(bundle-version<=10.0.0.rev4))
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The rev is already rev5 for the glassfish-api :(
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>> -marina
>>>>>>>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Subject:
>>> Version ranges in pom.xml?
>>> From:
>>> Ken Paulsen <Ken.Paulsen_at_Sun.COM>
>>> Date:
>>> Mon, 16 Jun 2008 15:09:19 -0700
>>> To:
>>> dev_at_glassfish.dev.java.net
>>>
>>> To:
>>> dev_at_glassfish.dev.java.net
>>>
>>>
>>>
>>> How can I specify version ranges in the pom.xml file such that those
>>> ranges persist to the MANIFEST.MF? I tried:
>>>
>>> <project xmlns="http://maven.apache.org/POM/4.0.0"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>> http://maven.apache.org/maven-v4_0_0.xsd">
>>> <modelVersion>4.0.0</modelVersion>
>>> <parent>
>>> <groupId>org.glassfish</groupId>
>>> <artifactId>glassfish-parent</artifactId>
>>> <version>10.0-SNAPSHOT</version>
>>> </parent>
>>> <groupId>org.glassfish.admingui</groupId>
>>> <artifactId>console-plugin-service</artifactId>
>>> <packaging>hk2-jar</packaging>
>>> <name>Admin GUI Integration</name>
>>> <description>Glassfish V3 Admin Console Integration</description>
>>>
>>> <dependencies>
>>> <dependency>
>>> <groupId>com.sun.enterprise</groupId>
>>> <artifactId>hk2</artifactId>
>>> <version>${hk2.version}</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>org.glassfish.common</groupId>
>>> <artifactId>glassfish-api</artifactId>
>>> * <version>[10.0*,11.0)</version>*
>>> </dependency>
>>> </dependencies>
>>>
>>> ...
>>>
>>> Which gave me this in the MANIFEST.MF file:
>>>
>>> bundle-version="[10.0.0.tp-2-SNAPSHOT, 10.0.0.tp-2-SNAPSHOT]
>>>
>>> This was the first of several available versions available, however,
>>> I don't want 1 version, I want "[10.0,11.0)". How can I do this?
>>>
>>> Ken
>>> ------------------------------------------------------------------------
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>
> ---
> Lloyd L Chambers
> lloyd.chambers_at_sun.com <mailto:lloyd.chambers_at_sun.com>
> Sun Microsystems, Inc
>
>
>