Jerome,
Thanks for the info.
The problem is that we all seem to have to be experts to avoid the
seemingly constant snafus with the version stuff. I look forward to a
coherent scheme.
Lloyd
On Jun 19, 2008, at 10:19 AM, Jerome Dochez wrote:
> Why do you ask Kedar who has nothing to do with the decision about
> moving to versioned module ?
>
> First of all, you may not know, but we try to move several important
> pieces (eg the servlet container) out of the main glassfish build
> and for that we need versioned integration as SNAPSHOT is very
> fragile mechanism (as you have yourself experimented first hand).
>
> Also, If you want to allow external users to use our public APIs to
> write extensions for glassfish V3, there has to be stable versions
> they can compile against. The issue is not about using versioned
> module, in fact, in maven, you can just set a version range in your
> dependency and that works very well. Unfortunely, the maven bundle
> plugin we use to generate the OSGi metadata does not use the version
> range but rather the explicit version you happened to compile
> against. I am trying to find an easy way to achieve that but so far,
> it's still in progress.
>
> Eventually when we can start using version ranges in dependencies
> both in maven and in OSGi, this difficulty will be a lot less
> difficult.
>
> Jerome
>
>
> On Jun 19, 2008, at 8:11 AM, Lloyd L Chambers wrote:
>
>> 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
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> 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