Errors sharing BND workspace to Github

[Rubén Pérez Vázquez]

Hi all,

I was trying to upload my BND workspace to Github for the first time and I get multiple errors.

The workspace was created using the provided templates, so it already has multiple git-related files, such as .gitignore, .gitattributes and so on. The reason is that Eclipse's git plugin is expecting git resources to be inside projects, while Bndtools maps BND workspace to Eclipse workspace. In doing this, now Eclipse see files to commit to Git outside projects and complains about it (and rightly so, at least from its perspective). Is there any way to avoid these issues?

On the other hand, I was unable to "see" a BND workspace correctly without having it selected as the current Eclipse workspace at the same time. This is surprising because I have read some conversations in the bndtools repo issue tracker which seem to indicate that the intention was exactly the opposite --that the concepts of BND workspace and Eclipse workspace should be completely independent. However, in my experience they must be the same thing in practice, otherwise Bndtools gets confused.

To top it all, this confusion led me to making a mess with the configuration, and on trying to fix that I found yet another limitation: there is no option to import existing BND OSGI projects into the current workspace. It is possible, though, to create a new project and enter the name of an existing project, which will import it but completely clean its bnd.bnd

All in all, it looks that the support that Bndtools offers for BND workspace is somewhat incomplete or a work in progress.

I guess I've just written this to ask: are all those issues known and expected or am I doing something (or everything) completely wrong?

Thanks in advance for your answers.

Best regards

Rubén

[Fr Jeremy Krieg (Home)]

Dear Ruben,

I pray that you are well.

I don't have all of the answers, but here are a few:

1. It is definitely possible (indeed, preferable) to have your Bnd workspace in a different folder to your Eclipse workspace. I don't know exactly why you feel that this isn't working for you, nor what it is that you are seeing which causes you to say "Eclipse's git plugin is expecting git resources to be inside projects" - this isn't strictly true. It is true that you won't be able to see the root-level resources in Eclipse (and hence not able to commit them with EGit), but git on the command line will still know about them. Usually there aren't any files in the root folder that are of concern to Bndtools (they're usually Gradle files, which are for CI builds) so in practice I've rarely found this to be a concern. But I do vaguely recall that Buildship (I haven't used Buildship for a long time) does a similar trick where it creates a special project in the Eclipse workspace called "ROOT" which points to the root directory (but with subdirectories filtered out) so that these root-level are visible to Eclipse and can be edited in Eclipse, or even committed using EGit. Perhaps there is a case for Bndtools to offer a similar feature.

2. There is an option to import existing Bnd OSGi projects: First, make sure that your project is already in your Bnd workspace directory - if not, then manually copy it there using your OS commands/UI. Then go "Import...|General|Existing Projects into Workspace". Click "select root directory" and browse to your Bnd workspace directory. Make sure that you do not have "Copy projects into workspace" checked (this copies the project into your *Eclipse* workspace, which is not what you want if you have your Bnd workspace in a separate dir). You can also import the Bndtools "cnf" dir this way, which means you can import an entire Bndtools workspace this way.

3. I have always found the Bndtools-specific import for "Import Existing Bnd workspace" to be problematic. I can't remember why exactly - something to do with the circularity in a macro for setting the Javac compliance levels. Since I discovered 2, I've never really invested any time trying to figure out why. Arguably, we should look at fixing this as it can sour the experience for newcomers.

I hope that this helps. Let us know if you have any more questions.

Blessings,

Fr Jeremy

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/019d0511-2595-49ad-983c-563b044df514n%40googlegroups.com.

[Rubén Pérez Vázquez]

Dear Fr Jeremy,

As always, thanks for you kind and informative answer. Please let me add some remarks to your answers:

