On Tue, Aug 4, 2009 at 3:37 PM, Brian Fox<[email protected]> wrote:
> That stuff is generated from the javadoc annotations. Take a look at
> the usage page:
>
> http://maven.apache.org/plugins/maven-dependency-plugin/usage.html#Overwrite%20Rules
>
> Overwrite Rules
>
> Artifacts are copied or unpacked using the following rules:
>
>    * If the artifact doesn't exist in the destination, then copy/unpack it.
>
>      Otherwise:
>    * For copy/unpack mojo only: if artifactItem / overWrite or
> overWrite is true, then it will force an overwrite.
>    * Releases check the overWriteReleases value (default = false). If
> true, then it will force an overwrite.
>    * Snapshots check the overWriteSnapshots value (default = false).
> If true, then it will force an overwrite.
>    * If none of the above is set to true, then it defaults to the
> overWriteIfNewer value (default = true). This value, if true, causes
> the plugin to only copy if the source is newer than the destination
> (or it doesn't exist in the destination). (for unpack, this checks the
> existence of the marker file, created in the markersDirectory path. To
> avoid unexpected behavior after mvn clean, this path should normally
> be contained within the /target hierarchy.)
>
> Examples:
>
>    * Using the default settings (overWriteReleases = false,
> overWriteSnapshots = false, overWriteIfNewer = true), then a release
> or snapshot artifact will only over write the destination if the
> source is newer than the destination (or marker file if unpacking).
>    * If overWriteReleases = true, then a release artifact (ie
> foo-1.0.jar) will always overwrite.
>    * If overWriteSnapshots = true, then a snapshot artifact (ie
> foo-1.0-SNAPSHOT.jar) will always overwrite.
>    * If all of the values are false, then a copy/unpack will only
> occur if it doesn't exist in the destination (or markersDirectory if
> unpacking).
>
>
> So I again assert that for a plugin the documentation is good.
>

Bleh, I still think it's awful, it reads like it was written by a cyborg.  :-)

If I'm going to "unpack" something, I'm going to expect that
"overwrite" would allow me to control whether or not the process of
unpacking was going to be destructive to existing files or not.
That's the conundrum here, I see not other way than excludes to do
this overlay without replacing files that already exist.

The alternative would be to set staleMillis on the compiler plugin to
a value that would always force a compile, but StaleSourceScanner
doesn't support anything like staleMillis = -1.

>
> On Tue, Aug 4, 2009 at 4:28 PM, Tim O'Brien<[email protected]> wrote:
>> I love it how you are so close to the code, you think that this is
>> sufficient documentation for a plugin goal configuration property on
>> unpack:
>>
>> Property: overWriteIfNewer
>> Documentation: Overwrite if newer
>>
>> :-)
>>
>> Like I said, that leave a lot to be desired.
>>
>> On Tue, Aug 4, 2009 at 3:19 PM, Brian Fox<[email protected]> wrote:
>>> On Tue, Aug 4, 2009 at 3:30 PM, Tim O'Brien<[email protected]> wrote:
>>>> Use the excludes config property to exclude the specific files you
>>>> don't want to overwrite.
>>>>
>>>> http://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html
>>>>
>>>> The docs on that mojo leave much to be desired.
>>>>
>>>
>>> Oh come on, the dependency plugin is very well documented. It's just
>>> got a lot of options so it's non-trivial.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to