from:"Tim O'Brien"



On Feb 12, 2008, at 10:30 AM, John Casey wrote:

FWIW, I think as long as we have a standard format for POMs on a  
single remote repository, it doesn't hurt to accommodate all comers  
WRT format.


XML is okay for developers familiar with it to read, but it was  
always intended to be rendered in some way. If we had rendering  
tools to give the user a decent view on the POM, all of these  
arguments would go away, since we could just provide additional  
renderers along with the different parsers.


Also, if we're going to accommodate multiple XML formats (element- 
oriented vs. attribute-oriented) would it make more sense to give a  
hint of which format we're using via processing instruction at the  
top or something similar? If we do this, there could be 2 XML-based  
parsers, or 2000...as long as the shared data in the remote  
repository has a standard format, what's the difference? We can  
control the standard format on the central repository, for one  
thing, and definitely make sure it's as consumable as possible for  
older Maven versions. Others running their own internal repositories  
will have their own concerns WRT POM format, and can set their  
internal policy as they see fit.




Open it up to all formats, but make sure that people know that if they  
decide to use a YAML format, they are on there own.   Provide easy  
tools that allow someone to convert back to the "blessed" format.


I'll stop picking fights about this, but I understand people's  
preference to keep a strict standard.  I'm all for it, but I also  
think that if someone comes along with the "reduced text-format",  
there should be a way for them to plug in a parser or a pre- 
processor.   Even though it might make it more difficult for people  
building out tool support, if someone wanted to do something like  
create a binary format, there's nothing stopping them.




-john

On Feb 12, 2008, at 10:55 AM, Tim O'Brien wrote:



On Feb 12, 2008, at 9:34 AM, Gilles Scokart wrote:





-Original Message-
From: Tim O'Brien [mailto:[EMAIL PROTECTED]
Sent: mardi 12 février 2008 16:03
To: Maven Developers List
Subject: Re: An Attribute Based POM


On Feb 12, 2008, at 3:58 AM, Benjamin Bentmann wrote:


For example, we'd can group groupId/artifactId/version into one
attribute
like this:




Please don't do this. This would require another parsing step  
after

the XML
parsing and introduces further error sources. Use XML to structure
the data,
not some proprietary format. Third-party tools dealing with the  
POM

will
also appreciate a proper/pure XML representation of the project  
model.

Consider for instance the pain such string aggregates would cause
for XSLT
processing of the POM. Merging different pieces of data into a
single string
is in general a bad idea.



Couldn't disagree more.   Certain data has a native format.   
Consider

something like a 24 hour time.   Is:

 23:22:22.003

an "undue burden" on different parsers?   No, this is reasonable.
This would be unreasonable:

 

The idea that we have to design data around parsers means that you
sacrifice usability and readability.

I'd take it one step further than Emmanuel:






Should be:


 maven-project:2.0.8
 continuum:continuum-model:1.1


XSLT can tokenize strings just fine.




Than why to use XML?  Why not have simple text?


Giles, why not simple text?  People have already been working with  
POMs in alternative formats that don't involve XML at all.   I  
guess the real question here is, why would it disturb people so  
much if someone had an alternative format for a POM for every day  
use, but when they published to a repo it used the standard format.





No seriously, keep the organisation and artefact separated from  
the version.  There are plenty of use case that needs to
identify them separately (like the management of the conflict, the  
management of the dependent projects).


If you really want something more textual, I suggest you look at  
buildr.  It give you something like this :


AXIOM  = group("axiom-api", "axiom-impl", "axiom-dom",
   :under=>"org.apache.ws.commons.axiom", version=>"1.2.4")
AXIS2 = "org.apache.axis2:axis2:jar:1.2"
OPENJPA = ["org.apache.openjpa:openjpa-all:jar:0.9.7",  
"net.sourceforge.serp:serp:jar:1.12.0"]

AXIS_OF_WS = [AXIS2, AXIOM]

compile.with OPENJPA, AXIS_OF_WS


Why not?  It might be user friendly (for some users...).  But I  
don't want to see this in a repository.  IMO, XML is

much better.



No one is talking about modifying the repository, the repository  
should contain one format of POM, but there is no reason why there  
cannot be a diversity of implementations.  Oh wait, people here  
think it would screw up "Univ

Re: An Attribute Based POM



On Feb 12, 2008, at 9:34 AM, Gilles Scokart wrote:





-Original Message-
From: Tim O'Brien [mailto:[EMAIL PROTECTED]
Sent: mardi 12 février 2008 16:03
To: Maven Developers List
Subject: Re: An Attribute Based POM


On Feb 12, 2008, at 3:58 AM, Benjamin Bentmann wrote:


For example, we'd can group groupId/artifactId/version into one
attribute
like this:




Please don't do this. This would require another parsing step after
the XML
parsing and introduces further error sources. Use XML to structure
the data,
not some proprietary format. Third-party tools dealing with the POM
will
also appreciate a proper/pure XML representation of the project  
model.

Consider for instance the pain such string aggregates would cause
for XSLT
processing of the POM. Merging different pieces of data into a
single string
is in general a bad idea.



Couldn't disagree more.   Certain data has a native format.  Consider
something like a 24 hour time.   Is:

  23:22:22.003

an "undue burden" on different parsers?   No, this is reasonable.
This would be unreasonable:

  

The idea that we have to design data around parsers means that you
sacrifice usability and readability.

I'd take it one step further than Emmanuel:


 
 


Should be:


  maven-project:2.0.8
  continuum:continuum-model:1.1


XSLT can tokenize strings just fine.




Than why to use XML?  Why not have simple text?


Giles, why not simple text?  People have already been working with  
POMs in alternative formats that don't involve XML at all.   I guess  
the real question here is, why would it disturb people so much if  
someone had an alternative format for a POM for every day use, but  
when they published to a repo it used the standard format.





No seriously, keep the organisation and artefact separated from the  
version.  There are plenty of use case that needs to
identify them separately (like the management of the conflict, the  
management of the dependent projects).


If you really want something more textual, I suggest you look at  
buildr.  It give you something like this :


AXIOM  = group("axiom-api", "axiom-impl", "axiom-dom",
   :under=>"org.apache.ws.commons.axiom", version=>"1.2.4")
AXIS2 = "org.apache.axis2:axis2:jar:1.2"
OPENJPA = ["org.apache.openjpa:openjpa-all:jar:0.9.7",  
"net.sourceforge.serp:serp:jar:1.12.0"]

AXIS_OF_WS = [AXIS2, AXIOM]

compile.with OPENJPA, AXIS_OF_WS


Why not?  It might be user friendly (for some users...).  But I  
don't want to see this in a repository.  IMO, XML is

much better.



No one is talking about modifying the repository, the repository  
should contain one format of POM, but there is no reason why there  
cannot be a diversity of implementations.  Oh wait, people here  
think it would screw up "Universal Understanding".


:-)



Gilles







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: An Attribute Based POM

Right of course, but the core idea is that XML doesn't drive the  
format or structure of data.It should tell you guys something that  
negative reactions to Maven like Buildr use the colon notation. 
Maven itself prints out dependencies using the colon notation when you  
run the dependency plugin and when you turn on debug info.


On Feb 12, 2008, at 9:18 AM, nicolas de loof wrote:


Your example just demonstrate the issue with String formated :

23:22:22.003
or
11PM:22:22.003
or
21:22:22.003 UTC

???

The "native" format for time (in computer world) is number of ms since
01/01/1970 .. so its un non-formated binary type
The equivalent XML element should be something like

23:22:22.003

2008/2/12, Tim O'Brien <[EMAIL PROTECTED]>:



On Feb 12, 2008, at 3:58 AM, Benjamin Bentmann wrote:


For example, we'd can group groupId/artifactId/version into one
attribute
like this:




Please don't do this. This would require another parsing step after
the XML
parsing and introduces further error sources. Use XML to structure
the data,
not some proprietary format. Third-party tools dealing with the POM
will
also appreciate a proper/pure XML representation of the project  
model.

Consider for instance the pain such string aggregates would cause
for XSLT
processing of the POM. Merging different pieces of data into a
single string
is in general a bad idea.



Couldn't disagree more.   Certain data has a native format.  Consider
something like a 24 hour time.   Is:

  23:22:22.003

an "undue burden" on different parsers?   No, this is reasonable.
This would be unreasonable:

  

The idea that we have to design data around parsers means that you
sacrifice usability and readability.

I'd take it one step further than Emmanuel:


 
 


Should be:


  maven-project:2.0.8
  continuum:continuum-model:1.1


XSLT can tokenize strings just fine.




Besides, this thread is about improving user experience with the
POM. Now,
if one needs to declare a dependency with groupId, artifactId,
version,
classifier, type and scope can you remember the proper order for all
those
elements when putting them into a single string? As for me, the
answer is
"No".

Regards,


Benjamin Bentmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: An Attribute Based POM



On Feb 12, 2008, at 3:58 AM, Benjamin Bentmann wrote:

For example, we'd can group groupId/artifactId/version into one  
attribute

like this:




Please don't do this. This would require another parsing step after  
the XML
parsing and introduces further error sources. Use XML to structure  
the data,
not some proprietary format. Third-party tools dealing with the POM  
will

also appreciate a proper/pure XML representation of the project model.
Consider for instance the pain such string aggregates would cause  
for XSLT
processing of the POM. Merging different pieces of data into a  
single string

is in general a bad idea.



Couldn't disagree more.   Certain data has a native format.  Consider  
something like a 24 hour time.   Is:


  23:22:22.003

an "undue burden" on different parsers?   No, this is reasonable.
This would be unreasonable:


  

The idea that we have to design data around parsers means that you  
sacrifice usability and readability.


I'd take it one step further than Emmanuel:


 
 


Should be:


  maven-project:2.0.8
  continuum:continuum-model:1.1


XSLT can tokenize strings just fine.




Besides, this thread is about improving user experience with the  
POM. Now,
if one needs to declare a dependency with groupId, artifactId,  
version,
classifier, type and scope can you remember the proper order for all  
those
elements when putting them into a single string? As for me, the  
answer is

"No".

Regards,


Benjamin Bentmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: An Attribute Based POM

Why not further steps towards terseness?

1. Get rid of collection container elements.

Why this:

descriptor

When this wold suffice:

descriptor

This seems like a trivial issue, but when you look at all of the
container elements, dependencies, plugins, exclusions, profiles.
Doing this would require...

2. Getting away from xs:all and defining an order for child elements
throughout the XSD.

On Feb 11, 2008, at 12:45 AM, Brett Porter wrote:

Hi,

I've always wanted to see an attribute based POM, so based on
Nicolas' suggestion I killed some time after waking up early this
morning to do it.

JIRA: http://jira.codehaus.org/browse/MNG-3397

Here is a build to try:
http://people.apache.org/~brett/apache-maven-2.0.9-SNAPSHOT-terse-bin.tar.gz
and svn branch:
http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x-terse

Here are two different files for comparison (it halved the size):
http://svn.apache.org/viewvc/maven/archiva/trunk/pom.xml?content-type=text%2Fplain&view=co
http://svn.apache.org/viewvc/maven/archiva/trunk/pom-4.1.0.xml?content-type=text%2Fplain&view=co

What I did is basically convert all the primitive types in the model
to attributes. I think more could be done (flattening lists, doing
the same for plugin configuration elements), but this gets a big win
at least in the dependencies section for minimal work.

It should be completely backwards compatible. It detects v4.0.0 and
reads it like it used to (then internally converts to the 4.1.0 Java
model).

