Date   

Affinity artifacts versions 0.4.1-SNAPSHOT not appearing in Nexus

Ed Warnicke (eaw) <eaw@...>
 

Guys,
It would appear that version 0.4.1-SNAPSHOT of your affinity artifacts are not appearing 
in Nexus: 


Would you please check to make sure your affinity-merge job is pushing them correctly?
I discovered this while trying to pull together the distribution directories for the Release Vehicles
in the integration project.  It cannot resolve them from Nexus :(
Please correct this promptly so that we can include you in the Release Vehicles :)

Ed


Re: Please publish Defense4All artifacts so they can be included in Simultaneous Release Vehicles

Ed Warnicke (eaw) <eaw@...>
 

Resending to defense4-all as original was bounced because I wasn't subscribed.

Ed
On Oct 1, 2013, at 3:57 PM, Ed Warnicke (eaw) <eaw@...> wrote:

Guys,
Right now there are no artifacts for groupid org.opendaylight.defense4all in nexus.opendaylight.org,
which means I can't include them in the Release Vehicle (what we will actually be releasing)  builds I'm doing in the integration project.
Looking at your pom.xml files, this appears to be because they are using groupId controlapps and not org.opendaylight.defense4all
and thus your Jenkin's Merge Job will not have appropriate rights to deploy them to Nexus.  If you could please correct this, and 
make sure that your merge job is properly pushing artifacts to Nexus:


I would be happy to include you in the Virtualization Edition :)

Ed


Re: Affinity artifacts versions 0.4.1-SNAPSHOT not appearing in Nexus

Ed Warnicke (eaw) <eaw@...>
 

Resending to affinity-dev as the original was bounced because I wasn't subscribed.

Ed
On Oct 1, 2013, at 4:41 PM, Ed Warnicke (eaw) <eaw@...> wrote:

Guys,
It would appear that version 0.4.1-SNAPSHOT of your affinity artifacts are not appearing 
in Nexus: 


Would you please check to make sure your affinity-merge job is pushing them correctly?
I discovered this while trying to pull together the distribution directories for the Release Vehicles
in the integration project.  It cannot resolve them from Nexus :(
Please correct this promptly so that we can include you in the Release Vehicles :)

Ed



ODL Integration Group weekly call

Luis Gomez <luis.gomez@...>
 

Hi all,

 

Please do not forget the weekly call tomorrow.

 

https://wiki.opendaylight.org/view/CrossProject:Integration_Group:Meetings

 

BR/Luis

 

From: Cisco WebEx [mailto:admin@...]
Sent: Tuesday, October 01, 2013 4:06 PM
To: Luis Gomez
Subject: WebEx meeting scheduled: ODL Integration Group weekly call

 

Cisco WebEx logo

 

Hi Luis Gomez,

You are scheduled to host this WebEx meeting.

Here are the details for your meeting. To edit the meeting or add files and comments, visit your meeting space by selecting the meeting name below.

 

  

ODL Integration Group weekly call

Wed, Oct 2, 1:00 pm | 1 hr

San Francisco (Pacific Daylight Time, GMT-07:00)

Host: Luis Gomez

  

 

 

 

Add the attached iCalendar (.ics) file to your calendar.

 

 

 

Agenda

Project news
Tasks progress
Q&A

 

 

 

Access Information

Where:

 

WebEx Online

Meeting number:

 

199 361 236

Password:

 

This meeting does not require a password.

Host key:

 

753067 (Use this key in the meeting if you have made someone else the host and then want to reclaim the host role.)

 

 

 

Audio Connection

+1-415-655-0001 US TOLL

Access code: 199 361 236

 

 

 

 

 

 

Meeting Files (0)

 

Can't access your meeting? Get help.

Delivering the power of collaboration,
Cisco WebEx Team

Footer

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the meeting to be recorded. You should inform all meeting attendees prior to recording if you intend to record the meeting. Please note that any such recordings may be subject to discovery in the event of litigation.

©2013 Cisco and/or its affiliates. All rights reserved.
MT-A-015

Cisco

 


ODL Integration Group weekly call (till end of the year)

Luis Gomez <luis.gomez@...>
 

And here is the meeting series till the end of the year.

 

BR/Luis

 


Re: Please update vtn-verify and vtn-merge to support Release Vehicles

Hideyuki Tai <h-tai@...>
 

