search

bndtools / bnd

Bnd/Bndtools. Tooling to build OSGi bundles including Eclipse, Maven, and Gradle plugins.
https://bndtools.org
Other
526 stars 304 forks source link

Provide bndtools 7.1+ p2 release repositories so that oomph setups can refer to specific bndtools versions #6084

Open scottslewis opened 2 months ago

scottslewis commented 2 months ago

As per discussion on #6046 and summarized by issue #6083 it would be desirable to have oomph setups contributed so that users could easily create and configure bndtools without having to separately install bndtools to Eclipse.

One requirement of using oomph setups is that there should be separate p2 repo urls for specific versions of bndtools, rather than simply the latest released version of bndtools by new versions. This need is summarized by this discussion:

https://bnd.discourse.group/t/specific-release-url-for-each-release-humble-request/289

This will require some changes to the bnd build and perhaps usage of p2 director (command line)? There is relevant work described by this comment https://github.com/bndtools/bnd/issues/6046#issuecomment-2024704462

chrisrueger commented 2 months ago

Just for further reference: The bnd release process (including the P2 repo stuff) seems to be described here: https://github.com/bndtools/bnd/wiki/Release-Process

pkriens commented 2 weeks ago

from the #6083: As per the discussion on issue https://github.com/bndtools/bnd/issues/6046 there are oomph setups that can be contributed to the bndtools project, so that users can then use oomph to install and configure bndtools 7.1+

This issue can be used to track these contributions

scottslewis commented 2 weeks ago

from the #6083: As per the discussion on issue #6046 there are oomph setups that can be contributed to the bndtools project, so that users can then use oomph to install and configure bndtools 7.1+

This issue can be used to track these contributions

Peter I don't understand this comment at all. As discussed on #6046 (contributing oomph setups to bndtools project) is currently (and for years now) thwarted by the fact that oomph setups need a version specific bndtools p2 repo...thus this issue was opened, so that this need can be satisfied by bndtools 7.1+ release repos, and then the oomph setups can be contributed as per the work described in #6046. It's effectively useless to contribute the existing oomph setups...until this issue is resolved...because the oomph setups must point to a hacked together private bndtools p2 repo (not the public one).

The point being: this issue has to be addressed (via changes to the bndtools release process) before it's even possible to contribute oomph setups for bndtools 7.1+.

chrisrueger commented 2 weeks ago

The point being: this issue has to be addressed (via changes to the bndtools release process) before it's even possible to contribute oomph setups for bndtools 7.1+.

I think this is going to happen. @peterkir is working on that part. He presented his proposal for a "new release process" in today's bnd call (as mentioned here). Maybe he can post an update.

So something is going on in this regard.

Peter I don't understand this comment at all.

The confusion is justified. The confusion probably comes from the fact, that @pkriens just copy pasted this comment from here We saw it since he did it via screensharing in today's bnd call. I can't remember the exact situation but it was maybe meant more as quick reference / reminder.

pkriens commented 1 week ago

@scottslewis people are working to make you happy ... @peterkir is now working on the oomph, I did the fragment templates and @chrisrueger is heorically trying to tie it all together.

As said before, I often find it really hard to translate your issues in specific actions since they are not proposals but more a rough analysis of what doesn't work for you. People are working hard to fix the issues you pointed out.

We now have this issue which is basically trying to make you happy ...

scottslewis commented 1 week ago

@scottslewis people are working to make you happy ...

Thanks, but I'm not trying to make myself happy...I'm trying to help make bndtools usable by people other than those that have designed and built it.

@peterkir is now working on the oomph, I did the fragment templates and @chrisrueger is heorically trying to tie it all together.

Kudos and thanks to you, me, and all these contributors. In my experience as an Eclipse project lead, it's always the committer community that steps up to create the real value.

As said before, I often find it really hard to translate your issues in specific actions since they are not proposals but more a rough analysis of what doesn't work for you.

I fail to understand how this issue: Provide bndtools 7.1+ p2 release repositories so that oomph setups can refer to specific bndtools versions

could somehow be misunderstood as some 'vague analysis of what doesn't work for you'. My interpretation is that you simply can't take a perspective on what bndtools needs to be usable by others. (e.g. oomph setups to allow for easy install and config, use of Eclipse wizards to help people that wish to use the very powerful OSGi services without having to learn or even understand bundles or the rest of osgi; the complicated but required mess that is trying make tooling for Remote Services via workspace and project templates).

These are not, by any means, 'rough analysis of what doesn't work for me'...although as a user of bndtools I have certainly experienced the user problems identified in the above paragraph. They are rather identifying areas where bndtools is completely unsatisfying in my view...with an emphasis on finding and improving those areas that most 'hold back' adoption by new osgi developers.

People are working hard to fix the issues you pointed out.

We now have this issue which is basically trying to make you happy ...

Somehow by your comments you make it sound like I'm some sort of bitchy bndtools developer that has my own, idiosyncratic way of doing things, and so I come up with a bunch of crazy ideas for meeting my specific needs that can't be understood by anyone else (e.g. dealing with the mess that is installing and configuring bndtools...via oomph installs, making the creation of OSGi services (and remote services) easier for new osgi devs, trying to use workspace templates so that remote services can be easily created).

I hate to break it to you, but to remain relevant bndtools (and osgi and Eclipse imho) are going to have to have a wider set of developer users and new ideas and community contributions at the level of usability and tooling features will be needed to attract those users to osgi development.

You're welcome.

chrisrueger commented 1 week ago

contributions at the level of usability and tooling features will be needed to attract those users to osgi development.

I couldn't agree more. And that (e.g. usability, getting started and the "unhappy path") are my main motivations for contributing here. Challenging goals. Let's see how far we can get. I think with regards to this issue, we are on the home stretch. 😄

Regarding your other comments: I don't think Peter means it in bad faith. I agree that the short sentence-replies come across a bit harsh, but written communication can be misinterpreted easily.

I found the friday zoom-calls always very productive and motivating. Last friday we spent a large portion discussing specifically this issue here. So maybe join the next one?