8000 Document Maven dependencies README.textile · Issue #141 · eclipse-cbi/targetplatform-dsl · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Document Maven dependencies README.textile #141

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
jukzi opened this issue Sep 28, 2023 · 9 comments
Open

Document Maven dependencies README.textile #141

jukzi opened this issue Sep 28, 2023 · 9 comments

Comments

@jukzi
Copy link
jukzi commented Sep 28, 2023

please document the keywords for maven added with #115
in

targetplatform-dsl/README.textile

Line 88 in 67c0f88

Then, you define the locations of your p2 repositories. You can add as many locations as your want to your target. Location string must be URL, if your p2 repository is local, don't forget to put a @file:/@ URL.

see https://github.com/eclipse-cbi/targetplatform-dsl/blame/67c0f8838880eb0b36eb99b581f08615e56037d7/org.eclipse.cbi.targetplatform/src/main/java/org/eclipse/cbi/targetplatform/TargetPlatform.xtext#L52
@UdoW
Copy link
UdoW commented Oct 31, 2023 •
edited
Loading

As I read the Xtext grammar correctly the documentation should look something like this for Maven artifacts:

maven central scope = test dependencyDepth = direct missingManifest = generate includeSources {
	dependency {
		groupId = "org.testcontainers"
		artifactId = "testcontainers"
		version = "1.19.0"
	}
}

At least this works for me and the generated target source looks like this:

    <location includeDependencyDepth="direct" includeDependencyScopes="test" includeSource="true" missingManifest="generate" type="Maven" label="central">
    <dependencies>
    	<dependency>
    		<groupId>org.testcontainers</groupId>
    		<artifactId>testcontainers</artifactId>
    		<version>1.19.0</version>
    		<type>jar</type>
    	</dependency>
    </dependencies>
    </location>

The Xtext grammar is here:

org.eclipse.cbi.targetplatform/src/main/java/org/eclipse/cbi/targetplatform/TargetPlatform.xtext

@jukzi
Copy link
Author
jukzi commented Nov 2, 2023

@hannesN can you provide a documentation, please?

@guw
Copy link
guw commented Apr 8, 2025

Anyone knows if the Maven support does allow patching/overriding of some headers in some bundles?

@haubi
Copy link
Contributor
haubi commented Apr 9, 2025

I have had need for this as well, and as far as I have discovered, there's two problems here:

  • in .target files: although you can define specific BND-recipes for generating OSGi metadata, this generation is performed when there are no OSGi metadata at all. I haven't found a way to modify existing OSGi metadata.
  • in .tpd files: defining BND-recipes is not supported at all

@merks
Copy link
Contributor
merks commented Apr 9, 2025

I've previously discussed with @laeubi the occasional need to repair broken metadata, but he is not a big fan of opening the floodgates on such an easily abused feature.

@guw
Copy link
guw commented Apr 9, 2025

FWIW, I am dealing with another "I need duplicate Guava bundles just because of this one thing" issue.
protocolbuffers/protobuf#21173

I understand addressing them upstream is the right solution but it's time consuming and very expensive.

@laeubi
Copy link
laeubi commented Apr 10, 2025

FWIW, I am dealing with another "I need duplicate Guava bundles just because of this one thing" issue.

And that's the reason why it is intentionally not possible to wrap exiting OSGi bundles, the risk is just to high that this cause complete confusion if the same bundle is wrapped multiple times with different settings and there is also an additional official one.

Also wrapping non OSGi jars is more a workaround / temporary solution for rapid prototyping and closed systems. The goal should always be to add appropriate metadata in the first place.

I understand addressing them upstream is the right solution but it's time consuming and very expensive.

It is the only solution or soon one will end up with multiple slightly differing libraries of the same version what is a real mess.

@guw
Copy link
guw commented Apr 10, 2025

Also wrapping non OSGi jars is more a workaround / temporary solution for rapid prototyping and closed systems. The goal should always be to add appropriate metadata in the first place.

You have a very interesting definition of "closed systems" and project timelines. I do agree with the goal, though.

It is the only solution

Sorry it's not. It is the one idealistic solution, though. But that's ok. I don't want to force my ideas and views on anyone. I was just asking for possibilities. For the time being, I'll continue shipping multiple versions for Guava in Eclipse with grief.

@laeubi
Copy link
laeubi commented Apr 10, 2025

You have a very interesting definition of "closed systems" and project timelines.

I don't see how "project timelines" relate here ... this all is completely independent from "timelines", if projects depend on unstable third party libraries it is the choice of the project and not the responsibility of the tool to solve this.

Also one should take into consideration that the actual contributions / support for that particular feature are very low, but the expectation form people benefit from it a very high. So I don't really want to open it to use-case where "we have no time to properly fix it" is the main driver and will only create problems and frustrations.

I'll continue shipping multiple versions for Guava in Eclipse with grief.

This is nothing bad per se, OSGi is explicitly made for this and it is better as every project shipping its own variant of "guava 33 with my fixes"

If you know the consequences and think you can manage them Tycho offers a wrap goal with that you can wrap arbitrary files with arbitrary instructions:

https://tycho.eclipseprojects.io/doc/latest/tycho-wrap-plugin/wrap-mojo.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@guw @merks @laeubi @haubi @UdoW @jukzi
0