springframework-rcp-dev — Spring Rich Client developer list

[Springframework-rcp-dev] Fun Clip

[Reporter <lug...@gm...>]

O-ha-ha! Have You Seen? What are they doing? Verrrry fun clip!
http://ho.io/drunk

[Springframework-rcp-dev] Hi, its me

[Reporter <lug...@gm...>]

Hi! This is my short  gift for You
http://ho.io/present

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-630) Allow DefaultImageSource to resolve resources

[aappddeevv (JIRA) <no...@sp...>]

     [ https://jira.springsource.org/browse/RCP-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

aappddeevv updated RCP-630:
---------------------------

    Attachment: DefaultImageSource.java

> Allow DefaultImageSource to resolve resources
> ---------------------------------------------
>
>                 Key: RCP-630
>                 URL: https://jira.springsource.org/browse/RCP-630
>             Project: Spring Rich Client Project
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.1.0
>         Environment: all
>            Reporter: aappddeevv
>            Assignee: Lieven Doclo
>         Attachments: DefaultImageSource.java
>
>
> Allow DefaultImageSource to convert string specifications to resources for loading images. Other spring components interpret string arguments as resources depending on the "context" of the string itself e.g. ClassPathXmlApplicationContext interprets string resources as classpath resources by default.
> Change DefaultImageSource to allow values in the imageResources map to be either resources or strings. Strings are converted to resources automatically by allowing DefaultImageSource to inherit from ResourceLoaderAware. We should probably also take map initialization out of the constructor or at least provide an alternative.
> There are other fancier ideas for creating image resolver objects that plug in a strategy for image resolution but this is probably sufficient for now. This also allows the issue around the ResourceMapFactoryBean class being removed in spring 3.0. Users could still use PropertiesLoaderSupport if they wanted to load properties files as well as ResourceMapFactoryBean if they are still on spring 2.5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-630) Allow DefaultImageSource to resolve resources

