jar dying on test:test
all of a sudden my projects which use jar:install are dying on attainGoal Goal [test:test] has no action definition. I have not changed anything at all in my maven setup, not one thing. Has maven downloaded some crap while I wasn't watching, that doesn't work? Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven SCM has landed! :-)
http://blogs.codehaus.org/projects/maven/archives/000271.html -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] The Maven Logo
What am I missing? This is sounding like Forrest. Why duplicate, why not
collaborate?
regards
Adam
- Original Message -
From: Mark R. Diggory [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Sunday, November 30, 2003 8:58 AM
Subject: Re: [VOTE] The Maven Logo
Paul Libbrecht wrote:
An alternative would be to actually consider a complete notion of skin.
And this is probably going to happen very soon I think... xdoc
implementors, hasn't it already been thought about ? With the cool
download mechanism of maven, it really looks to be something we could
easily do.
Ahh, a clearing after the storm! I suspect this would be as simple as a
modification to a css style sheet, as complex as an alternate
${maven.xdoc.jsl}, and in between, alternate settings for just about any
other maven.xdoc property.
http://maven.apache.org/reference/plugins/xdoc/properties.html
From the discussions on the Jakarta Commons list it would be evident
that such a skin would be beneficial in terms of site consistency in
Jakarta and other places.
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
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] The Maven Logo
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: 30 November 2003 20:41
To: Maven Users List
Subject: Re: [VOTE] The Maven Logo
On Sun, 2003-11-30 at 11:20, Adam R. B. Jack wrote:
What am I missing? This is sounding like Forrest. Why duplicate, why
not
collaborate?
Forrest is massive overkill for most sites, additionally it barely
worked when we started Maven and as far as I know is still rather
unwieldly in terms of size and ease of use.
I don't think anyone will ever convince me that Forrest is a better
solution than simple Jelly+CSS.
In any case, Maven has an open architecture and Forrest has a Maven
plugin. That's cool. Users can choose to use whichever they prefer.
-Vincent
regards
Adam
- Original Message -
From: Mark R. Diggory [EMAIL PROTECTED]
To: Maven Users List [EMAIL PROTECTED]
Sent: Sunday, November 30, 2003 8:58 AM
Subject: Re: [VOTE] The Maven Logo
Paul Libbrecht wrote:
An alternative would be to actually consider a complete notion
of
skin.
And this is probably going to happen very soon I think... xdoc
implementors, hasn't it already been thought about ? With the
cool
download mechanism of maven, it really looks to be something we
could
easily do.
Ahh, a clearing after the storm! I suspect this would be as simple
as
a
modification to a css style sheet, as complex as an alternate
${maven.xdoc.jsl}, and in between, alternate settings for just
about
any
other maven.xdoc property.
http://maven.apache.org/reference/plugins/xdoc/properties.html
From the discussions on the Jakarta Commons list it would be
evident
that such a skin would be beneficial in terms of site
consistency in
Jakarta and other places.
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
-
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]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
-
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] The Maven Logo
Vincent Massol wrote: In any case, Maven has an open architecture and Forrest has a Maven plugin. That's cool. Users can choose to use whichever they prefer. Mmmh, is that not a Forrest plugin for maven ? http://marc.theaimsgroup.com/?l=turbine-maven-devm=105438035409490w=2 I am a bit unclear on it all. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] The Maven Logo
-Original Message- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: 30 November 2003 21:14 To: Maven Users List Subject: Re: [VOTE] The Maven Logo Vincent Massol wrote: In any case, Maven has an open architecture and Forrest has a Maven plugin. That's cool. Users can choose to use whichever they prefer. Mmmh, is that not a Forrest plugin for maven ? http://marc.theaimsgroup.com/?l=turbine-maven-devm=105438035409490w=2 So, you're confirming what I said? I am a bit unclear on it all. Not sure what you mean. -Vincent Paul - 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] The Maven Logo
On Sun, 2003-11-30 at 14:59, Vincent Massol wrote: -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: 30 November 2003 20:41 To: Maven Users List Subject: Re: [VOTE] The Maven Logo On Sun, 2003-11-30 at 11:20, Adam R. B. Jack wrote: What am I missing? This is sounding like Forrest. Why duplicate, why not collaborate? Forrest is massive overkill for most sites, additionally it barely worked when we started Maven and as far as I know is still rather unwieldly in terms of size and ease of use. I don't think anyone will ever convince me that Forrest is a better solution than simple Jelly+CSS. In any case, Maven has an open architecture and Forrest has a Maven plugin. That's cool. Users can choose to use whichever they prefer. Exactly. And no one to my knowledge ever got it working or continued to work on it. Forrest will probably never be the default rendering mechanism but no one is stopping anyone from making a plugin. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] The Maven Logo
On Sun, 2003-11-30 at 14:54, Paul Libbrecht wrote: Jason van Zyl wrote: On Sun, 2003-11-30 at 11:20, Adam R. B. Jack wrote: What am I missing? This is sounding like Forrest. Why duplicate, why not collaborate? Forrest is massive overkill for most sites, additionally it barely worked when we started Maven and as far as I know is still rather unwieldly in terms of size and ease of use. I don't think anyone will ever convince me that Forrest is a better solution than simple Jelly+CSS. Jason, Are you actually confirming you believe it's an overkill even ofr jakarta commons ? Absolutely it's overkill. Additionally if I ever made a live site tool for Maven I would personally never use anything Cocoon-based. That's my preference and as such carries some weight around here. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] The Maven Logo
On Sun, 2003-11-30 at 16:00, Vincent Massol wrote: I'd like to see the report registration mechanism untied from the site plugin so that any plugin wishing to use it can. Once this is done, all plugins web site generation plugins will be equal. It's been suggested before, I think when Berin raised issues at not being able to use Forrest. But the onus is on people who want to use Forrest with Maven to do the work because all the Maven devs are happy using Jelly+CSS and that combination works so it's not really a high priority for most of the Maven developers. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Help get your plugin patches/fixes applied!
Hi, Anyone who wants to get their fixes or patches applied expediently I make the following offer. If you have patches/fixes you want applied and they are in JIRA and globbed in with core issues then 1. Send me an email telling me which plugin you're interested and I will create a project for that plugin. 2. Then you move whatever issues from the core to that plugin project and provided it comes with a changes.xml diff I will apply immediately. I aim to cleanup the core JIRA project and get all the plugin related issues flushed out into separate plugin projects but help is certainly appreciated. I figured this offer might stimulate some more activity. The patches for the hibernate and genapp plugins were done just now as it is so much easier to deal with a plugin on its own. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Torque Plugin
Hi Martin, The torque plugin is now part of Torque, yes? I just wanted to check as I want to nuke the issues related to the torque plugin in Maven's JIRA install. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven:site and Forrest (was Re: [VOTE] The Maven Logo)
Jason van Zyl wrote: Are you actually confirming you believe it's an overkill even ofr jakarta commons ? Absolutely it's overkill. Additionally if I ever made a live site tool for Maven I would personally never use anything Cocoon-based. That's my preference and as such carries some weight around here. I fear I'm sharing your view but this view on my side has always been made as an ignorant... i.e. Cocoon has always seemed to be too big for our needs, and little talks I had seemed to make it too hard to work with. It would be nice if persons that both know jelly, xdoc, and maven, as well as Cocoon do comment on a comparison... Thanks. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] The Maven Logo
Jason van Zyl wrote: On Sun, 2003-11-30 at 16:00, Vincent Massol wrote: I'd like to see the report registration mechanism untied from the site plugin so that any plugin wishing to use it can. Once this is done, all plugins web site generation plugins will be equal. It's been suggested before, I think when Berin raised issues at not being able to use Forrest. But the onus is on people who want to use Forrest with Maven to do the work because all the Maven devs are happy using Jelly+CSS and that combination works so it's not really a high priority for most of the Maven developers. What does any of this have to do with ... [VOTE] The Maven Logo...? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
xdoclet plugin and multiple java source directories
I am pretty sure this one is for the xdoclet
developers but I am wondering
if anyone here has come across this.
I am writing an AndroMDA maven plugin. Its working
well, but I am having
trouble when it comes time to run xdoclet on the
AndroMDA generated code
AndroMDA generates 2 kinds of files. One that can
safely be regenerated (a
base class if you like), and one that is supposed to
serve as a template
that is generated once and then hand edited thereafter
Usually this is done into 2 different directory
structures
The base classes I want to generate into
${maven.build.dir}/genarc/java and
the other files into ${maven.src.dir}/java/main
Now the problem comes from 2 places
a) pom.build.sourceDirectory only has a single root
b) all the xdoclet plugin jelly code assumes that the
directory for supplied
filesets is ${pom.build.sourceDirectory}
j:set var=fileset_index value=0/
j:forEach begin=0 end=10
indexVar=fileset_index
j:set var=fileset_index_var_name
value=maven.xdoclet.webdoclet.fileset.${fileset_index}/
j:if
test=${context.getVariable(fileset_index_var_name) !=
null}
fileset
dir=${pom.build.sourceDirectory}
j:set
var=fileset_index_include_var_name
value=maven.xdoclet.webdoclet.fileset.${fileset_index}.include/
j:set
var=fileset_index_exclude_var_name
value=maven.xdoclet.webdoclet.fileset.${fileset_index}.exclude/
j:if
test=${context.getVariable(fileset_index_include_var_name)
!= null}
include
name=${context.getVariable(fileset_index_include_var_name)}/
/j:if
j:if
test=${context.getVariable(fileset_index_exclude_var_name)
!= null}
exclude
name=${context.getVariable(fileset_index_exclude_var_name)}/
/j:if
/fileset
/j:if
/j:forEach
So I could create my own xdoclet maven plugn and allow
the dir to be
specified
i.e.
maven.xdoclet.webdoclet.fileset.0=true
maven.xdoclet.webdoclet.fileset.0.dir=${maven.build.dir}/genarc/java
maven.xdoclet.webdoclet.fileset.0.include=**/*Servlet.java
That would be nice, and I'll try get the xdoclet
folks to make that change
to the xdoclet plugin.jelly file
But how generally do people deal with generated Java
code, especially when
there are 2 levels of generation
1. AndroMDA
2. XDoclet
Right now I get my AndroMDA plugin to add the output
folders to the
'maven.compile.src.set'
maven:addPath id=maven.compile.src.set
refid=andromda.java.compile.src.set.${subelement_index}/
Anyway I'd appreciate any advice people care to pass
on
Thanks,
Matthew
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
