Details
-
Type:
Enhancement
-
Status: Closed (View Workflow)
-
Priority:
Minor
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: 3.3.0.Beta1
-
Component/s: maven
-
Labels:
Description
M2e exposes an extension point, which allows plugins to contribute repositories to be indexed. Automatically registering the JBoss repository seems like a sensible thing for JBoss Tools. This would allow the user to access the JBoss public repository from the tooling (e.g. add dependency) without requiring them to add the JBoss public repository to their settings.xml file. Of course, the user would still need to ensure that the repository was correctly configured within their pom so the project will build correctly.
The following is all that is required (in plugin.xml):
<extension
point="org.eclipse.m2e.core.indexes">
<index
indexId="JBOSS_NEXUS"
isShort="true"
repositoryUrl="http://repository.jboss.org/nexus/content/groups/public">
</index>
</extension>
Gliffy Diagrams
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
interesting, but does that apply too all projects then as if they are in settings.xml ?
This means the behavior will be different from command line.
That users with their own proxy servers will not notice that they are not using their repository.
Both sounds like very bad tooling IMO
Max Rydahl Andersen
added a comment - interesting, but does that apply too all projects then as if they are in settings.xml ?
This means the behavior will be different from command line.
That users with their own proxy servers will not notice that they are not using their repository.
Both sounds like very bad tooling IMO Max, as I understand the problem, we would just force m2e to index the JBoss repo, allowing its jars to be available during dependency searches/autocompletion. If the artifacts found in the index are added to the pom without defining the repo explicitely in settings.xml/pom.xml then dependency resolution would still fail, same as for a command line build.
Just my gut feeling here. Needs to be investigated.
Fred Bricon
added a comment - Max, as I understand the problem, we would just force m2e to index the JBoss repo, allowing its jars to be available during dependency searches/autocompletion. If the artifacts found in the index are added to the pom without defining the repo explicitely in settings.xml/pom.xml then dependency resolution would still fail, same as for a command line build.
Just my gut feeling here. Needs to be investigated. if that is the case then +1!
Max Rydahl Andersen
added a comment - if that is the case then +1! I tested the behavior matches what I thought. Dependencies found in the index can't be resolved until the repository is explicitely added to the pom.xml or settings.xml. Which is a good thing(tm).
Now my question is : should we reference http://repository.jboss.org/nexus/content/groups/public (20.9MB index) or the more focussed https://repository.jboss.org/nexus/content/repositories/releases/ (16.5 MB index) which contains only JBoss / RedHat artifacts?
Fred Bricon
added a comment - I tested the behavior matches what I thought. Dependencies found in the index can't be resolved until the repository is explicitely added to the pom.xml or settings.xml. Which is a good thing(tm).
Now my question is : should we reference http://repository.jboss.org/nexus/content/groups/public (20.9MB index) or the more focussed https://repository.jboss.org/nexus/content/repositories/releases/ (16.5 MB index) which contains only JBoss / RedHat artifacts? Reading http://community.jboss.org/wiki/MavenGettingStarted-Users I would say https://repository.jboss.org/nexus/content/repositories/releases/ is the "default" one we would add since that is the actual releases.
Max Rydahl Andersen
added a comment - Reading http://community.jboss.org/wiki/MavenGettingStarted-Users I would say https://repository.jboss.org/nexus/content/repositories/releases/ is the "default" one we would add since that is the actual releases. Fixed in trunk.
If m2e's configured as such, the JBoss Releases repo index will be downloaded/updated on workspace startup.
Fred Bricon
added a comment - Fixed in trunk.
If m2e's configured as such, the JBoss Releases repo index will be downloaded/updated on workspace startup. verified in jbosstools-3.3_stable_branch.aggregate-Update-2012-02-24_23-15-15-H93
Rastislav Wagner
added a comment - verified in jbosstools-3.3_stable_branch.aggregate-Update-2012-02-24_23-15-15-H93 As on Eclipse m2e issue https://bugs.eclipse.org/bugs/show_bug.cgi?id=379832, "org.eclipse.m2e.core.indexes" extension is deprecated.
The problem is with firewall configurations, since custom repositories do not pass trhough mirror configurations.
So, I request a reopening of this issue for better evaluation.
Claudio Weiler
added a comment - As on Eclipse m2e issue https://bugs.eclipse.org/bugs/show_bug.cgi?id=379832 , "org.eclipse.m2e.core.indexes" extension is deprecated.
The problem is with firewall configurations, since custom repositories do not pass trhough mirror configurations.
So, I request a reopening of this issue for better evaluation. Hey Claudio,
I'm not sure what to do here. While the extension point has been deprecated, I don't believe an alternative has been provided. Furthermore, while these repositories are not used for dependency resolution, they are useful in other capacities. For SwitchYard, we are using it to discover the available versions. Another use is resolving archetypes, which I think would be an issue of concern for the generic m2e tooling.
I'll verify the assertions above and add a comment to the Eclipse ticket.
Thanks for highlighting the issue.
Best,
Rob
Rob Cernich
added a comment - Hey Claudio,
I'm not sure what to do here. While the extension point has been deprecated, I don't believe an alternative has been provided. Furthermore, while these repositories are not used for dependency resolution, they are useful in other capacities. For SwitchYard, we are using it to discover the available versions. Another use is resolving archetypes, which I think would be an issue of concern for the generic m2e tooling.
I'll verify the assertions above and add a comment to the Eclipse ticket.
Thanks for highlighting the issue.
Best,
Rob Ok Rob, will be watching this issues. For now our solution for this was edit plugin.xml and put our nexus address on the url for this custom repository.
Best regards.
Claudio Weiler
added a comment - Ok Rob, will be watching this issues. For now our solution for this was edit plugin.xml and put our nexus address on the url for this custom repository.
Best regards. 
Apologies if this functionality already exists. Also, it looks like this extension point has been deprecated, however the replacement "repository" extension point does not appear to have materialized yet, so I think it is safe to use until the new extension point is defined. Please see the following for more information.
https://issues.sonatype.org/browse/MNGECLIPSE-1325