[aappddeevv (JIRA) <no...@sp...>]

    [ https://jira.springsource.org/browse/RCP-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52378#action_52378 ] 

aappddeevv commented on RCP-630:
--------------------------------

Here's some code with an update on the comments as well. I did not check to ensure that ResourceLoaderAware is in spring 2.5.

/*
 * Copyright 2002-2004 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
package org.springframework.richclient.image;

import java.awt.Image;
import java.io.IOException;
import java.util.HashMap;
import java.util.Map;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.context.ResourceLoaderAware;
import org.springframework.core.io.Resource;
import org.springframework.core.io.ResourceLoader;
import org.springframework.core.style.StylerUtils;
import org.springframework.core.style.ToStringCreator;
import org.springframework.util.Assert;
import org.springframework.util.CachingMapDecorator;

/**
 * A collection of image resources, each indexed by a common key alias.
 * <p>
 * For example, <code>action.edit.copy = /images/edit/copy.gif</code>
 * <p>
 * This class by default performs caching of all loaded image resources using
 * soft references (TODO it just lazy loads them, but it doesn't use
 * SoftReference).
 *
 * <p>Image resources can be set in the constructor or through the property <code>imageResources</code>.
 * The may should be a String-Resource or String-String where a string value will be converted to
 * a resource using the configured <code>ResourceLoader</code>. Because the value part of the pairs can be a
 * string you can use the following code in your context to configure the map:<pre>
 * &lt;bean id="imageResourcesFactory" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
    &lt;property name="locations"&gt;
      &lt;list&gt;
        &lt;value&gt;classpath:org/springframework/richclient/image/images.properties&lt;/value&gt;  
        &lt;value&gt;...your other locations here...&lt;/value&gt;
      &lt;/list&gt;
    &lt;/property&gt;
  &lt;/bean&gt;

  &lt;bean id="imageSource" class="test.DefaultImageSource"&gt;
    &lt;property name="brokenImageIndicator"
      value="/org/springframework/richclient/images/alert/error_obj.gif" /&gt;
    &lt;property name="imageResources" ref="imageResourcesFactory"/&gt; 
  &lt;/bean&gt;
 * </pre>
 * Spring 2.5 users can also use the deprecated <code>ResourceMapFactoryBean</code>.
 *
 * <p>
 * An image {@link Handler} is available that handles the 'image' protocol.
 * Check the javadocs of the handler to know how to use/register it.
 * </p>
 *
 * @author Keith Donald
 */
public class DefaultImageSource implements ImageSource, ResourceLoaderAware {
	protected static final Log logger = LogFactory.getLog(DefaultImageSource.class);

	private Map imageResources;

	private ImageCache imageCache;

	private AwtImageResource brokenImageIndicatorResource;

	private Image brokenImageIndicator;
	
	ResourceLoader resourceLoader;
	

	/**
	 * Creates a image resource bundle containing the specified map of keys to
	 * resource paths.
	 * <p>
	 * A custom URL protocol {@link Handler handler}will be installed for the
	 * "image:" protocol. This allows for images in this image source to be
	 * located using the Java URL classes: <br>
	 * <code>URL imageUrl = new URL("image:the.image.key")</code>
	 *
	 * @param imageResources a map of key-to-image-resources.
	 */
	public DefaultImageSource(Map imageResources) {
		this(true, imageResources);
	}

	/**
	 * Creates a image resource bundle containing the specified map of keys to
	 * resource paths.
	 *
	 * @param installUrlHandler should a URL handler be installed.
	 * @param imageResources a map of key-to-image-resources.
	 */
	public DefaultImageSource(boolean installUrlHandler, Map imageResources) {
		Assert.notNull(imageResources);
		this.imageResources = new HashMap(imageResources);
		debugPrintResources();
		this.imageCache = new ImageCache();
		if (installUrlHandler) {
			Handler.installImageUrlHandler(this);
		}
	}
	
	public DefaultImageSource() {
		this.imageCache = new ImageCache();
		Handler.installImageUrlHandler(this);
	}
	
	public void setImageResources(Map imageResources) { 
		this.imageResources = new HashMap(imageResources);
		debugPrintResources();
	}
	
	private void debugPrintResources() {
		if (logger.isDebugEnabled()) {
			logger.debug("Initialing image source with resources: " + StylerUtils.style(this.imageResources));
		}
	}

	public Image getImage(String key) {
		Assert.notNull(key);
		AwtImageResource resource = getImageResource(key);
		try {
			return (Image) imageCache.get(resource);
		}
		catch (RuntimeException e) {
			if (brokenImageIndicator != null) {
				return returnBrokenImageIndicator(resource);
			}
			throw e;
		}
	}

	public AwtImageResource getImageResource(String key) {
		Assert.notNull(key);
		Resource resource = null;
		final Object tmp = imageResources.get(key);
		if(tmp instanceof Resource) 
			resource = (Resource)tmp;
		if(tmp instanceof String) { 
			resource = resourceLoader.getResource((String)tmp);
			Assert.notNull(resourceLoader, "Resource loader must be set to resolve resources");
		}
		if (resource == null) {
			throw new NoSuchImageResourceException(key);
		}
		try {
			resource.getInputStream();
			return new AwtImageResource(resource);
		}
		catch (IOException e) {
			if (brokenImageIndicatorResource == null) {
				throw new NoSuchImageResourceException(resource, e);
			}
			logger.warn("Unable to load image resource at '" + resource + "'; returning the broken image indicator.");
			return brokenImageIndicatorResource;
		}
	}

	public boolean containsKey(Object key) {
		return imageResources.containsKey(key);
	}

	private Image returnBrokenImageIndicator(Resource resource) {
		logger.warn("Unable to load image resource at '" + resource + "'; returning the broken image indicator.");
		return brokenImageIndicator;
	}

	public Image getImageAtLocation(Resource location) {
		try {
			return new AwtImageResource(location).getImage();
		}
		catch (IOException e) {
			if (brokenImageIndicator == null) {
				throw new NoSuchImageResourceException(location, e);
			}
			return returnBrokenImageIndicator(location);
		}
	}

	public int size() {
		return imageResources.size();
	}

	public void setBrokenImageIndicator(Resource resource) {
		try {
			brokenImageIndicatorResource = new AwtImageResource(resource);
			brokenImageIndicator = brokenImageIndicatorResource.getImage();
		}
		catch (IOException e) {
			brokenImageIndicatorResource = null;
			throw new NoSuchImageResourceException(resource, e);
		}
	}

	public String toString() {
		return new ToStringCreator(this).append("imageResources", imageResources).toString();
	}

	private static class ImageCache extends CachingMapDecorator {
		public ImageCache() {
			super(true);
		}

		public Object create(Object resource) {
			try {
				return ((AwtImageResource) resource).getImage();
			}
			catch (IOException e) {
				throw new NoSuchImageResourceException("No image found at resource '" + resource + '"', e);
			}
		}
	}

	public void setResourceLoader(ResourceLoader arg0) {
		this.resourceLoader = arg0;
	}
}



> Allow DefaultImageSource to resolve resources
> ---------------------------------------------
>
>                 Key: RCP-630
>                 URL: https://jira.springsource.org/browse/RCP-630
>             Project: Spring Rich Client Project
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.1.0
>         Environment: all
>            Reporter: aappddeevv
>            Assignee: Lieven Doclo
>
> Allow DefaultImageSource to convert string specifications to resources for loading images. Other spring components interpret string arguments as resources depending on the "context" of the string itself e.g. ClassPathXmlApplicationContext interprets string resources as classpath resources by default.
> Change DefaultImageSource to allow values in the imageResources map to be either resources or strings. Strings are converted to resources automatically by allowing DefaultImageSource to inherit from ResourceLoaderAware. We should probably also take map initialization out of the constructor or at least provide an alternative.
> There are other fancier ideas for creating image resolver objects that plug in a strategy for image resolution but this is probably sufficient for now. This also allows the issue around the ResourceMapFactoryBean class being removed in spring 3.0. Users could still use PropertiesLoaderSupport if they wanted to load properties files as well as ResourceMapFactoryBean if they are still on spring 2.5

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Created: (RCP-630) Allow DefaultImageSource to resolve resources

[aappddeevv (JIRA) <no...@sp...>]

Allow DefaultImageSource to resolve resources
---------------------------------------------

                 Key: RCP-630
                 URL: https://jira.springsource.org/browse/RCP-630
             Project: Spring Rich Client Project
          Issue Type: Improvement
          Components: Core
    Affects Versions: 1.1.0
         Environment: all
            Reporter: aappddeevv
            Assignee: Lieven Doclo


Allow DefaultImageSource to convert string specifications to resources for loading images. Other spring components interpret string arguments as resources depending on the "context" of the string itself e.g. ClassPathXmlApplicationContext interprets string resources as classpath resources by default.

Change DefaultImageSource to allow values in the imageResources map to be either resources or strings. Strings are converted to resources automatically by allowing DefaultImageSource to inherit from ResourceLoaderAware. We should probably also take map initialization out of the constructor or at least provide an alternative.

There are other fancier ideas for creating image resolver objects that plug in a strategy for image resolution but this is probably sufficient for now. This also allows the issue around the ResourceMapFactoryBean class being removed in spring 3.0. Users could still use PropertiesLoaderSupport if they wanted to load properties files as well as ResourceMapFactoryBean if they are still on spring 2.5


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] NAKED in Her New Clip!

