Skip to content
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.

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

If possible, please use dependency management in runtime's parent pom #402

Open
MarceloRuiz opened this issue May 4, 2020 · 5 comments
Open

Comments

@MarceloRuiz
Copy link

All maven e(fx)clipse application's parent pom declare a parent:

	<parent>
		<groupId>at.bestsolution.efxclipse.rt</groupId>
		<artifactId>at.bestsolution.efxclipse.rt.release</artifactId>
		<version>3.6.0</version>
	</parent>

When an application needs to declare a dependency to a component like org.eclipse.e4.core.di.annotations it should not be necessary to delve into the repository and look, for example at https://maven.bestsolution.at/efxclipse-releases/at/bestsolution/efxclipse/rt/at.bestsolution.efxclipse.rt.release-bom/3.6.0/at.bestsolution.efxclipse.rt.release-bom-3.6.0.pom to find out which version number should be used (1.6.200.v20180817-1215 in the example).
A much better approach, if possible, would be to have the version number automatically provided so there will be no need to specify the version number. This might also make updating from one version of e(fx)clipse to another much easier, because all the dependencies will be recalculated based on what the platform needs.

@tomsontom
Copy link
Contributor

The exact reason to provide the bom is that in your dependency section you don't have to put any version because it is defined in the bom for you

@MarceloRuiz
Copy link
Author

Thanks for answering me. How is this implemented in practice?
After defining the property efxclipse.runtime-version to 3.6.0, I included the following in the parent (sample.mvn.parent) pom dependency management section:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>at.bestsolution.efxclipse.rt</groupId>
            <artifactId>at.bestsolution.efxclipse.rt.release-bom</artifactId>
            <version>${efxclipse.runtime-version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        ...
    </dependencies>
</dependencyManagement>

Now, let's say I need to declare the dependency on sample.mvn.app, so I write:

<dependencies>
    <dependency>
        <groupId>at.bestsolution.efxclipse.eclipse</groupId>
        <artifactId>org.eclipse.e4.core.di.annotations</artifactId>
    </dependency>
    ...
</dependencies>

but eclipse complains with this error:
Project build error: 'dependencies.dependency.version' for at.bestsolution.efxclipse.eclipse:org.eclipse.e4.core.di.annotations:jar is missing.
What am I doing wrong?
Thanks!

@MarceloRuiz
Copy link
Author

MarceloRuiz commented May 4, 2020

I also read that another way to do it is by declaring the bom as the parent, so in sample.mvn.parent I declared:

<parent>
    <groupId>at.bestsolution.efxclipse.rt</groupId>
    <artifactId>at.bestsolution.efxclipse.rt.release-bom</artifactId>
    <version>3.6.0</version>
</parent>

and of course removed what I mentioned in my previous comment from the dependencyManagement section, but I get errors everywhere about missing artifacts. Just an example:
'Missing artifact at.bestsolution.efxclipse.eclipse:org.eclipse.m2e.jdt:jar:1.12.0.20190529-1916'

@tomsontom
Copy link
Contributor

Oh yeah silly me the generation of the bom is wrong! I need to fix that. What works today is that if you use https://maven.bestsolution.at/efxclipse-releases/at/bestsolution/efxclipse/rt/at.bestsolution.efxclipse.rt.release/3.6.0/at.bestsolution.efxclipse.rt.release-3.6.0.pom as your parent you can use the variables in there. But the bom way is the better one!

@MarceloRuiz
Copy link
Author

Thanks for answering me. I can't tell you how much I hit my head against the wall today!
Can you let me know once the bom is fixed? I will focus on adding functionality and then work on the dependency salad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants