Yes, we can do that. Could you please run build time comparison before
and after to find out how much of an impact on the build time this makes?
Thanks,
Snjezana
Jane Young wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>