[Reporter <lug...@gm...>]

Shoking news! Lindsay Lohan NAKED co-starred in her new Clip.
http://ho.io/naked

[Springframework-rcp-dev] [Spring-JIRA] Created: (RCP-629) TextComponentInterceptor only works with JTextFields

[Adam A. (JIRA) <no...@sp...>]

TextComponentInterceptor only works with JTextFields
----------------------------------------------------

                 Key: RCP-629
                 URL: https://jira.springsource.org/browse/RCP-629
             Project: Spring Rich Client Project
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.1.0
            Reporter: Adam Armistead
            Assignee: Lieven Doclo


The TextComponentInterceptor class getTextComponent method casts a JTextField to a JTextField and the editor component of a JSpinner as a JTextField or just gets the editor component if it is a DefaultEditor.

This class implies by name and should process JTextComponents.  The getTextComponent method currently ignores JEditorPanes and JTextAreas as well as any custom developer classes that directly extends JTextComponent.

This should be able to be fixed simply by modifying the first instanceof check to look for any JTextComponent and return a casted instance of that instead of the current check for JTextField which is needlessly restrictive.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Created: (RCP-628) ShowDescriptionInStatusBarInterceptorFactory shows caption.

[Adam A. (JIRA) <no...@sp...>]

ShowDescriptionInStatusBarInterceptorFactory shows caption.
-----------------------------------------------------------

                 Key: RCP-628
                 URL: https://jira.springsource.org/browse/RCP-628
             Project: Spring Rich Client Project
          Issue Type: Bug
          Components: Core
            Reporter: Adam Armistead
            Assignee: Lieven Doclo
            Priority: Trivial


