Hi Igor, Funny, now that you mention it, your name seems familiar too - I see you worked at ThinkDynamics, so we might've met there before the IBM buyout. Possibly, though, you remember my brother Colin who was with Brightspark from the start and who was one of the founders of SpringSource. Are you still in Toronto?
Once I actually try Tycho out, I'll see if I can be more specific about how the tools should work together. For one, Spring also provides a (manifest) classpath container based on OSGi bundle repositories. This is used to resolve dependencies for the project and also to provide them to the Spring DM server target that the Spring tooling installs. So, what their tooling provides for OSGi development is an OSGi bundle nature, an enhanced manifest editor (I'm not sure what the base Eclipse provides, but this one supports Spring's extra "Import-Bundle" and "Import-Library" manifest entries (macros, as they call them), syntax coloring, etc). There is a bundle project wizard which supports their web module (http://static.springsource.com/projects/dm-server/1.0.x/programmer-guide/html/ch05s02.html#developing-applications-packaging-web-modules) concept, and, as I mentioned before, they also add a server target runtime for Spring DM Server for use with WTP. Oh, they also support the PAR packaging that they've defined and which looks to be added to OSGi 4.2 in some form (RFC 124 provides for this, among other things). I suppose what I would want for smooth development is that your dependency (bundle) resolver somehow co-operates with theirs - maybe this would be through the ability to disable one or the other of the resolvers or maybe by allowing their priorities to be set such that that the order of lookup is known. The other thing is that Spring DM Server defines the PAR packaging type which, if using your resolver, should have it's scope enforced. Of course, the resolution that is arrived at in the IDE should be mirrored for command-line Maven builds. As you say, I don't think that you are that far from having the tooling work together, but as I see it now, there is still the possibility of stepping on each others toes in dependency resolution if both tooling would provide their respective natures, or, if theirs were to be disabled, there would be some missing functionality due to the lack of support for web modules, PAR scope, etc. What do you think? Adrian Igor Fedorenko-4 wrote: > > Adrian, > > I don't know enough about Spring to be able to answer this question, to > be honest. > > If you are interested to invest some time into this, it would be great > if you could help us understand "ideal" spring-eclipse-maven development > environment and workflow. I may be wrong, but my gut feeling is that we > are not too off, especially considering the work we are planning for > next few months. At least we should be able to tell what works and what > is missing and hopefully give some estimates when we plan to implement > the missing parts. > > -- > Regards, > Igor > > PS: your name sounds familiar. did you by any chance work at brightspark > few years ago? > > > adrians wrote: >> Hi, >> >> I've been trying to see (by reading, so far) how close you can come today >> to >> achieving a good command-line build as well as nice Eclipse integration >> when >> working with OSGi and are targetting the Spring DM server. I've installed >> the Spring tooling from http://www.springsource.org/dmserver and, things >> work very smoothly as far as developing (web) bundles and deploying them >> to >> DM Server from within Eclipse. >> >> Of course I want headless builds as well. Up until now, I've been using >> Maven and m2eclipse for the best of both worlds and I'd like to continue >> using it in conjunction with Tycho. Can this combination of tools play >> nicely with each other when it comes to the various natures/builders >> involved and with the new dependency resolution needed for OSGi? What >> about >> deployment to DM Server or some arbitrary OSGi platform? I don't mind >> duplicated functionality (although I would hope Sonatype and SpringSource >> can avoid this wasted effort) as long as the tools don't step on each >> other's toes. I'd be willing to forgo some parts of the Spring tooling >> functionality if similar features are available with Tycho. >> >> Thanks in advance for any clarity and cheers for the great tools so far, >> >> Adrian Sampaleanu > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > > -- View this message in context: http://www.nabble.com/What-is-the-current-situation-WRT-Spring-Tooling-Spring-DM-Server-and-Maven-Tycho--tp21815222p21861542.html Sent from the Maven Eclipse - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
