I know there is another thread regarding similar issues, but I’m seeing (locally at least) some more repo issues with the Community modules in the 2.8.x branch (and possibly the 2.9.x branch as well). It seems that the Geofence Server community module (in 2.8.x and 2.9.x) has a wicket-dnd repository configured that points to:
The module is dependent upon version 0.4.2 of wicket-dnd, which is rather old. I’ve tried to update the dependency to use version 0.6.0 that is now in Maven Central, but alas, the code in the module is not compatible with that version of wicket-dnd.
Not sure if anyone else is seeing issues. It seems the Boundless nightly build (at least the 2.8.x build) is ok now that the java-vector-tile dependency issue has been resolved.
I’ll check again locally to make sure it’s not something messed up on my end and reply back with what I find.
Well, for me locally, since I don’t have version 0.4.2 of wicket-dnd, I still get this (on 2.8.x):
[ERROR] Failed to execute goal on project gs-geofence-server: Could not resolve dependencies for project org.geoserver.community:gs-geofence-server:jar:2.8-SNAPSHOT: Failure to find wicket-dnd:wicket-dnd:jar:0.4.2 in http://wicket-dnd.googlecode.com/svn/repo was cached in the local repository, resolution will not be reattempted until the update interval of wicket-dnd has elapsed or updates are forced → [Help 1]
Since it’s a community module, I don’t know how important it is to address it, but if someone is trying to build Geofence-server (or assembling all the community modules since it’s grouped with communityRelease) and they don’t have wicket-dnd-0.4.2 already in their local Maven repository, it is going to present some problems.
I haven’t built it, but it seems like 2.9.x will have the same issues. The master branch seems to have been updated to use the 0.7.3 version in Maven Central, so this issue should be isolated to just 2.8.x and 2.9.x.
I know there is another thread regarding similar issues, but I’m seeing (locally at least) some more repo issues with the Community modules in the 2.8.x branch (and possibly the 2.9.x branch as well). It seems that the Geofence Server community module (in 2.8.x and 2.9.x) has a wicket-dnd repository configured that points to:
The module is dependent upon version 0.4.2 of wicket-dnd, which is rather old. I’ve tried to update the dependency to use version 0.6.0 that is now in Maven Central, but alas, the code in the module is not compatible with that version of wicket-dnd.
Not sure if anyone else is seeing issues. It seems the Boundless nightly build (at least the 2.8.x build) is ok now that the java-vector-tile dependency issue has been resolved.
I’ll check again locally to make sure it’s not something messed up on my end and reply back with what I find.
So same story as the other repo, we need to pick up the dependency and deploy to repo.boundlessgeo.com.
We used to do a better on the geotools project (how to add a 3rd party jar) to ensure each third party jar has been added to a repo we control. I think we have been spoiled with third party repositories being relatively stable.
I know there is another thread regarding similar issues, but I’m seeing (locally at least) some more repo issues with the Community modules in the 2.8.x branch (and possibly the 2.9.x branch as well). It seems that the Geofence Server community module (in 2.8.x and 2.9.x) has a wicket-dnd repository configured that points to:
The module is dependent upon version 0.4.2 of wicket-dnd, which is rather old. I’ve tried to update the dependency to use version 0.6.0 that is now in Maven Central, but alas, the code in the module is not compatible with that version of wicket-dnd.
Not sure if anyone else is seeing issues. It seems the Boundless nightly build (at least the 2.8.x build) is ok now that the java-vector-tile dependency issue has been resolved.
I’ll check again locally to make sure it’s not something messed up on my end and reply back with what I find.
Erik Merkle
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
I found a copy of wicket-dnd-0.4.2 in a VM I have from when the repo was alive and copied it to my current local .m2 repository directory and, as expected, it gets me past this issue. Jody, let me know if you can’t get a hold of the artifact to deploy to the Boundless repos. I don’t believe I have access to upload it, but I can bundle it up if you can’t obtain it from the build servers that seem to have it.
So same story as the other repo, we need to pick up the dependency and deploy to repo.boundlessgeo.com.
We used to do a better on the geotools project (how to add a 3rd party jar) to ensure each third party jar has been added to a repo we control. I think we have been spoiled with third party repositories being relatively stable.
I know there is another thread regarding similar issues, but I’m seeing (locally at least) some more repo issues with the Community modules in the 2.8.x branch (and possibly the 2.9.x branch as well). It seems that the Geofence Server community module (in 2.8.x and 2.9.x) has a wicket-dnd repository configured that points to:
The module is dependent upon version 0.4.2 of wicket-dnd, which is rather old. I’ve tried to update the dependency to use version 0.6.0 that is now in Maven Central, but alas, the code in the module is not compatible with that version of wicket-dnd.
Not sure if anyone else is seeing issues. It seems the Boundless nightly build (at least the 2.8.x build) is ok now that the java-vector-tile dependency issue has been resolved.
I’ll check again locally to make sure it’s not something messed up on my end and reply back with what I find.
Erik Merkle
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
I found a copy of wicket-dnd-0.4.2 in a VM I have from when the repo was alive and copied it to my current local .m2 repository directory and, as expected, it gets me past this issue. Jody, let me know if you can’t get a hold of the artifact to deploy to the Boundless repos. I don’t believe I have access to upload it, but I can bundle it up if you can’t obtain it from the build servers that seem to have it.
So same story as the other repo, we need to pick up the dependency and deploy to repo.boundlessgeo.com.
We used to do a better on the geotools project (how to add a 3rd party jar) to ensure each third party jar has been added to a repo we control. I think we have been spoiled with third party repositories being relatively stable.
I know there is another thread regarding similar issues, but I’m seeing (locally at least) some more repo issues with the Community modules in the 2.8.x branch (and possibly the 2.9.x branch as well). It seems that the Geofence Server community module (in 2.8.x and 2.9.x) has a wicket-dnd repository configured that points to:
The module is dependent upon version 0.4.2 of wicket-dnd, which is rather old. I’ve tried to update the dependency to use version 0.6.0 that is now in Maven Central, but alas, the code in the module is not compatible with that version of wicket-dnd.
Not sure if anyone else is seeing issues. It seems the Boundless nightly build (at least the 2.8.x build) is ok now that the java-vector-tile dependency issue has been resolved.
I’ll check again locally to make sure it’s not something messed up on my end and reply back with what I find.
Erik Merkle
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
