IPF 2.0 project structure draft

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

IPF 2.0 project structure draft

mrt1nz
Administrator
As mentioned in one of my previous posts here's now a proposal for the
new IPF 2.0 project structure.

http://repo.openehealth.org/confluence/display/ipf/IPF+2.0#IPF2.0-IPF2.0projectstructure

After the next milestone release (planned for end of this week) we will

- continue IPF 1.7 development on a separate ipf-1.7 branch
- start with IPF 2.0 development on the trunk (reusing changes from the
experimental IPF 2.0 branch)

As always, feedback is highly welcome.

Cheers,
Martin

_______________________________________________
Ipf-developer mailing list
[hidden email]
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
Reply | Threaded
Open this post in threaded view
|

Re: IPF 2.0 project structure draft

Hadrian Zbarcea
Hi,

You probably know that 2.0-M3 was released last week.  There is one  
major changes coming in 2.0 actually related to faults.

If you followed the [hidden email] mailing list there will be no get/
setFault api in the Exchange. Instead what we know as faults today  
will be out Messages with a fault flag set.  This is to differentiate  
between persistent and transient errors during message flow.

This change will have an impact on ipf.  I am not sure when the right  
time to start the transition is.  Coding against 2.0-m3 would be fine  
i guess, but for a final release of ifp 2.0, i'd say better is to wait  
for camel 2.0 which is to be expected i guess within 6-8 weeks at  
most.  And again, I can help with the migration.

Cheers,
Hadrian

On Jul 28, 2009, at 5:12 AM, Martin Krasser wrote:

> As mentioned in one of my previous posts here's now a proposal for the
> new IPF 2.0 project structure.
>
> http://repo.openehealth.org/confluence/display/ipf/IPF+2.0#IPF2.0-IPF2.0projectstructure
>
> After the next milestone release (planned for end of this week) we  
> will
>
> - continue IPF 1.7 development on a separate ipf-1.7 branch
> - start with IPF 2.0 development on the trunk (reusing changes from  
> the
> experimental IPF 2.0 branch)
>
> As always, feedback is highly welcome.
>
> Cheers,
> Martin
>
> _______________________________________________
> Ipf-developer mailing list
> [hidden email]
> http://gforge.openehealth.org/mailman/listinfo/ipf-developer

_______________________________________________
Ipf-developer mailing list
[hidden email]
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
Reply | Threaded
Open this post in threaded view
|

Re: IPF 2.0 project structure draft

christian.ohr
In reply to this post by mrt1nz

I'm not sure about the distinction between "libraries" and "modules". You probably end up ripping apart e.g. HL7 and CDA functionality into at least two projects (if not three, because there's always some small IPF integration project as well). I wonder whether "implementing the modules API" is the right discriminator. Also, isn't  "Libraries that support IPF features but can be used independently of Camel and IPF" is also true for "modules"?

I would still prefer to have "libraries" that provides basic domain-independent helper classes (either implementing the API or not), and "modules", that work on a higher level of abstraction, i.e. bounded by eHealth topics like IHE profiles or HL7 or CDA. I'd also like to merge HL7 and HL7DSL.

As an alternative, throw everything together under "libraries" as long as it doesn't have any Camel dependencies.

cheers
Christian

Christian Ohr | Software Architect | R&D ProfessionalGate
InterComponentWare AG | Industriestraße 41 | 69190 Walldorf (Baden) | Germany
Tel.: +49 (0) 6227 385 152 | Fax: +49 (0) 6227 385 491
[hidden email] |
www.icw.de| www.lifesensor.com


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ICW und GE Healthcare starten strategische Partnerschaft. Anspruch
beider Unternehmen ist, weltweit anstehende Transformationsprozesse
in nationalen Gesundheitswesen mit flexiblen und interoperablen
IT-Lösungen zu unterstützen:
www.icw.de/presse
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *




[hidden email] wrote on 28.07.2009 11:12:35:

> [image removed]

>
> [Ipf-developer] IPF 2.0 project structure draft

>
> Martin Krasser

>
> to:

>
> ipf-developer

>
> 28.07.2009 16:30

>
> Sent by:

>
> [hidden email]

>
> Please respond to ipf-developer

>

