Trying out a new route...

[LievenDoclo]

Julio,

I've tried that approach too, but I ended up not choosing it for various reasons:
- dependency on "magic" strings (your aliases)
- the default implementations would still get loaded even if you provide your own implementation, which means a larger memory footprint (could be mediated with lazy beans, but still something to be avoided).
- it just ended up more difficult than the current solution (now you have type safety, something you don't have when using property file based injection with aliases, and something I find quite important)

Also, the only reason why I'd use a property file for certain things, is for those things I expect to change in production environments. As far as I know, being able to switch implementations of services while in production isn't a good practice. Which implementations you inject just isn't something you should be able to configure and change at runtime.
Perhaps a couple percent of the applications out there may need a functionality like this, but that doesn't justify the potential increased complexity.

[julio.arguello]

Thanks indeed for you response.

IMHO:

1. Magic string
   

   - dependency on "magic" strings (your aliases)

   It is not really a pitfall, anyway you can access al declared services at a single point. It's just a question of convention CoC

1. Overriden implementations
   

   the default implementations would still get loaded even if you provide your own implementation

   It sounds good but I don't know how to avoid loading overriden implementations. May be I need to learn more about Spring 3 (annotations support).

1. Type safety
   

   it just ended up more difficult than the current solution

   I agree with you.

[akuhtz]

Hi Lieven,

Many thanks for working on the project again. I've pulled the code from the repo and had to manually remove 2 imports to get it run (after importing the jide-oss to my repo).
Is there any location (JIRA ?) set up where we can provide patches?

Cheers
Andi

[adamarmistead]

When pulling the main trunk from the repository and trying to build I also had trouble building it. Only 2 issues though, one bad jar version.

--- aspectj-maven-plugin:1.3:compile (default) @ valkyrie-rcp-core ---
[WARNING] bad version number found in <my base dir>\.m2\repository\org\aspectj\aspectjrt\1.6.8\as pectjrt-1.6.8.jar expected 1.6.7 found 1.6.8
[WARNING] advice defined in org.springframework.orm.jpa.aspectj.JpaExceptionTr anslatorAspect has not been applied [Xlint:adviceDidNotMatch]
... some more warnings like this one ...


and the missing jides-oss stuff. According to https://jide-oss.dev.java.net/ at the bottom of the page under the Maven Repository section is mentions specifying the repository in the pom. I'm don't use maven much, so it looks like the pom should have something like this in it to access the jides-oss jar.

<repositories>
<repository>
<id>maven2-repository.dev.java.net</id>
<name>Java.net Repository for Maven</name>
<url>http://download.java.net/maven/2/</url>
<layout>default</layout>
</repository>
</repositories>

But I'm not sure where to put it. I tried putting it in the top level Valkyrie pom, and it compiles, but it complains something about a 'system' scoped dependency being found. And if I put it in the Valkyrie Jide OSS integration pom it downloads the jar, but then complains about a 'system' scope dependency not being found. So *shrug*.

As for the BlueBell OverlayService and its custom RepaintManager, here is another way you can get the same effect without providing a custom RepaintManager or GlassPane. I tend to favor JXLayer whenever I am tempted to use glass panes or repaint managers, as those are problematic if for some reason an application is using its own custom implementation of one of those.

http://free-the-pixel.blogspot.com/2...-overlays.html

[akuhtz]

Unfortunately the latest version of jide-oss is not in the repo you specified (just up to 2.10.2). But you can either download the newest version of jide-oss and put it into your local repo or change the version that is used to 2.10.2 (hoping that nothing was fixed since this version that is needed).

[LievenDoclo]

Regarding the missing dependencies, I'm planning on contacting Sonatype in order to get a opensource repository where we can deploy some of our dependencies. Or we need to find someone able to host a Nexus repository. Either way you'll have to change your local Maven settings in order to add the needed repository to your local build. According to Maven rules, no external repositories should be included in a POM.

I just used the latest JideOSS version available.

The AspectJ error doesn't seem to have adverse effects aside from a warning.

By the way, Adam, if you want you can adapt the OverlayService according to that blogpost.

[adamarmistead]

According to Maven rules, no external repositories should be included in a POM.

hehe, learn something new all the time.

...you can adapt the OverlayService according to that blogpost.

I'll totally give it a shot as soon as I have some time.

[opticyclic]

The main thing that the project needs is someone to pull all the documentation together in one place and provide transparancy on what to use and how to use it.
Is there going to be a consolidation any time soon with instructions on which version is best to use and some quick sample projects to demonstrate it?

[enavarrocu]

A lot of people are waiting for a new release of Spring RCP, so I think a good idea will be port Valkyrie to Spring RCP creating the version 2. Also can be merge with Bluebell but always keep the Spring RCP name. Even if the people have to port the old version of applications to the version 2 of Spring RCP.

Thanks a lot for all the work you and the other people do in Spring RCP.

[julio.arguello]

Perhaps you'll find usefull this post:
http://forum.springsource.org/showth...544#post351544

Bluebell demos are now online. It will be a pleasure for me to collaborate with Spring RCP guys.