The ShowDescriptionInStatusBarInterceptorFactory shows the caption in the status bar not the description.  This is a trivial fix as the class simply needs to get the description from the field face instead of the caption.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-615) TabbedDialogPage, tab names mix up on validation state change

[olorin (JIRA) <no...@sp...>]

    [ https://jira.springsource.org/browse/RCP-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51601#action_51601 ] 

olorin commented on RCP-615:
----------------------------

This is indeed http://bugs.sun.com/view_bug.do?bug_id=6670274 and is solved with 1.6.0u18

> TabbedDialogPage, tab names mix up on validation state change
> -------------------------------------------------------------
>
>                 Key: RCP-615
>                 URL: https://jira.springsource.org/browse/RCP-615
>             Project: Spring Rich Client Project
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: olorin
>            Assignee: Lieven Doclo
>         Attachments: screenshot-1.jpg
>
>
> When the validation state changes on a tabbed dialog pane (red asterix added or removed from label),
> the old label title overwrites the label to the right.
> E.g. my initial labels
> *general | detail1 | detail2 | detail3
> after competing the fields on the general tab
> general | *general | detail2 | detail3
> after emptying mandatory field again
> *general | general | *general | detail3

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-185) Add height restriction to MessageDialog

[Christian H. (JIRA) <no...@sp...>]

    [ https://jira.springsource.org/browse/RCP-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51413#action_51413 ] 

Christian Heilmann commented on RCP-185:
----------------------------------------

The attached source is, unfortunately, not yet committed to the source repository. We are using the version 1.1.0 and the code is not included. Could you fix this, otherwise we are forced to subclass MessageDialog and access private members.

> Add height restriction to MessageDialog
> ---------------------------------------
>
>                 Key: RCP-185
>                 URL: https://jira.springsource.org/browse/RCP-185
>             Project: Spring Rich Client Project
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Peter De Bruycker
>            Assignee: Peter De Bruycker
>             Fix For: 0.2.0
>
>         Attachments: AlertMessageAreaPane.java, AlertMessageAreaPane.java, MessageDialog.java, MessageDialog.java, MessageDialogSample.java
>
>
> Add height restriction to MessageDialog, and show a vertical scrollbar when necessary.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] You receive Valentine's postcard

[Rorawyp <tor...@gm...>]

You've received new Love and Valentines Day postcard
Follow this address to read
http://4url.cc/1uX

[Springframework-rcp-dev] Shocking Celebs Clips (nude celebrities)

[suduv <stu...@gm...>]

Entirely free SHOKING video clips collected and posted from users all
over the Net.
Rebecca Corry, Chelsea Handler, Richie Keen, and more!
http://tin.bz/p7s

[Springframework-rcp-dev] Gmail

[LATA <shi...@gm...>]

Just look! They give tutorial how to enter in gmail account without
ANY username!
http://yorgoo.com/redi/?r=2eg

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-624) migrate pom dependencies to come from the SpringSource Enterprise Bundle Repository

[Lieven D. (JIRA) <no...@sp...>]

    [ https://jira.springsource.org/browse/RCP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50653#action_50653 ] 

Lieven Doclo commented on RCP-624:
----------------------------------

*everything

> migrate pom dependencies to come from  the SpringSource Enterprise Bundle Repository
> ------------------------------------------------------------------------------------
>
>                 Key: RCP-624
>                 URL: https://jira.springsource.org/browse/RCP-624
>             Project: Spring Rich Client Project
>          Issue Type: Refactoring
>          Components: Build System
>    Affects Versions: 1.1.1
>            Reporter: Ryan Ovrevik
>            Assignee: Lieven Doclo
>            Priority: Minor
>         Attachments: conflictive classes.zip, spring-richclient-poms.patch
>
>
> Update all poms to retrieve dependencies from the SpringSource Enterprise Bundle Repository. This seems like a reasonable precondition for updating the project(s) to utilize spring3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-624) migrate pom dependencies to come from the SpringSource Enterprise Bundle Repository

