[Geoserver-devel] Cannot build extensions?

Andrea_Aime3 · January 18, 2009, 5:56pm

Hi,
today trying to build the extensions with -Prelease I
stumbled upon this:

Missing:
----------
1) com.esri:jsde_sdk:jar:9.2

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=com.esri -DartifactId=jsde_sdk -Dversion=9.2 -Dpackaging=jar -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=com.esri -DartifactId=jsde_sdk -Dversion=9.2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

   Path to dependency:
     1) org.geoserver.extension:arcsde:jar:1.7.2-SNAPSHOT
     2) com.esri:jsde_sdk:jar:9.2

2) com.esri:jsde_jpe_sdk:jar:9.2

Try downloading the file manually from the project website.

Then, install it using the command:
mvn install:install-file -DgroupId=com.esri -DartifactId=jsde_jpe_sdk -Dversion=9.2 -Dpackaging=jar -Dfile=/path/to/file

Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=com.esri -DartifactId=jsde_jpe_sdk -Dversion=9.2 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

   Path to dependency:
     1) org.geoserver.extension:arcsde:jar:1.7.2-SNAPSHOT
     2) com.esri:jsde_jpe_sdk:jar:9.2

----------
2 required artifacts are missing.

for artifact:
org.geoserver.extension:arcsde:jar:1.7.2-SNAPSHOT

from the specified remote repositories:
   maven-restlet (http://maven.restlet.org),
   central (http://repo1.maven.org/maven2),
   refractions (http://lists.refractions.net/m2/),
   geotools (http://maven.geotools.fr/repository/),
   mortbay (http://www.mortbay.org/maven2/release)

[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 18 seconds
[INFO] Finished at: Sun Jan 18 18:54:43 CET 2009
[INFO] Final Memory: 18M/32M
[INFO] ------------------------------------------------------------------------

Oh hum, those look like the modules one must get from the SDE install,
and that we cannot redistribute so... I guess there is a problem with
the extension dependencies?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea_Aime3 · January 18, 2009, 6:11pm

Andrea Aime ha scritto:

Hi,
today trying to build the extensions with -Prelease I
stumbled upon this...

The same happens with the sqlserver module, I've got
this failed dependency:

com.microsoft:sqljdbc:jar:1.2

I was also wondering about these modules... since they
don't contain any code, shouldn't the packaging
be just "pom" instead of "jar"?

Anyways, the reason for me trying them was to check I
did the right things when moving the ogr module into
extensions while adding it to the release.
I tried to be careful, but keep an eye,
as I have no real way to double check.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin_Deoliveira · January 18, 2009, 9:24pm

Yeah, the way I set it up was to add the dependencies on the jars that have to be downloaded manually. The rationale being that the two cases where one will want to engage the extension (1. actually using it, or 2. doing a release) will need the actual libraries.

We can set up the extensions not to include the libs but then we need to add another profile for them which makes things a bit more complicated. And we need to make sure those profiles are engaged when building a release.

Thoughts?

Andrea Aime wrote:

Andrea Aime ha scritto:

Hi,
today trying to build the extensions with -Prelease I
stumbled upon this...

The same happens with the sqlserver module, I've got
this failed dependency:

com.microsoft:sqljdbc:jar:1.2

I was also wondering about these modules... since they
don't contain any code, shouldn't the packaging
be just "pom" instead of "jar"?

Anyways, the reason for me trying them was to check I
did the right things when moving the ogr module into
extensions while adding it to the release.
I tried to be careful, but keep an eye,
as I have no real way to double check.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Andrea_Aime3 · January 19, 2009, 7:39am

Justin Deoliveira ha scritto:

Yeah, the way I set it up was to add the dependencies on the jars that have to be downloaded manually. The rationale being that the two cases where one will want to engage the extension (1. actually using it, or 2. doing a release) will need the actual libraries.

We can set up the extensions not to include the libs but then we need to add another profile for them which makes things a bit more complicated. And we need to make sure those profiles are engaged when building a release.

Thoughts?

Afaik the sde libraries we cannot redistribute, so they should
not be around when making a release, the user should add them
manually?
Moreover, the way it's set up, only one that has all those extra
packages can make a release, which does not make much sense (have
I to buy a SDE license or to download the full SQL Server
to make a release?)

Btw, the sql server one, can we redistribute? If so, it should be added to the maven repos no?

I mean, look at what happened to me, I could not even test if the
extension I was trying to add was good for the release, or not...

In fact in gt2 we have an extra profile in the oracle pom that disables
the dummy jars and enables the real ones. It seems the only practical
way to go. Generally speaking, I'm open to any process that can be
described in a wiki page, applied by everyone, without buying software
or making big (or platform dependent) downloads works for me.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin_Deoliveira · January 19, 2009, 2:11pm

FYI,

The extensions and what we actual redistribute are separate. But yeah, i guess the only option here are to add some profiles to the extensions. I will put this on the list of things todo.

-Justin

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Yeah, the way I set it up was to add the dependencies on the jars that have to be downloaded manually. The rationale being that the two cases where one will want to engage the extension (1. actually using it, or 2. doing a release) will need the actual libraries.

We can set up the extensions not to include the libs but then we need to add another profile for them which makes things a bit more complicated. And we need to make sure those profiles are engaged when building a release.

Thoughts?

Afaik the sde libraries we cannot redistribute, so they should
not be around when making a release, the user should add them
manually?
Moreover, the way it's set up, only one that has all those extra
packages can make a release, which does not make much sense (have
I to buy a SDE license or to download the full SQL Server
to make a release?)

Btw, the sql server one, can we redistribute? If so, it should be added to the maven repos no?

I mean, look at what happened to me, I could not even test if the
extension I was trying to add was good for the release, or not...

In fact in gt2 we have an extra profile in the oracle pom that disables
the dummy jars and enables the real ones. It seems the only practical
way to go. Generally speaking, I'm open to any process that can be
described in a wiki page, applied by everyone, without buying software
or making big (or platform dependent) downloads works for me.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.