commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: [configuration] Cutting a 1.0 Release Help Needed
Date Mon, 29 Mar 2004 10:58:01 GMT
Jörg,

I think wat you have proposed is a good compromise..  We'll leave
configurationfactory alone so as not to create a dependency on the apis for
jdk1.3, and if you can get me that patch, I'll do it all tomarrow morning.

then, as part of 1.1, doing the refactoring on ConfigurationFactory will be
great..

Eric



> -----Original Message-----
> From: Jörg Schaible [mailto:Joerg.Schaible@Elsag-Solutions.com]
> Sent: Monday, March 29, 2004 9:42 AM
> To: Jakarta Commons Developers List; epugh@upstate.com
> Subject: RE: [configuration] Cutting a 1.0 Release Help Needed
>
>
> Eric Pugh wrote on Monday, March 29, 2004 10:57 AM:
>
> > Ok,
> >
> > I just went back and reread the posts..  Basically what you
> > want is to refactor the HierarchicalDOM4JConfiguration into
> > AbstractHierarchicalConfiguration and then have
> > HierarchicalDOM4JConfiguration and HierarchicalDOMConfiguration.
>
> Well, here
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27498 I just
> have the additional classes for basic DOM support (inkl. unit
> tests). Any refactoring I would also see post 1.0.
>
> > You then would retrofit the ConfigurationFactory to support a
> > <dom> as well as a <dom4j> element?
>
> Well, if it is just for DOM support it is a one liner. Personally
> I would break up the ConfigurationFactory into a more pluggable
> approach, but this can also wait post 1.0.
>
> > Is this correct?  If you verify that this won't break 1.3
> > compatiblity (which I guess it won't..?) and can send in a
> > patch ASAP with some doc fixes and unit tests, then I'll hold
> > up the release.  I definitly would want to document the
> > differences between dom and dom4j...
>
> IMHO we just have to decide, if we should add this single line in
> ConfigurationFactory for 1.0 or not. This would imply a
> dependency on xml-apis for JDK 1.3 ... therefore I did not add it
> in first line. And since the ConfigurationFactory did also not
> support the DB based config at the moment, I would just add the
> files from the patch. Then we have 1.0 with DOM4J as default, but
> anyone can use JDK 1.4 DOM (although currently not with the
> ConfigurfationFactory) if he likes to (as it is done with DB
> config). For post 1.1 I would refactor the factory as already
> proposed some time ago and then we have support for any kind of
> configuration technology, but only with the implied depenencies a
> user really wants to have.
>
> > Any idea how long it will take you to get this done?
> > Otherwise we can cut 1.0, and then, as soon as you get your
> > code in, either cut 1.0.1 or just cut a snapshot for you.
>
> So my proposal: Add 27498 and release 1.0 and do any further
> refactoring later.
>
> But do me another favour: Remove this cruft from the
> commons-configuration-x.y.jar, that is collected in the root of
> the archive. I have a modified project.xml at home, that avoids
> this. I'll create an issue this evening (~ 8h from now) if you like.
>
> Regards,
> Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message