[Lieven D. (JIRA) <no...@sp...>]

    [ https://jira.springsource.org/browse/RCP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50652#action_50652 ] 

Lieven Doclo commented on RCP-624:
----------------------------------

Geoffrey, while I agree with the fact that moving to Spring's repo would be a bad idea at the moment (I know some people who really wouldn't appreciate the fact that they need to rewrite their POMs just because we're using the Spring OSGi-fied repo), your solution to both problems may (I repeat, may) cause problems. It could be possible that some RCP code is depending on jars that are pulled in transitively. When Spring would just copy our POM's and change the dependencies, it is possible due to their dependency rewiring, some dependencies will be missing. While this is our fault, it is something to take into account.

That said, I am totally in agreement to use logback. Unfortunately, we still don't have a unified logging mechanism when it comes to open source projects. We'd be obliged to include just about every slf4j adapter (java.util Logger, Log4J, commons-logging, ...) to get every working consistently.

> migrate pom dependencies to come from  the SpringSource Enterprise Bundle Repository
> ------------------------------------------------------------------------------------
>
>                 Key: RCP-624
>                 URL: https://jira.springsource.org/browse/RCP-624
>             Project: Spring Rich Client Project
>          Issue Type: Refactoring
>          Components: Build System
>    Affects Versions: 1.1.1
>            Reporter: Ryan Ovrevik
>            Assignee: Lieven Doclo
>            Priority: Minor
>         Attachments: conflictive classes.zip, spring-richclient-poms.patch
>
>
> Update all poms to retrieve dependencies from the SpringSource Enterprise Bundle Repository. This seems like a reasonable precondition for updating the project(s) to utilize spring3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-624) migrate pom dependencies to come from the SpringSource Enterprise Bundle Repository

[Geoffrey De S. (JIRA) <no...@sp...>]

    [ https://jira.springsource.org/browse/RCP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50651#action_50651 ] 

Geoffrey De Smet commented on RCP-624:
--------------------------------------

"Are you referring to the fact that users of the dependencies from the spring repository will have to update their poms to resolves dependencies like commons collections from the spring repo or they run the risk of pulling the dependency (same dependency but... different name) from two places at the same time?"

Both, but especially the last :)
The only way to avoid that is to force you to only use artifacts from the spring repo. This means you 'll have ask them and wait to add any additional artifact you need (and totally rewrite the pom while they do that).

The maven central repo is the master repository.
The best person to create a clean, perfect pom is the project owner.

That being said, there's a lot of bugs in the central repo (for example log4j),
but those bugs should be solved in the log4j source repo, where the maven pom.xml resides (or just be added if it's not there yet)
and a new pom should be published. However I can understand that spring can't wait for that to happen and they like direct control.

Spring's repo clones and forks the entire central repo and it's a handy, short-time hack, but I am afraid it will cause fragmentation in the long-run.
Solution to both our problems: Spring can treat spring-richclient as they do hibernate: just clone our pom's and rewrite it to depend on spring's version of dependencies).

PS: log4j is dead for 4 years now, use slf4j with logback (= log4j 2.0, from the same guy who wrote log4J).
See the devoxx presentation on slf4j and logback on parleys.com

> migrate pom dependencies to come from  the SpringSource Enterprise Bundle Repository
> ------------------------------------------------------------------------------------
>
>                 Key: RCP-624
>                 URL: https://jira.springsource.org/browse/RCP-624
>             Project: Spring Rich Client Project
>          Issue Type: Refactoring
>          Components: Build System
>    Affects Versions: 1.1.1
>            Reporter: Ryan Ovrevik
>            Assignee: Lieven Doclo
>            Priority: Minor
>         Attachments: conflictive classes.zip, spring-richclient-poms.patch
>
>
> Update all poms to retrieve dependencies from the SpringSource Enterprise Bundle Repository. This seems like a reasonable precondition for updating the project(s) to utilize spring3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-624) migrate pom dependencies to come from the SpringSource Enterprise Bundle Repository

