Using repo01 as a repo name is confusing about osgi.enroute HOT 17 CLOSED

A more insightful name may be an advantage.

Do you have any suggestions? One option would be to use the artifactId of the project defining the index. It's pretty easy to set the index name using the bnd-indexer-maven-plugin.

from osgi.enroute.

Those words I lifted from Ray's comment on osgi-dev.
What confused me is that coming from 3.3 where the repositories were self explanatory, local etc..
I searched the github repository and my workspace but found no ref to repo01. As you would be aware this is all new to me and I am seeing the new enRoute to some extent as a a new recruit to OSGi would although many java developers are well versed in maven.
Any name that gave a clue to the index woud be an improvement.

from osgi.enroute.

Specifically the synthetic repo names comes from this line:

https://github.com/bndtools/bnd/blob/master/biz.aQute.bndlib/src/aQute/bnd/build/Workspace.java#L1219

where you can see that had the index file contained a name it would have been used.

I wonder if the enroute archetype might setup the indexer plugin to provide a name using:

<configuration>
    <indexName>my-index</indexName>
</configuration>

.. something meaningful maybe like enRoute (bnd-indexer-maven-plugin)

from osgi.enroute.

.. something meaningful maybe like enRoute (bnd-indexer-maven-plugin)

My proposal was just to use ${project.artifactId}. That should give you a pretty obvious link to where the index is being generated.

from osgi.enroute.

sounds good!

from osgi.enroute.

Oddly, the name from the code isn't actually pulled from the index file reference as I expected, but rather from an attribute name on the instruction, so like:

-standalone: target/index.xml;name="${project.artifactId}"

which I would suggest that we put as a fallback behind the index's name.

What do you think?

from osgi.enroute.

Oddly, the name from the code isn't actually pulled from the index file reference as I expected, but rather from an attribute name on the instruction, so like:

-standalone: target/index.xml;name="${project.artifactId}"

which I would suggest that we put as a fallback behind the index's name.

What do you think?

This sounds like a bug in bnd, and would need to be fixed there. All we can do in enRoute is to set the name of the generated index, or put the name property into the standalone entry. The former seems much cleaner.

from osgi.enroute.

agreed!

from osgi.enroute.

from osgi.enroute.

Yup, I just observed that...

from osgi.enroute.

And the repo name never comes from
the name in the index file. It is always supplied on the repo
configuration.

Why is this?

from osgi.enroute.

@timothyjward simply because it would be complicated. The OSGiRepo can refer to multiple locations, so which one would provide the name.

It certainly is possible for the OSGiRepo to "take" the name of the index because the XMLResourceParser certainly gets that information on it's behalf. OSGiRepo just doesn't use it.

So the only problem scenario is if there are multiple locations specified.

from osgi.enroute.

So the only problem scenario is if there are multiple locations specified.

This seems like quite a rare case. Would it not be possible to use the name from a single index file in the absence of any configured name for the repo?

from osgi.enroute.

the other issue might be "laziness". the repo might want to give out it's name before it ever touches any potentially remote resources.. but that seems odd case to me. It always should need to at least pull the index.

from osgi.enroute.

from osgi.enroute.

What I'll do is open a bnd issue and we can move this discussion over there.

For the time being there's a workaround for enRoute, which is use the name attribute on any -standalone location entries.

from osgi.enroute.

bndtools/bnd#2464

from osgi.enroute.