Here's some notes on the implementation so far (again, go easy, I
just whipped this up today and it's not production ready):
- I see this as a stepping stone to the final solution. I've said
this before, but I think the POM should separate the build
information from the project metadata (particularly that stored in
the repository). I think we need to take baby steps towards that
though.
- this could feasibly be applied to the settings and profile files
too.
- I switched to StAX in the process. This is likely going to
introduce some small quirks we need to iron out (like the hack I
added to parse Trygve's name - why did we ever allow that!) I think
ideally we'd use the Xpp3Reader for 4.0.0 and the StaxReader for
4.1.0 for best compatibility. This would also fix the problem in
that I've just removed the Xpp3Reader and so some plugins may choke.
I'm sure the release plugin won't be happy, for example.
- There is probably a slight performance overhead in reading v4 POMs
since it repopulates the model twice. I haven't measured it but if
it's an issue we could optimise the reader/converter. It also adds
about 200k to the maven-model JAR.
- It is very close to detecting based on namespace so we could
enforce the use of that instead.

Enjoy!

Cheers,
Brett

--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: proposal : make POM less verbose



On Feb 10, 2008, at 11:14 AM, Wendell Beckwith wrote:


Tim,

I see where you're going and in general I agree with you as I think  
most
software should be extensible to handle unknown environments and  
unique

situations.




 However, I think the biggest bang for buck is to fix/enhance
the current one way and then add pluggability for POM parser  
substitution if
it is really needed.  The 1 negative that I see in POM parser  
substitution
is that if a user is use to "classic" POM files and sees an  
"enhanced" POM
file then they will likely still be able to grok what's going on.   
However,
a user seeing a groovy, jruby or Joe Blow's domain specific language  
POM

file will be in a WTF situation.


People will use whatever implementation they feel like using.   I'd  
propose that you start by shipping Maven with two:


1. Classic - the way it works now
2. Reduced XML - the thing that Nicolas proposed

If someone wants to ship an implementation that understands something  
like:


http://www.coderoshi.com/2007/08/maven-less-ugly.html

If people start using it, and there is a demand to add native support  
for someone's format, then you can add it in later.


As long as it contains the same info, no more, no less, than the POM  
you have now.   What's the damage?   Does Eric's YAML break the  
Universal Understanding, or does it provide another path for users who  
might not want to start at XML even if it is different?














Wb


On Feb 10, 2008 11:01 AM, Tim O'Brien <[EMAIL PROTECTED]> wrote:



On Feb 10, 2008, at 10:57 AM, nicolas de loof wrote:


Using attributes in place of XML elements is not revolutionary. I
don't
speak here about writting POMs in groovy !



That's the difference, I do.   I think people should have the
opportunity to replace the parser entirely and write custom
implementations.   Class POM + something more like what you propose.
But I also don't think the door should be closed for someone to come
along and write a parser that can read something like YAML or Groovy.


This is just about better use of XML, it requires only a "tweak" of
the
Xpp3Parser to handle attributes the same way it handles nested
elements, and
maybe to change the install/deploy to convert the POM to "classic"
element-based format.



The problem here is that there is one way to parse a model, changing
that one way to a different way isn't the fix.  The fix is to provide
more than one implementation.




Nico.

2008/2/10, Tim O'Brien <[EMAIL PROTECTED]>:


Nicolas,

I agree that POM verbosity is a problem, but I also think that a  
lot

of people on this list are not going to want to introduce
revolutionary changes to POM structure without being convinced  
(as we

are) that it is a problem.

The first step to this would be to add the ability to plugin in
another parser implementation.   Abstract both the pom and settings
parsing from the Xpp3 stuff generated by modello, and make the Xpp3
parsers the default implementation.   At that point, it would be
easier to generate alternative parsers or preprocessors (like what
Redmond did with YAML).  What can't change is the infoset of the
current POM, the current POM structure can't change because of
backwards compatibility, the POM that is generated in a repository
cannot change, but the format that people use to manage a project.
That should be pluggable and customizable, but any change  
introduced

can't break the current model.

But, I'm not optimisitc it is going to happen unless someone just
does
it and writes a ranting blog entry about it.

Tim O'Brien

On Feb 10, 2008, at 3:34 AM, nicolas de loof wrote:


Hello,

Maven detractors blam maven  POM.xml to become huge XML files even
for
simple tasks.
Considering the comparison with ant, the latest use XML attributes
an few
XML elements, making tasks declaration consise.

Could we introduce a new XML schema (for maven 2.1) to support
simple types
elements as attributes, maybe using namespaces :



4.0.0

org.codehaus.mojo
my-project
1.0


... could be written :




We could use namespaces to avoid colision in maven schemas, and
support a mix of elements and attributs :




4.0.0




The previous examples are just to fix the principle. Declaring
dependencies and plugins configuration could become really consice
and
enhance readability.



Nico.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: proposal : make POM less verbose



On Feb 10, 2008, at 10:57 AM, nicolas de loof wrote:

Using attributes in place of XML elements is not revolutionary. I  
don't

speak here about writting POMs in groovy !



That's the difference, I do.   I think people should have the  
opportunity to replace the parser entirely and write custom  
implementations.   Class POM + something more like what you propose.
But I also don't think the door should be closed for someone to come  
along and write a parser that can read something like YAML or Groovy.


This is just about better use of XML, it requires only a "tweak" of  
the
Xpp3Parser to handle attributes the same way it handles nested  
elements, and

maybe to change the install/deploy to convert the POM to "classic"
element-based format.



The problem here is that there is one way to parse a model, changing  
that one way to a different way isn't the fix.  The fix is to provide  
more than one implementation.





Nico.

2008/2/10, Tim O'Brien <[EMAIL PROTECTED]>:


Nicolas,

I agree that POM verbosity is a problem, but I also think that a lot
of people on this list are not going to want to introduce
revolutionary changes to POM structure without being convinced (as we
are) that it is a problem.

The first step to this would be to add the ability to plugin in
another parser implementation.   Abstract both the pom and settings
parsing from the Xpp3 stuff generated by modello, and make the Xpp3
parsers the default implementation.   At that point, it would be
easier to generate alternative parsers or preprocessors (like what
Redmond did with YAML).  What can't change is the infoset of the
current POM, the current POM structure can't change because of
backwards compatibility, the POM that is generated in a repository
cannot change, but the format that people use to manage a project.
That should be pluggable and customizable, but any change introduced
can't break the current model.

But, I'm not optimisitc it is going to happen unless someone just  
does

it and writes a ranting blog entry about it.

Tim O'Brien

On Feb 10, 2008, at 3:34 AM, nicolas de loof wrote:


Hello,

Maven detractors blam maven  POM.xml to become huge XML files even  
for

simple tasks.
Considering the comparison with ant, the latest use XML attributes
an few
XML elements, making tasks declaration consise.

Could we introduce a new XML schema (for maven 2.1) to support
simple types
elements as attributes, maybe using namespaces :



4.0.0

org.codehaus.mojo
my-project
1.0


... could be written :




We could use namespaces to avoid colision in maven schemas, and
support a mix of elements and attributs :




4.0.0




The previous examples are just to fix the principle. Declaring
dependencies and plugins configuration could become really consice  
and

enhance readability.



Nico.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: proposal : make POM less verbose


Nicolas,

I agree that POM verbosity is a problem, but I also think that a lot  
of people on this list are not going to want to introduce  
revolutionary changes to POM structure without being convinced (as we  
are) that it is a problem.


The first step to this would be to add the ability to plugin in  
another parser implementation.   Abstract both the pom and settings  
parsing from the Xpp3 stuff generated by modello, and make the Xpp3  
parsers the default implementation.   At that point, it would be  
easier to generate alternative parsers or preprocessors (like what  
Redmond did with YAML).  What can't change is the infoset of the  
current POM, the current POM structure can't change because of  
backwards compatibility, the POM that is generated in a repository  
cannot change, but the format that people use to manage a project.
That should be pluggable and customizable, but any change introduced  
can't break the current model.


But, I'm not optimisitc it is going to happen unless someone just does  
it and writes a ranting blog entry about it.


Tim O'Brien

On Feb 10, 2008, at 3:34 AM, nicolas de loof wrote:


Hello,

Maven detractors blam maven  POM.xml to become huge XML files even for
simple tasks.
Considering the comparison with ant, the latest use XML attributes  
an few

XML elements, making tasks declaration consise.

Could we introduce a new XML schema (for maven 2.1) to support  
simple types

elements as attributes, maybe using namespaces :



4.0.0

org.codehaus.mojo
my-project
1.0


... could be written :

   groupId="org.codehaus.mojo" artifactId="my-project"  
version="1.0">



We could use namespaces to avoid colision in maven schemas, and
support a mix of elements and attributs :




4.0.0




The previous examples are just to fix the principle. Declaring
dependencies and plugins configuration could become really consice and
enhance readability.



Nico.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Discuss] MPLUGIN-40

2008-02-04 Thread Tim O'Brien



On Feb 4, 2008, at 8:49 PM, Dan Fabulich wrote:


Tim O'Brien wrote:

I'm sorry, hold on... starting stopwatch "mvn help:describe - 
Dplugin=nifty -Dmojo=nifty -Dfull" - alright, I type fast, but that  
took me 10 seconds.   Then I hit enter and a whole *crapload* of  
information zoomed past.   Ok, CTRL-R, mvn, adding a "| less".
Ok, for something like "help:describe", I'm looking at eight or  
nine pages of sleep inducing variable names.


Slow down, we agree more than we disagree.  That's why I filed a  
bunch of bugs against MPH today:


http://tinyurl.com/2c4j42

In particular, I think MPH-31 and MPH-32 would be good fixes, and  
don't require weird changes to core.  I'd prefer you'd typed "mvn  
help -Dcmd=nifty:nifty", and that "mvn help" explained how that works.


I'm serious the help plugin hurts, go back to what Jason said about  
svn doing a better job.


