Deleting the domain will resolve the "failonerror" but it still does not
solve the problem that Sahoo raised. Creating the domain in
distributions will still use the old files and if there are any changes
in domain.xml, it will not get used.
Kedar's response suggests that any build in packager and distributions
should always start with a clean target directory.
Snjezana, do you see an issue if I add the Maven clean plugin in
packager and distributions modules so that clean gets automatically
invoked in the build.
Thanks,
Jane
Snjezana Sevo-Zenzerovic wrote:
> Correct, the original bug evaluation mentioned that we would also need
> to provide more sophisticated mechanism to make sure that we skip
> the domain creation only if all artifacts involved in domain creation
> remained the same...
>
> When all is said and done, safe thing to do in the short term would be
> to get rid of the domain directory and recreate on each run...
>
> Thanks,
>
> Snjezana
>
> Sahoo wrote:
>
>> Snjezana Sevo-Zenzerovic wrote:
>>
>>> Removing the domain directory from the staging area will work, but
>>> this also means that build will need to recreate the domain each
>>> time distributions module is built and that's something we
>>> originally wanted to avoid for incremental builds. So, other option
>>> would be to look for the presence of the default domain directory
>>> and skip the domain creation step in that scenario.
>>
>>
>> This optimisation can cause problems. Imagine a user updates the
>> workspace and now create-domain produces different set of files
>> (let's say a different domain.xml). Because of the above
>> optimization, we won't run create-domain and hence would end up using
>> old files.
>>
>> Sahoo
>>
>> ---------------------------------------------------------------------
>> 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
>