Sahoo wrote:
> Now that HK2 has stabilized, GFv3 depending on a non-SNAPSHOT version of
> HK2 is definitely the right thing.
> Since you are changing the version number, you may have already noticed
> this; in case you have not, then please note that in a few places in
> GFv3 workspace, the version is currently hard coded. It includes both
> HK2 as well as GlassFish project version. The ones that come to my mind
> are *Deployer.java, ASMainOSGi.java and felix/config.properties. The
> last one can be taken care of by maven-resource-plugin, but the ones in
> source code should use some kind of property that's read from asenv.conf
> or similar source. The version in asenv.conf can itself be populated at
> build time.
OK, I'll take a look. Thanks for the information.
>
> Thanks,
> Sahoo
>
> Kohsuke Kawaguchi wrote:
>>
>> I've started test-driving the maven release plugin toward the TP2
>> release, and the first step was to make this work for HK2.
>>
>> I now believe I made all the necessary changes for the release plugin
>> to work correctly. I changed HK2 to auto-complete OSGi version from
>> Maven version, tweaked the site generation a bit to work around a
>> Maven bug, and finally did some more nasty hacking to work around the
>> cyclic reference issue between the hk2-maven-plugin vs hk2.
>>
>>
>> For us to run the release plugin on GFv3, one of the prerequisite is
>> for all its dependencies to be non-SNAPSHOT. So I propose we switch
>> GFv3 to depend on a released version of HK2, instead of the current
>> SNAPSHOT dependency.
>>
>> There are several implications in doing this, but most notably, when
>> we make changes in HK2 that need to be picked up by GFv3, HK2 needs to
>> be released and the new version must be given. For us to test the
>> local SNAPSHOT HK2 with GFv3, we'd have to build GFv3
>>
>> But I think going forward this is the right thing to do. This should
>> also fix the temporary build breakage problem when you make a change
>> that spans across HK2 and GFv3.
>>
>> I can set up a Hudson task so that we can automate the release process.
>>
>>
>> WDYT?
>>
>> ----
>>
>> Before I lose this note, this is the exact instruction to run a
>> successful release
>>
>> # base line
>> mvn clean install
>> # this fails citing maven-hk2-plugin is not available
>> mvn -B -P release release:prepare
>> # so we build it...
>> mvn -P release-phase1 install
>> # then retry the release
>> mvn -B -P release release:prepare
>>
>> # now I need this again, just so that POM loads
>> mvn -P release-phase1 install
>> # finally a release
>> mvn -B release:perform
>>
>>
>>
>>
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com