RE: Mbean deployment descriptors
The only way I've been successful (I've only tried once or twice) was to create a custom maven.xml goal to run jmxdoclet via ant (the xdoclet maven plugin is pretty hard to understand, much less use, from my perspective). I can send you my goal definition from my other email address/computer if you'd like... -john -Original Message- From: Rich [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 10:36 AM To: Maven Users List Subject: Mbean deployment descriptors Does anyone know how to generate deployment descriptors for Mbeans? Can anyone tell me where I should look to find some docs on this? Thanks in advance. -- Rich >From his PowerBook G4 An awesome piece of engineering - 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: Can I set the classpath for a plugin?
What about using the project.xml from the plugin? You can add dependencies via the subnode... Is this not adequate? -john -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Friday, February 13, 2004 12:52 PM To: [EMAIL PROTECTED] Subject: Can I set the classpath for a plugin? I'm working on a maven plugin for xmlbeans. I need to be able to specify for each use of the plugin which dependencies are in the classloader that loads the java class used by the plugin (which is included in the plugin) or what is in the thread context classloader (I think). Before I go off and spend hours investigating this I thought I'd ask if this is possible and how to do it. Many thanks, david jencks - 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: ejb:ejb-client usage
What are the conceptual implications of this on the one-and-only-one
artifact principal? Personally, I've defined an ejb-client subproject for
each ejb, with pom ID -client, where the POM extends the
parent directory's. Looks something like this:
../project.xml
.
.
.
${basedir}/../src
${basedir}/../test
I know, it seems like a lot of work, but I'm not even sure where to begin
patching the ejb plugin until we have pluggable artifact types in maven. In
this model, I just execute a maven process in place of the other definition
of which you all defined below. It works
pretty well...
-john
-Original Message-
From: nicolas De Loof [mailto:[EMAIL PROTECTED]
Sent: Monday, February 09, 2004 10:28 AM
To: Maven Users List
Subject: Re: ejb:ejb-client usage
... and I defined this in my webapp project.xml to make Eclipse
.classpath have a src reference to the ejb project :
${project.name}
${project.name}-ejbxxx
client-${pom.currentVersion}
jar
true
true
Hope it can help.
Nico.
nicolas De Loof a écrit :
> Just for info to other users having the same needs, I've defined this
> postgoal to make it work fine. Jelly code comes form patches
> http://jira.codehaus.org/ViewIssue.jspa?key=MPEJB-2
>
>
>
>
>
> value="${maven.build.dir}/${maven.final.name}-client.jar"/>
>
>
>
> artifact="${maven.ejb.final.client.name}"
>type="jar"
>project="${pom}"/>
>
>
>
> Nico.
>
>
> Emmanuel Venisse a écrit :
>
>> - Original Message - From: "nicolas De Loof"
>> <[EMAIL PROTECTED]>
>> To: "Maven Users List" <[EMAIL PROTECTED]>
>> Sent: Monday, February 09, 2004 3:32 PM
>> Subject: ejb:ejb-client usage
>>
>>
>>
>>
>>> Hi
>>>
>>> I'm trying to migrate an existing project to maven. This projects has
>>> some Ejbs, and I would like multiproject:install to build Ejb.jar AND
>>> Ejb-client.jar. Another sub-project (webapp) has ejb-client.jar for
>>> dependency.
>>>
>>> When using multiproject:install, Ejb.jar is build but not
>>> Ejb-client.jar. I can see in plugin.jelly that "ejb:ejb-client" looks
>>> like an optional goal in the ejb plugin.
>>>
>>> Do I need to define a postgoal to call ejb:ejb-client and
>>> install:artifact for Ejb-client.jar or is they're any way to handle
>>> this
>>> automatically ?
>>>
>>
>>
>> Yes or if you have a default goal for all your project, you can add an
>> attainGoal to ejb:ejb-client.
>>
>>
>>
>>> 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]
>
-
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: Are unit test includes and excludes inherited?
Phrased as a feature request, I'd echo these sentiments... -j - John Casey Programmer/Analyst Gainesville Regional Utilities -Original Message- From: Sean Timm [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 3:35 PM To: Maven Users List Subject: RE: Are unit test includes and excludes inherited? Jason van Zyl [mailto:[EMAIL PROTECTED] wrote: > > > > Reports get aggregated in the RC2 branch (and I'm taking > advantage of this fact). Are they not supposed to? > > No, something is wrong. Only the dependencies are supposed to > be aggregated. Is there a better way to accomplish what I'm trying to do then? I want to use the same reports for all of our Java components...except occasionally a component will require additional reports (like the Cactus report if Cactus unit tests are available). I'm trying to make the specification of an individual project.xml as simple as possible and do most of the configuration in the parent. -- Sean T. - 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: Are unit test includes and excludes inherited?
Your explanation is much easier to understand. :)
-Original Message-
From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 05, 2004 10:30 AM
To: Maven Users List
Subject: Re: Are unit test includes and excludes inherited?
If you have this in parent :
1
.
a jar A with version 1
a jar B with version 1
.
${basedir}/src/somedir
and in child :
1
.
a jar A with version 2
.
${basedir}/src/otherdir
The list of dependencies is :
- jar A version 2
- jar B version 1
sourcedirectory = ${basedir}/src/otherdir
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 05, 2004 3:41 PM
Subject: RE: Are unit test includes and excludes inherited?
> The key word below is _merged_. That is, the XML structures are merged.
So,
> if you have a first-level child element of the project element, it'll be
> inherited. Beyond that, if your n-level specification isn't within the
> dependencies declaration, it'll be overwritten by the child declaration.
>
>
> 1 <= first-level
> .
> .
> .
>
> ${basedir}/src/somedir <= n-level
>
>
>
>
> In the above example, the source directory will be overwritten if the
build
> element is specified in the child project.xml, since the first-level
element
> is not . In non-dependency situations, maven does a simple
> node replacement, not a node-structure-merge.
Yes
>
> Hope this helps.
>
> -john
>
> -Original Message-
> From: Nigel Deakin [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 05, 2004 8:51 AM
> To: Maven Users List
> Subject: RE: Are unit test includes and excludes inherited?
>
> Thanks. Are you saying that dependencies are the *only* thing that is
> inherited? I was under the impression that other components of the POM
> were inherited, such as .
>
> Furthermore, I notice that in maven.xml, goals are inherited but not
> post-goals.
>
> Is there a definititive definition of what is inherited?
>
> Nigel
>
> > -Original Message-
> > From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
> > Sent: Thursday February 5 2004 1:08 pm
> > To: Maven Users List
> > Subject: Re: Are unit test includes and excludes inherited?
> >
> >
> > In Maven, only dependencies are merged when you inherit a project.
> > In your case, you redeclare a build tag, so only the child
> > part is used and
> > not the parent part.
> >
> > Emmanuel
> >
> > - Original Message -
> > From: "Nigel Deakin" <[EMAIL PROTECTED]>
> > To: "Maven Users List" <[EMAIL PROTECTED]>
> > Sent: Thursday, February 05, 2004 1:16 PM
> > Subject: Are unit test includes and excludes inherited?
> >
> >
> > I have a question about project inheritance which I haven't
> > been able to
> > find out an answer to from searching the documentation or the archives
> > of this list.
> >
> > I have two maven projects, one which extends the others. In
> > general the
> > inheritence is working as I would expect.
> >
> > In the parent project I have defined which unit tests I want
> > to run and
> > which ones I want to omit:
> >
> >
> >
> >
> >
> >
> > com/**/Test*.java
> >
> >
> > **/foo/TestBar*.java
> >
> >
> >
> >
> > In the child project I simply have:
> >
> >
> >
> >
> >
> >
> > Now when I run the tests in the child project it runs
> > everything in the
> > unitTestSourceDirectory, ignoring the excludes defined in the parent
> > project. So it looks as if the includes and excludes are not being
> > inherited.
> >
> > Is this expected behaviour?
> >
> > (This is with 1.0-rc1)
> >
> > Nigel
> >
> >
> > This message contains confidential information and is
> > intended only for the
> > named individual and may not be disseminated without prior
> > permission. If
> > you are not the named addressee, you should not disseminate,
> > distribute or
> > copy this e-mail. Please notify the sender immediately by
> > e-mail if you have
> > received this message in error and delete this e-message from
> > your system.
> > E-mail transmission cannot be guaranteed to be secure or error-free as
> > information could be intercepted, corrupted, lost, destroyed,
> > delayed in
> > transmission, incomplete, or may contain viruses. The sender
> > therefore does
> > not accept liability for any errors or omissions in the
> > contents of this
> > Message which arise as a result of e-mail transmission. If
> > verification is
> > required please request a hard-copy version. This message is
> > provided for
> > informational purposes and should not be construed as a
> > solicitation or
> > offer to buy or sell any software or services.
> >
> > __
> > __
> > This email has been scanned for all viruses by the MessageLabs SkyScan
> > service. http://www.messagelabs.com
> >
RE: Are unit test includes and excludes inherited?
The key word below is _merged_. That is, the XML structures are merged. So,
if you have a first-level child element of the project element, it'll be
inherited. Beyond that, if your n-level specification isn't within the
dependencies declaration, it'll be overwritten by the child declaration.
1 <= first-level
.
.
.
${basedir}/src/somedir <= n-level
In the above example, the source directory will be overwritten if the build
element is specified in the child project.xml, since the first-level element
is not . In non-dependency situations, maven does a simple
node replacement, not a node-structure-merge.
Hope this helps.
-john
-Original Message-
From: Nigel Deakin [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 05, 2004 8:51 AM
To: Maven Users List
Subject: RE: Are unit test includes and excludes inherited?
Thanks. Are you saying that dependencies are the *only* thing that is
inherited? I was under the impression that other components of the POM
were inherited, such as .
Furthermore, I notice that in maven.xml, goals are inherited but not
post-goals.
Is there a definititive definition of what is inherited?
Nigel
> -Original Message-
> From: Emmanuel Venisse [mailto:[EMAIL PROTECTED]
> Sent: Thursday February 5 2004 1:08 pm
> To: Maven Users List
> Subject: Re: Are unit test includes and excludes inherited?
>
>
> In Maven, only dependencies are merged when you inherit a project.
> In your case, you redeclare a build tag, so only the child
> part is used and
> not the parent part.
>
> Emmanuel
>
> - Original Message -
> From: "Nigel Deakin" <[EMAIL PROTECTED]>
> To: "Maven Users List" <[EMAIL PROTECTED]>
> Sent: Thursday, February 05, 2004 1:16 PM
> Subject: Are unit test includes and excludes inherited?
>
>
> I have a question about project inheritance which I haven't
> been able to
> find out an answer to from searching the documentation or the archives
> of this list.
>
> I have two maven projects, one which extends the others. In
> general the
> inheritence is working as I would expect.
>
> In the parent project I have defined which unit tests I want
> to run and
> which ones I want to omit:
>
>
>
>
>
>
> com/**/Test*.java
>
>
> **/foo/TestBar*.java
>
>
>
>
> In the child project I simply have:
>
>
>
>
>
>
> Now when I run the tests in the child project it runs
> everything in the
> unitTestSourceDirectory, ignoring the excludes defined in the parent
> project. So it looks as if the includes and excludes are not being
> inherited.
>
> Is this expected behaviour?
>
> (This is with 1.0-rc1)
>
> Nigel
>
>
> This message contains confidential information and is
> intended only for the
> named individual and may not be disseminated without prior
> permission. If
> you are not the named addressee, you should not disseminate,
> distribute or
> copy this e-mail. Please notify the sender immediately by
> e-mail if you have
> received this message in error and delete this e-message from
> your system.
> E-mail transmission cannot be guaranteed to be secure or error-free as
> information could be intercepted, corrupted, lost, destroyed,
> delayed in
> transmission, incomplete, or may contain viruses. The sender
> therefore does
> not accept liability for any errors or omissions in the
> contents of this
> Message which arise as a result of e-mail transmission. If
> verification is
> required please request a hard-copy version. This message is
> provided for
> informational purposes and should not be construed as a
> solicitation or
> offer to buy or sell any software or services.
>
> __
> __
> This email has been scanned for all viruses by the MessageLabs SkyScan
> service. http://www.messagelabs.com
> __
> __
>
> -
> 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]
>
>
> __
> __
>
> This email has been scanned for all viruses by MessageLabs
> __
> __
>
This message contains confidential information and is intended only for the
named individual and may not be disseminated without prior permission. If
you are not the named addressee, you should not disseminate, distribute or
copy this e-mail. Please notify the sender immediately by e-mail if you have
received this message in error and delete this e-message from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
RE: dependencies of dependencies
Yeah, I think that functionality is on the way, but will not make the 1.0 release...I'm not actually on the development team, though, so I can't speak too intelligently about this. Unless I'm mistaken, you're looking to achieve closure of the set of dependencies and their implied dependencies, and include that in the resulting deliverable. That's what all the discussion of transitive dependencies is about, I believe. -john -Original Message- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 2:10 PM To: Maven Users List Subject: RE: dependencies of dependencies Unless I completely missed something, you are still managing these manually; you've just moved dealing with it from the project file to a pre-goal. What I was thinking of was: 1) war plugin starts to bundle, say hibernate's jar into the webapp because I specified it as a runtime library; 2) war plugin determines that hibernate, itself, has a number of runtime dependencies and bundles those (possible retreiving from repo) into the webapp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 12:49 PM To: [EMAIL PROTECTED] Subject: RE: dependencies of dependencies FYI, check out old archive messages referring to transitive dependencies. -john -Original Message- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 1:49 PM To: Maven Users List Subject: dependencies of dependencies Just wondering if there is a way through maven to better manage the dependencies of my project's dependencies. For example, say I have a project whose deliverable/artifact is a war and further say I have utilized the true on any number of the dependencies I have defined for that project. If those dependencies in turn have dependencies (especially of the run-time variety) it would be nice for the war plugin to pull those "extended" dependencies in along with the explicit dependencies. As it is, I instead have to manually add dependency definitions to my project for those "extended" dependencies. Is there a way to get maven to pull in those "extended" dependencies automagically during build? Just curious... Thanks, Steve - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependencies of dependencies
FYI, check out old archive messages referring to transitive dependencies. -john -Original Message- From: Ebersole, Steven [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 1:49 PM To: Maven Users List Subject: dependencies of dependencies Just wondering if there is a way through maven to better manage the dependencies of my project's dependencies. For example, say I have a project whose deliverable/artifact is a war and further say I have utilized the true on any number of the dependencies I have defined for that project. If those dependencies in turn have dependencies (especially of the run-time variety) it would be nice for the war plugin to pull those "extended" dependencies in along with the explicit dependencies. As it is, I instead have to manually add dependency definitions to my project for those "extended" dependencies. Is there a way to get maven to pull in those "extended" dependencies automagically during build? Just curious... Thanks, Steve - 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: including resources into target/classes
Inside the section of the project.xml, try something like
the following:
${basedir}/src/java <-- or whatever
... <-- unit tests
.
. <-- unit test configurations...you have unit tests, right? ;)
.
${basedir}/src/java
**/*.xml
See if that helps.
-john
-Original Message-
From: Ebersole, Steven [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 20, 2004 10:13 AM
To: Maven Users List
Subject: including resources into target/classes
I am trying to build a hibernate-backed app using maven, but noticed that
the hibernate mapping files are not pulled over into the target/classes
directory. How is this typically acheived using maven?
-
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]
nomenclature question
I'm trying to write a plugin for maven, which will de-archive a WAR or EAR, filter in environment-specific configurations, re-archive the application, backup the old version of the running app, and deploy the new version. I know that the words 'install' and 'deploy' have a distinct meaning in mavenese, and I'm wondering if there is any consensus about what term I should use to address my process, in order to avoid confusion with these other processes. The two taken terms are the obvious choices, but other than those, I'm at a loss. I know this seems like a trivial question, but it is extremely important when you consider that I'm going to be attempting to present the packaging and deployment (from version control to running application) to my management. Does anyone have any suggestions? Thanks, John
testing maven plugins
Is there a standardized way of testing a maven plugin? I've developed one for enforcement of our in-house packaging and deployment processes, and I've been going through this install/test manual loop for like a day now. Is there a way that I can [easily] test the plugin prior to installation? Specifically, I'm talking about testing of the plugin.jelly. Any advice would be much appreciated. Thanks, John Casey
project.xml jelly support
I think I read something in the mail archive about the project.xml being just a big jelly script? In that message (I believe it from Jason), there was a warning not to abuse this fact...for our own good. :-) Anyway, I wanted to find out the level of jelly support provided in the project.xml. Does this mean that I can use the following: . . . . . . If so, I'm missing something, because the parser appears to ignore this tag... Does anyone have any advice? Thanks, John Casey
