Kedar,
I think the problems happens when there is also a Module Y that depends on X,
but Y is also built outside the main tree.
Case 1: Y is not aware of the version change for X, and it's not rebuilt. When Y
is added to the installation, it can't find the old (v1) version of X.
Case 2: Y is changed to accommodate version change for X, but it's own version
is not a SNAPSHOT, but rather a fixed version, and the version wasn't changed
during the build. The new copy of Y won't be picked up by the main tree build,
as by the versioning rules, it's still the same known (stable) version.
I don't know why SNAPSHOT is wrong though...
Regards,
-marina
Kedar Mhaswade wrote:
> Tim, others,
>
> Please help me understand this better.
>
> You revved Module X from Version v1-> v2.
>
> All currently checked out workspaces with all modules that depend on
> X will have an effective pom.xml that refers to "v1". If these modules
> have been built at least once with X at v1, they should continue to
> build right until there is an update. [I am hoping that we are doing
> away with SNAPSHOT versions].
>
> All new checkouts/updates of workspace would show that they depend on
> v2 for module X. This should trigger a "download" of new binaries into
> your local repository (~/.m2), assuming X(v2) has been pushed into one
> of the
> maven repositories we depend on. I assume upload of X(v2) to a remote
> maven repo happened.
>
> So, I guess I fail to understand why this failed. Of course, there are
> several things that I don't understand about our build system, but this
> looked like a straightforward use case that we are going to run into
> every now and then.
>
> Regards,
> Kedar
>
>
> Tim Quinn wrote:
>
>> 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
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>