RE: List of packages on scala-tools

The question whether the POM supports this-and-that is a moot one. Why not just add an XML namespace for scala extensions and do it like this:   <project xmlns="..." xmlns:s="http://www.scala-tools.org/namespaces/scala-metadata">
  <!-- ... -->
  <s:tags>
    <s:tag>whatever</s:tag>
  </s:tags>

  <!-- ... -->
</project>
A much cleaner solution IMO.
On Fri, Apr 23, 2010 at 10:32 AM, Detering Dirk <Dirk.Detering@bitmarck.de> wrote:

> -----Original Message-----
> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
> Sent: Friday, April 23, 2010 5:23 AM
> To: Daniel Sobral
> Cc: Toby Corkindale; James Strachan; Scala User list
> Subject: Re: [scala-user] List of packages on scala-tools
>
> For what purpose?

Well, wouldn't it be natural for an XML file to
represent items in XML markuped style?

Otherwise you would have another separate parsing step with
a different (non-xml) parser to get the taglist as
a list structure, while after parsing the primary XML no
path-expression oriented access is possible into the taglist.

>
>
> On Thu, Apr 22, 2010 at 11:17 PM, Daniel Sobral <dcsobral@gmail.com>
> wrote:
>
>
>       I quite agree with that.
>
>
>       On Thu, Apr 22, 2010 at 10:50 PM, Toby Corkindale
> <toby@dryft.net> wrote:
>
>
>               On 21 April 2010 18:07, James Strachan
> <james.strachan@gmail.com> wrote:
>               > On 21 April 2010 08:28, David Bernard
> <david.bernard.31@gmail.com> wrote:
>               >> I thinks the suggestion to add a property in th pom is
> more easier to parse:
>               >>
>               >> <properties>
>               >>   <project.tags>internet, social, beta</project.tags>
>               >> </properties>
>               >>
>               >> From what I understand mvnrepository.com predefine a
> list of tag and
>               >> categorize artifact in the tag in the artifact name,
> description,
>               >> artifactId, groupId
>               >
>               > The pom.xml already has most metadata about a project
> (,name,
>               > description, home page, license, source code, issue
> tracker, CI server
>               > etc) so no real need for JSON right now IMHO. The only
> real missing
>               > bit of information I can think of right now is the tags -
> so I'm
>               > liking the "project.tags" property idea as that seems to
> be the one
>               > missing bit of metadata in the pom.xml.
>               >
>               > So should the tags be space separated or comma separated?
> :). Folks
>               > used to delicious might not bother with the commas; so
> I'd be tempted
>               > to tokenise by whitespace and commas?
>
>
>
>               Well, if we're using XML, the tags should be separated by
> tags!
>
>               ie.
>
>               <project.tags>
>                <tag>internet</tag>
>                <tag>social</tag>
>                <tag>railway stations</tag>
>               </project.tags>
>
>
>
>
>
>       --
>       Daniel C. Sobral
>
>       I travel to the future all the time.
>
>

I might accept:- it's more robust- you have a good idea for future metadata, and this approach is more extensible- it's more idiomatic xml - it could ease scraping if this is being done with pure xslt constructs

Though I could counter-argue all of the above:- robustness is a tough sell; boilerplate makes it less maintainable, which arguably reduces robustness- properties are extensible to some level, be specific, or this will just be a burdensome framework to support extensions that never actually happen - it may be idiomatic, but a comma-separated list in xsl is far from rare- xslt supports the tokenise function, which can easily split a comma-separated list

But you'd have to bribe me quite heavily before I'd accept it as "cleaner", I just see a lot of boilerplate and accidental complexity.  If we're going so far as to isolate this stuff in an entire dedicated namespace, then we may as well just use a separate file with one tag per line - can't get much cleaner than that!




On 23 April 2010 10:36, David Flemström <david.flemstrom@gmail.com> wrote:

The question whether the POM supports this-and-that is a moot one. Why not just add an XML namespace for scala extensions and do it like this:   <project xmlns="..." xmlns:s="http://www.scala-tools.org/namespaces/scala-metadata">
  <!-- ... -->
  <s:tags>
    <s:tag>whatever</s:tag>
  </s:tags>

  <!-- ... -->
</project>
A much cleaner solution IMO.
On Fri, Apr 23, 2010 at 10:32 AM, Detering Dirk <Dirk.Detering@bitmarck.de> wrote:

> -----Original Message-----
> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
> Sent: Friday, April 23, 2010 5:23 AM
> To: Daniel Sobral
> Cc: Toby Corkindale; James Strachan; Scala User list
> Subject: Re: [scala-user] List of packages on scala-tools
>
> For what purpose?

Well, wouldn't it be natural for an XML file to
represent items in XML markuped style?

Otherwise you would have another separate parsing step with
a different (non-xml) parser to get the taglist as
a list structure, while after parsing the primary XML no
path-expression oriented access is possible into the taglist.

>
>
> On Thu, Apr 22, 2010 at 11:17 PM, Daniel Sobral <dcsobral@gmail.com>
> wrote:
>
>
>       I quite agree with that.
>
>
>       On Thu, Apr 22, 2010 at 10:50 PM, Toby Corkindale
> <toby@dryft.net> wrote:
>
>
>               On 21 April 2010 18:07, James Strachan
> <james.strachan@gmail.com> wrote:
>               > On 21 April 2010 08:28, David Bernard
> <david.bernard.31@gmail.com> wrote:
>               >> I thinks the suggestion to add a property in th pom is
> more easier to parse:
>               >>
>               >> <properties>
>               >>   <project.tags>internet, social, beta</project.tags>
>               >> </properties>
>               >>
>               >> From what I understand mvnrepository.com predefine a
> list of tag and
>               >> categorize artifact in the tag in the artifact name,
> description,
>               >> artifactId, groupId
>               >
>               > The pom.xml already has most metadata about a project
> (,name,
>               > description, home page, license, source code, issue
> tracker, CI server
>               > etc) so no real need for JSON right now IMHO. The only
> real missing
>               > bit of information I can think of right now is the tags -
> so I'm
>               > liking the "project.tags" property idea as that seems to
> be the one
>               > missing bit of metadata in the pom.xml.
>               >
>               > So should the tags be space separated or comma separated?
> :). Folks
>               > used to delicious might not bother with the commas; so
> I'd be tempted
>               > to tokenise by whitespace and commas?
>
>
>
>               Well, if we're using XML, the tags should be separated by
> tags!
>
>               ie.
>
>               <project.tags>
>                <tag>internet</tag>
>                <tag>social</tag>
>                <tag>railway stations</tag>
>               </project.tags>
>
>
>
>
>
>       --
>       Daniel C. Sobral
>
>       I travel to the future all the time.
>
>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

So are you saying that the purpose would be to make it easier to code the spiderer?

On Fri, Apr 23, 2010 at 4:32 AM, Detering Dirk <Dirk.Detering@bitmarck.de> wrote:

> -----Original Message-----
> From: Naftoli Gugenheim [mailto:naftoligug@gmail.com]
> Sent: Friday, April 23, 2010 5:23 AM
> To: Daniel Sobral
> Cc: Toby Corkindale; James Strachan; Scala User list
> Subject: Re: [scala-user] List of packages on scala-tools
>
> For what purpose?

Well, wouldn't it be natural for an XML file to
represent items in XML markuped style?

Otherwise you would have another separate parsing step with
a different (non-xml) parser to get the taglist as
a list structure, while after parsing the primary XML no
path-expression oriented access is possible into the taglist.

>
>
> On Thu, Apr 22, 2010 at 11:17 PM, Daniel Sobral <dcsobral@gmail.com>
> wrote:
>
>
>       I quite agree with that.
>
>
>       On Thu, Apr 22, 2010 at 10:50 PM, Toby Corkindale
> <toby@dryft.net> wrote:
>
>
>               On 21 April 2010 18:07, James Strachan
> <james.strachan@gmail.com> wrote:
>               > On 21 April 2010 08:28, David Bernard
> <david.bernard.31@gmail.com> wrote:
>               >> I thinks the suggestion to add a property in th pom is
> more easier to parse:
>               >>
>               >> <properties>
>               >>   <project.tags>internet, social, beta</project.tags>
>               >> </properties>
>               >>
>               >> From what I understand mvnrepository.com predefine a
> list of tag and
>               >> categorize artifact in the tag in the artifact name,
> description,
>               >> artifactId, groupId
>               >
>               > The pom.xml already has most metadata about a project
> (,name,
>               > description, home page, license, source code, issue
> tracker, CI server
>               > etc) so no real need for JSON right now IMHO. The only
> real missing
>               > bit of information I can think of right now is the tags -
> so I'm
>               > liking the "project.tags" property idea as that seems to
> be the one
>               > missing bit of metadata in the pom.xml.
>               >
>               > So should the tags be space separated or comma separated?
> :). Folks
>               > used to delicious might not bother with the commas; so
> I'd be tempted
>               > to tokenise by whitespace and commas?
>
>
>
>               Well, if we're using XML, the tags should be separated by
> tags!
>
>               ie.
>
>               <project.tags>
>                <tag>internet</tag>
>                <tag>social</tag>
>                <tag>railway stations</tag>
>               </project.tags>
>
>
>
>
>
>       --
>       Daniel C. Sobral
>
>       I travel to the future all the time.
>
>

On Fri, Apr 23, 2010 at 12:12 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

But you'd have to bribe me quite heavily before I'd accept it as "cleaner", I just see a lot of boilerplate and accidental complexity.  If we're going so far as to isolate this stuff in an entire dedicated namespace, then we may as well just use a separate file with one tag per line - can't get much cleaner than that!

Problem: random files are not automatically included in published artifacts; POMs most certainly are.

Fair point! Though I wasn't seriously proposing it's something we actually do :)I strongly favour a simple-as-possible within-the-pom solution.

On 23 April 2010 19:56, David Flemström <david.flemstrom@gmail.com> wrote:

On Fri, Apr 23, 2010 at 12:12 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

But you'd have to bribe me quite heavily before I'd accept it as "cleaner", I just see a lot of boilerplate and accidental complexity.  If we're going so far as to isolate this stuff in an entire dedicated namespace, then we may as well just use a separate file with one tag per line - can't get much cleaner than that!

Problem: random files are not automatically included in published artifacts; POMs most certainly are.

On Fri, Apr 23, 2010 at 12:12 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

But you'd have to bribe me quite heavily before I'd accept it as "cleaner", I just see a lot of boilerplate and accidental complexity.  If we're going so far as to isolate this stuff in an entire dedicated namespace, then we may as well just use a separate file with one tag per line - can't get much cleaner than that!

