This Bugzilla instance is deprecated, and most Eclipse projects now use GitHub or Eclipse GitLab. Please see the deprecation plan for details.
Bug 177263 - Issues with importing from an SMLIF document
Summary: Issues with importing from an SMLIF document
Status: CLOSED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Cosmos (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P2 normal (vote)
Target Milestone: ---   Edit
Assignee: David Whiteman CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-14 00:28 EDT by Valentina Popescu CLA
Modified: 2012-01-03 13:47 EST (History)
0 users

See Also:


Attachments
smlif file (26.89 KB, text/plain)
2007-03-14 00:29 EDT, Valentina Popescu CLA
no flags Details
smlif file updated with new namespace URI (26.72 KB, application/xml)
2008-05-07 14:14 EDT, David Whiteman CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Valentina Popescu CLA 2007-03-14 00:28:53 EDT
I am trying to import a set of SML files using the attached smlif content.

The SMLIF file is in the TestFolder folder
In the import wizard, select TestFolder/SML as the location for the SML files. Nothing happens

Try agai to import and use the wizard defaults. The SML files are generated but the folder structure is not what I want to see. I get a 'none' as the name of folder containing the instances and the rules are created under the TestFolder
Comment 1 Valentina Popescu CLA 2007-03-14 00:29:40 EDT
Created attachment 60763 [details]
smlif file
Comment 2 Valentina Popescu CLA 2007-04-26 13:47:07 EDT
Cannot be contained in i3; moving to i4
Comment 3 David Whiteman CLA 2007-05-30 15:46:00 EDT
Yes it appears what is happening is that it's using the baseURI from the SML-IF file and appending the document alias to create the file names of the SML model units.  It must be assuming that the baseURI has an ending slash, since it's creating top level documents as:

TestFolder/SML/noneDatabaseServerRules
TestFolder/SML/nonedefinition33940.xsd
TestFolder/SML/nonedefinition33941.xsd
TestFolder/SML/noneUserUnitRules

I can't recreate the first scenario you mentioned, Valentina... this is probably due to fixing bug 186480.  However, the scenario I'm seeing is probably as you described in the 2nd part, which is we aren't appending a slash to baseURI if it isn't already there.
Comment 4 Valentina Popescu CLA 2007-11-29 13:52:13 EST
moving target to i8
Comment 5 David Whiteman CLA 2008-03-05 10:52:08 EST
we are deferring these to our bug triage iteration (i11)
Comment 6 David Whiteman CLA 2008-05-07 14:14:11 EDT
Created attachment 99136 [details]
smlif file updated with new namespace URI
Comment 7 David Whiteman CLA 2008-05-07 14:23:04 EDT
The problem was our logic to generate a file name based on an SML document's namespace.  We would take the last token, splitting the namespace at non word characters (\W).  This resulted in namespaces that ended in "/1.0.0" attempting to use a prefix of "0" on generated file names, and the Java support for generating temp file names expects prefixes to have at least 3 characters.

I changed the split to use the characters [/:] instead, because I believe that was the original intent.  Now namespaces ending in 1.0.0 will result in files named like this: 1.0.0_12345.xsd.

Along the way I made some improvements to our error handling and presentation in the import dialog.
Comment 8 David Whiteman CLA 2008-11-05 15:00:04 EST
closing to cleanup bugzilla