Community
Participate
Working Groups
org.eclipse.core.variables org.eclipse.core.commands org.eclipse.core.jobs
Moving to Platform > Releng since I'm not sure where the best place for this is yet. Uploading jars to repo.eclipse.org is typically up to the project not Webmaster. With JDT the JDT project has been pushing up very specific jars to repo.eclipse.org. As we gain more requests for various jars doing these one time jar pushes will become more overwhelming unless we start doing it as part of the Maven build with the "deploy" goal but that would push all Platform built artifacts to repo.eclipse.org. Should we leave it up to the sub-project to push these jars?
(In reply to Thanh Ha from comment #1) > Moving to Platform > Releng since I'm not sure where the best place for this > is yet. Uploading jars to repo.eclipse.org is typically up to the project > not Webmaster. > > With JDT the JDT project has been pushing up very specific jars to > repo.eclipse.org. As we gain more requests for various jars doing these one > time jar pushes will become more overwhelming unless we start doing it as > part of the Maven build with the "deploy" goal but that would push all > Platform built artifacts to repo.eclipse.org. > > Should we leave it up to the sub-project to push these jars? The project should certainly have a say, though having the bug here in releng is fine, since I'm sure we'd be involved if this treated as part of our deliverables. I think the next step is to discuss at our next status meeting ... if not also the PMC to discuss. (Adding Dani, so he can say if this is a PMC issue or not). Dan Dumont, can you clarify a little what your "use case" is? What problem is being solved? I'm guessing you have a "maven only" build that relies on these three bundles? I'm wondering if this is some "tip of the iceberg" you've just happened to hit first? Or or would this "completely solve" your problem?
I just followed the instructions for getting a project into the repo: > Simply file a Bug and specify what project you'd like a Nexus repo for. But I see that I've slightly misinterpreted it :) Here's my use case: Maven central repos have, for a while now, hosted various user-uploaded jars from eclipse distros. Finding dependencies are hit-or-miss. My team is trying to build an eclipse plugin with maven and the maven-bundle-plugin. We build all sorts of other osgi plugins with it. Currently, we resort to defining the dependencies with system scope and hardcode the path, but this makes CI hard, since each jenkins node has to have the jars local, or we have to check in the jars to the source pack. Eventually, I'd love to see all the eclipse jars published to the repo here. I have a few more jars on the list of things that aren't currently published, how should I handle it?
ps: tycho is not an option.
(In reply to Dan Dumont from comment #3) > > Eventually, I'd love to see all the eclipse jars published to the repo here. > I have a few more jars on the list of things that aren't currently > published, how should I handle it? If it's a finite list, I think it'd be good to list them here. That's part of why I asked ... to know "big picture". I thought we had a number of bundles that could not be used in a "pure maven" build, which is why I'd hesitate to say we'd ever "publish them all" (but, keep in mind ... I'm working with limited knowledge of "pure maven").
Here is what we are currently building with: org.eclipse.equinox.registry org.eclipse.equinox.common org.eclipse.core.runtime org.eclipse.core.resources org.eclipse.core.variables org.eclipse.core.commands org.eclipse.core.jobs org.eclipse.osgi org.eclipse.ant.core org.eclipse.pde.core org.eclipse.ui.console org.eclipse.ui.workbench org.eclipse.jface org.eclipse.swt Some of them are already in repo. We're using maven, but building a plugin. Actually the OSGi bundle building tools work quite well. I'm not sure why any plugin bundle wouldn't work well with maven. I'm also quite willing to send pull requests or patches if pointed in the right direction.
(In reply to Dan Dumont from comment #6) > ... I'm not sure why > any plugin bundle wouldn't work well with maven. > Perhaps I'm over- or mis-interpreting is, but we have lots of messages in our build logs (from Tycho) that say: [DEBUG] Dependency from [...]org.eclipse.jdt to nested classpath entry [...]org.eclipse.equinox.registry/runtime_registry_compatibility.jar can not be represented in Maven model and will not be visible to non-OSGi aware Maven plugins
(In reply to David Williams from comment #7) > [DEBUG] Dependency from [...]org.eclipse.jdt to nested classpath entry > [...]org.eclipse.equinox.registry/runtime_registry_compatibility.jar can not > be represented in Maven model and will not be visible to non-OSGi aware > Maven plugins I don't know... I don't use Tycho :) I've never had an issue consuming plugin jars from eclipse before. It might be talking about how the jar depends on other jars through the manifest... or by using some p2 system to hook things up. I'm not really worried. For things like eclipse, I would be marking the bundles as "provided" since they would be in eclipse during runtime. I only would need the actual jar to compile against.
(In reply to David Williams from comment #2) > The project should certainly have a say, though having the bug here in > releng is fine, since I'm sure we'd be involved if this treated as part of > our deliverables. I think the next step is to discuss at our next status > meeting ... if not also the PMC to discuss. (Adding Dani, so he can say if > this is a PMC issue or not). I'll discuss with the PMC in our next meeting.
(In reply to Dani Megert from comment #9) > (In reply to David Williams from comment #2) > > The project should certainly have a say, though having the bug here in > > releng is fine, since I'm sure we'd be involved if this treated as part of > > our deliverables. I think the next step is to discuss at our next status > > meeting ... if not also the PMC to discuss. (Adding Dani, so he can say if > > this is a PMC issue or not). > > I'll discuss with the PMC in our next meeting. Thanks Dani. (In reply to Dan Dumont from comment #8) > ... For things like eclipse, I would be marking the bundles as > "provided" since they would be in eclipse during runtime. I only would need > the actual jar to compile against. [I wrote this prior to seeing Dani's comment, but some other questions occurred to me, so will still ask them.] Another question about the "big picture requirement" ... Do you need these only for "released" versions of Eclipse? (such as final Luna release) or do you need them on an ongoing basis, such as weekly I- or M- builds? My guess is right now you'd be happy with a "released" version, but guess I'm asking more about what's anticipated long term. And, I have another concern ... more about what you are doing, rather than what you are asking for :) ... it sounds like you are building in one environment, against one set of jars, all with certain assumptions ... and then running in a different environment (Eclipse itself) potentially a different version? Certainly with different assumptions about how bundles are resolved and wired up. So ... sounds a bit risky or experimental, to me. [But, admit, I could simply be exhibiting my lack of understanding.]. But, it does make me wonder ... why couldn't you just publish the jars you need to your own, small, "internal maven repo", pulled from what ever version of Eclipse you'd be running on, and then build against that? While we'd love to hear the results of your experiments and processes, I'm not sure we have the resources to sign up to participate. Others may know more about this than I do, may know how simple it is, etc., but to me it looks like we'd be headed down a path where we did not know where it would end. Such as even if easy to "do once", what about 4 months from now, when you might need some sort of maintenance ... would it be so easy/obvious then? The Platform team is famous for "providing only what they use" ... but, if we don't use it, it is pretty hard for us to stand behind it. Please don't take my remarks as negative, or unwilling to help ... it's just part of my personality to be real explicit about things, so would appreciate hearing your responses. And, as I said previously, I think the "Platform team" needs to discuss this before much is decided -- we are stretched pretty thin as it is, and every "small request" isn't so bad ... but, we get scores of "small requests" ... so hard (for me) to know which of those to focus on. Thanks,
Point in favour of a coordinated push: If repo.eclipse.org contains only a "random" subset of eclipse artifacts, I don't think the repo will be perceived as anything serious / reliable. As a result, consumers expect artifacts to be pushed to *maven central* instead of repo.eclipse.org, for which a coordinated appearance of eclipse projects seems even more unlikely. I suggest that some level of completeness on repo.eclipse.org is a good compromise between (a) ignoring maven users and (b) putting every bit we produce on maven central. My background, btw, is twofold: (I) publishing org.eclipse.jdt.annotation which we encourage to use in *any* Java project, no further dependencies. (II) Generators built on Xtext, which are consumed in all kinds of OSGi-unaware build contexts. In the latter case a significant set of transitive dependencies is being pulled in, all of which can be used OK as dependencies of a maven plugin (i.e., pure build-time dependencies).
(In reply to David Williams from comment #10) > [I wrote this prior to seeing Dani's comment, but some other questions > occurred to me, so will still ask them.] > > Another question about the "big picture requirement" ... > > Do you need these only for "released" versions of Eclipse? (such as final > Luna release) or do you need them on an ongoing basis, such as weekly I- or > M- builds? > My guess is right now you'd be happy with a "released" version, but guess > I'm asking more about what's anticipated long term. I'm personally happy with release versions. It might be great to get snapshot versions as well for the dailies or however often you want to push unreleased code, but I don't have a requirement for that. > And, I have another concern ... more about what you are doing, rather than > what you are asking for :) ... it sounds like you are building in one > environment, against one set of jars, all with certain assumptions ... and > then running in a different environment (Eclipse itself) potentially a > different version? Certainly with different assumptions about how bundles > are resolved and wired up. So ... sounds a bit risky or experimental, to me. Well we're building a plugin for a released version of eclipse... so we want to target the release plugins. Published bundles in the repo would allow us to specify version ranges that would get wired up into the manifest for acceptable bundle versions. I'm not really sure what you mean :( I'm building in jenkins on a linux machine with no eclipse install. Now, yes, I have to make sure that the plugins I'm using are part of the release of eclipse and not a mismatch of different releases. I expect this, and that's why having all the release versions for the plugins in the eclipse repo is great, because I can find it all and list my dependencies. > [But, admit, I could simply be exhibiting my lack of understanding.]. But, > it does make me wonder ... why couldn't you just publish the jars you need > to your own, small, "internal maven repo", pulled from what ever version of > Eclipse you'd be running on, and then build against that? I guess I could, but then I'd have to set up a nexus myself, maintain it, repackage things that (in theory) you guys are already packaging. If I'm going to do packaging work, I would so much rather help you guys out and get it available for everyone in the most visible place I can. Eclipse is the authority for eclipse code. I've never liked using the random bundles people have pushed out to maven central. > While we'd love to hear the results of your experiments and processes, I'm > not sure we have the resources to sign up to participate. Others may know > more about this than I do, may know how simple it is, etc., but to me it > looks like we'd be headed down a path where we did not know where it would > end. Such as even if easy to "do once", what about 4 months from now, when > you might need some sort of maintenance ... would it be so easy/obvious > then? The Platform team is famous for "providing only what they use" ... > but, if we don't use it, it is pretty hard for us to stand behind it. Not sure what you're saying. If you don't use it? You mean if you don't release it in eclipse? I'd imagine if you stop developing bundles/features in eclipse they would no longer get release builds... As for maintenance, I would hope the deploy of the artifacts would be automatic to the repo and occur during the release build phase. There should be a way to plug it in to however the projects are currently using maven to release. > Please don't take my remarks as negative, or unwilling to help ... it's just > part of my personality to be real explicit about things, so would appreciate > hearing your responses. And, as I said previously, I think the "Platform > team" needs to discuss this before much is decided -- we are stretched > pretty thin as it is, and every "small request" isn't so bad ... but, we get > scores of "small requests" ... so hard (for me) to know which of those to > focus on. Let me know how I can help! > Thanks,
Part of the problem I see is that pom.xml files in repos don't contain any information about dependencies as most projects rely on OSGi tool to fullfill them from Manifest.MF. In order to get a good maven repo (aka when you specify some dependency it's transitive dependencies would have to be supplied too) we would need to have pom.xml files that list all dependencies as Maven currently relies on pom.xml only for that. That would be significant change to the way projects work (manifest first) or some generator would have to be added that would inject this information into pom.xml files (I'm not aware of such tool existing).
(In reply to Alexander Kurtakov from comment #13) > Part of the problem I see is that pom.xml files in repos don't contain any > information about dependencies as most projects rely on OSGi tool to > fullfill them from Manifest.MF. In order to get a good maven repo (aka when > you specify some dependency it's transitive dependencies would have to be > supplied too) we would need to have pom.xml files that list all dependencies > as Maven currently relies on pom.xml only for that. That would be > significant change to the way projects work (manifest first) or some > generator would have to be added that would inject this information into > pom.xml files (I'm not aware of such tool existing). This is one of the reasons I don't use the Tycho plugin. But I'm not about to suggest to all of eclipse that they change the way they are building things... :) I don't want to let the perfect solution get in the way of the good, so I'm happy to manually list the deps I need (as all of the deps are runtime for me, and I can list them out as they are not transitive).
(In reply to Alexander Kurtakov from comment #13) > ... or some > generator would have to be added that would inject this information into > pom.xml files (I'm not aware of such tool existing). b3 can do s.t. along these lines, actually.
After discussion on PMC call the agreement is: 1. We don't want to have dependencies listed in the pom.xml file as it would force new dependencies to be added in two places which is a recipe for getting out of sync. So in git repos we stay with dependencies being listed in Manifest.MF files via OSGi directives. 2. Adding bundles to repo.eclipse.org will require someone doing it and thus people interested in doing it would have to do the work. 3. Some tool would have to be used or written if it doesn't exist that would translate OSGi dependencies into Maven style dependencies so repo.eclipse.org doesn't end up being like maven central containing bundles with insufficient maven metadata thus easily getting broken at runtime. We are really interested to help anyone that would work on moving this forward but available resources simply don't allow pushing it ahead.
Given the PMC's decision in comment 16, I believe that implies "CBI" would be a better component for this bug. If that's incorrect, please feel free to move it to a more appropriate component.
*** Bug 441510 has been marked as a duplicate of this bug. ***
Eclipse Platform has automated submission of bundles to maven central.
