-
Notifications
You must be signed in to change notification settings - Fork 115
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
Make m2e.core.ui host of archetype-fragments and delete archetype.common #1494
Conversation
I don't think this is really worth because it require special treatment of the m2.ui bundle. |
34b9695
to
2055eca
Compare
Did that and also re-used the jdom2 bundle provided by maven-bnd Orbit, so that we don't have to define an own one.
I wouldn't consider this a braeking change in thise case since the bundles contained in this PDE are more internal and the same feature (in a functional sense is still provided). But I worked around this, simply by keep the generated bundle name as |
version="0.0.0" | ||
fragment="true" | ||
unpack="false"/> | ||
|
||
<plugin | ||
id="org.eclipse.m2e.archetype.catalog" | ||
download-size="0" | ||
install-size="0" | ||
version="0.0.0" | ||
fragment="true" | ||
unpack="false"/> | ||
|
||
<plugin | ||
id="org.eclipse.m2e.archetype.descriptor" | ||
download-size="0" | ||
install-size="0" | ||
version="0.0.0" | ||
fragment="true" | ||
unpack="false"/> | ||
|
||
<plugin | ||
id="org.eclipse.m2e.archetype.maven-artifact-transfer" | ||
download-size="0" | ||
install-size="0" | ||
version="0.0.0" | ||
fragment="true" | ||
unpack="false"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@laeubi do you see any reason that speaks against including the archetype bundles in this feature?
I would prefer it over the p2.inf file since it is less magic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The p2.inf ensures that all fragments are always installed together (especially for cases like tests).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The p2.inf ensures that all fragments are always installed together (especially for cases like tests).
This can also be achieved by corresponding Import-Packages and is less magic and even less to type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No this can't work because a fragment is always optional, so a consumer would need to import a package from each fragment even if it is never used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No this can't work because a fragment is always optional, so a consumer would need to import a package from each fragment even if it is never used.
That's right, a fragment is optional but m2e.core.ui already needs to import a package from each of the archetype artifacts (if one does not use require-bundle). The only import that would not be necessary from a class-loading/compiling point of view is the maven-transfer. But I think one not so necessary import is IMHO ok. And just to save that I wouldn't add/keep the p2.inf.
0a0f68f
to
8d68f5f
Compare
ff657d7
to
23659cc
Compare
@laeubi this change is IMHO now ready, do you have any objects? |
Bundle-Name: M2Eclipse supplement fragment for ${mvnGroupId}:${mvnArtifactId}:${mvnVersion} | ||
version: ${version_cleanup;${mvnVersion}} | ||
Bundle-SymbolicName: org.eclipse.m2e.archetype.common | ||
Bundle-Version: ${version}.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this will result in a 3.2.1.1
version is this really desired?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it is.
It is a (manual) qualifier bump so that those that use the snapshots don't miss the update.
When there is a new archetype version, it can be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1 is really a bad qualifier, why not do like in maven-runtime and use
${version}01
what will result in 3.2.101
d870fbf
to
0d82317
Compare
The Plugin o.e.m2e.archetype.common is empty and only serves as host for the maven-archetype fragment-bundles. Since they are only used by m2e.core.ui, we can simply make that the host of those fragments and save one project in m2e. In o.e.m2e.core.ui import all required packages plus those that are from fragments that are also needed for archetype.common to function properly, even if the package is not directly needed in m2e.core.ui.
0d82317
to
f1380c6
Compare
The Plug-in org.eclipse.m2e.archetype.common is not a Fragment and the corresponding attribute was added erroneously. This was accidentally added in eclipse-m2e#1494 Reported in eclipse-m2e#1537
The Plug-in org.eclipse.m2e.archetype.common is not a Fragment and the corresponding attribute was added erroneously. This was accidentally added in eclipse-m2e#1494 Reported in eclipse-m2e#1537
The Plugin o.e.m2e.archetype.common is empty and only serves as host for the maven-archetype fragment-bundles. Since they are only used by m2e.core.ui, we can simply make that the host of those fragments and save one project in m2e.
@laeubi what do you think?