You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/09/12 18:06:04 UTC
Comments on Avalon-Framework RC
Steve, I have a question and a comment really. The question is: does the build
have all the stuff I did so far to improve error reporting in configuration
elements?
My comment is that we should have the AbstractLogEnabled class as part of the
interface/API portion. Several projects I know of almost depend on that class,
but they don't necessarily depend on anything else in the IMPL portion directly.
I would prefer *not* to have the AbstractLoggable interface in the API part for
the simple reason that it forces the API to have an explicit dependency on
LogKit--and it is deprecated so its use should be discouraged.
I guess the last question would be do we want to start a "deprecated/compat"
JAR distributable to house all the stuff that is marked as deprecated? That
way new projects can simply focus on the current stuff and old projects will
have to either add a dependency (not hard) or upgrade (higher level of effort).
What do you think?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Comments on Avalon-Framework RC
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
>> Yes - Leo moved it all across to sandbox.
>
>
> you're building the RCs from the sandbox? Hmm. Seems like a weird
> twist of events :D. Anyways, since you got the combined jar
> functionality back (I think?) and the new gump build script is holding
> up, I'll
Combined jar as there.
Here is the snipet of script used to construct it.
<!-- Add composite jar -->
<ant:jar jarfile="${maven.build.dir}/${maven.final.name}.jar"
compress="true" manifest="manifest.mf">
<ant:fileset dir="api/target/classes"/>
<ant:fileset dir="impl/target/classes"/>
</ant:jar>
>
> - `cvs tag` the avalon cvs
> - `cvs tag` the sandbox cvs
> - copy the sandbox framework over to the main repo (yes, we keep all
> history)
> - `cvs rm` the sandbox framework
> - `cvs tag` the avalon cvs again
>
> tomorrow morning, if that's okay with you.
+1
Steve.
>
> cheers,
>
> - LSD
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
avalon/framework CVS restructuring complete
Posted by Leo Simons <le...@apache.org>.
(resend for mail archive searching purposes)
We did some restructuring of the build system for the avalon/framework
package over in avalon-sandbox/framework, then I did a little CVS
surgery to move the restructured package back to avalon/framework when
it was done. Look for the tag Avalon_4_1_5_RC4 which exists both in
avalon-sandbox and avalon cvs for the situation prior to the manual
merge. Look for Avalon_4_1_5_RC4_2 for the situation after the merge.
cheers,
- Leo
Leo Simons wrote:
> Leo Simons wrote:
>
>> - `cvs tag` the avalon cvs
>> - `cvs tag` the sandbox cvs
>> - copy the sandbox framework over to the main repo (yes, we keep all
>> history)
>> - `cvs rm` the sandbox framework
>> - `cvs tag` the avalon cvs again
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Comments on Avalon-Framework RC
Posted by Leo Simons <le...@apache.org>.
Leo Simons wrote:
> - `cvs tag` the avalon cvs
> - `cvs tag` the sandbox cvs
> - copy the sandbox framework over to the main repo (yes, we keep all
> history)
> - `cvs rm` the sandbox framework
> - `cvs tag` the avalon cvs again
done. Everything seems to be in working order.
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Comments on Avalon-Framework RC
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> Yes - Leo moved it all across to sandbox.
you're building the RCs from the sandbox? Hmm. Seems like a weird twist
of events :D. Anyways, since you got the combined jar functionality back
(I think?) and the new gump build script is holding up, I'll
- `cvs tag` the avalon cvs
- `cvs tag` the sandbox cvs
- copy the sandbox framework over to the main repo (yes, we keep all
history)
- `cvs rm` the sandbox framework
- `cvs tag` the avalon cvs again
tomorrow morning, if that's okay with you.
cheers,
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Comments on Avalon-Framework RC
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> BTW, The docs look nice, and I like the links to the mailing lists.
>>
>> Two comments though (couldn't resist):
>>
>> * We should probably have the mailing lists page centralized if we can.
>
>
>
> This is auto generated content.
> We can centralize this at the build level later later.
Not a show stopper. I agree.
>
>>
>> * We might want to enable the Test Report and the metrics report.
>>
>> That way we can make that info a bit more accessible.
>
>
>
> Yes - but lets do this later. Doing this with a multi-source project
> does not work will with maven in its current form. Lots of plugins dont
> respect the source path attribute so you are forced to do some shuffling
> of results and I would prefer to do that sort of thing - if - maven
> final does not take care of it properly.
Ok. Again, I agree. Not trying to force a ton of stuff here.
>>>
>>> My comment is that we should have the AbstractLogEnabled class as
>>> part of the
>>> interface/API portion. Several projects I know of almost depend on
>>> that class,
>>> but they don't necessarily depend on anything else in the IMPL
>>> portion directly.
>>> I would prefer *not* to have the AbstractLoggable interface in the
>>> API part for
>>> the simple reason that it forces the API to have an explicit
>>> dependency on
>>> LogKit--and it is deprecated so its use should be discouraged.
>>
>>
>
> I agree. If nobody objects I'll cut a new release this weekend under
> 4.1.5 (i.e. drop the RC3 tag) containing AbstractLogEnabled inside the API.
Cool! Thanks.
>
>>>
>>> I guess the last question would be do we want to start a
>>> "deprecated/compat"
>>> JAR distributable to house all the stuff that is marked as
>>> deprecated? That
>>> way new projects can simply focus on the current stuff and old
>>> projects will
>>> have to either add a dependency (not hard) or upgrade (higher level
>>> of effort).
>>>
>>> What do you think?
>>
>>
>
> Can we worry about it later?
Yep. You did ask for comments, though ;P
Trust me, I am not as detailed as the IV&V (Independant Verification and
Validation) guy I get to work with on the job. He would go so far as to mention
that the exact text of a property that must be replaced at install time does
not match the installation instructions. A non-issue, but mentioned nonetheless
;P
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Comments on Avalon-Framework RC
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> BTW, The docs look nice, and I like the links to the mailing lists.
>
> Two comments though (couldn't resist):
>
> * We should probably have the mailing lists page centralized if we can.
This is auto generated content.
We can centralize this at the build level later later.
>
> * We might want to enable the Test Report and the metrics report.
>
> That way we can make that info a bit more accessible.
Yes - but lets do this later. Doing this with a multi-source project
does not work will with maven in its current form. Lots of plugins dont
respect the source path attribute so you are forced to do some shuffling
of results and I would prefer to do that sort of thing - if - maven
final does not take care of it properly.
>
> Berin Loritsch wrote:
>
>> Steve, I have a question and a comment really. The question is: does
>> the build
>> have all the stuff I did so far to improve error reporting in
>> configuration
>> elements?
>
Yes - Leo moved it all across to sandbox.
>>
>>
>> My comment is that we should have the AbstractLogEnabled class as
>> part of the
>> interface/API portion. Several projects I know of almost depend on
>> that class,
>> but they don't necessarily depend on anything else in the IMPL
>> portion directly.
>> I would prefer *not* to have the AbstractLoggable interface in the
>> API part for
>> the simple reason that it forces the API to have an explicit
>> dependency on
>> LogKit--and it is deprecated so its use should be discouraged.
>
I agree. If nobody objects I'll cut a new release this weekend under
4.1.5 (i.e. drop the RC3 tag) containing AbstractLogEnabled inside the API.
>>
>> I guess the last question would be do we want to start a
>> "deprecated/compat"
>> JAR distributable to house all the stuff that is marked as
>> deprecated? That
>> way new projects can simply focus on the current stuff and old
>> projects will
>> have to either add a dependency (not hard) or upgrade (higher level
>> of effort).
>>
>> What do you think?
>
Can we worry about it later?
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Comments on Avalon-Framework RC
Posted by Berin Loritsch <bl...@apache.org>.
BTW, The docs look nice, and I like the links to the mailing lists.
Two comments though (couldn't resist):
* We should probably have the mailing lists page centralized if we can.
* We might want to enable the Test Report and the metrics report.
That way we can make that info a bit more accessible.
Berin Loritsch wrote:
> Steve, I have a question and a comment really. The question is: does
> the build
> have all the stuff I did so far to improve error reporting in configuration
> elements?
>
> My comment is that we should have the AbstractLogEnabled class as part
> of the
> interface/API portion. Several projects I know of almost depend on that
> class,
> but they don't necessarily depend on anything else in the IMPL portion
> directly.
> I would prefer *not* to have the AbstractLoggable interface in the API
> part for
> the simple reason that it forces the API to have an explicit dependency on
> LogKit--and it is deprecated so its use should be discouraged.
>
> I guess the last question would be do we want to start a
> "deprecated/compat"
> JAR distributable to house all the stuff that is marked as deprecated?
> That
> way new projects can simply focus on the current stuff and old projects
> will
> have to either add a dependency (not hard) or upgrade (higher level of
> effort).
>
> What do you think?
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org