(Didn't I say that?)  I'm not saying that the help plugin is  
perfect; I'm saying that we don't need to re-invent the wheel or  
hack the CLI to make this feature work, and that if you want to use  
it, you can start doing so right now.


Well I think it would help to make it a bit more accessible.   All that:

mvn help:describe -Dplugin= -Dmojo= -Dfull

Should likely be changed to something easier to type:

mvn-help dependency

or

mvn-help ant:run

mvn-help -l   

No?  Yes?




But as for finding plugins, it's better to search the Internet for  
that sort of thing, rather than trying to turn the Maven core into  
an Internet search engine for Maven plugins.


Dan, can I quote you on "It's better to search the Internet for  
that sort of thing" the next time I have to defend Maven to some  
end-user who is absolutely enraged by the fact that they've had to  
spend the last fourteen hours trying to track down the reason why  
the dependency plugin they have installed doesn't support the tree  
goal even though the documentation on the Maven site tells them to  
run it (Hint: they don't have the right version)


Version diagnosis is very different from finding plugins to use.  It  
IS better to search the Internet to find plugins, which is what the - 
G switch is all about.  (It tells you about all plugins available  
everywhere, not just the ones you've got installed.)  Searching the  
Internet isn't better to diagnose version problems, but then, -G  
wouldn't have helped that either.




I guess I disagree here because I believe the following statements to  
be true:  mojo is something of a horror (it's getting a little  
better), plugins on the Maven site are often dev versions, the future  
of the success of Maven is for plugin development to become very  
decentralized (see Springer's Docbkx, and the Israfil Flex plugin)


I think a simple tool, packaged with Maven that knows of some plugin  
groupIds. Would be a great thing.   Run it, it lists all the plugins  
it knows about, you can see information about them.It's like gem  
for Maven..


In fact, the help plugin is a pretty good way of diagnosing  
versions, or at least starting to.  "mvn help:describe - 
Dplugin=dependency -Dmedium" will tell you what you can do with the  
dependency plugin you've got installed and, prominently, what  
version you're using.


Annoyed by those -Dfull and -Dmedium flags?  Me, too... that's  
MPH-31, MPH-32, and MPH-35.


No one is saying they want Maven to be the "Internet Search Engine"  
for plugins.  Maybe someone is saying, "what we have now isn't  
adequate". Seconded.


We agree again!



Alright, Dan, let's do it.   Let me know how I can help.

Makes sense.  But, wait, in that help:describe, you didn't call it  
a "goal", the property was a "mojo"?


Yeah, that's why I already filed MPH-33 earlier today.


I dig.



-Dan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Discuss] MPLUGIN-40

2008-02-04 Thread Tim O'Brien



On Feb 4, 2008, at 6:14 PM, Dan Fabulich wrote:


Jan Nielsen wrote:

Finding the definitive help information for a plugin should be  
absolutely trivial and built-in; having the CLI option which give  
the code-you-are-executing-right-now the ability to answer that  
question avoids the issues we have today with multiple sources for  
a plugin with different HTML usage information.


Have you tried "mvn help:describe -Dplugin=nifty -Dmojo=nifty - 
Dfull"?  I think we already have what you want, but we've yet again  
failed to document it adequately.  (Try it with -Dplugin=compiler - 
Dmojo=compile.)


I'm sorry, hold on... starting stopwatch "mvn help:describe - 
Dplugin=nifty -Dmojo=nifty -Dfull" - alright, I type fast, but that  
took me 10 seconds.   Then I hit enter and a whole *crapload* of  
information zoomed past.   Ok, CTRL-R, mvn, adding a "| less".   Ok,  
for something like "help:describe", I'm looking at eight or nine pages  
of sleep inducing variable names.


I'm serious the help plugin hurts, go back to what Jason said about  
svn doing a better job.





And while I'm at it, and relatedly, whatever happened to "-G" to  
get me a list of all plugins???


I never used 1.x, but I don't think that makes sense any more.  We  
could certainly provide a list of all valid lifecycle phases (and we  
should do so in the help plugin), since those are static and don't  
change.


http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

But as for finding plugins, it's better to search the Internet for  
that sort of thing, rather than trying to turn the Maven core into  
an Internet search engine for Maven plugins.  (Similarly, wouldn't  
it be cool if you could use a simple Maven command-line switch to  
search for jars you could use in your project?  Wait, no it  
wouldn't; that's what Google is for.)


Dan, can I quote you on "It's better to search the Internet for that  
sort of thing" the next time I have to defend Maven to some end-user  
who is absolutely enraged by the fact that they've had to spend the  
last fourteen hours trying to track down the reason why the dependency  
plugin they have installed doesn't support the tree goal even though  
the documentation on the Maven site tells them to run it (Hint: they  
don't have the right version)


No one is saying they want Maven to be the "Internet Search Engine"  
for plugins.   Maybe someone is saying, "what we have now isn't  
adequate".Seconded.





And I might as well chuck in: why in the world do I need to do "mvn  
nifty:nifty" and not just "mvn nifty"?


Because that way we don't have to guess whether you're trying to run  
a goal or a lifecycle phase.  "install" is a great example.  Do you  
just want to run the install:install goal, or did you want to run  
every lifecycle phase up through the install phase?


Makes sense.But, wait, in that help:describe, you didn't call it a  
"goal", the property was a "mojo"?I guess what Mavenland has to  
get over is that "users" don't know what a Mojo is?   They shouldn't  
be expected to know what a "Mojo" is, you should be able to use Maven  
without knowing very much about it.





-Dan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release maven-changelog-plugin 2.1 (take 2)

2007-07-19 Thread Tim O'Brien


+0  (non-binding).   Just chiming in that I've tested this plugin release
and verified that it works.

On 7/19/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:


Hi,

This is a second try to release maven-changelog-plugin 2.1. All issues
in JIRA have been closed, including MCHANGELOG-66 which came in during
the last vote.

Release Notes:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11211&styleName=Html&version=12587

Tag:

http://svn.apache.org/repos/asf/maven/plugins/tags/maven-changelog-plugin-2.1/

Staged at:
http://people.apache.org/~dennisl/staging-repository-changelog-plugin/

Staged site at:
http://people.apache.org/~dennisl/maven-changelog-plugin/index.html

The vote will be open for 72 hours.


Here is my +1


PS. I forgot to remove the staging repo from the last vote, before I did
release:perform. So I did these steps, hope that is correct. If not
please let me know.

* Nuked the staging-repo on people.a.o
* Went down into the directory target/checkout, that was just created
* Ran
   mvn deploy -Prelease -DaltDeploymentRepository=same-as-in-settings.xml

--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
--
Tim O'Brien: (847) 863-7045

Re: Maven Wiki

2007-05-23 Thread Tim O'Brien

On 5/23/07, Brett Porter <[EMAIL PROTECTED]> wrote:

On 23/05/2007, at 2:10 PM, Jason van Zyl wrote:

> Let's run with that below, now what do we do to organize the actual
> information for each sub-project and what tools can we make to make
> the site making follow that structure below.

I think it's just a matter of configuration at this point. So I'll
get started with SCM. Emmanuel - interested?

I'm also calling on Tim O'Brien and Henri Yandell here since I saw
them at JavaOne and they said they'd help out in some way (even if
just applying patches). I think it was even recorded. Are you guys
in? :)

Yes, I'm going to carve out some time each week to  help, and I'm very aware
that the "Nth time with no real results" has a lot to do with me.

I also think it's "put up or shut" time in general.  I've said, and
twittered, a number of lukewarm things about Maven, but that has more to do
with doc frustration than with the project itself.   checking out, checking
JIRA, expect some doc patches.

Tim

Re: Making the current web site suck less

2006-03-10 Thread Tim O'Brien

Brett,

Sure will do, I think a JIRA task wouldn't do this justice.  I'm working on
a mockup in Adobe Illustrator ;-)

On 3/9/06, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> Tim,
>
> There's plenty of points here and on your blog. Can you please put this
> in a proposal form for how to make specific improvements. ie, for
> everything that you think is wrong, say how you'd make it right, in
> point form so each can be specifically addressed and turned into jira
> tasks.
>
> - Brett
>
> Tim O'Brien wrote:
> >  I'm not saying this to be contrary, bear with me:  most people that use
> > Maven don't care to know much about the internals or how it is being
> > developed.
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Making the current web site suck less

2006-03-10 Thread Tim O'Brien

On 3/9/06, Brett Porter <[EMAIL PROTECTED]> wrote:

> Tim O'Brien wrote:
> >  I read your response, clicked on the Geronimo site, and wanted to
> believe
> > that that was possible with Maven.  But, if you look at
> > https://svn.apache.org/repos/asf/geronimo/site/
> >
> > It's either Maven 1.x or Ant the directory contains a v3 POM, but it
> also
> > contains an .  The NOTES.txt begins "Download Ant from
> http://ant.apache.org";.
> >
>
> It's not, but it's entirely possible with the current SVN version of the
> site plugin and is where I want it to go. It's just a replacement
> velocity template.
>
> I didn't understand your point about the structure of the XHTML in your
> blog. It should be reasonably flexible for CSS based layout, and in the
> event you need something different you can fall back to the packaged up
> velocity template.
>
> - Brett

What I mean by this.  Point a graphics desiger at a Maven site - make this
site look great with CSS.  I think you'll find that the graphic designer is
going to request so many changes to structure it would almost be easier for
an organization to just fork and customize the site plugin rather than deal
with what is produced.I would agree that Maven provides a reasonable
amount of flexibility, but I guess I have yet to see a Maven site that
doesn't look like a Maven site.  Maybe we need a site that customizes the
CSS to show people what is possible.  A Zen Garden for Maven.

Tim

> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Making the current web site suck less

2006-03-09 Thread Tim O'Brien

On 3/9/06, John Casey <[EMAIL PROTECTED]> wrote:

>
> 
>
> I agree with you on that point. My point was that physical separation of
> the websites might not be appropriate or necessary, since IMO every ASF
> project that releases a product (not an API) should apply this advice,
> and therefore should have a user-driven aspect, behind which lurks a
> developer-driven section, one click away. The developer pages don't have
> to invade the landing page, but there should be a link (to elsewhere on
> the same physical web site).

Sure.  maybe the same physical web site maybe a different one.  The
Developer and User sites might share a color scheme and a logo, but they
should be able to have completely different structure.   completely
different layout, different context, etc.I'm convinced Maven needs a
focused documentation project.  I'm not convinced that it makes sense to
house that project within the foundation.  That's what drives my suggestion
about a Maven user site being totally separate from a developer site.

Here's where I think we miss.  In the absence of a Maven plugin that creates
a site that a designer can really control, can really customize.  That has
DIV structure and CSS that a designer can be happy with, we probably won't
enable people to get to the point where they can apply a good design to a
Maven site.

> >
> >> It's not a simple hierarchy, but then, we have a great deal of
> variation
> >> among our audience members. As these audience members [possibly]
> >> transition from users to contributors and so on, we don't want a
> >> separation like this to get in their way...there should be *some*
> >> cohesiveness, I would think...
> >
>
> See my comments above. Again, this isn't about merging the developer and
> user communities, forcing them to read the same webpages and filter the
> content that pertains to them. It's about whether we want to move toward
> uniting all of the Maven project content to make it look like part of
> the same site, albeit in different sections. I can't think of very many
> people who might disagree that our site needs some organizational help,
> and a heavy-ish touch of user-friendliness.

And again, I think that the "Maven site" should be a lot more like a
community site that aggregates blogs, lists articles, news items.  In the
absence of a runtime container uses some Javscript to display RSS feeds of
the last 10 user posts.

Look around at Sourceforge sometime, and see how many of the non-Maven
> sites out there are well-designed.

The medocrity of the average shouldn't be the argument here.  If Maven
intends to revolutionize the way people approach software projects.   It
should strive to solve this problem as elegantly as it solves dependency
management.

Re: Making the current web site suck less

On 3/9/06, Brian K. Wallace <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jesse Kuhnert wrote:
> > I think what everyone is saying sounds more or less correct, but what is
> the
> > solution then?
> >
> > If they can't rely on a runtime container to host the site, options
> become
> > MUCH more limited.
> >
> > Complaints about the UI are fine and I'm sure everyone welcomes them,
> but
> > possible solutions that fit into the requirements of the projects
> technical
> > constraints are much more helpful :) I can't think of any really good
> > solutions off the top of my head that don't rely on runtime stuff?
> >
>
> In thinking about what a runtime container would provide, I can't think
> of anything required on a site with no user-login / form / etc that
> would require any sort of container. I, personally, think maven-site
> does an adequate job for sites that "only a developer could love".
>
> To illustrate both my point that a runtime container isn't necessary for
> the information necessary, and a site that's more "user-geared" I
> suggest a look at Geronimo's new look (http://geronimo.apache.org). I'm
> not saying it's perfect - it's closer to Maven's current site than a
> Mozilla site - but it's definitely more "user" oriented/friendly - and
> to the best of my knowledge runs outside of a container. The difference?
> That site was designed. Maven generates sites that are coded. (And I'm
> not talking about "pretty" - more the "concise look" and "user-level
> links".) And that's more of a 'content designed' than a 'look and feel'
> design.


 I read your response, clicked on the Geronimo site, and wanted to believe
that that was possible with Maven.  But, if you look at
https://svn.apache.org/repos/asf/geronimo/site/

It's either Maven 1.x or Ant the directory contains a v3 POM, but it also
contains an .  The NOTES.txt begins "Download Ant from http://ant.apache.org";.

Re: Making the current web site suck less

 links back to
the home page.   The Maven site is full of these inconsistencies, and it's
not something that people can just fix with patches.  IMO, the site plugin
needs serious rework.  It doesn't create good web sites, especially
for multi-projects.

I guess I've just pissed off the Maven development team by telling all of
you that Maven doesn't do a good job of creating web sites for
users.  There, I said it.  Maven creates so-so web sites for developers, but
doesn't do a good job creating web sites for end-users.  Maybe that was
never the goal.  Maybe I should just shut up and write the
maven-end-user-site plugin?  But, it's one reason why I didn't get too
exctied about contributing to the site last year.  I don't think another 100
APT documents are the right direction, I think you need to think long and
hard about the audience, and I think someone other than Hani Sulemani needs
to say "Maven sites suck"   :-)  The fact that one of the core committers
for Maven, had to send out an email entitled "Making the current web site
suck less", is not a good sell for generating sites with Maven.


