You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/02/16 17:58:44 UTC
an approach to framework 4.1.4 packaging
Have been thinking about how to handle the packaging of 4.1.4. In an
earlier email I suggested that this could be done with some fine grain
manipulation in the buildfile. While that is possible - it is also an
approach that can easily lead to errors due to the non-inclusion of a
file in a jar because a buildfile was not updated.
My current thinking is that we should split the avalon project into a
'common', 'spec' and 'impl' project. The spec and impl project would
simply handle the compilation and jar creation and the common avalon
project build would pull in these resources as part of an overall dist
and doc generation focus.
I.e. - repacking the avalon CVS project as follows
avalon
-- avalon-common
- build.xml <-- includes dist target and import of spec and impl jars
- src/documentation
- src/xdocs
- tools
-- avalon-spec
- build.xml <-- compile and jar the spec project
- src/java <-- interfaces and self contained classes
-- avalon-impl
- lib
- build.xml <-- compile and jar the impl project
- src/java <-- general implementation classes
If this sounds reasonable I would like to recruit some help from someone
who can "manipulate" the file system to create the copies of the current
tree under a avalon-common, avalon-spec and avalon-impl. I can then dig
into seperating what is in each without loosing CVS info.
Thoughts?
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: an approach to framework 4.1.4 packaging
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>> Have been thinking about how to handle the packaging of 4.1.4. In an
>> earlier email I suggested that this could be done with some fine
>> grain manipulation in the buildfile. While that is possible - it is
>> also an approach that can easily lead to errors due to the
>> non-inclusion of a file in a jar because a buildfile was not updated.
>>
>
> <snip/>
>
>> If this sounds reasonable I would like to recruit some help from
>> someone who can "manipulate" the file system to create the copies of
>> the current tree under a avalon-common, avalon-spec and avalon-impl.
>> I can then dig into seperating what is in each without loosing CVS info.
>>
>> Thoughts?
>
>
> I am not crazy about the idea of doing so much CVS upheaval right before
> a release. That would push the inclusion of this feature further out
> than should be included for the release timefrime I want to shoot for.
> In the short term, we have to go for simple or not at all. The longer
> term will allow us to pursue avenues like this.
>
> However, I do want us to do the easiest thing to make it possible, and
> no more. If we apply that philosophy to everything, we can get releases
> out much more frequently.
Berin:
Similar sentiments here - how about we release what we have now and work
on a good seperation with a little more time on our hands.
Cheers, Steve.
>
>
> ---------------------------------------------------------------------
> 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
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: an approach to framework 4.1.4 packaging
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> Have been thinking about how to handle the packaging of 4.1.4. In an
> earlier email I suggested that this could be done with some fine grain
> manipulation in the buildfile. While that is possible - it is also an
> approach that can easily lead to errors due to the non-inclusion of a
> file in a jar because a buildfile was not updated.
>
<snip/>
> If this sounds reasonable I would like to recruit some help from someone
> who can "manipulate" the file system to create the copies of the current
> tree under a avalon-common, avalon-spec and avalon-impl. I can then dig
> into seperating what is in each without loosing CVS info.
>
> Thoughts?
I am not crazy about the idea of doing so much CVS upheaval right before
a release. That would push the inclusion of this feature further out
than should be included for the release timefrime I want to shoot for.
In the short term, we have to go for simple or not at all. The longer
term will allow us to pursue avenues like this.
However, I do want us to do the easiest thing to make it possible, and
no more. If we apply that philosophy to everything, we can get releases
out much more frequently.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: an approach to framework 4.1.4 packaging
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> My current thinking is that we should split the avalon project into a
> 'common', 'spec' and 'impl' project.
<snip/>
> Thoughts?
definately not a good idea for 4.1.4. Beyond that, sure thing! I have
some more ideas on cvs/package organisation which kinda include this
idea of yours (basically been experimenting with what works best in a
maven setup :D). I suggest we delay talks until after the ECM release or
something...
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: an approach to framework 4.1.4 packaging
Posted by Stephen McConnell <mc...@apache.org>.
Noel:
Yep - I'm certainly receptive to delaying this until after 4.1.4 - maybe
4.2 as a target (i.e. I see this as something well before A5).
Cheers, Steve.
Noel J. Bergman wrote:
>Stephen,
>
>Sounds reasonable for AV5 and for a release after the one Berin is trying to
>put out. Probably not a great idea to shuffle the CVS while trying to do a
>release.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>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
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: an approach to framework 4.1.4 packaging
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen,
Sounds reasonable for AV5 and for a release after the one Berin is trying to
put out. Probably not a great idea to shuffle the CVS while trying to do a
release.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: an approach to framework 4.1.4 packaging
Posted by Leo Simons <le...@apache.org>.
Leo Sutic wrote:
>>From: Paul Hammant [mailto:paul_hammant@yahoo.com]
>>
>>We're confusing CVS refactoring with real work again (no offence).
>>
>>It would be more Maven friendly with separate project hierarchys.
>
> Is a CVS module the smallest unit Maven can handle?
nope.
> I don't
> really understand how it becomes more friendly, as I thought
> Maven handled deps. on the individual JAR level.
sort-of, yep. Maven can support lots of different project setups, and it
has support for stuff like dependency grouping (even if the docs don't
reflect that yet).
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: an approach to framework 4.1.4 packaging
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Paul Hammant [mailto:paul_hammant@yahoo.com]
>
> We're confusing CVS refactoring with real work again (no offence).
>
> It would be more Maven friendly with separate project hierarchys.
Is a CVS module the smallest unit Maven can handle? I don't
really understand how it becomes more friendly, as I thought
Maven handled deps. on the individual JAR level.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: an approach to framework 4.1.4 packaging
Posted by Paul Hammant <pa...@yahoo.com>.
Folks,
> > My current thinking is that we should split the avalon project into a
> > 'common', 'spec' and 'impl' project.
> >
> > Thoughts?
>
> Seems like we're getting a plethora of subprojects instead of
> the plethora of sub-subprojects we had before.
>
> Can't we just arrange the source code into:
>
> avalon/src/java/
> |
> +- spec/
> |
> +- impl/
>
> ?
>
> This would make interface/impl compilation & packaging easier, plus
> we get to keep things into one project which should be much easier
> than splitting it over three projects.
We're confusing CVS refactoring with real work again (no offence).
It would be more Maven friendly with separate project hierarchys.
So -1 for incluing any impl of Avalon in the avalon/ tree.
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: an approach to framework 4.1.4 packaging
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> My current thinking is that we should split the avalon project into a
> 'common', 'spec' and 'impl' project.
>
> Thoughts?
Seems like we're getting a plethora of subprojects instead of
the plethora of sub-subprojects we had before.
Can't we just arrange the source code into:
avalon/src/java/
|
+- spec/
|
+- impl/
?
This would make interface/impl compilation & packaging easier, plus
we get to keep things into one project which should be much easier
than splitting it over three projects.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org