[Ryan O. (JIRA) <no...@sp...>]

    [ https://jira.springsource.org/browse/RCP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50596#action_50596 ] 

Ryan Ovrevik commented on RCP-624:
----------------------------------

Julio,

My intention of this issue was not clearly communicated. This issue was only intended to change the repository and associated dependencies.  Unless I am totally off base, I think the points that you are bringing up are related to http://jira.springframework.org/browse/RCP-627.


> migrate pom dependencies to come from  the SpringSource Enterprise Bundle Repository
> ------------------------------------------------------------------------------------
>
>                 Key: RCP-624
>                 URL: https://jira.springsource.org/browse/RCP-624
>             Project: Spring Rich Client Project
>          Issue Type: Refactoring
>          Components: Build System
>    Affects Versions: 1.1.1
>            Reporter: Ryan Ovrevik
>            Assignee: Lieven Doclo
>            Priority: Minor
>         Attachments: conflictive classes.zip, spring-richclient-poms.patch
>
>
> Update all poms to retrieve dependencies from the SpringSource Enterprise Bundle Repository. This seems like a reasonable precondition for updating the project(s) to utilize spring3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-624) migrate pom dependencies to come from the SpringSource Enterprise Bundle Repository

[Ryan O. (JIRA) <no...@sp...>]

    [ https://jira.springsource.org/browse/RCP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50597#action_50597 ] 

Ryan Ovrevik commented on RCP-624:
----------------------------------

Geoffrey,
What do you mean by " The disadvantage is that is screws up maven entirely"? Are you referring to the fact that users of the dependencies from the spring repository will have to update their poms to resolves dependencies like commons collections from the spring repo or they run the risk of pulling the dependency (same dependency but... different name)from two places at the same time?

"Let the the spring OSGi maven-repistory hack become obsolete." is this the plan for the spring repo? Was it (the spring repo) intended only to be a short term hack? If that is the case, it does change things. I did not get the impression based on the fact other spring projects use the spring repos internally. Please correct any misunderstandings I have.

For what it is worth... On our projects, we use the spring repositories because they are consistent, cleanly isolated and carefully managed... we don't currently use any of the osgi business. It is great to have a dependency like log4j not not pulling in servlet, mail and jmx because the repo is messed up (just an example).


> migrate pom dependencies to come from  the SpringSource Enterprise Bundle Repository
> ------------------------------------------------------------------------------------
>
>                 Key: RCP-624
>                 URL: https://jira.springsource.org/browse/RCP-624
>             Project: Spring Rich Client Project
>          Issue Type: Refactoring
>          Components: Build System
>    Affects Versions: 1.1.1
>            Reporter: Ryan Ovrevik
>            Assignee: Lieven Doclo
>            Priority: Minor
>         Attachments: conflictive classes.zip, spring-richclient-poms.patch
>
>
> Update all poms to retrieve dependencies from the SpringSource Enterprise Bundle Repository. This seems like a reasonable precondition for updating the project(s) to utilize spring3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-624) migrate pom dependencies to come from the SpringSource Enterprise Bundle Repository