Hi Ed,

Sorry for the inconvenience.
We will look into vtn-verify job and vtn-merge job to support Release
Vehicles, and also review the use of check style config.

Thanks,
Hideyuki Tai

-----Original Message-----
From: integration-dev-bounces@...
[mailto:integration-dev-bounces@...] On Behalf Of Ed
Warnicke (eaw)
Sent: Wednesday, October 02, 2013 5:48 AM
To: vtn-dev@...; integration-dev@...
Subject: Re: [integration-dev] Please update vtn-verify and vtn-merge to
support Release Vehicles

I realized when trying to build your manager/commons that it suffers from
an
issue around the use of

<configLocation>
${project.parent.basedir}/checkstyle.xml
</configLocation>

for check style, that causes a build error. We solved that in controller
by
pulling the check style config into its own maven project (see
opendaylight/commons/checkstyle, it's quite simple) and including it as a
dependency for the check style plugin (see
opendaylight/commons/opendaylight :

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>${checkstyle.version}</version>
<dependencies>
<dependency>
<groupId>org.opendaylight.controller</groupId>
<artifactId>checkstyle</artifactId>
<version>0.0.2-SNAPSHOT</version>
</dependency>
</dependencies>
<executions>
<execution>
<phase>process-sources</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
<configuration>
<failsOnError>true</failsOnError>

<configLocation>controller/space_and_tabs_checks.xml</configLocation>
<consoleOutput>true</consoleOutput>
<includeTestSourceDirectory>true</includeTestSourceDirectory>
<sourceDirectory>${project.basedir}</sourceDirectory>

<includes>**\/*.java,**\/*.xml,**\/*.ini,**\/*.sh,**\/*.bat</includes>
<excludes>target\/</excludes>
</configuration>
</plugin>


).

Ed
On Oct 1, 2013, at 3:33 PM, Ed Warnicke (eaw) <eaw@...> wrote:

As part of putting together the release vehicles for ODL (Base,
Virtualization, Service Provider) I am constructing distribution
directories
for each flavor in the integration project.

When I attempt to pull in

<dependency>
<groupId>org.opendaylight.vtn</groupId>
<artifactId>manager</artifactId>
<version>0.1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.opendaylight.vtn</groupId>
<artifactId>manager.implementation</artifactId>
<version>0.1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.opendaylight.vtn</groupId>
<artifactId>manager.northbound</artifactId>
<version>0.1.0-SNAPSHOT</version>
</dependency>


To include the vtn pieces, I encounter an error:

[ERROR] Failed to execute goal on project
distributions-virtualization: Could not resolve dependencies for
project
org.opendaylight.integration:distributions-virtualization:pom:0.1.0-SN
APSHOT: Failed to collect dependencies for
[org.opendaylight.integration:distributions-base:zip:osgipackage:0.1.0
-SNAPSHOT (provided), org.opendaylight.ovsdb:ovsdb:jar:0.4.0-SNAPSHOT
(compile), org.opendaylight.vtn:manager:jar:0.1.0-SNAPSHOT (compile),
org.opendaylight.vtn:manager.implementation:jar:0.1.0-SNAPSHOT
(compile), org.opendaylight.vtn:manager.northbound:jar:0.1.0-SNAPSHOT
(compile)]: Failed to read artifact descriptor for
org.opendaylight.vtn:manager:jar:0.1.0-SNAPSHOT: Failure to find
org.opendaylight.vtn:manager.common:pom:0.1.0-SNAPSHOT in
http://nexus.opendaylight.org/content/repositories/jsonrpc4j-webdav-ma
ven-repo/ was cached in the local repository, resolution will not be
reattempted until the update interval of jsonrpc4j-webdav-maven-repo
has elapsed or updates are forced -
> [Help 1]


This error is occurring because the
org.opendaylight.vtn:manager.common is not being built by your merge
job, and thus its artifact is not being pushed to Nexus. Since the
other vtn manager artifacts depend on it, I am unsuccessful in pulling
them into the virtualization edition via maven/nexus. You can resolve
this if you will insert a Post Build Step into your vtn-verify and
vtn-merge jobs that build

commons/
manager/commons/

So that their pom.xml files get deployed. Your prompt assistance with
this
would be very much appreciated,
as it is blocking getting the Release Vehicles going :)

Ed

_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev


Initial commit of distributions directories (Base, Virtualization, Service Provider)

Ed Warnicke (eaw) <eaw@...>
 

The initial commit of the distributions directories is here:


If another committer from integration could review it and submit it so it can be merged into master, that would help :)

Ed

P.S.  Currently I've commented out of Virtualization vtn and defense4all due to some issues 
that prevent their inclusion (their respective aliases have been informed, and the problems should be
easy for them to fix :) )

For the same reasons, defense4all is commented out of Service Provider (again, should be an easy fix).



Re: Initial commit of distributions directories (Base, Virtualization, Service Provider)

Luis Gomez <luis.gomez@...>
 

Hi Ed, I have already approved your commit. Just one curiosity, how is it that the code got merged without running jenkins verify and merge jobs? Are not these set yet?


On Oct 1, 2013, at 9:22 PM, "Ed Warnicke (eaw)" <eaw@...> wrote:

The initial commit of the distributions directories is here:


If another committer from integration could review it and submit it so it can be merged into master, that would help :)

Ed

P.S.  Currently I've commented out of Virtualization vtn and defense4all due to some issues 
that prevent their inclusion (their respective aliases have been informed, and the problems should be
easy for them to fix :) )

For the same reasons, defense4all is commented out of Service Provider (again, should be an easy fix).


_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev


Re: Initial commit of distributions directories (Base, Virtualization, Service Provider)

Luis Gomez <luis.gomez@...>
 

I just tried the verify job and it failed, maybe this is expected and thats why it is not triggered during the commit.


On Oct 1, 2013, at 11:17 PM, "Luis Gomez" <luis.gomez@...> wrote:

Hi Ed, I have already approved your commit. Just one curiosity, how is it that the code got merged without running jenkins verify and merge jobs? Are not these set yet?


On Oct 1, 2013, at 9:22 PM, "Ed Warnicke (eaw)" <eaw@...> wrote:

The initial commit of the distributions directories is here:


If another committer from integration could review it and submit it so it can be merged into master, that would help :)

Ed

P.S.  Currently I've commented out of Virtualization vtn and defense4all due to some issues 
that prevent their inclusion (their respective aliases have been informed, and the problems should be
easy for them to fix :) )

For the same reasons, defense4all is commented out of Service Provider (again, should be an easy fix).


_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev
_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev


Re: Please update vtn-verify and vtn-merge to support Release Vehicles

Hideyuki Tai <h-tai@...>
 

Hi Ed,

The problem has been fixed by the patch pushed by Shigeru.
https://git.opendaylight.org/gerrit/#/c/1592/

Now, all files of VTN Project needed for building Virtulization Edition are
deployed.

Regards,
Hideyuki Tai

-----Original Message-----
From: integration-dev-bounces@...
[mailto:integration-dev-bounces@...] On Behalf Of
Hideyuki Tai
Sent: Wednesday, October 02, 2013 8:49 AM
To: 'Ed Warnicke (eaw)'; vtn-dev@...;
integration-dev@...
Subject: Re: [integration-dev] Please update vtn-verify and vtn-merge to
support Release Vehicles

Hi Ed,

Sorry for the inconvenience.
We will look into vtn-verify job and vtn-merge job to support Release
Vehicles,
and also review the use of check style config.

Thanks,
Hideyuki Tai

-----Original Message-----
From: integration-dev-bounces@...
[mailto:integration-dev-bounces@...] On Behalf Of
Ed Warnicke (eaw)
Sent: Wednesday, October 02, 2013 5:48 AM
To: vtn-dev@...;
integration-dev@...
Subject: Re: [integration-dev] Please update vtn-verify and vtn-merge
to support Release Vehicles

I realized when trying to build your manager/commons that it suffers
from
an
issue around the use of

<configLocation>
${project.parent.basedir}/checkstyle.xml
</configLocation>

for check style, that causes a build error. We solved that in
controller
by
pulling the check style config into its own maven project (see
opendaylight/commons/checkstyle, it's quite simple) and including it
as a dependency for the check style plugin (see
opendaylight/commons/opendaylight :

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>${checkstyle.version}</version>
<dependencies>
<dependency>
<groupId>org.opendaylight.controller</groupId>
<artifactId>checkstyle</artifactId>
<version>0.0.2-SNAPSHOT</version>
</dependency>
</dependencies>
<executions>
<execution>
<phase>process-sources</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
<configuration>
<failsOnError>true</failsOnError>

<configLocation>controller/space_and_tabs_checks.xml</configLocation>
<consoleOutput>true</consoleOutput>
<includeTestSourceDirectory>true</includeTestSourceDirectory>
<sourceDirectory>${project.basedir}</sourceDirectory>

<includes>**\/*.java,**\/*.xml,**\/*.ini,**\/*.sh,**\/*.bat</includes>
<excludes>target\/</excludes>
</configuration>
</plugin>


).

Ed
On Oct 1, 2013, at 3:33 PM, Ed Warnicke (eaw) <eaw@...> wrote:

As part of putting together the release vehicles for ODL (Base,
Virtualization, Service Provider) I am constructing distribution
directories
for each flavor in the integration project.

When I attempt to pull in

<dependency>
<groupId>org.opendaylight.vtn</groupId>
<artifactId>manager</artifactId>
<version>0.1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.opendaylight.vtn</groupId>
<artifactId>manager.implementation</artifactId>
<version>0.1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.opendaylight.vtn</groupId>
<artifactId>manager.northbound</artifactId>
<version>0.1.0-SNAPSHOT</version>
</dependency>


To include the vtn pieces, I encounter an error:

[ERROR] Failed to execute goal on project
distributions-virtualization: Could not resolve dependencies for
project
org.opendaylight.integration:distributions-virtualization:pom:0.1.0-
SN
APSHOT: Failed to collect dependencies for
[org.opendaylight.integration:distributions-base:zip:osgipackage:0.1
.0 -SNAPSHOT (provided),
org.opendaylight.ovsdb:ovsdb:jar:0.4.0-SNAPSHOT
(compile), org.opendaylight.vtn:manager:jar:0.1.0-SNAPSHOT
(compile),
org.opendaylight.vtn:manager.implementation:jar:0.1.0-SNAPSHOT
(compile),
org.opendaylight.vtn:manager.northbound:jar:0.1.0-SNAPSHOT
(compile)]: Failed to read artifact descriptor for
org.opendaylight.vtn:manager:jar:0.1.0-SNAPSHOT: Failure to find
org.opendaylight.vtn:manager.common:pom:0.1.0-SNAPSHOT in
http://nexus.opendaylight.org/content/repositories/jsonrpc4j-webdav-
ma ven-repo/ was cached in the local repository, resolution will not
be reattempted until the update interval of
jsonrpc4j-webdav-maven-repo has elapsed or updates are forced -
> [Help 1]


This error is occurring because the
org.opendaylight.vtn:manager.common is not being built by your merge
job, and thus its artifact is not being pushed to Nexus. Since the
other vtn manager artifacts depend on it, I am unsuccessful in
pulling them into the virtualization edition via maven/nexus. You
can resolve this if you will insert a Post Build Step into your
vtn-verify and vtn-merge jobs that build

commons/
manager/commons/

So that their pom.xml files get deployed. Your prompt assistance
with
this
would be very much appreciated,
as it is blocking getting the Release Vehicles going :)

Ed

_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev
_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev


Re: [OpenDaylight Discuss] Initial commit of distributions directories (Base, Virtualization, Service Provider)

Hideyuki Tai <h-tai@...>
 

Hi Ed,

 

The issue on VTN Project has been fixed by the following patch.

  https://git.opendaylight.org/gerrit/#/c/1592/

 

So could you delete the line to comment out vtn from distributions/virtualization/pom.xml?

 

I’ve already confirmed that building Virtual Edition with vtn is successful in my local server.

 

Regards,

Hideyuki Tai

 

 

From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of Ed Warnicke (eaw)
Sent: Wednesday, October 02, 2013 1:22 PM
To: integration-dev@...
Cc: discuss@...
Subject: [OpenDaylight Discuss] Initial commit of distributions directories (Base, Virtualization, Service Provider)

 

The initial commit of the distributions directories is here:

 

 

If another committer from integration could review it and submit it so it can be merged into master, that would help :)

 

Ed

 

P.S.  Currently I've commented out of Virtualization vtn and defense4all due to some issues 

that prevent their inclusion (their respective aliases have been informed, and the problems should be

easy for them to fix :) )

 

For the same reasons, defense4all is commented out of Service Provider (again, should be an easy fix).

 

 


Update release information

Luis Gomez <luis.gomez@...>
 

Hi all,

 

I have been reading about the components and NB APIs available for Basic Edition and I updated our wiki with basic information:

 

https://wiki.opendaylight.org/view/CrossProject:Integration_Group:Release_Features

 

Please check it out and come back with comments.

 

BR/Luis

 


Integration meeting MoM

Luis Gomez <luis.gomez@...>
 

Hi all,

Please check MoM of yesterday meeting:

 

https://wiki.opendaylight.org/view/CrossProject:Integration_Group:Meetings

 

BR/Luis

 


System Test for BGP/PCEP

Luis Gomez <luis.gomez@...>
 

Hi BGP/PCEP people,

 

I am reading you project wiki and I have a question: do you know of any service or plugin that makes use of your libraries in this ODL first release? I am just trying to figure out how we can test your libraries from a system test point of view.

 

Thanks/Luis


Re: TestON

Swaraj Vinjapuri
 

Check this at the Github.


It is python based.  I am trying to setup the environment.

Regards,
Swaraj


From: carol.sanders@...
To: swarajv@...; luis.gomez@...
CC: integration-dev@...
Date: Tue, 1 Oct 2013 10:56:14 -0700
Subject: RE: [integration-dev] TestON

I would love to be able to demo results of some of our test way On Labs did graphically.

It’s probably too much to implement for our current milestone dates but we could perhaps plan to integrate

a graphical demonstration of the Test/Automation and CIT environment later.

 

Very cool,

 

Carol

 

 

From: Swaraj Vinjapuri [mailto:swarajv@...]
Sent: Tuesday, October 01, 2013 10:52 AM
To: Carol Sanders; Luis Gomez
Cc: integration-dev@...
Subject: RE: [integration-dev] TestON

 

Yes Luis, I was present at the TWS call as well. ON.LAB Preso was awesome.

 

 

the webx recording link is at 

Sep 30th meeting.

 

 

They claim that they have they Unit testing covering 70% code coverage and their 

 

System/Integration testing  taking it to 85%.

 

We should be able to look at what they have and leverage, given that it is an open sources code base.

 

I am trying to get the contact of folks in ON.LAB and reach out to them. Plan to get my environment setup to  get their git code base.

 

 

Regards,

Swaraj

 

 

> From: carol.sanders@...
> To: luis.gomez@...
> Date: Tue, 1 Oct 2013 08:45:25 -0700
> CC: integration-dev@...
> Subject: Re: [integration-dev] TestON
>
> Yes I will take a look today.
>
> Thanks,
>
> Carol
>
> -----Original Message-----
> From: Luis Gomez [mailto:luis.gomez@...]
> Sent: Monday, September 30, 2013 3:38 PM
> To: Carol Sanders
> Cc: integration-dev@...
> Subject: TestON
>
> Hi Carol,
>
> Today I learned through the TWS call that people from ON.LAB (http://onlab.us) are developing another kind (OS based) of SDN controller called ONOS. It happens that they use a test framework also developed by them called TestON (http://onlab.us/testing.html) and even more interesting they offer a set of TCs for those interested in testing the SDN controller. We should maybe take a look and see if we can reuse something...
>
> Thanks/Luis
>
>
>
>
>
> _______________________________________________
> integration-dev mailing list
> integration-dev@...
> https://lists.opendaylight.org/mailman/listinfo/integration-dev


Re: System Test for BGP/PCEP

Dana Kutenicsova -X (dkutenic - Pantheon Technologies SRO@Cisco) <dkutenic@...>
 

Hi Luis,

there is no user of our code in ODL, to my knowledge. 
For BGP we can use http://www.nongnu.org/quagga/ (but note, that it doesn't implement BGP linkstate
 - http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-03) which is core feature in our BGP implementation.
As for PCEP, we need to discuss an idea, I'll get back to you next week (no later than on Wednesday).

Regards,
Dana


From: Luis Gomez [luis.gomez@...]
Sent: Friday, October 04, 2013 2:46 AM
To: Robert Varga -X (rovarga - Pantheon Technologies SRO at Cisco); Dana Kutenicsova -X (dkutenic - Pantheon Technologies SRO at Cisco); Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco); Jan Medved (jmedved)
Cc: integration-dev@...
Subject: System Test for BGP/PCEP

Hi BGP/PCEP people,

 

I am reading you project wiki and I have a question: do you know of any service or plugin that makes use of your libraries in this ODL first release? I am just trying to figure out how we can test your libraries from a system test point of view.

 

Thanks/Luis


Java and REST API docs

Luis Gomez <luis.gomez@...>
 

Hi Ed or any other integration member with some understanding on the development infrastructure:

 

I saw that for controller project, every time they do a new build they generate a bunch of very useful information regarding Java APIs and NB REST APIs (see attached captures).

 

Is it possible to generate this useful information when we build our release vehicles? If not, is there a chance to have it available for the other projects (Affinity, Dove, VTN, etc..)? If not, is there a standard way to check the generated APIs without going and read the Java source code?

 

PS- API freeze Milestone is coming and I am just looking for an easy way to learn about the APIs.

 

Thanks/Luis

 

 


Re: Java and REST API docs

Ed Warnicke (eaw) <eaw@...>
 

There should be… we use the enunciate plugin to do it, and there's no reason other projects couldn't as well.  Pulling it all 
together in one place could be interesting.  That said, we do have


That lists them out :)

Ed
On Oct 4, 2013, at 11:49 AM, Luis Gomez <luis.gomez@...>
 wrote:

Hi Ed or any other integration member with some understanding on the development infrastructure:
 
I saw that for controller project, every time they do a new build they generate a bunch of very useful information regarding Java APIs and NB REST APIs (see attached captures).
 
Is it possible to generate this useful information when we build our release vehicles? If not, is there a chance to have it available for the other projects (Affinity, Dove, VTN, etc..)? If not, is there a standard way to check the generated APIs without going and read the Java source code?
 
PS- API freeze Milestone is coming and I am just looking for an easy way to learn about the APIs.
 
Thanks/Luis
 
 
<NB_REST.JPG><API_docs.JPG>


Re: Java and REST API docs

Luis Gomez <luis.gomez@...>
 

Hi Ed,

 

The link is OK but has the same issue, so far only the controller project shows the right information from the build. Question: are the projects supposed to feed this page with their information after API freezes? If so I guess I can wait but it would be good to have something before. If you tell me how this enunciate plugin works, I can maybe ask the projects to include it.

 

Thanks/Luis

 

 

From: Ed Warnicke (eaw) [mailto:eaw@...]
Sent: Friday, October 04, 2013 11:32 AM
To: Luis Gomez
Cc: integration-dev@...
Subject: Re: Java and REST API docs

 

There should be… we use the enunciate plugin to do it, and there's no reason other projects couldn't as well.  Pulling it all 

together in one place could be interesting.  That said, we do have

 

 

That lists them out :)

 

Ed

On Oct 4, 2013, at 11:49 AM, Luis Gomez <luis.gomez@...>

 wrote:



Hi Ed or any other integration member with some understanding on the development infrastructure:

 

I saw that for controller project, every time they do a new build they generate a bunch of very useful information regarding Java APIs and NB REST APIs (see attached captures).

 

Is it possible to generate this useful information when we build our release vehicles? If not, is there a chance to have it available for the other projects (Affinity, Dove, VTN, etc..)? If not, is there a standard way to check the generated APIs without going and read the Java source code?

 

PS- API freeze Milestone is coming and I am just looking for an easy way to learn about the APIs.

 

Thanks/Luis

 

 

<NB_REST.JPG><API_docs.JPG>

 


CSIT OSGi -> CIT Java

Luis Gomez <luis.gomez@...>
 

Hi all,

 

I have changed our deliverable and task name: CSIT OSGi -> CIT Java. This is because: 1) I think “Java” is more global than “OSGi” and we are actually helping projects (thanks Moiz) on writing all kind of Java tests (JUnit, PAX-EXAM, etc…). 2) “CIT” (or Continuous Integration Test) is because all these Java tests are executed in the projects whenever they build their code, however this is not the case for release integration. This week we learned (thanks Ed) there is no Java tests invoked when we build a release vehicle, therefore I do not see the point of calling the Java test a System Test “CSIT”.

 

The Continuous System Integration Test (CSIT) will be the one the release vehicles will pass using the new test framework and tools Carol and other collaborators are working on.

 

Does this make sense to you?

 

BR/Luis