Jane Young wrote:
> Not sure if you ever got a response from Jerome or Sahoo:
>
> Here are some comments:
>
> ===================================================================
> --- appclient/client/appclient-scripts/pom.xml (revision
> 26111) +++
> appclient/client/appclient-scripts/pom.xml (working
> copy) @@ -2,13 +2,21 @@
>
>
>
> <modelVersion>4.0.0</modelVersion>
>
>
> <parent>
>
> -
> <groupId>org.glassfish</groupId>
>
> -
> <artifactId>appclient</artifactId>
>
> +
> <groupId>org.glassfish.appclient</groupId>
>
> +
> <artifactId>client</artifactId>
>
>
> <version>3.0-SNAPSHOT</version>
>
>
> </parent>
>
> -
>
> + <!-- we seem to need to explicitly specify the groupId for a dist
> frag ??? --> +
> <groupId>org.glassfish.appclient.client</groupId>
>
>
> <artifactId>appclient-scripts</artifactId>
>
> <name>GlassFish appclient scripts</name>
> The reason why you need to explicitly specify the groupId is because
> it is different than the parent's groupId. Is there a reason why this
> artifact has a different groupId from the parent?
I had thought that the default group ID was the parent-group-Id +
parent-artifact-Id. It's easy enough to change.
>
> Parent groupId: org.glassfish.appclient
> Child groupId: org.glassfish.appclient.client
>
> Looks like the appclient-scripts module copies the files from
> acc-standalone to a structured glassfish distribution directory and
> then zipping-it so it's in the project's target directory and
> publishing to maven repo. Distrubtion pulls this module and extracts
> appclient to the glassfish bin location. The steps looks cumbersome.
>
> This is temporary? What is the right solution? If you've worked
> this out with Snjezana, the changes are fine with me.
> Thanks,
Yes, it's horribly cumbersome and messy. It is definitely a very
short-term stop-gap measure.
The plan I would like to follow is for us to create a new distribution
that will contain the app client bits (and the various jars it depends
on). Once that is in place then I can remove the entire creation of the
gf-client-bundle.zip file which is basically a poor-man's distribution
anyway. Snjezana had written some temporary logic to process the
gf-client-bundle.zip file individually; this set of changes cleans that
out at the (temporary) cost of the complexity within the appclient
module you've noticed.
Thanks for the review and the feedback.
> Jane
>
>
>
>
>
> Tim Quinn wrote:
>> Hi.
>>
>> I sent this yesterday. Could someone please review and respond today
>> (Tuesday U.S.)?
>>
>> Thanks.
>>
>> - Tim
>>
>> Tim Quinn wrote:
>>> Hi.
>>>
>>> The attached zip file contains diffs and raw files for several
>>> changes to poms and changes to the glassfish distribution.
>>>
>>> I have created a new appclient-all module which depends on all the
>>> various appclient modules. As a favor to me Snjezana had hacked the
>>> glassfish distribution pom and build.xml files to gather the
>>> individual appclient-related modules. This new module does that (as
>>> in webtier-all, for example) so the attached changes also remove the
>>> special handling in the distributions/glassfish files.
>>>
>>> Mostly unrelated - but also involving pom changes - I have also
>>> modified various of the appclient/... poms to clean up some of the
>>> naming and improve the packaging of the gf-client-bundle.zip file
>>> (until we create a client distribution).
>>>
>>> Snjezana, could you please take a look at the
>>> distributions/glassfish changes particularly to make sure I've done
>>> the right thing.
>>>
>>> Jerome or Sahoo, could one of you please look at the pom changes?
>>>
>>> Many thanks.
>>>
>>> - Tim
>>>
>>>
>>
>