Raffael Herzog schrieb:
> > On 08/02/07, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> > > IIRC, people has done very similar things in the past.
>
> Sure, this is nothing new. However, up to now, I haven't found
> anything which is able to handle the complex case of Silk/Loom. In
> Silk/Loom, you'll have to combine configurations from several sources
> into one single configuration:
OK, I'm picking this up once again. I'd also like to quote Niclas from
the HiveApp thread:
> Perhaps you know I am not to crazy about XML, especially hand-edited
> one, but since you say "e.g.", I am curious...
And I generally agree at this point. XML is human readable and writable,
but it's designed for being read and written by machines in the first
place.
The more I think about it, the more I like the idea of a specialised
Syntax for Silk project files. Thanks, Niclas, that reminder of what I
think about XML myself made me think hard, which sometimes produces
some results. ;)
So, let's go ...
First of all, a Silk project configuration is still a hierarchically
organised structure of values. But this structure can be kept rather
flat, I think. It should actually be reducible to:
- sections, possibly parametrised (=> "what I am generally talking about
right now" or "what functionallity am I configurung")
- values
- compound values
These should be enough for configuring a project.
Let's look at a hypothetical project.silk file:
// Java-style comments are supported, both // for line comments and
// /* ... */ for block comments
// the start of a section; this one could actually be left out, as
// it's the default at the start of a file
general:
// our first compound value; compound values can be spread across
// several lines, but must be terminated by ';'
info name 'MyProject'
version '1.0'
description 'An awesome project';
// now, we start another section, where we configure the main Java
// compilation unit
java(main):
// simple values; simple values do not have to be terminated
// by ';', but they can, for the sake of consistence; they cannot be
// spread across sever lines
source 1.5
target 1.5
dependency m2
group org.apache
artifact commons-digester
version 1.7;
dependency obr ...;
Let's look at the hivemodule.xml files:
<!-- hivemodule.xml of the core plugin itself -->
<contribution configuration-id="ConfigurationSections">
<section class="GeneralSection"/>
</contribution>
<!-- hivemodule.xml of the java plugin -->
<contribution configuration-id="ConfigurationSections">
<section class="CompilationUnit"/>
</contribution>
The classes:
public class GeneralSection {
@Compound("info")
@Optional
public ProjectInfo createProjectInfo() {...}
// because the parser can only validate the contents of the config
// file, after inspecting the result of createProjectInfo(), I'm
// splitting this up in two steps, to avoid incomplete ProjectInfo
// objects in our GeneralSection object; this is optional
@EndCompound("info")
public void addProjectInfo(ProjectInfo info) {...}
}
public class ProjectInfo {
@Value("name")
@Quoted
public void setName(String name) {...}
@Value("version")
@Quoted
public void setVersion(String version) {...}
@Value("description")
@Optional("No description")
@Quoted
public void setDescription(String description) {...}
}
public class CompilationUnit {
@Value("target")
@Optional
public void setTarget(String target) {...}
@Value("source")
@Optional
public void setSource(String source) {...}
@Compound("dependency")
@Optional
@Repeatable
public Dependency createDependency(String type) {...}
@EndCompound("dependency")
public void addDependency(Dependency dependency) {...}
}
I think, that would be better than my previous idea:
- The syntax is proprietary, but easy enough that missing tools support
isn't really an issue
- It's easy to parse
- It's human readable and, more importantly, human typable
- I think, it provides all that's needed to be able to configure
projects
- It's much easier implement handling of the annotations, than
for "full-blown" XML
Is that a better proposal? :)
cu,
Raffi
--
The difference between theory and practice is that in theory, there is
no difference, but in practice, there is.
[EMAIL PROTECTED] · Jabber: [EMAIL PROTECTED]
PGP Key 0x5FFDB5DB5D1FF5F4 · http://keyserver.pgp.com
_______________________________________________
general mailing list
general@lists.ops4j.org
http://lists.ops4j.org/mailman/listinfo/general
