Date   

Integration new committers

Luis Gomez <luis.gomez@...>
 

OK people, you heard Andrew, have any of you any objection on adding Moiz and Huang to the list of committers for Integration project?

Thanks
Luis


Re: Integration new committers

Liguangpeng (Roc, IPTechnologyResearchDept&HW) <guangpeng.li@...>
 

+1 for adding them.

-----Original Message-----
From: Luis Gomez [mailto:luis.gomez@...]
Sent: Friday, September 27, 2013 8:34 AM
To: Ed Warnicke; Carol Sanders; Swaraj Vinjapuri; Punal Patel; Liguangpeng
(Roc, IPTechnologyResearchDept&HW); Baohua Yang; Moiz Raja (moraja)
(moraja@...); huang denghui
Cc: integration-dev@...
Subject: Integration new committers

OK people, you heard Andrew, have any of you any objection on adding Moiz
and Huang to the list of committers for Integration project?

Thanks
Luis


Re: Integration new committers

Baohua Yang <yangbaohua@...>
 

+1!


On Fri, Sep 27, 2013 at 11:03 AM, Liguangpeng (Roc, IPTechnologyResearchDept&HW) <guangpeng.li@...> wrote:
+1 for adding them.

> -----Original Message-----
> From: Luis Gomez [mailto:luis.gomez@...]
> Sent: Friday, September 27, 2013 8:34 AM
> To: Ed Warnicke; Carol Sanders; Swaraj Vinjapuri; Punal Patel; Liguangpeng
> (Roc, IPTechnologyResearchDept&HW); Baohua Yang; Moiz Raja (moraja)
> (moraja@...); huang denghui
> Cc: integration-dev@...
> Subject: Integration new committers
>
> OK people, you heard Andrew, have any of you any objection on adding Moiz
> and Huang to the list of committers for Integration project?
>
> Thanks
> Luis



--
Best wishes!
Baohua


Re: Integration new committers

Carol Sanders <carol.sanders@...>
 

No objections.

-----Original Message-----
From: Luis Gomez [mailto:luis.gomez@...]
Sent: Thursday, September 26, 2013 05:34 PM
To: Ed Warnicke; Carol Sanders; Swaraj Vinjapuri; Punal Patel; Guangpeng Li; Baohua Yang; Moiz Raja (moraja) (moraja@...); huang denghui
Cc: integration-dev@...
Subject: Integration new committers

OK people, you heard Andrew, have any of you any objection on adding Moiz and Huang to the list of committers for Integration project?

Thanks
Luis


Re: Integration new committers

Punal Patel <Punal.Patel@...>
 

No objections.

-----Original Message-----
From: Carol Sanders [mailto:carol.sanders@...]
Sent: September-26-13 11:09 PM
To: Luis Gomez; Ed Warnicke; Swaraj Vinjapuri; Punal Patel; Guangpeng Li; Baohua Yang; Moiz Raja (moraja) (moraja@...); huang denghui
Cc: integration-dev@...
Subject: RE: Integration new committers

No objections.

-----Original Message-----
From: Luis Gomez [mailto:luis.gomez@...]
Sent: Thursday, September 26, 2013 05:34 PM
To: Ed Warnicke; Carol Sanders; Swaraj Vinjapuri; Punal Patel; Guangpeng Li; Baohua Yang; Moiz Raja (moraja) (moraja@...); huang denghui
Cc: integration-dev@...
Subject: Integration new committers

OK people, you heard Andrew, have any of you any objection on adding Moiz and Huang to the list of committers for Integration project?

Thanks
Luis

Legal Disclaimer:
The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message!


Re: Integration new committers

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

+1

Ed

On Sep 26, 2013, at 7:34 PM, Luis Gomez <luis.gomez@...> wrote:

OK people, you heard Andrew, have any of you any objection on adding Moiz and Huang to the list of committers for Integration project?

Thanks
Luis


Re: Integration new committers

Swaraj Vinjapuri
 