> As mentioned in one of my previous posts here's now a proposal for the
> new IPF 2.0 project structure.
>
>
http://repo.openehealth.org/confluence/display/ipf/IPF+2.0#IPF2.0-
> IPF2.0projectstructure
>
> After the next milestone release (planned for end of this week) we will
>
> - continue IPF 1.7 development on a separate ipf-1.7 branch
> - start with IPF 2.0 development on the trunk (reusing changes from the
> experimental IPF 2.0 branch)
>
> As always, feedback is highly welcome.
>
> Cheers,
> Martin
>
> _______________________________________________
> Ipf-developer mailing list
> [hidden email]
>
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
InterComponentWare AG:
Vorstand: Peter Reuschel (Vors.), Norbert Olsacher / Aufsichtsratsvors.: Prof. Dr. Christof Hettich
Firmensitz: 69190 Walldorf, Industriestraße 41 / AG Mannheim HRB 351761 / USt.-IdNr.: DE 198388516

_______________________________________________
Ipf-developer mailing list
[hidden email]
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
Reply | Threaded
Open this post in threaded view
|

Re: IPF 2.0 project structure draft

mrt1nz
Administrator
In reply to this post by Hadrian Zbarcea
Hi Hadrian,

Waiting for Camel 2.0.0 before releasing IPF 2.0 is what we wanted to
do. Our initial expectation was that Camel 2.0.0 will be released in
August (I remember a mailing list post that mentioned a release by end
of July). This would perfectly fit a planned release date of IPF 2.0
beginning of September. With a Camel 2.0.0 release in 6-8 weeks we'll
need to rethink our release plans. It would be great if another Camel
2.0-M4 milestone with a stable API/SPI could be released mid of August.
Do you think that this is doable? Then we could at least start coding
against a stable API and do an IPF 2.0.1 release later that includes
Camel 2.0.0

Current work with Camel 2.0 milestones is for dealing with all the other
changes in Camel that have an impact on IPF. The experimental IPF 2.0
branch is already using Camel 2.0-M3. Regarding fault messages, IPF is
only making very limited use of them and I'm currently thinking about
not using them at all (... at the framework level but we will likely see
an impact in IPF applications).