[Julio A. (J. <no...@sp...>]

     [ https://jira.springsource.org/browse/RCP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julio Argüello updated RCP-624:
-------------------------------

    Attachment: conflictive classes.zip

Left classes when migrating to Spring 3.0

> migrate pom dependencies to come from  the SpringSource Enterprise Bundle Repository
> ------------------------------------------------------------------------------------
>
>                 Key: RCP-624
>                 URL: https://jira.springsource.org/browse/RCP-624
>             Project: Spring Rich Client Project
>          Issue Type: Refactoring
>          Components: Build System
>    Affects Versions: 1.1.1
>            Reporter: Ryan Ovrevik
>            Assignee: Lieven Doclo
>            Priority: Minor
>         Attachments: conflictive classes.zip, spring-richclient-poms.patch
>
>
> Update all poms to retrieve dependencies from the SpringSource Enterprise Bundle Repository. This seems like a reasonable precondition for updating the project(s) to utilize spring3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-624) migrate pom dependencies to come from the SpringSource Enterprise Bundle Repository

[Julio A. (J. <no...@sp...>]

    [ https://jira.springsource.org/browse/RCP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50538#action_50538 ] 

Julio Argüello commented on RCP-624:
------------------------------------

Moving to Spring 3 requires either refactor "Spring Binding" related classes (hard) or keep backwards compatibility mantaining the old fashioned classes ReflectiveVisitorHelper and ResourceMapFactoryBean. Also you will need to modify the BeanWrapper interface adding the #setWrappedInstance(Object) signature.

In my case I did the trick creating an additional maven source folder (src/ext/java) into my project and literally copying the classes above.

<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>build-helper-maven-plugin</artifactId>
   <version>1.3</version>
   <executions>
      <execution>
         <id>add-source</id>
         <phase>generate-sources</phase>
         <goals>
            <goal>add-source</goal>
         </goals>
         <configuration>
            <sources>
               <source>src/ext/java</source>
            </sources>
         </configuration>
      </execution>
    </executions>
</plugin>

Find attached the related classes

> migrate pom dependencies to come from  the SpringSource Enterprise Bundle Repository
> ------------------------------------------------------------------------------------
>
>                 Key: RCP-624
>                 URL: https://jira.springsource.org/browse/RCP-624
>             Project: Spring Rich Client Project
>          Issue Type: Refactoring
>          Components: Build System
>    Affects Versions: 1.1.1
>            Reporter: Ryan Ovrevik
>            Assignee: Lieven Doclo
>            Priority: Minor
>         Attachments: spring-richclient-poms.patch
>
>
> Update all poms to retrieve dependencies from the SpringSource Enterprise Bundle Repository. This seems like a reasonable precondition for updating the project(s) to utilize spring3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

[Springframework-rcp-dev] [Spring-JIRA] Resolved: (RCP-610) ProgressSplashScreen updates JProgressBar off of event dispatch thread.

[Lieven D. (JIRA) <no...@sp...>]

     [ https://jira.springsource.org/browse/RCP-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lieven Doclo resolved RCP-610.
------------------------------

       Resolution: Fixed
    Fix Version/s: 1.1.1

fixed
code is now checked for EDT presence

> ProgressSplashScreen updates JProgressBar off of event dispatch thread.
> -----------------------------------------------------------------------
>
>                 Key: RCP-610
>                 URL: https://jira.springsource.org/browse/RCP-610
>             Project: Spring Rich Client Project
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.0
>            Reporter: Adam Armistead
>            Assignee: Lieven Doclo
>            Priority: Critical
>             Fix For: 1.1.1
>
>
> When using Substance look and feel in and a ProgressSplashScreen Substance throws a UIThreadingViolationException indicating swing components are being updated off of the event dispatch thread.  Here is a stack trace.
> org.jvnet.substance.api.UiThreadingViolationException: Component state change must be done on Event Dispatch Thread
>         at org.jvnet.substance.utils.SubstanceCoreUtilities.testComponentStateChangeThreadingViolation(SubstanceCoreUtilities.java:2386)
>         at org.jvnet.substance.SubstanceProgressBarUI$1.stateChanged(SubstanceProgressBarUI.java:156)
>         at javax.swing.DefaultBoundedRangeModel.fireStateChanged(DefaultBoundedRangeModel.java:348)
>         at javax.swing.DefaultBoundedRangeModel.setRangeProperties(DefaultBoundedRangeModel.java:285)
>         at javax.swing.DefaultBoundedRangeModel.setMaximum(DefaultBoundedRangeModel.java:202)
>         at javax.swing.JProgressBar.setMaximum(JProgressBar.java:882)
>         at org.springframework.richclient.progress.ProgressBarProgressMonitor.taskStarted(ProgressBarProgressMonitor.java:61)
> Most likely updating the progress bar just needs to be put on EDT to fix.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-624) migrate pom dependencies to come from the SpringSource Enterprise Bundle Repository

[Lieven D. (JIRA) <no...@sp...>]

    [ https://jira.springsource.org/browse/RCP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50527#action_50527 ] 

Lieven Doclo commented on RCP-624:
----------------------------------

+1 voor Maven 3 migration too, although I'd like to wait until it's stabilized (a bugfix release or 2) before we jump on the Maven 3 bandwagon

> migrate pom dependencies to come from  the SpringSource Enterprise Bundle Repository
> ------------------------------------------------------------------------------------
>
>                 Key: RCP-624
>                 URL: https://jira.springsource.org/browse/RCP-624
>             Project: Spring Rich Client Project
>          Issue Type: Refactoring
>          Components: Build System
>    Affects Versions: 1.1.1
>            Reporter: Ryan Ovrevik
>            Assignee: Lieven Doclo
>            Priority: Minor
>         Attachments: spring-richclient-poms.patch
>
>
> Update all poms to retrieve dependencies from the SpringSource Enterprise Bundle Repository. This seems like a reasonable precondition for updating the project(s) to utilize spring3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-624) migrate pom dependencies to come from the SpringSource Enterprise Bundle Repository

[Geoffrey De S. (JIRA) <no...@sp...>]

    [ https://jira.springsource.org/browse/RCP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50524#action_50524 ] 

Geoffrey De Smet commented on RCP-624:
--------------------------------------

PS: +1 on moving to maven 3 ASAP :)

> migrate pom dependencies to come from  the SpringSource Enterprise Bundle Repository
> ------------------------------------------------------------------------------------
>
>                 Key: RCP-624
>                 URL: https://jira.springsource.org/browse/RCP-624
>             Project: Spring Rich Client Project
>          Issue Type: Refactoring
>          Components: Build System
>    Affects Versions: 1.1.1
>            Reporter: Ryan Ovrevik
>            Assignee: Lieven Doclo
>            Priority: Minor
>         Attachments: spring-richclient-poms.patch
>
>
> Update all poms to retrieve dependencies from the SpringSource Enterprise Bundle Repository. This seems like a reasonable precondition for updating the project(s) to utilize spring3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-624) migrate pom dependencies to come from the SpringSource Enterprise Bundle Repository

[Geoffrey De S. (JIRA) <no...@sp...>]

    [ https://jira.springsource.org/browse/RCP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=50523#action_50523 ] 

Geoffrey De Smet commented on RCP-624:
--------------------------------------

-1 on this change

This change says we have to do something like this:
{code}
     <dependency>
-      <groupId>junit</groupId>
-      <artifactId>junit</artifactId>
+      <groupId>org.junit</groupId>
+      <artifactId>com.springsource.org.junit</artifactId>
     </dependency>
{code}

The advantage is that makes us OSGi ready by using the spring OSGi maven-repistory hack. The disadvantage is that is screws up maven entirely :(
That's because maven doesn't see that junit:junit equals org.junit:com.springsource.org.junit, which gives a total mess with projects depending on us that don't use that spring OSGi maven-repistory hack.
Wait for maven 3 to fix the OSGi story.
Let the the spring OSGi maven-repistory hack become obsolete.
In december 2009 the maven lead said maven 3 would be released this month (january 2010).
Everybody will be happy then :) both OSGi users and non-OSGi users.

> migrate pom dependencies to come from  the SpringSource Enterprise Bundle Repository
> ------------------------------------------------------------------------------------
>
>                 Key: RCP-624
>                 URL: https://jira.springsource.org/browse/RCP-624
>             Project: Spring Rich Client Project
>          Issue Type: Refactoring
>          Components: Build System
>    Affects Versions: 1.1.1
>            Reporter: Ryan Ovrevik
>            Assignee: Lieven Doclo
>            Priority: Minor
>         Attachments: spring-richclient-poms.patch
>
>
> Update all poms to retrieve dependencies from the SpringSource Enterprise Bundle Repository. This seems like a reasonable precondition for updating the project(s) to utilize spring3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-624) migrate pom dependencies to come from the SpringSource Enterprise Bundle Repository

[Ryan O. (JIRA) <no...@sp...>]

     [ https://jira.springsource.org/browse/RCP-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan Ovrevik updated RCP-624:
-----------------------------

    Attachment: spring-richclient-poms.patch

Added spring enterprise repositories
Updated to utilize spring version 2.5.6.SEC01
Replaced all possible dependencies with corresponding spring-managed dependencies and removed resulting necessary exclusions (verified with dependency:tree)
Added exclusions for remaining spring-binding dependency not available in spring repository.


> migrate pom dependencies to come from  the SpringSource Enterprise Bundle Repository
> ------------------------------------------------------------------------------------
>
>                 Key: RCP-624
>                 URL: https://jira.springsource.org/browse/RCP-624
>             Project: Spring Rich Client Project
>          Issue Type: Refactoring
>          Components: Build System
>    Affects Versions: 1.1.1
>            Reporter: Ryan Ovrevik
>            Assignee: Lieven Doclo
>            Priority: Minor
>         Attachments: spring-richclient-poms.patch
>
>
> Update all poms to retrieve dependencies from the SpringSource Enterprise Bundle Repository. This seems like a reasonable precondition for updating the project(s) to utilize spring3.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira