[m2] Assembly-plugin Manifest.mf
Perhaps I do not understand the purpose of the assembly plug-in, but as it works in alpha-3, the assembled jar gets a new MANIFEST.MF which is basically empty (and not the MANIFEST.MF from the created artifact). Maven-jar-plugin writes a lot of stuff to the MANIFEST (and I am writing an Eclipse PDE plugin that augments that), but sadly it doesn't get copied to the assembled jar. Is this intended? Should I move this to the dev list? Thanks, Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Assembly-plugin Manifest.mf
I don't think this is intended - can you provide us with a small test case that exhibits the behaviour and what you were expecting so we can determine whether it is a misunderstanding or a defect? Thanks, Brett On 7/20/05, J. Matthew Pryor [EMAIL PROTECTED] wrote: Perhaps I do not understand the purpose of the assembly plug-in, but as it works in alpha-3, the assembled jar gets a new MANIFEST.MF which is basically empty (and not the MANIFEST.MF from the created artifact). Maven-jar-plugin writes a lot of stuff to the MANIFEST (and I am writing an Eclipse PDE plugin that augments that), but sadly it doesn't get copied to the assembled jar. Is this intended? Should I move this to the dev list? Thanks, Matthew - 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: [m2] Assembly-plugin Manifest.mf
I am building eclipse plugins, and with Eclipse 3.1 these are essentially OSGI bundles OSGI works from entries in the manifest, in particular Bundle-Classpath attribute I have a Mojo that reads the dependencies updates the Bundle-Classpath of the created artifact (a jar in this case). What I then need to do is include all the dependent jars inside the main artifact (exploded or not) Obviously the assembly plugin suits my needs very well here, as it does all the work, but it also adds its own Manifest. I guess I saw an assembly simply as a 'superjar' but basically the same artifact as the project is meant to produce, just one that includes (transitively) all the dependent classes. Does that make sense? Matthew -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 20, 2005 5:28 PM To: Maven Users List; [EMAIL PROTECTED] Subject: Re: [m2] Assembly-plugin Manifest.mf I don't think this is intended - can you provide us with a small test case that exhibits the behaviour and what you were expecting so we can determine whether it is a misunderstanding or a defect? Thanks, Brett On 7/20/05, J. Matthew Pryor [EMAIL PROTECTED] wrote: Perhaps I do not understand the purpose of the assembly plug-in, but as it works in alpha-3, the assembled jar gets a new MANIFEST.MF which is basically empty (and not the MANIFEST.MF from the created artifact). Maven-jar-plugin writes a lot of stuff to the MANIFEST (and I am writing an Eclipse PDE plugin that augments that), but sadly it doesn't get copied to the assembled jar. Is this intended? Should I move this to the dev list? Thanks, Matthew - 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]
[m102] multiproject:deploy fails
Hi Folks, I´m trying to run maven mutliproject:deploy on a dummy project I just generated with maven genapp [complex]. The project builds fine with cruisecontrol but when I trry to deploy I get this error: BUILD FAILED File.. ~\.maven\cache\maven-multiproject-plugin-1.4.1\plugin.jelly Element... maven:reactor Line.. 218 Column 9 Unable to obtain goal [multiproject:deploy-callback] -- ~\.maven\cache\maven-xdoclet-plugin-1.2\plugin.jelly:5746:81: taskdef taskdef class xdoclet.modules.ejb.EjbDocletTask cannot be found Total time: 13 seconds What´s missing and how do I get it? Thanks Regards, Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m102] multiproject:deploy fails
Hi, got a bit further now, but still no luck. I found out that the cause of the error seems to be the ejb project. I get the error when running maven ejb:deploy in the ejb project folder: Tag library requested that is not present: 'maven' in plugin: 'maven-xdoclet-plugin-1.2' BUILD FAILED File.. C:\Dokumente und Einstellungen\chris\.maven\cache\maven-xdoclet-plugin-1.2\plugin.jelly Element... taskdef Line.. 5746 Column 81 taskdef class xdoclet.modules.ejb.EjbDocletTask cannot be found Total time: 4 seconds I also checked my repository. The dependent jar referenced in the ejb´s pom is also available: dependency groupIdxdoclet/groupId artifactIdxdoclet-ejb-module/artifactId version1.2/version urlhttp://xdoclet.sf.net//url /dependency Any ideas? Thanks! Christian Christian Schlaefcke schrieb: Hi Folks, I´m trying to run maven mutliproject:deploy on a dummy project I just generated with maven genapp [complex]. The project builds fine with cruisecontrol but when I trry to deploy I get this error: BUILD FAILED File.. ~\.maven\cache\maven-multiproject-plugin-1.4.1\plugin.jelly Element... maven:reactor Line.. 218 Column 9 Unable to obtain goal [multiproject:deploy-callback] -- ~\.maven\cache\maven-xdoclet-plugin-1.2\plugin.jelly:5746:81: taskdef taskdef class xdoclet.modules.ejb.EjbDocletTask cannot be found Total time: 13 seconds What´s missing and how do I get it? Thanks Regards, Christian - 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]
[m2] javassist-3.0.pom missing in ibiblio repository
Sorry for the wide distribution, but I don't know where to file this problem in Jira. The ibiblio repository does not contain the javassist-3.0.pom file and related artifacts. (Suggested contents for the javassist-3.0.pom file: project modelVersion4.0.0/modelVersion groupIdjavassist/groupId artifactIdjavassist/artifactId version3.0/version /project ) -- _ Wilfred SpringerPhone : +31 (0)3 3451 5736 Software Architect Mobile : +31 (0)6 2295 7321 Client SolutionsFax: +31 (0)3 3451 5734 Enterprise Web Services Mail : [EMAIL PROTECTED] Sun Microsystems NetherlandsAIM: wilfred springer http://blogs.sun.com/wilfred/ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Report about modules
Hi, I would like to generate a report from my top level project that contains the modules defined in the pom file and links to the sites of the modules. Is there a reporting plugin available for that task? Thanks, Friedger
Re: A bug in the Maven plugin for XDoclet?
Ken,
The maven plugin is just a wrapper around the ant task and the Xdoclet
guys manage this plugin themselves so you should contact them.
Cheers,
Stéphane
On 7/20/05, Ballard, Ken [EMAIL PROTECTED] wrote:
Is this a bug in the Maven plugin for XDoclet (I'm using version 1.2.3)?
When using EJBDoclet with ANT, you can write a Stateless Session Bean that
extends Spring's EJB support class
org.springframework.ejb.support.AbstractStatelessSessionBean and XDoclet
will generate the appropriate interfaces and descriptors. With the XDoclet
plugin for Maven you can only write a Stateless Session Bean that implements
javax.ejb.SessionBean and get the correct results. Otherwise EJBDoclet
generates interfaces that extend fictitious classes. For example, if you
have a Stateless Session Bean that extends AbstractStatelessSessionBean,
instead of generating a RemoteInterface that extends javax.ejb.EJBObject,
ejbdoclet creates a RemoteInterface that extends a fictitious class. It
takes the word AbstractStatelessSessionBean, and either adds Remote to the
end of it if you specified
maven.xdoclet.ejbdoclet.remoteinterface.0.pattern={0}Remote in your
project.properties or just strips off Bean leaving you with
org.springframework.ejb.support.AbstractStatelessSession which also does not
exist. I've scoured the earth looking for any documentation, blog, or
anything that will tell me how to get around this. I haven't found anything.
Is this a bug?
Thanks,
Ken
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
.::You're welcome ::.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: A bug in the Maven plugin for XDoclet?
Thanks, I'll post it to their list.
-Original Message-
From: Stephane Nicoll [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 20, 2005 10:24 AM
To: Maven Users List
Subject: Re: A bug in the Maven plugin for XDoclet?
Ken,
The maven plugin is just a wrapper around the ant task and the Xdoclet
guys manage this plugin themselves so you should contact them.
Cheers,
Stéphane
On 7/20/05, Ballard, Ken [EMAIL PROTECTED] wrote:
Is this a bug in the Maven plugin for XDoclet (I'm using version 1.2.3)?
When using EJBDoclet with ANT, you can write a Stateless Session Bean that
extends Spring's EJB support class
org.springframework.ejb.support.AbstractStatelessSessionBean and XDoclet
will generate the appropriate interfaces and descriptors. With the XDoclet
plugin for Maven you can only write a Stateless Session Bean that
implements
javax.ejb.SessionBean and get the correct results. Otherwise EJBDoclet
generates interfaces that extend fictitious classes. For example, if you
have a Stateless Session Bean that extends AbstractStatelessSessionBean,
instead of generating a RemoteInterface that extends javax.ejb.EJBObject,
ejbdoclet creates a RemoteInterface that extends a fictitious class. It
takes the word AbstractStatelessSessionBean, and either adds Remote to the
end of it if you specified
maven.xdoclet.ejbdoclet.remoteinterface.0.pattern={0}Remote in your
project.properties or just strips off Bean leaving you with
org.springframework.ejb.support.AbstractStatelessSession which also does
not
exist. I've scoured the earth looking for any documentation, blog, or
anything that will tell me how to get around this. I haven't found
anything.
Is this a bug?
Thanks,
Ken
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
.::You're welcome ::.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[m2] Tasklist plugin converted: what should I do now?
Hi guys! First of all, I'd like to congratulate the m2 team for the great work they've done, especially the various APIs (MOFO, reporting, doxia, ...etc) which are a pleasure to use to develop plugins. :o) To discover the m2-style plugin writing, I converted the tasklist plugin into a taglist plugin. taglist plugin because I added the possibility to look for any kind of user task tag : - Javadoc ones, as it used to be: @todo, @whatever, ... - but also any kind of tag found in a Java comment (// TODO for instance). This works for any Java comment (//, /* or /**). What should I do now to contribute this code to the Maven project? Can someone contact me to tell me what to do? Cheers! Best Regards / Cordialement, Fabrice BELLINGARD DINQ/DSIN/INSI/EATE/IDVS/AIDV (+33) (01 61) 45 15 91 - [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A bug in the Maven plugin for XDoclet?
I had the same exact isue, and I resolved this by creating an
AbstractSLSB.java file that extended Springs Abstract Session bean class,
then my XDoclet Bean extends that, and XDoclet was fine.
public abstract class AbstractSLSB extends AbstractStatelessSessionBean {
}
/**
* Bean implementation class for Enterprise Bean: ConsumerManagerBean
*
* @ejb.beanname=ConsumerManager
* display-name=Consumer Manager Session Bean
* type=Stateless
* view-type=local
* local-jndi-name=local/ConsumerManager
*
* @ejb.home local-extends=javax.ejb.EJBLocalHome
* @ejb.interface local-extends=ConsumerManager, javax.ejb.EJBLocalObject
*
* @jboss.container-configuration name=Standard Stateless SessionBean
*
* @websphere.container-configuration name=Standard Stateless SessionBean
* @websphere.bean
*
* @ejb.env-entry name=ejb/BeanFactoryPath
* type=java.lang.String
* value=applicationContext.xml
*
* @ejb.util generate=physical
* @ejb.transaction type=Required
* @ejb.transaction-type type=Container
* @ejb.permission unchecked=true
*/
public class ConsumerManagerBean extends AbstractSLSB
implements ConsumerManager {
.
}
From: Stephane Nicoll [EMAIL PROTECTED]
Reply-To: Stephane Nicoll [EMAIL PROTECTED]
To: Maven Users List users@maven.apache.org
Subject: Re: A bug in the Maven plugin for XDoclet?
Date: Wed, 20 Jul 2005 16:23:41 +0200
Ken,
The maven plugin is just a wrapper around the ant task and the Xdoclet
guys manage this plugin themselves so you should contact them.
Cheers,
Stéphane
On 7/20/05, Ballard, Ken [EMAIL PROTECTED] wrote:
Is this a bug in the Maven plugin for XDoclet (I'm using version 1.2.3)?
When using EJBDoclet with ANT, you can write a Stateless Session Bean
that
extends Spring's EJB support class
org.springframework.ejb.support.AbstractStatelessSessionBean and XDoclet
will generate the appropriate interfaces and descriptors. With the
XDoclet
plugin for Maven you can only write a Stateless Session Bean that
implements
javax.ejb.SessionBean and get the correct results. Otherwise EJBDoclet
generates interfaces that extend fictitious classes. For example, if you
have a Stateless Session Bean that extends AbstractStatelessSessionBean,
instead of generating a RemoteInterface that extends
javax.ejb.EJBObject,
ejbdoclet creates a RemoteInterface that extends a fictitious class. It
takes the word AbstractStatelessSessionBean, and either adds Remote to
the
end of it if you specified
maven.xdoclet.ejbdoclet.remoteinterface.0.pattern={0}Remote in your
project.properties or just strips off Bean leaving you with
org.springframework.ejb.support.AbstractStatelessSession which also does
not
exist. I've scoured the earth looking for any documentation, blog, or
anything that will tell me how to get around this. I haven't found
anything.
Is this a bug?
Thanks,
Ken
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is
for the sole use of the intended recipient(s) and may contain
confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please
contact the sender by reply e-mail and destroy all copies of the
original
message.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
.::You're welcome ::.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thank You
Mick Knutson
Sr. Java/J2EE Consultant
BASE logic, inc.
(415) 648-1804 (S.F., CA)
http://www.BASELogic.com
HP Consulting Services (Walnut Creek, CA)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[maven 1.0.2] limiting the remote repo timeout?
I have an internal remote repository, and ibilblio as a secondary repo. I want to know how I can limit the timeout for my repo if the dependancy does not exist. Right now it seems like it is well over a minute. Thank You Mick Knutson Sr. Java/J2EE Consultant BASE logic, inc. (415) 648-1804 (S.F., CA) http://www.BASELogic.com HP Consulting Services (Walnut Creek, CA) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [maven] jcoverage examples please?
Mick Knutson wrote:
Can you please show me your Maven cfg then for this please?
From: Carlos Sanchez [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Maven Users List users@maven.apache.org
Subject: Re: [maven] jcoverage examples please?
Date: Tue, 19 Jul 2005 16:18:23 -0700
Hi,
I suggest you to take a look at the cobertura plugin. Cobertura is a
fork of jcoverage actively developed, while jcoverage seems stalled.
http://maven-plugins.sourceforge.net//maven-cobertura-plugin/
Mick,
I just did a couple of experiments with both the jcoverage and the
cobertura plugins with a Maven project on which I had never used either.
If you download the plugins into your ${MAVEN_HOME}/plugins directory,
you can simply invoke the default goals of each plugin:
maven [clean] jcoverage cobertura
It isn't necessary that you execute the clean goal, I included it as
an option so that, if you use it, you will be able to see all of the
goals/subgoals that Maven will execute as it prepares your project for
instrumentation and then later as the test sets are run.
Unless you have special requirements that is all you have to do during
your normal development cycle, and since JCoverage and Cobertura are
pretty similar, you can choose between them. As was already said,
Cobertura is the active fork of the now moribund open source bits of the
JCoverage project (JCoverage continues to be developed and enhanced, but
that version is commercial.)
If you were to add a reference to the maven-cobertura-plugin to the
reports section of your pom (project.xml) file, then, if and when you
generate a website for your project using Maven, it will include the
Cobertura HTML report in the generated site.
If there are specific things that you need to tweak, take a look at the
properties available to you on the plugin's website.
I hope that this helps. If you have more detailed questions, don't
hesitate to email me directly and I'll attempt to offer more assistance.
Best regards,
Andy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [maven] jcoverage examples please?
OK, I ran it like you said in my maven multiproject:site-deploy as one of
the report plugins.
Now each of my 8 subprojects have 50 to 200 unit tests each. However, _ALL_
of the 8 Cobertura reports showed zero tests where run at all.
So what am I missing to get Cobertura to see my unit tests and operate
properly?
From: Andy Glick [EMAIL PROTECTED]
Reply-To: Maven Users List users@maven.apache.org
To: users@maven.apache.org
Subject: Re: [maven] jcoverage examples please?
Date: Wed, 20 Jul 2005 14:05:32 -0400
Mick Knutson wrote:
Can you please show me your Maven cfg then for this please?
From: Carlos Sanchez [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Maven Users List users@maven.apache.org
Subject: Re: [maven] jcoverage examples please?
Date: Tue, 19 Jul 2005 16:18:23 -0700
Hi,
I suggest you to take a look at the cobertura plugin. Cobertura is a
fork of jcoverage actively developed, while jcoverage seems stalled.
http://maven-plugins.sourceforge.net//maven-cobertura-plugin/
Mick,
I just did a couple of experiments with both the jcoverage and the
cobertura plugins with a Maven project on which I had never used either.
If you download the plugins into your ${MAVEN_HOME}/plugins directory, you
can simply invoke the default goals of each plugin:
maven [clean] jcoverage cobertura
It isn't necessary that you execute the clean goal, I included it as an
option so that, if you use it, you will be able to see all of the
goals/subgoals that Maven will execute as it prepares your project for
instrumentation and then later as the test sets are run.
Unless you have special requirements that is all you have to do during your
normal development cycle, and since JCoverage and Cobertura are pretty
similar, you can choose between them. As was already said, Cobertura is the
active fork of the now moribund open source bits of the JCoverage project
(JCoverage continues to be developed and enhanced, but that version is
commercial.)
If you were to add a reference to the maven-cobertura-plugin to the reports
section of your pom (project.xml) file, then, if and when you generate a
website for your project using Maven, it will include the Cobertura HTML
report in the generated site.
If there are specific things that you need to tweak, take a look at the
properties available to you on the plugin's website.
I hope that this helps. If you have more detailed questions, don't hesitate
to email me directly and I'll attempt to offer more assistance.
Best regards,
Andy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thank You
Mick Knutson
Sr. Java/J2EE Consultant
BASE logic, inc.
(415) 648-1804 (S.F., CA)
http://www.BASELogic.com
HP Consulting Services (Walnut Creek, CA)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Alternate build step
Reid - I would just define your own goal in the maven.xml file and call that. You can make it then call the checkstyle goal by using attainGoal or whatever else you want it to do. -marc -Original Message- From: Reid Pinchback [mailto:[EMAIL PROTECTED] Sent: Wed 7/20/2005 6:01 PM To: users@maven.apache.org Cc: Subject: Alternate build step Yes, I'm a newbie. I trolled through faqs and did some web searches and didn't see what I'm looking for. If you know a specific place that addresses the question I'm about to ask, please send me pointer to it. Situation: I have an existing Ant-based build environment involving multiple projects and multiple developers. For a host of obvious reasons, sweeping changes don't go through overnight. I'm in the process of using Maven for mavenish things, but the bulk of day-to-day developer activity will, for some time, be Ant. Changing that isn't on the table without consequences involving hot tar and a bunch of plucked chickens. I'd like Maven to be able to do things like run Checkstyle when I build the site. What I don't want is for it to perform its default Java build steps. I don't want Maven to know anything about how the various software products are really built. I don't mind it knowing where the Java source is, but I don't want it to do anything with it. What I really want is for it to insert my Ant build as a *replacement* for what it normally does... not as some pre-goal to doing its thing. I don't want it doing its thing. It's thing isn't going to do me any good. In the future maybe we'll go all Maven, but what I've described is what I need to achieve for the present. So in summary the idea is: maven site causes my ant target to be invoked (I see in the docs how to invoke an ant task), and then runs checkstyle, and then builds the site, but never tries to compile or deploy anything. How do I do that? Thanks in advance, Reid __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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]
Re: Directory Structure conventions for multiprojects
I'm curious also to know if anyone from the Maven team can comment on Ken's project directory structure for Maven 2. We are in a similar predicament with Maven 2 with mutiple applications with multiple EARs. There doesn't seem to be enough depth on the [http://maven.apache.org/reference/conventions.html] page. Any pointers sincerely appreciated. Thanks, Manny - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Directory Structure conventions for multiprojects
this is basically my goal at the moment in regards to m2 root/ root/core root/war1 - uses core, lib1 root/war2 - uses core, lib1, lib2 root/war3 root/ejb1 - uses lib1, core root/ejb2 - uses lib2, core root/lib1 root/lib2 root/ear1 - uses war1, war2, ejb1 root/ear2 - uses war3, ejb2 basically just seperate the source as much as makes sense into seperately compilable units, and then in the pom.xml for the wars, ejb, and ear just source in the dependencies that are needed in a bit of a tree. problem becomes when you have a hefty chunk of classes that are pretty entertwined, but its my feeling that adopting this kinda structure allows you to grow into a cleaner seperation of logical entities. nice thing about that is say that your team splits and each team takes control on one of those ears, it is pretty easy to setup either cvs modules or subversion to pluck those things out and share those 'subprojects' between the root projects. only issue I am running up against now is that my ears are coming out a fair amount bigger then our existing ant system...but that is actually what I'll be tackling tomorrow. my 2 cents, jesse On 7/20/05, Manny Nainu [EMAIL PROTECTED] wrote: I'm curious also to know if anyone from the Maven team can comment on Ken's project directory structure for Maven 2. We are in a similar predicament with Maven 2 with mutiple applications with multiple EARs. There doesn't seem to be enough depth on the [http://maven.apache.org/reference/conventions.html] page. Any pointers sincerely appreciated. Thanks, Manny - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jesse mcconnell jesseDOTmcconnellATgmailDOTcom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [maven] jcoverage examples please?
On Jul 20, 2005, at 2:42 PM, Mick Knutson wrote: Sorry, I mean that I get the Cobertura reports being generated, but it says that there are no tests, and 0% coverage on all of my projects. I've had this problem lately, too. It used to work, but one of the more recent snapshots broke it for me. (Looks like 1.0 proper is out now, too. It doesn't work for me.) Another developer here can do them fine. I suspect it has something to do with your version of maven - I think he's been always on 1.0.2. I've upgraded some components as recommended on the download page and played with maven 1.1 beta 1. I've been meaning to take this up on the maven-plugins- [EMAIL PROTECTED] list. It seems the appropriate place. -- Scott Lamb http://www.slamb.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] Assembly-plugin Manifest.mf
On 7/20/05, J. Matthew Pryor [EMAIL PROTECTED] wrote: Obviously the assembly plugin suits my needs very well here, as it does all the work, but it also adds its own Manifest. I guess I saw an assembly simply as a 'superjar' but basically the same artifact as the project is meant to produce, just one that includes (transitively) all the dependent classes. This sounds right. Assembly should let you specify your own manifest fields though - if it is not, its a bug. But what I'm thinking is that it should have an OSGi JAR format that will add these fields automatically using POM data. We could use the Maven1 OSGi plugin as a starting point: http://mavenosgiplugin.berlios.de/osgidevandbuild.html - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[m2] jsp syntax verification
Does the war plugin verify the syntax correctness of JSP pages / documents during the build? If not, would this be a reasonable enhancement request to the maven-war-plugin? Or perhaps it should have its own maven-jspc-plugin? Such JSP files are usually compiled-on-demand after deployment to the web container. It would be useful to automatically fail the build when invalid JSP syntax is used. Kind Regards, John Fallows. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] jsp syntax verification
Since there is no standard JSPC, I would think that this belongs in a tomcat plugin. It would bind into the lifecycle to ensure the war plugin is handed the correct classes if the precompiled files are being included. - Brett On 7/21/05, John Fallows [EMAIL PROTECTED] wrote: Does the war plugin verify the syntax correctness of JSP pages / documents during the build? If not, would this be a reasonable enhancement request to the maven-war-plugin? Or perhaps it should have its own maven-jspc-plugin? Such JSP files are usually compiled-on-demand after deployment to the web container. It would be useful to automatically fail the build when invalid JSP syntax is used. Kind Regards, John Fallows. - 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: Alternate build step
That sounds promising. This is probably going to sound like the dumbest newbie question in the world, but how do I do that? I suspect you're talking about setting up a goal in maven.xml. Not yet fully up to speed on the goal/namespace relationship in Maven, and I bet that is rather key to what you suggest. --- dan tran [EMAIL PROTECTED] wrote: how about overide java:compile to do nothing? -D __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternate build step
correct add goal name=java:compile / to override the implementation of http://maven.apache.org/reference/plugins/java/goals.html to your maven.xml -D On 7/20/05, Reid Pinchback [EMAIL PROTECTED] wrote: That sounds promising. This is probably going to sound like the dumbest newbie question in the world, but how do I do that? I suspect you're talking about setting up a goal in maven.xml. Not yet fully up to speed on the goal/namespace relationship in Maven, and I bet that is rather key to what you suggest. --- dan tran [EMAIL PROTECTED] wrote: how about overide java:compile to do nothing? -D __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [maven] jcoverage examples please?
Seems maven-cobertura-plugin 1.0 is not working; file a JIRA issue. I don't think it matters if you are using 1.0.2 or 1.1-beta. On 7/20/05, Scott Lamb [EMAIL PROTECTED] wrote: On Jul 20, 2005, at 2:42 PM, Mick Knutson wrote: Sorry, I mean that I get the Cobertura reports being generated, but it says that there are no tests, and 0% coverage on all of my projects. I've had this problem lately, too. It used to work, but one of the more recent snapshots broke it for me. (Looks like 1.0 proper is out now, too. It doesn't work for me.) Another developer here can do them fine. I suspect it has something to do with your version of maven - I think he's been always on 1.0.2. I've upgraded some components as recommended on the download page and played with maven 1.1 beta 1. I've been meaning to take this up on the maven-plugins- [EMAIL PROTECTED] list. It seems the appropriate place. -- Scott Lamb http://www.slamb.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jamie Bisotti Software Engineer Lexmark International, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternate build step
What exactly do you want the site to consist of? Why not just do maven checkstyle xdoc? On 7/21/05, dan tran [EMAIL PROTECTED] wrote: correct add goal name=java:compile / to override the implementation of http://maven.apache.org/reference/plugins/java/goals.html to your maven.xml -D On 7/20/05, Reid Pinchback [EMAIL PROTECTED] wrote: That sounds promising. This is probably going to sound like the dumbest newbie question in the world, but how do I do that? I suspect you're talking about setting up a goal in maven.xml. Not yet fully up to speed on the goal/namespace relationship in Maven, and I bet that is rather key to what you suggest. --- dan tran [EMAIL PROTECTED] wrote: how about overide java:compile to do nothing? -D __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jamie Bisotti Software Engineer Lexmark International, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [m2] Assembly-plugin Manifest.mf
POM Data would work well for a fair bit of it, certainly Bundle-Classpath other stuff What would be the next steps? jmp -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, July 21, 2005 9:56 AM To: [EMAIL PROTECTED] Cc: Maven Users List Subject: Re: [m2] Assembly-plugin Manifest.mf On 7/20/05, J. Matthew Pryor [EMAIL PROTECTED] wrote: Obviously the assembly plugin suits my needs very well here, as it does all the work, but it also adds its own Manifest. I guess I saw an assembly simply as a 'superjar' but basically the same artifact as the project is meant to produce, just one that includes (transitively) all the dependent classes. This sounds right. Assembly should let you specify your own manifest fields though - if it is not, its a bug. But what I'm thinking is that it should have an OSGi JAR format that will add these fields automatically using POM data. We could use the Maven1 OSGi plugin as a starting point: http://mavenosgiplugin.berlios.de/osgidevandbuild.html - Brett - 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]
