Martin Desruisseaux wrote:
>> Frankly it's a bit embarrassing explaining to users that it is normal
>> for the GeoTools build system to explode the first few times you run
>> it... thoughts?
>
> Right. But do we want to copy the "maven-plugin-xxx" dependencies (and
> their transitive dependenci
Cory Horner a écrit :
> The refractions version numbers are correct: 2.2-RC4 is an actual
> release and 2.2-RC4-SNAPSHOT is a snapshot. The 2.2.x snapshots do not
> have timestamps because of the pom settings:
>
>
>
>false
>refractions
>Refractions Research Repository
>dav:ht
Martin Desruisseaux ha scritto:
> Andrea Aime a écrit :
>> I can confirm some files are put by hand on that repo because we
>> needed them in a project
>> we are carrying on along with Refractions, and that were not built
>> with maven.
>
> There is no problem with that, and this is not specific
Cory Horner wrote:
> Martin Desruisseaux wrote:
>
> The current repository (with the exception of _share and old-m2-repo)
> has been rebuilt from scratch using the mvn deploy:deploy-file command
> (via
> http://svn.geotools.org/geotools/trunk/scripts/deploy_dependencies.sh).
> Only a handful o
Martin Desruisseaux wrote:
>I have setup maven.geotools.fr as a mirror of list.refractions.net/m2 using
>"rsync" and it seems to
>work. However I have done that in a test directory for now, not yet the actual
>maven.geotools.fr/repository directory, because of some issues I have:
>
>* The curre
Andrea Aime a écrit :
> I can confirm some files are put by hand on that repo because we needed them
> in a project
> we are carrying on along with Refractions, and that were not built with maven.
There is no problem with that, and this is not specific to the other projects.
We had to put a lot
Martin Desruisseaux ha scritto:
>
> * The current repository on http://list.refractions.net/m2 seems to be a copy
> of some local
>repository, instead of files put there by "mvn deploy". I'm not sure that
> this is what we
>should do. For example local repository uses gt2-xxx-SNAPSHOT f
I have setup maven.geotools.fr as a mirror of list.refractions.net/m2 using
"rsync" and it seems to
work. However I have done that in a test directory for now, not yet the actual
maven.geotools.fr/repository directory, because of some issues I have:
* The current repository on http://list.refra
Richard Gould a écrit :
hmm - that worked. I get the correct output.
Cool!
Checking the built zip file, it looks like only the javadocs for
gt/module were built. For the release, don't we want all javadocs to be
in the javadoc zip file?
This is very easy to adjust. We just need to agree on
hmm - that worked. I get the correct output.
I then executed mvn org.geotools:gt2-javadoc:javadoc on trunk and it
worked!
(note that I have not done an svn update since I last tried, so it seems
mvn install in gt/maven/javadoc did the trick, which is odd, because I
tried that before!)
Tryi
Richard Gould a écrit :
Do you get the same exception when running "mvn install" and "mvn
org.geotools:gt2-javadoc:javadoc" both on trunk?
Yeah, I get the same exception on trunk. Am I missing something?
Not necessarly, it is likely to be a bug in the custom plugin.
When invoking "mvn insta
Yeah, I get the same exception on trunk. Am I missing something?
Martin Desruisseaux wrote:
Martin Desruisseaux a écrit :
Do you get the same exception when running "mvn install" and "mvn
org.geotools:gt2-javadoc:javadoc" both on trunk?
(I mean on a fresh trunk checkout - I fixed a bug simi
Added a wiki page about generating javadoc:
http://docs.codehaus.org/display/GEOT/2.6+Generating+Javadoc
I noticed that a new maven-javadoc-plugin were released recently. I tried it, but some Maven plugins
still have a number of bugs. For example:
* upgrating maven-resources-plugin from 2.1
Martin Desruisseaux a écrit :
Do you get the same exception when running "mvn install" and "mvn
org.geotools:gt2-javadoc:javadoc" both on trunk?
(I mean on a fresh trunk checkout - I fixed a bug similar to this one a few
days ago).
Martin.
---
Richard Gould a écrit :
I tried a mvn install on trunk and then went to my 2.2-RC3 checkout.
Executing mvn org.geotools:gt2-javadoc:javadoc yields this exception:
[...snip...]
[DEBUG] Trace java.lang.NullPointerException
Cory Horner a écrit :
At a glance it looked like:
r19455 | rgould | 2006-05-11 13:57:44 -0700 (Thu, 11 May 2006) | 1 line
[maven-release-plugin] prepare release 2.2-RC3
was responsible... but upon review, perhaps it was:
r19418 | rgould | 2006-05-09 17:18:21 -0700 (Tue, 09 May 2006) | 1 line
[
Martin Desruisseaux wrote:
Richard Gould a écrit :
The poms are changed whenever maven release:prepare is executed, but
they do not change the formatting. I had a look at the diff for the
commit and it just changes version numbers.
Just checked. It is true that the poms are almost the same
Martin Desruisseaux wrote:
Richard Gould a écrit :
The poms are changed whenever maven release:prepare is executed, but
they do not change the formatting. I had a look at the diff for the
commit and it just changes version numbers.
Just checked. It is true that the poms are almost the same be
Richard Gould a écrit :
The poms are changed whenever maven release:prepare is executed, but
they do not change the formatting. I had a look at the diff for the
commit and it just changes version numbers.
Just checked. It is true that the poms are almost the same between 2.2.x and 2.2-RC3. But
Martin Desruisseaux wrote:
>> Does this create the javadoc zip archive that was normally generated
>> during maven 1 createRelease?
>
>
> Not yet, but it would be trivial to add (the plugin just execute an Ant
> build file, so it is just a matter of adding a few lines to this Ant
> build file - I
Jody Garnett a écrit :
If possible I would like to get a smaller javadoc of "module/*" - aka
just the geotools library.
Commited on trunk as of revision 19516. Our custom javadoc plugin now have 2
goals:
mvn org.geotools:gt2-javadoc:javadoc - Generates javadoc for the whole
Geotools
Just realized that
mvn org.geotools:gt2-javadoc:javadoc
is implemented on trunk only. I tried to port it on 2.2 branch one or two week ago, but failed
because the pom.xml files in the 2.2 branch are very different from the pom.xml files in the trunk.
Was the pom.xml files overwritten by Ma
Martin Desruisseaux wrote:
I have documented the progress I have made so far:
http://docs.codehaus.org/display/GEOT/How+to+cut+a+release
It's right at the top in the big blue box.
Can we delete the Maven 1 specific instructions in the above page, and
reformat the blue box as top-level text? I
Richard Gould wrote:
I have successfully built all of the release jars for 2.2-RC3 and they
have been uploaded to maven.geotools.fr.
Wow congrats! Thanks Richard this is very good news.
The only part that remains is to have the release process construct
the standard binary/src/javadoc archives
Richard Gould a écrit :
For now, cross-module javadoc is generated using the following custom
plugin:
mvn org.geotools:gt2-javadoc:javadoc
Does this create the javadoc zip archive that was normally generated
during maven 1 createRelease?
Not yet, but it would be trivial to add (the plug
Martin Desruisseaux wrote:
Richard Gould a écrit :
I have successfully built all of the release jars for 2.2-RC3 and they
have been uploaded to maven.geotools.fr. The only part that remains is
to have the release process construct the standard binary/src/javadoc
archives that we use for norma
Hmm actually I think I just succesfully built a source release. I was
just confused and trying something silly before. I have go to now, so I
will check it out tomorrow, and try your javadoc plug-in. Then
everything should be done.
Cheers
Richard
Richard Gould wrote:
Martin Desruisseaux wr
I have successfully built all of the release jars for 2.2-RC3 and they
have been uploaded to maven.geotools.fr. The only part that remains is
to have the release process construct the standard binary/src/javadoc
archives that we use for normal distribution.
I have documented the progress I hav
Richard Gould a écrit :
I have successfully built all of the release jars for 2.2-RC3 and they
have been uploaded to maven.geotools.fr. The only part that remains is
to have the release process construct the standard binary/src/javadoc
archives that we use for normal distribution.
Thanks a lo
Jody Garnett wrote:
Richard Gould wrote:
The only part that remains is to have the release process construct
the standard binary/src/javadoc archives that we use for normal
distribution.
Um what does it build right now? Is it something we can distribute?
It builds a bunch of jars and upload
Martin Desruisseaux wrote:
I made a review of the state of our test coverage in Maven 2 build. In
short, Maven 2 now performs as well as Maven 1 regarding the test
coverage, except for the WMS module. Result below:
I agree - thanks for the update Martin. Hopefully we can try a Maven 2
release l
Martin (and others),
Thanks a lot for this update, its given me a lot of info.
dave
---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Do
I made a review of the state of our test coverage in Maven 2 build. In short, Maven 2 now performs
as well as Maven 1 regarding the test coverage, except for the WMS module. Result below:
Modules excluded from the build because of compilation error:
geometryless
oraclespatial
Modules
How to add a third-party JAR
I'm in the process of getting an account and a password that I can give to
developpers
for write access on http://maven.geotools.fr/repository. Will email back
when I will
have this account.
Test skipped
This is partially our test suite fault, not Mav
Martin Desruisseaux wrote:
How to add a third-party JAR
I'm in the process of getting an account and a password that I can
give to developpers
for write access on http://maven.geotools.fr/repository. Will email
back when I will
have this account.
Test skipped
This is partially
Actually the jdom dependency should appears straight at the root.
The Maven2 repository on ibiblio is somewhat confusing: some
packages appears in an org or javax super-package, and some do not.
In which module do you encounter the missing dependency?
In "GeoTIFF grid coverage exchange module
So we have been working with maven 2 a bit and have found the next level
of madness - Xerces. Xerces has always been a mess since Sun included
some of it in your JRE (see the fun GeoServer has). Added to the this
the interesting behaviour of the surefire test plugin and we are kind of
stuck.
Actually the jdom dependency should appears straight at the root.
The Maven2 repository on ibiblio is somewhat confusing: some
packages appears in an org or javax super-package, and some do not.
In which module do you encounter the missing dependency?
In "GeoTIFF grid coverage exchange module
Thank you Cory! [INFO] [INFO] Reactor Summary:[INFO] [INFO] Geotools 2 SUCCESS [
1.297s][INFO] Maven plugins f
Martin Desruisseaux wrote:
Cory Horner a écrit :
Jesse pointed out that one can run groups of tests in eclipse, so
i've finally got the test failures in a readable format for main
(although debugging doesn't quite work right). I've noticed one
thing: most failures have something to do with
Cory Horner a écrit :
Jesse pointed out that one can run groups of tests in eclipse, so i've
finally got the test failures in a readable format for main (although
debugging doesn't quite work right). I've noticed one thing: most
failures have something to do with FeatureType and $Proxy0. Does
Help!
Jesse pointed out that one can run groups of tests in eclipse, so i've
finally got the test failures in a readable format for main (although
debugging doesn't quite work right). I've noticed one thing: most
failures have something to do with FeatureType and $Proxy0. Does anyone
know w
Oliver Loe wrote:
Seems like we have found the problem. Main was dependent on
referencing and referencing was depedent on api, but main was also
dependent on api, so there were 2 dependencies on api, causing a
conflict. Seems like you cannot have more than one dependency over
multiple depende
HiSeems like we have found the problem. Main was dependent on referencing and referencing was depedent on api, but main was also dependent on api, so there were 2 dependencies on api, causing a conflict. Seems like you cannot have more than one dependency over multiple dependencies.
OliverOn 4/6/06
Hi Clint, I am trying to commit some of your hacking today and am
running into some consistency issues - as an example the vpf module
failes when I do a:
- 2.2.x/> mvn clean
- 2.2.x/> mvn install
The problem seems to be an inability to find - JTS. Please see the logs
at the end of this message
The vs issue gave me an idea. Should we move all our current
declarations outside Geotools (maybe in OSGEO?) in some parent pom.xml file
inherited by Geotools, Geoserver, uDig and maybe some other open source projects? It would make sure
that Geotools and Geoserver were built and tested with
Jody Garnett a écrit :
referencing do not need JTS (or it did in 2.2, but is doesn't need it anymore
in 2.3).
Okay we can update that then
Actually this dependency was already removed from referencing/pom.xml in trunk (but should still
presents in 2.2 branch, since this branch still need it)
Thanks Martin you have helped us here again.. Thanks again
Martin Desruisseaux wrote:
Jody Garnett a écrit :
We found that the number of dependencies in the "parent" pom actually
masks the real needs of a module like referencing.
According to the current sturcture, referencing needs batik for
Martin Desruisseaux wrote:
Jody Garnett a écrit :
We found that the number of dependencies in the "parent" pom actually
masks the real needs of a module like referencing.
According to the current sturcture, referencing needs batik for example.
Referencing do not need batik, I'm pretty sure of t
Jody Garnett a écrit :
We found that the number of dependencies in the "parent" pom actually
masks the real needs of a module like referencing.
According to the current sturcture, referencing needs batik for example.
Referencing do not need batik, I'm pretty sure of that. Unless I didn't notic
So after some heroics (thanks Refractions, Dave and everyone) we are
finally back in the game.
We found that the number of dependencies in the "parent" pom actually
masks the real needs of a module like referencing.
According to the current sturcture, referencing needs batik for example.
I un
BLUE4A4E a écrit :
Why in plugin/pom.xml geometryless is commented out?
It has compile-time error at this time, mostly about "Cannot find symbol" in LiteralExpression and
AttributeType.
I saw your answer about:
org.opengis
geoapi-legacy
0.2
We can eliminate
Hi
Can someone please tell me how I can get my geotools projects into eclipse using maven 2?
I try mvn eclipseAll in my gt folder, but I get the following build failed message:
---
[ERROR] BUILD FAILURE
[INFO] -
---
[INFO]
Jesse Eichar a écrit :
I had to comment out the dependency on tools.jar because those classes are
part of classes.jar on Macs.
I while try to get this dependency automatically excluded on Mac OS X then.
Thank for the report.
The next problem was I didn't have ImageIO
installed, I had though
I'm making a great deal of progress on the Mac OS X with maven 2. I
had to comment out the dependency on tools.jar because those classes
are part of classes.jar on Macs. The next problem was I didn't have
ImageIO installed, I had thought that we had a build that would be
automatically dow
Thank you Martin for having updated pom.xml files.
If you can, create plugin/Grib1/pom.xml and insert an entry for this
plugin in plugin/pom.xml:
Grib1
Why in plugin/pom.xml geometryless is commented out?
I saw your answer about:
org.opengis
geoapi-legacy
0.2
Martin Desruisseaux wrote:
I'm not if it is the cause for the build failure. I noticed that the
2.2 branch upgrated to JTS 1.7, but this dependency was not yet
uploaded to the maven repository. It is now done. "mvn install" seems
to work like usual on the 2.2 branch for me...
Sorry I should not
I'm not if it is the cause for the build failure. I noticed that the 2.2 branch upgrated to JTS 1.7,
but this dependency was not yet uploaded to the maven repository. It is now done. "mvn install"
seems to work like usual on the 2.2 branch for me...
Martin.
---
I looked at the log posted by Jesse and see no obvious reason why Surefire fails to setup itself. I
don't think that the problem come from Geotools, since Surefire fails before to run a single test.
The symptoms seem very similar to http://jira.codehaus.org/browse/MSUREFIRE-43 but the cause is
o
The pom.xml files in the coverage branch seem somewhat broken. We should not have a mix of
2.2-SNAPSHOT and 2.3-SNAPSHOT; it should be all one or all the other. I replaced all remaining
occurence of 2.2-SNAPSHOT by 2.3-SNAPSHOT (as you suggested) on the coverage branch as of SVN
revision 18674.
I just tried maven 2.0 and I'm getting the same errors as with maven
2.0.2. No log is being created just the console output.
Jesse
On 14-Mar-06, at 11:18 AM, Cory Horner wrote:
Here's a potential workaround:
svn checkout http://svn.apache.org/repos/asf/maven/plugins/trunk/
maven-surefire-
Here's a potential workaround:
svn checkout
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-surefire-plugin
maven-surefire-plugin
cd maven-surefire-plugin
mvn install
adjust geotools pom.xml (2.1.2 --> 2.1.3-SNAPSHOT):
org.apache.maven.plugins
maven-surefire-plugin
2.1.3-SNA
Jesse Eichar wrote:
Unfortunately the reports wasn't generated, it seemed to fail before
it was created or while it was being generated. Cory just searched
the maven bug tracker and there was a report about something
similar. So it could be a bug with the version we're using. (Cory
is
Unfortunately the reports wasn't generated, it seemed to fail before
it was created or while it was being generated. Cory just searched
the maven bug tracker and there was a report about something
similar. So it could be a bug with the version we're using. (Cory
is having the same probl
I've deleted these folders: C:\Documents and
settings\\.m2
C:\AllData\CoveragesI've done a fresh checkout
from: http://svn.geotools.org/geotools/branches/coverages_branch/trunkto: C:\AllData\Coverages
TortoiseSVN told me:
Updated:
C:\AllData\Coverages Completed: At rev
Jesse Eichar a écrit :
Just tried it on trunk. I updated and ran:
mvn clean:clean
mvn install.
Just tried myself the same on trunk, revision 18624, and it worked for me...
Which Maven version do you have? Could you also send me the content of
C:\java\gttrunk\module\referencing\target/suref
Just tried it on trunk. I updated and ran:
mvn clean:clean
mvn install.
Thats all and I got the same problem again.
So I deleted the .m2 directory and did the clean install again.
(Still all on trunk) It still didn't work. I've attached the output
of running it with the -e option. I co
Maybe I should start with building trunk. I'll do that.
Jesse
On 13-Mar-06, at 4:02 PM, Martin Desruisseaux wrote:
BLUE4A4E a écrit :
[INFO] Failed to resolve artifact.
GroupId: org.geotools
ArtifactId: gt2-plugin
Version: 2.2-SNAPSHOT
It sound like the kind of error I would expect if "mvn
BLUE4A4E a écrit :
[INFO] Failed to resolve artifact.
GroupId: org.geotools
ArtifactId: gt2-plugin
Version: 2.2-SNAPSHOT
It sound like the kind of error I would expect if "mvn install" has not be run at least once from
the topermost directory (the one that contains "module", "plugin", "ext" an
Yes it was the gt directory. I was trying to do a full build.
Jesse
On 13-Mar-06, at 3:27 PM, Martin Desruisseaux wrote:
Jesse Eichar a écrit :
I'm getting the exact same errors (The errors I mean are the
compilation errors where unit and so on are not found) on 2.2.x
branch. I did a fre
Jesse Eichar a écrit :
I'm getting the exact same errors (The errors I mean are the compilation
errors where unit and so on are not found) on 2.2.x branch. I did a
fresh checkout of 2.2 and ran mvn clean:clean then mvn install.
Did you run from trunk/gt/ directory directly (i.e. the directory
I'm getting the exact same errors (The errors I mean are the
compilation errors where unit and so on are not found) on 2.2.x
branch. I did a fresh checkout of 2.2 and ran mvn clean:clean then
mvn install.
Jesse
On 13-Mar-06, at 2:12 PM, BLUE4A4E wrote:
I've done an SVN update from:
http
I've done an SVN update from:
http://svn.geotools.org/geotools/branches/coverages_branch/trunk
Trying a Maven 2 build I've got these errors:
[INFO] Scanning for projects...
[INFO]
[ERROR] FATAL ERROR
[INFO]
I've just updated from this SVN url:
http://svn.geotools.org/geotools/branches/coverages_branch/trunk
Someone has moved all previous contents to a trunk subdirectory why?
Trying to do a Maven full build I get these errors:
[INFO] Scanning for projects...[INFO]
[INFO] Scanning for projects...
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] Error building POM (may not be this project's POM).
Project ID: unk
All modules and plugins now have a pom.xml file. Only ext/* remains to
be done.
I had to disable JUnit tests in some modules. Reasons for tests failure
include (but are not limited to):
- Different ClassLoader behavior in Maven 2
(see http://jira.codehaus.org/browse/MNG-441)
- Root dire
76 matches
Mail list logo