> >
> >
> > On 3/8/06, John Casey <[EMAIL PROTECTED]> wrote:
> >> +1
> >>
> >> Maybe we can put a banner at the top of each page that marks the
> version
> >> it refers to or something. If we styled the reference doco as a manual,
> >> it could be part of the page layout that ties it together. I'd be
> >> willing to trade a bit of the look&feel for that sort of information,
> as
> >> it seems to me that it would reduce confusion.
> >>
> >> -john
> >>
> >> Tim O'Brien wrote:
> >>> Having to choose between publishing the latest and greatest docs and
> >> only
> >>> the released version is a problem that Maven seems to have created for
> >>> itself.  Same issue comes up in other projects frequently - Commons
> has
> >> a
> >>> problem because some of the sites only publish on a release.  Latest
> and
> >>> greatest are almost never there.
> >>>
> >>> What about publishing the latest and greatest docs to another
> directory?
> >>> The Maven site gets pushed to a directory that has a version of a
> >>> label.  http://maven.apache.org/version/1.0
> >>> , http://maven.apache.org/version/2.0.2, and
> >>> http://maven.apache.org/version/trunk.  This way the Maven site can
> have
> >> a
> >>> nightly publish of the most current Maven site to Trunk every single
> >> day,
> >>> but still keep legacy docs around intact for people using older
> versions
> >> of
> >>> the product.  The "consumer" site can point to the latest release, and
> >> the
> >>> "developer" site can point to "trunk".  The Maven site plugin would
> need
> >>> some mechanism for adding a skin to a site to clearly identify it as
> >>> "Development".
> >>>
> >>>
> >>>
> >>> On 3/7/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> >>>> On 3/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> * I'm still a little torn on where plugin docs go. No hurry on this,
> >> but
> >>>>> something to ponder. We definitely need to make the references for
> >> those
> >>>>> integrate better. Site/skin inheritance will help
> >>>> No matter where they go, I think they need to be updated more often.
> >>>> Random example... the assembly plugin docs are wrong, and have been
> >>>> that way for months. (it's descriptorId, not
> >>>> maven.assembly.descriptorId.)
> >>>> * http://maven.apache.org/plugins/maven-assembly-plugin/howto.html
> >>>>
> >>>> I would like to see the "latest and greatest" docs on the main site.
> >>>> Yes, they'll be ahead of the released version, but not by much, and
> >>>> (hopefully) not for long.When the answer to a lot of "X doesn't work"
> >>>> questions is "It's fixed in the trunk, use a snapshot," it would be
> >>>> nice to have the snapshot docs available in a centralized place.
> >>>>
> >>>> This also makes it more fun to contribute to the documentation,
> >>>> because you get to see your work "in print" right away.
> >>>>
> >>>> Thanks for updating the main site. :)
> >>>>
> >>>> --
> >>>> Wendy
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>
> >>>>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Making the current web site suck less