+1 for both.

Great additions.

Regards,
Swaraj

> From: luis.gomez@...
> To: eaw@...; carol.sanders@...; swarajv@...; punal.patel@...; guangpeng.li@...; yangbaohua@...; moraja@...; huangdenghui@...
> CC: integration-dev@...
> Subject: Integration new committers
> Date: Fri, 27 Sep 2013 00:34:12 +0000
>
> OK people, you heard Andrew, have any of you any objection on adding Moiz and Huang to the list of committers for Integration project?
>
> Thanks
> Luis


Testing tools VMs

Andrew Grimberg
 

Greetings folks,

So last week there was a request for new VMs for doing black box
testing.

I understand we're talking about 5 systems. What I've seen is the
following:

VM1: Test management tools
VM2: REST/GUI test generator
VM3: ODL controller
VM4: OF simulator
VM5: Netconf simulator

I've got a few questions about how these are suppposed to be used.

1) How are you expecting to deploy code to these systems?

2) What sort of interface to the systems is being requested?

3) How much space is expected to be needed on the systems as well as the
amount of RAM?

4) What is expected to be put on each of the systems. I can sort of
figure it out a little bit from the descriptions above, but having it
nailed down more will help. I'm assuming I'll need java on all of them
but outside of that I don't know what specifically will be needed.

5) What network ports am I going to need to open on the devices?

-Andy-

--
Andrew J Grimberg
Systems Administrator
The Linux Foundation


Re: Testing tools VMs

Luis Gomez <luis.gomez@...>
 

Hi Andrew, I will discuss your questions more in detail with Carol but so far this is my idea for the VMs networking:

1) IP interfaces:
The VMs need 1 IP interface that can be used for both: operation of the VM and traffic to other VMs

2) Internal Access:
All VMs must see each other, i.e. be in the same subnet or at least routable among them. They also should see the other servers of ODL for integration with Jenkins, etc...

3) Access to Internet:
It would be good if all VMs have access to Internet so that we can download test packages, upgrade the ODL controller code, etc... If not you can always provision an internal repository with all that is required.

4) Access from Internet for operation (ssh):
A few people (2/3) in the integration team might need to operate the VMs. I am not sure how you do in Linux Foundation: the VMs may be directly reachable if they have public IPs, or we could use a Jump server with public IP (like we do in our Lab in Ericsson) and once we authenticate there we get access to the VMs.

5) General access from Internet, I see 2 scenarios:
- For programming the TCs: I do not see a need (at least in the beginning) because we are very few people doing this now (2/3) but maybe if there is a secure way to access the programming interface, we can open it to Internet
- For reporting: I believe some test tools may generate some web based reports that would useful to access from Internet.

Other integration members, any comments or thoughts about the test environment for ODL...

Thanks/Luis

-----Original Message-----
From: integration-dev-bounces@... [mailto:integration-dev-bounces@...] On Behalf Of Andrew Grimberg
Sent: Monday, September 30, 2013 10:36 AM
To: integration-dev@...
Subject: [integration-dev] Testing tools VMs

Greetings folks,

So last week there was a request for new VMs for doing black box
testing.

I understand we're talking about 5 systems. What I've seen is the
following:

VM1: Test management tools
VM2: REST/GUI test generator
VM3: ODL controller
VM4: OF simulator
VM5: Netconf simulator

I've got a few questions about how these are suppposed to be used.

1) How are you expecting to deploy code to these systems?

2) What sort of interface to the systems is being requested?

3) How much space is expected to be needed on the systems as well as the
amount of RAM?

4) What is expected to be put on each of the systems. I can sort of
figure it out a little bit from the descriptions above, but having it
nailed down more will help. I'm assuming I'll need java on all of them
but outside of that I don't know what specifically will be needed.

5) What network ports am I going to need to open on the devices?

-Andy-

--
Andrew J Grimberg
Systems Administrator
The Linux Foundation


Re: Testing tools VMs

