adrians wrote:
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?
Right, now I see your last name "ran the bell". Sorry about that. Yes, I
am still in Toronto. Get in touch with folks from Thinkdynamics from
time to time, but not often enough unfortunately.
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).
Tycho does not currently support any spring-specific manifest
attributes. Internally, Tycho uses Equinox OSGi resolver, so I am quite
certain current Tycho won't be able to resolve Spring-specific
attributes. I am not sure how hard it is going to be to add this to
tycho, but chances are, it will be quite tricky.
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?
I did not realize Spring was extending OSGi resolution rules, to be
honest. I am planning to extend m2e project configuration framework to
effectively be able to get m2e out of the way. I need this to support
PDE projects, but the same plumbing should work for spring projects too.
As for cli, I really need to see a good sample project to understand how
to build it it properly first. Then I will be able to tell what needs to
be fixed in Tycho to support spring dm.
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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
