It uploads the site documentation using the site:deploy target, the same as any Maven site deploy. If you have generated source listings, those will be uploaded.
Yes, it is separate from source commits. That's standard. Apparently the Maven developers rather wish that site generation hadn't been included in the POM, but since it is, they're not removing it. To them, the source and documentation are completely separate. You'd like documentation to be generated, released, and tagged simultaneously with a release:prepare target? That's probably doable with a plugin. The plugin may not currently exist, however. -K On Oct 26, 2010, at 2:14 PM, Kenneth McDonald wrote: > Kathyrn > > I greatly appreciate the feedback. I've looked at using your system but > (correct me if I'm wrong), it doesn't maintain simulteneity of source and > docs. In other words, I have to upload the docs seperately from the source? > > This is important to me. I regard a release as a juxtaposition of properly > correlated source and docs. That's what I'm aiming at. > > > Thanks, > Ken > > On Oct 25, 2010, at 9:54 AM, Kathryn Huxtable wrote: > >> I have a plugin (org.kathrynhuxtable.maven.wagon.wagon-gitsite) that uploads >> your site documentation to github. It hasn't been verified to work with >> Maven 3 yet. The docs are at http://khuxtable.github.com/wagon-gitsite/, if >> you're interested. >> >> -K >> >> On Oct 23, 2010, at 4:15 PM, Kenneth McDonald wrote: >> >>> First, note that I did tag this as repetitive: You don't need to be reading >>> it if you don't want to be rehashing recent issues. >>> >>> <beginning of rant> >>> However, I want to give a concrete example of just why I dislike maven (and >>> all other XML solutions) so far. I am trying to do what I think should be a >>> reasonably easy thing to do--upload onto github (or something similar) >>> current documentation for the project I have hosted on github. So far the >>> best solution I've seen involves making another branch of my project and >>> including the documentation there. This is fundamentally wrong (the docs >>> are _part_ of the project), but I'm not blaming maven here. It's probably a >>> git thing I don't yet understand. >>> >>> However, once we get past that, the pom files necessary to upload the docs >>> are daunting, to say the least. >>> >>> Even more than that, though, the pom files are fundamentally unreadable. Oh >>> I don't mean you can't puzzle through them in an afternoon or so if you >>> have the time. Of course you can. But (and I think this deserves to be in >>> caps), XML FILES ARE FUNDAMENTALLY WRITTEN WITH THE EASE OF THE COMPUTER, >>> NOT THE HUMAN, AT HAND. I mean, that's just a simple statement of fact, not >>> an opinion. I just don't get how people can be so oblivious to this. Would >>> you really want to program in a dialect of XML? How many people do you know >>> who do so? Do you really think that all of the work that has been done on >>> parsers and compilers over the last thirty years has been in vain because, >>> realistically, humans should just program in XML? I open up an XML file, >>> and unless I'm quite familiar with the "dialect" of XML in use, simply >>> understanding the structure takes at least half an hour. THEN I need to >>> understand the content. There is too much redundancy, too few structural >>> cues to indicate meaning, too few keywords (yes, they're important!), too >>> much nesting, too little ordering in that nesting...I could go on. >>> >>> Of course people will dispute this. They're wrong. If they were right, we >>> would have had something like XML for all our programming needs twenty >>> years ago. Sorry people, you're just plain wrong. >>> >>> Now, what are the claims made for (or implied by) maven: >>> 1) That it is declaratively, not procedurally, based. >>> 1-a) Whoop-te-do. So are makefiles. Sure, they've accumulated a lot of crud >>> over the years (and a rewrite _like_ maven was probably necessary to clear >>> this out), but makefiles are, at their core pretty simple. You have a build >>> target. It depends on other build targets. You build those other targets, >>> and then you build what you're working on. Is this revolutionary? >>> 1-b) I've mentioned this before, but Prolog has been doing declarative >>> programming for years. Without obscure semantics. With lots of extra >>> expressive power, like list manipulations, arithmetic, etc. etc. With an >>> understandable syntax. With lots of extra libraries. Would it have really >>> been so bad to base a declarative codebase on Prolog, a mature, proven >>> technology? >>> 2) XML is standards based. >>> 2-a) Sure. Like Prolog. Or even (choose a variant of) LISP, for god's sake. >>> All of these "languages" are standards compliant until they're not. XML >>> will suffer the same fate. >>> 3) XML makes it easy to interoperate with other systems. >>> 3-b) This is the biggest piece of bullshit I've ever heard. It totally >>> confuses a data format (let's say, "ASCII") with a data standard (let's >>> say, "CORBA", though that's stretching things.) XML is a data format, pure >>> and simple. No matter how hard it tries (remember DTDs?), it cannot attain >>> the status of a data standard, because the needs of data standards evolve >>> and continually require new things. So a data format such as ASCII, can >>> have quite a long life--but trying to do the same thing to a data standard >>> is a pointless exercise, and will not hold. >>> 4) Apache is wedded to XML. >>> 4-a) This one really pisses me off because I suspect it's absolutely true. >>> I believe that Apache has a large number of very talented programmers, and >>> I believe they are, in large respect, wasting their time because they have >>> come to worship XML. I don't get it. There are things for which XML is >>> appropriate. There are also so many things for which it's not, that why >>> would you spend all of your time there? I don't have an answer. >>> >>> Anyway >>> </end of rant> >>> Ken >>> --------------------------------------------------------------------- >>> 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]
