RE: Reasonable use of profiles?
Another desire I have is to allow for developers not even building most of the modules, and just letting the ear project pull snapshot artifacts from the Nexus repo (built by the release team or continuous integration). I could do this with multiple build projects, including different sets of module elements. That seems messy, however. You don't need separate projects for this. You just need a bunch of developer-facing pom files with different modules lists. They can certainly live in the same directory. This is something we definitely take advantage of, for producing interesting developer build sets. This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Reasonable use of profiles?
What is the semantic difference between multiple POMs and a single POM containing the different module lists in profiles? It seems like the former is harder to support because a change outside the module sets requires changing every POM. Well, one difference is a separation of developer concerns from the concerns of the consumers of your artifacts. This is especially applicable if the pom containing the profiles is the parent pom of your project, that actually gets deployed to a repository and consumed by those who consume your software. More subtly, I'd argue that the profiles are magic beans, things for which you have to introspect your source code to know what's going on, and not really knowing, without extensive examination, whether these profiles have any effect on any of the projects in the child tree. In contrast, a developer-facing pom is a distinct file whose purpose can be made quite clear at the file system level, and whose purpose is unambiguously contained entirely within the file itself. Descending down to the final level of abstract mysticism, I'd also say that the profiles represent a last resort in the context of The Maven Way, a thing you do not use unless you must. Yes, we use them -- for things like telling the build to execute integration tests that depend on the presence of an active database whose location you have defined in a settings.xml file. But for a trivial purpose like this, they are overkill. -- Bryan -Original Message- From: Brian Topping [mailto:topp...@codehaus.org] Sent: Friday, December 10, 2010 5:37 PM To: Maven Users List Subject: Re: Reasonable use of profiles? On Dec 10, 2010, at 8:08 PM, Bryan Loofbourrow wrote: You don't need separate projects for this. You just need a bunch of developer-facing pom files with different modules lists. They can certainly live in the same directory. This is something we definitely take advantage of, for producing interesting developer build sets. What is the semantic difference between multiple POMs and a single POM containing the different module lists in profiles? It seems like the former is harder to support because a change outside the module sets requires changing every POM. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: why I do not see the parent pom file in Nexus?
-Original Message- From: baz themail [mailto:bazthem...@gmail.com] Sent: Tuesday, September 21, 2010 1:39 PM To: Maven Users List Subject: Re: why I do not see the parent pom file in Nexus? The path of groupId, artifactID, version is there. I just do not see the pom.xml under it. This happens to both snapshot and release. All builds are taking the right values and settings. I am assuming that the parent pom has been deployed correctly to both release and snapshot repositories. Is there any way that i can verify? Are you looking for a .pom file? Because that's how pom.xml files get renamed when you're looking at a repo. You won't actually see pom.xml there. -- Bryan This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: why I do not see the parent pom file in Nexus?
All I have found is the path composed of groupId and version, then no contents in the directory (In the Nexus view). Is this what you are referring to? No. If your directory is empty, then something else is going on. One possibility is that your parent pom has simply never been built and deployed to the repo, but your build succeed because the version in source gets pulled in. That can happen if you don't actually build your parent pom on your build machine. My company has a distinct Hudson project for the parent pom, because we do not use the parent pom as a build parent. Without that, we'd have the same situation you have, no parent pom in the repo manager, and working builds. -Original Message- From: baz themail [mailto:bazthem...@gmail.com] Sent: Tuesday, September 21, 2010 2:19 PM To: Maven Users List Subject: Re: why I do not see the parent pom file in Nexus? I am not sure what you meant by .pom file. I am looking for a pom.xml which has the artifactId parent-pom and this should be the parent pom file for all project. I track down the whole groupId path in Nexus (both snapshot and release repositories). All I have found is the path composed of groupId and version, then no contents in the directory (In the Nexus view). Is this what you are referring to? Because that's how pom.xml files get renamed when you're looking at a repo. You won't actually see pom.xml there So, how can i verify the parent pom file in Nexus? Can you please explain the parent pom file deployment process? On Tue, Sep 21, 2010 at 2:03 PM, Bryan Loofbourrow bryan.loofbour...@amdocs.com wrote: -Original Message- From: baz themail [mailto:bazthem...@gmail.com] Sent: Tuesday, September 21, 2010 1:39 PM To: Maven Users List Subject: Re: why I do not see the parent pom file in Nexus? The path of groupId, artifactID, version is there. I just do not see the pom.xml under it. This happens to both snapshot and release. All builds are taking the right values and settings. I am assuming that the parent pom has been deployed correctly to both release and snapshot repositories. Is there any way that i can verify? Are you looking for a .pom file? Because that's how pom.xml files get renamed when you're looking at a repo. You won't actually see pom.xml there. -- Bryan This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Automating dependencyManagement enforcement
I'm hoping for advice about the best way to accomplish something in Maven. I am willing to write a plugin if that's the right answer. Here's the thing I want to accomplish: Given a Maven project that builds an ear/war, and which contains a dependencyManagement section, generally inherited from its parent or a more distant ancestor, fail the Maven build if any version chosen for inclusion in the reactor (or the ear or war, if you want to look at it that way) does not match the version declared in the dependencyManagement section. The point being, of course, to catch those cases where Maven's version choices override the ones I made in dependencyManagement, and fail fast. So, is there a way to do it now? If not, what would be the best practice for accomplishing it? Write a plugin that executes as part of the ear build? Write a plugin that executes as part of some separate analysis project, and which uses the ear artifact as a dependency or parameter? I will confess that there's part of me that thinks that this whole need should not arise, that Maven should simply decline to add anything to the reactor that matches something declared in dependencyManagement in every way except for a mismatching version. That's a separate discussion. If anyone knows whether 3.0 operates more like that, I'd be interested to know it. Thanks, -- Bryan Bryan Loofbourrow Principal Software Engineer Amdocs Interactive o:+1.206.830.7724 | m: +1.707.849.8892 | bry...@amdocs.com mailto:bry...@amdocs.com This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
RE: Automating dependencyManagement enforcement
Have you checked the possibility of using the enforcer plugin for your use case? It's a point. But really all that adds to this, that I can see, is the ability to fail the build, which is already easy to from within a plugin you're writing. This does something close: http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html I don't see how to parameterize this with the dependencyManagement values. But it does seem like a usefully rich source of code to examine. Adam Thanks, -- Bryan On Tue, 2009-12-01 at 03:09 -0800, Bryan Loofbourrow wrote: I'm hoping for advice about the best way to accomplish something in Maven. I am willing to write a plugin if that's the right answer. Here's the thing I want to accomplish: Given a Maven project that builds an ear/war, and which contains a dependencyManagement section, generally inherited from its parent or a more distant ancestor, fail the Maven build if any version chosen for inclusion in the reactor (or the ear or war, if you want to look at it that way) does not match the version declared in the dependencyManagement section. The point being, of course, to catch those cases where Maven's version choices override the ones I made in dependencyManagement, and fail fast. So, is there a way to do it now? If not, what would be the best practice for accomplishing it? Write a plugin that executes as part of the ear build? Write a plugin that executes as part of some separate analysis project, and which uses the ear artifact as a dependency or parameter? I will confess that there's part of me that thinks that this whole need should not arise, that Maven should simply decline to add anything to the reactor that matches something declared in dependencyManagement in every way except for a mismatching version. That's a separate discussion. If anyone knows whether 3.0 operates more like that, I'd be interested to know it. Thanks, -- Bryan Bryan Loofbourrow Principal Software Engineer Amdocs Interactive o:+1.206.830.7724 | m: +1.707.849.8892 | bry...@amdocs.com mailto:bry...@amdocs.com This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Automating dependencyManagement enforcement
From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Tuesday, December 01, 2009 4:27 AM To: Maven Users List Subject: Re: Automating dependencyManagement enforcement In Maven you can force a specific version to be used by adding square brackets: version[1.0]/version By doing so you'll make sure Maven doesn't override your version of choice. However, this will impact projects depending on your artifacts. Normally the version defined closest to the level you're building has preference, but forcing a specific version will change that behavior. Also, if two different versions are forced the build will fail. /Anders That's almost there, isn't it? But you're right, it's too heavy handed for what I want, which is more about maintaining control over third-party artifact versions when I build a particular assembly that packages them (war, ear, tgz, ...), than about forcing everyone who uses the artifacts of mine that went into that assembly, to make their own assemblies, to be required to insist on using those versions. Thanks, -- Bryan This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: War packaged in ear. How to exclude shared jars
I don't think it's possible to do this automatically - that would require the war project to be aware that it was going to be included in the ear project. There is a way to do manually. See http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.ht ml (or using the provided scope as you mention). This is a longstanding issue in Maven. Barend Garvelink made a page about it here: http://docs.codehaus.org/display/MAVENUSER/Solving+the+Skinny+Wars+probl em While I would prefer a more automatic solution from Maven (this is discussed extensively on the page), I do think my preferred approach is better than what's described on the official skinny wars page, especially the portion that begins Now the painful part. To quote my comment at the bottom of Barend Garvelink's page: (open self-quote)Here's what I do currently. For me, a skinny war is two projects. The war project itself, and a pom project that contains all of the dependencies. In the war project, I use warSourceIncludes (note that this is broken in the alpha-2 plugin: MWAR-182) to specify the (generally quite small) set of jars that must be packaged in the war, along with an extensive list of extensions for non-jars. I make the war project dependent on the dependency project. Then, in the ear, I add dependencies on both the war and the dependency project.(close self-quote) Better than duplicating all of the dependencies, I think. -- Bryan -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Wednesday, September 16, 2009 3:54 PM To: Maven Users List Subject: RE: War packaged in ear. How to exclude shared jars I don't think it's possible to do this automatically - that would require the war project to be aware that it was going to be included in the ear project. There is a way to do manually. See http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.ht ml (or using the provided scope as you mention). Justin From: David Weintraub [mailto:qazw...@gmail.com] Sent: Wed 9/16/2009 6:17 PM To: Maven Users List Subject: War packaged in ear. How to exclude shared jars We have multiple modules in this configuration: root aim core web* war* aimwebservices* projects ear** adinventory base jar hibernate-har ui *Builds a warfile and not a jar ** Builds the earfile that contains everything. Our module aim/web is dependent upon aim/core and that is dependent upon springframework:core. When we build, the aim.war file gets a copy of the springframework:core jarfile. However, this file is also in the ear project where an ear that contains all the jars and wars are packaged. Our developers don't want the aim:web warfile to contain the springframework:core jarfile since it is already in the overall earfile. We know we can specifically mention the dependency on springframework:core, then give its type as provided, but I am looking at an overall strategy: If a warfile will contain a jarfile that is already in the ear, we don't want it packaged in our warfile. Is that possible? -- David Weintraub qazw...@gmail.com This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: properties vs pluginManagement
-Original Message- From: Jim Sellers [mailto:jim.sell...@gmail.com] Sent: Thursday, May 14, 2009 1:38 PM To: Maven Users List Subject: properties vs pluginManagement Hi all. I've got a question for how to best configure plugins in a corporate parent pom. One way is to configure the plug in the pluginManagement section, the other is to use the properties that the plugin uses. snip I strongly prefer the pluginManagement approach. For one thing, it makes very clear that the property is intended for a plugin, and what plugin it's intended for, instead of leaving you guessing. Imagine that you were using the properties approach for a couple years, then someone handed you the job of eliminating the properties that weren't being used. -- Bryan This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Is maven so inflexible?
Fisrt I used to love maven, at this moment I'm not sure. I have a folder with a bunch of jars+wsdls+properties that need to be in the class path for my project compile in maven. How I do that without having to deploy each jar to the local repository or a remote repository? IMO, you don't. The best thing about Maven is that it brings order to the chaos that came before it, with respect to orderly management of dependencies. The existence of free-floating jars in a folder somewhere is exactly the sort of chaos that Maven was designed to bring order to. Deploy them to a repository. How do I deal with the wsdl files? Put them in a jar and deploy them to a repository? Seriously. If you need them to compile your project, then your project depends on them. Maven provides ways to declare and manage such a relationship. Why not use it, rather than seek to bypass it? -- João Miguel Pereira, PMP http://jpereira.eu http://www.linkedin.com/in/joaomiguelpereira joaomiguel.pere...@gmail.com (351) 96 275 68 58 -- João Miguel Pereira, PMP http://jpereira.eu http://www.linkedin.com/in/joaomiguelpereira joaomiguel.pere...@gmail.com (351) 96 275 68 58 This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Dependencie of war-developemant
From http://maven.apache.org/guides/introduction/introduction-to-dependency-m echanism.html: Excluded dependencies - If project X depends on project Y, and project Y depends on project Z, the owner of project X can explicitly exclude project Z as a dependency, using the exclusion element. This sounds like what you want, to exclude a transitive dependency. If it were nontransitive, but you needed it for compilation, you would use the provided scope instead, which is described on the same page. -- Bryan -Original Message- From: Robert Einsle [mailto:rob...@einsle.de] Sent: Monday, April 06, 2009 5:40 AM To: Maven Users List Subject: Dependencie of war-developemant Hy List, i'm developing an war-Application, sending Mail with commons-email. So i add commons-email as dependencie of my pom.xml --- cut --- dependency groupIdorg.apache.commons/groupId artifactIdcommons-email/artifactId version1.1/version /dependency --- cut --- but commons-email dependy on mail.jar, and activation.jar. So ist adds mail.jar and activation.jar on my Projectdependency. My Developemen-Environment is Eclipse with WTP. Here when i start my Application-Server, i recieved the Message: --- cut --- 2009-04-06 11:13:53,296 ERROR [main] ContextLoader M[initWebApplicationContext] - Context initialization failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name '/index.html' defined in ServletContext resource [/WEB-INF/spring-servlet.xml]: Initialization of bean failed; nested exception is org.springframework.beans.TypeMismatchException: Failed to convert property value of type [javax.mail.Session] to required type [javax.mail.Session] for property 'mailSession'; nested exception is java.lang.IllegalArgumentException: Cannot convert value of type [javax.mail.Session] to required type [javax.mail.Session] for property 'mailSession': no matching editors or conversion strategy found at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.doCreateBean(AbstractAutowireCapableBeanFactory.java:480) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory$1.run(AbstractAutowireCapableBeanFactory.java:409) at java.security.AccessController.doPrivileged(Native Method) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac tory.createBean(AbstractAutowireCapableBeanFactory.java:380) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObjec t(AbstractBeanFactory.java:264) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.g etSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean( AbstractBeanFactory.java:261) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:185) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Ab stractBeanFactory.java:164) at org.springframework.beans.factory.support.DefaultListableBeanFactory.pre InstantiateSingletons(DefaultListableBeanFactory.java:429) at org.springframework.context.support.AbstractApplicationContext.finishBea nFactoryInitialization(AbstractApplicationContext.java:728) at org.springframework.context.support.AbstractApplicationContext.refresh(A bstractApplicationContext.java:380) at org.springframework.web.context.ContextLoader.createWebApplicationContex t(ContextLoader.java:255) at org.springframework.web.context.ContextLoader.initWebApplicationContext( ContextLoader.java:199) at org.springframework.web.context.ContextLoaderServlet.init(ContextLoaderS ervlet.java:81) at javax.servlet.GenericServlet.init(GenericServlet.java:212) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.jav a:1172) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:992) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.j ava:4058) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4371 ) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at
RE: strange error with hopefully easy solution?
Adam,
I think the easy solution is to add the public no-args constructor to
your inner class, as it's telling you to do.
I've run into this before, surefire trying to instantiate all my
classes, including inner classes.
-- Bryan
-Original Message-
From: Adam Hardy [mailto:adam.ma...@cyberspaceroad.com]
Sent: Thursday, April 02, 2009 9:10 AM
To: Maven Users List
Subject: Re: strange error with hopefully easy solution?
Hi Martin,
you had me worried there for a moment, thought I'd emailed the wrong
list!
But anyway, I'll be surprised if you can reproduce it unless I send you
my whole
project.
Actually perhaps I should try recreating the eclipse project.
however here is the pom.xml - unless the mailing list strips off the
attachment.
There are no batchrun plug-ins, and in case the name of the class is
confusing,
the TestRunManager has nothing to do with the maven test run, except of
course
that it gets tested like all the other classes.
Just surefire, war and maven-openjpa (which affects the entity beans,
not the
Manager classes).
In case you wonder, I have no other classes in any of my dependent
projects
(atomic, testdatarepo, parent project) called TestRunManager - unless
it's hiding.
Thanks
Adam
Martin Gainty on 02/04/09 16:22, wrote:
experiencing a bit of difficulty reproducing this error
can you supply
pom.xml?
any plugins (junit-test-gen/batchrun) you may be using ?
empty org.permacode.patternrepo.basic.TestRunManagerTest Java class?
Date: Thu, 2 Apr 2009 14:26:32 +0100
From: adam.ma...@cyberspaceroad.com
To: users@maven.apache.org
Subject: strange error with hopefully easy solution?
My search results showed nothing in google or anything relevant in
the archives,
but I have an intractable error in my test batchrun, which seems to
be a
compilation problem.
The test is fine when executed in isolation.
This is what happens when I run all my test with mvn clean test:
Tests in error:
initializationError0(org.permacode.patternrepo.basic.TestRunManagerTest$
1)
The actual test file 'TestRunManagerTest' is all OK, I think. The $1
suffix is
incriminating evidence. These are the files that appear in my
directory tree:
a...@gondor:~/projects/pattern-repo$ find . -name TestRunManager*
-exec ls -la {} \;
-rw-r--r-- 1 adam adam 534 2009-02-24 10:00
./src/main/java/org/permacode/patternrepo/domain/TestRunManager.java
-rw-r--r-- 1 adam adam 8276 2009-03-03 14:36
./src/test/java/org/permacode/patternrepo/basic/TestRunManagerTest.java
-rw-r--r-- 1 adam adam 808 2009-04-02 14:09
./target/classes/org/permacode/patternrepo/domain/TestRunManager.class
-rw-r--r-- 1 adam adam 2305 2009-04-02 14:09
./target/test-classes/org/permacode/patternrepo/basic/TestRunManagerTest
$1.class
-rw-r--r-- 1 adam adam 7665 2009-04-02 14:09
./target/test-classes/org/permacode/patternrepo/basic/TestRunManagerTest
.class
-rw-r--r-- 1 adam adam 808 2009-04-02 14:08
./build/classes/org/permacode/patternrepo/domain/TestRunManager.class
-rw-r--r-- 1 adam adam 2289 2009-04-02 14:08
./build/classes/org/permacode/patternrepo/basic/TestRunManagerTest$1.cla
ss
-rw-r--r-- 1 adam adam 7699 2009-04-02 14:08
./build/classes/org/permacode/patternrepo/basic/TestRunManagerTest.class
So you can see that maven and eclipse both compile the normal test
class file,
but also create a TestRunManagerTest$1.class file. This one causes
the build to
file with this output:
initializationError0(org.permacode.patternrepo.basic.TestRunManagerTest$
1) Time
elapsed: 0.061 sec ERROR!
java.lang.Exception: Test class should have public zero-argument
constructor
at
org.junit.internal.runners.MethodValidator.validateNoArgConstructor(Meth
odValidator.java:54)
so the TestRunManagerTest$1 is obviously the result of jdk1.6.0_12
messing up
the compilation, right?
Does anyone know what I can do about it? And perhaps what I did that
caused it?
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: How to use maven-dependency-plugin to unpack-dependencies for 2 artifacts?
I've run into this too. I inferred that the dependency plugin's
unpack-dependencies goal was simply not written in a way that allows it
to be executed twice in the same project. I can see how that could
happen, if one were not pretty careful in the execute() method about
making the scratchpad controlling the scratchpad. I resorted to
splitting up Maven projects so that there's no more than one
unpack-dependencies per pom. But I too would love a better solution.
Actually, the situation could be a bit worse than I portray it above, if
Maven itself does not handle multiple executions by making separate
calls to execute, with a different set of instantiated parameters each
time. But I hope it does.
-- Bryan
-Original Message-
From: David Hoffer [mailto:dhoff...@gmail.com]
Sent: Wednesday, April 01, 2009 8:42 PM
To: users@maven.apache.org
Subject: How to use maven-dependency-plugin to unpack-dependencies for 2
artifacts?
I'm having problems figuring out how to configure the
maven-dependency-plugin to unpack 2 separate dependencies. I have 3
executions, the first uses the copy-dependencies goal to copy a swf
artifact, this seems to work.
Then I have two executions each using unpack-dependencies goal; the
first unpacks some flex config files and the second unpacks a spring
configuration file. Here is my pom:
executions
execution
idcopy-swf/id
phaseprocess-classes/phase
goals
goalcopy-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/${project.build.finalName}/
outputDirectory
includeArtifacIdscdf-as-client-testapp/includeArtifacIds
includeTypesswf/includeTypes
overWritetrue/overWrite
/configuration
/execution
execution
idunpack-config/id
goals
goalunpack-dependencies/goal
/goals
phasepackage/phase
configuration
outputDirectory${project.build.directory}/${project.build.finalName}/W
EB-INF/flex
/outputDirectory
includeArtifacIdscdf-blaze-svcs-config/includeArtifacIds
excludeTransitivetrue/excludeTransitive
excludeTypesjar,swf,pom/excludeTypes
overWriteReleasestrue/overWriteReleases
overWriteSnapshotstrue/overWriteSnapshots
/configuration
/execution
execution
idunpack-spring-config/id
goals
goalunpack-dependencies/goal
/goals
phasepackage/phase
configuration
outputDirectory${project.build.directory}/${project.build.finalName}/W
EB-INF/spring
/outputDirectory
includeArtifacIdscdf-spring-directbroker-config/includeArtifacIds
excludeTransitivetrue/excludeTransitive
excludeTypesjar,swf,pom/excludeTypes
overWriteReleasestrue/overWriteReleases
overWriteSnapshotstrue/overWriteSnapshots
/configuration
/execution
/executions
The problem is that the output folders /WEB-INF/flex /WEB-INF/spring
BOTH contain the same contents, i.e. they BOTH contain what is
supposed to be only in flex and only in spring. Furthermore BOTH
contain some content not from either artifact!?! This unexpected
content seems to be some flex content which I have no idea why it is
adding.
How can I use maven-dependency-plugin to just unpack one artifact and
put it in a separate folder?
-Dave
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Duplicate Module/Project Names in m2eclipse
On 31-Mar-09, at 11:40 AM, Jason Van Zyn wrote: As long as there is a unique coordinate Maven is fine. Aside from that having the exact same artifactId also just leads to problems. Try putting them in the same assembly, try to visually identify which one is which in different directories. For the possible aggravation I opt for what will cause the least amount of hassle. Ok, I see that -- the fact that groupIds are not included in the artifact file naming pattern means that they cannot serve as a namespace for artifactIds, in the sense of being sufficient to establish uniqueness. That leaves two issues: (1) The need for globally unique artifactIds for things that might end up in the same project. Without the com.mycompany sort of convention, that's hard to do. If I'm including two third party artifacts that happen to share an artifactId, it sounds as though I'm in some trouble. (2) Is Maven consistent about artifactId (plus version) as a unique identifier? Is that documented somewhere? Will I get errors if I try to assemble a war or ear from artifacts that have different groupIds, but the same artifactId, regardless of whether the versions match? -- Bryan This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: question regarding exclusions and indirect dependencies
FWIW, we've found it much better to manage exclusions globally, in a dependencyManagement section of the top parent pom.xml. Local exclusions sound like a challenge to maintain. Plus, I think you're expecting a kind of magic from Maven here, that it is not set up to deliver. There's only one reactor. -- Bryan -Original Message- From: Kirk Roberts [mailto:k...@languagecomputer.com] Sent: Friday, February 27, 2009 10:35 AM To: users@maven.apache.org Subject: question regarding exclusions and indirect dependencies Apologies if someone has already answered this, a link would suffice. I'm having a problem with the way maven dependencies handle exclusions. Let me set up a little example: * Project LOW_LEVEL has dependencies 1 and 2 * Project MID_LEVEL_1 has LOW_LEVEL as a dependency, but does not need dependency 2, so excludes it in its pom * Project MID_LEVEL_2 has LOW_LEVEL as a dependency, but does not need dependency 1, so excludes it in its pom * Project HIGH_LEVEL has MID_LEVEL_1 and MID_LEVEL_2 as dependencies Now I would hope that my dependency tree would include HIGH_LEVEL, MID_LEVEL_1, MID_LEVEL_2, LOW_LEVEL, 1, and 2. Unfortunately it won't. It'll look something like this: HIGH_LEVEL +- MID_LEVEL_1 | \- LOW_LEVEL | \- 1 \- MID_LEVEL_2 The problem, as I see it, is that Maven doesn't analyze all the dependencies. It sees LOW_LEVEL, grabs its dependencies at that point, and then once it sees LOW_LEVEL again it ignores it as well as any additional dependencies it might have (in this case, the LOW_LEVEL as a dependency of MID_LEVEL_2). Now clearly, my projects aren't set up as well as I'd have liked. Basically, they were made before we switched over to Maven. Totally refactoring them all so that this kind of problem doesn't happen is essentially out of the question as it would take too much time. One solution is to directly depend on the missing dependencies (in this case project 2). But clearly that is a very indirect dependency, and I would prefer to avoid this scenario if at all possible. So my question: is there some maven mode that could help me here and transverse the entire dependency tree? I'm sure it'll take much longer, but I'm willing to let that happen under certain circumstances. Or am I just in tough luck and refactoring or careful use of exclusions is necessary? Obviously, the example above it a toy scenario. In reality, we have many maven projects and the high-level projects don't use 90% of them. I'd like for people in charge of projects to locally decide what exclusions to use, but the problem above would cause the high-level projects to have to include many many indirect dependencies. I just don't think that would be very stable since not every developer should be expected to know the dependencies of every project. Any insight, common experience, or solutions (!) would be greatly appreciated, Kirk - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Managing SCM branching of large, multiple-releasable-artifacts Maven projects: ideas?
I'm working with Maven on a large project == many, many Maven projects, and multiple, separately releasable artifacts. Managing this is pretty reasonable, but the part I haven't figured out how to manage efficiently has to do with branching in my source control manager. Let's take a typical branching scenario: I want to branch the entire source tree, work on the branch for a while, release the branch artifacts under some appropriate version, then merge the changes back to the main trunk. In the meantime, it's likely enough that I've done a release from the main trunk. This is all fine, except when it comes to those version numbers in all of the myriad pom.xml files. That's a bit of a merge nightmare. I can't be the only person running into this. How do you manage this sort of thing? Thanks, -- Bryan
RE: How to inherit dependencies for compile+tests but not package them in the build ?
I have several modules that have a dependency on a PERSISTENCE module. Said Persistence module has a bunch of dependencies on jars of scope provided because they will actually be available directly in the app server's out-of-the-box libraries. My modules that depend on Persistence need to see the libraries that Persistence declares in its Pom, both for compilation and for tests (UTs are run outside of the app server), BUT since those jars are declared with scope provided in the Persistence module's Pom, the command line build fails I can see how provided is of limited usefulness in this situation, being non-transitive. So why not use compile scope and filter those jars out when you build your deployable war/ear? - 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]
MEAR-85 revisited: Transitive dependencies on ejb clients
MEAR-85 (http://jira.codehaus.org/browse/MEAR-85) is a Minor/Improvement JIRA that seems to be flying under the radar. In it, the maven-ear-plugin, faced with a dependency on an ejb-client, always packages it in the root directory of your ear, unless you explicitly tell it otherwise, for that specific artifact. defaultLibBundleDir does not affect this choice at all. In the defect, there are comments to the effect that one can easily work around this in one of two ways: (1) Putting something in the ear project pom to tell it to package the specific ejb client artifact in the ear directory of your choosing (2) changing the dependency from typeejb-client/type to classifierclient/classifier This seems viable, if a bit awkward, until you get to the case of transitive dependencies. If there are two layers of dependencies on ejb-client, and you don't control the transitive one, you're pretty much up a creek. That's the situation I have in my project. Let's suppose that I have an ear project, which depends a jar project, which depends on the client artifact of a separate ejb project, which in turn depends on another client ejb, like so: ear-project DEPENDS ON jar-project DEPENDS ON ejb-project-1-client DEPENDS ON ejb-project-2-client ejb-project-1-client's dependency on ejb-project-2-client uses typeejb-client/type. I need the ejb-project-2-client jar in the APP-INF/lib directory of my ear. So what are my options for getting it there. The only one I've thought of is to explicitly list every transitive dependency, either in every ear I build that includes jar-project, or in jar-project itself, in order to either force the packaging location or force the nature of the dependency. Having to enumerate transitive dependencies, one level up, seems to go against everything Maven is about. In the MEAR-85 comments, I propose a fix, which is to add defaultEjbClientBundleDir, so that Maven users get the same sort of control over ejb client jars, as they currently have over regular jars. An advantage of this would be that it could be done in completely back compatible fashion. Another advantage is that the maven-ear-plugin seems poised to accept such a thing; it would just be a matter of adding a parameter and passing it along, in place of null, when the object representing the ejb client is constructed. Does anyone see, under the existing ear plugin, and with the assumption of no control over ejb-project-1-client's dependencies, any way to work around this, that does not require enumerating transitive dependencies? Thanks, -- Bryan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: A unit test error with maven
with mvn test I got error
junit.framework.AssertionFailedError: Class Order$OrderChargeTest has
no
public constructor TestCase(String name) or TestCase()
If memory serves, I think the solution is to make sure all your classes
(inner included) have a no-args constructor (or, as appropriate, a
constructor-with-String). I think surefire might be force-instantiating
all of the classes. I also seem to recall that only certain surefire
versions exhibit this behavior.
-- Bryan
-Original Message-
From: flyingtiger [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 21, 2007 4:59 PM
To: users@maven.apache.org
Subject: A unit test error with maven
I have a unit test that I want to run run setUp() and tearDown() code
once
for all of my tests. I use an inner class as a wrapper to do the job. it
worked fine with eclipse but with mvn test I got error
junit.framework.AssertionFailedError: Class Order$OrderChargeTest has
no
public constructor TestCase(String name) or TestCase()
anybody as any idea?
my code here:
...
public class TestDataAccess extends TestCase {
private static final Logger logger = LoggerFinder.getLogger();
protected static DataAccess dao = new DataAccess();;
public TestDataAccess(String testName) {
super(testName);
// TODO Auto-generated constructor stub
}
public static class Wrapper extends TestSetup {
public Wrapper(Test arg0) {
super(arg0);
// TODO Auto-generated constructor stub
}
public Wrapper(TestSuite suite){
super(suite);
}
public void setUp() throws Exception {
prepareTestData();
}
public void tearDown() throws Exception {
destroyTestData();
}
}
public static Test suite() {
TestSuite suite = new TestSuite();
suite.addTest(new TestDataAccess(testGetAdvertiser));
suite.addTest(new
TestDataAccess(testGetAdvertiserIdByDfpId));
Wrapper wrapper = new Wrapper(suite);
return wrapper;
}
public void testGetAdvertiser() throws Exception {
int id = 10;
GorillaAdvertiser gAdvertiser = dao.getAdvertiser(id);
assertEquals(10, gAdvertiser.getId());
assertEquals(http://www.test.com;,
gAdvertiser.getUrl());
assertEquals(Test SF ID,
gAdvertiser.getSalesforceObjectId());
assertEquals(Test Advertiser, gAdvertiser.getName());
}
public void testGetAdvertiserIdByDfpId() throws Exception {
int dfpId = 1397500;
String id = dao.getAdvertiserIdByDfpId(dfpId);
assertEquals(2, id);
}
private static void prepareTestData() throws Exception {
logger.info(preparing data...);
dao.establishConnections();
prepareAdvertiser();
}
private static void destroyTestData() throws Exception {
logger.info(destroying data...);
destroyAdvertiser();
dao.closeConnections();
}
private static void prepareAdvertiser() throws Exception {
String sql = insert into advertisers (id, name, url,
dfp_id,
salesforce_object_id)
+ values (10, 'Test Advertiser',
'http://www.test.com', 10,
'Test SF ID');
PreparedStatement ps =
dao.getAdOpsConn().prepareStatement(sql);
ps.executeUpdate();
ps.close();
dao.getAdOpsConn().commit();
}
private static void destroyAdvertiser() throws Exception {
String sql = delete from advertisers where id =
10;
PreparedStatement ps =
dao.getAdOpsConn().prepareStatement(sql);
ps.executeUpdate();
ps.close();
dao.getAdOpsConn().commit();
}
}
error message:
Running com.gorillanation.dartaip.TestDataAccess$Wrapper
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.031
sec
FA
ILURE!
warning(junit.framework.TestSuite$1) Time elapsed: 0 sec FAILURE!
junit.framework.AssertionFailedError: Class
com.gorillanation.dartaip.TestDataAc
cess$Wrapper has no public constructor TestCase(String name) or
TestCase()
I searched the internet found this
http://www.oreillynet.com/onjava/blog/2004/12/where_should_your_unit_tes
ts_g.html
I did exactly as suggested but didn't help.
anybody any idea?
--
View this message in context:
http://www.nabble.com/A-unit-test-error-with-maven-tf4308575s177.html#a1
2265586
Sent from the Maven - Users mailing list archive at Nabble.com.
RE: Parent POM, properties and scm problem
I'm wondering if the following would work:
- Make your organizational pom project. Don't define any module entries in
it.
- Have all of your projects depend on it as a parent
- Build and install your organizational pom to a central repository
accessible to all of your projects.
I'm thinking that you can then independently build and deploy your
organizational pom by itself, and have your projects use it, from the
repository, as a parent for definition purposes, though not build purposes.
I'd be interested to know whether this works. It seems useful.
-- Bryan
-Original Message-
From: Oscar Picasso [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 01, 2007 10:31 AM
To: Maven Users List
Subject: Re: Parent POM, properties and scm problem
The current Maven behaviour is fine for multimodule projects.
However I am trying to write a organizational POM that all my projets would
inherited and wanted to avoid duplication of the scm section.
So in case of independent projects it does not make sense to put all them
inside the same trunk.
I guess currently I cannot avoid this duplication.
On 7/31/07, Eric Redmond [EMAIL PROTECTED] wrote:
Maven does this so that child module's scm can be defined once in the
parent.
scm
connectionscm:svn:https://url/project/trunk
/scm
modules
moduleChild
Then the Child module's scm url is automatically set as:
scm
connectionscm:svn:https://url/project/trunk/Child
/scm
Which is the convention for a multi-module project.
If your Child project has to be seperate, with it's own trunk, etc. I
would suggest (if svn) using svn:externals to access the child under the
parent project. Since it ownly appends the name on a multi-module project,
I'm trying to figure out how you locally check out your project... perhaps
create a trunks-style setup in your version control would be best?
Eric
On 7/30/07, Oscar Picasso [EMAIL PROTECTED] wrote:
I have also noticed the same behavior with the project url, the sit url
and
the scm url even if in the effective the corresponding properties are
correct (without the artifactId appended).
On 7/30/07, Oscar Picasso [EMAIL PROTECTED] wrote:
Hi,
In the parent POM I have the following:
[...]
properties
scmConnection
http://localhost/repos/repo/${groupId}/${artifactId}/trunk
http://localhost/repos/repo/$%7BgroupId%7D/$%7BartifactId%7D/trunk
/scmConnection
/properties
scm
connection${scmConnection}/connection
developerConnection${scmConnection}/developerConnection
/scm
[...]
The child POM has nothing expect mandatory elements and the reference
to
the parent POM. Both the child and the parent are snapshots. The
parent
POM
has been deployed to the remote repository.
When I run mvn help:effective-pom on the child project, I get:
[...]
scm
connection
http://localhost/repos/repo/com.opicasso/Child/trunk/Child
/connection
developerConnection
http://localhost/repos/repo/com.opicasso/Child/trunk/Child
/developerConnection
/scm
[..]
I would have expected:
[...]
scm
connectionhttp://localhost/repos/repo/com.opicasso/Child/trunk
/connection
developerConnection
http://localhost/repos/repo/com.opicasso/Child/trunk
/developerConnection
/scm
[..]
Why does maven happen the child artifactId to the connections? Does
maven
merge the parent scm connections with the children ones ? But in the
current
case the child has no scm connections defined in its pom.
How to get rid of this extra artifactId?
Thanks
Oscar
--
Eric Redmond
http://blog.propellors.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Creating Skinny WARs still up to date?
is there still no better way to refer to libraries in an EAR from a WAR than outlined here: http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html Two points: - There has been some recent activity in http://jira.codehaus.org/browse/MWAR-21 that you may find to be of interest. - That page suggests re-listing all of the non-packaged dependencies of the war, in the ear pom. I've found it much more convenient to put those dependencies in a separate jar project, and include dependencies on that project in both the war and ear poms. -- Bryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 25, 2007 3:43 PM To: users@maven.apache.org Cc: [EMAIL PROTECTED] Subject: Creating Skinny WARs still up to date? Hi, is there still no better way to refer to libraries in an EAR from a WAR than outlined here: http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html It's still a hack, IMHO. Andreas Ebbert-Karroum Senior Software Design Engineer - Nokia Siemens Networks / Operations Business Software phone: +49-211-94123928, fax: +49-211-94123838 Heltorfer Straße 1, 40472 Düsseldorf, Germany Nokia Siemens Networks GmbH Co. KG * Sitz der Gesellschaft: München / Registered office: Munich * Registergericht: München / Commercial registry: Munich, HRA 88537 * WEEE-Reg.-Nr.: DE 52984304 Persönlich haftende Gesellschafterin / General Partner: Nokia Siemens Networks Management GmbH * Geschäftsleitung / Board of Directors: Joachim Malterer, Lydia Sommer * Sitz der Gesellschaft: München / Registered office: Munich * Registergericht: München / Commercial registry: Munich, HRB 163416 This message is confidential. If you have received this message in error, please delete it from your system. You should not copy it for any purpose, or disclose its contents to any other person. Internet communications are not secure and therefore Nokia Siemens Networks GmbH Co. KG does not accept legal responsibility for the contents of this message as it has been transmitted over a public network. Thank you. Nokia Siemens Networks GmbH Co. KG is a German Company. Further information about the Company is available from its offices at Heltorferstrasse 1, D-40472, Düsseldorf, Germany and from the website at http://www.nsn.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: Using Maven with Eclipse well: mvn eclipse:eclipse and nested projects
An interesting message on the Maven User's list, especially for those (Daryoush!) who have expressed frustration about the inability to mass-perforce-enable all those Eclipse projects that you get when using mvn eclipse:eclipse. I'm not sure I understand completely where he's coming from, but basically it seems like a way to maintain an RRmodules Eclipse project, for the purpose of SCM, and also a bunch of subprojects, for mvn eclipse:eclipse. I'm not positive that this mixture of things will cause Perforce to always check things out automatically if the RRmodules project is Perforce-enabled and the others are not, but it seems worth a try, because it seems to be working for this guy, and I doubt he'd be so enthusiastic if that part didn't work. The downside, which I have discovered myself by accident, is that with this setup you can no longer mass-import Eclipse projects at the RRmodules level, but instead have to do your importing iteratively, one level down. Not a big deal for ongoing updates, but somewhat of a pain the very first time. Happy 4th! Especially to Balazs, who's actually working today, presumably because his East European upbringing didn't instill an irresistable compulsion to grill something outdoors on this special day. -- Bryan -Original Message- From: Greg Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 04, 2007 5:53 AM To: Maven Users List Subject: Re: Using Maven with Eclipse well: mvn eclipse:eclipse and nested projects Alan Kent wrote: Q: Is there any way to make mvn eclipse:elipse generate a .project file for the root directory as well as each module? That way I can check out the whole project tree from the root and have a project per pom file. Not that I know of, but this works for me: 1. Check out the parent module into your workspace. 2. mvn eclipse:eclipse to create the various .project and .classpath files in the sub-modules. 3. Switch to the Java perspective in Eclipse. 4. Select the parent module and hit F5 to refresh (just for grins). 5. Choose File-Import..., Existing Projects into Workspace, and browse in your workspace into your parent module. 6. Select one of the sub-modules, make sure Copy projects into workspace is /not/ checked, and hit Finish. 7. Lather, rinse, and repeat steps 5 and 6 with the other submodules. In this way, you can do all of your SCM in Eclipse via the parent module, yet play with the submodules as proper Java projects. As far as I know, this is the recommended way to develop a multi-module project with Eclipse. Someone please correct me if I'm wrong. -- -Greg - 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: Using Maven with Eclipse well: mvn eclipse:eclipse and nested projects
Sorry. Not intended for the list. Apologies. -Original Message- From: Bryan Loofbourrow [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 04, 2007 2:43 PM To: *Qpass - Content Catalog Discussion Cc: Maven Users List Subject: FW: Using Maven with Eclipse well: mvn eclipse:eclipse and nested projects An interesting message on the Maven User's list, especially for those (Daryoush!) who have expressed frustration about the inability to mass-perforce-enable all those Eclipse projects that you get when using mvn eclipse:eclipse. I'm not sure I understand completely where he's coming from, but basically it seems like a way to maintain an RRmodules Eclipse project, for the purpose of SCM, and also a bunch of subprojects, for mvn eclipse:eclipse. I'm not positive that this mixture of things will cause Perforce to always check things out automatically if the RRmodules project is Perforce-enabled and the others are not, but it seems worth a try, because it seems to be working for this guy, and I doubt he'd be so enthusiastic if that part didn't work. The downside, which I have discovered myself by accident, is that with this setup you can no longer mass-import Eclipse projects at the RRmodules level, but instead have to do your importing iteratively, one level down. Not a big deal for ongoing updates, but somewhat of a pain the very first time. Happy 4th! Especially to Balazs, who's actually working today, presumably because his East European upbringing didn't instill an irresistable compulsion to grill something outdoors on this special day. -- Bryan -Original Message- From: Greg Thompson [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 04, 2007 5:53 AM To: Maven Users List Subject: Re: Using Maven with Eclipse well: mvn eclipse:eclipse and nested projects Alan Kent wrote: Q: Is there any way to make mvn eclipse:elipse generate a .project file for the root directory as well as each module? That way I can check out the whole project tree from the root and have a project per pom file. Not that I know of, but this works for me: 1. Check out the parent module into your workspace. 2. mvn eclipse:eclipse to create the various .project and .classpath files in the sub-modules. 3. Switch to the Java perspective in Eclipse. 4. Select the parent module and hit F5 to refresh (just for grins). 5. Choose File-Import..., Existing Projects into Workspace, and browse in your workspace into your parent module. 6. Select one of the sub-modules, make sure Copy projects into workspace is /not/ checked, and hit Finish. 7. Lather, rinse, and repeat steps 5 and 6 with the other submodules. In this way, you can do all of your SCM in Eclipse via the parent module, yet play with the submodules as proper Java projects. As far as I know, this is the recommended way to develop a multi-module project with Eclipse. Someone please correct me if I'm wrong. -- -Greg - 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: XML parser versions
I'm assuming that you have your preferred version of xerces listed in a dependencyManagement section of your root pom.xml. That's a good thing, but it's not a panacea because of Maven 2's oddball rules about what version wins, based on some sort of distance from the invoker rule. I think there's a JIRA entry asking for better behavior there, and I haven't checked on it lately so I don't know the status. I've dealt with a similar issue by putting an explicit dependency on the preferred artifact version into the pom.xml of the project that generates the artifact into which the subsidiary artifact will be packaged. That's an ear, in my case. That works because such dependencies always win the version competition, but it is a bit of a hack. -- Bryan -Original Message- From: Chris Searle [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 03, 2007 2:04 AM To: Maven Users List Subject: Re: XML parser versions I suggest grepping your local repository for 1.2.3. My guess would be that you'll find a reference to it in a pom.xml file somewhere in there. slippen:~/.m2/repository chris$ grep -r -l 1.2.3 . | grep pom$ ./commons-jxpath/commons-jxpath/1.2/commons-jxpath-1.2.pom ./xerces/xerces/1.2.3/xerces-1.2.3.pom So - it is present in xerces itself and commons-jxpath. So - I have added the following again: dependency groupIdcommons-jxpath/groupId artifactIdcommons-jxpath/artifactId version1.2/version exclusions exclusion groupIdxerces/groupId artifactIdxerces/artifactId /exclusion /exclusions /dependency Ran a mvn clean, then a site then a test. site still shows xerces xerces 1.2.3 required under Project Transitive Dependencies test still fails due to the wrong parser being used -Original Message- From: Chris Searle [mailto:[EMAIL PROTECTED] Sent: Monday, July 02, 2007 5:55 AM To: users@maven.apache.org Subject: XML parser versions OK. A little confused here. I have three maven projects - all were running just fine. All are spring based - and I wanted to add some simple aspect programming to one of them. So - I changed the spring config file to start like: ?xml version=1.0 encoding=UTF-8? beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:aop=http://www.springframework.org/schema/aop; xmlns:tx=http://www.springframework.org/schema/tx; xsi:schemaLocation=http://www.springframework.org/schema/ beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd; aop:spring-configured/ Now - for this to be parseable you need a recent parser - so - I added the following to the pom: dependency groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.8.1/version /dependency This project works just fine. mvn test completes, mvn install works. All is well and good. Even the spring aop stuff works fine - using the aspectjweaver.jar :) Projects 2 and 3 depend on project 1. Both of these have the exact same start to their spring XML minus the aop:spring-configured line since they do not directly have aop (they both use the spring config of project1 for that part - loaded from the classpath). Both projects 2 and 3 have the same xerces dependency in their poms. mvn test and mvn install work just fine on project 2. But project 3 fails. It gives: testGetActiveMembersReport(net.chrissearle.export.TestExportService) Time elapsed: 5.424 sec ERROR! org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: L ine 9 in XML document from class path resource [project1.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc- complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'aop:spring-configured'. Now - this is apparently due to parser version. mvn dependency:build-classpath shows only xerces 2.8.1. But - mvn site builds a site page where the dependencies show: For compile: xerces xercesImpl 2.8.1 - jar but - for Project Transitive Dependencies xerces xerces 1.2.3 - jar However - the Project Dependency Graph only lists xerces:xercesImpl:jar (the direct dependency) - not the xerces:xerces:jar. I just can't figure out what is pulling in the older xerces - and I need to get it into an exclusion somehow. Any hints on how to find out what is pulling it in? Chris Searle [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Chris Searle [EMAIL
RE: XML parser versions
I suggest grepping your local repository for 1.2.3. My guess would be that you'll find a reference to it in a pom.xml file somewhere in there. -Original Message- From: Chris Searle [mailto:[EMAIL PROTECTED] Sent: Monday, July 02, 2007 5:55 AM To: users@maven.apache.org Subject: XML parser versions OK. A little confused here. I have three maven projects - all were running just fine. All are spring based - and I wanted to add some simple aspect programming to one of them. So - I changed the spring config file to start like: ?xml version=1.0 encoding=UTF-8? beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:aop=http://www.springframework.org/schema/aop; xmlns:tx=http://www.springframework.org/schema/tx; xsi:schemaLocation=http://www.springframework.org/schema/ beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd; aop:spring-configured/ Now - for this to be parseable you need a recent parser - so - I added the following to the pom: dependency groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.8.1/version /dependency This project works just fine. mvn test completes, mvn install works. All is well and good. Even the spring aop stuff works fine - using the aspectjweaver.jar :) Projects 2 and 3 depend on project 1. Both of these have the exact same start to their spring XML minus the aop:spring-configured line since they do not directly have aop (they both use the spring config of project1 for that part - loaded from the classpath). Both projects 2 and 3 have the same xerces dependency in their poms. mvn test and mvn install work just fine on project 2. But project 3 fails. It gives: testGetActiveMembersReport(net.chrissearle.export.TestExportService) Time elapsed: 5.424 sec ERROR! org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: L ine 9 in XML document from class path resource [project1.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc- complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'aop:spring-configured'. Now - this is apparently due to parser version. mvn dependency:build-classpath shows only xerces 2.8.1. But - mvn site builds a site page where the dependencies show: For compile: xerces xercesImpl 2.8.1 - jar but - for Project Transitive Dependencies xerces xerces 1.2.3 - jar However - the Project Dependency Graph only lists xerces:xercesImpl:jar (the direct dependency) - not the xerces:xerces:jar. I just can't figure out what is pulling in the older xerces - and I need to get it into an exclusion somehow. Any hints on how to find out what is pulling it in? Chris Searle [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can modules by specified with coordinates instead of a simple name/path?
I wouldn't think you could do anything like that. The coordinates you describe tell you where to find something in the repository, but they're no help finding source code. module tells Maven where to find the source code so it can build the project if necessary. Seems unavoidable that Maven would need to know that. -- Bryan -Original Message- From: Steven Cummings [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 20, 2007 1:34 PM To: Maven Users List Subject: Can modules by specified with coordinates instead of a simple name/path? I would like to be able to have a parent POM that specifies its child modules with coordinates, just like dependencies and parent POMs are specified. So instead of modulea/module where that module must exist as an immediate sub-folder, I could have module artifactIda/artifactId groupIdb/groupId version1.0/version /module where the parent and modules can be stored more or less independently and find each other using maven coordinates. Is this possible? I have seen no documentation or discussion describing this, so I figure you can't do it. As always though, I had to ask. Thanks! -- Steven Cummings - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: install:install-file demanding a valid lifecycle phase ...
Well, you have some odd spaces in both of your examples. For example, no space between gwt and -, and a space between the = after version in the first example. -- Bryan -Original Message- From: Kerry Sainsbury [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 19, 2007 5:15 PM To: users@maven.apache.org Subject: install:install-file demanding a valid lifecycle phase ... Hi Folks, I'm a Maven newbie (sorry!) and I can't figure out what I'm doing wrong with install:install-file using Maven 2.0.6 I'm trying to install a jar file from the GWT toolkit, on Windows XP, but keep getting told Invalid task 'X': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal, where X is whatever value I pass to the first -D parameter passed. eg: C:\work\snews2\snews-gwtmvn install:install-file -DgroupId=com.google.gwt-DartifactId=gwt-servlet -Dversion= 1.4.10 -Dpackaging=jar -Dfile=gwt-servlet.jar [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'install'. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'com.google.gwt': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal Even when I make up some dummy -D property, that too is used to generate the error: C:\work\snews2\snews-gwtmvn install:install-file -Dmmm=77 -DgroupId= com.google. gwt -DartifactId=gwt-servlet -Dversion=1.4.10 -Dpackaging=jar -Dfile=gwt-servlet .jar [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'install'. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task '77': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal [INFO] Does anybody have any idea at all? I've googled for Africa, but can't find anything sensible. Thanks, Kerry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Version number propogation
I believe that you are correct about not being able to parameterize the
project parent tag, or so a co-worker tells me. He conjectures that the
parent resolution is required before resolution of property names. That
makes sense, since, in general, the value you're looking for could be
defined in the parent pom, but it does create a situation in which it
doesn't seem possible to have your consistent version number for a
multimodule project in a single place. I suspect that the official answer is
that you're the only place you're supposed to impose a single version number
on a multimodule project is via the release plugin, which copies the same
version number into everything you're releasing. It does seem as though
parameterzing parent version tags within a multimodule project might
interfere with the release plugin, or vice versa, even if it were allowed.
-- Bryan
-Original Message-
From: Martin Gilday [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 06, 2007 12:50 PM
To: Maven Users List
Subject: Re: Version number propogation
You can use ${pom.version} in some circumstances. I think a parent tag
might be a case where you can't though.
- Original message -
From: Howard Lewis Ship [EMAIL PROTECTED]
To: Maven Users List users@maven.apache.org
Date: Sun, 6 May 2007 08:30:45 -0700
Subject: Version number propogation
I have a project with multiple modules.
I'm keeping the version numbers synced.
This ends up with a lot of repetition of the version number:
artifactIdtapestry-core/artifactId
packagingjar/packaging
version5.0.5-SNAPSHOT/version
parent
groupIdorg.apache.tapestry/groupId
artifactIdtapestry-project/artifactId
version5.0.5-SNAPSHOT/version
relativePath../tapestry-project/pom.xml/relativePath
/parent
Worse yet, those same version numbers are creeping into documentation
and
into project archetypes.
How would I go about externalizing the version number so that it appears
just once? I'd love to have something like I used to do in Ant ... a
build.properties file that defines the version number.
Also, is there a general way to include POM properties inside APT
documents
and/or site.xml?
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.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: Problem with ear-plugin
Peter, Happy New Year. According to the page here: http://maven.apache.org/plugins/maven-ear-plugin/modules.html there is no such thing as warModule. Do you want webModule? That's what I've used successfully for wars. Also note that webModule does not have an includeInApplicationXml flag. I think that stack trace would be generated for any noncomformant XML configuration. -- Bryan -Original Message- From: Petar Tahchiev [mailto:[EMAIL PROTECTED] Sent: Monday, January 01, 2007 2:01 PM To: Maven Users List Subject: Problem with ear-plugin Hi guys, Happy New Year to all of you. I have the following problem: I have a project in which I produce some jars and wars which get installed in the local repository. The in one of my modules I want to package some of those jars and wars into an ear archive, so I do this in my pom: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId configuration modules jarModule groupIdorg.my.test.jarModules/groupId artifactIdjar-module/artifactId includeInApplicationXmltrue/includeInApplicationXml /jarModule warModule groupIdorg.my.test.warModules/groupId artifactIdwar-module/artifactId includeInApplicationXmltrue/includeInApplicationXml /warModule /modules /configuration /plugin /plugins /build but when running the build I get the following error: [INFO] Failed to configure plugin parameters for: org.apache.maven.plugins:maven-ear-plugin:2.2 Cause: Class 'org.apache.maven.plugin.ear.EarModule' cannot be instantiated After running mvn with the -e option I get this one: org.apache.maven.lifecycle.LifecycleExecutionException: Error configuring: org.apache.maven.plugins:maven-ear-plugin. Reason: Unable to parse the created DOM for plugin configuration at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals( DefaultLifecycleExecutor.java:563) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle (DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal( DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures (DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:273) I read in the archive to try replacing the jarModule tag with javaModule, but it didn't work - I still get the same exception. :-( So, does anyone have an idea, what is going on here? P.S. Do I need to include only modules that are submodules of the pom that builds the ear, i.e. is it obligatory for them to be submodules of my module, or they just have to be in the repository? Thanks for any help. -- Regards, Petar! Karlovo, Bulgaria. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with ear-plugin
A second point, one you may already know but it's not clear from your example. In general, I am pretty sure that the xxxModule configurations are only necessary when you want to configure something about that module's inclusion. The main way you tell the ear pom what you want in the ear is by including dependencies on the artifacts you want packaged up, and, yes, those dependencies are pulled from the repository. -- Bryan -Original Message- From: Petar Tahchiev [mailto:[EMAIL PROTECTED] Sent: Monday, January 01, 2007 2:01 PM To: Maven Users List Subject: Problem with ear-plugin Hi guys, Happy New Year to all of you. I have the following problem: I have a project in which I produce some jars and wars which get installed in the local repository. The in one of my modules I want to package some of those jars and wars into an ear archive, so I do this in my pom: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId configuration modules jarModule groupIdorg.my.test.jarModules/groupId artifactIdjar-module/artifactId includeInApplicationXmltrue/includeInApplicationXml /jarModule warModule groupIdorg.my.test.warModules/groupId artifactIdwar-module/artifactId includeInApplicationXmltrue/includeInApplicationXml /warModule /modules /configuration /plugin /plugins /build but when running the build I get the following error: [INFO] Failed to configure plugin parameters for: org.apache.maven.plugins:maven-ear-plugin:2.2 Cause: Class 'org.apache.maven.plugin.ear.EarModule' cannot be instantiated After running mvn with the -e option I get this one: org.apache.maven.lifecycle.LifecycleExecutionException: Error configuring: org.apache.maven.plugins:maven-ear-plugin. Reason: Unable to parse the created DOM for plugin configuration at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals( DefaultLifecycleExecutor.java:563) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle (DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal( DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures (DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:273) I read in the archive to try replacing the jarModule tag with javaModule, but it didn't work - I still get the same exception. :-( So, does anyone have an idea, what is going on here? P.S. Do I need to include only modules that are submodules of the pom that builds the ear, i.e. is it obligatory for them to be submodules of my module, or they just have to be in the repository? Thanks for any help. -- Regards, Petar! Karlovo, Bulgaria. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dependency groups?
To answer your original question... I'm not sure I'd recommend this approach, but (I just tried it and) it works... you can create a project with packagingpom which has dependencies, and then have your project _depend_ on that pom, so that you pick up those dependencies transitively. Not only does this technique work, but I think it's both sensible and useful, any time you want separately characterize or expose a separate type of dependencies. In particular, I've found it helpful for the currently-not-really-addressed-in-Maven-2 use case of packaging wars in an ear, with (most) dependent jars packaged in the ear. You make a dependency project for the things you want packaged in the ear, and have the war project and the ear project depend on the dependency project. The only difficulty with this is that the exclusion of the jars from the war is an awkward business, because you only have includes and excludes to work with, with only * as wildcards. Regular expressions would clean that right up, and I've requested such a change here: http://jira.codehaus.org/browse/MWAR-81 I've found other uses for this too. I think it's a neat trick. -- Bryan -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Friday, December 22, 2006 5:34 PM To: Maven Users List Subject: Re: Dependency groups? On 12/22/06, MikeKey [EMAIL PROTECTED] wrote: Forgive a likely newbie question but I've not found anything outside a hacked parent pom to get something like this to work. Is there any way to setup a pre-defined set of dependencies to include in a given pom? For example, Hibernate requires several jars to be included as dependencies to a project using it...is there a sane way in maven to define a hibernate-dependencies.pom or something like that and include it in my pom.xml? To make a reusable set of dependencies? Without seeing the project, it's hard to make a recommendation. If you're finding that you have the same dependencies in a lot of places, is it possible that some code could be moved into a separate module? Then you'd depend on that jar, and get thost dependencies transitively. To answer your original question... I'm not sure I'd recommend this approach, but (I just tried it and) it works... you can create a project with packagingpom which has dependencies, and then have your project _depend_ on that pom, so that you pick up those dependencies transitively. For example dependency groupIdnet.wsmoak/groupId artifactIddependencies-only/artifactId version1.0-SNAPSHOT/version typepom/type /dependency -- Wendy - 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]
Ear Plugin: Transitive dependencies and sharing jars among wars
I'm looking to package multiple WAR files in an EAR, using the EAR plugin. I'd like to have the dependent jars in the EAR, not the WARS, so that they can be shared. That can be accomplished by using warSourceExcludes to exclude the jars from the wars, and copying the dependencies from the WAR poms to the EAR pom. But by doing that, one loses one of the primary advantages of Maven, the ability to manage transitive dependencies automatically. Ideally, there would be something in the EAR plugin that caused transitive dependencies from included WAR artifacts to be packaged in the ear, but I don't see anything like that in the documentation. Is there any way to do this? Thanks.
RE: How do I add a directory to the classpath visible to a Maven plugin?
A plausible and clever idea, but it doesn't work. Nor did supplying a URLClassLoader with the directory. I'm guessing that there's code somewhere in the new Kodo that just walks the class path property and does its own thing to find the license file. I did some experimentation with invoking the enhancer from the command line using kodoc. If you put the bea.license file in a directory and add that directory to the classpath, everything works fine. If you put the bea.license file into a jar, at the root: [] jar -tf bea-license.jar META-INF/ META-INF/MANIFEST.MF License.bea ...and put that jar on the classpath, Kodo does not find the license file. So I think I'm back to the original problem: jars won't do it; how do I add an actual directory to a Maven classpath? -Original Message- From: Barrie Treloar [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 3:32 PM To: Maven Users List Subject: Re: How do I add a directory to the classpath visible to a Maven plugin? Specifically, I am trying to use BEA Kodo 4, the enhancer, and it appears to require that the directory containing the license.bea file be on the classpath. From my understanding stuff on the classpath is treated the same, regardless of whether it came from a jar or a directory. So if you put the license.bea inside a jar file so that it was at the root directory of the archive it should be the same as attaching a directory. Then you could install that archive into your repository as dependecy groupIdcom.bea/group artifactIdkodo/artifactId classifierlicense/classifier /dependency and then users of your plugin would need to have installed into their local repository (or their company internal repository) the license jar. I'm guessing that you might even be able to check that this dependency exists and provide a reasomable error message from your plugin if it doesn'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]
How do I add a directory to the classpath visible to a Maven plugin?
Sorry if this is an elementary question, I am learning about Maven (2), but I've certainly tried to do my homework. I have a need to add a directory to the classpath that's visible to a plugin I'm writing, and I don't see how to do it. All I see is stuff that seems to assume: - Maven controls the classpath, which it constructs from artifacts on which you depend. - You can make your own artifact types, and specify that they be added to the classpath - It appears that an artifact is assumed to be a file. - That's the only way to get something onto the classpath. I am hoping, of course, that at least one of these statements is false, and that there's a way to add a directory (not a file) to a classpath. Specifically, I am trying to use BEA Kodo 4, the enhancer, and it appears to require that the directory containing the license.bea file be on the classpath. I grant that I could do this by hacking up a ClassLoader and invoking the enhancer with that, or invoking the enhancer in a different JVM so that I gain control over that classpath, but those approaches have other difficulties, and certainly doesn't seem like the Maven Way. I figure there's a right way to do this; I just haven't discovered it in the documentation. Thanks for any help or guidance.
