Edi Conversion Tool
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Edi Conversion Tool
by Bård Langöy
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi, I have finally checked in the first parts
of the Edi Convert Tool. The code does not exist in the trunk yet, but can be
downloaded at: https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT The conversion tool converts the zipped un/edifact
specifications located at http://www.unece.org/trade/untdid/down_index.htm
into Smooks configuration files (mapping-files) . I have created a test-case
that demonstrates the whole procedure: ConfigReaderTest. test_Converting_UnEdifact_D08A().
But in general the conversion-tool takes
the following arguments: ·
InFile – the zip-file
containing the un/edifact specs. ·
outDir – the directory to
put the generated configuration-files. ·
message – The name of the
message to parse. In the testcase example I am generating the INVOIC message.
It is also possible to generate all messages by writing ALL. Today the conversion tool only handles zip-files.
An improvement would be to check whether it is a zip-file or an unzipped
directory. Also, when writing the testcases I found
that the segments UNH and UNT are not located in the zip-file containing the
specification :(. I have handwritten a config-file (un-edifact-interchange-definition.xml)
that will be used for now. But in the future it would be nice if we could find
the location/url of the interchange envelope specification. Regards, Bård |
|
|
Re: Edi Conversion Tool
by Maurice Zeijen-2
::
Rate this Message:
Great work bard. I think that this is one of greatets new parts of Smooks :).
M. On Sun, Nov 8, 2009 at 9:36 AM, Bård Langöy <bardl@...> wrote:
|
|
|
Re: Edi Conversion Tool
by TomFennelly
::
Rate this Message:
This stuff is awesome Bard. I will be looking at it ASAP!! I might also
look at creating Ant and Maven plugins for this, as well as integrating it with EJC. Bård Langöy wrote: > > Hi, > > I have finally checked in the first parts of the Edi Convert Tool. The > code does not exist in the trunk yet, but can be downloaded at: > https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT > > The conversion tool converts the zipped un/edifact specifications > located at http://www.unece.org/trade/untdid/down_index.htm into > Smooks configuration files (mapping-files) . I have created a > test-case that demonstrates the whole procedure: ConfigReaderTest. > test_Converting_UnEdifact_D08A(). > > But in general the conversion-tool takes the following arguments: > > · InFile – the zip-file containing the un/edifact specs. > > · outDir – the directory to put the generated configuration-files. > > · message – The name of the message to parse. In the testcase example > I am generating the INVOIC message. It is also possible to generate > all messages by writing ALL. > > Today the conversion tool only handles zip-files. An improvement would > be to check whether it is a zip-file or an unzipped directory. > > Also, when writing the testcases I found that the segments UNH and UNT > are not located in the zip-file containing the specification :(. I > have handwritten a config-file (un-edifact-interchange-definition.xml) > that will be used for now. But in the future it would be nice if we > could find the location/url of the interchange envelope specification. > > Regards, > > Bård** > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
SV: Edi Conversion Tool
by Bård Langöy
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Maurice, Thanks ! J I hope people will
find it useful. Regards, Bård Från: Maurice Zeijen
[mailto:smies.com@...] Great work bard. I think that
this is one of greatets new parts of Smooks :). On Sun, Nov 8, 2009 at 9:36 AM, Bård Langöy <bardl@...> wrote: Hi, I have finally checked in the first parts of the Edi Convert Tool.
The code does not exist in the trunk yet, but can be downloaded at: https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT The conversion tool converts the zipped un/edifact specifications
located at http://www.unece.org/trade/untdid/down_index.htm into
Smooks configuration files (mapping-files) . I have created a test-case that
demonstrates the whole procedure: ConfigReaderTest.
test_Converting_UnEdifact_D08A(). But in general the conversion-tool takes the following arguments: · InFile – the zip-file containing the un/edifact specs. · outDir – the directory to put the generated configuration-files. · message – The name of the message to parse. In the testcase example
I am generating the INVOIC message. It is also possible to generate all
messages by writing ALL. Today the conversion tool only handles zip-files. An
improvement would be to check whether it is a zip-file or an unzipped
directory. Also, when writing the testcases I found that the segments UNH and
UNT are not located in the zip-file containing the specification :(. I have
handwritten a config-file (un-edifact-interchange-definition.xml) that will be
used for now. But in the future it would be nice if we could find the
location/url of the interchange envelope specification. Regards, Bård |
|
|
SV: Edi Conversion Tool
by Bård Langöy
::
Rate this Message:
Hi Tom,
Yes that would be great ! When integrating the ECT with the EJC it would be great to add the new documentation element as javadoc in the generated classes. Will you do that or should I take a look at it ? Regards, Bård -----Ursprungligt meddelande----- Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 8 november 2009 21:48 Till: dev@... Ämne: Re: [milyn-dev] Edi Conversion Tool This stuff is awesome Bard. I will be looking at it ASAP!! I might also look at creating Ant and Maven plugins for this, as well as integrating it with EJC. Bård Langöy wrote: > > Hi, > > I have finally checked in the first parts of the Edi Convert Tool. The > code does not exist in the trunk yet, but can be downloaded at: > https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT > > The conversion tool converts the zipped un/edifact specifications > located at http://www.unece.org/trade/untdid/down_index.htm into > Smooks configuration files (mapping-files) . I have created a > test-case that demonstrates the whole procedure: ConfigReaderTest. > test_Converting_UnEdifact_D08A(). > > But in general the conversion-tool takes the following arguments: > > · InFile - the zip-file containing the un/edifact specs. > > · outDir - the directory to put the generated configuration-files. > > · message - The name of the message to parse. In the testcase example > I am generating the INVOIC message. It is also possible to generate > all messages by writing ALL. > > Today the conversion tool only handles zip-files. An improvement would > be to check whether it is a zip-file or an unzipped directory. > > Also, when writing the testcases I found that the segments UNH and UNT > are not located in the zip-file containing the specification :(. I > have handwritten a config-file (un-edifact-interchange-definition.xml) > that will be used for now. But in the future it would be nice if we > could find the location/url of the interchange envelope specification. > > Regards, > > Bård** > --------------------------------------------------------------------- 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 |
|
|
Re: Edi Conversion Tool
by Daniel Bevenius
::
Rate this Message:
Cool, I'll try it out as soon as I get a chance!
/Dan 2009/11/9 Bård Langöy <bardl@...> Hi Tom, |
|
|
Re: SV: Edi Conversion Tool
by TomFennelly
::
Rate this Message:
Hey Bard.
Well first thing I plan on doing is just looking at it. I suppose the best thing we should do for now is get what you have sorted out and checked into trunk. Then we can look at adding the plugins and EJC. Yeah? T. Bård Langöy wrote: > Hi Tom, > > Yes that would be great ! When integrating the ECT with the EJC it would be great to add the new documentation element as javadoc in the generated classes. Will you do that or should I take a look at it ? > > > Regards, > Bård > > > > -----Ursprungligt meddelande----- > Från: Tom Fennelly [mailto:tom.fennelly@...] > Skickat: den 8 november 2009 21:48 > Till: dev@... > Ämne: Re: [milyn-dev] Edi Conversion Tool > > This stuff is awesome Bard. I will be looking at it ASAP!! I might also > look at creating Ant and Maven plugins for this, as well as integrating > it with EJC. > > Bård Langöy wrote: > >> Hi, >> >> I have finally checked in the first parts of the Edi Convert Tool. The >> code does not exist in the trunk yet, but can be downloaded at: >> https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT >> >> The conversion tool converts the zipped un/edifact specifications >> located at http://www.unece.org/trade/untdid/down_index.htm into >> Smooks configuration files (mapping-files) . I have created a >> test-case that demonstrates the whole procedure: ConfigReaderTest. >> test_Converting_UnEdifact_D08A(). >> >> But in general the conversion-tool takes the following arguments: >> >> · InFile - the zip-file containing the un/edifact specs. >> >> · outDir - the directory to put the generated configuration-files. >> >> · message - The name of the message to parse. In the testcase example >> I am generating the INVOIC message. It is also possible to generate >> all messages by writing ALL. >> >> Today the conversion tool only handles zip-files. An improvement would >> be to check whether it is a zip-file or an unzipped directory. >> >> Also, when writing the testcases I found that the segments UNH and UNT >> are not located in the zip-file containing the specification :(. I >> have handwritten a config-file (un-edifact-interchange-definition.xml) >> that will be used for now. But in the future it would be nice if we >> could find the location/url of the interchange envelope specification. >> >> Regards, >> >> Bård** >> >> > > --------------------------------------------------------------------- > 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 > > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
SV: Edi Conversion Tool
by Bård Langöy
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Great Dan, Look forward hearing what you think about the tool ! Regards, Bård Från: Daniel Bevenius
[mailto:daniel.bevenius@...] Cool, I'll try it out as soon
as I get a chance! 2009/11/9 Bård Langöy <bardl@...> Hi Tom, Till: dev@... This stuff is awesome Bard. I
will be looking at it ASAP!! I might also |
|
|
SV: SV: Edi Conversion Tool
by Bård Langöy
::
Rate this Message:
Hi Tom,
Should I check in the stuff now or do you want to look at it first ? Regards, Bård -----Ursprungligt meddelande----- Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 november 2009 15:50 Till: dev@... Ämne: Re: SV: [milyn-dev] Edi Conversion Tool Hey Bard. Well first thing I plan on doing is just looking at it. I suppose the best thing we should do for now is get what you have sorted out and checked into trunk. Then we can look at adding the plugins and EJC. Yeah? T. Bård Langöy wrote: > Hi Tom, > > Yes that would be great ! When integrating the ECT with the EJC it would be great to add the new documentation element as javadoc in the generated classes. Will you do that or should I take a look at it ? > > > Regards, > Bård > > > > -----Ursprungligt meddelande----- > Från: Tom Fennelly [mailto:tom.fennelly@...] > Skickat: den 8 november 2009 21:48 > Till: dev@... > Ämne: Re: [milyn-dev] Edi Conversion Tool > > This stuff is awesome Bard. I will be looking at it ASAP!! I might also > look at creating Ant and Maven plugins for this, as well as integrating > it with EJC. > > Bård Langöy wrote: > >> Hi, >> >> I have finally checked in the first parts of the Edi Convert Tool. The >> code does not exist in the trunk yet, but can be downloaded at: >> https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT >> >> The conversion tool converts the zipped un/edifact specifications >> located at http://www.unece.org/trade/untdid/down_index.htm into >> Smooks configuration files (mapping-files) . I have created a >> test-case that demonstrates the whole procedure: ConfigReaderTest. >> test_Converting_UnEdifact_D08A(). >> >> But in general the conversion-tool takes the following arguments: >> >> · InFile - the zip-file containing the un/edifact specs. >> >> · outDir - the directory to put the generated configuration-files. >> >> · message - The name of the message to parse. In the testcase example >> I am generating the INVOIC message. It is also possible to generate >> all messages by writing ALL. >> >> Today the conversion tool only handles zip-files. An improvement would >> be to check whether it is a zip-file or an unzipped directory. >> >> Also, when writing the testcases I found that the segments UNH and UNT >> are not located in the zip-file containing the specification :(. I >> have handwritten a config-file (un-edifact-interchange-definition.xml) >> that will be used for now. But in the future it would be nice if we >> could find the location/url of the interchange envelope specification. >> >> Regards, >> >> Bård** >> >> > > --------------------------------------------------------------------- > 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 > > > > --------------------------------------------------------------------- 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 |
|
|
Re: SV: SV: Edi Conversion Tool
by TomFennelly
::
Rate this Message:
Hey Bard..... if it builds and doesn't break the build lets go for it
and check it into trunk. We can still make changes to it from there, but I'd prefer to get this out into the wild asap in a snapshot. The more feedback we get the better. We can be playing with it and refining it ourselves too!!! Bård Langöy wrote: > Hi Tom, > > Should I check in the stuff now or do you want to look at it first ? > > Regards, > Bård > > -----Ursprungligt meddelande----- > Från: Tom Fennelly [mailto:tom.fennelly@...] > Skickat: den 10 november 2009 15:50 > Till: dev@... > Ämne: Re: SV: [milyn-dev] Edi Conversion Tool > > Hey Bard. > > Well first thing I plan on doing is just looking at it. I suppose the > best thing we should do for now is get what you have sorted out and > checked into trunk. Then we can look at adding the plugins and EJC. Yeah? > > T. > > > Bård Langöy wrote: > >> Hi Tom, >> >> Yes that would be great ! When integrating the ECT with the EJC it would be great to add the new documentation element as javadoc in the generated classes. Will you do that or should I take a look at it ? >> >> >> Regards, >> Bård >> >> >> >> -----Ursprungligt meddelande----- >> Från: Tom Fennelly [mailto:tom.fennelly@...] >> Skickat: den 8 november 2009 21:48 >> Till: dev@... >> Ämne: Re: [milyn-dev] Edi Conversion Tool >> >> This stuff is awesome Bard. I will be looking at it ASAP!! I might also >> look at creating Ant and Maven plugins for this, as well as integrating >> it with EJC. >> >> Bård Langöy wrote: >> >> >>> Hi, >>> >>> I have finally checked in the first parts of the Edi Convert Tool. The >>> code does not exist in the trunk yet, but can be downloaded at: >>> https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT >>> >>> The conversion tool converts the zipped un/edifact specifications >>> located at http://www.unece.org/trade/untdid/down_index.htm into >>> Smooks configuration files (mapping-files) . I have created a >>> test-case that demonstrates the whole procedure: ConfigReaderTest. >>> test_Converting_UnEdifact_D08A(). >>> >>> But in general the conversion-tool takes the following arguments: >>> >>> · InFile - the zip-file containing the un/edifact specs. >>> >>> · outDir - the directory to put the generated configuration-files. >>> >>> · message - The name of the message to parse. In the testcase example >>> I am generating the INVOIC message. It is also possible to generate >>> all messages by writing ALL. >>> >>> Today the conversion tool only handles zip-files. An improvement would >>> be to check whether it is a zip-file or an unzipped directory. >>> >>> Also, when writing the testcases I found that the segments UNH and UNT >>> are not located in the zip-file containing the specification :(. I >>> have handwritten a config-file (un-edifact-interchange-definition.xml) >>> that will be used for now. But in the future it would be nice if we >>> could find the location/url of the interchange envelope specification. >>> >>> Regards, >>> >>> Bård** >>> >>> >>> >> --------------------------------------------------------------------- >> 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 >> >> >> >> >> > > --------------------------------------------------------------------- > 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 > > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
SV: SV: SV: Edi Conversion Tool
by Bård Langöy
::
Rate this Message:
Okidoki Tom,
I will try to get it into the trunk tonight then. Regards, Bård -----Ursprungligt meddelande----- Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 november 2009 16:12 Till: dev@... Ämne: Re: SV: SV: [milyn-dev] Edi Conversion Tool Hey Bard..... if it builds and doesn't break the build lets go for it and check it into trunk. We can still make changes to it from there, but I'd prefer to get this out into the wild asap in a snapshot. The more feedback we get the better. We can be playing with it and refining it ourselves too!!! Bård Langöy wrote: > Hi Tom, > > Should I check in the stuff now or do you want to look at it first ? > > Regards, > Bård > > -----Ursprungligt meddelande----- > Från: Tom Fennelly [mailto:tom.fennelly@...] > Skickat: den 10 november 2009 15:50 > Till: dev@... > Ämne: Re: SV: [milyn-dev] Edi Conversion Tool > > Hey Bard. > > Well first thing I plan on doing is just looking at it. I suppose the > best thing we should do for now is get what you have sorted out and > checked into trunk. Then we can look at adding the plugins and EJC. Yeah? > > T. > > > Bård Langöy wrote: > >> Hi Tom, >> >> Yes that would be great ! When integrating the ECT with the EJC it would be great to add the new documentation element as javadoc in the generated classes. Will you do that or should I take a look at it ? >> >> >> Regards, >> Bård >> >> >> >> -----Ursprungligt meddelande----- >> Från: Tom Fennelly [mailto:tom.fennelly@...] >> Skickat: den 8 november 2009 21:48 >> Till: dev@... >> Ämne: Re: [milyn-dev] Edi Conversion Tool >> >> This stuff is awesome Bard. I will be looking at it ASAP!! I might also >> look at creating Ant and Maven plugins for this, as well as integrating >> it with EJC. >> >> Bård Langöy wrote: >> >> >>> Hi, >>> >>> I have finally checked in the first parts of the Edi Convert Tool. The >>> code does not exist in the trunk yet, but can be downloaded at: >>> https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT >>> >>> The conversion tool converts the zipped un/edifact specifications >>> located at http://www.unece.org/trade/untdid/down_index.htm into >>> Smooks configuration files (mapping-files) . I have created a >>> test-case that demonstrates the whole procedure: ConfigReaderTest. >>> test_Converting_UnEdifact_D08A(). >>> >>> But in general the conversion-tool takes the following arguments: >>> >>> · InFile - the zip-file containing the un/edifact specs. >>> >>> · outDir - the directory to put the generated configuration-files. >>> >>> · message - The name of the message to parse. In the testcase example >>> I am generating the INVOIC message. It is also possible to generate >>> all messages by writing ALL. >>> >>> Today the conversion tool only handles zip-files. An improvement would >>> be to check whether it is a zip-file or an unzipped directory. >>> >>> Also, when writing the testcases I found that the segments UNH and UNT >>> are not located in the zip-file containing the specification :(. I >>> have handwritten a config-file (un-edifact-interchange-definition.xml) >>> that will be used for now. But in the future it would be nice if we >>> could find the location/url of the interchange envelope specification. >>> >>> Regards, >>> >>> Bård** >>> >>> >>> >> --------------------------------------------------------------------- >> 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 >> >> >> >> >> > > --------------------------------------------------------------------- > 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 > > > > --------------------------------------------------------------------- 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 |
|
|
Re: SV: SV: SV: Edi Conversion Tool
by TomFennelly
::
Rate this Message:
Nice one Bard :)
Bård Langöy wrote: > Okidoki Tom, > > I will try to get it into the trunk tonight then. > > Regards, > Bård > > > > -----Ursprungligt meddelande----- > Från: Tom Fennelly [mailto:tom.fennelly@...] > Skickat: den 10 november 2009 16:12 > Till: dev@... > Ämne: Re: SV: SV: [milyn-dev] Edi Conversion Tool > > Hey Bard..... if it builds and doesn't break the build lets go for it > and check it into trunk. We can still make changes to it from there, > but I'd prefer to get this out into the wild asap in a snapshot. The > more feedback we get the better. We can be playing with it and refining > it ourselves too!!! > > Bård Langöy wrote: > >> Hi Tom, >> >> Should I check in the stuff now or do you want to look at it first ? >> >> Regards, >> Bård >> >> -----Ursprungligt meddelande----- >> Från: Tom Fennelly [mailto:tom.fennelly@...] >> Skickat: den 10 november 2009 15:50 >> Till: dev@... >> Ämne: Re: SV: [milyn-dev] Edi Conversion Tool >> >> Hey Bard. >> >> Well first thing I plan on doing is just looking at it. I suppose the >> best thing we should do for now is get what you have sorted out and >> checked into trunk. Then we can look at adding the plugins and EJC. Yeah? >> >> T. >> >> >> Bård Langöy wrote: >> >> >>> Hi Tom, >>> >>> Yes that would be great ! When integrating the ECT with the EJC it would be great to add the new documentation element as javadoc in the generated classes. Will you do that or should I take a look at it ? >>> >>> >>> Regards, >>> Bård >>> >>> >>> >>> -----Ursprungligt meddelande----- >>> Från: Tom Fennelly [mailto:tom.fennelly@...] >>> Skickat: den 8 november 2009 21:48 >>> Till: dev@... >>> Ämne: Re: [milyn-dev] Edi Conversion Tool >>> >>> This stuff is awesome Bard. I will be looking at it ASAP!! I might also >>> look at creating Ant and Maven plugins for this, as well as integrating >>> it with EJC. >>> >>> Bård Langöy wrote: >>> >>> >>> >>>> Hi, >>>> >>>> I have finally checked in the first parts of the Edi Convert Tool. The >>>> code does not exist in the trunk yet, but can be downloaded at: >>>> https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT >>>> >>>> The conversion tool converts the zipped un/edifact specifications >>>> located at http://www.unece.org/trade/untdid/down_index.htm into >>>> Smooks configuration files (mapping-files) . I have created a >>>> test-case that demonstrates the whole procedure: ConfigReaderTest. >>>> test_Converting_UnEdifact_D08A(). >>>> >>>> But in general the conversion-tool takes the following arguments: >>>> >>>> · InFile - the zip-file containing the un/edifact specs. >>>> >>>> · outDir - the directory to put the generated configuration-files. >>>> >>>> · message - The name of the message to parse. In the testcase example >>>> I am generating the INVOIC message. It is also possible to generate >>>> all messages by writing ALL. >>>> >>>> Today the conversion tool only handles zip-files. An improvement would >>>> be to check whether it is a zip-file or an unzipped directory. >>>> >>>> Also, when writing the testcases I found that the segments UNH and UNT >>>> are not located in the zip-file containing the specification :(. I >>>> have handwritten a config-file (un-edifact-interchange-definition.xml) >>>> that will be used for now. But in the future it would be nice if we >>>> could find the location/url of the interchange envelope specification. >>>> >>>> Regards, >>>> >>>> Bård** >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> 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 >>> >>> >>> >>> >>> >>> >> --------------------------------------------------------------------- >> 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 >> >> >> >> >> > > --------------------------------------------------------------------- > 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 > > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
SV: SV: SV: SV: Edi Conversion Tool
by Bård Langöy
::
Rate this Message:
Hi,
I have checked in the ECT into the trunk now. I also solved Milyn-362 which was the extension of the EDIParseException to also contain the current erranous MappingNode, the current segment number as well as the current segment line. Regards, Bård -----Ursprungligt meddelande----- Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 november 2009 16:29 Till: dev@... Ämne: Re: SV: SV: SV: [milyn-dev] Edi Conversion Tool Nice one Bard :) Bård Langöy wrote: > Okidoki Tom, > > I will try to get it into the trunk tonight then. > > Regards, > Bård > > > > -----Ursprungligt meddelande----- > Från: Tom Fennelly [mailto:tom.fennelly@...] > Skickat: den 10 november 2009 16:12 > Till: dev@... > Ämne: Re: SV: SV: [milyn-dev] Edi Conversion Tool > > Hey Bard..... if it builds and doesn't break the build lets go for it > and check it into trunk. We can still make changes to it from there, > but I'd prefer to get this out into the wild asap in a snapshot. The > more feedback we get the better. We can be playing with it and refining > it ourselves too!!! > > Bård Langöy wrote: > >> Hi Tom, >> >> Should I check in the stuff now or do you want to look at it first ? >> >> Regards, >> Bård >> >> -----Ursprungligt meddelande----- >> Från: Tom Fennelly [mailto:tom.fennelly@...] >> Skickat: den 10 november 2009 15:50 >> Till: dev@... >> Ämne: Re: SV: [milyn-dev] Edi Conversion Tool >> >> Hey Bard. >> >> Well first thing I plan on doing is just looking at it. I suppose the >> best thing we should do for now is get what you have sorted out and >> checked into trunk. Then we can look at adding the plugins and EJC. Yeah? >> >> T. >> >> >> Bård Langöy wrote: >> >> >>> Hi Tom, >>> >>> Yes that would be great ! When integrating the ECT with the EJC it would be great to add the new documentation element as javadoc in the generated classes. Will you do that or should I take a look at it ? >>> >>> >>> Regards, >>> Bård >>> >>> >>> >>> -----Ursprungligt meddelande----- >>> Från: Tom Fennelly [mailto:tom.fennelly@...] >>> Skickat: den 8 november 2009 21:48 >>> Till: dev@... >>> Ämne: Re: [milyn-dev] Edi Conversion Tool >>> >>> This stuff is awesome Bard. I will be looking at it ASAP!! I might also >>> look at creating Ant and Maven plugins for this, as well as integrating >>> it with EJC. >>> >>> Bård Langöy wrote: >>> >>> >>> >>>> Hi, >>>> >>>> I have finally checked in the first parts of the Edi Convert Tool. The >>>> code does not exist in the trunk yet, but can be downloaded at: >>>> https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT >>>> >>>> The conversion tool converts the zipped un/edifact specifications >>>> located at http://www.unece.org/trade/untdid/down_index.htm into >>>> Smooks configuration files (mapping-files) . I have created a >>>> test-case that demonstrates the whole procedure: ConfigReaderTest. >>>> test_Converting_UnEdifact_D08A(). >>>> >>>> But in general the conversion-tool takes the following arguments: >>>> >>>> · InFile - the zip-file containing the un/edifact specs. >>>> >>>> · outDir - the directory to put the generated configuration-files. >>>> >>>> · message - The name of the message to parse. In the testcase example >>>> I am generating the INVOIC message. It is also possible to generate >>>> all messages by writing ALL. >>>> >>>> Today the conversion tool only handles zip-files. An improvement would >>>> be to check whether it is a zip-file or an unzipped directory. >>>> >>>> Also, when writing the testcases I found that the segments UNH and UNT >>>> are not located in the zip-file containing the specification :(. I >>>> have handwritten a config-file (un-edifact-interchange-definition.xml) >>>> that will be used for now. But in the future it would be nice if we >>>> could find the location/url of the interchange envelope specification. >>>> >>>> Regards, >>>> >>>> Bård** >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> 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 >>> >>> >>> >>> >>> >>> >> --------------------------------------------------------------------- >> 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 >> >> >> >> >> > > --------------------------------------------------------------------- > 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 > > > > --------------------------------------------------------------------- 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 |
|
|
Re: SV: SV: SV: SV: Edi Conversion Tool
by TomFennelly
::
Rate this Message:
That's great Bard, thanks... I'll have a look at it asap... it's next on
my list of Smooks tasks :) Bård Langöy wrote: > Hi, > > I have checked in the ECT into the trunk now. > > I also solved Milyn-362 which was the extension of the EDIParseException to also contain the current erranous MappingNode, the current segment number as well as the current segment line. > > > Regards, > Bård > > -----Ursprungligt meddelande----- > Från: Tom Fennelly [mailto:tom.fennelly@...] > Skickat: den 10 november 2009 16:29 > Till: dev@... > Ämne: Re: SV: SV: SV: [milyn-dev] Edi Conversion Tool > > Nice one Bard :) > > Bård Langöy wrote: > >> Okidoki Tom, >> >> I will try to get it into the trunk tonight then. >> >> Regards, >> Bård >> >> >> >> -----Ursprungligt meddelande----- >> Från: Tom Fennelly [mailto:tom.fennelly@...] >> Skickat: den 10 november 2009 16:12 >> Till: dev@... >> Ämne: Re: SV: SV: [milyn-dev] Edi Conversion Tool >> >> Hey Bard..... if it builds and doesn't break the build lets go for it >> and check it into trunk. We can still make changes to it from there, >> but I'd prefer to get this out into the wild asap in a snapshot. The >> more feedback we get the better. We can be playing with it and refining >> it ourselves too!!! >> >> Bård Langöy wrote: >> >> >>> Hi Tom, >>> >>> Should I check in the stuff now or do you want to look at it first ? >>> >>> Regards, >>> Bård >>> >>> -----Ursprungligt meddelande----- >>> Från: Tom Fennelly [mailto:tom.fennelly@...] >>> Skickat: den 10 november 2009 15:50 >>> Till: dev@... >>> Ämne: Re: SV: [milyn-dev] Edi Conversion Tool >>> >>> Hey Bard. >>> >>> Well first thing I plan on doing is just looking at it. I suppose the >>> best thing we should do for now is get what you have sorted out and >>> checked into trunk. Then we can look at adding the plugins and EJC. Yeah? >>> >>> T. >>> >>> >>> Bård Langöy wrote: >>> >>> >>> >>>> Hi Tom, >>>> >>>> Yes that would be great ! When integrating the ECT with the EJC it would be great to add the new documentation element as javadoc in the generated classes. Will you do that or should I take a look at it ? >>>> >>>> >>>> Regards, >>>> Bård >>>> >>>> >>>> >>>> -----Ursprungligt meddelande----- >>>> Från: Tom Fennelly [mailto:tom.fennelly@...] >>>> Skickat: den 8 november 2009 21:48 >>>> Till: dev@... >>>> Ämne: Re: [milyn-dev] Edi Conversion Tool >>>> >>>> This stuff is awesome Bard. I will be looking at it ASAP!! I might also >>>> look at creating Ant and Maven plugins for this, as well as integrating >>>> it with EJC. >>>> >>>> Bård Langöy wrote: >>>> >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> I have finally checked in the first parts of the Edi Convert Tool. The >>>>> code does not exist in the trunk yet, but can be downloaded at: >>>>> https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT >>>>> >>>>> The conversion tool converts the zipped un/edifact specifications >>>>> located at http://www.unece.org/trade/untdid/down_index.htm into >>>>> Smooks configuration files (mapping-files) . I have created a >>>>> test-case that demonstrates the whole procedure: ConfigReaderTest. >>>>> test_Converting_UnEdifact_D08A(). >>>>> >>>>> But in general the conversion-tool takes the following arguments: >>>>> >>>>> · InFile - the zip-file containing the un/edifact specs. >>>>> >>>>> · outDir - the directory to put the generated configuration-files. >>>>> >>>>> · message - The name of the message to parse. In the testcase example >>>>> I am generating the INVOIC message. It is also possible to generate >>>>> all messages by writing ALL. >>>>> >>>>> Today the conversion tool only handles zip-files. An improvement would >>>>> be to check whether it is a zip-file or an unzipped directory. >>>>> >>>>> Also, when writing the testcases I found that the segments UNH and UNT >>>>> are not located in the zip-file containing the specification :(. I >>>>> have handwritten a config-file (un-edifact-interchange-definition.xml) >>>>> that will be used for now. But in the future it would be nice if we >>>>> could find the location/url of the interchange envelope specification. >>>>> >>>>> Regards, >>>>> >>>>> Bård** >>>>> >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> 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 >>> >>> >>> >>> >>> >>> >> --------------------------------------------------------------------- >> 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 >> >> >> >> >> > > --------------------------------------------------------------------- > 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 > > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: SV: SV: SV: SV: Edi Conversion Tool
by TomFennelly
::
Rate this Message:
Bard.... I haven't forgotten this at all... just up to my t*ts in work.
I have started looking at it, but need to dig in more :) T. Tom Fennelly wrote: > That's great Bard, thanks... I'll have a look at it asap... it's next > on my list of Smooks tasks :) > > Bård Langöy wrote: >> Hi, >> I have checked in the ECT into the trunk now. >> >> I also solved Milyn-362 which was the extension of the >> EDIParseException to also contain the current erranous MappingNode, >> the current segment number as well as the current segment line. >> >> Regards, >> Bård >> >> -----Ursprungligt meddelande----- >> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >> november 2009 16:29 >> Till: dev@... >> Ämne: Re: SV: SV: SV: [milyn-dev] Edi Conversion Tool >> >> Nice one Bard :) >> >> Bård Langöy wrote: >> >>> Okidoki Tom, >>> >>> I will try to get it into the trunk tonight then. >>> >>> Regards, >>> Bård >>> >>> >>> >>> -----Ursprungligt meddelande----- >>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >>> november 2009 16:12 >>> Till: dev@... >>> Ämne: Re: SV: SV: [milyn-dev] Edi Conversion Tool >>> >>> Hey Bard..... if it builds and doesn't break the build lets go for >>> it and check it into trunk. We can still make changes to it from >>> there, but I'd prefer to get this out into the wild asap in a >>> snapshot. The more feedback we get the better. We can be playing >>> with it and refining it ourselves too!!! >>> >>> Bård Langöy wrote: >>> >>>> Hi Tom, >>>> >>>> Should I check in the stuff now or do you want to look at it first ? >>>> >>>> Regards, >>>> Bård >>>> >>>> -----Ursprungligt meddelande----- >>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >>>> november 2009 15:50 >>>> Till: dev@... >>>> Ämne: Re: SV: [milyn-dev] Edi Conversion Tool >>>> >>>> Hey Bard. >>>> >>>> Well first thing I plan on doing is just looking at it. I suppose >>>> the best thing we should do for now is get what you have sorted out >>>> and checked into trunk. Then we can look at adding the plugins and >>>> EJC. Yeah? >>>> >>>> T. >>>> >>>> >>>> Bård Langöy wrote: >>>> >>>>> Hi Tom, >>>>> >>>>> Yes that would be great ! When integrating the ECT with the EJC it >>>>> would be great to add the new documentation element as javadoc in >>>>> the generated classes. Will you do that or should I take a look at >>>>> it ? >>>>> >>>>> >>>>> Regards, >>>>> Bård >>>>> >>>>> >>>>> >>>>> -----Ursprungligt meddelande----- >>>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 8 >>>>> november 2009 21:48 >>>>> Till: dev@... >>>>> Ämne: Re: [milyn-dev] Edi Conversion Tool >>>>> >>>>> This stuff is awesome Bard. I will be looking at it ASAP!! I might >>>>> also look at creating Ant and Maven plugins for this, as well as >>>>> integrating it with EJC. >>>>> >>>>> Bård Langöy wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I have finally checked in the first parts of the Edi Convert >>>>>> Tool. The code does not exist in the trunk yet, but can be >>>>>> downloaded at: >>>>>> https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT >>>>>> >>>>>> The conversion tool converts the zipped un/edifact specifications >>>>>> located at http://www.unece.org/trade/untdid/down_index.htm into >>>>>> Smooks configuration files (mapping-files) . I have created a >>>>>> test-case that demonstrates the whole procedure: >>>>>> ConfigReaderTest. test_Converting_UnEdifact_D08A(). >>>>>> >>>>>> But in general the conversion-tool takes the following arguments: >>>>>> >>>>>> · InFile - the zip-file containing the un/edifact specs. >>>>>> >>>>>> · outDir - the directory to put the generated configuration-files. >>>>>> >>>>>> · message - The name of the message to parse. In the testcase >>>>>> example I am generating the INVOIC message. It is also possible >>>>>> to generate all messages by writing ALL. >>>>>> >>>>>> Today the conversion tool only handles zip-files. An improvement >>>>>> would be to check whether it is a zip-file or an unzipped directory. >>>>>> >>>>>> Also, when writing the testcases I found that the segments UNH >>>>>> and UNT are not located in the zip-file containing the >>>>>> specification :(. I have handwritten a config-file >>>>>> (un-edifact-interchange-definition.xml) that will be used for >>>>>> now. But in the future it would be nice if we could find the >>>>>> location/url of the interchange envelope specification. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Bård** >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> 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 >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> 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 >>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> 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 >> >> >> >> > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: SV: SV: SV: SV: Edi Conversion Tool
by TomFennelly
::
Rate this Message:
Hey Bard, so I eventually got to go through ECT :)
So I concentrated my attention on the UnEdifactReader class. I should have asked you (earlier) to outline the basic algorithm for processing these UN/EDIFACT files, but from reading the code: 1. The UnEdifactReader API takes infile and outDir String args, as well as the message name to be processed. * Notes... * From a core API point of view, in general, I like to avoid passing file names around, if it can be avoided. Avoiding it makes the core API a bit easier to test. I think "system" level params (like files etc) are better suited when you get to the likes of the Ant and Maven plugins, or in a utility main method. * How about something like one of the following: o String UnEdifactReader.parse(ZipInputStream unEdifactDefinition, String messageName), where the return param is the serialized smooks edi mapping model, or... o UnEdifactReader unEdifactReader = new UnEdifactReader(ZipInputStream unEdifactDefinition).... + String defName = unEdifactReader.getDefinitionName(); + String defVersion = unEdifactReader.getDefinitionVersion(); + Set<String> messageNames = unEdifactReader.getMessageNames(); # foreach messageName in messageNames..... String mappingModel = unEdifactReader.convert(messageName); # or simply, get a one off message... String invoicMappingModel = unEdifactReader.convert("INVOIC"); 2. I think I'd avoid creating hierarchies of files for these messages. I know that might lead to some duplication in the generated models... but so what ?? (for now at least :) )... seems to me as though the duplication is not as important when it's all generated/automated anyway. 3. The zip files inside the definition file are being unzipped to disk. How about unzipping these and building an in-memory model (the EdiModel components perhaps) instead?? i.e.... again... avoid system level "stuff" in the core code (leave that to the Ant/Maven plugins)... looking at the D08A.zip file in the tests (1.7M), we're not dealing with huge files. In fact... looks like we are doing this anyway at line #50... we process the decompressedDir and build an Edimap instance in memory... couldn't we just process the hierarchy of the zip directly... skip the decompression step?? 4. Use of Thread.currentThread().getContextClassLoader().getResourceAsStream can be replaced with ClassUtil.getResourceAsStream(...). It will all back to the Thread Context ClassLoader if needed. 5. The interchange definitions are being included as an import: * The import URI is going to be absolute, and specific to the machine on which the configs are generated. Therefore... will not be portable, right? I think if we followed suggestion #2 above, we'd avoid this issue i.e. no use of imports at all - it's segments would just be included. Would that work? 6. Is the interchange definition version specific? What I mean is... is the version that's there in the code specific to D08A? 7. The ConfigWriter is using file names too Vs simply a Writer instance... can be whatever you want then e.g. a FileWriter or just a StringWriter. That was all I noticed from a pass through. Hope that helps Bard. Hope I make some sense :) T. Tom Fennelly wrote: > Bard.... I haven't forgotten this at all... just up to my t*ts in > work. I have started looking at it, but need to dig in more :) > > T. > > > Tom Fennelly wrote: >> That's great Bard, thanks... I'll have a look at it asap... it's next >> on my list of Smooks tasks :) >> >> Bård Langöy wrote: >>> Hi, >>> I have checked in the ECT into the trunk now. >>> >>> I also solved Milyn-362 which was the extension of the >>> EDIParseException to also contain the current erranous MappingNode, >>> the current segment number as well as the current segment line. >>> >>> Regards, >>> Bård >>> >>> -----Ursprungligt meddelande----- >>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >>> november 2009 16:29 >>> Till: dev@... >>> Ämne: Re: SV: SV: SV: [milyn-dev] Edi Conversion Tool >>> >>> Nice one Bard :) >>> >>> Bård Langöy wrote: >>> >>>> Okidoki Tom, >>>> >>>> I will try to get it into the trunk tonight then. >>>> >>>> Regards, >>>> Bård >>>> >>>> >>>> >>>> -----Ursprungligt meddelande----- >>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >>>> november 2009 16:12 >>>> Till: dev@... >>>> Ämne: Re: SV: SV: [milyn-dev] Edi Conversion Tool >>>> >>>> Hey Bard..... if it builds and doesn't break the build lets go for >>>> it and check it into trunk. We can still make changes to it from >>>> there, but I'd prefer to get this out into the wild asap in a >>>> snapshot. The more feedback we get the better. We can be playing >>>> with it and refining it ourselves too!!! >>>> >>>> Bård Langöy wrote: >>>> >>>>> Hi Tom, >>>>> >>>>> Should I check in the stuff now or do you want to look at it first ? >>>>> >>>>> Regards, >>>>> Bård >>>>> >>>>> -----Ursprungligt meddelande----- >>>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >>>>> november 2009 15:50 >>>>> Till: dev@... >>>>> Ämne: Re: SV: [milyn-dev] Edi Conversion Tool >>>>> >>>>> Hey Bard. >>>>> >>>>> Well first thing I plan on doing is just looking at it. I suppose >>>>> the best thing we should do for now is get what you have sorted >>>>> out and checked into trunk. Then we can look at adding the >>>>> plugins and EJC. Yeah? >>>>> >>>>> T. >>>>> >>>>> >>>>> Bård Langöy wrote: >>>>> >>>>>> Hi Tom, >>>>>> >>>>>> Yes that would be great ! When integrating the ECT with the EJC >>>>>> it would be great to add the new documentation element as javadoc >>>>>> in the generated classes. Will you do that or should I take a >>>>>> look at it ? >>>>>> >>>>>> >>>>>> Regards, >>>>>> Bård >>>>>> >>>>>> >>>>>> >>>>>> -----Ursprungligt meddelande----- >>>>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 8 >>>>>> november 2009 21:48 >>>>>> Till: dev@... >>>>>> Ämne: Re: [milyn-dev] Edi Conversion Tool >>>>>> >>>>>> This stuff is awesome Bard. I will be looking at it ASAP!! I >>>>>> might also look at creating Ant and Maven plugins for this, as >>>>>> well as integrating it with EJC. >>>>>> >>>>>> Bård Langöy wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have finally checked in the first parts of the Edi Convert >>>>>>> Tool. The code does not exist in the trunk yet, but can be >>>>>>> downloaded at: >>>>>>> https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT >>>>>>> >>>>>>> The conversion tool converts the zipped un/edifact >>>>>>> specifications located at >>>>>>> http://www.unece.org/trade/untdid/down_index.htm into Smooks >>>>>>> configuration files (mapping-files) . I have created a test-case >>>>>>> that demonstrates the whole procedure: ConfigReaderTest. >>>>>>> test_Converting_UnEdifact_D08A(). >>>>>>> >>>>>>> But in general the conversion-tool takes the following arguments: >>>>>>> >>>>>>> · InFile - the zip-file containing the un/edifact specs. >>>>>>> >>>>>>> · outDir - the directory to put the generated configuration-files. >>>>>>> >>>>>>> · message - The name of the message to parse. In the testcase >>>>>>> example I am generating the INVOIC message. It is also possible >>>>>>> to generate all messages by writing ALL. >>>>>>> >>>>>>> Today the conversion tool only handles zip-files. An improvement >>>>>>> would be to check whether it is a zip-file or an unzipped >>>>>>> directory. >>>>>>> >>>>>>> Also, when writing the testcases I found that the segments UNH >>>>>>> and UNT are not located in the zip-file containing the >>>>>>> specification :(. I have handwritten a config-file >>>>>>> (un-edifact-interchange-definition.xml) that will be used for >>>>>>> now. But in the future it would be nice if we could find the >>>>>>> location/url of the interchange envelope specification. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Bård** >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> 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 >>>> >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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 >>> >>> >>> >>> >> > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
SV: SV: SV: SV: SV: Edi Conversion Tool
by Bård Langöy
::
Rate this Message:
Hi Tom.
No problem. I have been swamped in work myself... :) Regards, Bård -----Ursprungligt meddelande----- Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 4 december 2009 13:34 Till: dev@... Ämne: Re: SV: SV: SV: SV: [milyn-dev] Edi Conversion Tool Bard.... I haven't forgotten this at all... just up to my t*ts in work. I have started looking at it, but need to dig in more :) T. Tom Fennelly wrote: > That's great Bard, thanks... I'll have a look at it asap... it's next > on my list of Smooks tasks :) > > Bård Langöy wrote: >> Hi, >> I have checked in the ECT into the trunk now. >> >> I also solved Milyn-362 which was the extension of the >> EDIParseException to also contain the current erranous MappingNode, >> the current segment number as well as the current segment line. >> >> Regards, >> Bård >> >> -----Ursprungligt meddelande----- >> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >> november 2009 16:29 >> Till: dev@... >> Ämne: Re: SV: SV: SV: [milyn-dev] Edi Conversion Tool >> >> Nice one Bard :) >> >> Bård Langöy wrote: >> >>> Okidoki Tom, >>> >>> I will try to get it into the trunk tonight then. >>> >>> Regards, >>> Bård >>> >>> >>> >>> -----Ursprungligt meddelande----- >>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >>> november 2009 16:12 >>> Till: dev@... >>> Ämne: Re: SV: SV: [milyn-dev] Edi Conversion Tool >>> >>> Hey Bard..... if it builds and doesn't break the build lets go for >>> it and check it into trunk. We can still make changes to it from >>> there, but I'd prefer to get this out into the wild asap in a >>> snapshot. The more feedback we get the better. We can be playing >>> with it and refining it ourselves too!!! >>> >>> Bård Langöy wrote: >>> >>>> Hi Tom, >>>> >>>> Should I check in the stuff now or do you want to look at it first ? >>>> >>>> Regards, >>>> Bård >>>> >>>> -----Ursprungligt meddelande----- >>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >>>> november 2009 15:50 >>>> Till: dev@... >>>> Ämne: Re: SV: [milyn-dev] Edi Conversion Tool >>>> >>>> Hey Bard. >>>> >>>> Well first thing I plan on doing is just looking at it. I suppose >>>> the best thing we should do for now is get what you have sorted out >>>> and checked into trunk. Then we can look at adding the plugins and >>>> EJC. Yeah? >>>> >>>> T. >>>> >>>> >>>> Bård Langöy wrote: >>>> >>>>> Hi Tom, >>>>> >>>>> Yes that would be great ! When integrating the ECT with the EJC it >>>>> would be great to add the new documentation element as javadoc in >>>>> the generated classes. Will you do that or should I take a look at >>>>> it ? >>>>> >>>>> >>>>> Regards, >>>>> Bård >>>>> >>>>> >>>>> >>>>> -----Ursprungligt meddelande----- >>>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 8 >>>>> november 2009 21:48 >>>>> Till: dev@... >>>>> Ämne: Re: [milyn-dev] Edi Conversion Tool >>>>> >>>>> This stuff is awesome Bard. I will be looking at it ASAP!! I might >>>>> also look at creating Ant and Maven plugins for this, as well as >>>>> integrating it with EJC. >>>>> >>>>> Bård Langöy wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I have finally checked in the first parts of the Edi Convert >>>>>> Tool. The code does not exist in the trunk yet, but can be >>>>>> downloaded at: >>>>>> https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT >>>>>> >>>>>> The conversion tool converts the zipped un/edifact specifications >>>>>> located at http://www.unece.org/trade/untdid/down_index.htm into >>>>>> Smooks configuration files (mapping-files) . I have created a >>>>>> test-case that demonstrates the whole procedure: >>>>>> ConfigReaderTest. test_Converting_UnEdifact_D08A(). >>>>>> >>>>>> But in general the conversion-tool takes the following arguments: >>>>>> >>>>>> · InFile - the zip-file containing the un/edifact specs. >>>>>> >>>>>> · outDir - the directory to put the generated configuration-files. >>>>>> >>>>>> · message - The name of the message to parse. In the testcase >>>>>> example I am generating the INVOIC message. It is also possible >>>>>> to generate all messages by writing ALL. >>>>>> >>>>>> Today the conversion tool only handles zip-files. An improvement >>>>>> would be to check whether it is a zip-file or an unzipped directory. >>>>>> >>>>>> Also, when writing the testcases I found that the segments UNH >>>>>> and UNT are not located in the zip-file containing the >>>>>> specification :(. I have handwritten a config-file >>>>>> (un-edifact-interchange-definition.xml) that will be used for >>>>>> now. But in the future it would be nice if we could find the >>>>>> location/url of the interchange envelope specification. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Bård** >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> 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 >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> 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 >>> >>> >>> >>> >> >> --------------------------------------------------------------------- >> 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 >> >> >> >> > --------------------------------------------------------------------- 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 |
|
|
Re: SV: SV: SV: SV: SV: Edi Conversion Tool
by TomFennelly
::
Rate this Message:
Hey Bard, I have replied since with some coments :)
Sent from my iPhone. On 7 Dec 2009, at 07:43, Bård Langöy <bardl@...> wrote: > Hi Tom. > > No problem. I have been swamped in work myself... :) > > > Regards, > Bård > > > -----Ursprungligt meddelande----- > Från: Tom Fennelly [mailto:tom.fennelly@...] > Skickat: den 4 december 2009 13:34 > Till: dev@... > Ämne: Re: SV: SV: SV: SV: [milyn-dev] Edi Conversion Tool > > Bard.... I haven't forgotten this at all... just up to my t*ts in > work. > I have started looking at it, but need to dig in more :) > > T. > > > Tom Fennelly wrote: >> That's great Bard, thanks... I'll have a look at it asap... it's next >> on my list of Smooks tasks :) >> >> Bård Langöy wrote: >>> Hi, >>> I have checked in the ECT into the trunk now. >>> >>> I also solved Milyn-362 which was the extension of the >>> EDIParseException to also contain the current erranous MappingNode, >>> the current segment number as well as the current segment line. >>> >>> Regards, >>> Bård >>> >>> -----Ursprungligt meddelande----- >>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >>> november 2009 16:29 >>> Till: dev@... >>> Ämne: Re: SV: SV: SV: [milyn-dev] Edi Conversion Tool >>> >>> Nice one Bard :) >>> >>> Bård Langöy wrote: >>> >>>> Okidoki Tom, >>>> >>>> I will try to get it into the trunk tonight then. >>>> >>>> Regards, >>>> Bård >>>> >>>> >>>> >>>> -----Ursprungligt meddelande----- >>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >>>> november 2009 16:12 >>>> Till: dev@... >>>> Ämne: Re: SV: SV: [milyn-dev] Edi Conversion Tool >>>> >>>> Hey Bard..... if it builds and doesn't break the build lets go for >>>> it and check it into trunk. We can still make changes to it from >>>> there, but I'd prefer to get this out into the wild asap in a >>>> snapshot. The more feedback we get the better. We can be playing >>>> with it and refining it ourselves too!!! >>>> >>>> Bård Langöy wrote: >>>> >>>>> Hi Tom, >>>>> >>>>> Should I check in the stuff now or do you want to look at it >>>>> first ? >>>>> >>>>> Regards, >>>>> Bård >>>>> >>>>> -----Ursprungligt meddelande----- >>>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: >>>>> den 10 >>>>> november 2009 15:50 >>>>> Till: dev@... >>>>> Ämne: Re: SV: [milyn-dev] Edi Conversion Tool >>>>> >>>>> Hey Bard. >>>>> >>>>> Well first thing I plan on doing is just looking at it. I suppose >>>>> the best thing we should do for now is get what you have sorted >>>>> out >>>>> and checked into trunk. Then we can look at adding the plugins >>>>> and >>>>> EJC. Yeah? >>>>> >>>>> T. >>>>> >>>>> >>>>> Bård Langöy wrote: >>>>> >>>>>> Hi Tom, >>>>>> >>>>>> Yes that would be great ! When integrating the ECT with the EJC >>>>>> it >>>>>> would be great to add the new documentation element as javadoc in >>>>>> the generated classes. Will you do that or should I take a look >>>>>> at >>>>>> it ? >>>>>> >>>>>> >>>>>> Regards, >>>>>> Bård >>>>>> >>>>>> >>>>>> >>>>>> -----Ursprungligt meddelande----- >>>>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat >>>>>> : den 8 >>>>>> november 2009 21:48 >>>>>> Till: dev@... >>>>>> Ämne: Re: [milyn-dev] Edi Conversion Tool >>>>>> >>>>>> This stuff is awesome Bard. I will be looking at it ASAP!! I >>>>>> might >>>>>> also look at creating Ant and Maven plugins for this, as well as >>>>>> integrating it with EJC. >>>>>> >>>>>> Bård Langöy wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have finally checked in the first parts of the Edi Convert >>>>>>> Tool. The code does not exist in the trunk yet, but can be >>>>>>> downloaded at: >>>>>>> https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT >>>>>>> >>>>>>> The conversion tool converts the zipped un/edifact >>>>>>> specifications >>>>>>> located at http://www.unece.org/trade/untdid/down_index.htm into >>>>>>> Smooks configuration files (mapping-files) . I have created a >>>>>>> test-case that demonstrates the whole procedure: >>>>>>> ConfigReaderTest. test_Converting_UnEdifact_D08A(). >>>>>>> >>>>>>> But in general the conversion-tool takes the following >>>>>>> arguments: >>>>>>> >>>>>>> · InFile - the zip-file containing the un/edifact specs. >>>>>>> >>>>>>> · outDir - the directory to put the generated configurat >>>>>>> ion-files. >>>>>>> >>>>>>> · message - The name of the message to parse. In the testcase >>>>>>> example I am generating the INVOIC message. It is also possible >>>>>>> to generate all messages by writing ALL. >>>>>>> >>>>>>> Today the conversion tool only handles zip-files. An improvement >>>>>>> would be to check whether it is a zip-file or an unzipped >>>>>>> directory. >>>>>>> >>>>>>> Also, when writing the testcases I found that the segments UNH >>>>>>> and UNT are not located in the zip-file containing the >>>>>>> specification :(. I have handwritten a config-file >>>>>>> (un-edifact-interchange-definition.xml) that will be used for >>>>>>> now. But in the future it would be nice if we could find the >>>>>>> location/url of the interchange envelope specification. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Bård** >>>>>>> >>>>>>> >>>>>> --- >>>>>> --- >>>>>> --------------------------------------------------------------- >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --- >>>>> ------------------------------------------------------------------ >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>> --- >>>> ------------------------------------------------------------------ >>>> 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 >>>> >>>> >>>> >>>> >>> >>> --- >>> ------------------------------------------------------------------ >>> 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 >>> >>> >>> >>> >> > > --------------------------------------------------------------------- > 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: SV: SV: SV: SV: Edi Conversion Tool
by TomFennelly
::
Rate this Message:
Well Bard... did you get to look at these yet?
T. Tom Fennelly wrote: > Hey Bard, so I eventually got to go through ECT :) > > So I concentrated my attention on the UnEdifactReader class. I should > have asked you (earlier) to outline the basic algorithm for processing > these UN/EDIFACT files, but from reading the code: > > 1. The UnEdifactReader API takes infile and outDir String args, as > well as the message name to be processed. > * Notes... > * From a core API point of view, in general, I like to avoid > passing file names around, if it can be avoided. Avoiding > it makes the core API a bit easier to test. I think > "system" level params (like files etc) are better suited > when you get to the likes of the Ant and Maven plugins, or > in a utility main method. > * How about something like one of the following: > o String UnEdifactReader.parse(ZipInputStream > unEdifactDefinition, String messageName), where the > return param is the serialized smooks edi mapping > model, or... > o UnEdifactReader unEdifactReader = new > UnEdifactReader(ZipInputStream unEdifactDefinition).... > + String defName = > unEdifactReader.getDefinitionName(); > + String defVersion = > unEdifactReader.getDefinitionVersion(); > + Set<String> messageNames = > unEdifactReader.getMessageNames(); > # foreach messageName in messageNames..... > String mappingModel = > unEdifactReader.convert(messageName); > # or simply, get a one off message... String > invoicMappingModel = > unEdifactReader.convert("INVOIC"); > 2. I think I'd avoid creating hierarchies of files for these > messages. I know that might lead to some duplication in the > generated models... but so what ?? (for now at least :) )... seems > to me as though the duplication is not as important when it's all > generated/automated anyway. > 3. The zip files inside the definition file are being unzipped to > disk. How about unzipping these and building an in-memory model > (the EdiModel components perhaps) instead?? i.e.... again... > avoid system level "stuff" in the core code (leave that to the > Ant/Maven plugins)... looking at the D08A.zip file in the tests > (1.7M), we're not dealing with huge files. In fact... looks like > we are doing this anyway at line #50... we process the > decompressedDir and build an Edimap instance in memory... couldn't > we just process the hierarchy of the zip directly... skip the > decompression step?? > 4. Use of > Thread.currentThread().getContextClassLoader().getResourceAsStream > can be replaced with ClassUtil.getResourceAsStream(...). It will > all back to the Thread Context ClassLoader if needed. > 5. The interchange definitions are being included as an import: > * The import URI is going to be absolute, and specific to the > machine on which the configs are generated. Therefore... > will not be portable, right? I think if we followed > suggestion #2 above, we'd avoid this issue i.e. no use of > imports at all - it's segments would just be included. > Would that work? > 6. Is the interchange definition version specific? What I mean is... > is the version that's there in the code specific to D08A? > 7. The ConfigWriter is using file names too Vs simply a Writer > instance... can be whatever you want then e.g. a FileWriter or > just a StringWriter. > > That was all I noticed from a pass through. Hope that helps Bard. > Hope I make some sense :) > > T. > > > > Tom Fennelly wrote: >> Bard.... I haven't forgotten this at all... just up to my t*ts in >> work. I have started looking at it, but need to dig in more :) >> >> T. >> >> >> Tom Fennelly wrote: >>> That's great Bard, thanks... I'll have a look at it asap... it's >>> next on my list of Smooks tasks :) >>> >>> Bård Langöy wrote: >>>> Hi, >>>> I have checked in the ECT into the trunk now. >>>> >>>> I also solved Milyn-362 which was the extension of the >>>> EDIParseException to also contain the current erranous MappingNode, >>>> the current segment number as well as the current segment line. >>>> >>>> Regards, >>>> Bård >>>> >>>> -----Ursprungligt meddelande----- >>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >>>> november 2009 16:29 >>>> Till: dev@... >>>> Ämne: Re: SV: SV: SV: [milyn-dev] Edi Conversion Tool >>>> >>>> Nice one Bard :) >>>> >>>> Bård Langöy wrote: >>>> >>>>> Okidoki Tom, >>>>> >>>>> I will try to get it into the trunk tonight then. >>>>> >>>>> Regards, >>>>> Bård >>>>> >>>>> >>>>> >>>>> -----Ursprungligt meddelande----- >>>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >>>>> november 2009 16:12 >>>>> Till: dev@... >>>>> Ämne: Re: SV: SV: [milyn-dev] Edi Conversion Tool >>>>> >>>>> Hey Bard..... if it builds and doesn't break the build lets go for >>>>> it and check it into trunk. We can still make changes to it from >>>>> there, but I'd prefer to get this out into the wild asap in a >>>>> snapshot. The more feedback we get the better. We can be playing >>>>> with it and refining it ourselves too!!! >>>>> >>>>> Bård Langöy wrote: >>>>> >>>>>> Hi Tom, >>>>>> >>>>>> Should I check in the stuff now or do you want to look at it first ? >>>>>> >>>>>> Regards, >>>>>> Bård >>>>>> >>>>>> -----Ursprungligt meddelande----- >>>>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den >>>>>> 10 november 2009 15:50 >>>>>> Till: dev@... >>>>>> Ämne: Re: SV: [milyn-dev] Edi Conversion Tool >>>>>> >>>>>> Hey Bard. >>>>>> >>>>>> Well first thing I plan on doing is just looking at it. I >>>>>> suppose the best thing we should do for now is get what you have >>>>>> sorted out and checked into trunk. Then we can look at adding >>>>>> the plugins and EJC. Yeah? >>>>>> >>>>>> T. >>>>>> >>>>>> >>>>>> Bård Langöy wrote: >>>>>> >>>>>>> Hi Tom, >>>>>>> >>>>>>> Yes that would be great ! When integrating the ECT with the EJC >>>>>>> it would be great to add the new documentation element as >>>>>>> javadoc in the generated classes. Will you do that or should I >>>>>>> take a look at it ? >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Bård >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Ursprungligt meddelande----- >>>>>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den >>>>>>> 8 november 2009 21:48 >>>>>>> Till: dev@... >>>>>>> Ämne: Re: [milyn-dev] Edi Conversion Tool >>>>>>> >>>>>>> This stuff is awesome Bard. I will be looking at it ASAP!! I >>>>>>> might also look at creating Ant and Maven plugins for this, as >>>>>>> well as integrating it with EJC. >>>>>>> >>>>>>> Bård Langöy wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have finally checked in the first parts of the Edi Convert >>>>>>>> Tool. The code does not exist in the trunk yet, but can be >>>>>>>> downloaded at: >>>>>>>> https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT >>>>>>>> >>>>>>>> The conversion tool converts the zipped un/edifact >>>>>>>> specifications located at >>>>>>>> http://www.unece.org/trade/untdid/down_index.htm into Smooks >>>>>>>> configuration files (mapping-files) . I have created a >>>>>>>> test-case that demonstrates the whole procedure: >>>>>>>> ConfigReaderTest. test_Converting_UnEdifact_D08A(). >>>>>>>> >>>>>>>> But in general the conversion-tool takes the following arguments: >>>>>>>> >>>>>>>> · InFile - the zip-file containing the un/edifact specs. >>>>>>>> >>>>>>>> · outDir - the directory to put the generated configuration-files. >>>>>>>> >>>>>>>> · message - The name of the message to parse. In the testcase >>>>>>>> example I am generating the INVOIC message. It is also possible >>>>>>>> to generate all messages by writing ALL. >>>>>>>> >>>>>>>> Today the conversion tool only handles zip-files. An >>>>>>>> improvement would be to check whether it is a zip-file or an >>>>>>>> unzipped directory. >>>>>>>> >>>>>>>> Also, when writing the testcases I found that the segments UNH >>>>>>>> and UNT are not located in the zip-file containing the >>>>>>>> specification :(. I have handwritten a config-file >>>>>>>> (un-edifact-interchange-definition.xml) that will be used for >>>>>>>> now. But in the future it would be nice if we could find the >>>>>>>> location/url of the interchange envelope specification. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Bård** >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>>> >>>> >>>> >>>> >>> >> > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
SV: SV: SV: SV: SV: Edi Conversion Tool
by Bård Langöy
::
Rate this Message:
Hi Tom,
Thanks for the excellent feedback :). I totally agree with you regarding the Filenames being passed through ECT. The thought crossed my mind too when writing the code but I took the easy way on that one. But I will go back and fix this. But just to verify that I have understood you correctly. 1. So you mean that the ECT should only take one parameter in the constructor (the ZipInputStream) and all the other stuff like messagenames, definitionnames, definitionversion, etc. should be set by using setters ? 2. I am not certain I agree 100% with you on this one :). When using the ECT in combination with the EJC I also think it would be better. But not for the people that is only using the ECT... Maybe this could be switched on/off. By default the ECT does not create any hierarchies/imports. But when the ECT.separateDefinitionsAndSequence(true) then it behaves like it does today. What do you think ? 3. Yes, I agree. I will fix this. 4. Yes, I agree. I will fix this. 5. Like I answered in #2. If the user wants to separate the definitionfile and the sequencefile they would maybe have to manually set the import-resource in the sequencefile. But I still think that we should not remove this functionality. But by default the definitions would not be separated from the sequence... but if the user choose to separate the two parts then maybe the ECT could write a warning that the import resource should be manually set ? By default only the filename (and not the path) of the definitionfile should be set in the importresource. 6. No, it shouldn't be. It should work for all Un/Edifact specs downloaded from the UN website. 7. Yes, I agree. I will fix this. Regards, Bård -----Ursprungligt meddelande----- Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 14 december 2009 20:37 Till: dev@... Ämne: Re: SV: SV: SV: SV: [milyn-dev] Edi Conversion Tool Well Bard... did you get to look at these yet? T. Tom Fennelly wrote: > Hey Bard, so I eventually got to go through ECT :) > > So I concentrated my attention on the UnEdifactReader class. I should > have asked you (earlier) to outline the basic algorithm for processing > these UN/EDIFACT files, but from reading the code: > > 1. The UnEdifactReader API takes infile and outDir String args, as > well as the message name to be processed. > * Notes... > * From a core API point of view, in general, I like to avoid > passing file names around, if it can be avoided. Avoiding > it makes the core API a bit easier to test. I think > "system" level params (like files etc) are better suited > when you get to the likes of the Ant and Maven plugins, or > in a utility main method. > * How about something like one of the following: > o String UnEdifactReader.parse(ZipInputStream > unEdifactDefinition, String messageName), where the > return param is the serialized smooks edi mapping > model, or... > o UnEdifactReader unEdifactReader = new > UnEdifactReader(ZipInputStream unEdifactDefinition).... > + String defName = > unEdifactReader.getDefinitionName(); > + String defVersion = > unEdifactReader.getDefinitionVersion(); > + Set<String> messageNames = > unEdifactReader.getMessageNames(); > # foreach messageName in messageNames..... > String mappingModel = > unEdifactReader.convert(messageName); > # or simply, get a one off message... String > invoicMappingModel = > unEdifactReader.convert("INVOIC"); > 2. I think I'd avoid creating hierarchies of files for these > messages. I know that might lead to some duplication in the > generated models... but so what ?? (for now at least :) )... seems > to me as though the duplication is not as important when it's all > generated/automated anyway. > 3. The zip files inside the definition file are being unzipped to > disk. How about unzipping these and building an in-memory model > (the EdiModel components perhaps) instead?? i.e.... again... > avoid system level "stuff" in the core code (leave that to the > Ant/Maven plugins)... looking at the D08A.zip file in the tests > (1.7M), we're not dealing with huge files. In fact... looks like > we are doing this anyway at line #50... we process the > decompressedDir and build an Edimap instance in memory... couldn't > we just process the hierarchy of the zip directly... skip the > decompression step?? > 4. Use of > Thread.currentThread().getContextClassLoader().getResourceAsStream > can be replaced with ClassUtil.getResourceAsStream(...). It will > all back to the Thread Context ClassLoader if needed. > 5. The interchange definitions are being included as an import: > * The import URI is going to be absolute, and specific to the > machine on which the configs are generated. Therefore... > will not be portable, right? I think if we followed > suggestion #2 above, we'd avoid this issue i.e. no use of > imports at all - it's segments would just be included. > Would that work? > 6. Is the interchange definition version specific? What I mean is... > is the version that's there in the code specific to D08A? > 7. The ConfigWriter is using file names too Vs simply a Writer > instance... can be whatever you want then e.g. a FileWriter or > just a StringWriter. > > That was all I noticed from a pass through. Hope that helps Bard. > Hope I make some sense :) > > T. > > > > Tom Fennelly wrote: >> Bard.... I haven't forgotten this at all... just up to my t*ts in >> work. I have started looking at it, but need to dig in more :) >> >> T. >> >> >> Tom Fennelly wrote: >>> That's great Bard, thanks... I'll have a look at it asap... it's >>> next on my list of Smooks tasks :) >>> >>> Bård Langöy wrote: >>>> Hi, >>>> I have checked in the ECT into the trunk now. >>>> >>>> I also solved Milyn-362 which was the extension of the >>>> EDIParseException to also contain the current erranous MappingNode, >>>> the current segment number as well as the current segment line. >>>> >>>> Regards, >>>> Bård >>>> >>>> -----Ursprungligt meddelande----- >>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >>>> november 2009 16:29 >>>> Till: dev@... >>>> Ämne: Re: SV: SV: SV: [milyn-dev] Edi Conversion Tool >>>> >>>> Nice one Bard :) >>>> >>>> Bård Langöy wrote: >>>> >>>>> Okidoki Tom, >>>>> >>>>> I will try to get it into the trunk tonight then. >>>>> >>>>> Regards, >>>>> Bård >>>>> >>>>> >>>>> >>>>> -----Ursprungligt meddelande----- >>>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den 10 >>>>> november 2009 16:12 >>>>> Till: dev@... >>>>> Ämne: Re: SV: SV: [milyn-dev] Edi Conversion Tool >>>>> >>>>> Hey Bard..... if it builds and doesn't break the build lets go for >>>>> it and check it into trunk. We can still make changes to it from >>>>> there, but I'd prefer to get this out into the wild asap in a >>>>> snapshot. The more feedback we get the better. We can be playing >>>>> with it and refining it ourselves too!!! >>>>> >>>>> Bård Langöy wrote: >>>>> >>>>>> Hi Tom, >>>>>> >>>>>> Should I check in the stuff now or do you want to look at it first ? >>>>>> >>>>>> Regards, >>>>>> Bård >>>>>> >>>>>> -----Ursprungligt meddelande----- >>>>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den >>>>>> 10 november 2009 15:50 >>>>>> Till: dev@... >>>>>> Ämne: Re: SV: [milyn-dev] Edi Conversion Tool >>>>>> >>>>>> Hey Bard. >>>>>> >>>>>> Well first thing I plan on doing is just looking at it. I >>>>>> suppose the best thing we should do for now is get what you have >>>>>> sorted out and checked into trunk. Then we can look at adding >>>>>> the plugins and EJC. Yeah? >>>>>> >>>>>> T. >>>>>> >>>>>> >>>>>> Bård Langöy wrote: >>>>>> >>>>>>> Hi Tom, >>>>>>> >>>>>>> Yes that would be great ! When integrating the ECT with the EJC >>>>>>> it would be great to add the new documentation element as >>>>>>> javadoc in the generated classes. Will you do that or should I >>>>>>> take a look at it ? >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Bård >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Ursprungligt meddelande----- >>>>>>> Från: Tom Fennelly [mailto:tom.fennelly@...] Skickat: den >>>>>>> 8 november 2009 21:48 >>>>>>> Till: dev@... >>>>>>> Ämne: Re: [milyn-dev] Edi Conversion Tool >>>>>>> >>>>>>> This stuff is awesome Bard. I will be looking at it ASAP!! I >>>>>>> might also look at creating Ant and Maven plugins for this, as >>>>>>> well as integrating it with EJC. >>>>>>> >>>>>>> Bård Langöy wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have finally checked in the first parts of the Edi Convert >>>>>>>> Tool. The code does not exist in the trunk yet, but can be >>>>>>>> downloaded at: >>>>>>>> https://svn.codehaus.org/milyn/workspaces/bardl/bardl_edipop/ECT >>>>>>>> >>>>>>>> The conversion tool converts the zipped un/edifact >>>>>>>> specifications located at >>>>>>>> http://www.unece.org/trade/untdid/down_index.htm into Smooks >>>>>>>> configuration files (mapping-files) . I have created a >>>>>>>> test-case that demonstrates the whole procedure: >>>>>>>> ConfigReaderTest. test_Converting_UnEdifact_D08A(). >>>>>>>> >>>>>>>> But in general the conversion-tool takes the following arguments: >>>>>>>> >>>>>>>> · InFile - the zip-file containing the un/edifact specs. >>>>>>>> >>>>>>>> · outDir - the directory to put the generated configuration-files. >>>>>>>> >>>>>>>> · message - The name of the message to parse. In the testcase >>>>>>>> example I am generating the INVOIC message. It is also possible >>>>>>>> to generate all messages by writing ALL. >>>>>>>> >>>>>>>> Today the conversion tool only handles zip-files. An >>>>>>>> improvement would be to check whether it is a zip-file or an >>>>>>>> unzipped directory. >>>>>>>> >>>>>>>> Also, when writing the testcases I found that the segments UNH >>>>>>>> and UNT are not located in the zip-file containing the >>>>>>>> specification :(. I have handwritten a config-file >>>>>>>> (un-edifact-interchange-definition.xml) that will be used for >>>>>>>> now. But in the future it would be nice if we could find the >>>>>>>> location/url of the interchange envelope specification. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Bård** >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>>> >>>> >>>> >>>> >>> >> > --------------------------------------------------------------------- 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 |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
