Kedar et al,
What I don't understand is why we want to endure the hassle of
specific versions while we are under active development; so far it has
caused only problems for me and others.
By using SNAPSHOT versions, don't we avoid these problems? Of course
at some point we need to start using specific versions, but why *now*?
Lloyd
On Jun 19, 2008, at 4:31 AM, 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
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc