problem finding maven-j2ee-plugin-1.1.jar
Hello, I am progressing with building maven from cvs, however I have hit a small problem. Maven is looking for: maven-j2ee-plugin-1.1.jar in the boot stratp, but there only seems to be snapshots available at: http://www.ibiblio.org/maven/maven/jars/ Is this correct? Thanks Neil -- I am taking part in Flora London Marathon 2003 on behalf of Breakthrough Breast Cancer Please click on a link below to support me! http://www.bmycharity.com/breakthrough/event.asp?eventid=BE3CD43A-0243-44BB-A564-40A0B38C075C or http://www.geocities.com/neilblue/index.html or http://www.geocities.com/neilblue/marathon.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs build error
Maven will expect that it is set all the time anyway, so best to just
drop it wherever it will get loaded for every shell.
Cheers,
Ben
Neil Blue wrote:
Doh! I moved terminal windows after setting it in the other one first :)
thanks
Neil
Ben Walding wrote:
Looks to me like MAVEN_HOME variable isn't set
See http://maven.apache.org/start/bootstrap.html
Neil Blue wrote:
Hello,
In an attempt to learn more about what maven is and how to use it, I
am trying to build the latest version.
I have got the source from cvs but I get the following error when I
run the bootstrap process.
[exec] ${env.MAVEN_HOME}/bin/maven: line 1: cd:
${env.MAVEN_HOME}/bin/..: No such file or directory
[exec] Exception in thread "main"
java.lang.NoClassDefFoundError: com/werken/forehead/Forehead
Please could anyone tell me what I may be doing wrong?
Cheers
Neil
-
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: cvs build error
Doh! I moved terminal windows after setting it in the other one first :)
thanks
Neil
Ben Walding wrote:
Looks to me like MAVEN_HOME variable isn't set
See http://maven.apache.org/start/bootstrap.html
Neil Blue wrote:
Hello,
In an attempt to learn more about what maven is and how to use it, I
am trying to build the latest version.
I have got the source from cvs but I get the following error when I
run the bootstrap process.
[exec] ${env.MAVEN_HOME}/bin/maven: line 1: cd:
${env.MAVEN_HOME}/bin/..: No such file or directory
[exec] Exception in thread "main"
java.lang.NoClassDefFoundError: com/werken/forehead/Forehead
Please could anyone tell me what I may be doing wrong?
Cheers
Neil
-
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]
--
I am taking part in Flora London Marathon 2003
on behalf of Breakthrough Breast Cancer
Please click on a link below to support me!
http://www.bmycharity.com/breakthrough/event.asp?eventid=BE3CD43A-0243-44BB-A564-40A0B38C075C
or
http://www.geocities.com/neilblue/index.html
or
http://www.geocities.com/neilblue/marathon.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Handling build dependencies smartly
OK, here's a good one for you clever Maven folk... I have several CVS projects that are inter-related and change often. Because they change so frequently we wanted to "short-circuit" the normal JAR publishing and instead compile our code and put JARs directly into our local repository. My first crack at "Maven-izing" them was to create a custom Jelly goal that would figure out which dependencies were local (i.e. one of my other CVS projects) and get it to build those dependency projects and deploy their JARs in the local repository prior to compilation. For example I have four projects: 'dog', 'cat', 'horse' and 'fish'. The dependencies look like this: fish is a base package with no dependencies horse depends on fish cat depends on horse and fish dog depends on horse, cat and fish. I want to be able to build any one of these projects at a given moment and have any out-of-date source from other dependent projects compile. With this dependency graph the Reactor processes the 'dog' projects like this: - Check that cat is up to date - Check that horse is up to date - Check that fish is up to date - compile fish and install in the local repo - Compile horse and install in the local repo - Compile cat and install in the local repo - Check that horse is up to date - horse checks that fish is up to date - fish jar in local repo is up to date with fish source - take no action - horse jar in local repo is up to date with horse source - take no action - Compile dog source and install jar in local repo Now this is a gross simplification of my real build system. You can imagine that projects that are referred to by lots of other projects (the 'fish' project in this case) are queried quite extensively causing my builds to be thorough (meaning no updated source is missed), but pretty slow. Now since I have a rather tangled dependency tree I have to recurse around quite a bit to get everything to build. I'm wondering if someone else hasn't already run into this and solved the problem. Any ideas besides re-structuring my projects? Thanks! --Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Navigation] Collapse functionnality
It isn't in b8 - have to use a CVS version to get that functionality. I'm not allowed to comment on b9 release on the grounds that I have no information. That's right no information at all. You can't make me say. [EMAIL PROTECTED] wrote: Hi all, Does anyone can tell me if the collapse functionnality that uses maven.apache.org is in beta9 version ?? I think it is not in beta8 as it does not work for me. If it is in beta9, is it close to release ? A+. Didier. - 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: cvs build error
Looks to me like MAVEN_HOME variable isn't set
See http://maven.apache.org/start/bootstrap.html
Neil Blue wrote:
Hello,
In an attempt to learn more about what maven is and how to use it, I
am trying to build the latest version.
I have got the source from cvs but I get the following error when I
run the bootstrap process.
[exec] ${env.MAVEN_HOME}/bin/maven: line 1: cd:
${env.MAVEN_HOME}/bin/..: No such file or directory
[exec] Exception in thread "main" java.lang.NoClassDefFoundError:
com/werken/forehead/Forehead
Please could anyone tell me what I may be doing wrong?
Cheers
Neil
-
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]
sorry
sorry about the double post there, mozilla is playing up at the moment. -- I am taking part in Flora London Marathon 2003 on behalf of Breakthrough Breast Cancer Please click on a link below to support me! http://www.bmycharity.com/breakthrough/event.asp?eventid=BE3CD43A-0243-44BB-A564-40A0B38C075C or http://www.geocities.com/neilblue/index.html or http://www.geocities.com/neilblue/marathon.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs build error
Hello,
In an attempt to learn more about what maven is and how to use it, I am
trying to build the latest version.
I have got the source from cvs but I get the following error when I run
the bootstrap process.
[exec] ${env.MAVEN_HOME}/bin/maven: line 1: cd:
${env.MAVEN_HOME}/bin/..: No such file or directory
[exec] Exception in thread "main" java.lang.NoClassDefFoundError:
com/werken/forehead/Forehead
Please could anyone tell me what I may be doing wrong?
Cheers
Neil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
build problems with cvs version
Hello,
In an attempt to find out more about what maven is and how to use it, I
am trying to build the latest cvs version, but I am running into trouble.
When I run the bootstrap.xml I get the following error:
[exec] ${env.MAVEN_HOME}/bin/maven: line 1: cd:
${env.MAVEN_HOME}/bin/..: No such file or directory
[exec] Exception in thread "main" java.lang.NoClassDefFoundError:
com/werken/forehead/Forehead
please could anyone tell me what I have done wrong?
Cheers
Neil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: null:49:15: null
I am receiving this error as well... I notice that changelog is not listed as a goal when I type 'maven --goals'. Is that a problem? -Original Message- From: Ben Walding [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 10:30 PM To: Maven Users List Subject: Re: null:49:15: null Take a look at maven.log and search for SCM. It can be enlightening. If it isn't, send it to the mailing list! Jabe Bloom wrote: > >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >Hello all, > >I have managed to get Maven to build my project. I had to remove all of the CVS reports however (changelog, activity. etc). When I try to use them I get: > >maven-changelog-plugin:report: >[echo] Generating the changelog report > >BUILD FAILED >null:49:15: null >Total time: 7 seconds > >I am using CVS over SSH. and I assume this has something to do with it. Can anyone help? > >Thanx > >- --jabe > >-BEGIN PGP SIGNATURE- >Version: PGP 8.0 > >iQA/AwUBPoqABnbQyyB4YIwbEQLWdACg3NFvYQtVkvpTjvbF1U06eI8MJ+EAniE4 >YpZX9QdddbIp2bLLU1hZrviu >=jVSo >-END PGP SIGNATURE- > > > > > >- >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: werkz or jeez documetation
Thanks Colin, What I was looking for was some information on what goals are and how to write them. As far as I understand, in order to add project specific functionality to maven I need to add goals in a similar way as I added targets in ant. Cheers Neil Colin Sampaleanu wrote: You can find some werkz documentation here: http://werkz.werken.com/ although you normally shouldn't have to understand werkz that much if all you want to do is use maven (as opposed to hacking it). Neil Blue wrote: Hello, I am trying to get started with Maven, but I can't find any documentation on werkz or jeez. Please can anyone tell me if any is available. Thanks Neil - 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] -- I am taking part in Flora London Marathon 2003 on behalf of Breakthrough Breast Cancer Please click on a link below to support me! http://www.bmycharity.com/breakthrough/event.asp?eventid=BE3CD43A-0243-44BB-A564-40A0B38C075C or http://www.geocities.com/neilblue/index.html or http://www.geocities.com/neilblue/marathon.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: werkz or jeez documetation
You can find some werkz documentation here: http://werkz.werken.com/ although you normally shouldn't have to understand werkz that much if all you want to do is use maven (as opposed to hacking it). Neil Blue wrote: Hello, I am trying to get started with Maven, but I can't find any documentation on werkz or jeez. Please can anyone tell me if any is available. Thanks Neil - 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: Documentation, CVS, and Maven
Could you please post the URL of that DTD? Sure... http://www.oasis-open.org/docbook/xml/simple/1.0CR2/sdocbook.dtd";> Regards Jose - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Plugins] Maven and PHP
Our PHP folks felt in love with what we could do for Java with Maven. So we will do Maven plugins to invoke PHPDoc or PHPDocumentor, a source xref like and unit tests. I would like to know if someone already started such a work ?? Sounds like a worthy effort. I haven't come across any such work as yet, and was considering writing something like it at some point. I'd be interested in helping out or at least seeing what you come up with. Gabe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
werkz or jeez documetation
Hello, I am trying to get started with Maven, but I can't find any documentation on werkz or jeez. Please can anyone tell me if any is available. Thanks Neil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Plugins] Maven and PHP
Hi all, Maybe this seems stupid for some but le me ask this question. We are in the process to homogenize our PHP and Java free software sites. Our PHP folks felt in love with what we could do for Java with Maven. So we will do Maven plugins to invoke PHPDoc or PHPDocumentor, a source xref like and unit tests. I would like to know if someone already started such a work ?? Thanks for your help. Maven rocks! A+. Didier. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Navigation] Collapse functionnality
Hi all, Does anyone can tell me if the collapse functionnality that uses maven.apache.org is in beta9 version ?? I think it is not in beta8 as it does not work for me. If it is in beta9, is it close to release ? A+. Didier. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why no multiple locations of sources? ( was Re: inter-project dependencies for the Eclipse plugin )
> -Original Message-
> From: Rafal Krzewski [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 04, 2003 1:37 PM
> To: Maven Users List
> Subject: Re: Why no multiple locations of sources? ( was Re:
> inter-project dependencies for the Eclipse plugin )
>
>
> Brian Ewins wrote:
>
> > The 'official' way to deal with code generators is to chuck their output
> > into the 'global list of sources'. Are we suggesting global variables
> > are a good thing? Also, this mechanism only deals with .java files -
> > there is no equivalent fat pipe for documentation etc AFAIK. (BTW this
> > can also be seen as inverting the problem in the previous para - now B
> > knows how A works and is pushing its data at A)
>
> Instead of 'global' think about 'valid during a session'. Suppose you
> have Maven embedded in an IDE, with your project loaded and all goal
> dependency information in place. You click a toolbar icon that invokes
> a pre-configured goal on the current project. This starts a new Maven
> session for your project. Maven uses the loaded goal dependency
> information to build of a graph of goals that need to be attained to
> achieve the goal you requested. Then the order in which the goals will
> be attained is computed (with the possible outcome of cirular dependency
> error message). At this point we have a pipeline formed. The goals that
> run at the beginning of the pipeline are usually producers of ... well,
> let's call'em 'interim artifacts'. For example, 'java:init' goal would
> check for existence of ${basedir}/src/java, and if it's present, would
> create a FileSet interim artifact named 'java.source.set' and pass it
> down the pipeline. How would that be done? The object would be injected
> into the Maven session context. How further elements of the pipeline
> know where to look for that interim artifact? The key in the session
> context is a part of public API of the plugin that produces it.
>
> I think that most, if not all of the infrastructure needed to implement
> that kind of pipelining operation is already present in Maven. All we
> need is defining that this is how things should be done, and documenting
> the contracts of all plugins -- what 'interim artifacts' they produce
> and consume.
>
Do you think that such things should be legal then?
I have in my POM:
my_stupid_question
1.0
..
my_stupid_question
my_stupid_question<
${pom.version}
true
war
..
I type "maven ear" and war pluging is invoked first in order to deliver
needed artifact:
my_stupid_question-1.0.war
So I mean a sort of "inner" reactor.
Such things would be nice but f... complex.
greets
Michal
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Documentation, CVS, and Maven
On Fri, 2003-04-04 at 14:21, Jose Gonzalez Gomez wrote: > The simple docbook is just a DTD based on docbook with a lot of > trimmed tags for use in simple documentation. Maven provides limited > support for this kind of docbook. Could you please post the URL of that DTD? > What tools are you using to author docbook documentation? jEdit http://www.jedit.org/, with XML plugins installed. I have put one of our docbook files to maven and it worked more or less: * Easy tables worked, complex tables failed. * , worked fine * Titles of inside did not show up in a different style/code, possibly a CSS problem. * and images/inlinegraphic failed * links () worked well * failed * failed * and failed * FAQ () failed Seems that the docbook-plugin fraction needs some programming support... ;-) I was actually impressed that it worked! -- Martin Skopp Riege Software International GmbH Support: mailto:[EMAIL PROTECTED], Information: http://www.riege.com This email is intended to be viewed with a nonproportional font. Public Key on http://www.keyserver.net, Key-ID: 3D4027B5 Fingerprint: 1970 C78D 9A1D 99FA 5CE4 5C0D 29E6 6A95 3D40 27B5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Documentation, CVS, and Maven
Jose Gonzalez Gomez <[EMAIL PROTECTED]> writes: > Another question... is there any reason for mapping section and > subsection to h3 and h4 instead of h1 and h2? Maven uses the style.tigris.org CSS stylesheets which were created by Todd Fahrner and co. This stylesheet defines h2 even though we don't use it over in Maven-land. h2 sections are rendered as large black text on a white background. I.e. does not have the reverse video look of h3 and h4. As a result, when I made the mapping of the style CSS to Maven's xdoc, I opted to not use h2 because I felt it didn't look as good. You can provide your own stylesheet and override the one provided by Maven if you want more control. In addition, you can also just drop HTML files in the xdocs directory and they'll be copied over as is to the final documentation directory (actually, any non-.xml file is treated in this manner). Thus, you could write your own docs in HTML and use the Maven stylesheet and have access to all of the header styles. The only drawback to the above approach is that your documents will not be automatically integrated into the site. I.e. you'll have to add the nav bar to the page, the banner, etc ... At some point, we need to re-evaluate how we generate the site documentation to be more flexible at the integration level rather than force everyone to use the inflexible xdoc format. xdoc is a great format for simple things like the reports Maven generates and simple documentation, but forcing everything to xdoc for site integration is not a good thing. I'm not proposing to get rid of xdoc, but rather find a different way of integrating the site nav bar and banner to any type of user-supplied docs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Documentation, CVS, and Maven
Martin, The simple docbook is just a DTD based on docbook with a lot of trimmed tags for use in simple documentation. Maven provides limited support for this kind of docbook. What tools are you using to author docbook documentation? Regards Jose Martin Skopp wrote: On Fri, 2003-04-04 at 13:22, Jose Gonzalez Gomez wrote: * docbook. Based on standards, lot of tools to output in a variety of formats, with limited support in maven for the simple version. Don't know the diff betw. docbook full+simple, but we use docbook here for such docs since we sometimes need to integrate images, tables, appendixes, indexes, table of content automatically etc. and sometimes we need to deliver PDF. DocBook does the job well - we use just a few tags but * it has more options than xdoc * it has less layout than html which makes it ideal for us here. Haven't looked into mavens docbook support, but that could be a point against it... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why no multiple locations of sources? ( was Re: inter-projectdependencies for the Eclipse plugin )
michal.maczka wrote: Yeap you right. And I guess that I am right too ... becouse I believe that, we alredy have a workflow of goals in Maven. Yup, I agree. so basically B should not update the path. and in A (when needed)you should use something like: B:getUpatedOutputPath() which will "black-box" what B does to the output Well, yes and no. This means that A /explicitly/ knows that it depends on B (which is where we are at now). I mean something more like, A does not know it depends on B, the framework does. The framework takes care of adding the output of B to the input of A. This might sound like I'm suggesting a central file which describes the dependency of A on B - I'm not, I see the plugin.jelly as declaring two things - the processes for each goal, and the default connections between goals. So you can override the inputs, outputs (ie dependencies) without overriding the goal processing - this is pretty much what pregoal and postgoals do now. This is partly my answer to Rafal as well - I mention 'the framework' above and mean pretty much the same as you do when talking about 'the session'. The difference is you're describing a passive session manipulated by the goals (roughly speaking - when they lookup/store data), I'm describing passive goals manipulated by the framework. I totally agree with both of you that most of this is already there. Anyway - if Jason had a penny for every time someone argued for changing how maven workshe'd say, "here's your penny back, give me a patch instead". I'll shut up. -Baz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Documentation, CVS, and Maven
On Fri, 2003-04-04 at 13:22, Jose Gonzalez Gomez wrote: > * docbook. Based on standards, lot of tools to output in a variety > of formats, with limited support in maven for the simple version. Don't know the diff betw. docbook full+simple, but we use docbook here for such docs since we sometimes need to integrate images, tables, appendixes, indexes, table of content automatically etc. and sometimes we need to deliver PDF. DocBook does the job well - we use just a few tags but * it has more options than xdoc * it has less layout than html which makes it ideal for us here. Haven't looked into mavens docbook support, but that could be a point against it... -- Martin Skopp Riege Software International GmbH Support: mailto:[EMAIL PROTECTED], Information: http://www.riege.com This email is intended to be viewed with a nonproportional font. Public Key on http://www.keyserver.net, Key-ID: 3D4027B5 Fingerprint: 1970 C78D 9A1D 99FA 5CE4 5C0D 29E6 6A95 3D40 27B5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why no multiple locations of sources? ( was Re: inter-projectdependencies for the Eclipse plugin )
Brian Ewins wrote:
> The 'official' way to deal with code generators is to chuck their output
> into the 'global list of sources'. Are we suggesting global variables
> are a good thing? Also, this mechanism only deals with .java files -
> there is no equivalent fat pipe for documentation etc AFAIK. (BTW this
> can also be seen as inverting the problem in the previous para - now B
> knows how A works and is pushing its data at A)
Instead of 'global' think about 'valid during a session'. Suppose you
have Maven embedded in an IDE, with your project loaded and all goal
dependency information in place. You click a toolbar icon that invokes
a pre-configured goal on the current project. This starts a new Maven
session for your project. Maven uses the loaded goal dependency
information to build of a graph of goals that need to be attained to
achieve the goal you requested. Then the order in which the goals will
be attained is computed (with the possible outcome of cirular dependency
error message). At this point we have a pipeline formed. The goals that
run at the beginning of the pipeline are usually producers of ... well,
let's call'em 'interim artifacts'. For example, 'java:init' goal would
check for existence of ${basedir}/src/java, and if it's present, would
create a FileSet interim artifact named 'java.source.set' and pass it
down the pipeline. How would that be done? The object would be injected
into the Maven session context. How further elements of the pipeline
know where to look for that interim artifact? The key in the session
context is a part of public API of the plugin that produces it.
I think that most, if not all of the infrastructure needed to implement
that kind of pipelining operation is already present in Maven. All we
need is defining that this is how things should be done, and documenting
the contracts of all plugins -- what 'interim artifacts' they produce
and consume.
> There also seems to be a clash with the Inversion of Control
> principle[1] here: either A is pulling data from B, or B is pushing data
> at A (or equivalently, A pulls from a global, B pushes to a global). It
> should be the framework telling A what files to process, which happens
> to include the output of B because the current 'flow' declares that
> dependency.
I'm no expert at the theory behind frameworks, but what I've described
above seems reasonably well strucured to me. A and B need to agree on
a contract (names of the passed artifacts) and the framework does the
storage/lookup for them.
R.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Documentation, CVS, and Maven
Lately I've been thinking about documentation, cvs and maven, and I'd like to hear opinions from you. Here's the scenario: * I want to document a software project using a subset of the artifacts provided in the unified process, you know, capture requirements using use cases, analysis and design using UML, etc * I want this documentation to be easily integrated in cvs, so I don't want them to be binary formats * I want this documentation to be easily integrated in maven. So the candidates are html, xdoc and docbook (full or simple). Do you know any other alternative I should take into account? Thougths about them: * html. A good option, as long as all the people creating documentation can share a stylesheet, and we can find a program to edit the files that doesn't put garbage in the html code * xdoc. The preferred documentation format for maven. * docbook. Based on standards, lot of tools to output in a variety of formats, with limited support in maven for the simple version. Questions about xdoc: I have the impression, after taking a look at the maven source, that the main reason for adopting xdoc is simplicity and possibility of processing it with xml stylesheets to add the format and the banner and menu typical of maven projects. I find xdoc too simple for my needs. For example I have some documents where I have more than two levels of headers, while xdoc only support section and subsection (two levels). Maven style is applied to headers, tables, and source code basically, am I right? So couldn't be the source for maven documentation a plain xhtml with h1 and h2 instead of section and subsection? This way maven wouldn't impose a restriction on levels or format of the document, and xml stylesheet for site generation could still be used. Maven could still provide a html stylesheet defining styles for h1 through h6, tables and pre. Another question... is there any reason for mapping section and subsection to h3 and h4 instead of h1 and h2? Regards Jose - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why no multiple locations of sources? ( was Re: inter-project dependencies for the Eclipse plugin )
> -Original Message- > From: Brian Ewins [mailto:[EMAIL PROTECTED] > Sent: Friday, April 04, 2003 11:36 AM > To: Maven Users List > Subject: Re: Why no multiple locations of sources? ( was Re: > inter-project dependencies for the Eclipse plugin ) > > > Michal Maczka wrote: > > > > But there are even worst cases when pipelining is useless. > > > > E.g. consider following use case > > > > 1) First run of Maven : > > I start XDoclet it creates some classes and updates java path > for the rest > > of plugins (e.g. javac) > > > > 2) Second/Third etc.. run of Maven > > I don't want to regenerate one more time XDoclet stuff .. but I > want to have > > the source previously generated visible in my path. > > That would be handled exactly as it is now, I'm not sure I see your > point? i.e., each plugin in a pipeline invokes its dependents, which end > up doing nothing because their output already exists? The pipeline is > not passing the file contents (I guess this might be what you're > thinking?), only data structures (eg FileSets) which allow you to get > access to the files. > Yeap you right. And I guess that I am right too ... becouse I believe that, we alredy have a workflow of goals in Maven. The problem I see is that Maven is in a big part implemented in scripting language. This is hugh adavatange for a lot of things, but this is also is a cause of many weeknesess of Maven. You want to have goals which are formaly declaring what thay return/modify etc. I think that such things are getting too be to complicated to be really maintanable. > > > > The only way it can be handled properly is to make it on plugin level. > > So plugins like XDoclet should be equipped with some hooks for > making such > > things > > and hide some details into which directories they will put > their sources. > > All I am suggesting is that saying 'goal A depends on goal B' generally > means 'goal A depends on the /output of/ goal B'. At the moment, B knows > where its output went, but A is just guessing. So we require A to have > knowledge of how B works in order to get hold of B's data. That hides > /less/ about which directories B uses than my suggestion. > so basically B should not update the path. and in A (when needed)you should use something like: B:getUpatedOutputPath() which will "black-box" what B does to the output > The 'official' way to deal with code generators is to chuck their output > into the 'global list of sources'. Are we suggesting global variables > are a good thing? >Also, this mechanism only deals with .java files - > there is no equivalent fat pipe for documentation etc AFAIK. (BTW this > can also be seen as inverting the problem in the previous para - now B > knows how A works and is pushing its data at A) > There are always some global variables. E.g worflow information are globals I think that you are just speaking about making the same sort of things in a diferent way - e.g through more formal set of APIs. But I think that those things really are alredy in Maven! My idea of reorganizing the sources' meta information was aiming at exactly the same goal: unification of the workflow. It is usually easier to work with one common abstraction then with couple simmilar things (like now we have 4 types of different sources, javaclass path and probably other things) > There also seems to be a clash with the Inversion of Control > principle[1] here: either A is pulling data from B, or B is pushing data > at A (or equivalently, A pulls from a global, B pushes to a global). It > should be the framework telling A what files to process, which happens > to include the output of B because the current 'flow' declares that > dependency. > > To some extent I'm echoing Bob McWhirter here, and suggesting that > "everything is workflow"[2] - including maven. > > -Baz > Cool sentence! regards (also to Bob!) Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why no multiple locations of sources? ( was Re: inter-projectdependencies for the Eclipse plugin )
Michal Maczka wrote: But there are even worst cases when pipelining is useless. E.g. consider following use case 1) First run of Maven : I start XDoclet it creates some classes and updates java path for the rest of plugins (e.g. javac) 2) Second/Third etc.. run of Maven I don't want to regenerate one more time XDoclet stuff .. but I want to have the source previously generated visible in my path. That would be handled exactly as it is now, I'm not sure I see your point? i.e., each plugin in a pipeline invokes its dependents, which end up doing nothing because their output already exists? The pipeline is not passing the file contents (I guess this might be what you're thinking?), only data structures (eg FileSets) which allow you to get access to the files. The only way it can be handled properly is to make it on plugin level. So plugins like XDoclet should be equipped with some hooks for making such things and hide some details into which directories they will put their sources. All I am suggesting is that saying 'goal A depends on goal B' generally means 'goal A depends on the /output of/ goal B'. At the moment, B knows where its output went, but A is just guessing. So we require A to have knowledge of how B works in order to get hold of B's data. That hides /less/ about which directories B uses than my suggestion. The 'official' way to deal with code generators is to chuck their output into the 'global list of sources'. Are we suggesting global variables are a good thing? Also, this mechanism only deals with .java files - there is no equivalent fat pipe for documentation etc AFAIK. (BTW this can also be seen as inverting the problem in the previous para - now B knows how A works and is pushing its data at A) There also seems to be a clash with the Inversion of Control principle[1] here: either A is pulling data from B, or B is pushing data at A (or equivalently, A pulls from a global, B pushes to a global). It should be the framework telling A what files to process, which happens to include the output of B because the current 'flow' declares that dependency. To some extent I'm echoing Bob McWhirter here, and suggesting that "everything is workflow"[2] - including maven. -Baz [1] http://avalon.apache.org/framework/guide-patterns-ioc.html [2] http://blogs.werken.com/people/bob/archives/000160.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
war files and applets?
I need to make an applet available from a webapp (so it can't be
beneath WEB-INF). I can't figure out a clean way to do it using the
war plugin. To make it work for both war:war and war:webapp, I ended
up copying the applet's class file to ${maven.src.dir}/webapp in a
war:init preGoal, but that's kinda gross to muck up the src branch,
isn't it?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: reactor templates and project ordering
On Thu, 2003-04-03 at 21:37, Mark R. Diggory wrote: > I'm trying to enforce an ordering on the POM's used in "templating" of > the navigation bar. This specific approach is built upon the db-site > demo at apache > > http://db.apache.org/ I was trying to do exactly the same thing yesterday, but haven't made much progress. It should be sufficient to sort $reactorProjects, ordering by each projects name property, or by some other property applied to each project, but I haven't worked out how to do that in either jelly or velocity... -Mark. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
