Reading the instructions
<http://maven.apache.org/guides/development/guide-testing-development-plugins.html>,
...
Technically we should mange these maven plugins with their own version
numbers as this is a bother.
I have not setup an explicit maven-plugin repository on repo.osgeo.org
although we could do so if you feel strongly about separation of concerns.
I think we could do so by providing a distinct distributionManagement
configuration for the jar-collector pom.xml.
The minimal change we could do is:
<pluginRepository>
<id>osgeo</id>
<name>OSGeo Nexus Maven Repository</name>
<url>https://repo.osgeo.org/repository/release/</url>
<snapshots><enabled>false</enabled></snapshots>
<releases><enabled>false</enabled></releases>
</pluginRepository>
<pluginRepository>
<id>osgeo-snapshot</id>
<name>OSGeo Nexus Maven Repository</name>
<url>https://repo.osgeo.org/repository/snapshot/</url>
<snapshots><enabled>true</enabled></snapshots>
<releases><enabled>false</enabled></releases>
</pluginRepository>
Previously repo.boundlessgeo.com/main included both releases and snapshots.
I don't think the above will slow us down too much as the explicit setting
of snapshots and releases should prevent both repositories being checked
for 23.0 (during a 23.0 build) and 23-SNAPSHOT (during a 23.x build).
aside: There will be no way to confirm the above approach works until we
both make the above change, and you complete the deploy step.
--
Jody Garnett
On Thu, 9 Apr 2020 at 14:44, Jody Garnett <jody.garn...@gmail.com> wrote:
> We often get this problem when starting a new branch, jar-collector is our
> custom thing in build/maven/jar-collector
> <https://github.com/geotools/geotools/tree/master/build/maven/jar-collector>
> .
>
> If I understand correctly you need to build once, fail, and then the
> collector is built locally and available for the next build.
>
> After you have deployed geotools (including this plugin) to the repository
> everyone else will be be able to use the use the plugin from the repository
> and one have this initial bootstrap failure.
>
> If you wanted to build locally the first time without error consider:
>
> 1. build root non recursively
> 2. build build non recursively
> 3. build jar-collector
> 4. return to root and build everything
>
> Of course the changes to the repository may cause you problems; I cannot
> remember if we are using repo.osgeo.org as a plugin repository or not.
>
> Checking root pom.xml
> <https://github.com/geotools/geotools/blob/master/pom.xml#L2401> shows:
>
> <pluginRepository>
> <snapshots>
> <enabled>true</enabled>
> </snapshots>
> <id>osgeo</id>
> <name>OSGeo Nexus Maven Repository</name>
> <url>https://repo.osgeo.org/repository/snapshot/</url>
> </pluginRepository>
>
> I don't think that is going to work the way we expect, it would not end up
> holding the release version of jar-collector leading to everyone having the
> build error you describe.
>
> We are going to have to think about this ...
> --
> Jody Garnett
>
>
> On Thu, 9 Apr 2020 at 08:05, Ian Turton <ijtur...@gmail.com> wrote:
>
>> So I'm seeing the following error building the new 23.0 release artifacts
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-install-plugin:2.4:install (default-install)
>> on project jar-collector: Failed to install metadata
>> org.geotools.maven/maven-metadata.xml: Error updating group repository
>> metadata: in epilog non whitespace content is not allowed but got s
>> (position: END_TAG seen ...</metadata>\ns... @11:2) -> [Help 1]
>> [ERROR]
>>
>> I can't however work out what the actual error is, Jody is this related
>> to moving the repos somehow?
>>
>> Or is it related to the warnings (that I don't recall seeing before):
>>
>> [INFO] --- maven-plugin-plugin:3.6.0:descriptor (default-descriptor) @
>> jar-collector ---
>> [INFO] Using 'UTF-8' encoding to read mojo source files.
>> [WARNING] org.geotools.maven.JarCollector#jarName:
>> [WARNING] The syntax
>> [WARNING] @parameter expression="${property}"
>> [WARNING] is deprecated, please use
>> [WARNING] @parameter property="property"
>> [WARNING] instead.
>> [WARNING] org.geotools.maven.JarCollector#outputDirectory:
>> [WARNING] The syntax
>> [WARNING] @parameter expression="${property}"
>> [WARNING] is deprecated, please use
>> [WARNING] @parameter property="property"
>> [WARNING] instead.
>> [WARNING] org.geotools.maven.JarCollector#project:
>> [WARNING] The syntax
>> [WARNING] @parameter expression="${property}"
>> [WARNING] is deprecated, please use
>> [WARNING] @parameter property="property"
>> [WARNING] instead.
>> [INFO] java-javadoc mojo extractor found 1 mojo descriptor.
>> [INFO] java-annotations mojo extractor found 0 mojo descriptor.
>>
>> Ian
>>
>> On Thu, 9 Apr 2020 at 15:01, Jody Garnett <jody.garn...@gmail.com> wrote:
>>
>>> I see, Ian please be aware that the deployment repositories have changed
>>> :)
>>>
>>> I did not get a chance to address the package issues for GeoServer
>>> mentioned on email.
>>> —
>>> Jody
>>>
>>> On Thu, Apr 9, 2020 at 2:58 AM Ian Turton <ijtur...@gmail.com> wrote:
>>>
>>>> I'm kicking off the release chain using
>>>>
>>>> GeoServer 6549c85312853ecb22b51d258423c983f22617cd
>>>> GeoWebCache - a31bcff2bd98e40c2dc5d176efe3b64b38d11429
>>>> GeoTools - 9dca3294fe372826163e25e46a3a1ae7a26a8684
>>>>
>>>> I'll keep people informed on the lists as I go, I expect to have
>>>> artifacts ready to test this afternoon for GeoTools.
>>>>
>>>> Ian
>>>> --
>>>> Ian Turton
>>>> _______________________________________________
>>>> Geowebcache-devel mailing list
>>>> geowebcache-de...@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geowebcache-devel
>>>>
>>> --
>>> --
>>> Jody Garnett
>>>
>>
>>
>> --
>> Ian Turton
>>
>
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
