Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-dev] GSoC 13 - Starting JGrassTools framework discovery

> I love when I get to this point in GSoC: environment setup time.
> It is perhaps the most enjoyable part of the whole game! ;-)

That is also my favourite moment. It is the moment in which I usually
give directions to read docs and students do what they think they know
and usually fail :)

Let's see what is going on.

> After issuing a:
>
>    git clone https://code.google.com/p/jgrasstools/
>
> I then tryied a:
>
>    mvn eclipse:eclipse

Not what I read in the docs.

https://code.google.com/p/jgrasstools/wiki/Building


--------------------------->8---------------------------------------------
How to build

The best way to build jgrasstools is from the root folder, in ordrr to
make maven take care about the build order of the various projects.

So enter the root folder and issue the command:

mvn install

if the release is not stable, tests may fail to pass, so you might
want to build with:

mvn install -Dmaven.test.skip=true

That will build the project, execute the tests and install the
resulting jar into the local repository of the user (usually ~/.m2).

Should there be some strange error in building from the root folder,
then try by running first:

mvn install -N

and only then the build as explained before.
---------------------------8<---------------------------------------------

did you come to try all that or did you start with the eclipse thing first?

>
> and I got to an error.
> It seems that
>
> https://code.google.com/p/jgrasstools/source/browse/pom.xml
>
> is referring to the NOT-EXISTING repository:
>
> <repository>
>       <id>JBOSS</id>
>       <name>JBoss Repository</name>
>       <url>http://repository.jboss.org/maven2/</url>
>     </repository>
>
> I suspect this is the cause of the subsequent error:
>
[...]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR]   mvn <goals> -rf :jgt-jgrassgears
>
> Am I mad or just missing something silly?

Well, we'll see soon :)

> More: Andrea can you please give me EditWiki permissions so I can eventually
> improve/fix documentation of JGrassTools ?

Adding you right now, improvements are always welcome.

Andrea

>
> Thanks
>
> Marco
>
>
> 2013/7/19 andrea antonello <andrea.antonello@xxxxxxxxx>
>>
>> Hi Marco,
>> finally I get to work :)
>>
>> > Today I could finally complete the review of the R script by Cristiano
>> > Lanni: it was a bit harder than expected and it took longer than due.. ..but
>> > I can now fully appreciate how useful is having this 'blueprint' for the
>> > logic I will implement in the model.
>>
>> sure thing.
>>
>> > In a private mail exchange between Andrea and me, he suggested me, as a
>> > first step, to implement the model as a java standalone to be moved into a
>> > JGrass module in a second phase.
>> >
>> > Andrea: can you expand a bit this idea?
>>
>> Well, this was a proposal due to your requirements boudn to the
>> university, I would never do that right now :)
>> I used to do it in the past to bridge the difficulty to first
>> understand a framework and wanting first to make sure that the module
>> works properly.
>> Right now, the oms framework is so simple and non-invasive, that you
>> can go right away with it.
>>
>> > I was expecting to rely on some JGrass/GeoTools feature to load input data
>> > in memory and start working the resulting objects to implement the logic.
>> > For sure I can rewrite the R code in Java and reproduce the smart matrix
>> > computation functions available in R.. ..but this would probably lead to
>> > some badly performing tool.
>> > In short I cannot see the advantage of this intermediate step: can you
>> > explain why are you suggesting it? I am surely missing something due to my
>> > ignorance about the involved libraries!
>>
>> Well, I think the best thing is to get started on the jgrasstools
>> developers documentation:
>> https://code.google.com/p/jgrasstools/wiki/Contribute
>>
>> I am sure there will be some outdated stuff, but this will also be a
>> good moment to upgrade it. Recently we had a quite invasive move in
>> the modules, so that it would be simple to use jgrasstools in the
>> scripting engine.
>>
>> So check the docs and then feel free to ask/enhance whatever you need.
>>
>> Remember, creating a jgrasstools module is as simple as writing your
>> module without the IO part and then adding some annotations to define
>> inputs/outputs and processing.
>>
>> There are already several reader for rasters and vector data, check
>> https://code.google.com/p/jgrasstools/wiki/RasterReader
>> and surroundings.
>>
>> Cheers,
>> Andrea
>>
>>
>>
>> >
>> > Thanks!
>> >
>> > Marco
>> >
>> >
>> >
>> > _______________________________________________
>> > udig-dev mailing list
>> > udig-dev@xxxxxxxxxxxxxxxx
>> > https://locationtech.org/mailman/listinfo/udig-dev
>> >
>> _______________________________________________
>> udig-dev mailing list
>> udig-dev@xxxxxxxxxxxxxxxx
>> https://locationtech.org/mailman/listinfo/udig-dev
>
>


Back to the top