Jeanfrancois Arcand wrote:
>
> Kohsuke Kawaguchi wrote:
>> Jeanfrancois Arcand wrote:
>>> Many Thanks.
>>>
>>> Actually, Pramod did the changes a couple of weeks back. This will no
>>> longer happens:
>>>
>>> http://www.nabble.com/-VOTE--Moving-Jruby-module-under-contribs-td15719590.html
>>>
>>
>> I'm not following the logic. Why does this help?
>
> No longer needs the 1.7-SNAPSHOT hardcoded value for Jruby in v3, and
> official version for other grizzly extension. Now grizzly + extension
> will have the same ${grizzly.version}, and jruby will have jruby.version
> or something like that (consider two products instead of one big
> grizzly). So the problem will no longer happens.
I guess the way I see it is that the cause of this problem is the
combination of 2 that I mentioned in my earlier e-mail. So I thought it
doesn't really matter whether the two pieces are versioned independently
or not --- what we need to fix is to stop using a macro expansion in the
<version> field.
But in any case, I see that POMs in Grizzly SVN don't use macro
expansions in the <version> field, so I suppose when grizzly/jruby
related code move to the new glassfish-scripting project, this issue
will be fixed for Grizzly/JRuby.
But the same rule needs to be enforced on other modules, too, as
currently there are many modules in the v3 that does use a macro
expansion in the <version> field, which would cause the same problem
down the road.
>>> You might want to send a note to dev just in case :-)
>>
>> OK. Should we move this discussion to dev_at_glassfish?
>
> +1
>
> --Jeanfrancois
>
>>
>>>
>>> -- Jeanfrancois
>>>
>>> Kohsuke Kawaguchi wrote:
>>>>
>>>> OK, I think I understand what's going on now.
>>>>
>>>> The grizzly-module POM (distributions/external/grizzly-http) is
>>>> written to use the property value as the build version:
>>>>
>>>>> <project>
>>>>> <parent>
>>>> ...
>>>>> <artifactId>grizzly-module</artifactId>
>>>>> <packaging>hk2-jar</packaging>
>>>>> <version>${grizzly.version}</version>
>>>>
>>>> When we install/deploy these modules, this POM is deployed as-is to
>>>> the remote repository or your local repository. So for example, if
>>>> you look at our GFv3 repository, all the POMs have this
>>>> "${grizzly.version}" in its version field. See [1] for example.
>>>>
>>>> Another fact. The gf-jruby-connector module (extras/rails) is written
>>>> to refer to 1.7-SNAPSHOT version of grizzly-module, like this:
>>>>
>>>>> <dependency>
>>>>> <groupId>org.glassfish.external</groupId>
>>>>> <artifactId>grizzly-jruby-module</artifactId>
>>>>> <version>1.7-SNAPSHOT</version>
>>>>> </dependency>
>>>>> <dependency>
>>>>> <groupId>org.glassfish.external</groupId>
>>>>> <artifactId>grizzly-module</artifactId>
>>>>> <version>1.7-SNAPSHOT</version>
>>>>> <scope>compile</scope>
>>>>> </dependency>
>>>>
>>>> This is probably just an oversight --- it should have used
>>>> ${grizzly.version}, but this by itself should have been a rather
>>>> harmless mistake, because the version resolution mechanism in Maven
>>>> favors 1.7.2 instead of 1.7-SNAPSHOT because it's newer.
>>>>
>>>>
>>>> But when these two things are combined, unexpected things happen.
>>>> While working, Maven parses a lot of POMs, and as it parses a POM and
>>>> builds in-memory model, it caches it so that multiple attempt to
>>>> parse POMs would reuse the previous parsed value.
>>>>
>>>> The key of this cache is groupId:artifactId:version, so it is capable
>>>> of parsing multiple versions of the same artifact. This is necessary,
>>>> as the way Maven works is it parses grizzly-module:1.7-SNAPSHOT as
>>>> well as 1.7.2, before determining that 1.7.2 is newer and that it
>>>> should be used.
>>>>
>>>> Indeed even before the actual distribution assembly processing
>>>> happens (to be precise, as a part of the dependency resolution for
>>>> the maven-antrun-extended-plugin mojo execution), Maven parses
>>>> grizzly-module:1.7-SNAPSHOT POM, because this is referenced in
>>>> gf-jruby-connector, which is a transitive dependency of the
>>>> distribution build.
>>>>
>>>> Now, remember the fact 1 that this POM uses "${grizzly.version}" in
>>>> the version field. The variable resolutions in loading POM is always
>>>> done by using the current values, not by using the values when the
>>>> POM was originally deployed (in fact such values are not kept
>>>> anywhere) --- so what ends up happening here is that the parsed POM
>>>> would have version 1.7.2, even though this POM was supposed to be
>>>> 1.7-SNAPSHOT.
>>>>
>>>> Maven isn't written to gracefully handle this, so the rest of the
>>>> code gets very confused about whether this is a 1.7-SNAPSHOT POM or
>>>> 1.7.2 POM.
>>>>
>>>> Some of the rest of the code decides to think that this POM is
>>>> actually for 1.7.2. In grizzly-module:1.7-SNAPSHOT, it was depending
>>>> on grizzly-http:1.7-SNAPSHOT, so this is why the distribution
>>>> assembly process ends up placing grizzly-http and not grizzly-comet.
>>>>
>>>> So in the end, the fix was very easy --- I committed rev.18322 in
>>>> extras/rails/pom.xml to use ${grizzly.version} and this fixed the
>>>> problem.
>>>>
>>>>
>>>> I think the problem like this can happen in elsewhere in the future,
>>>> too, and debugging this kind of problem is very expensive. So we need
>>>> to generalize this lesson a bit to make sure we won't have to do this
>>>> again. So here is my suggestion:
>>>>
>>>> 1. don't use property expansion in the version, groupId, and
>>>> artifactId of POMs. These are key properties and therefore their
>>>> interpretations shouldn't change depending on where these POMs are
>>>> loaded. This is a relatively simple rule to enforce.
>>>>
>>>> 2. grizzly-jruby-module and grizzly-module builds should be split out
>>>> from the main build tree and built/released separately. These two
>>>> modules appear to only depend on com.sun.grizzly, so in fact it would
>>>> be even easier to just move them into the grizzly project. In this
>>>> way, single "mvn release:prepare release:perform" would rev them
>>>> correctly.
>>>>
>>>> If we don't move them to the grizzly project, at least they should
>>>> get a top-level directory in the v3 build and shouldn't be a part of
>>>> the glassfish-parent super POM.
>>>>
>>>> Splitting builds to smaller pieces helps stabilizing our builds, too.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> [1]
>>>> http://maven.dyndns.org/glassfish/org/glassfish/external/grizzly-module/1.7.0/grizzly-module-1.7.0.pom
>>>>
>>>>
>>>> Jeanfrancois Arcand wrote:
>>>>> Thanks.
>>>>>
>>>>> Sorry for pushing, but Sridatta/Rajiv really wanted Comet sooner
>>>>> than later :-) Let me know if I can be of any help.
>>>>>
>>>>> -- Jeanfrancois
>>>>>
>>>>> Kohsuke Kawaguchi wrote:
>>>>>>
>>>>>> I'll look into this now.
>>>>>>
>>>>>> Jeanfrancois Arcand wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Jerome is already aware, but maybe Kohsuke can fix the problem
>>>>>>> :-)...sorry for pushing but Comet is suddenly important to Sun and
>>>>>>> I'm getting a lot of requests to turn it on by docs, sqe, etc.
>>>>>>> This is not complicated to integrate at the servlet level, except
>>>>>>> there is a build/packaging issue. Adding:
>>>>>>>
>>>>>>>
>>>>>>> >
>>>>>>> > Index: distributions/external/grizzly-http/pom.xml
>>>>>>> >
>>>>>>> ===================================================================
>>>>>>> > --- distributions/external/grizzly-http/pom.xml (revision 18229)
>>>>>>> > +++ distributions/external/grizzly-http/pom.xml (working copy)
>>>>>>> > @@ -73,7 +73,7 @@
>>>>>>> > <dependencies>
>>>>>>> > <dependency>
>>>>>>> > <groupId>com.sun.grizzly</groupId>
>>>>>>> > - <artifactId>grizzly-http</artifactId>
>>>>>>> > + <artifactId>grizzly-comet</artifactId>
>>>>>>> > <version>${grizzly.version}</version>
>>>>>>> > </dependency>
>>>>>>> > </dependencies>
>>>>>>>
>>>>>>> should brings up comet into v3, but the grizzly-comet-1.7.2.jar is
>>>>>>> never added to the distribution. Jerome proposed a workaround:
>>>>>>>
>>>>>>>
>>>>>>>> <dependency>
>>>>>>>> <groupId>com.sun.grizzly</groupId>
>>>>>>>> <artifactId>grizzly-comet</artifactId>
>>>>>>>> <version>${grizzly.version}</version>
>>>>>>>> </dependency>
>>>>>>>
>>>>>>> in distribution/web and distribution/glassfish for now, but I
>>>>>>> would like to make sure we all agree I should go with the hack or
>>>>>>> wait for a complete fix. So I hack or should I wait?
>>>>>>>
>>>>>>> Just let me know :-)
>>>>>>>
>>>>>>> A+
>>>>>>>
>>>>>>> -- Jeanfrancois
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com