When I say 'clean', I usually refer to something that lacks complexity (and not only from the user's perspective).
For example, let's say that a special property was introduced called "project.tags" and that contained a comma-separated tag cloud as some have been suggesting. This might at first seem like a 'clean' solution as seen from the POM writer's perspective, but there are a heap of problems coming along as well. Let's say that someone wants to have a tag that includes a comma. Or let's say that a need for "main tags", "category tags" and "cloud tags" arises. Continuing along the same line of clean thinking, we might end up with something like:

<project.tags>[sbt plugin],[compiler plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type checker,dev</project.tags>

(I took this horrid syntax as an example because I've seen something very similar in a tag-based CSS-like selector system I've been unfortunate enough to work with recently. They also started out with a "clean" system)
Yes, this seemingly simple system works, but it:

1. introduces a completely new syntax that has to be learned both by developers and parsers
2. doesn't scale well
3. is very implementation dependent (Can the syntax be understood by other tag consumers? Is there an easy way to standardize it?)

I understand that you already realize most of this, but I just wanted to be explicit.
BTW, for comparison:

<s:tags>
    <s:tag type="main">sbt plugin</s:tag>
    <s:tag type="main">compiler plugin</s:tag>
    <s:tag type="main" alias="compiler-plugin">compiler plugin</s:tag>
    <s:tag type="category">development</s:tag>
    <s:tag>type checker</s:tag>
    <s:tag>dev</s:tag>
</s:tags>

If this is too verbose for you, get a tool that writes your POMs for you (e.g. NetBeans).

The point David makes about pom-building is important. POMs are not really meant for humans, editable as they might be. They are meant for programs, just as the goal of these tags is being used by software. No one is going to open POM files and look up the tags.
For the user, I can easily see one doing something like this in SBT:
val projectTags = Set("testing-framework", "bdd")

On Fri, Apr 23, 2010 at 5:11 PM, David Flemström <david.flemstrom@gmail.com> wrote:

On Fri, Apr 23, 2010 at 12:12 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

But you'd have to bribe me quite heavily before I'd accept it as "cleaner", I just see a lot of boilerplate and accidental complexity.  If we're going so far as to isolate this stuff in an entire dedicated namespace, then we may as well just use a separate file with one tag per line - can't get much cleaner than that!

When I say 'clean', I usually refer to something that lacks complexity (and not only from the user's perspective).
For example, let's say that a special property was introduced called "project.tags" and that contained a comma-separated tag cloud as some have been suggesting. This might at first seem like a 'clean' solution as seen from the POM writer's perspective, but there are a heap of problems coming along as well. Let's say that someone wants to have a tag that includes a comma. Or let's say that a need for "main tags", "category tags" and "cloud tags" arises. Continuing along the same line of clean thinking, we might end up with something like:

<project.tags>[sbt plugin],[compiler plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type checker,dev</project.tags>

(I took this horrid syntax as an example because I've seen something very similar in a tag-based CSS-like selector system I've been unfortunate enough to work with recently. They also started out with a "clean" system)
Yes, this seemingly simple system works, but it:

1. introduces a completely new syntax that has to be learned both by developers and parsers
2. doesn't scale well
3. is very implementation dependent (Can the syntax be understood by other tag consumers? Is there an easy way to standardize it?)

I understand that you already realize most of this, but I just wanted to be explicit.
BTW, for comparison:

<s:tags>
    <s:tag type="main">sbt plugin</s:tag>
    <s:tag type="main">compiler plugin</s:tag>
    <s:tag type="main" alias="compiler-plugin">compiler plugin</s:tag>
    <s:tag type="category">development</s:tag>
    <s:tag>type checker</s:tag>
    <s:tag>dev</s:tag>
</s:tags>

If this is too verbose for you, get a tool that writes your POMs for you (e.g. NetBeans).

--
Daniel C. Sobral

I travel to the future all the time.

On Friday 23 April 2010 04:19:17 pm Daniel Sobral wrote:
> The point David makes about pom-building is important. POMs are not really
> meant for humans, editable as they might be. They are meant for programs,
> just as the goal of these tags is being used by software. No one is going
> to open POM files and look up the tags.
>
> For the user, I can easily see one doing something like this in SBT:
>
> val projectTags = Set("testing-framework", "bdd")

Ivy supports extra attributes on IDs and sbt supports this in its Ivy API.
You can define extra attributes on your module and select dependencies with a
specific value for an extra attribute [1]. sbt itself uses this feature and is
one reason why it is published as an ivy.xml instead of a pom [2].

I realize this thread is about putting the information in a pom, but since an
sbt interface was mentioned, I figured I'd point out that something similar
exists in Ivy.

-Mark

[1] http://code.google.com/p/simple-build-
tool/wiki/LibraryManagement#Extra_Attributes
[2] http://databinder.net/repo/org.scala-tools.sbt/compiler-
interface/0.7.3/ivys/ivy.xml

> On Fri, Apr 23, 2010 at 5:11 PM, David Flemström
>
> wrote:
> > On Fri, Apr 23, 2010 at 12:12 PM, Kevin Wright <
> >
> > kev.lee.wright@googlemail.com> wrote:
> >> But you'd have to bribe me quite heavily before I'd accept it as
> >> "cleaner", I just see a lot of boilerplate and accidental complexity.
> >> If we're going so far as to isolate this stuff in an entire dedicated
> >> namespace, then we may as well just use a separate file with one tag per
> >> line - can't get much cleaner than that!
> >
> > When I say 'clean', I usually refer to something that lacks complexity
> > (and not only from the user's perspective).
> >
> > For example, let's say that a special property was introduced called
> > "project.tags" and that contained a comma-separated tag cloud as some
> > have been suggesting. This might at first seem like a 'clean' solution as
> > seen from the POM writer's perspective, but there are a heap of problems
> > coming along as well. Let's say that someone wants to have a tag that
> > includes a comma. Or let's say that a need for "main tags", "category
> > tags" and "cloud tags" arises. Continuing along the same line of clean
> > thinking, we might end up with something like:
> >
> > [sbt plugin],[compiler
> > plugin]{alias='compiler-plugin'},development{type='category'},concurrency
> >,type checker,dev
> >
> > (I took this horrid syntax as an example because I've seen something very
> > similar in a tag-based CSS-like selector system I've been unfortunate
> > enough to work with recently. They also started out with a "clean"
> > system)
> >
> > Yes, this seemingly simple system works, but it:
> >
> > 1. introduces a completely new syntax that has to be learned both by
> > developers and parsers
> > 2. doesn't scale well
> > 3. is very implementation dependent (Can the syntax be understood by
> > other tag consumers? Is there an easy way to standardize it?)
> >
> > I understand that you already realize most of this, but I just wanted to
> > be explicit.
> >
> > BTW, for comparison:
> >
> >
> > sbt plugin
> > compiler plugin
> > compiler plugin
> > development
> > type checker
> > dev
> >
> > If this is too verbose for you, get a tool that writes your POMs for you
> > (e.g. NetBeans).

On 23 April 2010 21:11, David Flemström <david.flemstrom@gmail.com> wrote:

On Fri, Apr 23, 2010 at 12:12 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

But you'd have to bribe me quite heavily before I'd accept it as "cleaner", I just see a lot of boilerplate and accidental complexity.  If we're going so far as to isolate this stuff in an entire dedicated namespace, then we may as well just use a separate file with one tag per line - can't get much cleaner than that!

When I say 'clean', I usually refer to something that lacks complexity (and not only from the user's perspective).
For example, let's say that a special property was introduced called "project.tags" and that contained a comma-separated tag cloud as some have been suggesting. This might at first seem like a 'clean' solution as seen from the POM writer's perspective, but there are a heap of problems coming along as well. Let's say that someone wants to have a tag that includes a comma. Or let's say that a need for "main tags", "category tags" and "cloud tags" arises. Continuing along the same line of clean thinking, we might end up with something like:

<project.tags>[sbt plugin],[compiler plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type checker,dev</project.tags>

(I took this horrid syntax as an example because I've seen something very similar in a tag-based CSS-like selector system I've been unfortunate enough to work with recently. They also started out with a "clean" system)
Yes, this seemingly simple system works, but it:

1. introduces a completely new syntax that has to be learned both by developers and parsers
2. doesn't scale well
3. is very implementation dependent (Can the syntax be understood by other tag consumers? Is there an easy way to standardize it?)

I understand that you already realize most of this, but I just wanted to be explicit.
BTW, for comparison:

<s:tags>
    <s:tag type="main">sbt plugin</s:tag>
    <s:tag type="main">compiler plugin</s:tag>
    <s:tag type="main" alias="compiler-plugin">compiler plugin</s:tag>
    <s:tag type="category">development</s:tag>
    <s:tag>type checker</s:tag>
    <s:tag>dev</s:tag>
</s:tags>

If this is too verbose for you, get a tool that writes your POMs for you (e.g. NetBeans).

There is a middle ground...
I was only ever considering a single class of tags, intended for indexing, searching and human readability
In this context, I'd expect the above example to be something like:

<project.tags>sbt plugin, compiler plugin, concurrency, type checker</project.tags>

Not entirely sure what the intent is behind the category, alias and dev references in your example.  But it's still possible to be a bit richer with a pure property solution and not get too convoluted:

<project.category>development</project.category>

<project.tags>sbt plugin, compiler plugin, concurrency, type checker</project.tags>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

 How about a method like this in SBT :

  def projectSearchableAndPresentableInfo =
    <ProjectInfo name='Etc...'>
      <KeyWords="sbt, compiler, plugin"/>
      <OneParagraphDescription>
         Short description here....
      </OneParagraphDescription>
      <MainPage>
         h1. textile or Markdown markup in here....
      </MainPage>
    </ProjectInfo>

 This would end up in the POM. All project from a maven repo could be extracted to generate a searchable *and* presentable catalogue like site.
Now I don't know how maven behaves if you put non maven tags in a POM. In case it doesn't like it,
I would just cram the whole structure in JSON in the project description tag... Yes it would be very ugly and non human readable,
but I already avoid reading and writing POMs anyways, I leave it to SBT.

 Max

On Fri, Apr 23, 2010 at 7:03 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

On 23 April 2010 21:11, David Flemström <david.flemstrom@gmail.com> wrote:

On Fri, Apr 23, 2010 at 12:12 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

But you'd have to bribe me quite heavily before I'd accept it as "cleaner", I just see a lot of boilerplate and accidental complexity.  If we're going so far as to isolate this stuff in an entire dedicated namespace, then we may as well just use a separate file with one tag per line - can't get much cleaner than that!

When I say 'clean', I usually refer to something that lacks complexity (and not only from the user's perspective).
For example, let's say that a special property was introduced called "project.tags" and that contained a comma-separated tag cloud as some have been suggesting. This might at first seem like a 'clean' solution as seen from the POM writer's perspective, but there are a heap of problems coming along as well. Let's say that someone wants to have a tag that includes a comma. Or let's say that a need for "main tags", "category tags" and "cloud tags" arises. Continuing along the same line of clean thinking, we might end up with something like:

<project.tags>[sbt plugin],[compiler plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type checker,dev</project.tags>

(I took this horrid syntax as an example because I've seen something very similar in a tag-based CSS-like selector system I've been unfortunate enough to work with recently. They also started out with a "clean" system)
Yes, this seemingly simple system works, but it:

1. introduces a completely new syntax that has to be learned both by developers and parsers
2. doesn't scale well
3. is very implementation dependent (Can the syntax be understood by other tag consumers? Is there an easy way to standardize it?)

I understand that you already realize most of this, but I just wanted to be explicit.
BTW, for comparison:

<s:tags>
    <s:tag type="main">sbt plugin</s:tag>
    <s:tag type="main">compiler plugin</s:tag>
    <s:tag type="main" alias="compiler-plugin">compiler plugin</s:tag>
    <s:tag type="category">development</s:tag>
    <s:tag>type checker</s:tag>
    <s:tag>dev</s:tag>
</s:tags>

If this is too verbose for you, get a tool that writes your POMs for you (e.g. NetBeans).

There is a middle ground...
I was only ever considering a single class of tags, intended for indexing, searching and human readability
In this context, I'd expect the above example to be something like:

<project.tags>sbt plugin, compiler plugin, concurrency, type checker</project.tags>

Not entirely sure what the intent is behind the category, alias and dev references in your example.  But it's still possible to be a bit richer with a pure property solution and not get too convoluted:

<project.category>development</project.category>

<project.tags>sbt plugin, compiler plugin, concurrency, type checker</project.tags>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

I'm not adverse to sbt driving this effort... after all, it's going to rule the world one day!
I'd still like to keep it clean and low on boilerplate in the POM though, I can definitely see a slow migration from maven -> sbt for many people, and would love to keep things as accessible as possible!

On 24 April 2010 00:35, Maxime Lévesque <maxime.levesque@gmail.com> wrote:

 How about a method like this in SBT :

  def projectSearchableAndPresentableInfo =
    <ProjectInfo name='Etc...'>
      <KeyWords="sbt, compiler, plugin"/>
      <OneParagraphDescription>
         Short description here....
      </OneParagraphDescription>
      <MainPage>
         h1. textile or Markdown markup in here....
      </MainPage>
    </ProjectInfo>

 This would end up in the POM. All project from a maven repo could be extracted to generate a searchable *and* presentable catalogue like site.
Now I don't know how maven behaves if you put non maven tags in a POM. In case it doesn't like it,
I would just cram the whole structure in JSON in the project description tag... Yes it would be very ugly and non human readable,
but I already avoid reading and writing POMs anyways, I leave it to SBT.

 Max

On Fri, Apr 23, 2010 at 7:03 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

On 23 April 2010 21:11, David Flemström <david.flemstrom@gmail.com> wrote:

On Fri, Apr 23, 2010 at 12:12 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

But you'd have to bribe me quite heavily before I'd accept it as "cleaner", I just see a lot of boilerplate and accidental complexity.  If we're going so far as to isolate this stuff in an entire dedicated namespace, then we may as well just use a separate file with one tag per line - can't get much cleaner than that!

When I say 'clean', I usually refer to something that lacks complexity (and not only from the user's perspective).
For example, let's say that a special property was introduced called "project.tags" and that contained a comma-separated tag cloud as some have been suggesting. This might at first seem like a 'clean' solution as seen from the POM writer's perspective, but there are a heap of problems coming along as well. Let's say that someone wants to have a tag that includes a comma. Or let's say that a need for "main tags", "category tags" and "cloud tags" arises. Continuing along the same line of clean thinking, we might end up with something like:

<project.tags>[sbt plugin],[compiler plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type checker,dev</project.tags>

(I took this horrid syntax as an example because I've seen something very similar in a tag-based CSS-like selector system I've been unfortunate enough to work with recently. They also started out with a "clean" system)
Yes, this seemingly simple system works, but it:

1. introduces a completely new syntax that has to be learned both by developers and parsers
2. doesn't scale well
3. is very implementation dependent (Can the syntax be understood by other tag consumers? Is there an easy way to standardize it?)

I understand that you already realize most of this, but I just wanted to be explicit.
BTW, for comparison:

<s:tags>
    <s:tag type="main">sbt plugin</s:tag>
    <s:tag type="main">compiler plugin</s:tag>
    <s:tag type="main" alias="compiler-plugin">compiler plugin</s:tag>
    <s:tag type="category">development</s:tag>
    <s:tag>type checker</s:tag>
    <s:tag>dev</s:tag>
</s:tags>

If this is too verbose for you, get a tool that writes your POMs for you (e.g. NetBeans).

There is a middle ground...
I was only ever considering a single class of tags, intended for indexing, searching and human readability
In this context, I'd expect the above example to be something like:

<project.tags>sbt plugin, compiler plugin, concurrency, type checker</project.tags>

Not entirely sure what the intent is behind the category, alias and dev references in your example.  But it's still possible to be a bit richer with a pure property solution and not get too convoluted:

<project.category>development</project.category>

<project.tags>sbt plugin, compiler plugin, concurrency, type checker</project.tags>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

Primarily... I think people need to be a little forgiving of Maven.   I help maintain the maven-scala-plugin solely because it was our means of introducing Scala into our existing java projects.   We need to make sure as a community we don't lose sight of the importance of this.    The easier it is for folks to pick up and use scala on existing projects the better.   This means Ant + Maven aren't going away quickly... But we can hopefully get most scala-only or new development to use SBT.

- Josh

On Fri, Apr 23, 2010 at 7:46 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

I'm not adverse to sbt driving this effort... after all, it's going to rule the world one day!
I'd still like to keep it clean and low on boilerplate in the POM though, I can definitely see a slow migration from maven -> sbt for many people, and would love to keep things as accessible as possible!

On 24 April 2010 00:35, Maxime Lévesque <maxime.levesque@gmail.com> wrote:

 How about a method like this in SBT :

  def projectSearchableAndPresentableInfo =
    <ProjectInfo name='Etc...'>
      <KeyWords="sbt, compiler, plugin"/>
      <OneParagraphDescription>
         Short description here....
      </OneParagraphDescription>
      <MainPage>
         h1. textile or Markdown markup in here....
      </MainPage>
    </ProjectInfo>

 This would end up in the POM. All project from a maven repo could be extracted to generate a searchable *and* presentable catalogue like site.
Now I don't know how maven behaves if you put non maven tags in a POM. In case it doesn't like it,
I would just cram the whole structure in JSON in the project description tag... Yes it would be very ugly and non human readable,
but I already avoid reading and writing POMs anyways, I leave it to SBT.

 Max

On Fri, Apr 23, 2010 at 7:03 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

On 23 April 2010 21:11, David Flemström <david.flemstrom@gmail.com> wrote:

On Fri, Apr 23, 2010 at 12:12 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

But you'd have to bribe me quite heavily before I'd accept it as "cleaner", I just see a lot of boilerplate and accidental complexity.  If we're going so far as to isolate this stuff in an entire dedicated namespace, then we may as well just use a separate file with one tag per line - can't get much cleaner than that!

When I say 'clean', I usually refer to something that lacks complexity (and not only from the user's perspective).
For example, let's say that a special property was introduced called "project.tags" and that contained a comma-separated tag cloud as some have been suggesting. This might at first seem like a 'clean' solution as seen from the POM writer's perspective, but there are a heap of problems coming along as well. Let's say that someone wants to have a tag that includes a comma. Or let's say that a need for "main tags", "category tags" and "cloud tags" arises. Continuing along the same line of clean thinking, we might end up with something like:

<project.tags>[sbt plugin],[compiler plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type checker,dev</project.tags>

(I took this horrid syntax as an example because I've seen something very similar in a tag-based CSS-like selector system I've been unfortunate enough to work with recently. They also started out with a "clean" system)
Yes, this seemingly simple system works, but it:

1. introduces a completely new syntax that has to be learned both by developers and parsers
2. doesn't scale well
3. is very implementation dependent (Can the syntax be understood by other tag consumers? Is there an easy way to standardize it?)

I understand that you already realize most of this, but I just wanted to be explicit.
BTW, for comparison:

<s:tags>
    <s:tag type="main">sbt plugin</s:tag>
    <s:tag type="main">compiler plugin</s:tag>
    <s:tag type="main" alias="compiler-plugin">compiler plugin</s:tag>
    <s:tag type="category">development</s:tag>
    <s:tag>type checker</s:tag>
    <s:tag>dev</s:tag>
</s:tags>

If this is too verbose for you, get a tool that writes your POMs for you (e.g. NetBeans).

There is a middle ground...
I was only ever considering a single class of tags, intended for indexing, searching and human readability
In this context, I'd expect the above example to be something like:

<project.tags>sbt plugin, compiler plugin, concurrency, type checker</project.tags>

Not entirely sure what the intent is behind the category, alias and dev references in your example.  But it's still possible to be a bit richer with a pure property solution and not get too convoluted:

<project.category>development</project.category>

<project.tags>sbt plugin, compiler plugin, concurrency, type checker</project.tags>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

 That is very true, if a POM's description tag can be stuffed with non maven tags, without maven
choking, I think it's the best choice by far.


On Fri, Apr 23, 2010 at 7:53 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Primarily... I think people need to be a little forgiving of Maven.   I help maintain the maven-scala-plugin solely because it was our means of introducing Scala into our existing java projects.   We need to make sure as a community we don't lose sight of the importance of this.    The easier it is for folks to pick up and use scala on existing projects the better.   This means Ant + Maven aren't going away quickly... But we can hopefully get most scala-only or new development to use SBT.

- Josh

On Fri, Apr 23, 2010 at 7:46 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

I'm not adverse to sbt driving this effort... after all, it's going to rule the world one day!
I'd still like to keep it clean and low on boilerplate in the POM though, I can definitely see a slow migration from maven -> sbt for many people, and would love to keep things as accessible as possible!

On 24 April 2010 00:35, Maxime Lévesque <maxime.levesque@gmail.com> wrote:

 How about a method like this in SBT :

  def projectSearchableAndPresentableInfo =
    <ProjectInfo name='Etc...'>
      <KeyWords="sbt, compiler, plugin"/>
      <OneParagraphDescription>
         Short description here....
      </OneParagraphDescription>
      <MainPage>
         h1. textile or Markdown markup in here....
      </MainPage>
    </ProjectInfo>

 This would end up in the POM. All project from a maven repo could be extracted to generate a searchable *and* presentable catalogue like site.
Now I don't know how maven behaves if you put non maven tags in a POM. In case it doesn't like it,
I would just cram the whole structure in JSON in the project description tag... Yes it would be very ugly and non human readable,
but I already avoid reading and writing POMs anyways, I leave it to SBT.

 Max

On Fri, Apr 23, 2010 at 7:03 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

On 23 April 2010 21:11, David Flemström <david.flemstrom@gmail.com> wrote:

On Fri, Apr 23, 2010 at 12:12 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

But you'd have to bribe me quite heavily before I'd accept it as "cleaner", I just see a lot of boilerplate and accidental complexity.  If we're going so far as to isolate this stuff in an entire dedicated namespace, then we may as well just use a separate file with one tag per line - can't get much cleaner than that!

When I say 'clean', I usually refer to something that lacks complexity (and not only from the user's perspective).
For example, let's say that a special property was introduced called "project.tags" and that contained a comma-separated tag cloud as some have been suggesting. This might at first seem like a 'clean' solution as seen from the POM writer's perspective, but there are a heap of problems coming along as well. Let's say that someone wants to have a tag that includes a comma. Or let's say that a need for "main tags", "category tags" and "cloud tags" arises. Continuing along the same line of clean thinking, we might end up with something like:

<project.tags>[sbt plugin],[compiler plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type checker,dev</project.tags>

(I took this horrid syntax as an example because I've seen something very similar in a tag-based CSS-like selector system I've been unfortunate enough to work with recently. They also started out with a "clean" system)
Yes, this seemingly simple system works, but it:

1. introduces a completely new syntax that has to be learned both by developers and parsers
2. doesn't scale well
3. is very implementation dependent (Can the syntax be understood by other tag consumers? Is there an easy way to standardize it?)

I understand that you already realize most of this, but I just wanted to be explicit.
BTW, for comparison:

<s:tags>
    <s:tag type="main">sbt plugin</s:tag>
    <s:tag type="main">compiler plugin</s:tag>
    <s:tag type="main" alias="compiler-plugin">compiler plugin</s:tag>
    <s:tag type="category">development</s:tag>
    <s:tag>type checker</s:tag>
    <s:tag>dev</s:tag>
</s:tags>

If this is too verbose for you, get a tool that writes your POMs for you (e.g. NetBeans).

There is a middle ground...
I was only ever considering a single class of tags, intended for indexing, searching and human readability
In this context, I'd expect the above example to be something like:

<project.tags>sbt plugin, compiler plugin, concurrency, type checker</project.tags>

Not entirely sure what the intent is behind the category, alias and dev references in your example.  But it's still possible to be a bit richer with a pure property solution and not get too convoluted:

<project.category>development</project.category>

<project.tags>sbt plugin, compiler plugin, concurrency, type checker</project.tags>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

This is drifting off-topic, but I think an Ant task (and equivalent for Maven) that send commands to a running sbt process (and starts it it if it isn't already started) would be great.  It would help integrate with Java projects and with IDEs like NetBeans that can use Ant/Maven effectively.

On Fri, Apr 23, 2010 at 7:53 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

Primarily... I think people need to be a little forgiving of Maven.   I help maintain the maven-scala-plugin solely because it was our means of introducing Scala into our existing java projects.   We need to make sure as a community we don't lose sight of the importance of this.    The easier it is for folks to pick up and use scala on existing projects the better.   This means Ant + Maven aren't going away quickly... But we can hopefully get most scala-only or new development to use SBT.

- Josh

On Fri, Apr 23, 2010 at 7:46 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

I'm not adverse to sbt driving this effort... after all, it's going to rule the world one day!
I'd still like to keep it clean and low on boilerplate in the POM though, I can definitely see a slow migration from maven -> sbt for many people, and would love to keep things as accessible as possible!

On 24 April 2010 00:35, Maxime Lévesque <maxime.levesque@gmail.com> wrote:

 How about a method like this in SBT :

  def projectSearchableAndPresentableInfo =
    <ProjectInfo name='Etc...'>
      <KeyWords="sbt, compiler, plugin"/>
      <OneParagraphDescription>
         Short description here....
      </OneParagraphDescription>
      <MainPage>
         h1. textile or Markdown markup in here....
      </MainPage>
    </ProjectInfo>

 This would end up in the POM. All project from a maven repo could be extracted to generate a searchable *and* presentable catalogue like site.
Now I don't know how maven behaves if you put non maven tags in a POM. In case it doesn't like it,
I would just cram the whole structure in JSON in the project description tag... Yes it would be very ugly and non human readable,
but I already avoid reading and writing POMs anyways, I leave it to SBT.

 Max

On Fri, Apr 23, 2010 at 7:03 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

On 23 April 2010 21:11, David Flemström <david.flemstrom@gmail.com> wrote:

On Fri, Apr 23, 2010 at 12:12 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

But you'd have to bribe me quite heavily before I'd accept it as "cleaner", I just see a lot of boilerplate and accidental complexity.  If we're going so far as to isolate this stuff in an entire dedicated namespace, then we may as well just use a separate file with one tag per line - can't get much cleaner than that!

When I say 'clean', I usually refer to something that lacks complexity (and not only from the user's perspective).
For example, let's say that a special property was introduced called "project.tags" and that contained a comma-separated tag cloud as some have been suggesting. This might at first seem like a 'clean' solution as seen from the POM writer's perspective, but there are a heap of problems coming along as well. Let's say that someone wants to have a tag that includes a comma. Or let's say that a need for "main tags", "category tags" and "cloud tags" arises. Continuing along the same line of clean thinking, we might end up with something like:

<project.tags>[sbt plugin],[compiler plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type checker,dev</project.tags>

(I took this horrid syntax as an example because I've seen something very similar in a tag-based CSS-like selector system I've been unfortunate enough to work with recently. They also started out with a "clean" system)
Yes, this seemingly simple system works, but it:

1. introduces a completely new syntax that has to be learned both by developers and parsers
2. doesn't scale well
3. is very implementation dependent (Can the syntax be understood by other tag consumers? Is there an easy way to standardize it?)

I understand that you already realize most of this, but I just wanted to be explicit.
BTW, for comparison:

<s:tags>
    <s:tag type="main">sbt plugin</s:tag>
    <s:tag type="main">compiler plugin</s:tag>
    <s:tag type="main" alias="compiler-plugin">compiler plugin</s:tag>
    <s:tag type="category">development</s:tag>
    <s:tag>type checker</s:tag>
    <s:tag>dev</s:tag>
</s:tags>

If this is too verbose for you, get a tool that writes your POMs for you (e.g. NetBeans).

There is a middle ground...
I was only ever considering a single class of tags, intended for indexing, searching and human readability
In this context, I'd expect the above example to be something like:

<project.tags>sbt plugin, compiler plugin, concurrency, type checker</project.tags>

Not entirely sure what the intent is behind the category, alias and dev references in your example.  But it's still possible to be a bit richer with a pure property solution and not get too convoluted:

<project.category>development</project.category>

<project.tags>sbt plugin, compiler plugin, concurrency, type checker</project.tags>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

--
http://erikengbrecht.blogspot.com/

If you are providing tags within the Project definition then please do
it with a scala syntax and not a huge xml artifact. I find it highly
unreadable and obstructing the code when using xml even though Scala
has excellent support for xml.
I don't mind a xmlTo and fromXml for easier match up with xml but if
we are inventing someting new lets stick with classes, objects and
traits for defining it and provide a nice and easy scalaresque DSL for
accessing it.

Just my 2cts.

- Stefan

2010/4/24 Maxime Lévesque :
>
>  How about a method like this in SBT :
>
>   def projectSearchableAndPresentableInfo =
>    
>      
>      
>          Short description here....
>      
>      
>          h1. textile or Markdown markup in here....
>      
>    
>
>  This would end up in the POM. All project from a maven repo could be
> extracted to generate a searchable *and* presentable catalogue like site.
> Now I don't know how maven behaves if you put non maven tags in a POM. In
> case it doesn't like it,
> I would just cram the whole structure in JSON in the project description
> tag... Yes it would be very ugly and non human readable,
> but I already avoid reading and writing POMs anyways, I leave it to SBT.
>
>  Max
>
> On Fri, Apr 23, 2010 at 7:03 PM, Kevin Wright
> wrote:
>>
>>
>> On 23 April 2010 21:11, David Flemström wrote:
>>>
>>> On Fri, Apr 23, 2010 at 12:12 PM, Kevin
>>> Wright  wrote:
>>>>
>>>> But you'd have to bribe me quite heavily before I'd accept it as
>>>> "cleaner", I just see a lot of boilerplate and accidental complexity.  If
>>>> we're going so far as to isolate this stuff in an entire dedicated
>>>> namespace, then we may as well just use a separate file with one tag per
>>>> line - can't get much cleaner than that!
>>>
>>> When I say 'clean', I usually refer to something that lacks complexity
>>> (and not only from the user's perspective).
>>> For example, let's say that a special property was introduced called
>>> "project.tags" and that contained a comma-separated tag cloud as some have
>>> been suggesting. This might at first seem like a 'clean' solution as seen
>>> from the POM writer's perspective, but there are a heap of problems coming
>>> along as well. Let's say that someone wants to have a tag that includes a
>>> comma. Or let's say that a need for "main tags", "category tags" and "cloud
>>> tags" arises. Continuing along the same line of clean thinking, we might end
>>> up with something like:
>>>
>>> [sbt plugin],[compiler
>>> plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type
>>> checker,dev
>>>
>>> (I took this horrid syntax as an example because I've seen something very
>>> similar in a tag-based CSS-like selector system I've been unfortunate enough
>>> to work with recently. They also started out with a "clean" system)
>>> Yes, this seemingly simple system works, but it:
>>>
>>> introduces a completely new syntax that has to be learned both by
>>> developers and parsers
>>> doesn't scale well
>>> is very implementation dependent (Can the syntax be understood by other
>>> tag consumers? Is there an easy way to standardize it?)
>>>
>>> I understand that you already realize most of this, but I just wanted to
>>> be explicit.
>>> BTW, for comparison:
>>>
>>>
>>> sbt plugin
>>> compiler plugin
>>> compiler plugin
>>> development
>>> type checker
>>> dev
>>>
>>>
>>> If this is too verbose for you, get a tool that writes your POMs for you
>>> (e.g. NetBeans).
>>
>> There is a middle ground...
>> I was only ever considering a single class of tags, intended for indexing,
>> searching and human readability
>> In this context, I'd expect the above example to be something like:
>>
>> sbt plugin, compiler plugin, concurrency, type
>> checker
>>
>> Not entirely sure what the intent is behind the category, alias and dev
>> references in your example.  But it's still possible to be a bit richer with
>> a pure property solution and not get too convoluted:
>>
>> development
>>
>> sbt plugin, compiler plugin, concurrency, type
>> checker
>>
>>
>>
>>
>> --
>> Kevin Wright
>>
>> mail/google talk: kev.lee.wright@googlemail.com
>> wave: kev.lee.wright@googlewave.com
>> skype: kev.lee.wright
>> twitter: @thecoda
>>
>
>

I'd like to strongly disagree. If these project tags are to be used for anything other than pure scala, then it is very important that they be represented as xml in the pom. There's nothing like finding micro-syntax in an xml file to completely turn people off. Maven3 allows project config files to be represented in the language of your choice. You can have your nice pure scala syntax using maven3's polyglot capabilities. For eveyone using the legacy xml format, they will be expecting everything to be xml.

Matthew

On 26 April 2010 12:43, Stefan Langer <mailtolanger@googlemail.com> wrote:

If you are providing tags within the Project definition then please do
it with a scala syntax and not a huge xml artifact. I find it highly
unreadable and obstructing the code when using xml even though Scala
has excellent support for xml.
I don't mind a xmlTo and fromXml for easier match up with xml but if
we are inventing someting new lets stick with classes, objects and
traits for defining it and provide a nice and easy scalaresque DSL for
accessing it.

Just my 2cts.

- Stefan

2010/4/24 Maxime Lévesque <maxime.levesque@gmail.com>:
>
>  How about a method like this in SBT :
>
>   def projectSearchableAndPresentableInfo =
>     <ProjectInfo name='Etc...'>
>       <KeyWords="sbt, compiler, plugin"/>
>       <OneParagraphDescription>
>          Short description here....
>       </OneParagraphDescription>
>       <MainPage>
>          h1. textile or Markdown markup in here....
>       </MainPage>
>     </ProjectInfo>
>
>  This would end up in the POM. All project from a maven repo could be
> extracted to generate a searchable *and* presentable catalogue like site.
> Now I don't know how maven behaves if you put non maven tags in a POM. In
> case it doesn't like it,
> I would just cram the whole structure in JSON in the project description
> tag... Yes it would be very ugly and non human readable,
> but I already avoid reading and writing POMs anyways, I leave it to SBT.
>
>  Max
>
> On Fri, Apr 23, 2010 at 7:03 PM, Kevin Wright
> <kev.lee.wright@googlemail.com> wrote:
>>
>>
>> On 23 April 2010 21:11, David Flemström <david.flemstrom@gmail.com> wrote:
>>>
>>> On Fri, Apr 23, 2010 at 12:12 PM, Kevin
>>> Wright <kev.lee.wright@googlemail.com> wrote:
>>>>
>>>> But you'd have to bribe me quite heavily before I'd accept it as
>>>> "cleaner", I just see a lot of boilerplate and accidental complexity.  If
>>>> we're going so far as to isolate this stuff in an entire dedicated
>>>> namespace, then we may as well just use a separate file with one tag per
>>>> line - can't get much cleaner than that!
>>>
>>> When I say 'clean', I usually refer to something that lacks complexity
>>> (and not only from the user's perspective).
>>> For example, let's say that a special property was introduced called
>>> "project.tags" and that contained a comma-separated tag cloud as some have
>>> been suggesting. This might at first seem like a 'clean' solution as seen
>>> from the POM writer's perspective, but there are a heap of problems coming
>>> along as well. Let's say that someone wants to have a tag that includes a
>>> comma. Or let's say that a need for "main tags", "category tags" and "cloud
>>> tags" arises. Continuing along the same line of clean thinking, we might end
>>> up with something like:
>>>
>>> <project.tags>[sbt plugin],[compiler
>>> plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type
>>> checker,dev</project.tags>
>>>
>>> (I took this horrid syntax as an example because I've seen something very
>>> similar in a tag-based CSS-like selector system I've been unfortunate enough
>>> to work with recently. They also started out with a "clean" system)
>>> Yes, this seemingly simple system works, but it:
>>>
>>> introduces a completely new syntax that has to be learned both by
>>> developers and parsers
>>> doesn't scale well
>>> is very implementation dependent (Can the syntax be understood by other
>>> tag consumers? Is there an easy way to standardize it?)
>>>
>>> I understand that you already realize most of this, but I just wanted to
>>> be explicit.
>>> BTW, for comparison:
>>>
>>> <s:tags>
>>>     <s:tag type="main">sbt plugin</s:tag>
>>>     <s:tag type="main">compiler plugin</s:tag>
>>>     <s:tag type="main" alias="compiler-plugin">compiler plugin</s:tag>
>>>     <s:tag type="category">development</s:tag>
>>>     <s:tag>type checker</s:tag>
>>>     <s:tag>dev</s:tag>
>>> </s:tags>
>>>
>>> If this is too verbose for you, get a tool that writes your POMs for you
>>> (e.g. NetBeans).
>>
>> There is a middle ground...
>> I was only ever considering a single class of tags, intended for indexing,
>> searching and human readability
>> In this context, I'd expect the above example to be something like:
>>
>> <project.tags>sbt plugin, compiler plugin, concurrency, type
>> checker</project.tags>
>>
>> Not entirely sure what the intent is behind the category, alias and dev
>> references in your example.  But it's still possible to be a bit richer with
>> a pure property solution and not get too convoluted:
>>
>> <project.category>development</project.category>
>>
>> <project.tags>sbt plugin, compiler plugin, concurrency, type
>> checker</project.tags>
>>
>>
>>
>>
>> --
>> Kevin Wright
>>
>> mail/google talk: kev.lee.wright@googlemail.com
>> wave: kev.lee.wright@googlewave.com
>> skype: kev.lee.wright
>> twitter: @thecoda
>>
>
>

On Mon, Apr 26, 2010 at 2:03 PM, Matthew Pocock <turingatemyhamster@googlemail.com> wrote:

I'd like to strongly disagree. If these project tags are to be used for anything other than pure scala, then it is very important that they be represented as xml in the pom. There's nothing like finding micro-syntax in an xml file to completely turn people off. Maven3 allows project config files to be represented in the language of your choice. You can have your nice pure scala syntax using maven3's polyglot capabilities. For eveyone using the legacy xml format, they will be expecting everything to be xml.

Let me weigh in because I'm the guy that owns the Scala tools machine and will be one of the guys that deploys whatever script/code creates the index.

XML is the best format.  Anything that requires running code (e.g., Scala code) on that machine isn't going to happen... there's just too much of a security risk.
 

Matthew

On 26 April 2010 12:43, Stefan Langer <mailtolanger@googlemail.com> wrote:

If you are providing tags within the Project definition then please do
it with a scala syntax and not a huge xml artifact. I find it highly
unreadable and obstructing the code when using xml even though Scala
has excellent support for xml.
I don't mind a xmlTo and fromXml for easier match up with xml but if
we are inventing someting new lets stick with classes, objects and
traits for defining it and provide a nice and easy scalaresque DSL for
accessing it.

Just my 2cts.

- Stefan

2010/4/24 Maxime Lévesque <maxime.levesque@gmail.com>:
>
>  How about a method like this in SBT :
>
>   def projectSearchableAndPresentableInfo =
>     <ProjectInfo name='Etc...'>
>       <KeyWords="sbt, compiler, plugin"/>
>       <OneParagraphDescription>
>          Short description here....
>       </OneParagraphDescription>
>       <MainPage>
>          h1. textile or Markdown markup in here....
>       </MainPage>
>     </ProjectInfo>
>
>  This would end up in the POM. All project from a maven repo could be
> extracted to generate a searchable *and* presentable catalogue like site.
> Now I don't know how maven behaves if you put non maven tags in a POM. In
> case it doesn't like it,
> I would just cram the whole structure in JSON in the project description
> tag... Yes it would be very ugly and non human readable,
> but I already avoid reading and writing POMs anyways, I leave it to SBT.
>
>  Max
>
> On Fri, Apr 23, 2010 at 7:03 PM, Kevin Wright
> <kev.lee.wright@googlemail.com> wrote:
>>
>>
>> On 23 April 2010 21:11, David Flemström <david.flemstrom@gmail.com> wrote:
>>>
>>> On Fri, Apr 23, 2010 at 12:12 PM, Kevin
>>> Wright <kev.lee.wright@googlemail.com> wrote:
>>>>
>>>> But you'd have to bribe me quite heavily before I'd accept it as
>>>> "cleaner", I just see a lot of boilerplate and accidental complexity.  If
>>>> we're going so far as to isolate this stuff in an entire dedicated
>>>> namespace, then we may as well just use a separate file with one tag per
>>>> line - can't get much cleaner than that!
>>>
>>> When I say 'clean', I usually refer to something that lacks complexity
>>> (and not only from the user's perspective).
>>> For example, let's say that a special property was introduced called
>>> "project.tags" and that contained a comma-separated tag cloud as some have
>>> been suggesting. This might at first seem like a 'clean' solution as seen
>>> from the POM writer's perspective, but there are a heap of problems coming
>>> along as well. Let's say that someone wants to have a tag that includes a
>>> comma. Or let's say that a need for "main tags", "category tags" and "cloud
>>> tags" arises. Continuing along the same line of clean thinking, we might end
>>> up with something like:
>>>
>>> <project.tags>[sbt plugin],[compiler
>>> plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type
>>> checker,dev</project.tags>
>>>
>>> (I took this horrid syntax as an example because I've seen something very
>>> similar in a tag-based CSS-like selector system I've been unfortunate enough
>>> to work with recently. They also started out with a "clean" system)
>>> Yes, this seemingly simple system works, but it:
>>>
>>> introduces a completely new syntax that has to be learned both by
>>> developers and parsers
>>> doesn't scale well
>>> is very implementation dependent (Can the syntax be understood by other
>>> tag consumers? Is there an easy way to standardize it?)
>>>
>>> I understand that you already realize most of this, but I just wanted to
>>> be explicit.
>>> BTW, for comparison:
>>>
>>> <s:tags>
>>>     <s:tag type="main">sbt plugin</s:tag>
>>>     <s:tag type="main">compiler plugin</s:tag>
>>>     <s:tag type="main" alias="compiler-plugin">compiler plugin</s:tag>
>>>     <s:tag type="category">development</s:tag>
>>>     <s:tag>type checker</s:tag>
>>>     <s:tag>dev</s:tag>
>>> </s:tags>
>>>
>>> If this is too verbose for you, get a tool that writes your POMs for you
>>> (e.g. NetBeans).
>>
>> There is a middle ground...
>> I was only ever considering a single class of tags, intended for indexing,
>> searching and human readability
>> In this context, I'd expect the above example to be something like:
>>
>> <project.tags>sbt plugin, compiler plugin, concurrency, type
>> checker</project.tags>
>>
>> Not entirely sure what the intent is behind the category, alias and dev
>> references in your example.  But it's still possible to be a bit richer with
>> a pure property solution and not get too convoluted:
>>
>> <project.category>development</project.category>
>>
>> <project.tags>sbt plugin, compiler plugin, concurrency, type
>> checker</project.tags>
>>
>>
>>
>>
>> --
>> Kevin Wright
>>
>> mail/google talk: kev.lee.wright@googlemail.com
>> wave: kev.lee.wright@googlewave.com
>> skype: kev.lee.wright
>> twitter: @thecoda
>>
>
>

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

Surely this is an argument AGAINST xml tags
If any of the other languages expect a property to be nothing but a string (maybe with a bit of variable expansion) then how will they cope when you attempt to put unexpected structure into a property?
The same argument goes for xml namespaces, where will they be supported outside of an xml pom, or sbt?
Even worse, I can see the pom being written in i.e. groovy, and then the tags being escaped on writing to the pom, this is *not* a Good Thing™
Considering alternate formats for authoring a POM, I'm now more convinced than ever; anything that steps outside of the schema or that introduces parallel schema is just going to cause a wealth of headaches and should be avoided.
On 26 April 2010 22:03, Matthew Pocock <turingatemyhamster@googlemail.com> wrote:

I'd like to strongly disagree. If these project tags are to be used for anything other than pure scala, then it is very important that they be represented as xml in the pom. There's nothing like finding micro-syntax in an xml file to completely turn people off. Maven3 allows project config files to be represented in the language of your choice. You can have your nice pure scala syntax using maven3's polyglot capabilities. For eveyone using the legacy xml format, they will be expecting everything to be xml.

Matthew

On 26 April 2010 12:43, Stefan Langer <mailtolanger@googlemail.com> wrote:

If you are providing tags within the Project definition then please do
it with a scala syntax and not a huge xml artifact. I find it highly
unreadable and obstructing the code when using xml even though Scala
has excellent support for xml.
I don't mind a xmlTo and fromXml for easier match up with xml but if
we are inventing someting new lets stick with classes, objects and
traits for defining it and provide a nice and easy scalaresque DSL for
accessing it.

Just my 2cts.

- Stefan

2010/4/24 Maxime Lévesque <maxime.levesque@gmail.com>:
>
>  How about a method like this in SBT :
>
>   def projectSearchableAndPresentableInfo =
>     <ProjectInfo name='Etc...'>
>       <KeyWords="sbt, compiler, plugin"/>
>       <OneParagraphDescription>
>          Short description here....
>       </OneParagraphDescription>
>       <MainPage>
>          h1. textile or Markdown markup in here....
>       </MainPage>
>     </ProjectInfo>
>
>  This would end up in the POM. All project from a maven repo could be
> extracted to generate a searchable *and* presentable catalogue like site.
> Now I don't know how maven behaves if you put non maven tags in a POM. In
> case it doesn't like it,
> I would just cram the whole structure in JSON in the project description
> tag... Yes it would be very ugly and non human readable,
> but I already avoid reading and writing POMs anyways, I leave it to SBT.
>
>  Max
>
> On Fri, Apr 23, 2010 at 7:03 PM, Kevin Wright
> <kev.lee.wright@googlemail.com> wrote:
>>
>>
>> On 23 April 2010 21:11, David Flemström <david.flemstrom@gmail.com> wrote:
>>>
>>> On Fri, Apr 23, 2010 at 12:12 PM, Kevin
>>> Wright <kev.lee.wright@googlemail.com> wrote:
>>>>
>>>> But you'd have to bribe me quite heavily before I'd accept it as
>>>> "cleaner", I just see a lot of boilerplate and accidental complexity.  If
>>>> we're going so far as to isolate this stuff in an entire dedicated
>>>> namespace, then we may as well just use a separate file with one tag per
>>>> line - can't get much cleaner than that!
>>>
>>> When I say 'clean', I usually refer to something that lacks complexity
>>> (and not only from the user's perspective).
>>> For example, let's say that a special property was introduced called
>>> "project.tags" and that contained a comma-separated tag cloud as some have
>>> been suggesting. This might at first seem like a 'clean' solution as seen
>>> from the POM writer's perspective, but there are a heap of problems coming
>>> along as well. Let's say that someone wants to have a tag that includes a
>>> comma. Or let's say that a need for "main tags", "category tags" and "cloud
>>> tags" arises. Continuing along the same line of clean thinking, we might end
>>> up with something like:
>>>
>>> <project.tags>[sbt plugin],[compiler
>>> plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type
>>> checker,dev</project.tags>
>>>
>>> (I took this horrid syntax as an example because I've seen something very
>>> similar in a tag-based CSS-like selector system I've been unfortunate enough
>>> to work with recently. They also started out with a "clean" system)
>>> Yes, this seemingly simple system works, but it:
>>>
>>> introduces a completely new syntax that has to be learned both by
>>> developers and parsers
>>> doesn't scale well
>>> is very implementation dependent (Can the syntax be understood by other
>>> tag consumers? Is there an easy way to standardize it?)
>>>
>>> I understand that you already realize most of this, but I just wanted to
>>> be explicit.
>>> BTW, for comparison:
>>>
>>> <s:tags>
>>>     <s:tag type="main">sbt plugin</s:tag>
>>>     <s:tag type="main">compiler plugin</s:tag>
>>>     <s:tag type="main" alias="compiler-plugin">compiler plugin</s:tag>
>>>     <s:tag type="category">development</s:tag>
>>>     <s:tag>type checker</s:tag>
>>>     <s:tag>dev</s:tag>
>>> </s:tags>
>>>
>>> If this is too verbose for you, get a tool that writes your POMs for you
>>> (e.g. NetBeans).
>>
>> There is a middle ground...
>> I was only ever considering a single class of tags, intended for indexing,
>> searching and human readability
>> In this context, I'd expect the above example to be something like:
>>
>> <project.tags>sbt plugin, compiler plugin, concurrency, type
>> checker</project.tags>
>>
>> Not entirely sure what the intent is behind the category, alias and dev
>> references in your example.  But it's still possible to be a bit richer with
>> a pure property solution and not get too convoluted:
>>
>> <project.category>development</project.category>
>>
>> <project.tags>sbt plugin, compiler plugin, concurrency, type
>> checker</project.tags>
>>
>>
>>
>>
>> --
>> Kevin Wright
>>
>> mail/google talk: kev.lee.wright@googlemail.com
>> wave: kev.lee.wright@googlewave.com
>> skype: kev.lee.wright
>> twitter: @thecoda
>>
>
>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

On 26 April 2010 22:10, David Pollak wrote:
> On Mon, Apr 26, 2010 at 2:03 PM, Matthew Pocock
> wrote:
>>
>> I'd like to strongly disagree. If these project tags are to be used for
>> anything other than pure scala, then it is very important that they be
>> represented as xml in the pom. There's nothing like finding micro-syntax in
>> an xml file to completely turn people off. Maven3 allows project config
>> files to be represented in the language of your choice. You can have your
>> nice pure scala syntax using maven3's polyglot capabilities. For eveyone
>> using the legacy xml format, they will be expecting everything to be xml.
>
> Let me weigh in because I'm the guy that owns the Scala tools machine and
> will be one of the guys that deploys whatever script/code creates the index.
>
> XML is the best format.  Anything that requires running code (e.g., Scala
> code) on that machine isn't going to happen... there's just too much of a
> security risk.

The pom.xml is definitely the most suitable output format to be
deployed in maven repos. How folks create the pom.xml is totally up to
them and doesn't really matter (maven/sbt/ant/ivy/custom
DSL/whatever).

For now using maven properties seems the best approach - I had a quick
tweet-chat with Jason a little while ago
http://twitter.com/jvanzyl/status/12575071429

so it looks likely that Maven will probably support (maybe in 3.1)
tags in the XSD; so there will eventually be a proper XML schema in
the maven XSD for tags (which with polyglot maven can be created using
any language/DSL but has a consistent XML output format for easy
interchange). So in the interim using a canonical maven property makes
the most sense as a tactical solution - which hopefully Maven can
detect and use to populate the real Maven project model when it
supports tags.

Using the "project.tags" maven property to tag a project seems to make
the most sense right now. We could introduce different maven
properties for different kinds of tags other than the "project" if we
need categories of tags (though I struggle to understand what those
categories might be yet - but "FOO.tags" or whatever could be used for
tags which don't apply to the project as a whole but apply to FOO
(whatever FOO might be).

So the remaining decision seems to be, do we use a String with commas
for the value of project.tags which seems to fit how most maven
properties work so far and works well with existing maven plugins - or
try shove elements in there (I've no idea if that works or
barfs). Since this is only a temporary work around until Maven 3.x
supports XML syntax anyway, I'd be tempted to go for the simplest
risk-free tactical solution which we know works - using a String for
the value of the property - which is then super easy to use within the
build process and works with existing plugins etc. Folks really
wanting to use XML to describe their tags can do so at their build
level (e.g. in sbt or some other plugin) which can then generate the
tactical property string and the new Maven XML tags when they are
available.

Jsut to make my argument more clear I'm not saying that the published
artifact should not be xml . I'm just saying that it should not be in
the sbt Project.scala file which is scala code. It should be
encapsulated in a object structrue which is type safe and easily
accessible through the Project file. When sbt creates the pom.xml it
will turn this internal representation into the expected xml
structure.

2010/4/26 David Pollak :
>
>
> On Mon, Apr 26, 2010 at 2:03 PM, Matthew Pocock
> wrote:
>>
>> I'd like to strongly disagree. If these project tags are to be used for
>> anything other than pure scala, then it is very important that they be
>> represented as xml in the pom. There's nothing like finding micro-syntax in
>> an xml file to completely turn people off. Maven3 allows project config
>> files to be represented in the language of your choice. You can have your
>> nice pure scala syntax using maven3's polyglot capabilities. For eveyone
>> using the legacy xml format, they will be expecting everything to be xml.
>
> Let me weigh in because I'm the guy that owns the Scala tools machine and
> will be one of the guys that deploys whatever script/code creates the index.
>
> XML is the best format.  Anything that requires running code (e.g., Scala
> code) on that machine isn't going to happen... there's just too much of a
> security risk.
>
>>
>> Matthew
>>
>> On 26 April 2010 12:43, Stefan Langer wrote:
>>>
>>> If you are providing tags within the Project definition then please do
>>> it with a scala syntax and not a huge xml artifact. I find it highly
>>> unreadable and obstructing the code when using xml even though Scala
>>> has excellent support for xml.
>>> I don't mind a xmlTo and fromXml for easier match up with xml but if
>>> we are inventing someting new lets stick with classes, objects and
>>> traits for defining it and provide a nice and easy scalaresque DSL for
>>> accessing it.
>>>
>>> Just my 2cts.
>>>
>>> - Stefan
>>>
>>> 2010/4/24 Maxime Lévesque :
>>> >
>>> >  How about a method like this in SBT :
>>> >
>>> >   def projectSearchableAndPresentableInfo =
>>> >    
>>> >      
>>> >      
>>> >          Short description here....
>>> >      
>>> >      
>>> >          h1. textile or Markdown markup in here....
>>> >      
>>> >    
>>> >
>>> >  This would end up in the POM. All project from a maven repo could be
>>> > extracted to generate a searchable *and* presentable catalogue like
>>> > site.
>>> > Now I don't know how maven behaves if you put non maven tags in a POM.
>>> > In
>>> > case it doesn't like it,
>>> > I would just cram the whole structure in JSON in the project
>>> > description
>>> > tag... Yes it would be very ugly and non human readable,
>>> > but I already avoid reading and writing POMs anyways, I leave it to
>>> > SBT.
>>> >
>>> >  Max
>>> >
>>> > On Fri, Apr 23, 2010 at 7:03 PM, Kevin Wright
>>> > wrote:
>>> >>
>>> >>
>>> >> On 23 April 2010 21:11, David Flemström
>>> >> wrote:
>>> >>>
>>> >>> On Fri, Apr 23, 2010 at 12:12 PM, Kevin
>>> >>> Wright  wrote:
>>> >>>>
>>> >>>> But you'd have to bribe me quite heavily before I'd accept it as
>>> >>>> "cleaner", I just see a lot of boilerplate and accidental
>>> >>>> complexity.  If
>>> >>>> we're going so far as to isolate this stuff in an entire dedicated
>>> >>>> namespace, then we may as well just use a separate file with one tag
>>> >>>> per
>>> >>>> line - can't get much cleaner than that!
>>> >>>
>>> >>> When I say 'clean', I usually refer to something that lacks
>>> >>> complexity
>>> >>> (and not only from the user's perspective).
>>> >>> For example, let's say that a special property was introduced called
>>> >>> "project.tags" and that contained a comma-separated tag cloud as some
>>> >>> have
>>> >>> been suggesting. This might at first seem like a 'clean' solution as
>>> >>> seen
>>> >>> from the POM writer's perspective, but there are a heap of problems
>>> >>> coming
>>> >>> along as well. Let's say that someone wants to have a tag that
>>> >>> includes a
>>> >>> comma. Or let's say that a need for "main tags", "category tags" and
>>> >>> "cloud
>>> >>> tags" arises. Continuing along the same line of clean thinking, we
>>> >>> might end
>>> >>> up with something like:
>>> >>>
>>> >>> [sbt plugin],[compiler
>>> >>>
>>> >>> plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type
>>> >>> checker,dev
>>> >>>
>>> >>> (I took this horrid syntax as an example because I've seen something
>>> >>> very
>>> >>> similar in a tag-based CSS-like selector system I've been unfortunate
>>> >>> enough
>>> >>> to work with recently. They also started out with a "clean" system)
>>> >>> Yes, this seemingly simple system works, but it:
>>> >>>
>>> >>> introduces a completely new syntax that has to be learned both by
>>> >>> developers and parsers
>>> >>> doesn't scale well
>>> >>> is very implementation dependent (Can the syntax be understood by
>>> >>> other
>>> >>> tag consumers? Is there an easy way to standardize it?)
>>> >>>
>>> >>> I understand that you already realize most of this, but I just wanted
>>> >>> to
>>> >>> be explicit.
>>> >>> BTW, for comparison:
>>> >>>
>>> >>>
>>> >>>     sbt plugin
>>> >>>     compiler plugin
>>> >>>     compiler
>>> >>> plugin
>>> >>>     development
>>> >>>     type checker
>>> >>>     dev
>>> >>>
>>> >>>
>>> >>> If this is too verbose for you, get a tool that writes your POMs for
>>> >>> you
>>> >>> (e.g. NetBeans).
>>> >>
>>> >> There is a middle ground...
>>> >> I was only ever considering a single class of tags, intended for
>>> >> indexing,
>>> >> searching and human readability
>>> >> In this context, I'd expect the above example to be something like:
>>> >>
>>> >> sbt plugin, compiler plugin, concurrency, type
>>> >> checker
>>> >>
>>> >> Not entirely sure what the intent is behind the category, alias and
>>> >> dev
>>> >> references in your example.  But it's still possible to be a bit
>>> >> richer with
>>> >> a pure property solution and not get too convoluted:
>>> >>
>>> >> development
>>> >>
>>> >> sbt plugin, compiler plugin, concurrency, type
>>> >> checker
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Kevin Wright
>>> >>
>>> >> mail/google talk: kev.lee.wright@googlemail.com
>>> >> wave: kev.lee.wright@googlewave.com
>>> >> skype: kev.lee.wright
>>> >> twitter: @thecoda
>>> >>
>>> >
>>> >
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>

Three places where this could fail:
1. Report generation that lists properties defined in a POM.  I imagine that such a tool would perform variable substitution then dump the string into the generated HTML, where the xml tags would be unrecognised and thus suppressed  (or worse still, fail on some form of schema validation).
2. I'm not yet converted to sbt, so I hand-craft my pom at first, then later convert to yaml after getting annoyed with the boilerplate.  yaml-xml synchronisation is maintained by a maven plugin and it considers all properties to be raw strings.  What if ALL raw strings are xml-escaped as part of the conversion?  my pom would now contain &gt; and &lt; where I actually expected proper xml tags.
3. Same as 2, but this time I'm using the POM editor built into eclipse.

I *do* understand the logic behind keeping everything in XML, truly I do... but I also believe that:
- There's not a single tool we'll be using that can't easily deal with a comma-delimited string
- There are too many third-party tools out there, none of which are under our control, and many of which will choke on nested tags inside a property or a separate namespace inside the pom.



On 27 April 2010 11:45, Stefan Langer <mailtolanger@googlemail.com> wrote:

Jsut to make my argument more clear I'm not saying that the published
artifact should not be xml . I'm just saying that it should not be in
the sbt Project.scala file which is scala code. It should be
encapsulated in a object structrue which is type safe and easily
accessible through the Project file. When sbt creates the pom.xml it
will turn this internal representation into the expected xml
structure.

2010/4/26 David Pollak <feeder.of.the.bears@gmail.com>:
>
>
> On Mon, Apr 26, 2010 at 2:03 PM, Matthew Pocock
> <turingatemyhamster@googlemail.com> wrote:
>>
>> I'd like to strongly disagree. If these project tags are to be used for
>> anything other than pure scala, then it is very important that they be
>> represented as xml in the pom. There's nothing like finding micro-syntax in
>> an xml file to completely turn people off. Maven3 allows project config
>> files to be represented in the language of your choice. You can have your
>> nice pure scala syntax using maven3's polyglot capabilities. For eveyone
>> using the legacy xml format, they will be expecting everything to be xml.
>
> Let me weigh in because I'm the guy that owns the Scala tools machine and
> will be one of the guys that deploys whatever script/code creates the index.
>
> XML is the best format.  Anything that requires running code (e.g., Scala
> code) on that machine isn't going to happen... there's just too much of a
> security risk.
>
>>
>> Matthew
>>
>> On 26 April 2010 12:43, Stefan Langer <mailtolanger@googlemail.com> wrote:
>>>
>>> If you are providing tags within the Project definition then please do
>>> it with a scala syntax and not a huge xml artifact. I find it highly
>>> unreadable and obstructing the code when using xml even though Scala
>>> has excellent support for xml.
>>> I don't mind a xmlTo and fromXml for easier match up with xml but if
>>> we are inventing someting new lets stick with classes, objects and
>>> traits for defining it and provide a nice and easy scalaresque DSL for
>>> accessing it.
>>>
>>> Just my 2cts.
>>>
>>> - Stefan
>>>
>>> 2010/4/24 Maxime Lévesque <maxime.levesque@gmail.com>:
>>> >
>>> >  How about a method like this in SBT :
>>> >
>>> >   def projectSearchableAndPresentableInfo =
>>> >     <ProjectInfo name='Etc...'>
>>> >       <KeyWords="sbt, compiler, plugin"/>
>>> >       <OneParagraphDescription>
>>> >          Short description here....
>>> >       </OneParagraphDescription>
>>> >       <MainPage>
>>> >          h1. textile or Markdown markup in here....
>>> >       </MainPage>
>>> >     </ProjectInfo>
>>> >
>>> >  This would end up in the POM. All project from a maven repo could be
>>> > extracted to generate a searchable *and* presentable catalogue like
>>> > site.
>>> > Now I don't know how maven behaves if you put non maven tags in a POM.
>>> > In
>>> > case it doesn't like it,
>>> > I would just cram the whole structure in JSON in the project
>>> > description
>>> > tag... Yes it would be very ugly and non human readable,
>>> > but I already avoid reading and writing POMs anyways, I leave it to
>>> > SBT.
>>> >
>>> >  Max
>>> >
>>> > On Fri, Apr 23, 2010 at 7:03 PM, Kevin Wright
>>> > <kev.lee.wright@googlemail.com> wrote:
>>> >>
>>> >>
>>> >> On 23 April 2010 21:11, David Flemström <david.flemstrom@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> On Fri, Apr 23, 2010 at 12:12 PM, Kevin
>>> >>> Wright <kev.lee.wright@googlemail.com> wrote:
>>> >>>>
>>> >>>> But you'd have to bribe me quite heavily before I'd accept it as
>>> >>>> "cleaner", I just see a lot of boilerplate and accidental
>>> >>>> complexity.  If
>>> >>>> we're going so far as to isolate this stuff in an entire dedicated
>>> >>>> namespace, then we may as well just use a separate file with one tag
>>> >>>> per
>>> >>>> line - can't get much cleaner than that!
>>> >>>
>>> >>> When I say 'clean', I usually refer to something that lacks
>>> >>> complexity
>>> >>> (and not only from the user's perspective).
>>> >>> For example, let's say that a special property was introduced called
>>> >>> "project.tags" and that contained a comma-separated tag cloud as some
>>> >>> have
>>> >>> been suggesting. This might at first seem like a 'clean' solution as
>>> >>> seen
>>> >>> from the POM writer's perspective, but there are a heap of problems
>>> >>> coming
>>> >>> along as well. Let's say that someone wants to have a tag that
>>> >>> includes a
>>> >>> comma. Or let's say that a need for "main tags", "category tags" and
>>> >>> "cloud
>>> >>> tags" arises. Continuing along the same line of clean thinking, we
>>> >>> might end
>>> >>> up with something like:
>>> >>>
>>> >>> <project.tags>[sbt plugin],[compiler
>>> >>>
>>> >>> plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type
>>> >>> checker,dev</project.tags>
>>> >>>
>>> >>> (I took this horrid syntax as an example because I've seen something
>>> >>> very
>>> >>> similar in a tag-based CSS-like selector system I've been unfortunate
>>> >>> enough
>>> >>> to work with recently. They also started out with a "clean" system)
>>> >>> Yes, this seemingly simple system works, but it:
>>> >>>
>>> >>> introduces a completely new syntax that has to be learned both by
>>> >>> developers and parsers
>>> >>> doesn't scale well
>>> >>> is very implementation dependent (Can the syntax be understood by
>>> >>> other
>>> >>> tag consumers? Is there an easy way to standardize it?)
>>> >>>
>>> >>> I understand that you already realize most of this, but I just wanted
>>> >>> to
>>> >>> be explicit.
>>> >>> BTW, for comparison:
>>> >>>
>>> >>> <s:tags>
>>> >>>     <s:tag type="main">sbt plugin</s:tag>
>>> >>>     <s:tag type="main">compiler plugin</s:tag>
>>> >>>     <s:tag type="main" alias="compiler-plugin">compiler
>>> >>> plugin</s:tag>
>>> >>>     <s:tag type="category">development</s:tag>
>>> >>>     <s:tag>type checker</s:tag>
>>> >>>     <s:tag>dev</s:tag>
>>> >>> </s:tags>
>>> >>>
>>> >>> If this is too verbose for you, get a tool that writes your POMs for
>>> >>> you
>>> >>> (e.g. NetBeans).
>>> >>
>>> >> There is a middle ground...
>>> >> I was only ever considering a single class of tags, intended for
>>> >> indexing,
>>> >> searching and human readability
>>> >> In this context, I'd expect the above example to be something like:
>>> >>
>>> >> <project.tags>sbt plugin, compiler plugin, concurrency, type
>>> >> checker</project.tags>
>>> >>
>>> >> Not entirely sure what the intent is behind the category, alias and
>>> >> dev
>>> >> references in your example.  But it's still possible to be a bit
>>> >> richer with
>>> >> a pure property solution and not get too convoluted:
>>> >>
>>> >> <project.category>development</project.category>
>>> >>
>>> >> <project.tags>sbt plugin, compiler plugin, concurrency, type
>>> >> checker</project.tags>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Kevin Wright
>>> >>
>>> >> mail/google talk: kev.lee.wright@googlemail.com
>>> >> wave: kev.lee.wright@googlewave.com
>>> >> skype: kev.lee.wright
>>> >> twitter: @thecoda
>>> >>
>>> >
>>> >
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

The whole point of a "Standard" is so that all the thrid-party tools either conform to the standard for some various piece of functionality to work, are they dont' conform at all and people don't use them for that reason.   Look at WAR file formats - A standard that all java-related build tools will create...  Think of it the same way.  We're making a standard for scala-tools.org pom files (which are already in the maven standard format which tools make use of) for those who wish to deploy artifacts to scala-tools.org.   If you don't want to deploy, you can do whatever you want.

I'm going to offer another alternative (one that can be accomplished with Maven/Ant/Ivy) and that is deploying a secondary XML file with a classifer of "scalatools-metainfo".   In the artifact directory you would then see something like:

/org/scala-lang/scala-library/2.7.7/
   scala-library-2.7.7.jar
   scala-library-2.7.7.pom
   scala-library-2.7.7-sources.jar
   scala-library-2.7.7-javadoc.jar
   scala-library-2.7.7-scalatools-metainfo.xml    <---****  This is easy to deploy with most maven repository deployment solutions


This will:
   * Let us use whatever format we want
   * Work with existing tool chains
   * Allow machine-slurpers to discover information about artifacts on scala-tools.org
   * Allow build tools to create DSLs or non-XML means to describe the content


The next question we need to answer is what is the format/content of this data?   After we agree on that standard, I think this is the easiest path to success... Rather than waiting for Maven 3.1.   When that happens, we could roll the data back into the pom, but for now I think separate solution is far better on all accounts.   It also makes it easy for users of the data to deal with "legacy" artifacts... they don't have a metadata xml file!


- Josh




On Tue, Apr 27, 2010 at 6:57 AM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

Three places where this could fail:
1. Report generation that lists properties defined in a POM.  I imagine that such a tool would perform variable substitution then dump the string into the generated HTML, where the xml tags would be unrecognised and thus suppressed  (or worse still, fail on some form of schema validation).
2. I'm not yet converted to sbt, so I hand-craft my pom at first, then later convert to yaml after getting annoyed with the boilerplate.  yaml-xml synchronisation is maintained by a maven plugin and it considers all properties to be raw strings.  What if ALL raw strings are xml-escaped as part of the conversion?  my pom would now contain &gt; and &lt; where I actually expected proper xml tags.
3. Same as 2, but this time I'm using the POM editor built into eclipse.

I *do* understand the logic behind keeping everything in XML, truly I do... but I also believe that:
- There's not a single tool we'll be using that can't easily deal with a comma-delimited string
- There are too many third-party tools out there, none of which are under our control, and many of which will choke on nested tags inside a property or a separate namespace inside the pom.



On 27 April 2010 11:45, Stefan Langer <mailtolanger@googlemail.com> wrote:

Jsut to make my argument more clear I'm not saying that the published
artifact should not be xml . I'm just saying that it should not be in
the sbt Project.scala file which is scala code. It should be
encapsulated in a object structrue which is type safe and easily
accessible through the Project file. When sbt creates the pom.xml it
will turn this internal representation into the expected xml
structure.

2010/4/26 David Pollak <feeder.of.the.bears@gmail.com>:
>
>
> On Mon, Apr 26, 2010 at 2:03 PM, Matthew Pocock
> <turingatemyhamster@googlemail.com> wrote:
>>
>> I'd like to strongly disagree. If these project tags are to be used for
>> anything other than pure scala, then it is very important that they be
>> represented as xml in the pom. There's nothing like finding micro-syntax in
>> an xml file to completely turn people off. Maven3 allows project config
>> files to be represented in the language of your choice. You can have your
>> nice pure scala syntax using maven3's polyglot capabilities. For eveyone
>> using the legacy xml format, they will be expecting everything to be xml.
>
> Let me weigh in because I'm the guy that owns the Scala tools machine and
> will be one of the guys that deploys whatever script/code creates the index.
>
> XML is the best format.  Anything that requires running code (e.g., Scala
> code) on that machine isn't going to happen... there's just too much of a
> security risk.
>
>>
>> Matthew
>>
>> On 26 April 2010 12:43, Stefan Langer <mailtolanger@googlemail.com> wrote:
>>>
>>> If you are providing tags within the Project definition then please do
>>> it with a scala syntax and not a huge xml artifact. I find it highly
>>> unreadable and obstructing the code when using xml even though Scala
>>> has excellent support for xml.
>>> I don't mind a xmlTo and fromXml for easier match up with xml but if
>>> we are inventing someting new lets stick with classes, objects and
>>> traits for defining it and provide a nice and easy scalaresque DSL for
>>> accessing it.
>>>
>>> Just my 2cts.
>>>
>>> - Stefan
>>>
>>> 2010/4/24 Maxime Lévesque <maxime.levesque@gmail.com>:
>>> >
>>> >  How about a method like this in SBT :
>>> >
>>> >   def projectSearchableAndPresentableInfo =
>>> >     <ProjectInfo name='Etc...'>
>>> >       <KeyWords="sbt, compiler, plugin"/>
>>> >       <OneParagraphDescription>
>>> >          Short description here....
>>> >       </OneParagraphDescription>
>>> >       <MainPage>
>>> >          h1. textile or Markdown markup in here....
>>> >       </MainPage>
>>> >     </ProjectInfo>
>>> >
>>> >  This would end up in the POM. All project from a maven repo could be
>>> > extracted to generate a searchable *and* presentable catalogue like
>>> > site.
>>> > Now I don't know how maven behaves if you put non maven tags in a POM.
>>> > In
>>> > case it doesn't like it,
>>> > I would just cram the whole structure in JSON in the project
>>> > description
>>> > tag... Yes it would be very ugly and non human readable,
>>> > but I already avoid reading and writing POMs anyways, I leave it to
>>> > SBT.
>>> >
>>> >  Max
>>> >
>>> > On Fri, Apr 23, 2010 at 7:03 PM, Kevin Wright
>>> > <kev.lee.wright@googlemail.com> wrote:
>>> >>
>>> >>
>>> >> On 23 April 2010 21:11, David Flemström <david.flemstrom@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> On Fri, Apr 23, 2010 at 12:12 PM, Kevin
>>> >>> Wright <kev.lee.wright@googlemail.com> wrote:
>>> >>>>
>>> >>>> But you'd have to bribe me quite heavily before I'd accept it as
>>> >>>> "cleaner", I just see a lot of boilerplate and accidental
>>> >>>> complexity.  If
>>> >>>> we're going so far as to isolate this stuff in an entire dedicated
>>> >>>> namespace, then we may as well just use a separate file with one tag
>>> >>>> per
>>> >>>> line - can't get much cleaner than that!
>>> >>>
>>> >>> When I say 'clean', I usually refer to something that lacks
>>> >>> complexity
>>> >>> (and not only from the user's perspective).
>>> >>> For example, let's say that a special property was introduced called
>>> >>> "project.tags" and that contained a comma-separated tag cloud as some
>>> >>> have
>>> >>> been suggesting. This might at first seem like a 'clean' solution as
>>> >>> seen
>>> >>> from the POM writer's perspective, but there are a heap of problems
>>> >>> coming
>>> >>> along as well. Let's say that someone wants to have a tag that
>>> >>> includes a
>>> >>> comma. Or let's say that a need for "main tags", "category tags" and
>>> >>> "cloud
>>> >>> tags" arises. Continuing along the same line of clean thinking, we
>>> >>> might end
>>> >>> up with something like:
>>> >>>
>>> >>> <project.tags>[sbt plugin],[compiler
>>> >>>
>>> >>> plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type
>>> >>> checker,dev</project.tags>
>>> >>>
>>> >>> (I took this horrid syntax as an example because I've seen something
>>> >>> very
>>> >>> similar in a tag-based CSS-like selector system I've been unfortunate
>>> >>> enough
>>> >>> to work with recently. They also started out with a "clean" system)
>>> >>> Yes, this seemingly simple system works, but it:
>>> >>>
>>> >>> introduces a completely new syntax that has to be learned both by
>>> >>> developers and parsers
>>> >>> doesn't scale well
>>> >>> is very implementation dependent (Can the syntax be understood by
>>> >>> other
>>> >>> tag consumers? Is there an easy way to standardize it?)
>>> >>>
>>> >>> I understand that you already realize most of this, but I just wanted
>>> >>> to
>>> >>> be explicit.
>>> >>> BTW, for comparison:
>>> >>>
>>> >>> <s:tags>
>>> >>>     <s:tag type="main">sbt plugin</s:tag>
>>> >>>     <s:tag type="main">compiler plugin</s:tag>
>>> >>>     <s:tag type="main" alias="compiler-plugin">compiler
>>> >>> plugin</s:tag>
>>> >>>     <s:tag type="category">development</s:tag>
>>> >>>     <s:tag>type checker</s:tag>
>>> >>>     <s:tag>dev</s:tag>
>>> >>> </s:tags>
>>> >>>
>>> >>> If this is too verbose for you, get a tool that writes your POMs for
>>> >>> you
>>> >>> (e.g. NetBeans).
>>> >>
>>> >> There is a middle ground...
>>> >> I was only ever considering a single class of tags, intended for
>>> >> indexing,
>>> >> searching and human readability
>>> >> In this context, I'd expect the above example to be something like:
>>> >>
>>> >> <project.tags>sbt plugin, compiler plugin, concurrency, type
>>> >> checker</project.tags>
>>> >>
>>> >> Not entirely sure what the intent is behind the category, alias and
>>> >> dev
>>> >> references in your example.  But it's still possible to be a bit
>>> >> richer with
>>> >> a pure property solution and not get too convoluted:
>>> >>
>>> >> <project.category>development</project.category>
>>> >>
>>> >> <project.tags>sbt plugin, compiler plugin, concurrency, type
>>> >> checker</project.tags>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Kevin Wright
>>> >>
>>> >> mail/google talk: kev.lee.wright@googlemail.com
>>> >> wave: kev.lee.wright@googlewave.com
>>> >> skype: kev.lee.wright
>>> >> twitter: @thecoda
>>> >>
>>> >
>>> >
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

On 27 April 2010 13:03, Josh Suereth wrote:
> The whole point of a "Standard" is so that all the thrid-party tools either
> conform to the standard for some various piece of functionality to work, are
> they dont' conform at all and people don't use them for that reason.   Look
> at WAR file formats - A standard that all java-related build tools will
> create...  Think of it the same way.  We're making a standard for
> scala-tools.org pom files (which are already in the maven standard format
> which tools make use of) for those who wish to deploy artifacts to
> scala-tools.org.   If you don't want to deploy, you can do whatever you
> want.
>
> I'm going to offer another alternative (one that can be accomplished with
> Maven/Ant/Ivy) and that is deploying a secondary XML file with a classifer
> of "scalatools-metainfo".   In the artifact directory you would then see
> something like:

As an aside - adding tags to a project in a maven repo seems to be a
very useful thing in general - its not really scala specific at all.
The more that folks add tags in maven pom's across the entire Java
ecosystem the more chance we have of nicer tag related tooling in
maven/ant/ivy/sbt/IDE and repository tools like Nexus et al.

So adding a scala-specific XML file rather than a standard property to
maven poms seems to be a step backwards from an ecosystem perspective.

Remember the main point of this exercise is to let users find
libraries more easily using tagged searches on web sites, command line
tools, IDEs or from repos - not necessarily to worrry about the ideal
XML format to represent a list of strings.

> /org/scala-lang/scala-library/2.7.7/
>    scala-library-2.7.7.jar
>    scala-library-2.7.7.pom
>    scala-library-2.7.7-sources.jar
>    scala-library-2.7.7-javadoc.jar
>    scala-library-2.7.7-scalatools-metainfo.xml    <---****  This is easy to
> deploy with most maven repository deployment solutions
>
>
> This will:
>    * Let us use whatever format we want
>    * Work with existing tool chains
>    * Allow machine-slurpers to discover information about artifacts on
> scala-tools.org
>    * Allow build tools to create DSLs or non-XML means to describe the
> content
>
>
> The next question we need to answer is what is the format/content of this
> data?   After we agree on that standard, I think this is the easiest path to
> success... Rather than waiting for Maven 3.1.

Noone's saying we have to wait for Maven 3.1. We can use maven
properties in the pom.xml yesterday with Maven 2.0.x onwards or with
any tool that creates a pom.xml file. Or write a couple of liner Scala
script to edit the generated pom.xml from your tool

> When that happens, we could
> roll the data back into the pom, but for now I think separate solution is
> far better on all accounts.

Why?

Adding a property to a pom.xml is typically much easier than adding a
new artifact to be deployed in a release. (e.g. in maven it requires
much more knowledge to know how to deploy an extra XML file). Plus
whenever the pom.xml structure natively supports the XML tagging
structure, this new artifact becomes deprecated anyway.

> It also makes it easy for users of the data to
> deal with "legacy" artifacts... they don't have a metadata xml file!

Being able to add tags to old releases is kinda nice; am not sure
though if hacking an old release in a maven repo breaks some
repo/syncing stuff does it? Releases are not meant to be edited.
Though I guess the tags could be a separate project but somehow
related to the original release using a naming convention; but this is
already sounding a little too complex.

Wouldn't just cutting a new release with the metadata included be
easier? With Scala we have to release often to keep pace with the
scala compiler anyway right? :)

I could go for that, I already have experience of cross-deploying .dmg, .deb, .rpm and .msi files alongside jars, so I know the approach works
On the other hand... unless using functionality that would be rolled into sbt, this'll also require a large chunk of extra xml in the pom, either via one of the existing plugins to support deploying extra  artefacts, or via a new plugin of our own.
The benefits are undoubtedly higher, but compared to a comma-delimited string the cost/benefit ratio is still very difficult to justify.



On 27 April 2010 13:03, Josh Suereth <joshua.suereth@gmail.com> wrote:

The whole point of a "Standard" is so that all the thrid-party tools either conform to the standard for some various piece of functionality to work, are they dont' conform at all and people don't use them for that reason.   Look at WAR file formats - A standard that all java-related build tools will create...  Think of it the same way.  We're making a standard for scala-tools.org pom files (which are already in the maven standard format which tools make use of) for those who wish to deploy artifacts to scala-tools.org.   If you don't want to deploy, you can do whatever you want.

I'm going to offer another alternative (one that can be accomplished with Maven/Ant/Ivy) and that is deploying a secondary XML file with a classifer of "scalatools-metainfo".   In the artifact directory you would then see something like:

/org/scala-lang/scala-library/2.7.7/
   scala-library-2.7.7.jar
   scala-library-2.7.7.pom
   scala-library-2.7.7-sources.jar
   scala-library-2.7.7-javadoc.jar
   scala-library-2.7.7-scalatools-metainfo.xml    <---****  This is easy to deploy with most maven repository deployment solutions


This will:
   * Let us use whatever format we want
   * Work with existing tool chains
   * Allow machine-slurpers to discover information about artifacts on scala-tools.org
   * Allow build tools to create DSLs or non-XML means to describe the content


The next question we need to answer is what is the format/content of this data?   After we agree on that standard, I think this is the easiest path to success... Rather than waiting for Maven 3.1.   When that happens, we could roll the data back into the pom, but for now I think separate solution is far better on all accounts.   It also makes it easy for users of the data to deal with "legacy" artifacts... they don't have a metadata xml file!


- Josh




On Tue, Apr 27, 2010 at 6:57 AM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

Three places where this could fail:
1. Report generation that lists properties defined in a POM.  I imagine that such a tool would perform variable substitution then dump the string into the generated HTML, where the xml tags would be unrecognised and thus suppressed  (or worse still, fail on some form of schema validation).
2. I'm not yet converted to sbt, so I hand-craft my pom at first, then later convert to yaml after getting annoyed with the boilerplate.  yaml-xml synchronisation is maintained by a maven plugin and it considers all properties to be raw strings.  What if ALL raw strings are xml-escaped as part of the conversion?  my pom would now contain &gt; and &lt; where I actually expected proper xml tags.
3. Same as 2, but this time I'm using the POM editor built into eclipse.

I *do* understand the logic behind keeping everything in XML, truly I do... but I also believe that:
- There's not a single tool we'll be using that can't easily deal with a comma-delimited string
- There are too many third-party tools out there, none of which are under our control, and many of which will choke on nested tags inside a property or a separate namespace inside the pom.



On 27 April 2010 11:45, Stefan Langer <mailtolanger@googlemail.com> wrote:

Jsut to make my argument more clear I'm not saying that the published
artifact should not be xml . I'm just saying that it should not be in
the sbt Project.scala file which is scala code. It should be
encapsulated in a object structrue which is type safe and easily
accessible through the Project file. When sbt creates the pom.xml it
will turn this internal representation into the expected xml
structure.

2010/4/26 David Pollak <feeder.of.the.bears@gmail.com>:
>
>
> On Mon, Apr 26, 2010 at 2:03 PM, Matthew Pocock
> <turingatemyhamster@googlemail.com> wrote:
>>
>> I'd like to strongly disagree. If these project tags are to be used for
>> anything other than pure scala, then it is very important that they be
>> represented as xml in the pom. There's nothing like finding micro-syntax in
>> an xml file to completely turn people off. Maven3 allows project config
>> files to be represented in the language of your choice. You can have your
>> nice pure scala syntax using maven3's polyglot capabilities. For eveyone
>> using the legacy xml format, they will be expecting everything to be xml.
>
> Let me weigh in because I'm the guy that owns the Scala tools machine and
> will be one of the guys that deploys whatever script/code creates the index.
>
> XML is the best format.  Anything that requires running code (e.g., Scala
> code) on that machine isn't going to happen... there's just too much of a
> security risk.
>
>>
>> Matthew
>>
>> On 26 April 2010 12:43, Stefan Langer <mailtolanger@googlemail.com> wrote:
>>>
>>> If you are providing tags within the Project definition then please do
>>> it with a scala syntax and not a huge xml artifact. I find it highly
>>> unreadable and obstructing the code when using xml even though Scala
>>> has excellent support for xml.
>>> I don't mind a xmlTo and fromXml for easier match up with xml but if
>>> we are inventing someting new lets stick with classes, objects and
>>> traits for defining it and provide a nice and easy scalaresque DSL for
>>> accessing it.
>>>
>>> Just my 2cts.
>>>
>>> - Stefan
>>>
>>> 2010/4/24 Maxime Lévesque <maxime.levesque@gmail.com>:
>>> >
>>> >  How about a method like this in SBT :
>>> >
>>> >   def projectSearchableAndPresentableInfo =
>>> >     <ProjectInfo name='Etc...'>
>>> >       <KeyWords="sbt, compiler, plugin"/>
>>> >       <OneParagraphDescription>
>>> >          Short description here....
>>> >       </OneParagraphDescription>
>>> >       <MainPage>
>>> >          h1. textile or Markdown markup in here....
>>> >       </MainPage>
>>> >     </ProjectInfo>
>>> >
>>> >  This would end up in the POM. All project from a maven repo could be
>>> > extracted to generate a searchable *and* presentable catalogue like
>>> > site.
>>> > Now I don't know how maven behaves if you put non maven tags in a POM.
>>> > In
>>> > case it doesn't like it,
>>> > I would just cram the whole structure in JSON in the project
>>> > description
>>> > tag... Yes it would be very ugly and non human readable,
>>> > but I already avoid reading and writing POMs anyways, I leave it to
>>> > SBT.
>>> >
>>> >  Max
>>> >
>>> > On Fri, Apr 23, 2010 at 7:03 PM, Kevin Wright
>>> > <kev.lee.wright@googlemail.com> wrote:
>>> >>
>>> >>
>>> >> On 23 April 2010 21:11, David Flemström <david.flemstrom@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> On Fri, Apr 23, 2010 at 12:12 PM, Kevin
>>> >>> Wright <kev.lee.wright@googlemail.com> wrote:
>>> >>>>
>>> >>>> But you'd have to bribe me quite heavily before I'd accept it as
>>> >>>> "cleaner", I just see a lot of boilerplate and accidental
>>> >>>> complexity.  If
>>> >>>> we're going so far as to isolate this stuff in an entire dedicated
>>> >>>> namespace, then we may as well just use a separate file with one tag
>>> >>>> per
>>> >>>> line - can't get much cleaner than that!
>>> >>>
>>> >>> When I say 'clean', I usually refer to something that lacks
>>> >>> complexity
>>> >>> (and not only from the user's perspective).
>>> >>> For example, let's say that a special property was introduced called
>>> >>> "project.tags" and that contained a comma-separated tag cloud as some
>>> >>> have
>>> >>> been suggesting. This might at first seem like a 'clean' solution as
>>> >>> seen
>>> >>> from the POM writer's perspective, but there are a heap of problems
>>> >>> coming
>>> >>> along as well. Let's say that someone wants to have a tag that
>>> >>> includes a
>>> >>> comma. Or let's say that a need for "main tags", "category tags" and
>>> >>> "cloud
>>> >>> tags" arises. Continuing along the same line of clean thinking, we
>>> >>> might end
>>> >>> up with something like:
>>> >>>
>>> >>> <project.tags>[sbt plugin],[compiler
>>> >>>
>>> >>> plugin]{alias='compiler-plugin'},development{type='category'},concurrency,type
>>> >>> checker,dev</project.tags>
>>> >>>
>>> >>> (I took this horrid syntax as an example because I've seen something
>>> >>> very
>>> >>> similar in a tag-based CSS-like selector system I've been unfortunate
>>> >>> enough
>>> >>> to work with recently. They also started out with a "clean" system)
>>> >>> Yes, this seemingly simple system works, but it:
>>> >>>
>>> >>> introduces a completely new syntax that has to be learned both by
>>> >>> developers and parsers
>>> >>> doesn't scale well
>>> >>> is very implementation dependent (Can the syntax be understood by
>>> >>> other
>>> >>> tag consumers? Is there an easy way to standardize it?)
>>> >>>
>>> >>> I understand that you already realize most of this, but I just wanted
>>> >>> to
>>> >>> be explicit.
>>> >>> BTW, for comparison:
>>> >>>
>>> >>> <s:tags>
>>> >>>     <s:tag type="main">sbt plugin</s:tag>
>>> >>>     <s:tag type="main">compiler plugin</s:tag>
>>> >>>     <s:tag type="main" alias="compiler-plugin">compiler
>>> >>> plugin</s:tag>
>>> >>>     <s:tag type="category">development</s:tag>
>>> >>>     <s:tag>type checker</s:tag>
>>> >>>     <s:tag>dev</s:tag>
>>> >>> </s:tags>
>>> >>>
>>> >>> If this is too verbose for you, get a tool that writes your POMs for
>>> >>> you
>>> >>> (e.g. NetBeans).
>>> >>
>>> >> There is a middle ground...
>>> >> I was only ever considering a single class of tags, intended for
>>> >> indexing,
>>> >> searching and human readability
>>> >> In this context, I'd expect the above example to be something like:
>>> >>
>>> >> <project.tags>sbt plugin, compiler plugin, concurrency, type
>>> >> checker</project.tags>
>>> >>
>>> >> Not entirely sure what the intent is behind the category, alias and
>>> >> dev
>>> >> references in your example.  But it's still possible to be a bit
>>> >> richer with
>>> >> a pure property solution and not get too convoluted:
>>> >>
>>> >> <project.category>development</project.category>
>>> >>
>>> >> <project.tags>sbt plugin, compiler plugin, concurrency, type
>>> >> checker</project.tags>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Kevin Wright
>>> >>
>>> >> mail/google talk: kev.lee.wright@googlemail.com
>>> >> wave: kev.lee.wright@googlewave.com
>>> >> skype: kev.lee.wright
>>> >> twitter: @thecoda
>>> >>
>>> >
>>> >
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

[OT] A side note : Thinking about tag is a nice plus, but lib creator
shouldn't forgot to used existing entry in pom.xml (ignoring by lot of
creator, and not provide by sbt, ant,...) like :

* name
* url
* description
* licences
* scm
* issue tracker
* developers
* ...

/davidB

On Tue, Apr 27, 2010 at 14:23, James Strachan wrote:
> On 27 April 2010 13:03, Josh Suereth wrote:
>> The whole point of a "Standard" is so that all the thrid-party tools either
>> conform to the standard for some various piece of functionality to work, are
>> they dont' conform at all and people don't use them for that reason.   Look
>> at WAR file formats - A standard that all java-related build tools will
>> create...  Think of it the same way.  We're making a standard for
>> scala-tools.org pom files (which are already in the maven standard format
>> which tools make use of) for those who wish to deploy artifacts to
>> scala-tools.org.   If you don't want to deploy, you can do whatever you
>> want.
>>
>> I'm going to offer another alternative (one that can be accomplished with
>> Maven/Ant/Ivy) and that is deploying a secondary XML file with a classifer
>> of "scalatools-metainfo".   In the artifact directory you would then see
>> something like:
>
> As an aside - adding tags to a project in a maven repo seems to be a
> very useful thing in general - its not really scala specific at all.
> The more that folks add tags in maven pom's across the entire Java
> ecosystem the more chance we have of nicer tag related tooling in
> maven/ant/ivy/sbt/IDE and repository tools like Nexus et al.
>
> So adding a scala-specific XML file rather than a standard property to
> maven poms seems to be a step backwards from an ecosystem perspective.
>
> Remember the main point of this exercise is to let users find
> libraries more easily using tagged searches on web sites, command line
> tools, IDEs or from repos - not necessarily to worrry about the ideal
> XML format to represent a list of strings.
>
>
>> /org/scala-lang/scala-library/2.7.7/
>>    scala-library-2.7.7.jar
>>    scala-library-2.7.7.pom
>>    scala-library-2.7.7-sources.jar
>>    scala-library-2.7.7-javadoc.jar
>>    scala-library-2.7.7-scalatools-metainfo.xml    <---****  This is easy to
>> deploy with most maven repository deployment solutions
>>
>>
>> This will:
>>    * Let us use whatever format we want
>>    * Work with existing tool chains
>>    * Allow machine-slurpers to discover information about artifacts on
>> scala-tools.org
>>    * Allow build tools to create DSLs or non-XML means to describe the
>> content
>>
>>
>> The next question we need to answer is what is the format/content of this
>> data?   After we agree on that standard, I think this is the easiest path to
>> success... Rather than waiting for Maven 3.1.
>
> Noone's saying we have to wait for Maven 3.1. We can use maven
> properties in the pom.xml yesterday with Maven 2.0.x onwards or with
> any tool that creates a pom.xml file. Or write a couple of liner Scala
> script to edit the generated pom.xml from your tool
>
>
>> When that happens, we could
>> roll the data back into the pom, but for now I think separate solution is
>> far better on all accounts.
>
> Why?
>
> Adding a property to a pom.xml is typically much easier than adding a
> new artifact to be deployed in a release. (e.g. in maven it requires
> much more knowledge to know how to deploy an extra XML file). Plus
> whenever the pom.xml structure natively supports the XML tagging
> structure, this new artifact becomes deprecated anyway.
>
>
>> It also makes it easy for users of the data to
>> deal with "legacy" artifacts... they don't have a metadata xml file!
>
> Being able to add tags to old releases is kinda nice; am not sure
> though if hacking an old release in a maven repo breaks some
> repo/syncing stuff does it? Releases are not meant to be edited.
> Though I guess the tags could be a separate project but somehow
> related to the original release using a naming convention; but this is
> already sounding a little too complex.
>
> Wouldn't just cutting a new release with the metadata included be
> easier? With Scala we have to release often to keep pace with the
> scala compiler anyway right? :)
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>

Most definitely, always use existing pom capabilities where possible!
Can anybody think of other attributes worth publishing? besides those already covered:- existing metadata already available through the pom - a list of classifier tags

On 27 April 2010 13:37, David Bernard <david.bernard.31@gmail.com> wrote:

[OT] A side note : Thinking about tag is a nice plus, but lib creator
shouldn't forgot to used existing entry in pom.xml (ignoring by lot of
creator, and not provide by sbt, ant,...) like :

* name
* url
* description
* licences
* scm
* issue tracker
* developers
* ...

/davidB

On Tue, Apr 27, 2010 at 14:23, James Strachan <james.strachan@gmail.com> wrote:
> On 27 April 2010 13:03, Josh Suereth <joshua.suereth@gmail.com> wrote:
>> The whole point of a "Standard" is so that all the thrid-party tools either
>> conform to the standard for some various piece of functionality to work, are
>> they dont' conform at all and people don't use them for that reason.   Look
>> at WAR file formats - A standard that all java-related build tools will
>> create...  Think of it the same way.  We're making a standard for
>> scala-tools.org pom files (which are already in the maven standard format
>> which tools make use of) for those who wish to deploy artifacts to
>> scala-tools.org.   If you don't want to deploy, you can do whatever you
>> want.
>>
>> I'm going to offer another alternative (one that can be accomplished with
>> Maven/Ant/Ivy) and that is deploying a secondary XML file with a classifer
>> of "scalatools-metainfo".   In the artifact directory you would then see
>> something like:
>
> As an aside - adding tags to a project in a maven repo seems to be a
> very useful thing in general - its not really scala specific at all.
> The more that folks add tags in maven pom's across the entire Java
> ecosystem the more chance we have of nicer tag related tooling in
> maven/ant/ivy/sbt/IDE and repository tools like Nexus et al.
>
> So adding a scala-specific XML file rather than a standard property to
> maven poms seems to be a step backwards from an ecosystem perspective.
>
> Remember the main point of this exercise is to let users find
> libraries more easily using tagged searches on web sites, command line
> tools, IDEs or from repos - not necessarily to worrry about the ideal
> XML format to represent a list of strings.
>
>
>> /org/scala-lang/scala-library/2.7.7/
>>    scala-library-2.7.7.jar
>>    scala-library-2.7.7.pom
>>    scala-library-2.7.7-sources.jar
>>    scala-library-2.7.7-javadoc.jar
>>    scala-library-2.7.7-scalatools-metainfo.xml    <---****  This is easy to
>> deploy with most maven repository deployment solutions
>>
>>
>> This will:
>>    * Let us use whatever format we want
>>    * Work with existing tool chains
>>    * Allow machine-slurpers to discover information about artifacts on
>> scala-tools.org
>>    * Allow build tools to create DSLs or non-XML means to describe the
>> content
>>
>>
>> The next question we need to answer is what is the format/content of this
>> data?   After we agree on that standard, I think this is the easiest path to
>> success... Rather than waiting for Maven 3.1.
>
> Noone's saying we have to wait for Maven 3.1. We can use maven
> properties in the pom.xml yesterday with Maven 2.0.x onwards or with
> any tool that creates a pom.xml file. Or write a couple of liner Scala
> script to edit the generated pom.xml from your tool
>
>
>> When that happens, we could
>> roll the data back into the pom, but for now I think separate solution is
>> far better on all accounts.
>
> Why?
>
> Adding a property to a pom.xml is typically much easier than adding a
> new artifact to be deployed in a release. (e.g. in maven it requires
> much more knowledge to know how to deploy an extra XML file). Plus
> whenever the pom.xml structure natively supports the XML tagging
> structure, this new artifact becomes deprecated anyway.
>
>
>> It also makes it easy for users of the data to
>> deal with "legacy" artifacts... they don't have a metadata xml file!
>
> Being able to add tags to old releases is kinda nice; am not sure
> though if hacking an old release in a maven repo breaks some
> repo/syncing stuff does it? Releases are not meant to be edited.
> Though I guess the tags could be a separate project but somehow
> related to the original release using a naming convention; but this is
> already sounding a little too complex.
>
> Wouldn't just cutting a new release with the metadata included be
> easier? With Scala we have to release often to keep pace with the
> scala compiler anyway right? :)
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

O, I agree with you that the pom format should be extended. I see
that as a longer term strategy with the short term involving a
specific "extra" meta info XML file. This will let us accomplish our
tasks while we wait for the mammoth maven machine to add custom tag
support (or add new tags to the basic pom schema).

- Josh

On Apr 27, 2010, at 8:23 AM, James Strachan
wrote:

> On 27 April 2010 13:03, Josh Suereth wrote:
>> The whole point of a "Standard" is so that all the thrid-party
>> tools either
>> conform to the standard for some various piece of functionality to
>> work, are
>> they dont' conform at all and people don't use them for that
>> reason. Look
>> at WAR file formats - A standard that all java-related build tools
>> will
>> create... Think of it the same way. We're making a standard for
>> scala-tools.org pom files (which are already in the maven standard
>> format
>> which tools make use of) for those who wish to deploy artifacts to
>> scala-tools.org. If you don't want to deploy, you can do whatever
>> you
>> want.
>>
>> I'm going to offer another alternative (one that can be
>> accomplished with
>> Maven/Ant/Ivy) and that is deploying a secondary XML file with a
>> classifer
>> of "scalatools-metainfo". In the artifact directory you would
>> then see
>> something like:
>
> As an aside - adding tags to a project in a maven repo seems to be a
> very useful thing in general - its not really scala specific at all.
> The more that folks add tags in maven pom's across the entire Java
> ecosystem the more chance we have of nicer tag related tooling in
> maven/ant/ivy/sbt/IDE and repository tools like Nexus et al.
>
> So adding a scala-specific XML file rather than a standard property to
> maven poms seems to be a step backwards from an ecosystem perspective.
>
> Remember the main point of this exercise is to let users find
> libraries more easily using tagged searches on web sites, command line
> tools, IDEs or from repos - not necessarily to worrry about the ideal
> XML format to represent a list of strings.
>
>
>> /org/scala-lang/scala-library/2.7.7/
>> scala-library-2.7.7.jar
>> scala-library-2.7.7.pom
>> scala-library-2.7.7-sources.jar
>> scala-library-2.7.7-javadoc.jar
>> scala-library-2.7.7-scalatools-metainfo.xml <---**** This is
>> easy to
>> deploy with most maven repository deployment solutions
>>
>>
>> This will:
>> * Let us use whatever format we want
>> * Work with existing tool chains
>> * Allow machine-slurpers to discover information about artifacts
>> on
>> scala-tools.org
>> * Allow build tools to create DSLs or non-XML means to describe
>> the
>> content
>>
>>
>> The next question we need to answer is what is the format/content
>> of this
>> data? After we agree on that standard, I think this is the
>> easiest path to
>> success... Rather than waiting for Maven 3.1.
>
> Noone's saying we have to wait for Maven 3.1. We can use maven
> properties in the pom.xml yesterday with Maven 2.0.x onwards or with
> any tool that creates a pom.xml file. Or write a couple of liner Scala
> script to edit the generated pom.xml from your tool
>
>
>> When that happens, we could
>> roll the data back into the pom, but for now I think separate
>> solution is
>> far better on all accounts.
>
> Why?
>
> Adding a property to a pom.xml is typically much easier than adding a
> new artifact to be deployed in a release. (e.g. in maven it requires
> much more knowledge to know how to deploy an extra XML file). Plus
> whenever the pom.xml structure natively supports the XML tagging
> structure, this new artifact becomes deprecated anyway.
>
>
>> It also makes it easy for users of the data to
>> deal with "legacy" artifacts... they don't have a metadata xml file!
>
> Being able to add tags to old releases is kinda nice; am not sure
> though if hacking an old release in a maven repo breaks some
> repo/syncing stuff does it? Releases are not meant to be edited.
> Though I guess the tags could be a separate project but somehow
> related to the original release using a naming convention; but this is
> already sounding a little too complex.
>
> Wouldn't just cutting a new release with the metadata included be
> easier? With Scala we have to release often to keep pace with the
> scala compiler anyway right? :)
>

Josh Suereth wrote:

> I'm going to offer another alternative (one that can be accomplished
> with Maven/Ant/Ivy) and that is deploying a secondary XML file with a
> classifer of "scalatools-metainfo". In the artifact directory you
> would then see something like:
>
> /org/scala-lang/scala-library/2.7.7/
> scala-library-2.7.7.jar
> scala-library-2.7.7.pom
> scala-library-2.7.7-sources.jar
> scala-library-2.7.7-javadoc.jar
> scala-library-2.7.7-scalatools-metainfo.xml <---**** This is easy
> to deploy with most maven repository deployment solutions
>
>
> This will:
> * Let us use whatever format we want
> * Work with existing tool chains
> * Allow machine-slurpers to discover information about artifacts on
> scala-tools.org
> * Allow build tools to create DSLs or non-XML means to describe the
> content

+1