Carol Sanders <carol.sanders@...>
 

I agree with all items mentioned with additional consideration: I like to have a separate management interface on each VM than what I'm using for test traffic. Is it possible to have two or three interfaces per VM so that we can keep traffic separate?

Thanks,

Carol

-----Original Message-----
From: integration-dev-bounces@... [mailto:integration-dev-bounces@...] On Behalf Of Luis Gomez
Sent: Monday, September 30, 2013 11:39 AM
To: Andrew Grimberg; integration-dev@...
Subject: Re: [integration-dev] Testing tools VMs

Hi Andrew, I will discuss your questions more in detail with Carol but so far this is my idea for the VMs networking:

1) IP interfaces:
The VMs need 1 IP interface that can be used for both: operation of the VM and traffic to other VMs

2) Internal Access:
All VMs must see each other, i.e. be in the same subnet or at least routable among them. They also should see the other servers of ODL for integration with Jenkins, etc...

3) Access to Internet:
It would be good if all VMs have access to Internet so that we can download test packages, upgrade the ODL controller code, etc... If not you can always provision an internal repository with all that is required.

4) Access from Internet for operation (ssh):
A few people (2/3) in the integration team might need to operate the VMs. I am not sure how you do in Linux Foundation: the VMs may be directly reachable if they have public IPs, or we could use a Jump server with public IP (like we do in our Lab in Ericsson) and once we authenticate there we get access to the VMs.

5) General access from Internet, I see 2 scenarios:
- For programming the TCs: I do not see a need (at least in the beginning) because we are very few people doing this now (2/3) but maybe if there is a secure way to access the programming interface, we can open it to Internet
- For reporting: I believe some test tools may generate some web based reports that would useful to access from Internet.

Other integration members, any comments or thoughts about the test environment for ODL...

Thanks/Luis


-----Original Message-----
From: integration-dev-bounces@... [mailto:integration-dev-bounces@...] On Behalf Of Andrew Grimberg
Sent: Monday, September 30, 2013 10:36 AM
To: integration-dev@...
Subject: [integration-dev] Testing tools VMs

Greetings folks,

So last week there was a request for new VMs for doing black box testing.

I understand we're talking about 5 systems. What I've seen is the
following:

VM1: Test management tools
VM2: REST/GUI test generator
VM3: ODL controller
VM4: OF simulator
VM5: Netconf simulator

I've got a few questions about how these are suppposed to be used.

1) How are you expecting to deploy code to these systems?

2) What sort of interface to the systems is being requested?

3) How much space is expected to be needed on the systems as well as the amount of RAM?

4) What is expected to be put on each of the systems. I can sort of figure it out a little bit from the descriptions above, but having it nailed down more will help. I'm assuming I'll need java on all of them but outside of that I don't know what specifically will be needed.

5) What network ports am I going to need to open on the devices?

-Andy-

--
Andrew J Grimberg
Systems Administrator
The Linux Foundation
_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev


Re: Testing tools VMs

Luis Gomez <luis.gomez@...>
 

Hi Carol,

That makes sense to me too, so we can have 2 interfaces per VM:

- Test traffic interface: to connect to other test VM. This is on a private subnet shared only by the VMs and does not need default gw.
- Operation interface: default interface to connect to everything else. This could be on private or public subnet and requires default gw.

BR/Luis

-----Original Message-----
From: Carol Sanders [mailto:carol.sanders@...]
Sent: Monday, September 30, 2013 12:11 PM
To: Luis Gomez; Andrew Grimberg; integration-dev@...
Subject: RE: [integration-dev] Testing tools VMs

I agree with all items mentioned with additional consideration: I like to have a separate management interface on each VM than what I'm using for test traffic. Is it possible to have two or three interfaces per VM so that we can keep traffic separate?

Thanks,

Carol

