05/11/09 17:42
What have I been doing recently?
Building a variety of projects.
These include some - relatively - old projects. All of the CoffeeShop sample code in JUnit Recipes: Practical Methods for Programmer Testing -
Here are the details --
By: J. B. Rainsberger
Publisher: Manning Publications
Pub. Date: July 15, 2004
Print ISBN-10: 1-932394-23-0
Print ISBN-13: 978-1-932394-23-8
Pages in Print Edition: 752
Building a variety of projects.
These include some - relatively - old projects. All of the CoffeeShop sample code in JUnit Recipes: Practical Methods for Programmer Testing -
Here are the details --
By: J. B. Rainsberger
Publisher: Manning Publications
Pub. Date: July 15, 2004
Print ISBN-10: 1-932394-23-0
Print ISBN-13: 978-1-932394-23-8
Pages in Print Edition: 752
Look up safaribooksonline
This is from around 2005.
I have also done same with zoe, also from around 2005.
Interesting.
CoffeeShop, with multiple projects, needed a lot of work reconciling dependencies.
In come my friends jarvana and so.
zoe [1.,2.,3.,4.] is different, and, in a way, more complex.
zoe is configured for maven1 with a project.xml file.
It is instructive making the conversion by hand. Certainly the mvn one:convert tool cannot cope.
There are guesses that can be made that must be regular mappings. So why not look at the xsd for each version, along with any notes, and make a map from this, say using generateDS?
I have also done same with zoe, also from around 2005.
Interesting.
CoffeeShop, with multiple projects, needed a lot of work reconciling dependencies.
In come my friends jarvana and so.
zoe [1.,2.,3.,4.] is different, and, in a way, more complex.
zoe is configured for maven1 with a project.xml file.
It is instructive making the conversion by hand. Certainly the mvn one:convert tool cannot cope.
There are guesses that can be made that must be regular mappings. So why not look at the xsd for each version, along with any notes, and make a map from this, say using generateDS?
There are some other things.
The way I see it is that we have.
The way I see it is that we have.
ant builds - these entail finding canonical versions of referenced artifacts across a system - as far as is
possible.
1.1. when artifacts have been resolved the .properties file needs to be referenced in the created pom
1.2. the build.xml file needs to be parsed, from what I can see just for directory locations
1.3. the build file remains intact, other tasks, such as code generation, will be invoked via ant
1.3.1. some tasks are ant like and it is not reasonable to use maven for them. However some tasks imply something
about structure that really needs to be resolved in the pom module dependency hierarchy.
It is unclear how to make this distinction automatically, but a mechanism to create a module against
which a specific complex ant task is run would go some way.
maven1 builds - this would entail a mapping between the two as mentioned.
creating canonical versions and canonical version management.
3.1. creating canonical - there are different issues here. Finally it seems that there is no way of engineering
an unknown version apart from doing a look up
3.2. look ups have their own difficulties and interest. Sometimes a project cannot be found -
3.2.1. the jar is not available on public repositories, e.g. Sun version jars
3.2.2. the particular version is not available
3.3. above seems to be an issue that could be solved with some very sophisticated search - more later
3.4. canonical version management - augeas with the magic lens seems to be the way to control this and seems
preferable to an XML db. It would only be build.xml that would be appropriate to an xml db anyway.
issues to explore are semantic annotation, which would seem appropriate to build.xml etc. This maybe made
automatic if it is possible to digest the nature of the ant tasks.
0 comments:
Post a Comment