1. It may be possible, or perhaps it might have been possible to have a Bnd workspace in a subfolder of the Eclipse workspace (i.e. as an Eclipse project), but it does not seem to be the case anymore. As soon as one creates a new Bnd workspace, the Bndtools integration automatically switches Eclipse's current workspace to be the subfolder where the Bnd workspace was created. Indeed the files in the root of the Bnd workspace are mostly for configuring gradle and git -- which are the next steps in my little side project. Because now the Bnd workspace is also the current Eclipse workspace, as soon as I try to use EGit to push it to Github, I get errors in all these files. That does not mean that I cannot commit these files, but they appear as blank lines in EGit's "Git stating" view, and every time I do something with this files, I get this annoying popup error window telling me that there are errors in some files because their path does not include the project name (i.e. they are outside of a project, from Eclipse's perspective).
   
   On the other hand,  if I refuse to accept the automatic worspace switch that Bndtools does, I can of course switch back to the previous Eclipse workspace (File > Switch workspace), but of course I won't find my Bnd workspace there, because it was never imported (as a new project, for instance) into that Eclipse workspace.
   
   In short, the only way I could find to work with a Bnd workspace is that it is, at the same time, the current Eclipse workspace. Otherwise, it won't work (but it will cause all these errors when converting the workspace into a git project).
   
   
2. I will try that method and see if I can import the Bnd workspace as a project in a Eclipse workspace. I'll post my findings here. Anyway, it really seems like a hack more than a "sanctioned" way of importing Bnd projects. This goes with my earlier observation that the Bndtools integration seems incomplete or a work in progress or, at least, buggy.
   
   
3. The "Import existing Bnd workspace" is, indeed, problematic. Let me explain: let's say my Eclipse workspace is in C:\workspace and I create a new bnd workspace in C:\workspace\example. That will automatically change my current Eclipse workspace to be also C:\workspace\example, but at this point I am blissfully unaware of the problems that this will cause down the line and start to create new Bnd projects -- let's say C:\workspace\example\project1 and C:\workspace\example\project2 alongside the C:\workspace\example\cnf created by Bndtools. But after that I decide I want to work with my Bnd workspace without it being the Eclipse workspace. So I switch my Eclipse workspace back to C:\workspace and try to import the existing Bnd workspace using the "Import existing Bnd workspace" option. This will display an error popup:
   
   "'Import Bnd Workspace' has encountered a problem.
   Cound not finish import job for Bnd Workspace!
   
   , with no further details. In addition, two empty new folders will have been created in the workspace: C:\workspace\cnf and C:\workspace\project1. It seems that "Import existing Bnd workspace" tries to convert your current workspace into the workspace you are trying to import (but fortunately failing in the process). Interestingly enough, if I delete the C:\workspace\cnf and C:\workspace\project1 folders and try again, the process will fail with the same error message, but now the empty folders C:\workspace\cnf and C:\workspace\project2 will have been created, as if Eclipse remembered that it had already tried to import project1 or, perhaps, as if the import order is random.
   
   Bottom line is, the name "Import Bnd Workspace" is extremely misleading and it should be called "Convert the current workspace into an existing Bnd workspace", or something like that. It is definitely not what one is expecting when using that option.
   

Now, don't get me wrong. I like the OSGI model and I like many of the features that Bndtools offers, but the devil is in the details, and these details I've commented on here are certainly not a reason to abandon Bnd tools completely, but extremely annoying IMHO.

Thanks for bearing with my rant here and I hope someone finds it, at least, informative or useful.

Best regards,

Rubén

[Fr Jeremy Krieg (Home)]

Hi Rubén,

I'm sorry that you've had that experience. I remember having similar experiences in my early days of experience with Bndtools, so I sympathize. However, when I hit on a combination that worked I simply stuck with it and forgot about the options that didn't work. A couple more points:

1. I said in the previous email that you can simply use the general "Import|General|Existing projects", but I remembered in my workflow there's another trick I used to make this work - I manually create the .project and .classpath files if they do not already exist in the Bnd project before I try and import it into Eclipse. Usually I do this by copying it from another Bnd project and editing the .project file to change the name of the project (you have to edit it before importing; if you forget, then delete the project from the Eclipse WS, edit, and re-import the project). What's missing at the moment is a way for Bndtools to create these files for you automatically when you import a plain Bnd project.

2. I have my Bnd workspace in a completely different directory to the Eclipse workspace, and not as a subdirectory. So something like this:

C:\workspace\osgi-test (Bnd workspace)

C:\workspace\osgi-test-ws (Eclipse workspace)

They can even go in completely different directories, eg:

C:\git\osgi-test

C:\workspaces\osgi-test-ws

This seems to work well - if you do "New Bnd OSGi Project" it will create it in C:\git\osgi-test rather than if you do a regular "create project" (which puts the new project in the Eclipse WS by default).

3. I agree that the "Import Bnd workspace" functionality needs an overhaul. I don't use it at all, and I think that's part of the problem - most of the core team probably don't use it either so they aren't aware of the issues or simply content to use the workarounds. But Peter Kriens is doing some work in this area at the moment (https://github.com/bndtools/bnd/issues/4413) to make Bndtools automatically sync the Eclipse workspace with the Bnd workspace - once working, the Import Bnd workspace functionality might become redundant anyway (or at the very least be significantly modified).

Hope this helps!

Blessings,

Fr Jeremy

To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/7e56a2da-fbe8-4b67-9417-36472a1a3909n%40googlegroups.com.

[Peter Kriens]

On 23 Nov 2020, at 20:52, Rubén Pérez Vázquez <rube...@gmail.com> wrote:

Hi all,

I was trying to upload my BND workspace to Github for the first time and I get multiple errors.

The workspace was created using the provided templates, so it already has multiple git-related files, such as .gitignore, .gitattributes and so on. The reason is that Eclipse's git plugin is expecting git resources to be inside projects, while Bndtools maps BND workspace to Eclipse workspace. In doing this, now Eclipse see files to commit to Git outside projects and complains about it (and rightly so, at least from its perspective). Is there any way to avoid these issues?

The current best practice, at least in my mind, is to dedicate one single directory, that has:

   workspace/

.git/ marks it as the git workspace

.metadata/ marks it as an Eclipse workspace

settings.gradle marks it as a gradle root

cnf/ marks it as a bnd workspace

com.foo.example.bar/ project (= Symbolic Name)

bnd.bnd bnd project marker

.gitignore ignores .metadata, .gradle-wrapper and others

Did you read?

https://bndtools.org/concepts.html

https://bndtools.org/workspace/osgi

If yes, could you send me some comments what you think should be added?

On the other hand, I was unable to "see" a BND workspace correctly without having it selected as the current Eclipse workspace at the same time. This is surprising because I have read some conversations in the bndtools repo issue tracker which seem to indicate that the intention was exactly the opposite --that the concepts of BND workspace and Eclipse workspace should be completely independent. However, in my experience they must be the same thing in practice, otherwise Bndtools gets confused.

Git and bnd MUST overlap. However, unfortunately, Eclipse is designed to aggregate projects from all over the place. Its workspace is 'virtual'. The Eclipse workspace directory is only to host .metadata. Originally, we advised to keep them separate since EGit went bananas when the .metadata directory was in its view. However, that is fixed so since then I advise to let the git, bnd, and eclipse workspace be the exact same directory. 

For bnd, ALL projects MUST be in the same directory as the cnf directory. Since Eclipse spent significant effort on letting their projects reside everywhere you need to be aware of this. The worst problem is probably renaming and moving in Eclipse. In bnd, the project name IS the directory name IS the Bundle Symbolic Name. Eclipse went ballistic and allows you to have a different Eclipse project name than the directory name and it allows you to put that project anywhere. (I dislike that kind of design because it creates huge error spaces for imho very little benefit.) We have tried hard to make it impossible to create projects outside the bnd workspace directory when you use the Bndtools tooling. Once Bndtools sees a cnf project, its directory is the anchor for new Bndtools projects.

This basically means never use rename or move a project. If you really need to rename a project, delete the project from Eclipse without deleting it from disk. Rename the directory and edit the .project file since the project's name is redundantly in there, then reimport it in Eclipse.

To top it all, this confusion led me to making a mess with the configuration, and on trying to fix that I found yet another limitation: there is no option to import existing BND OSGI projects into the current workspace. It is possible, though, to create a new project and enter the name of an existing project, which will import it but completely clean its bnd.bnd

In general you can copy bnd projects to another workspace and import it.

All in all, it looks that the support that Bndtools offers for BND workspace is somewhat incomplete or a work in progress.

That is tad unfair I think. There are lots of people that use it daily with builds up to a thousand projects without any of these problems. It's a build like flying and driving a car. A car can be driven without any real knowledge of the internals but if you learn to fly the primary lesson is that the pilot needs to keep the plane in a surprisingly narrow envelope. Bndtools is more like a plane than a car. What I hear is that you've assumed it was a car and had lots of protections.

And the key problem in our industry is that we lost the normal moderation of money in our industry. As a consultant, I can setup the build of a company in a few days. In practice, I see people wasting months of their own time because nobody seems to make the tradeoff between their own cost and external expertise. And I know how hard it is. Generally management thinks that outside the salaries software should be free; they tend to hate requests for external expertise. Even training tend to be seen as a luxury nowadays. Ok, I stop ranting :-)

We'd like to make Bndtools more like a car than a  plane but it is an open source project. nobody pays for it. I've got a number of customers that use the Bndtools workspace intensively. I see many work around problems without reporting them, or better, providing a PR. With Github this is surprisingly little work but still most people go out of their way to not do share their experience but complain if they run in a shortcoming. Nobody makes any money on Bndtools, we've no sponsors except the hours from the people that work on it.

I guess I've just written this to ask: are all those issues known and expected or am I doing something (or everything) completely wrong?

In practice I find it very simple. The bnd project is a well maintained workspace this way. You can also look at https://github.com/aQute-os/biz.aQute.osgi.util. And again, I am sorry that the starter guide did not help.

Just have one directory with `cnf/build.bnd` and us this directory for Eclipse workspace (.metadata), Git workspace (.git) and make sure you setup your .gitignore correctly. Never use Move or Rename of a project.

Documentation is hard. If you have suggestions how we could've improved your experience, let me know.

Kind regards,

Peter Kriens

Thanks in advance for your answers.

Best regards

Rubén

[Peter Kriens]

On 24 Nov 2020, at 11:32, Rubén Pérez Vázquez <rube...@gmail.com> wrote:

Dear Fr Jeremy,

As always, thanks for you kind and informative answer. Please let me add some remarks to your answers:

1. It may be possible, or perhaps it might have been possible to have a Bnd workspace in a subfolder of the Eclipse workspace (i.e. as an Eclipse project), but it does not seem to be the case anymore. As soon as one creates a new Bnd workspace, the Bndtools integration automatically switches Eclipse's current workspace to be the subfolder where the Bnd workspace was created. Indeed the files in the root of the Bnd workspace are mostly for configuring gradle and git -- which are the next steps in my little side project. Because now the Bnd workspace is also the current Eclipse workspace, as soon as I try to use EGit to push it to Github, I get errors in all these files. That does not mean that I cannot commit these files, but they appear as blank lines in EGit's "Git stating" view, and every time I do something with this files, I get this annoying popup error window telling me that there are errors in some files because their path does not include the project name (i.e. they are outside of a project, from Eclipse's perspective).
   
   On the other hand,  if I refuse to accept the automatic worspace switch that Bndtools does, I can of course switch back to the previous Eclipse workspace (File > Switch workspace), but of course I won't find my Bnd workspace there, because it was never imported (as a new project, for instance) into that Eclipse workspace.
   
   In short, the only way I could find to work with a Bnd workspace is that it is, at the same time, the current Eclipse workspace. Otherwise, it won't work (but it will cause all these errors when converting the workspace into a git project).
   

As I said in my previous mails, the cnf directory defines the bnd workspace. You can place this anywhere. When you start a new Eclipse workspace anywhere, make sure you create the cnf directory in the directory you want. When you create a bnd workspace in Bndtools, it asks you where to place it.

1. 
   
2. I will try that method and see if I can import the Bnd workspace as a project in a Eclipse workspace. I'll post my findings here. Anyway, it really seems like a hack more than a "sanctioned" way of importing Bnd projects. This goes with my earlier observation that the Bndtools integration seems incomplete or a work in progress or, at least, buggy.
   

Nope, I think you're trying lots of things without having a good idea of the basic concepts as described here: https://bndtools.org/concepts.html ? As any sharp tool, it can hurt you. A simple mistake can then quickly get out of hand. Can we do better? Clearly but this is not a consumer tool.

2. 
   
3. The "Import existing Bnd workspace" is, indeed, problematic. Let me explain: let's say my Eclipse workspace is in C:\workspace and I create a new bnd workspace in C:\workspace\example. That will automatically change my current Eclipse workspace to be also C:\workspace\example,

No? Your Eclipse workspace is fixed, it is the directory with the .metadata/ directory in it. That will _never_ automatically change. You need to consciously switch it. Imho when you're learning a tool, keep it simple and start from scratch if you decide you want things differently.

3. but at this point I am blissfully unaware of the problems that this will cause down the line and start to create new Bnd projects -- let's say C:\workspace\example\project1 and C:\workspace\example\project2 alongside the C:\workspace\example\cnf created by Bndtools. But after that I decide I want to work with my Bnd workspace without it being the Eclipse workspace. So I switch my Eclipse workspace back to C:\workspace and try to import the existing Bnd workspace using the "Import existing Bnd workspace" option. This will display an error popup:
   
   "'Import Bnd Workspace' has encountered a problem.
   Cound not finish import job for Bnd Workspace!
   
   , with no further details. In addition, two empty new folders will have been created in the workspace: C:\workspace\cnf and C:\workspace\project1. It seems that "Import existing Bnd workspace" tries to convert your current workspace into the workspace you are trying to import (but fortunately failing in the process). Interestingly enough, if I delete the C:\workspace\cnf and C:\workspace\project1 folders and try again, the process will fail with the same error message, but now the empty folders C:\workspace\cnf and C:\workspace\project2 will have been created, as if Eclipse remembered that it had already tried to import project1 or, perhaps, as if the import order is random.
   

This does sound messy, I think you got old metadata and new metadata from bnd and Eclipse interacting. If you want a new Eclipse workspace, make sure it is clean. Then in the clean Eclipse (NO projects), do "Import existing projects" from your bnd workspace. Bndtools will detect the cnf folder and anchor the bndtools workspace on it. 

3. 
   Bottom line is, the name "Import Bnd Workspace" is extremely misleading and it should be called "Convert the current workspace into an existing Bnd workspace", or something like that. It is definitely not what one is expecting when using that option.
   

Now, don't get me wrong. I like the OSGI model and I like many of the features that Bndtools offers, but the devil is in the details, and these details I've commented on here are certainly not a reason to abandon Bnd tools completely, but extremely annoying IMHO.

I did not even know we had a "Import Bnd Workspace" :-( I think it is meant to import a bnd workspace where there are no .project files in it. All information is defined by the bnd.bnd file.

If you have an existing bnd workspace with .project files, use "import existing projects". This keeps the bnd workspace anchored where you import the projects from, this must of course include the cnf project. 

Thanks for bearing with my rant here and I hope someone finds it, at least, informative or useful.

Suggestions for documentations, or better, PRs for the documentation would really help. It also helps if you file a bug to the Import Bndtools Workspace command because it should not mess up or at least provide a better message.

Kind regards,

Peter Kriens

To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/7e56a2da-fbe8-4b67-9417-36472a1a3909n%40googlegroups.com.

[Michael Lipp]

The current best practice, at least in my mind, is to dedicate one single directory, that has:

   workspace/

.git/ marks it as the git workspace

.metadata/ marks it as an Eclipse workspace

settings.gradle marks it as a gradle root

cnf/ marks it as a bnd workspace

com.foo.example.bar/ project (= Symbolic Name)

bnd.bnd bnd project marker

.gitignore ignores .metadata, .gradle-wrapper and others

I don't like having my projects in a workspace (if anyone's interested why: my projects live in directories synchronized with the cloud and synchronizing an eclipse workspace with cloud storage is an unpleasant experience). Using Eclipse's nested project feature, my layout is

   overall-project/

        .project                         Eclipse "general" project

.git/ marks it as the git workspace

settings.gradle marks it as a gradle root

cnf/ marks it as a bnd workspace

com.foo.example.bar/ project (= Symbolic Name)

bnd.bnd bnd project marker

.gitignore ignores .metadata, .gradle-wrapper and others

        build.gradle

Combined with the hierarchical view in the project explorer, this works extremely well. A big advantage is that I can do git operations "for everything" in Eclipse.

Regards,

    Michael

To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/3DAAFF76-5A72-47CC-B39F-2DF0F787B84C%40gmail.com.

[Peter Kriens]

On 25 Nov 2020, at 09:43, Michael Lipp <m...@mnl.de> wrote:

The current best practice, at least in my mind, is to dedicate one single directory, that has:

   workspace/

.git/ marks it as the git workspace

.metadata/ marks it as an Eclipse workspace

settings.gradle marks it as a gradle root

cnf/ marks it as a bnd workspace

com.foo.example.bar/ project (= Symbolic Name)

bnd.bnd bnd project marker

.gitignore ignores .metadata, .gradle-wrapper and others

I don't like having my projects in a workspace (if anyone's interested why: my projects live in directories synchronized with the cloud and synchronizing an eclipse workspace with cloud storage is an unpleasant experience).

And you cannot exclude the .metadata directories from your synchronizer? Most synchronizers allow exclusions since it is a common problem. I worked for many years separating the Eclipse workspace from the bnd workspace. However, in the last year I converted them all to one when I visited them because it is just one thing less to be wrong.

Then again, as long as you ensure all your projects are in the same directory as the cnf project you're ok.

Using Eclipse's nested project feature, my layout is

   overall-project/

        .project                         Eclipse "general" project

.git/ marks it as the git workspace

settings.gradle marks it as a gradle root

cnf/ marks it as a bnd workspace

com.foo.example.bar/ project (= Symbolic Name)

bnd.bnd bnd project marker

.gitignore ignores .metadata, .gradle-wrapper and others

        build.gradle

I can see how this confuses the hell out of Eclipse. I would never ever have a  project at the root. your 'overall-project' is the bnd & git workspace. If you now try to import projects, it will only see one project. I could imagine there are more places where it gets confused. Although it might work, it also violates the idea of the bnd workspace that all projects are on the same level. I have a customer that does this and I trip over it every time I have to do something with their workspace.

When I want to see the root, create a symbolic link 'parent' in the cnf directory to the parent. I generally do the editing of the root files (since they are rarely ever needed) in the shell. But I agree, that could be done nicer.

Combined with the hierarchical view in the project explorer, this works extremely well.

Did you try the Bndtools Explorer? It allows you to quickly search by projects with warnings, errors, and name. It now also provides an easy function to reload the workspace.

A big advantage is that I can do git operations "for everything" in Eclipse

I do admit I abandoned EGit in the earlier days because it just did not work reliable. So I am in the shell for this work with a handy Mac tool for the visualizations. Maybe should give it another chance ...

Kind regards,

Peter Kriens

To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/0858a6af-3625-6717-0b69-32fb029200c3%40mnl.de.

[Michael Lipp]

Am 25.11.20 um 10:18 schrieb Peter Kriens:

Using Eclipse's nested project feature, my layout is

   overall-project/

        .project                         Eclipse "general" project

.git/ marks it as the git workspace

settings.gradle marks it as a gradle root

cnf/ marks it as a bnd workspace

com.foo.example.bar/ project (= Symbolic Name)

bnd.bnd bnd project marker

.gitignore ignores .metadata, .gradle-wrapper and others

        build.gradle

I can see how this confuses the hell out of Eclipse. I would never ever have a  project at the root. your 'overall-project' is the bnd & git workspace. If you now try to import projects, it will only see one project. I could imagine there are more places where it gets confused. Although it might work, it also violates the idea of the bnd workspace that all projects are on the same level. I have a customer that does this and I trip over it every time I have to do something with their workspace.

As mentioned, my Eclipse handles this perfectly well. Obviously, when you import the "overall-project" in Eclipse, you have to check the "search for subprojects" and import those as well. (And from bnd's point of view, all projects *are* on the same level.) Together with your customer, this seems to make at least two of us who like working this way.

A big advantage is that I can do git operations "for everything" in Eclipse

I do admit I abandoned EGit in the earlier days because it just did not work reliable. So I am in the shell for this work with a handy Mac tool for the visualizations. Maybe should give it another chance ...

As we all know, there are many ways to do something (especially in Eclipse) and much is about personal preference. For me, the "Commit window" (don't remember when they introduced it) turned out to be a very good way to handle git.

Regards,

    Michael

[Rubén Pérez Vázquez]

Hi everybody,

Let me start by addressing Peter Kriens' comment that I have been unfair. Yes, I think I have and I apologise. I can only imagine how many hours have gone into creating a nice environment to develop OSGi "natively". Sometimes we only focus on the problems and forget to mention the good things. So let me state here that there are many more things that I like than complaints. It's just that I was very frustrated when I wrote the message the other day.

I have tested this again using a freshly installed Eclipse with the latest version of bndtools available at the Eclipse Marketplace. I think that I have seen what my problem was: I thought that, when creating a new bnd workspace, bndtools would automatically switch Eclipse workspace to be in the root folder of the bnd workspace, but it is not the case. What it does happen is that Eclipse imports the bnd projects as if they were in the root of the workspace because the intermediate folder (the root of the bnd workspace) is not itself a project. So, the fact that, I see the following in the Java Project Explorer:

does not mean that those projects are physically in my current workspace. They are, in fact, both inside the folder workspace/org.example, but Eclipse never displays the org.example subfolder (which is the root of the bnd workspace) because it is not a project itself. Now I understand much better what Fr Jeremy Krieg and Peter Kriens meant, and I apologise if I didn't earlier.

This, however, still presents a problem when I try to add elements to the bnd workspace. From Eclipse's perspective, these elements must be inside a project, but the root of the bnd workspace is not one. The other problem that I see is the fact that the projects inside the workspace are completely independent from the perspective of Eclipse.

I think this model was practically mandatory back in the days where Eclipse did not handle and project with their subprojects very well. However, I don't think this is problematic anymore, and I do think that Michael Lipp's bnd-workspace-as-eclipse-parent-project approach is the most "native" solution, because Eclipse won't get confused when it sees all these resources in the root of the bnd workspace.

As per Michael's advice, which is similar to what Fr Jeremy suggested (creating a .project file by copy-pasting another one), I tried to create a general project in the same folder as the bnd workspace described above (namely org.example). I selected "New > Project > General > Project", gave the name org.example and I got the following dialog:

I selected both of them and voilá:

Of course, the option "Project Presentation > Hierarchical" when clicking the "three points" menu of the Project Explorer must be selected. If a "Flat" presentation is selected, however, the view is more confusing:

And the same happens with the Bndtools Explorer (which IMHO should be fixed):

EGit does not get confused with a root project either. One can choose to share the subprojects together or separately with their root project. By default, sharing a root project does not share its subprojects, but when sharing a subproject, one can select the same repository created for the root project and Eclipse will set that appropriately.

So, to summarize:

• I have clarified my confusion with what I assumed bndtools did and what it actually does.
• I agree with Michael Lipp that the bnd workspace works best when the root folder is imported as an Eclipse project. I believe it should become a best practice and I will, in fact, adopt it from now on.
  
• In relation to the previous item, may I suggest that the new bndtools versions should take care of that themselves (creating the root project, I mean). Also, the bndtools view should display the projects hierchically or hide the root project, should it exist. I would say this is a bug, but I am hesitant to call it that because having a root project is not standard and so far discouraged by Peter Kriens (but I hope these emails will help him reconsider his opinion? :D ).
• In providing screenshots for this message I have seen there have been changes in the default repository template, which now includes the new OSGi XML repository files, and it looks good! Can't wait to play with that.
• Re. contributions: I'd be more than happy to contribute to (re)writing documentation but I wouldn't know where to start. @Peter, feel free to contact me privately and suggest some of the areas that you think need more "love".
  As per the bug with the import of an existing bnd workspace, I'll gather some information and create a build report as soon as I find some free time. Writing this message took me ages already! :D

And just to clarify my general opinion about bndtools, despite my previous rants: thanks for existing!

Best regards,

Rubén

--
You received this message because you are subscribed to a topic in the Google Groups "bndtools-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bndtools-users/ES9tOhfMtuI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bndtools-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/de916508-45a8-4214-2860-3cb9cda04a5f%40mnl.de.

[Peter Kriens]

Thanks :-)

You might want to add a chapter to the concepts section on the Bndtools website. You can find the repo here: 

https://github.com/bndtools/bndtools.github.io/blob/master/concepts.md

You could make a new page completely about Eclipse workspace setup.

Kind regards,

Peter Kriens

On 26 Nov 2020, at 23:48, Rubén Pérez Vázquez <rube...@gmail.com> wrote:

Hi everybody,

Let me start by addressing Peter Kriens' comment that I have been unfair. Yes, I think I have and I apologise. I can only imagine how many hours have gone into creating a nice environment to develop OSGi "natively". Sometimes we only focus on the problems and forget to mention the good things. So let me state here that there are many more things that I like than complaints. It's just that I was very frustrated when I wrote the message the other day.

I have tested this again using a freshly installed Eclipse with the latest version of bndtools available at the Eclipse Marketplace. I think that I have seen what my problem was: I thought that, when creating a new bnd workspace, bndtools would automatically switch Eclipse workspace to be in the root folder of the bnd workspace, but it is not the case. What it does happen is that Eclipse imports the bnd projects as if they were in the root of the workspace because the intermediate folder (the root of the bnd workspace) is not itself a project. So, the fact that, I see the following in the Java Project Explorer:

<image.png>

does not mean that those projects are physically in my current workspace. They are, in fact, both inside the folder workspace/org.example, but Eclipse never displays the org.example subfolder (which is the root of the bnd workspace) because it is not a project itself. Now I understand much better what Fr Jeremy Krieg and Peter Kriens meant, and I apologise if I didn't earlier.

This, however, still presents a problem when I try to add elements to the bnd workspace. From Eclipse's perspective, these elements must be inside a project, but the root of the bnd workspace is not one. The other problem that I see is the fact that the projects inside the workspace are completely independent from the perspective of Eclipse.

I think this model was practically mandatory back in the days where Eclipse did not handle and project with their subprojects very well. However, I don't think this is problematic anymore, and I do think that Michael Lipp's bnd-workspace-as-eclipse-parent-project approach is the most "native" solution, because Eclipse won't get confused when it sees all these resources in the root of the bnd workspace.

As per Michael's advice, which is similar to what Fr Jeremy suggested (creating a .project file by copy-pasting another one), I tried to create a general project in the same folder as the bnd workspace described above (namely org.example). I selected "New > Project > General > Project", gave the name org.example and I got the following dialog:

<image.png>

I selected both of them and voilá:

<image.png>

Of course, the option "Project Presentation > Hierarchical" when clicking the "three points" menu of the Project Explorer must be selected. If a "Flat" presentation is selected, however, the view is more confusing:

<image.png>

And the same happens with the Bndtools Explorer (which IMHO should be fixed):

You received this message because you are subscribed to the Google Groups "bndtools-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/CAFWAsK0ie8xy%3D9Un6USfiLoiJeY_RVDmVRtRtUJsVbEF5EvguQ%40mail.gmail.com.