That separates the core site, but there is still a two issues, and,
unfortunately, I'm not sure if there is an easy way to address it.

First, it is easy to publish specific versions of projects to different
directories.  But, the Maven documentation consists of a bunch of related
sites.  I think the main challenge is Maven plug-in sites and making sure
that all external links from one version of Maven link to the appropriate
version of another site.  Here's where it would be helpful to be able to
provide URL prefixes for outbound links.  Instead of linking to a specific
URL.

Second, (and correct me if I'm wrong), a Maven "version" is just a String.
There is no concept in a the POM of a Major vs. a Minor release.  So,
although there's seems to be agreement that it doesn't make much sense to
publish a new version of the site for each minor revision, that might not be
possible without adding that concept to Maven (unlikely) or just coding
/ref/2 for a 2.x version instead of using the logic.  So while the
replacement logic you have for core is good, it would create a new Maven
site for each minor version release.  Maybe that's OK?




On 3/8/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
>
> We already have that in place for the core, the site url is
> maven.apache.org/ref/${project.version}/
> see
> http://svn.apache.org/viewcvs.cgi/maven/components/trunk/pom.xml?rev=382904&view=markup
>
> We're missing the continuous integration part to auto deploy site
> everytime it's changed
>
> On 3/8/06, Tim O'Brien <[EMAIL PROTECTED]> wrote:
> > Having to choose between publishing the latest and greatest docs and
> only
> > the released version is a problem that Maven seems to have created for
> > itself.  Same issue comes up in other projects frequently - Commons has
> a
> > problem because some of the sites only publish on a release.  Latest and
> > greatest are almost never there.
> >
> > What about publishing the latest and greatest docs to another directory?
> > The Maven site gets pushed to a directory that has a version of a
> > label.  http://maven.apache.org/version/1.0
> > , http://maven.apache.org/version/2.0.2, and
> > http://maven.apache.org/version/trunk.  This way the Maven site can have
> a
> > nightly publish of the most current Maven site to Trunk every single
> day,
> > but still keep legacy docs around intact for people using older versions
> of
> > the product.  The "consumer" site can point to the latest release, and
> the
> > "developer" site can point to "trunk".  The Maven site plugin would need
> > some mechanism for adding a skin to a site to clearly identify it as
> > "Development".
> >
> >
> >
> > On 3/7/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> > >
> > > On 3/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
> > >
> > > > * I'm still a little torn on where plugin docs go. No hurry on this,
> but
> > >
> > > > something to ponder. We definitely need to make the references for
> those
> > > > integrate better. Site/skin inheritance will help
> > >
> > > No matter where they go, I think they need to be updated more often.
> > > Random example... the assembly plugin docs are wrong, and have been
> > > that way for months. (it's descriptorId, not
> > > maven.assembly.descriptorId.)
> > > * http://maven.apache.org/plugins/maven-assembly-plugin/howto.html
> > >
> > > I would like to see the "latest and greatest" docs on the main site.
> > > Yes, they'll be ahead of the released version, but not by much, and
> > > (hopefully) not for long.When the answer to a lot of "X doesn't work"
> > > questions is "It's fixed in the trunk, use a snapshot," it would be
> > > nice to have the snapshot docs available in a centralized place.
> > >
> > > This also makes it more fun to contribute to the documentation,
> > > because you get to see your work "in print" right away.
> > >
> > > Thanks for updating the main site. :)
> > >
> > > --
> > > Wendy
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Making the current web site suck less

Sorry, gmail confused me and I sent that last one by mistake John.

I don't think you'll be trading look and feel here.  I think you'd just be
doing something like making the site.xml for trunk point to a logo or banner
GIF that just added a "trunk", "draft", or "development" stamp.  If this was
done correctly, i think you could add it to the banner graphic in an
attractive way.

But, it brings up some questions:

1. Would every minor release get a separate site?  Or are we just talking
about major releases?  In other words, is there a 2.x site, or is there a
2.0.2 site?(My vote is for a 2.x site.)

2. What would the first page look like? What would Maven's home page look
like?  Would it even be managed by Maven?

Something to think about is maybe not having the initial Maven page be a
Maven site.  ASF sites in general seems to be more Developer focused than
user focused.  What if the initial Maven site were more like the front pages
of Mozilla or Rails.  An attractive logo, links to resources and materials,
an introduction.  The home page should be user focused, Maven developers are
a minority of the audience here.


On 3/8/06, John Casey <[EMAIL PROTECTED]> wrote:
>
> +1
>
> Maybe we can put a banner at the top of each page that marks the version
> it refers to or something. If we styled the reference doco as a manual,
> it could be part of the page layout that ties it together. I'd be
> willing to trade a bit of the look&feel for that sort of information, as
> it seems to me that it would reduce confusion.
>
> -john
>
> Tim O'Brien wrote:
> > Having to choose between publishing the latest and greatest docs and
> only
> > the released version is a problem that Maven seems to have created for
> > itself.  Same issue comes up in other projects frequently - Commons has
> a
> > problem because some of the sites only publish on a release.  Latest and
> > greatest are almost never there.
> >
> > What about publishing the latest and greatest docs to another directory?
> > The Maven site gets pushed to a directory that has a version of a
> > label.  http://maven.apache.org/version/1.0
> > , http://maven.apache.org/version/2.0.2, and
> > http://maven.apache.org/version/trunk.  This way the Maven site can have
> a
> > nightly publish of the most current Maven site to Trunk every single
> day,
> > but still keep legacy docs around intact for people using older versions
> of
> > the product.  The "consumer" site can point to the latest release, and
> the
> > "developer" site can point to "trunk".  The Maven site plugin would need
> > some mechanism for adding a skin to a site to clearly identify it as
> > "Development".
> >
> >
> >
> > On 3/7/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> >> On 3/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
> >>
> >>> * I'm still a little torn on where plugin docs go. No hurry on this,
> but
> >>> something to ponder. We definitely need to make the references for
> those
> >>> integrate better. Site/skin inheritance will help
> >> No matter where they go, I think they need to be updated more often.
> >> Random example... the assembly plugin docs are wrong, and have been
> >> that way for months. (it's descriptorId, not
> >> maven.assembly.descriptorId.)
> >> * http://maven.apache.org/plugins/maven-assembly-plugin/howto.html
> >>
> >> I would like to see the "latest and greatest" docs on the main site.
> >> Yes, they'll be ahead of the released version, but not by much, and
> >> (hopefully) not for long.When the answer to a lot of "X doesn't work"
> >> questions is "It's fixed in the trunk, use a snapshot," it would be
> >> nice to have the snapshot docs available in a centralized place.
> >>
> >> This also makes it more fun to contribute to the documentation,
> >> because you get to see your work "in print" right away.
> >>
> >> Thanks for updating the main site. :)
> >>
> >> --
> >> Wendy
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Making the current web site suck less

Right, I think confusion is a good word.  I approach Maven as an end-user
most often, and if I need to dive into a plugin source to finally figure out
how it works I do.  But, I've had the displeasure of

On 3/8/06, John Casey <[EMAIL PROTECTED]> wrote:
>
> +1
>
> Maybe we can put a banner at the top of each page that marks the version
> it refers to or something. If we styled the reference doco as a manual,
> it could be part of the page layout that ties it together. I'd be
> willing to trade a bit of the look&feel for that sort of information, as
> it seems to me that it would reduce confusion.
>
> -john
>
> Tim O'Brien wrote:
> > Having to choose between publishing the latest and greatest docs and
> only
> > the released version is a problem that Maven seems to have created for
> > itself.  Same issue comes up in other projects frequently - Commons has
> a
> > problem because some of the sites only publish on a release.  Latest and
> > greatest are almost never there.
> >
> > What about publishing the latest and greatest docs to another directory?
> > The Maven site gets pushed to a directory that has a version of a
> > label.  http://maven.apache.org/version/1.0
> > , http://maven.apache.org/version/2.0.2, and
> > http://maven.apache.org/version/trunk.  This way the Maven site can have
> a
> > nightly publish of the most current Maven site to Trunk every single
> day,
> > but still keep legacy docs around intact for people using older versions
> of
> > the product.  The "consumer" site can point to the latest release, and
> the
> > "developer" site can point to "trunk".  The Maven site plugin would need
> > some mechanism for adding a skin to a site to clearly identify it as
> > "Development".
> >
> >
> >
> > On 3/7/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> >> On 3/7/06, Brett Porter < [EMAIL PROTECTED]> wrote:
> >>
> >>> * I'm still a little torn on where plugin docs go. No hurry on this,
> but
> >>> something to ponder. We definitely need to make the references for
> those
> >>> integrate better. Site/skin inheritance will help
> >> No matter where they go, I think they need to be updated more often.
> >> Random example... the assembly plugin docs are wrong, and have been
> >> that way for months. (it's descriptorId, not
> >> maven.assembly.descriptorId.)
> >> * http://maven.apache.org/plugins/maven-assembly-plugin/howto.html
> >>
> >> I would like to see the "latest and greatest" docs on the main site.
> >> Yes, they'll be ahead of the released version, but not by much, and
> >> (hopefully) not for long.When the answer to a lot of "X doesn't work"
> >> questions is "It's fixed in the trunk, use a snapshot," it would be
> >> nice to have the snapshot docs available in a centralized place.
> >>
> >> This also makes it more fun to contribute to the documentation,
> >> because you get to see your work "in print" right away.
> >>
> >> Thanks for updating the main site. :)
> >>
> >> --
> >> Wendy
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Making the current web site suck less

Having to choose between publishing the latest and greatest docs and only
the released version is a problem that Maven seems to have created for
itself.  Same issue comes up in other projects frequently - Commons has a
problem because some of the sites only publish on a release.  Latest and
greatest are almost never there.

What about publishing the latest and greatest docs to another directory?
The Maven site gets pushed to a directory that has a version of a
label.  http://maven.apache.org/version/1.0
, http://maven.apache.org/version/2.0.2, and
http://maven.apache.org/version/trunk.  This way the Maven site can have a
nightly publish of the most current Maven site to Trunk every single day,
but still keep legacy docs around intact for people using older versions of
the product.  The "consumer" site can point to the latest release, and the
"developer" site can point to "trunk".  The Maven site plugin would need
some mechanism for adding a skin to a site to clearly identify it as
"Development".

On 3/7/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
>
> On 3/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> > * I'm still a little torn on where plugin docs go. No hurry on this, but
>
> > something to ponder. We definitely need to make the references for those
> > integrate better. Site/skin inheritance will help
>
> No matter where they go, I think they need to be updated more often.
> Random example... the assembly plugin docs are wrong, and have been
> that way for months. (it's descriptorId, not
> maven.assembly.descriptorId.)
> * http://maven.apache.org/plugins/maven-assembly-plugin/howto.html
>
> I would like to see the "latest and greatest" docs on the main site.
> Yes, they'll be ahead of the released version, but not by much, and
> (hopefully) not for long.When the answer to a lot of "X doesn't work"
> questions is "It's fixed in the trunk, use a snapshot," it would be
> nice to have the snapshot docs available in a centralized place.
>
> This also makes it more fun to contribute to the documentation,
> because you get to see your work "in print" right away.
>
> Thanks for updating the main site. :)
>
> --
> Wendy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: making docs and tests suck less

2006-03-07 Thread Tim O'Brien

Developers don't write great documentation.   Don't raise the bar so high
that people are discouraged from submitting doco-less patches.  Just create
a structure to address documentation deficiency.

1. Create a documentation posse - identify people who will focus solely on
doco, reduce the barriers for them to commit. Or, move documentation to an
external project with lower barriers to entry.

2. Consider a separate list - people removed from the development process
produce better documentation.

