I'm a NOOB to ODL.
I downloaded ODL Magnesium and able to run karaf.
I downloaded DLUX from the mirror (https://github.com/opendaylight/dlux) and it built successfully.
I'd like to install odl-dlux-core, but the dlux/distribution-dlux folder does not exist?
Thoughts?
I manually copied the associated SNAPSHOT files to the system/org folder and was able to install dlux.
opendaylight-user#root>feature:list | grep dlux
features-dlux │ 1.0.0.SNAPSHOT │ x │ Started │ features-dlux │ features-dlux
odl-dlux-core │ 1.0.0.SNAPSHOT │ x │ Started │ odl-dlux-1.0.0-SNAPSHOT │ Opendaylight dlux minimal feature
Now, when I navigate to http://localhost:8181/index.html, I get dark gray blank page. After inspection, I'd getting a 404 for
http://localhost:8181/src/common/authentification/auth.module.js
I am in fact missing a bunch of files;
topbar.module.js
common.general.module.js
core.module.js
navigation.module.js
login.module.js
layout.module.js
I'll investigate further as to where these archives should be avail.
Any advice is appreciated.
thanks
After restarting ODL, I am now able to load the mentioned resources. However, my localhost:8181/index.html serves up a blank page and redirects to localhost:8181/index.html#/topology. I'm wondering if I need to install odl-dlux-topology?
Related
I have got a tree structure like this :
upperfolder
│
└───1
│ │ output_v1.xml
│ │ output_v2.xml
│
└───2
│ │ output_v1.xml
│
└───3
and i would like to goes to this :
upperfolder
│
└───1
│ │ output_v1.xml
│ │ output_v2.xml
│ │ output_v3.xml
│
└───2
│ │ output_v1.xml
│ │ output_v2.xml
│
└───3
│ │ output_v1.xml
I use a makefile to do this and it looks like this :
./upperfolder/%:
--- here i would like to grab the last version of each folder % , incremente it and ---
--- compute next version name file to put it in parameters of my python script ---
python3 writer.py <previous_version_path_script> $#_v?.xml
all: ./upperfolder/1/output ./upperfolder/2/output ./upperfolder/3/output ./upperfolder/4/output
Indeed my python script need 2 entries :
1) The path of previous version xml file
2) The path of new version xml file
I tried to eval variables fetching the last char of pwd of target (that is the number of folder since we can't grab the % value in target (grrrrrrrrrr)) like this :
$(eval number := $(shell basename $#))
But i'm not really satisfied because let's imagine the folder name is not a simple number but something+number, i would need to fetch the last char of it. So i'm pretty sure there exists a better way to do it. Concerning the last version of each folder, to be honest i don't have any idea how i could do it.
Help or ints would be really appreciated
You shouldn't use make to do this.
Makefiles require that you know what the final thing you want to build is. That final file is the target that make will try to build: it starts with that target and works backward find the things needed to build it. It can visualize what kinds of things you might need to build a given target, but you have to give it a target: it can't visualize forward from an existing file to some new file that it doesn't know about.
In your case you can't write down in your makefile what the final targets you want to build are, because they aren't static: the name of final target depends on the existing files.
Also, make's entire reason for existing is to avoid updating files if they already exist and are up to date. In your case you always want to create a new file, so it's not of any use to use make to try to avoid building something.
You would have to write a script that figures out what the current version is, then generates a new version from that. At that point it seems useless to even involve make: just have your script run the python command to generate the file.
In short, make is simply the wrong tool for the job you want to do.
In my maven application i have multiple projects:
Core
Application 1
Application 2
Application 1 and Application 2 are two projects that uses the core (for example, those application are built for two different customers)
In order to Dockerize all of them, the simplest way would be to create a multi-module project, but the downside is that i have all inside a single project (core + Application 1 + Application 2).
I would like to have the core separated from them.
The main problem with this configuration is that the core project need to built before the other two, and App 1 and App 2 use this as maven dependency:
App 1
<dependency>
<groupId>it.myorg</groupId>
<artifactId>core-project</artifactId>
<version>1.12.0-SNAPSHOT</version>
</dependency>
If i try to dockerize the App 1 its fail when i package it, because inside the docker container core-project 1.12.0-SNAPSHOT do not exists.
I was thinking to setup a "local maven repo", pushing the core there and App 1 will "pull" the jar from the repo and not from .m2 folder, but i dont like this soulution.
I can provide more information, sorry if i dont provide examples, but my paper is white right now :(
Folder structure
+- Core
--- pom.xml
--- src
+- Application1
--- pom.xml
--- src
The solution i'm trying to do now is create a Dockerfile for core project (FROM maven:latest), building the image with a tag and in Dockerfile of App1 use this image (so, creating a multi stage build but in two separate moments).
The best would be
FROM maven:latest as core-builder
## build the core
FROM maven:latest
## Copy jar from builder
Because the project are in separate folder, i cant build the core in this way. I need to build del core BEFORE (running docker build -t) and later copy from them.
UPDATE
After the correct answer from #mihai i'm asking if its possible a structure like this:
-- myapp-docker
- Dockerfile
- docker-compose.yml
-- core-app
-- application_1
Having Dockerfile at the same level of core-app and application_1 its totally fine and 100% working. The only "problem" is that i should put all the projects in the same repo.
This is the proposed solution with multi-stage builds.
To replicate your setup I created this structure:
.
├── Dockerfile-app1
├── application1
│ ├── pom.xml
│ └── src
│ └── main
│ ├── resources
│ └── webapp
│ ├── WEB-INF
│ │ └── web.xml
│ └── index.jsp
├── core
│ ├── pom.xml
│ └── src
│ ├── main
│ │ └── java
│ │ └── com
│ │ └── test
│ │ └── App.java
│ └── test
│ └── java
│ └── com
│ └── test
│ └── AppTest.java
In the pom.xml file from Application 1 I added the dependency to core:
<dependency>
<groupId>com.test</groupId>
<artifactId>core</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
I named the Dockerfile Dockerfile-app1, this way you can have more than 1 of them.
This is the Dockerfile-app1:
FROM maven:3.6.0-jdk-8 as build
WORKDIR /apps
COPY ./core .
RUN mvn clean install
FROM maven:3.6.0-jdk-8
# If you comment this out then the build fails because it cannot find the dependency to 'core'
COPY --from=build /root/.m2 /root/.m2
COPY ./application1 ./
RUN mvn clean install
You should probably add an entrypoint at the end to run your project or even better add another 3rd stage that only copies the generated artefacts and runs your project (this way the final image will not have your sourced in).
The first stage only builds the core submodule.
The second stage used the results of the first stage, copies only the source for application1 and builds it.
You can easily replicate this for application2 by creating a similar file Dockerfile-app2.
Since you're using maven, try dockerfile-maven to build the image. You don't want any of your build information inside of your image (like what the dependencies are), you should just add the jar at the end. I usually use it together with spring-boot-maven-plugin and repackage, to get a fully self-contained jar.
This question already has answers here:
How to use a module that is outside of "GOPATH" in another module?
(2 answers)
Closed 4 years ago.
I'm building an application using a 'Micro Service' architecture.
This means that I have different applications.
The truth is that some logic is in a 'shared' library.
See the following directory structure:
ROOT/
├── Service 1/
│ ├── src
│ ├──── app.go
├── Service 2/
│ ├── src
│ ├──── app.go
└── Lib/
├── Lib 1
│ ├── src
│ ├──── app.go
Service 1, Service 2, and Lib 1, are all initialized with the go mod command.
For Service 1, this resulted in a go.mod file with the following contents.
module github.com/kevin-de-coninck/datalytics/services/serviceOne
For Service 2, this resulted in a go.mod file with the following contents.
module github.com/kevin-de-coninck/datalytics/services/serviceTwo
For Lib 1, this resulted in a go.mod file with the following contents.
module github.com/kevin-de-coninck/datalytics/lib/libOne
The import statements of Service 1 contains a reference to the Lib 1
import (
"github.com/kevin-de-coninck/datalytics/lib/libOne"
)
However, when I try to build the application, the following output is showed:
go: finding github.com/kevin-de-coninck/datalytics/lib/libOne latest
go: finding github.com/kevin-de-coninck/datalytics/lib latest
go: finding github.com/kevin-de-coninck/datalytics latest
build github.com/kevin-de-coninck/datalytics/services/serviceOne/src:
cannot find module for path github.com/kevin-de-coninck/datalytics/lib/libOne
How can I resolve this issue so that i can use my LibOne package without making it public or whithout copying it across all the services?
Kind regards
After some fiddling around, I have found my answer.
It seems that the 'go.mod' and 'go.sum' file(s) should be placed in the 'src' directory.
After doing that, the application can be build and executed.
I'm writing a library package which depends on certain imports but I'm not sure how to handle it correctly.
Let me start with the directory structure:
go/src/github.com/
├── developer A/
│ ├── project 1
│ └── project 2
│
└── developer B/
└── project 3
└── vendor
└── project 4
Project 1 is a library. It is used in project 2 and gets pulled into 2s vendor folder. Therefore, project 1 should contain all its dependencies such that clients (e.g. project 2) don't need to pull them as well. However, one dependency of project 1 is project 4 which is contained in project 3s vendor folder. It is essential that this dependency is always exactly the version vendored by project 3. Go doesn't allow imports to point to packages inside vendor folders, so I can't import it directly from there. How do I solve this with govendor?
Go won't let you reach into another project's vendor directory. It sounds like your intention is to ensure versions. This is what go modules are tasked to do. Take a look at the wiki for more information.
I was quite surprised that I couldn't find this anywhere, but anyways, I would like to know the purpose of each folder in the .gradle folder, and how safe it is to delete them, especially in terms of portability.
I know that I need the caches folder, since it contains the
downloaded dependencies.
The daemon folder seems to only contain
logs?
workers is apparently empty for me
wrapper seems irrelevant, since I don't use gradle wrapper. Why does it even download all those wrappers?
No idea about native.
Directory layout is described in "The Directories and Files Gradle Uses" chapter of its user guide.
├── caches // <1>
│ ├── 4.8 // <2>
│ ├── 4.9 // <2>
│ ├── ⋮
│ ├── jars-3 // <3>
│ └── modules-2 // <3>
├── daemon // <4>
│ ├── ⋮
│ ├── 4.8
│ └── 4.9
├── init.d // <5>
│ └── my-setup.gradle
├── wrapper
│ └── dists // <6>
│ ├── ⋮
│ ├── gradle-4.8-bin
│ ├── gradle-4.9-all
│ └── gradle-4.9-bin
└── gradle.properties // <7>
Global cache directory (for everything that's not project-specific)
Version-specific caches (e.g. to support incremental builds)
Shared caches (e.g. for artifacts of dependencies)
Registry and logs of the Gradle Daemon
Global initialization scripts
Distributions downloaded by the Gradle Wrapper
Global Gradle configuration properties
From version 4.10 onwards, Gradle automatically cleans its user home directory. The cleanup runs in the background when the Gradle daemon is stopped or shuts down. If using --no-daemon, it runs in the foreground after the build session with a visual progress indicator.
The following cleanup strategies are applied periodically (at most every 24 hours):
Version-specific caches in caches/<gradle-version>/ are checked for whether they are still in use. If not, directories for release versions are deleted after 30 days of inactivity, snapshot versions after 7 days of inactivity.
Shared caches in caches/ (e.g. jars-*) are checked for whether they are still in use. If there's no Gradle version that still uses them, they are deleted.
Files in shared caches used by the current Gradle version in caches/ (e.g. jars-3 or modules-2) are checked for when they were last accessed. Depending on whether the file can be recreated locally or would have to be downloaded from a remote repository again, it will be deleted after 7 or 30 days of not being accessed, respectively.
Gradle distributions in wrapper/dists/ are checked for whether they are still in use, i.e. whether there's a corresponding version-specific cache directory. Unused distributions are deleted.
native seem to contain platform-specific dependencies (like .so, .dll) for libraries like Jansi: it needs them to provide rich console output (like colours in the output). The code for that features is not documented, but you can take a look here. Particularly library.jansi.path system property points to ~/.gradle/native/jansi/1.17.1/linux64 (on my machine; you can check that by printing System.getProperties() in a custom Gradle task).
workers seems to be used as a working directory for the workers described in Workers API.
wrappers could be downloaded by the IDE. Basically, if you have this directory non-empty that means that you've actually used a wrapper at least once.