Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 342579

Summary:

Support adding properties files from outside of Workspace

Product:

[RT] Virgo

Reporter:

Martin Lippert <mlippert>

Component:

tooling

Assignee:

Leo Dos Santos <leo.dos.santos>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

eclipse, glyn.normington, leo.dos.santos, mlippert

Version:

unspecified

Target Milestone:

1.0.1.RELEASE

Hardware:

OS:

Mac OS X

Whiteboard:

Bug Depends on:

Bug Blocks:

398481

Attachments:

Description	Flags
Screenshot of problematic panel	none

Description Martin Lippert

2011-04-12 10:43:09 EDT

Currently (e.g. in org.eclipse.virgo.kernel.services project in the kernel git repository) there are Bundlor preferences (stored in .settings/com.springsource.server.ide.bundlor.core.prefs) which refer to ../build.versions. This is (correctly) reference on the subject panel.

However, it is not possible to add a similar reference (e.g. to ../build.properties) using the panel, nor is it possible to add the existing (build.versions) reference after deleting it (which is possible). The panel prohibits references to properties files outside of the workspace.

Expectation: to be able to add path references to properties files even if they are outside of the Workspace.

I consider this a bug rather than an enhancement, since it is possible to see (and delete) a reference which it is not possible to add using the panel.

More details can be found here, from where this issue got moved: https://issuetracker.springsource.com/browse/STS-1282)

Comment 1 Miles Parker

2012-01-16 19:00:07 EST

Hmmm...AFAICT Eclipse project build.properties isn't intended to reference artifacts outside of the project itself. The PDE MANIFEST editor definitely chokes on that. My take on the reasoning is that if other people can't get to the file from the same VCS / workspace than it shouldn't be in the build, though on the other hand I can certainly think of cases where this would be a cool thing to do. For example, when maintaining legal files for standard Eclipse plugin projects, it would be great to be able to do that, but it isn't supported because it would break a lot of other tooling.

By "Subject Panel", what UI feature are we referring to? If we're talking about the PDE Manifest editor, or a tooling analog, I'd say this is a WONTFIX, but perhaps I've got the use case wrong.

Comment 2 Miles Parker

2012-01-16 19:07:10 EST

I'm sorry, I realized that I had misread this. You're not intending to modify build.properties, but refer to it. And I see the UI element is referred to in the bug description. :) Still I can find what the bug is referring to. Is this Config Files under Spring:Beans Support?

Comment 3 Glyn Normington

2012-01-17 07:58:35 EST

It is necessary to mark a Virgo project as having the Spring bundle project nature and then enable incremental manifest generation using the project's context menu. Then the manifest generation properties are shown, inaccurately compared to the corresponding properties file. For both the panel and the properties file content, see the attached screenshot.

Comment 4 Glyn Normington

2012-01-17 07:59:29 EST

Created attachment 209619 [details]
Screenshot of problematic panel

Comment 5 Miles Parker

2012-01-17 14:33:46 EST

Thanks for the clarification. I do have org.springframework.ide.eclipse.core.springnature nature but I'm not seeing the Manifest Generation page. I'm not sure why that is.

Comment 6 Miles Parker

2012-07-03 18:58:44 EDT

In fact, we get an NPE when we attempt to add any file!

Comment 7 Miles Parker

2012-09-01 16:20:18 EDT

I'm not sure where we ended up w/ this one. It's not throwing an NPE anymore, but now we're getting an UnsupportedOperationException. I'm not sure if that's because of project setup or something else, but we won't be able to deal with this for release. Reassigning to inbox.

Comment 8 Chris Frost

2013-01-16 11:08:03 EST

*** Bug 398303 has been marked as a duplicate of this bug. ***

Comment 9 Leo Dos Santos

2013-01-21 16:11:30 EST

I think we can add another button that opens up a dialog where you can type in a path (relative or absolute) to a known file. A drawback is that approach probably wouldn't validate that the file actually exists. Another option could be to open up a file selection dialog. That way we guarantee the file exists locally, but the path would be absolute and might not translate across file systems/workspaces. I think the first approach would be easiest and 'good enough'. Thoughts?

Comment 10 Chris Frost

2013-01-21 16:36:30 EST

I think that paths have to be relative. It is better to trust users to put in a file that exists than force then to put the project in a certain location. Would it be possible to display a warning when Bundlor runs if a properties file is missing?

Comment 11 Leo Dos Santos

2013-01-21 18:18:11 EST

When Bundlor runs we can print a warning to the Error Log informing the user that we've skipped over an unresolved file. The tool will just ignore unresolved file paths anyway.

Comment 12 Leo Dos Santos

2013-01-24 18:52:56 EST

http://git.eclipse.org/c/virgo/org.eclipse.virgo.ide.git/commit/?id=9363e195af89f526f26b316e176a7331fb1850db

"Enter Path.." button and dialog has been added to the Bundlor preference page