* reuse is bliss
* rtfm
* it doesn't matter if the standard sucks?
* restructure, then release
* leaky abstractions?
* who needs consensus anyway?Reuse Is Bliss --------------
I have committed maven based builds for four seperated cornerstone components.
cool!
while that setup is quite simple, it has the disadvantage that there's a lot of files to maintain:
project.xml
${component}/maven.xml
${component}/project.xml
${component}/api/maven.xml
${component}/api/project.xml
${component}/impl/maven.xml
${component}/impl/project.xmlof which there's actually more than a few files one would need to edit to change aspects of the build. I'd like that to just be
${component}/project.xml
with everything that is common actually shared.
It doesn't matter if the standard sucks? ----------------------------------------
seperation in directory structure (ie src/api/ and src/impl/). Yet another thing I want to do is convert the build to maven.
The structure I've put in place (and recommend) is to place the impl and apis into seperate subprojects of a common group. I.e. threads contains sup-project api and subproject impl (as per discussion on list a while back).
link / keyword? There's a 100 ways to do it. How important is it we consistently pick the same way?
RTFM ----
I would like to see a little stabalization of the new Avalon build. Based on an attempt to build using Maven early yesterday I had a bunch of messages telling me I had to do a bunch of things (and the message was way too long). This should not be necessary. Using Maven the entire process should be automated. I would prefer to see a clean solution (i.e. get maven, cd to your project, type "maven" and your done).
MPSRTFM (More People Should Read The [EMAIL PROTECTED] Manual) :D
cd avalon/framework
maven dist -Doverride.version=4.2
maven avalon:deploy -Doverride.version=4.2 cd ../fortress/container
maven dist -Doverride.version=1.1
maven avalon:deploy -Doverride.version=1.1 cd ../tools
maven dist -Doverride.version=1.1
maven avalon:deploy -Doverride.version=1.1releases built and deployed. To keep docs from appearing, just change buildsystem/maven.xml to have "dist" as the default goal (or something like that) instead of "avalon:info". But that is a bad idea.
Restructure, then release -------------------------
1) we should create a brand-new repository avalon-components, with a maven build structure and a directory structure similar to what I have put in place for the avalon repository
2) we should move the packages in list (1) there
we should discuss this after a release of the core suite
Restructuring is way down on the list of priorities as far as I can see and can always be done once the cornerstone releases are completed.
hmm. This is exactly my point: we should do restructure now, get something stable in place, *then* release. Otherwise we'll end up with incompatible releases or big changes further down the road which will just annoy your users.
putting it another way: I'm not going to do any of this /after/ a release because at that point the incentive to do it is gone. I am willing to invest the time /once/ to refactor builds and automate everything.
Leaky abstractions? -------------------
I disagree with this distinction. For me, Excalibur is about low-level utilities.
well, we disagree :D. I think many of the components in excalibur would be sm.lookup()ped together with many of the components in cornerstone and it would make sense. Oh well, we're not going to agree so lets drop that for now...
[a single repository (with single build structure, single website, etc etc) for all our components] is only valid if you ignore the different granularity of the object/components provided under excalibur versus cornerstone.
why?
This also enables an important discussion that should take place concerning the distinction in the levels of abstractions - IMHO - excalibur is a very different level of abstraction to cornerstone -
and these abstractions should not be merged together.
I think the differences are not as clear-cut as you paint them, nor do I
think that matters. I really don't see why the fact that the cornerstone-sockets interface is a little more abstract than the excalibur-sourceresolve would make it inconvenient to have these live side by side. We don't have the energy nor the desire to maintain all these different repos and build structures.
Who needs consensus anyway? --------------------------- > Can I presume that what you are thinking is 100% consitent with the > stuff I've committed yesterday and earlier today?
well, nope :D. But that's okay.
you go ahead and whip cornerstone into shape, I'll keep out of the way. Consider my proposal dropped in favor of Just Getting Things Done (By You, Not Me).
cheers!
- LSD, late for work (tm)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