3. Add "Waiting for Documentation" as a stage in a customized JIRA
workflow.  Instead of creating separate issues for "Document what I just did
in the Site Plugin", give developers the opportunity to just mark something
as implemented but undocumented (otherwise know n as useless and invisible)


On 3/7/06, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> This is not too long, and important. Please read.
>
> I've just spent some time discussing this on users@, and felt it was
> time to bring it here to look at the practical steps going forward.
>
> Basically, I think we've all known for a long time that both need work.
> There was a big push around 2.0 but it fizzled out afterwards.
>
> I don't want to focus on what we are missing now - we can address that
> with what is already in place. I also want to put aside the
> documentation and testing efforts that are already under way as they've
> been taken into consideration. What I want to focus on is going forward
> - new work. I think we need to change the culture. I realise this is
> hard given the timing because there isn't a lot of new work going on -
> because we're all doing bug fixes, docs and testing! - but hopefully
> because of this it will be apparent why it is important to do them as we
> go.
>
> I've been trying to push for this for a long time, but haven't lived up
> to it myself which is one reason why it fails. I hate hypocrisy so can't
> really call other people on it (though I probably do anyway), and it
> requires everyone to buy in.
>
> So, I've committed r383963 which emphasises these requirements on patch
> contributions:
>
> * Whether it works and does what is intended.
> * Whether it fits the spirit of the project.
> * Whether it contains tests. It is expected that any patches relating to
> functionality will be accompanied by unit tests and/or integration
> tests. It is strongly desired (and will be requested) for bug fixes too,
> but will not be the basis for not applying it. At a bare minimum, the
> change should not decrease the amount of automated test coverage.
> * Whether it contains documentation. All new functionality needs to be
> documented for users, even if it is very rough for someone to expand on
> later. While rough is acceptable, incomplete is not.
>
> In the following, I'll discuss a technical veto. That's a -1 that means
> that the issue needs to be resolved before a release can occur. It
> doesn't mean someone rolls it back immediately (though a release manager
> may if it blocks a branch being released). It also doesn't mean anything
> negative about the committer in question, and it's important we keep it
> that way so that people aren't afraid to contribute or to call people on
> theese things.
>
> So my questions are, can we institute the following:
>
> * new functionality without automated test coverage can and should be
> technically vetoed. We can measure this with code coverage tools, and
> the measure will be that the % does not decline. It will actually break
> the build, being an automatic technical veto :)
>
> * new functionality without documentation can and should be technically
> vetoed. We can't really measure this with tools, so need to be vigilant
> on it ourselves. We also need to be understanding that docs may follow
> the code once it is finished, so we should use JIRA to track it (keep
> the original ticket open until documented, or create a new, blocking
> issue).
>
> * new code without javadoc/code documentation can be technically vetoed.
> I'm less tied to this one, though for public facing APIs I think Javadoc
> is imperative. It may be that we can use Checkstyle to enforce this to a
> degree.
>
> * code that doesn't meet current metrics can and should be technically
> vetoed. Again, we should set these up to fail the build, using
> Checkstyle, PMD and Clirr.
>
> Of course, I'll incorporate this into the dev process after some
> discussion.
>
> Thoughts?
>
> - Brett
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[jira] Commented: (MASSEMBLY-59) Patch to the assembly plug-in introduction APT document

2006-01-19 Thread Tim O'Brien (JIRA)

[ http://jira.codehaus.org/browse/MASSEMBLY-59?page=comments#action_56352 ] 

Tim O'Brien commented on MASSEMBLY-59:
--

So, apply the second patch, it updates the documentation for the assembly 
plug-in.  Let me know if the patch needs to change.  Tim

> Patch to the assembly plug-in introduction APT document
> ---
>
>  Key: MASSEMBLY-59
>  URL: http://jira.codehaus.org/browse/MASSEMBLY-59
>  Project: Maven 2.x Assembly Plugin
> Type: Improvement

> Versions: 2.0
> Reporter: Tim O'Brien
>  Fix For: 2.1
>  Attachments: assembly-intro-path.txt, patch.txt
>
>
> This patch adds some explanation to the assembly plugin intro.  It summarizes 
> the plugin for newbies and it also defines "assembly".  While the developers 
> of Maven might know what an "assembly" is, it needs to be defined for Maven 
> users who might not have a good idea of what the term means.
> This patch also beefs up the content a little, friendlier, complete 
> sentences, etc.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (MASSEMBLY-58) Documentation Patch to supply descriptions to assembly descriptor.mdo

[ http://jira.codehaus.org/browse/MASSEMBLY-58?page=comments#action_55682 ] 

Tim O'Brien commented on MASSEMBLY-58:
--

Ick.  Annoying.  I'm sorry, I just posted a better patch for #59.  Apologies.



> Documentation Patch to supply descriptions to assembly descriptor.mdo
> -
>
>  Key: MASSEMBLY-58
>  URL: http://jira.codehaus.org/browse/MASSEMBLY-58
>  Project: Maven 2.x Assembly Plugin
> Type: Task

>     Versions: 2.0
> Reporter: Tim O'Brien
>  Fix For: 2.0
>  Attachments: assembly-descriptor-patch.txt
>
>
> This patch adds a description element to everything in the assembly 
> descriptor.  Tried to be as verbose as possible.  Which the current 
> documentation, the only way to figure out what the valid values for format or 
> lineEnding are to take a look at the Mojo sources of the .mdo file from 
> Subversion.  This at least gives people some info to work with other than 
> "put your formats here".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (MASSEMBLY-59) Patch to the assembly plug-in introduction APT document

 [ http://jira.codehaus.org/browse/MASSEMBLY-59?page=all ]

Tim O'Brien updated MASSEMBLY-59:
-

Attachment: patch.txt

> Patch to the assembly plug-in introduction APT document
> ---
>
>  Key: MASSEMBLY-59
>  URL: http://jira.codehaus.org/browse/MASSEMBLY-59
>  Project: Maven 2.x Assembly Plugin
> Type: Improvement

> Versions: 2.0
> Reporter: Tim O'Brien
>  Fix For: 2.0
>  Attachments: assembly-intro-path.txt, patch.txt
>
>
> This patch adds some explanation to the assembly plugin intro.  It summarizes 
> the plugin for newbies and it also defines "assembly".  While the developers 
> of Maven might know what an "assembly" is, it needs to be defined for Maven 
> users who might not have a good idea of what the term means.
> This patch also beefs up the content a little, friendlier, complete 
> sentences, etc.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MASSEMBLY-59) Patch to the assembly plug-in introduction APT document

Patch to the assembly plug-in introduction APT document
---

 Key: MASSEMBLY-59
 URL: http://jira.codehaus.org/browse/MASSEMBLY-59
 Project: Maven 2.x Assembly Plugin
Type: Improvement

Versions: 2.0
Reporter: Tim O'Brien
 Fix For: 2.0
 Attachments: assembly-intro-path.txt

This patch adds some explanation to the assembly plugin intro.  It summarizes 
the plugin for newbies and it also defines "assembly".  While the developers of 
Maven might know what an "assembly" is, it needs to be defined for Maven users 
who might not have a good idea of what the term means.

This patch also beefs up the content a little, friendlier, complete sentences, 
etc.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MASSEMBLY-58) Documentation Patch to supply descriptions to assembly descriptor.mdo