-----Original Message-----
From: integration-dev-bounces@... [mailto:integration-dev-bounces@...] On Behalf Of Luis Gomez
Sent: Monday, September 30, 2013 11:39 AM
To: Andrew Grimberg; integration-dev@...
Subject: Re: [integration-dev] Testing tools VMs

Hi Andrew, I will discuss your questions more in detail with Carol but so far this is my idea for the VMs networking:

1) IP interfaces:
The VMs need 1 IP interface that can be used for both: operation of the VM and traffic to other VMs

2) Internal Access:
All VMs must see each other, i.e. be in the same subnet or at least routable among them. They also should see the other servers of ODL for integration with Jenkins, etc...

3) Access to Internet:
It would be good if all VMs have access to Internet so that we can download test packages, upgrade the ODL controller code, etc... If not you can always provision an internal repository with all that is required.

4) Access from Internet for operation (ssh):
A few people (2/3) in the integration team might need to operate the VMs. I am not sure how you do in Linux Foundation: the VMs may be directly reachable if they have public IPs, or we could use a Jump server with public IP (like we do in our Lab in Ericsson) and once we authenticate there we get access to the VMs.

5) General access from Internet, I see 2 scenarios:
- For programming the TCs: I do not see a need (at least in the beginning) because we are very few people doing this now (2/3) but maybe if there is a secure way to access the programming interface, we can open it to Internet
- For reporting: I believe some test tools may generate some web based reports that would useful to access from Internet.

Other integration members, any comments or thoughts about the test environment for ODL...

Thanks/Luis


-----Original Message-----
From: integration-dev-bounces@... [mailto:integration-dev-bounces@...] On Behalf Of Andrew Grimberg
Sent: Monday, September 30, 2013 10:36 AM
To: integration-dev@...
Subject: [integration-dev] Testing tools VMs

Greetings folks,

So last week there was a request for new VMs for doing black box testing.

I understand we're talking about 5 systems. What I've seen is the
following:

VM1: Test management tools
VM2: REST/GUI test generator
VM3: ODL controller
VM4: OF simulator
VM5: Netconf simulator

I've got a few questions about how these are suppposed to be used.

1) How are you expecting to deploy code to these systems?

2) What sort of interface to the systems is being requested?

3) How much space is expected to be needed on the systems as well as the amount of RAM?

4) What is expected to be put on each of the systems. I can sort of figure it out a little bit from the descriptions above, but having it nailed down more will help. I'm assuming I'll need java on all of them but outside of that I don't know what specifically will be needed.

5) What network ports am I going to need to open on the devices?

-Andy-

--
Andrew J Grimberg
Systems Administrator
The Linux Foundation
_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev


TestON

Luis Gomez <luis.gomez@...>
 

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


Status on integration repo distribution directories

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

Guys,
I had promised distributions for the editions in integration by Monday. I hit some road bumps
around artifacts being available in nexus (which I'm working with projects to fix).
Or to put it differently: I uncovered bugs, I'm getting them fixed :)
Hope to get the distribution directories pushed out today :)

Ed


Re: TestON

Carol Sanders <carol.sanders@...>
 

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


Re: Status on integration repo distribution directories

Luis Gomez <luis.gomez@...>
 

Thanks very much Ed.

-----Original Message-----
From: integration-dev-bounces@... [mailto:integration-dev-bounces@...] On Behalf Of Ed Warnicke (eaw)
Sent: Tuesday, October 01, 2013 8:00 AM
To: integration-dev@...
Subject: [integration-dev] Status on integration repo distribution directories

Guys,
I had promised distributions for the editions in integration by Monday. I hit some road bumps
around artifacts being available in nexus (which I'm working with projects to fix).
Or to put it differently: I uncovered bugs, I'm getting them fixed :)
Hope to get the distribution directories pushed out today :)

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


Re: TestON

Swaraj Vinjapuri
 

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: TestON

Carol Sanders <carol.sanders@...>
 

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


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

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

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-SNAPSHOT: 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-maven-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


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

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

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-SNAPSHOT: 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-maven-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


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

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

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