You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2012/08/15 11:26:34 UTC
Starting sis-metadata
Hello all
Thanks Chris for all your comments. I got the acknowledgement from the
Apache secretary that the got my ICLA, so its look like that we can
process. I attached to this email I first patch proposal creating an
initially empty "sis-metadata" directory. The rest of this email is
about question related to this patch, the most important one probably
being the GeoAPI dependency:
Missing "svn:ignore" (minor)
------------------------
A quick note: isn't the "svn:ignore" property missing on the "sis-app"
directory? This property is presents in other directories (except
"sis-data").
Modules grouping (may be deferred)
-------------------------------
The attached patch creates the directory at the project root, because
all other SIS modules do that way. I'm not completely sure that it is
worth to group modules by categories; I did that way in Geotk mostly
because GeoTools did that way, and I originally wanted to stay close to
GeoTools developers habits. Whatever we should do that for Apache SIS or
not is an open question.
Parent pom.xml
-------------
I noticed that SIS put the parent pom.xml in a separated module, namely
"sis-parent". I wonder why the parent is not the root pom.xml? This
would reduce by 1 the amount of "modules". But surely I'm missing a reason?
<sis.version> property (minor)
--------------------------
I wonder also why declaring a "<sis.version>" property in the sis-parent
pom.xml given that the standard "$project.version" property fits the
purpose?
GeoAPI dependency
-----------------
This patch modifies the sis-parent/pom.xml file for adding dependency
management items for GeoAPI 3.0.0 (for now, maybe we would depend on a
milestone later). In order to ensure version consistency, this patch
does not only manage GeoAPI dependencies. It also _import_ the GeoAPI
<dependencyManagement> section, using the Maven <scope>import</scope>
functionality [1]. This has the effect of importing three dependency
management items:
* Units of measurement (currently JSR-275, but this project is dead...)
* vecmath
* JUnit
Because of the later, this import replaces the original JUnit
management. This has the side-effect of increasing the JUnit version
from 3.8.1 to 4.8.2. The reason why we import a JUnit dependency is
because we inherit that dependency from the geoapi-conformance module.
geoapi-conformance "extends" JUnit by providing validators and test
methods for arbitrary implementations of GeoAPI interfaces. Of course we
have this dependency only in the tests, not in the library itself.
What do peoples think?
Martin
[1]
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
Re: Starting sis-metadata
Posted by Adam Estrada <es...@gmail.com>.
Hey Andrew,
Did you have a chance to look at the SIS site? I may have some time this
weekend to focus on it too...
Adam
On Tue, Sep 4, 2012 at 11:42 AM, Andrew Hart <ah...@apache.org> wrote:
> Hey Adam,
>
> I can help out here. I will take a look this afternoon.
>
> I've also created a JIRA issue to track the creation of a SIS logo:
>
> https://issues.apache.org/**jira/browse/SIS-57<https://issues.apache.org/jira/browse/SIS-57>
>
> We've done this on other projects and found it is a decent way to share
> ideas with folks who may have comments/contributions.
>
> Best,
>
> Andrew.
>
>
> On 09/04/2012 04:42 AM, Adam Estrada wrote:
>
>> Martin,
>>
>> Bootstrap is really pretty cool, but it still needs work! I only did the
>> first few pages so someone else needs to step up and finish it off. Any
>> takers on that? I am also working on a couple new logo ideas.
>>
>> Adam
>>
>> On Tue, Sep 4, 2012 at 7:29 AM, Martin Desruisseaux<
>> martin.desruisseaux@geomatys.**fr <ma...@geomatys.fr>>
>> wrote:
>>
>> Hello Chris
>>>
>>> Le 04/09/12 00:56, Mattmann, Chris A (388J) a écrit :
>>>
>>> Hrm, I wonder if it's complaining that we need a site.vm (velocity
>>> macro
>>>
>>>> file) to generate the site. We
>>>> moved to the ASF CMS (per SIS-31 [1]) and Ross Laidlaw helped us get
>>>> there so maybe Ross can
>>>> suggest how best to build the site now that we don't use Maven to build
>>>> it anymore.
>>>>
>>>> Do you mean that the web site is generated not by "mvn site", but by
>>> something else? In such case, we don't really need to fix "mvn site". Or
>>> better and easier, we just need to remove the following lines from the
>>> root
>>> pom.xml to fix the issue:
>>>
>>> <plugin>
>>> <artifactId>maven-site-plugin<****/artifactId>
>>> -<configuration>
>>> -<templateDirectory>src/site</****templateDirectory>
>>>
>>> -<template>site.vm</template>
>>> -</configuration>
>>> </plugin>
>>>
>>>
>>> Removing the above lines (for now) allow the site build to pass. If
>>> everyone agree, I propose to temporarily remove this configuration. This
>>> would allow me to tune the pom.xml configuration as proposed in
>>> https://issues.apache.org/****jira/browse/SIS-56<https://issues.apache.org/**jira/browse/SIS-56>
>>> <https://**issues.apache.org/jira/browse/**SIS-56<https://issues.apache.org/jira/browse/SIS-56>>and
>>> test the result (except the release goal).
>>>
>>>
>>>
>>>
>>> On SIS-31 [1], Adam Estrada also uploaded a skeleton version of a new
>>>
>>>> website
>>>> theme based on Twitter bootstrap, so it would be great to actually
>>>> implement
>>>> that and get it out there.
>>>>
>>>> I had a look and I have been surprised, its look good!
>>>
>>>
>>>
>>> I'm of Jenkins as a CI tool, and I think it would be fairly easy to set
>>>
>>>> up. In fact,
>>>> I tested this and just went ahead and set us up a Jenkins job:
>>>>
>>>> https://builds.apache.org/job/****sis-trunk/<https://builds.apache.org/job/**sis-trunk/>
>>>> <https://builds.**apache.org/job/sis-trunk/<https://builds.apache.org/job/sis-trunk/>
>>>> >
>>>>
>>>> Thanks! I like Jenkins too. Is this one configured for nightly builds?
>>> At
>>> which hour? Does it deploys the artifacts and the web site? (actually I
>>> would propose to not deploy yet, since I would like to do SIS-56 first).
>>>
>>> Martin
>>>
>>>
>>>
>
Re: Starting sis-metadata
Posted by Adam Estrada <es...@gmail.com>.
Thanks Andrew!
On Tue, Sep 4, 2012 at 11:42 AM, Andrew Hart <ah...@apache.org> wrote:
> Hey Adam,
>
> I can help out here. I will take a look this afternoon.
>
> I've also created a JIRA issue to track the creation of a SIS logo:
>
> https://issues.apache.org/**jira/browse/SIS-57<https://issues.apache.org/jira/browse/SIS-57>
>
> We've done this on other projects and found it is a decent way to share
> ideas with folks who may have comments/contributions.
>
> Best,
>
> Andrew.
>
>
> On 09/04/2012 04:42 AM, Adam Estrada wrote:
>
>> Martin,
>>
>> Bootstrap is really pretty cool, but it still needs work! I only did the
>> first few pages so someone else needs to step up and finish it off. Any
>> takers on that? I am also working on a couple new logo ideas.
>>
>> Adam
>>
>> On Tue, Sep 4, 2012 at 7:29 AM, Martin Desruisseaux<
>> martin.desruisseaux@geomatys.**fr <ma...@geomatys.fr>>
>> wrote:
>>
>> Hello Chris
>>>
>>> Le 04/09/12 00:56, Mattmann, Chris A (388J) a écrit :
>>>
>>> Hrm, I wonder if it's complaining that we need a site.vm (velocity
>>> macro
>>>
>>>> file) to generate the site. We
>>>> moved to the ASF CMS (per SIS-31 [1]) and Ross Laidlaw helped us get
>>>> there so maybe Ross can
>>>> suggest how best to build the site now that we don't use Maven to build
>>>> it anymore.
>>>>
>>>> Do you mean that the web site is generated not by "mvn site", but by
>>> something else? In such case, we don't really need to fix "mvn site". Or
>>> better and easier, we just need to remove the following lines from the
>>> root
>>> pom.xml to fix the issue:
>>>
>>> <plugin>
>>> <artifactId>maven-site-plugin<****/artifactId>
>>> -<configuration>
>>> -<templateDirectory>src/site</****templateDirectory>
>>>
>>> -<template>site.vm</template>
>>> -</configuration>
>>> </plugin>
>>>
>>>
>>> Removing the above lines (for now) allow the site build to pass. If
>>> everyone agree, I propose to temporarily remove this configuration. This
>>> would allow me to tune the pom.xml configuration as proposed in
>>> https://issues.apache.org/****jira/browse/SIS-56<https://issues.apache.org/**jira/browse/SIS-56>
>>> <https://**issues.apache.org/jira/browse/**SIS-56<https://issues.apache.org/jira/browse/SIS-56>>and
>>> test the result (except the release goal).
>>>
>>>
>>>
>>>
>>> On SIS-31 [1], Adam Estrada also uploaded a skeleton version of a new
>>>
>>>> website
>>>> theme based on Twitter bootstrap, so it would be great to actually
>>>> implement
>>>> that and get it out there.
>>>>
>>>> I had a look and I have been surprised, its look good!
>>>
>>>
>>>
>>> I'm of Jenkins as a CI tool, and I think it would be fairly easy to set
>>>
>>>> up. In fact,
>>>> I tested this and just went ahead and set us up a Jenkins job:
>>>>
>>>> https://builds.apache.org/job/****sis-trunk/<https://builds.apache.org/job/**sis-trunk/>
>>>> <https://builds.**apache.org/job/sis-trunk/<https://builds.apache.org/job/sis-trunk/>
>>>> >
>>>>
>>>> Thanks! I like Jenkins too. Is this one configured for nightly builds?
>>> At
>>> which hour? Does it deploys the artifacts and the web site? (actually I
>>> would propose to not deploy yet, since I would like to do SIS-56 first).
>>>
>>> Martin
>>>
>>>
>>>
>
Re: Starting sis-metadata
Posted by Ross Laidlaw <rl...@gmail.com>.
Hi All,
On 3 September 2012 16:56, Mattmann, Chris A (388J)
<ch...@jpl.nasa.gov> wrote:
> ... We moved to the ASF CMS (per SIS-31 [1]) and Ross Laidlaw helped us get there so maybe Ross
> can suggest how best to build the site now that we don't use Maven to build it anymore.
>
I'll try to get some concrete answers for this one. Would we want to
link Maven, CMS and Bootstrap together? Or maybe use two out of three
(e.g. Bootstrap & CMS)? The Maven team has tested Maven site builds
with CMS (see [1] and [2]) and is also working on a plugin [3]. The
Apache Thrift project that Chris mentioned is already using Bootstrap,
but I don't think the site is published with Maven (or to CMS yet)
[4], it looks like a Ruby build tool is used instead.
Ross
[1] http://apache.org/dev/cmsadoption.html (see 'Maven' section)
[2] https://issues.apache.org/jira/browse/infra-4466
[3] http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/
[4] http://thrift.apache.org/docs/committers/HowToThriftWebsite/
Re: Starting sis-metadata
Posted by Andrew Hart <ah...@apache.org>.
Hey Adam,
I can help out here. I will take a look this afternoon.
I've also created a JIRA issue to track the creation of a SIS logo:
https://issues.apache.org/jira/browse/SIS-57
We've done this on other projects and found it is a decent way to share
ideas with folks who may have comments/contributions.
Best,
Andrew.
On 09/04/2012 04:42 AM, Adam Estrada wrote:
> Martin,
>
> Bootstrap is really pretty cool, but it still needs work! I only did the
> first few pages so someone else needs to step up and finish it off. Any
> takers on that? I am also working on a couple new logo ideas.
>
> Adam
>
> On Tue, Sep 4, 2012 at 7:29 AM, Martin Desruisseaux<
> martin.desruisseaux@geomatys.fr> wrote:
>
>> Hello Chris
>>
>> Le 04/09/12 00:56, Mattmann, Chris A (388J) a écrit :
>>
>> Hrm, I wonder if it's complaining that we need a site.vm (velocity macro
>>> file) to generate the site. We
>>> moved to the ASF CMS (per SIS-31 [1]) and Ross Laidlaw helped us get
>>> there so maybe Ross can
>>> suggest how best to build the site now that we don't use Maven to build
>>> it anymore.
>>>
>> Do you mean that the web site is generated not by "mvn site", but by
>> something else? In such case, we don't really need to fix "mvn site". Or
>> better and easier, we just need to remove the following lines from the root
>> pom.xml to fix the issue:
>>
>> <plugin>
>> <artifactId>maven-site-plugin<**/artifactId>
>> -<configuration>
>> -<templateDirectory>src/site</**templateDirectory>
>> -<template>site.vm</template>
>> -</configuration>
>> </plugin>
>>
>>
>> Removing the above lines (for now) allow the site build to pass. If
>> everyone agree, I propose to temporarily remove this configuration. This
>> would allow me to tune the pom.xml configuration as proposed in
>> https://issues.apache.org/**jira/browse/SIS-56<https://issues.apache.org/jira/browse/SIS-56>and test the result (except the release goal).
>>
>>
>>
>> On SIS-31 [1], Adam Estrada also uploaded a skeleton version of a new
>>> website
>>> theme based on Twitter bootstrap, so it would be great to actually
>>> implement
>>> that and get it out there.
>>>
>> I had a look and I have been surprised, its look good!
>>
>>
>>
>> I'm of Jenkins as a CI tool, and I think it would be fairly easy to set
>>> up. In fact,
>>> I tested this and just went ahead and set us up a Jenkins job:
>>>
>>> https://builds.apache.org/job/**sis-trunk/<https://builds.apache.org/job/sis-trunk/>
>>>
>> Thanks! I like Jenkins too. Is this one configured for nightly builds? At
>> which hour? Does it deploys the artifacts and the web site? (actually I
>> would propose to not deploy yet, since I would like to do SIS-56 first).
>>
>> Martin
>>
>>
Re: Starting sis-metadata
Posted by Adam Estrada <es...@gmail.com>.
Martin,
Bootstrap is really pretty cool, but it still needs work! I only did the
first few pages so someone else needs to step up and finish it off. Any
takers on that? I am also working on a couple new logo ideas.
Adam
On Tue, Sep 4, 2012 at 7:29 AM, Martin Desruisseaux <
martin.desruisseaux@geomatys.fr> wrote:
> Hello Chris
>
> Le 04/09/12 00:56, Mattmann, Chris A (388J) a écrit :
>
> Hrm, I wonder if it's complaining that we need a site.vm (velocity macro
>> file) to generate the site. We
>> moved to the ASF CMS (per SIS-31 [1]) and Ross Laidlaw helped us get
>> there so maybe Ross can
>> suggest how best to build the site now that we don't use Maven to build
>> it anymore.
>>
>
> Do you mean that the web site is generated not by "mvn site", but by
> something else? In such case, we don't really need to fix "mvn site". Or
> better and easier, we just need to remove the following lines from the root
> pom.xml to fix the issue:
>
> <plugin>
> <artifactId>maven-site-plugin<**/artifactId>
> - <configuration>
> - <templateDirectory>src/site</**templateDirectory>
> - <template>site.vm</template>
> - </configuration>
> </plugin>
>
>
> Removing the above lines (for now) allow the site build to pass. If
> everyone agree, I propose to temporarily remove this configuration. This
> would allow me to tune the pom.xml configuration as proposed in
> https://issues.apache.org/**jira/browse/SIS-56<https://issues.apache.org/jira/browse/SIS-56>and test the result (except the release goal).
>
>
>
> On SIS-31 [1], Adam Estrada also uploaded a skeleton version of a new
>> website
>> theme based on Twitter bootstrap, so it would be great to actually
>> implement
>> that and get it out there.
>>
>
> I had a look and I have been surprised, its look good!
>
>
>
> I'm of Jenkins as a CI tool, and I think it would be fairly easy to set
>> up. In fact,
>> I tested this and just went ahead and set us up a Jenkins job:
>>
>> https://builds.apache.org/job/**sis-trunk/<https://builds.apache.org/job/sis-trunk/>
>>
>
> Thanks! I like Jenkins too. Is this one configured for nightly builds? At
> which hour? Does it deploys the artifacts and the web site? (actually I
> would propose to not deploy yet, since I would like to do SIS-56 first).
>
> Martin
>
>
Re: Starting sis-metadata
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Thanks Peter!
Cheers,
Chris
On Sep 7, 2012, at 9:13 AM, Peter K wrote:
> Hi there,
>
>>> I think this was introduced by Adam in SIS-30 [1] when we put in
>>> Jetty integration in sis-webapp. I think Jetty is just picking the
>>> default
>>> port to run unit tests on (8080), and that port is in use from time
>>> to time.
>>> We should probably file a JIRA issue for this as a bug and simply update
>>> the config to choose a random, unused port.
>>
>> If Jetty can easily locate an unused port, that would help.
>
> I've used this in the past for another project. Hopefully it can help
> somehow.
>
> private void bootJetty(int retryCount) {
> String webapp = "./target/app";
> WebAppContext app = // TODO set up this. I'm using guice which
> is probably different to SIS usage.
> app.setParentLoaderPriority(true);
>
> for (int i = 0; i < retryCount; i++) {
> // We explicitly use the SocketConnector because the
> SelectChannelConnector locks files
> Connector connector = new SocketConnector();
> connector.setPort(port = 18080 + i);
> connector.setMaxIdleTime(10000);
> server = new Server();
> server.setConnectors(new Connector[]{connector});
> server.setHandler(app);
> try {
> logger.info("Trying to start jetty at port " + port);
> server.start();
> break;
> } catch (Exception ex) {
> server = null;
> logger.error("Cannot start jetty at port " + port + " "
> + ex.getMessage());
> }
> }
> }
>
> Regards,
> Peter.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Fixing Jenkins Webapp module builds (was Re: Starting sis-metadata)
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Guys,
FYI I changed the subject line to more accurately reflect what we're talking about.
So, I fixed this in SIS-58: https://issues.apache.org/jira/browse/SIS-58.
Builds should be fine now!
Cheers,
Chris
On Sep 7, 2012, at 9:13 AM, Peter K wrote:
> Hi there,
>
>>> I think this was introduced by Adam in SIS-30 [1] when we put in
>>> Jetty integration in sis-webapp. I think Jetty is just picking the
>>> default
>>> port to run unit tests on (8080), and that port is in use from time
>>> to time.
>>> We should probably file a JIRA issue for this as a bug and simply update
>>> the config to choose a random, unused port.
>>
>> If Jetty can easily locate an unused port, that would help.
>
> I've used this in the past for another project. Hopefully it can help
> somehow.
>
> private void bootJetty(int retryCount) {
> String webapp = "./target/app";
> WebAppContext app = // TODO set up this. I'm using guice which
> is probably different to SIS usage.
> app.setParentLoaderPriority(true);
>
> for (int i = 0; i < retryCount; i++) {
> // We explicitly use the SocketConnector because the
> SelectChannelConnector locks files
> Connector connector = new SocketConnector();
> connector.setPort(port = 18080 + i);
> connector.setMaxIdleTime(10000);
> server = new Server();
> server.setConnectors(new Connector[]{connector});
> server.setHandler(app);
> try {
> logger.info("Trying to start jetty at port " + port);
> server.start();
> break;
> } catch (Exception ex) {
> server = null;
> logger.error("Cannot start jetty at port " + port + " "
> + ex.getMessage());
> }
> }
> }
>
> Regards,
> Peter.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Starting sis-metadata
Posted by Peter K <pe...@yahoo.de>.
Hi there,
>> I think this was introduced by Adam in SIS-30 [1] when we put in
>> Jetty integration in sis-webapp. I think Jetty is just picking the
>> default
>> port to run unit tests on (8080), and that port is in use from time
>> to time.
>> We should probably file a JIRA issue for this as a bug and simply update
>> the config to choose a random, unused port.
>
> If Jetty can easily locate an unused port, that would help.
I've used this in the past for another project. Hopefully it can help
somehow.
private void bootJetty(int retryCount) {
String webapp = "./target/app";
WebAppContext app = // TODO set up this. I'm using guice which
is probably different to SIS usage.
app.setParentLoaderPriority(true);
for (int i = 0; i < retryCount; i++) {
// We explicitly use the SocketConnector because the
SelectChannelConnector locks files
Connector connector = new SocketConnector();
connector.setPort(port = 18080 + i);
connector.setMaxIdleTime(10000);
server = new Server();
server.setConnectors(new Connector[]{connector});
server.setHandler(app);
try {
logger.info("Trying to start jetty at port " + port);
server.start();
break;
} catch (Exception ex) {
server = null;
logger.error("Cannot start jetty at port " + port + " "
+ ex.getMessage());
}
}
}
Regards,
Peter.
Re: Starting sis-metadata
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
On Sep 7, 2012, at 7:22 AM, Martin Desruisseaux wrote:
> Le 07/09/12 01:30, Mattmann, Chris A (388J) a écrit :
>> I think this was introduced by Adam in SIS-30 [1] when we put in
>> Jetty integration in sis-webapp. I think Jetty is just picking the default
>> port to run unit tests on (8080), and that port is in use from time to time.
>> We should probably file a JIRA issue for this as a bug and simply update
>> the config to choose a random, unused port.
>
> If Jetty can easily locate an unused port, that would help. Otherwise maybe an alternative could be for Apache to create a wiki page were each project list the port that they use for their Jenkins build? It could be project responsibility to choose an unused port and list it on that wiki.
Looks like we can solve it using Maven2 config (yay!), see:
http://blog.andyhot.gr/controlling-jetty-port-in-maven-2/#comment-108
Looks like we can define a start and stop port for it to check on.
I'll file a JIRA issue today and update this.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Starting sis-metadata
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 07/09/12 01:30, Mattmann, Chris A (388J) a écrit :
> I think this was introduced by Adam in SIS-30 [1] when we put in
> Jetty integration in sis-webapp. I think Jetty is just picking the default
> port to run unit tests on (8080), and that port is in use from time to time.
> We should probably file a JIRA issue for this as a bug and simply update
> the config to choose a random, unused port.
If Jetty can easily locate an unused port, that would help. Otherwise
maybe an alternative could be for Apache to create a wiki page were each
project list the port that they use for their Jenkins build? It could be
project responsibility to choose an unused port and list it on that wiki.
Martin
Re: Starting sis-metadata
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
I think this was introduced by Adam in SIS-30 [1] when we put in
Jetty integration in sis-webapp. I think Jetty is just picking the default
port to run unit tests on (8080), and that port is in use from time to time.
We should probably file a JIRA issue for this as a bug and simply update
the config to choose a random, unused port.
Cheers,
Chris
On Sep 6, 2012, at 9:20 AM, Martin Desruisseaux wrote:
> I just modified the Jenkins configuration as proposed in previous email, with one additional change: I limited the builds saved by Jenkins to 7 last days (previous configuration was putting no limit on the amount of builds to save). Of course we can change that duration if we need a longer history.
>
> However we have random build failure. One of them is:
>
> Failed to execute goal (...snip...) (start-jetty) on project sis-webapp: Failure.
> Caused by: java.net.BindException: Address already in use
>
> I'm not familiar with Jetty, but I wonder if we are limited in the number of applications using Jetty concurrently, in which case the build failure or success would depend on the other projects being built concurrently. In such case, one possible approach would be to disable the sis-webapp tests if some profile in enabled, and that profile would be enabled on Jenkins.
>
> Martin
>
[1] https://issues.apache.org/jira/browse/SIS-30
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Starting sis-metadata
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
I just modified the Jenkins configuration as proposed in previous email,
with one additional change: I limited the builds saved by Jenkins to 7
last days (previous configuration was putting no limit on the amount of
builds to save). Of course we can change that duration if we need a
longer history.
However we have random build failure. One of them is:
Failed to execute goal (...snip...) (start-jetty) on project sis-webapp:
Failure.
Caused by: java.net.BindException: Address already in use
I'm not familiar with Jetty, but I wonder if we are limited in the
number of applications using Jetty concurrently, in which case the build
failure or success would depend on the other projects being built
concurrently. In such case, one possible approach would be to disable
the sis-webapp tests if some profile in enabled, and that profile would
be enabled on Jenkins.
Martin
Re: Starting sis-metadata
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
On Sep 4, 2012, at 8:11 AM, Martin Desruisseaux wrote:
>
>> With that karma you should be able to do job-config for the sis-trunk job here:
>>
>> http://builds.apache.org/job/sis-trunk/
>>
>> Right now I set it to do nightly builds, and upon SVN changes
>> polled hourly. Feel free to update the config and let others know if you
>> do.
>
> Thanks! I just had a look at the config (but didn't touched anything yet). My proposal would be (just to be kind toward server load):
>
> * Check-out Strategy: replace "Always check-out a fresh copy" by "Use
> SVN update as much as possible"
+1
> * Maven goal: replace "install" by "clean install" (as a replacement
> for the "svn update" checkout strategy)
+1
> * Build: keep the check for SVN changes, but omit the unconditional
> daily build. This one is not only for server load, but also as an
> easy way to know when was the last commit, just by looking at the
> time stamp of JAR files or web site home page.
+1, fine by me :)
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Starting sis-metadata
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 04/09/12 23:48, Mattmann, Chris A (388J) a écrit :
> +1 to remove the above lines.
Cool, I will update the pom.xml tomorrow then.
> With that karma you should be able to do job-config for the sis-trunk job here:
>
> http://builds.apache.org/job/sis-trunk/
>
> Right now I set it to do nightly builds, and upon SVN changes
> polled hourly. Feel free to update the config and let others know if you
> do.
Thanks! I just had a look at the config (but didn't touched anything
yet). My proposal would be (just to be kind toward server load):
* Check-out Strategy: replace "Always check-out a fresh copy" by "Use
SVN update as much as possible"
* Maven goal: replace "install" by "clean install" (as a replacement
for the "svn update" checkout strategy)
* Build: keep the check for SVN changes, but omit the unconditional
daily build. This one is not only for server load, but also as an
easy way to know when was the last commit, just by looking at the
time stamp of JAR files or web site home page.
Martin
Re: Starting sis-metadata
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
On Sep 4, 2012, at 4:29 AM, Martin Desruisseaux wrote:
> Hello Chris
>
> Le 04/09/12 00:56, Mattmann, Chris A (388J) a écrit :
>> Hrm, I wonder if it's complaining that we need a site.vm (velocity macro file) to generate the site. We
>> moved to the ASF CMS (per SIS-31 [1]) and Ross Laidlaw helped us get there so maybe Ross can
>> suggest how best to build the site now that we don't use Maven to build it anymore.
>
> Do you mean that the web site is generated not by "mvn site", but by something else? In such case, we don't really need to fix "mvn site". Or better and easier, we just need to remove the following lines from the root pom.xml to fix the issue:
>
> <plugin>
> <artifactId>maven-site-plugin</artifactId>
> - <configuration>
> - <templateDirectory>src/site</templateDirectory>
> - <template>site.vm</template>
> - </configuration>
> </plugin>
>
>
> Removing the above lines (for now) allow the site build to pass. If everyone agree, I propose to temporarily remove this configuration. This would allow me to tune the pom.xml configuration as proposed in https://issues.apache.org/jira/browse/SIS-56 and test the result (except the release goal).
+1 to remove the above lines.
>
>
>> I'm of Jenkins as a CI tool, and I think it would be fairly easy to set up. In fact,
>> I tested this and just went ahead and set us up a Jenkins job:
>>
>> https://builds.apache.org/job/sis-trunk/
>
> Thanks! I like Jenkins too. Is this one configured for nightly builds? At which hour? Does it deploys the artifacts and the web site? (actually I would propose to not deploy yet, since I would like to do SIS-56 first).
I've granted you karma on jenkins via the instructions on this page:
http://wiki.apache.org/general/Jenkins?action=show&redirect=Hudson
[mattmann@minotaur]/home/mattmann(24): modify_appgroups.pl hudson-jobadmin --add=desruisseaux
Password for 'mattmann' (^D aborts):
Done!
Notification sent to <ro...@apache.org>.
[mattmann@minotaur]/home/mattmann(25):
With that karma you should be able to do job-config for the sis-trunk job here:
http://builds.apache.org/job/sis-trunk/
Right now I set it to do nightly builds, and upon SVN changes
polled hourly. Feel free to update the config and let others know if you
do.
Thanks!
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Starting sis-metadata
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris
Le 04/09/12 00:56, Mattmann, Chris A (388J) a écrit :
> Hrm, I wonder if it's complaining that we need a site.vm (velocity macro file) to generate the site. We
> moved to the ASF CMS (per SIS-31 [1]) and Ross Laidlaw helped us get there so maybe Ross can
> suggest how best to build the site now that we don't use Maven to build it anymore.
Do you mean that the web site is generated not by "mvn site", but by
something else? In such case, we don't really need to fix "mvn site". Or
better and easier, we just need to remove the following lines from the
root pom.xml to fix the issue:
<plugin>
<artifactId>maven-site-plugin</artifactId>
- <configuration>
- <templateDirectory>src/site</templateDirectory>
- <template>site.vm</template>
- </configuration>
</plugin>
Removing the above lines (for now) allow the site build to pass. If
everyone agree, I propose to temporarily remove this configuration. This
would allow me to tune the pom.xml configuration as proposed in
https://issues.apache.org/jira/browse/SIS-56 and test the result (except
the release goal).
> On SIS-31 [1], Adam Estrada also uploaded a skeleton version of a new website
> theme based on Twitter bootstrap, so it would be great to actually implement
> that and get it out there.
I had a look and I have been surprised, its look good!
> I'm of Jenkins as a CI tool, and I think it would be fairly easy to set up. In fact,
> I tested this and just went ahead and set us up a Jenkins job:
>
> https://builds.apache.org/job/sis-trunk/
Thanks! I like Jenkins too. Is this one configured for nightly builds?
At which hour? Does it deploys the artifacts and the web site? (actually
I would propose to not deploy yet, since I would like to do SIS-56 first).
Martin
Re: Starting sis-metadata
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
On Sep 3, 2012, at 8:25 AM, Martin Desruisseaux wrote:
> Hello all
>
> "mvn install" work without problem, but "mvn site" produces the following error message. I didn't meet this error before, does anyone is familiar with it?
>
> Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project sis: Template file 'trunk/src/site/site.vm' does not exist
Hrm, I wonder if it's complaining that we need a site.vm (velocity macro file) to generate the site. We
moved to the ASF CMS (per SIS-31 [1]) and Ross Laidlaw helped us get there so maybe Ross can
suggest how best to build the site now that we don't use Maven to build it anymore.
On SIS-31 [1], Adam Estrada also uploaded a skeleton version of a new website
theme based on Twitter bootstrap, so it would be great to actually implement that and get
it out there.
>
> On a related question, which continuous build integration system does the project use?
ASF provides several CI tools at http://ci.apache.org/.
I'm of Jenkins as a CI tool, and I think it would be fairly easy to set up. In fact,
I tested this and just went ahead and set us up a Jenkins job:
https://builds.apache.org/job/sis-trunk/
Woot! :)
Cheers,
Chris
[1] https://issues.apache.org/jira/browse/SIS-31
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Starting sis-metadata
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello all
"mvn install" work without problem, but "mvn site" produces the
following error message. I didn't meet this error before, does anyone is
familiar with it?
Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on
project sis: Template file 'trunk/src/site/site.vm' does not exist
On a related question, which continuous build integration system does
the project use?
Martin
Re: Starting sis-metadata
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 01/09/12 00:15, Mattmann, Chris A (388J) a écrit :
> +1 from me to proceed. I granted you karma on the SIS JIRA for resolve/close and other permissions
> and added the metadata component.
Thanks! I moved the relevant tasks to the new "metadata" modules, and
created a new one for the pom.xml configuration:
https://issues.apache.org/jira/browse/SIS-56
Martin
Re: Starting sis-metadata
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
+1 from me to proceed. I granted you karma on the SIS JIRA for resolve/close and other permissions
and added the metadata component.
Thanks!
Cheers,
Chris
On Aug 31, 2012, at 7:53 AM, Martin Desruisseaux wrote:
> Hello all
>
> I propose to start contribution with the skeleton implementation of the CI_Citation type as described in the https://issues.apache.org/jira/browse/SIS-55 task. Following this initial commit (required in order to have a non-empty module), I would like to tweak the pom.xml files in order to publish javadoc and some other informations (I will detail more in a JIRA task), before to continue on CI_Citation.
>
> Is there any comment? If none, I presume that I could go ahead with SIS-55 around Monday. In the main time, if someone has administrative power on JIRA, maybe it would be worth to create a "metadata" component on the following page?
>
> https://issues.apache.org/jira/browse/SIS#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel
>
> Martin
>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Starting sis-metadata
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello all
I propose to start contribution with the skeleton implementation of the
CI_Citation type as described in the
https://issues.apache.org/jira/browse/SIS-55 task. Following this
initial commit (required in order to have a non-empty module), I would
like to tweak the pom.xml files in order to publish javadoc and some
other informations (I will detail more in a JIRA task), before to
continue on CI_Citation.
Is there any comment? If none, I presume that I could go ahead with
SIS-55 around Monday. In the main time, if someone has administrative
power on JIRA, maybe it would be worth to create a "metadata" component
on the following page?
https://issues.apache.org/jira/browse/SIS#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel
Martin
Re: Starting sis-metadata
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 17/08/12 12:00, Mattmann, Chris A (388J) a écrit :
> Yep we use:
>
> mvn release:prepare
> mvn release:perform
But I wonder, when modifying the pom.xml, how to test those goals
without creating real tags on the SVN and without performing real
deployment? Or are those goals tested and eventually debugged only
during real releases if all other goals work fine?
> I'm OK to use 4. Do you use Eclipse? If so, could you help make an
> Eclipse profile that we could put up on our SIS wiki for devs to share?
I use NetBeans... This leads me to an other minor topic. In some
projects I create an "IDE/NetBeans" directory at the project root, which
contains convenience project file for NetBeans users (not strictly
necessary since NetBeans can open Maven projects natively, but the
ability to open as a native NetBeans project has other advantages). I
presumed that other IDE could use "IDE/<something>" directory, but I
don't know if this is correct...
Martin
Re: Starting sis-metadata
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
On Aug 16, 2012, at 11:27 AM, Martin Desruisseaux wrote:
> Hello all
>
> Le 16/08/12 13:05, Mattmann, Chris A (388J) a écrit :
>>> 1. Eventually merge the sis-parent/pom.xml file with the root pom.xml file, for simplifying a little bit the system.
>> Fine by me if you can make it work out the same way it currently does.
> I presume that the goals to preserve are "compile", "test", "install", "site", "deploy" and "release"? The only goal I don't know about is "release"; I never used that one - I always do my releases by hand in order to check - and often fix - any step. Does Apache SIS uses it?
Yep we use:
mvn release:prepare
mvn release:perform
To make releases of our software. The Maven2 release plugin automatically tags,
and transforms Pom release versions and GPG signs and uploads artifacts to the
Apache Nexus server at https://repository.apache.org/. Since it is one of the approved
Forges for Maven Central, it is then synced to Central and made part of the Maven2
repo there for everyone.
>
> In the main time I provided a patch for a skeleton Citation implementation:
>
> https://issues.apache.org/jira/browse/SIS-55
>
> This is a very incomplete implementation; I trimmed many functionalities in order to focus the discussion on smaller items. Some items that may be worth to discuss are:
Awesome, I will review it hopefully tomorrow or later this evening. Specific comments
below:
>
> * Coding convention: I noticed that the other SIS Java classes use a
> 2-spaces indentation instead of the usual 4. How do peoples feel
> about that? (note: I'm a supporter of 2-spaces indentation in XML
> files, especially ISO 19139 XML files which tend to be very depth.
> But I was used to stick to the more usual convention for Java code...)
I'm OK to use 4. Do you use Eclipse? If so, could you help make an
Eclipse profile that we could put up on our SIS wiki for devs to share?
If not, I can always make one for those Eclipse users like me out there:
https://cwiki.apache.org/confluence/display/SIS/Home
> * Standard Javadoc tags:
> o @author: I propose "First name Last name (Institution)". Any though?
Fine by me. I'm not a stickler for stuff like this. Consistency is important, but
if folks aren't consistent, that's fine too. I like your suggestion though!
> o @version: Personally, I don't use that for the file version.
> Instead I use it for the last project version in which this file
> got a significant change. This allow the user to know if
> upgrading his Apache SIS dependency may brings a change in the
> behaviour (including bug fixes) of this class. Any though?
Yeah I'm fine with removing these if you see them. They don't really add
much.
> o @since: the project version when the file were first introduced,
> completed by the provenance when the file started somewhere
> else. Example: "@since 0.3 (derived from geotk-2.5)".
Yeah I do that or a combination of JIRA issue ids, like
@since SIS-xx SIS-yy
> * Custom Javadoc tags: @module, @preformat, @section, @note. They
> require a custom doclet (not yet provided in the proposed patch). Do
> peoples feel okay with creating a module (e.g. sis-build) that
> provides only tools for building SIS? This module would include
> doclets for the above-cited tags, optional pack200 on JAR files and
> other stuff like that.
Sure that's fine by me I'm not super familiar with having done that before
but I can watch what you do and then learn and I'm willing to help maintain it.
>
>
> There is other issues raised by the proposed patch, but I guess we can start by the above ones...
Yep. What do others think?
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Starting sis-metadata
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello all
Le 16/08/12 13:05, Mattmann, Chris A (388J) a écrit :
>> 1. Eventually merge the sis-parent/pom.xml file with the root pom.xml file, for simplifying a little bit the system.
> Fine by me if you can make it work out the same way it currently does.
I presume that the goals to preserve are "compile", "test", "install",
"site", "deploy" and "release"? The only goal I don't know about is
"release"; I never used that one - I always do my releases by hand in
order to check - and often fix - any step. Does Apache SIS uses it?
In the main time I provided a patch for a skeleton Citation implementation:
https://issues.apache.org/jira/browse/SIS-55
This is a very incomplete implementation; I trimmed many functionalities
in order to focus the discussion on smaller items. Some items that may
be worth to discuss are:
* Coding convention: I noticed that the other SIS Java classes use a
2-spaces indentation instead of the usual 4. How do peoples feel
about that? (note: I'm a supporter of 2-spaces indentation in XML
files, especially ISO 19139 XML files which tend to be very depth.
But I was used to stick to the more usual convention for Java code...)
* Standard Javadoc tags:
o @author: I propose "First name Last name (Institution)". Any though?
o @version: Personally, I don't use that for the file version.
Instead I use it for the last project version in which this file
got a significant change. This allow the user to know if
upgrading his Apache SIS dependency may brings a change in the
behaviour (including bug fixes) of this class. Any though?
o @since: the project version when the file were first introduced,
completed by the provenance when the file started somewhere
else. Example: "@since 0.3 (derived from geotk-2.5)".
* Custom Javadoc tags: @module, @preformat, @section, @note. They
require a custom doclet (not yet provided in the proposed patch). Do
peoples feel okay with creating a module (e.g. sis-build) that
provides only tools for building SIS? This module would include
doclets for the above-cited tags, optional pack200 on JAR files and
other stuff like that.
There is other issues raised by the proposed patch, but I guess we can
start by the above ones...
Martin
Re: Starting sis-metadata
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
On Aug 15, 2012, at 9:20 AM, Martin Desruisseaux wrote:
> I saw that you already committed the patch, thanks :-)
Anytime!
>
> Do I create a series of patch proposals for configuring the Maven build? My proposals would be as below (note: I'm not going to start this task before tomorrow, so you have time to tell me if some point are bad ideas):
Up to you in terms of the way you organize it in JIRA. I'm always a fan of smaller, more
easily revertible patches, but if you made one I wouldn't complain :) I appreciate the help.
>
> 1. Eventually merge the sis-parent/pom.xml file with the root pom.xml
> file, for simplifying a little bit the system.
Fine by me if you can make it work out the same way it currently does.
> 2. Upgrade the org.apache.apache parent from version 7 to version 10.
+1.
> 3. Add a <pluginManagement> section for the missing declaration of
> plugins version, namely maven-javadoc-plugin, maven-jxr-plugin,
> maven-surefire-report-plugin and maven-pmd-plugin. This would get
> ride of the warnings at building time.
+1.
> 4. Move the version declaration of maven-bundle-plugin (currently
> repeated in every modules) to the above cited <pluginManagement>
> section.
+1.
> 5. Move the <reporting> section, which is now deprecated, to the
> <configuration> section of the maven-site-plugin plugin.
+1.
> 6. Configure the javadoc plugin.
+1.
Awesomeness.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: Starting sis-metadata
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
I saw that you already committed the patch, thanks :-)
Do I create a series of patch proposals for configuring the Maven build?
My proposals would be as below (note: I'm not going to start this task
before tomorrow, so you have time to tell me if some point are bad ideas):
1. Eventually merge the sis-parent/pom.xml file with the root pom.xml
file, for simplifying a little bit the system.
2. Upgrade the org.apache.apache parent from version 7 to version 10.
3. Add a <pluginManagement> section for the missing declaration of
plugins version, namely maven-javadoc-plugin, maven-jxr-plugin,
maven-surefire-report-plugin and maven-pmd-plugin. This would get
ride of the warnings at building time.
4. Move the version declaration of maven-bundle-plugin (currently
repeated in every modules) to the above cited <pluginManagement>
section.
5. Move the <reporting> section, which is now deprecated, to the
<configuration> section of the maven-site-plugin plugin.
6. Configure the javadoc plugin.
Martin
Re: Starting sis-metadata
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris
Le 15/08/12 23:59, Mattmann, Chris A (388J) a écrit :
> Got it, thanks! Martin, can you please file an issue here:
>
> https://issues.apache.org/jira/browse/SIS
Done: https://issues.apache.org/jira/browse/SIS-52
I didn't assigned a component to this issue. Maybe someone with
administrative power could create a "metadata" component, then assign
the above issue to that component?
Additionally maybe we should rename the existing "distance function" as
"referencing", and "geometry objects" as "geometry"?
>> A quick note: isn't the "svn:ignore" property missing on the "sis-app" directory? This property is presents in other directories (except "sis-data").
> +1, another JIRA issue please :)
Done: https://issues.apache.org/jira/browse/SIS-53
> This is a good question. We applied this procedure in Tika, and so I copied it through to SIS. I think that the rationale is that
> the parent pom contains simply properties that we wanted to be inherited (e.g., plugin configuration, build set up, etc.), but
> it wasn't the multi-module project that would be ROOT/pom.xml as is currently. We don't expect any sis modules to inherit
> that pom else they would inherit the multi-module definition.
Ah, this is for preventing modules to inherit the <modules> elements? I
wonder if those elements are really inherited... I'm used to use the
root pom.xml both for the parent definition and the modules declaration,
and never noticed any issue with that. However I don't know which
practice is recommended.
>> I wonder also why declaring a "<sis.version>" property in the sis-parent pom.xml given that the standard "$project.version" property fits the purpose?
> +1, please file a JIRA issue for this and we'll convert it.
Done: https://issues.apache.org/jira/browse/SIS-54
>> * Units of measurement (currently JSR-275, but this project is dead...)
> - do you know the license on this library or vecmath?
The legacy JSR-275 library has a BSD-like license. But we need to get
ride of this dependency anyway (however this work needs to be done
partially one GeoAPI side).
The vecmath license is not clear to me. It was part of Java3D, so I
think it is one of the Sun license that allowed distribution (indeed, it
was pre-installed on any MacOS systems before Apple dropped Java
support). We may consider replacing this dependency by an other linear
algebra package (mostly matrix multiplication and inversion). Since its
use appears only in the referencing module, we have some time before that.
Martin
Re: Starting sis-metadata
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
On Aug 15, 2012, at 2:26 AM, Martin Desruisseaux wrote:
> Hello all
>
> Thanks Chris for all your comments. I got the acknowledgement from the Apache secretary that the got my ICLA, so its look like that we can process. I attached to this email I first patch proposal creating an initially empty "sis-metadata" directory. The rest of this email is about question related to this patch, the most important one probably being the GeoAPI dependency:
Got it, thanks! Martin, can you please file an issue here:
https://issues.apache.org/jira/browse/SIS
And then attach your sis-metadata directory patch there? We use JIRA to
track our issues and help to log our SVN commits and tie them to JIRA, so
I'd appreciate you filing that issue and getting the credit for the patch.
>
>
> Missing "svn:ignore" (minor)
> ------------------------
> A quick note: isn't the "svn:ignore" property missing on the "sis-app" directory? This property is presents in other directories (except "sis-data").
+1, another JIRA issue please :)
>
>
> Modules grouping (may be deferred)
> -------------------------------
> The attached patch creates the directory at the project root, because all other SIS modules do that way. I'm not completely sure that it is worth to group modules by categories; I did that way in Geotk mostly because GeoTools did that way, and I originally wanted to stay close to GeoTools developers habits. Whatever we should do that for Apache SIS or not is an open question.
Cool OK. Yeah for now, let's not group by categories, and if we find that we need to, that's fine too.
>
>
> Parent pom.xml
> -------------
> I noticed that SIS put the parent pom.xml in a separated module, namely "sis-parent". I wonder why the parent is not the root pom.xml? This would reduce by 1 the amount of "modules". But surely I'm missing a reason?
This is a good question. We applied this procedure in Tika, and so I copied it through to SIS. I think that the rationale is that
the parent pom contains simply properties that we wanted to be inherited (e.g., plugin configuration, build set up, etc.), but
it wasn't the multi-module project that would be ROOT/pom.xml as is currently. We don't expect any sis modules to inherit
that pom else they would inherit the multi-module definition.
>
>
> <sis.version> property (minor)
> --------------------------
> I wonder also why declaring a "<sis.version>" property in the sis-parent pom.xml given that the standard "$project.version" property fits the purpose?
+1, please file a JIRA issue for this and we'll convert it.
>
>
> GeoAPI dependency
> -----------------
> This patch modifies the sis-parent/pom.xml file for adding dependency management items for GeoAPI 3.0.0 (for now, maybe we would depend on a milestone later). In order to ensure version consistency, this patch does not only manage GeoAPI dependencies. It also _import_ the GeoAPI <dependencyManagement> section, using the Maven <scope>import</scope> functionality [1]. This has the effect of importing three dependency management items:
>
> * Units of measurement (currently JSR-275, but this project is dead...)
- do you know the license on this library or vecmath?
> * vecmath
> * JUnit
>
> Because of the later, this import replaces the original JUnit management. This has the side-effect of increasing the JUnit version from 3.8.1 to 4.8.2. The reason why we import a JUnit dependency is because we inherit that dependency from the geoapi-conformance module. geoapi-conformance "extends" JUnit by providing validators and test methods for arbitrary implementations of GeoAPI interfaces. Of course we have this dependency only in the tests, not in the library itself.
+1 I'm fine with upgrading to a later Junit module. That's fine by me.
>
>
> What do peoples think?
Yep, others, please speak up :) From me, my comments are above and looking forward to the JIRA issues, and to getting this
going Martin. Thanks.
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++