On the experimental IPF 2.0 branch I started to upgrade
platform-camel-core and platform-camel-flow to Camel 2.0 M3.
Contributions to the upgrade of the other platform-camel-* components
are highly welcome. Please let us know to which other components you'd
like to contribute (either via the mailing list or via the issue tracker
- I'll create corresponding tracker items soon). This week upgrade work
should be done on the experimental branch and beginning of next week we
merge them into the new IPF 2.0 trunk and do further upgrade work
directly there (especially the XDS components should be upgraded
directly there because they're outdated on the experimental branch).
After upgrading to Camel 2.0-M3 (or M4) I'd like to start with the
restructuring and package renaming of the IPF project. After that the
final Camel 2.0.0 upgrade is palnned. Did you make any progress
regarding the Java 5 support in the meantime?

Cheers,
Martin

Hadrian Zbarcea schrieb:

> Hi,
>
> You probably know that 2.0-M3 was released last week.  There is one  
> major changes coming in 2.0 actually related to faults.
>
> If you followed the [hidden email] mailing list there will be no get/
> setFault api in the Exchange. Instead what we know as faults today  
> will be out Messages with a fault flag set.  This is to differentiate  
> between persistent and transient errors during message flow.
>
> This change will have an impact on ipf.  I am not sure when the right  
> time to start the transition is.  Coding against 2.0-m3 would be fine  
> i guess, but for a final release of ifp 2.0, i'd say better is to wait  
> for camel 2.0 which is to be expected i guess within 6-8 weeks at  
> most.  And again, I can help with the migration.
>
> Cheers,
> Hadrian
>
> On Jul 28, 2009, at 5:12 AM, Martin Krasser wrote:
>
>  
>> As mentioned in one of my previous posts here's now a proposal for the
>> new IPF 2.0 project structure.
>>
>> http://repo.openehealth.org/confluence/display/ipf/IPF+2.0#IPF2.0-IPF2.0projectstructure
>>
>> After the next milestone release (planned for end of this week) we  
>> will
>>
>> - continue IPF 1.7 development on a separate ipf-1.7 branch
>> - start with IPF 2.0 development on the trunk (reusing changes from  
>> the
>> experimental IPF 2.0 branch)
>>
>> As always, feedback is highly welcome.
>>
>> Cheers,
>> Martin
>>
>> _______________________________________________
>> Ipf-developer mailing list
>> [hidden email]
>> http://gforge.openehealth.org/mailman/listinfo/ipf-developer
>>    
>
> _______________________________________________
> Ipf-developer mailing list
> [hidden email]
> http://gforge.openehealth.org/mailman/listinfo/ipf-developer
>
>  

_______________________________________________
Ipf-developer mailing list
[hidden email]
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
Reply | Threaded
Open this post in threaded view
|

Re: IPF 2.0 project structure draft

mrt1nz
Administrator
In reply to this post by christian.ohr
Hi Christian,

I was also thinking whether the distinction between libraries and
modules is somewhat artificial. So I don't see an issue if we throw them
all together under libraries. Furthermore I'd also like to drop the
'libraries' package name e.g. instead of having an
org.openehealth.ipf.libraries.flow package we only have an
org.openehealth.ipf.flow. Otherwise it's a bit strange to have a
<<library>> stereotype in the package names (especially if these libs
are reused by other apps without using IPF as a platform or framework).
For all other categories I'd leave the category name in the package name
(e.g. org.openehealth.ipf.platform.flow)

Any thoughts?

Cheers,
Martin

[hidden email] schrieb:

>
> I'm not sure about the distinction between "libraries" and "modules".
> You probably end up ripping apart e.g. HL7 and CDA functionality into
> at least two projects (if not three, because there's always some small
> IPF integration project as well). I wonder whether "implementing the
> modules API" is the right discriminator. Also, isn't  "Libraries that
> support IPF features but can be used independently of Camel and IPF"
> is also true for "modules"?
>
> I would still prefer to have "libraries" that provides basic
> domain-independent helper classes (either implementing the API or
> not), and "modules", that work on a higher level of abstraction, i.e.
> bounded by eHealth topics like IHE profiles or HL7 or CDA. I'd also
> like to merge HL7 and HL7DSL.
>
> As an alternative, throw everything together under "libraries" as long
> as it doesn't have any Camel dependencies.
>
> cheers
> Christian
>
> Christian Ohr | Software Architect | R&D ProfessionalGate
> InterComponentWare AG | Industriestraße 41 | 69190 Walldorf (Baden) |
> Germany
> Tel.: +49 (0) 6227 385 152 | Fax: +49 (0) 6227 385 491
> [hidden email] | www.icw.de| www.lifesensor.com
>
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> ICW und GE Healthcare starten strategische Partnerschaft. Anspruch
> beider Unternehmen ist, weltweit anstehende Transformationsprozesse
> in nationalen Gesundheitswesen mit flexiblen und interoperablen
> IT-Lösungen zu unterstützen: www.icw.de/presse
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
>
>
>
> [hidden email] wrote on 28.07.2009 11:12:35:
>
> > [image removed]
> >
> > [Ipf-developer] IPF 2.0 project structure draft
> >
> > Martin Krasser
> >
> > to:
> >
> > ipf-developer
> >
> > 28.07.2009 16:30
> >
> > Sent by:
> >
> > [hidden email]
> >
> > Please respond to ipf-developer
> >
> > As mentioned in one of my previous posts here's now a proposal for the
> > new IPF 2.0 project structure.
> >
> > http://repo.openehealth.org/confluence/display/ipf/IPF+2.0#IPF2.0-
> > IPF2.0projectstructure
> >
> > After the next milestone release (planned for end of this week) we will
> >
> > - continue IPF 1.7 development on a separate ipf-1.7 branch
> > - start with IPF 2.0 development on the trunk (reusing changes from the
> > experimental IPF 2.0 branch)
> >
> > As always, feedback is highly welcome.
> >
> > Cheers,
> > Martin
> >
> > _______________________________________________
> > Ipf-developer mailing list
> > [hidden email]
> > http://gforge.openehealth.org/mailman/listinfo/ipf-developer
> InterComponentWare AG:
> Vorstand: Peter Reuschel (Vors.), Norbert Olsacher /
> Aufsichtsratsvors.: Prof. Dr. Christof Hettich
> Firmensitz: 69190 Walldorf, Industriestraße 41 / AG Mannheim HRB
> 351761 / USt.-IdNr.: DE 198388516
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ipf-developer mailing list
> [hidden email]
> http://gforge.openehealth.org/mailman/listinfo/ipf-developer
>  

_______________________________________________
Ipf-developer mailing list
[hidden email]
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
Reply | Threaded
Open this post in threaded view
|

Re: IPF 2.0 project structure draft

christian.ohr

Sounds good.
Anyway I don't think that the "flow" library will EVER be used outside the IPF platform, i.e. without the Flow Manager service (except inside a JConsole classpath). It's more like an internal model... Probably the same is true for "test" and maybe also "event".

Christian

Christian Ohr | Software Architect | R&D ProfessionalGate
InterComponentWare AG | Industriestraße 41 | 69190 Walldorf (Baden) | Germany
Tel.: +49 (0) 6227 385 152 | Fax: +49 (0) 6227 385 491
[hidden email] |
www.icw.de| www.lifesensor.com


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ICW und GE Healthcare starten strategische Partnerschaft. Anspruch
beider Unternehmen ist, weltweit anstehende Transformationsprozesse
in nationalen Gesundheitswesen mit flexiblen und interoperablen
IT-Lösungen zu unterstützen:
www.icw.de/presse
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *




[hidden email] wrote on 29.07.2009 09:46:24:

> [image removed]

>
> Re: [Ipf-developer] IPF 2.0 project structure draft

>
> Martin Krasser

>
> to:

>
> ipf-developer

>
> 29.07.2009 09:46

>
> Sent by:

>
> [hidden email]

>
> Please respond to ipf-developer

>

> Hi Christian,
>
> I was also thinking whether the distinction between libraries and
> modules is somewhat artificial. So I don't see an issue if we throw them
> all together under libraries. Furthermore I'd also like to drop the
> 'libraries' package name e.g. instead of having an
> org.openehealth.ipf.libraries.flow package we only have an
> org.openehealth.ipf.flow. Otherwise it's a bit strange to have a
> <<library>> stereotype in the package names (especially if these libs
> are reused by other apps without using IPF as a platform or framework).
> For all other categories I'd leave the category name in the package name
> (e.g. org.openehealth.ipf.platform.flow)
>
> Any thoughts?
>
> Cheers,
> Martin
>
> [hidden email] schrieb:
> >
> > I'm not sure about the distinction between "libraries" and "modules".
> > You probably end up ripping apart e.g. HL7 and CDA functionality into
> > at least two projects (if not three, because there's always some small
> > IPF integration project as well). I wonder whether "implementing the
> > modules API" is the right discriminator. Also, isn't  "Libraries that
> > support IPF features but can be used independently of Camel and IPF"
> > is also true for "modules"?
> >
> > I would still prefer to have "libraries" that provides basic
> > domain-independent helper classes (either implementing the API or
> > not), and "modules", that work on a higher level of abstraction, i.e.
> > bounded by eHealth topics like IHE profiles or HL7 or CDA. I'd also
> > like to merge HL7 and HL7DSL.
> >
> > As an alternative, throw everything together under "libraries" as long
> > as it doesn't have any Camel dependencies.
> >
> > cheers
> > Christian
> >
> > Christian Ohr | Software Architect | R&D ProfessionalGate
> > InterComponentWare AG | Industriestraße 41 | 69190 Walldorf (Baden) |
> > Germany
> > Tel.: +49 (0) 6227 385 152 | Fax: +49 (0) 6227 385 491
> > [hidden email] |
<a href=www.icw.de|>www.icw.de|www.lifesensor.com
> >
> >
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> > ICW und GE Healthcare starten strategische Partnerschaft. Anspruch
> > beider Unternehmen ist, weltweit anstehende Transformationsprozesse
> > in nationalen Gesundheitswesen mit flexiblen und interoperablen
> > IT-Lösungen zu unterstützen:
www.icw.de/presse
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> >
> >
> >
> >
> > [hidden email] wrote on 28.07.2009 11:12:35:
> >
> > > [image removed]
> > >
> > > [Ipf-developer] IPF 2.0 project structure draft
> > >
> > > Martin Krasser
> > >
> > > to:
> > >
> > > ipf-developer
> > >
> > > 28.07.2009 16:30
> > >
> > > Sent by:
> > >
> > > [hidden email]
> > >
> > > Please respond to ipf-developer
> > >
> > > As mentioned in one of my previous posts here's now a proposal for the
> > > new IPF 2.0 project structure.
> > >
> > >
http://repo.openehealth.org/confluence/display/ipf/IPF+2.0#IPF2.0-
> > > IPF2.0projectstructure
> > >
> > > After the next milestone release (planned for end of this week) we will
> > >
> > > - continue IPF 1.7 development on a separate ipf-1.7 branch
> > > - start with IPF 2.0 development on the trunk (reusing changes from the
> > > experimental IPF 2.0 branch)
> > >
> > > As always, feedback is highly welcome.
> > >
> > > Cheers,
> > > Martin
> > >
> > > _______________________________________________
> > > Ipf-developer mailing list
> > > [hidden email]
> > >
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
> > InterComponentWare AG:
> > Vorstand: Peter Reuschel (Vors.), Norbert Olsacher /
> > Aufsichtsratsvors.: Prof. Dr. Christof Hettich
> > Firmensitz: 69190 Walldorf, Industriestraße 41 / AG Mannheim HRB
> > 351761 / USt.-IdNr.: DE 198388516
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Ipf-developer mailing list
> > [hidden email]
> >
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
> >  
>
> _______________________________________________
> Ipf-developer mailing list
> [hidden email]
>
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
InterComponentWare AG:
Vorstand: Peter Reuschel (Vors.), Norbert Olsacher / Aufsichtsratsvors.: Prof. Dr. Christof Hettich
Firmensitz: 69190 Walldorf, Industriestraße 41 / AG Mannheim HRB 351761 / USt.-IdNr.: DE 198388516

_______________________________________________
Ipf-developer mailing list
[hidden email]
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
Reply | Threaded
Open this post in threaded view
|

Re: IPF 2.0 project structure draft

mrt1nz
Administrator
Wiki page is updated. The 'libraries' is still part of artifact and
package names - still not sure if it's a good idea to introduce an
exception to the naming scheme to avoid having a 'stereotype' in the
package names. Anyway it's too hot today to make a clear decision :)

Cheers,
Martin

[hidden email] schrieb:

>
> Sounds good.
> Anyway I don't think that the "flow" library will EVER be used outside
> the IPF platform, i.e. without the Flow Manager service (except inside
> a JConsole classpath). It's more like an internal model... Probably
> the same is true for "test" and maybe also "event".
>
> Christian
>
> Christian Ohr | Software Architect | R&D ProfessionalGate
> InterComponentWare AG | Industriestraße 41 | 69190 Walldorf (Baden) |
> Germany
> Tel.: +49 (0) 6227 385 152 | Fax: +49 (0) 6227 385 491
> [hidden email] | www.icw.de| www.lifesensor.com
>
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> ICW und GE Healthcare starten strategische Partnerschaft. Anspruch
> beider Unternehmen ist, weltweit anstehende Transformationsprozesse
> in nationalen Gesundheitswesen mit flexiblen und interoperablen
> IT-Lösungen zu unterstützen: www.icw.de/presse
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
>
>
>
> [hidden email] wrote on 29.07.2009 09:46:24:
>
> > [image removed]
> >
> > Re: [Ipf-developer] IPF 2.0 project structure draft
> >
> > Martin Krasser
> >
> > to:
> >
> > ipf-developer
> >
> > 29.07.2009 09:46
> >
> > Sent by:
> >
> > [hidden email]
> >
> > Please respond to ipf-developer
> >
> > Hi Christian,
> >
> > I was also thinking whether the distinction between libraries and
> > modules is somewhat artificial. So I don't see an issue if we throw
> them
> > all together under libraries. Furthermore I'd also like to drop the
> > 'libraries' package name e.g. instead of having an
> > org.openehealth.ipf.libraries.flow package we only have an
> > org.openehealth.ipf.flow. Otherwise it's a bit strange to have a
> > <<library>> stereotype in the package names (especially if these libs
> > are reused by other apps without using IPF as a platform or framework).
> > For all other categories I'd leave the category name in the package
> name
> > (e.g. org.openehealth.ipf.platform.flow)
> >
> > Any thoughts?
> >
> > Cheers,
> > Martin
> >
> > [hidden email] schrieb:
> > >
> > > I'm not sure about the distinction between "libraries" and "modules".
> > > You probably end up ripping apart e.g. HL7 and CDA functionality into
> > > at least two projects (if not three, because there's always some
> small
> > > IPF integration project as well). I wonder whether "implementing the
> > > modules API" is the right discriminator. Also, isn't  "Libraries that
> > > support IPF features but can be used independently of Camel and IPF"
> > > is also true for "modules"?
> > >
> > > I would still prefer to have "libraries" that provides basic
> > > domain-independent helper classes (either implementing the API or
> > > not), and "modules", that work on a higher level of abstraction, i.e.
> > > bounded by eHealth topics like IHE profiles or HL7 or CDA. I'd also
> > > like to merge HL7 and HL7DSL.
> > >
> > > As an alternative, throw everything together under "libraries" as
> long
> > > as it doesn't have any Camel dependencies.
> > >
> > > cheers
> > > Christian
> > >
> > > Christian Ohr | Software Architect | R&D ProfessionalGate
> > > InterComponentWare AG | Industriestraße 41 | 69190 Walldorf (Baden) |
> > > Germany
> > > Tel.: +49 (0) 6227 385 152 | Fax: +49 (0) 6227 385 491
> > > [hidden email] | www.icw.de| <www.icw.de%7C>www.lifesensor.com
> > >
> > >
> > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * * *
> > > ICW und GE Healthcare starten strategische Partnerschaft. Anspruch
> > > beider Unternehmen ist, weltweit anstehende Transformationsprozesse
> > > in nationalen Gesundheitswesen mit flexiblen und interoperablen
> > > IT-Lösungen zu unterstützen: www.icw.de/presse
> > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * * *
> > >
> > >
> > >
> > >
> > > [hidden email] wrote on 28.07.2009
> 11:12:35:
> > >
> > > > [image removed]
> > > >
> > > > [Ipf-developer] IPF 2.0 project structure draft
> > > >
> > > > Martin Krasser
> > > >
> > > > to:
> > > >
> > > > ipf-developer
> > > >
> > > > 28.07.2009 16:30
> > > >
> > > > Sent by:
> > > >
> > > > [hidden email]
> > > >
> > > > Please respond to ipf-developer
> > > >
> > > > As mentioned in one of my previous posts here's now a proposal
> for the
> > > > new IPF 2.0 project structure.
> > > >
> > > > http://repo.openehealth.org/confluence/display/ipf/IPF+2.0#IPF2.0-
> > > > IPF2.0projectstructure
> > > >
> > > > After the next milestone release (planned for end of this week)
> we will
> > > >
> > > > - continue IPF 1.7 development on a separate ipf-1.7 branch
> > > > - start with IPF 2.0 development on the trunk (reusing changes
> from the
> > > > experimental IPF 2.0 branch)
> > > >
> > > > As always, feedback is highly welcome.
> > > >
> > > > Cheers,
> > > > Martin
> > > >
> > > > _______________________________________________
> > > > Ipf-developer mailing list
> > > > [hidden email]
> > > > http://gforge.openehealth.org/mailman/listinfo/ipf-developer
> > > InterComponentWare AG:
> > > Vorstand: Peter Reuschel (Vors.), Norbert Olsacher /
> > > Aufsichtsratsvors.: Prof. Dr. Christof Hettich
> > > Firmensitz: 69190 Walldorf, Industriestraße 41 / AG Mannheim HRB
> > > 351761 / USt.-IdNr.: DE 198388516
> > >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Ipf-developer mailing list
> > > [hidden email]
> > > http://gforge.openehealth.org/mailman/listinfo/ipf-developer
> > >  
> >
> > _______________________________________________
> > Ipf-developer mailing list
> > [hidden email]
> > http://gforge.openehealth.org/mailman/listinfo/ipf-developer
> InterComponentWare AG:
> Vorstand: Peter Reuschel (Vors.), Norbert Olsacher /
> Aufsichtsratsvors.: Prof. Dr. Christof Hettich
> Firmensitz: 69190 Walldorf, Industriestraße 41 / AG Mannheim HRB
> 351761 / USt.-IdNr.: DE 198388516
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ipf-developer mailing list
> [hidden email]
> http://gforge.openehealth.org/mailman/listinfo/ipf-developer
>  

_______________________________________________
Ipf-developer mailing list
[hidden email]
http://gforge.openehealth.org/mailman/listinfo/ipf-developer
Reply | Threaded
Open this post in threaded view
|

Re: IPF 2.0 project structure draft

Hadrian Zbarcea
In reply to this post by mrt1nz
As of now, we're still shooting for second half of August. We're  
confident all the api changes and fixes will be in, but we'll have to  
make sure the kit is really stable, examples work, and so forth.  
Obviously, all the help we can get with testing the release candidates  
is highly appreciated :).

Hadrian


On Jul 29, 2009, at 3:46 AM, Martin Krasser wrote:

> Hi Hadrian,
>
> Waiting for Camel 2.0.0 before releasing IPF 2.0 is what we wanted to
> do. Our initial expectation was that Camel 2.0.0 will be released in
> August (I remember a mailing list post that mentioned a release by end
> of July). This would perfectly fit a planned release date of IPF 2.0
> beginning of September. With a Camel 2.0.0 release in 6-8 weeks we'll
> need to rethink our release plans. It would be great if another Camel
> 2.0-M4 milestone with a stable API/SPI could be released mid of  
> August.
> Do you think that this is doable? Then we could at least start coding
> against a stable API and do an IPF 2.0.1 release later that includes
> Camel 2.0.0
>
> Current work with Camel 2.0 milestones is for dealing with all the  
> other
> changes in Camel that have an impact on IPF. The experimental IPF 2.0
> branch is already using Camel 2.0-M3. Regarding fault messages, IPF is
> only making very limited use of them and I'm currently thinking about
> not using them at all (... at the framework level but we will likely  
> see
> an impact in IPF applications).
>
> On the experimental IPF 2.0 branch I started to upgrade
> platform-camel-core and platform-camel-flow to Camel 2.0 M3.
> Contributions to the upgrade of the other platform-camel-* components
> are highly welcome. Please let us know to which other components you'd
> like to contribute (either via the mailing list or via the issue  
> tracker
> - I'll create corresponding tracker items soon). This week upgrade  
> work
> should be done on the experimental branch and beginning of next week  
> we
> merge them into the new IPF 2.0 trunk and do further upgrade work
> directly there (especially the XDS components should be upgraded
> directly there because they're outdated on the experimental branch).
> After upgrading to Camel 2.0-M3 (or M4) I'd like to start with the
> restructuring and package renaming of the IPF project. After that the
> final Camel 2.0.0 upgrade is palnned. Did you make any progress
> regarding the Java 5 support in the meantime?
>
> Cheers,
> Martin
>
> Hadrian Zbarcea schrieb:
>> Hi,
>>
>> You probably know that 2.0-M3 was released last week.  There is one
>> major changes coming in 2.0 actually related to faults.
>>
>> If you followed the [hidden email] mailing list there will be no get/
>> setFault api in the Exchange. Instead what we know as faults today
>> will be out Messages with a fault flag set.  This is to differentiate
>> between persistent and transient errors during message flow.
>>
>> This change will have an impact on ipf.  I am not sure when the right
>> time to start the transition is.  Coding against 2.0-m3 would be fine
>> i guess, but for a final release of ifp 2.0, i'd say better is to  
>> wait
>> for camel 2.0 which is to be expected i guess within 6-8 weeks at
>> most.  And again, I can help with the migration.
>>
>> Cheers,
>> Hadrian
>>
>> On Jul 28, 2009, at 5:12 AM, Martin Krasser wrote:
>>
>>
>>> As mentioned in one of my previous posts here's now a proposal for  
>>> the
>>> new IPF 2.0 project structure.
>>>
>>> http://repo.openehealth.org/confluence/display/ipf/IPF+2.0#IPF2.0-IPF2.0projectstructure
>>>
>>> After the next milestone release (planned for end of this week) we
>>> will
>>>
>>> - continue IPF 1.7 development on a separate ipf-1.7 branch
>>> - start with IPF 2.0 development on the trunk (reusing changes from
>>> the
>>> experimental IPF 2.0 branch)
>>>
>>> As always, feedback is highly welcome.
>>>
>>> Cheers,
>>> Martin
>>>
>>> _______________________________________________
>>> Ipf-developer mailing list
>>> [hidden email]
>>> http://gforge.openehealth.org/mailman/listinfo/ipf-developer
>>>
>>
>> _______________________________________________
>> Ipf-developer mailing list
>> [hidden email]
>> http://gforge.openehealth.org/mailman/listinfo/ipf-developer
>>
>>
>
> _______________________________________________
> Ipf-developer mailing list
> [hidden email]
> http://gforge.openehealth.org/mailman/listinfo/ipf-developer

_______________________________________________
Ipf-developer mailing list
[hidden email]
http://gforge.openehealth.org/mailman/listinfo/ipf-developer