Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [kapua-dev] [Design Note] Kapua Directory Layout

While not being an ordered list of each single commit, you can still navigate through all changes/commit on a specific file with the side panel in the blame view.

 

- Alberto

 

From: <kapua-dev-bounces@xxxxxxxxxxx> on behalf of Jens Reimann <jreimann@xxxxxxxxxx>
Reply-To: kapua developer discussions <kapua-dev@xxxxxxxxxxx>
Date: Tuesday, August 22, 2017 at 10:00 AM
To: kapua developer discussions <kapua-dev@xxxxxxxxxxx>
Subject: Re: [kapua-dev] [Design Note] Kapua Directory Layout

 

But in the "blame" tab you don't see the actual history, right? You only see the most recent state and when it got introduced.

 

On Mon, Aug 21, 2017 at 4:25 PM, Carrer, Marco <marco.carrer@xxxxxxxxxxxx> wrote:

All,

follow-ups based on what discussed in the call today, 

 

I think it would really help making a full layout, and maybe analyzing the dependencies between the modules. 

The mapping spreadsheet and the document have been updated with the full mapping.

https://docs.google.com/spreadsheets/d/1huvCSK3Fe0lSKri1XXsRY_sOB7qE4KdZpfwk18Ngufc/edit#gid=1676801248

 

 

1) I am not really convinced that the current layout is that flawed to justify a full re-structuring, restructuring effectively means loosing the history on GitHub.

 

My understanding is that as long as we move the files with no rename, git history can be preserved.

 

 

I was more referring to GitHub, not git. Git itself can do this, but we are hosting Kapua on GitHub, and GitHub doesn't support this. Please see: https://stackoverflow.com/a/5647721/222044

 

After a "git mv", GitHub does not show the full git history under the History tab, but all commits are still visible under the “Blame” tab.

The full history after a move is still visible through EGit in Eclipse, IntelliJ, and git at the command line prompt.

That seems to be an acceptable compromise.

 

As I do know that the "registration-simple" module actually requires to import various "internal" project due to the lack of the "Domain" objects on the API.

That’s a good point. Service-specifc Domain objects should be returned by the KapuaEntityFactories so these dependencies can be removed.

A GitHub Issue on this is being added.

 

-) Why would "assembly" be located under "utils"? Shouldn't that be "apps”?

Latest mapping proposal takes this suggestion in consideration.



-) I also think that external content (swagger) should stay under some "external” label

Latest mapping proposal takes this suggestion in consideration.

 

-) The spreadsheet simply lists "service/datastore", but the actual layout is more complex:
datastore/
  api/
  client/
  client-api/
  client-embedded/
  client-rest/
  client-transport/
  internal/

Latest mapping proposal addressed this.

 

-) Why would "security-shiro" go under "services", as it is being used by multiple projects as well?

shiro is the implementation of the auth service module.

It should not be used by projects outside of the auth service module.

 

Regards,

-Marco



Marco Carrer | CTO | EUROTECH | direct +39 0433 485 427 | mobile +39 346 4753123

 

 



 

On Aug 21, 2017, at 10:54 AM, Jens Reimann <jreimann@xxxxxxxxxx> wrote:

 

 

On Mon, Aug 21, 2017 at 10:29 AM, Carrer, Marco <marco.carrer@xxxxxxxxxxxx> wrote:

Hi Jens,

    comments inline below.

 

On Aug 21, 2017, at 9:25 AM, Jens Reimann <jreimann@xxxxxxxxxx> wrote:

 

Hello Marco,

thanks for migrating this to the google document. I guess for some high level topics the mailing list still is better.

1) I am not really convinced that the current layout is that flawed to justify a full re-structuring, restructuring effectively means loosing the history on GitHub.

 

My understanding is that as long as we move the files with no rename, git history can be preserved.

 

 

I was more referring to GitHub, not git. Git itself can do this, but we are hosting Kapua on GitHub, and GitHub doesn't support this. Please see: https://stackoverflow.com/a/5647721/222044

 



2) I couldn't find any explanation of my previous point #2 in the introduction, maybe you I overlooked it and you can point me towards it. Because from what I understood the grouping will be based on the deployment bundles (microservices) and that may change in the future.

 

Here is the paragraph on this topic in the document:

• The current Kapua architecture has 8 service modules identified. The proposal is to start with those directories. If more service modules are added in the future or existing service modules are further decomposed, new directories will be added. For the Kapua 1.0 release, the output of the projects under this directory is service jar files that are packaged into the distribution of the Kapua apps. For future Kapua releases, the output of the projects under this directory can evolve to a Docker image for the micro-service associated with the service module.

 

But this means that we again have to restructure and rename directories and that we would loose the history, right?. I am not sure this is a good approach for long term.

 



3) Looking at "Service Directory Proposed Layout" and "Example Service Directory Proposed Layout" it looks to me as if the proposed layout doesn't really work. At least in the example there are more exceptions than standard cases.

 

I saw your comments on the auth service.

In general, each directory under services is a service module. 

A service module is the bounded context of the microservice so it can have more service endpoints if necessary.



 

I would suggest to do a full breakdown (mapping table), from old to new, so that we can understand what the proposal actually is. Because right now I don't see how modules (like broker-core, dev-tools, sso, transport, …) would be match the proposed ruleset. I guess actually doing this in a spreadsheet might clear up a few questions.

 

The bullet list in the document is an attempt for the new map; broker-core is under apps, dev-tools under util, transport under libraries. 

I misses sso which should be under libraries if used by multiple services. 

 

I reformat it into a spreadsheet as suggested.

 

At least to me that spreadsheet caused more confusion. I am sorry for that, but I think making a full/complete mapping (excluding actual content directories like "src") would really help:

-) Why would "assembly" be located under "utils"? Shouldn't that be "apps"?

-) I also think that external content (swagger) should stay under some "external" label

-) The spreadsheet simply lists "service/datastore", but the actual layout is more complex:
datastore/
  api/
  client/
  client-api/
  client-embedded/
  client-rest/
  client-transport/
  internal/

-) Why would "security-shiro" go under "services", as it is being used by multiple projects as well?

I think it would really help making a full layout, and maybe analyzing the dependencies between the modules. As I do know that the "registration-simple" module actually requires to import various "internal" project due to the lack of the "Domain" objects on the API.

Cheers

Jens

 

 

Thanks

-Marco

 



 

Cheers

Jens

 

On Fri, Aug 18, 2017 at 6:44 PM, Carrer, Marco <marco.carrer@xxxxxxxxxxxx> wrote:

Jens,

    thanks for the comments.

 

I moved the wiki page to a pubic google document available for comments here:

 

I also expanded in the introduction addressing your questions.

 

Comments are welcome.

 

Ciao

-Marco

 



Hi,

I am not sure the Wiki is a good place for working on a design like that. There is no real way do amend or comment on GitHub wiki pages.

So I would like to understand two things here:

1) What is the benefit of re-organizing this?

2) What will happen if we decide in the future that the split up services in a different way?

Cheers

Jens


-- 

Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286



Marco Carrer | CTO | EUROTECH | direct +39 0433 485 427 | mobile +39 346 4753123

 

 



 


_______________________________________________
kapua-dev mailing list
kapua-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/kapua-dev




-- 

Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill

_______________________________________________
kapua-dev mailing list
kapua-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/kapua-dev

 


_______________________________________________
kapua-dev mailing list
kapua-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/kapua-dev




-- 

Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill

_______________________________________________
kapua-dev mailing list
kapua-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/kapua-dev

 


_______________________________________________
kapua-dev mailing list
kapua-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/kapua-dev




--

Jens Reimann
Senior Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill

Back to the top