RE: force maven to redownload/refresh released dependencies
On Sex, 06 Ago 2010, Haszlakiewicz, Eric wrote: I'm AGREEING with you that the solution is to wipe out the local artifact! But you can only do that once you know there is something wrong. How do you detect that the artifact has changed? You don't have to, because released artifacts do not change[0]. [0]Unless someone intentionally screws up. And it is no accidental screw up, I think all artifact managers forbid redeploying a non snapshot version. So in order to that happen, someone must circunvent the normal deploying route. If someone really needs to do so, then that person may simply warn everyone that might be affected. That is feasible, because such situation should never happen in any of the public repositories, being limited to the organization repository. -- Be circumspect in your liaisons with women. It is better to be seen at the opera with a man than at mass with a woman. -- De Maintenon Eduardo M KALINOWSKI edua...@kalinowski.com.br - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Help with Ant task
On 04/26/2010 06:41 PM, Lorenzo Thurman wrote: I'm just learning both Maven and Ant. I have a couple of weeks of working with Maven, but not I need to get it execute and Ant task. I know nothing about Ant, but using the antrun plugin for Maven, I've got things to the point where the task attempts to execute, but fails because it can't find a class which is contained within a jar file. The jar containing the class is actually referenced in the build.xml via classpath and classname tags. It seems to follow that if the Ant task can find the jar when running under Ant, it should do so when running via Maven, but that's not the case. So, my question is how do I pass a classpath variable to an Ant task from Maven? I case there are fundamental flaws in my approach, I've included both my pom.xml and the build.xml that should be executed. List the jar file with the custom task as a dependency of the plugin: project modelVersion4.0.0/modelVersion groupIdacquitygroup.AMA/groupId artifactIdAMA/artifactId version1/version profiles profile idprimary/id build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-antrun-plugin/artifactId configuration tasks ant antfile=src/AMA/modules/build.xml / /tasks /configuration dependencies dependency artifactId... ... /dependency /dependencies /plugin /plugins /build /profile /profiles /project -- Someday we'll look back on this moment and plow into a parked car. -- Evan Davis Eduardo M KALINOWSKI edua...@kalinowski.com.br - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Including a local jar in the build
Arrowx7 wrote:
Hello,
I migrated from ant to maven and just wanted to include the jars (for now
before we set up a repo).
repositories
repository
idproject/id
nameProject Maven Repository/name
layoutdefault/layout
urlfile://${basedir}/src/main/webapp/WEB-INF/lib/url
/repository
/repositories
Then I write dependencies, such as for apache commons logging
dependency
groupIdorg.apache.commons/groupId
artifactIdcommons-logging-1.1.1/artifactId
version/version
/dependency
It complains because it wants the version, if I give it the version it says
it can't find it. How do I just get this jar in there without setting up
your own repository and installing it to repository, generating version
etc... I just want to simply linclude that file in there. I realize that
it's bad format, but how do I tell it to just grab that file regardless of
version.
Use the system scope for your dependencies.
--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Howto find out which POM refers to some jar ?
Anders Hammar wrote: I was suggesting the Dependency Hierarchy screen of the pom editor in m2e. Which is a visual representation of what is obtained with mvn dependency:tree -- Eduardo M KALINOWSKI edua...@kalinowski.com.br - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: build problem
On Ter, 02 Mar 2010, kolaloka wrote:
and this is the output:
bal...@black:/usr/local/src/geotools-2.5.8$ mvn compile
[snip]
[INFO] Building imagemosaic-jdbc module
[INFO]task-segment: [compile]
[INFO]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] snapshot org.h2database:h2:1.0-SNAPSHOT: checking for updates from
maven2-repository.dev.java.net
[INFO] snapshot org.h2database:h2:1.0-SNAPSHOT: checking for updates from
osgeo
[INFO] snapshot org.h2database:h2:1.0-SNAPSHOT: checking for updates from
opengeo
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 31 source files to
/usr/local/src/geotools-2.5.8/modules/plugin/imagemosaic-jdbc/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/usr/local/src/geotools-2.5.8/modules/plugin/imagemosaic-jdbc/src/main/java/org/geotools/gce/imagemosaic/jdbc/GeoRasterThread.java:[25,31]
package oracle.spatial.georaster does not exist
[and so on]
Seems like you are missing one or more dependencies in the pom for
this project, or their scopes are incorrect.
--
Walking on water wasn't built in a day.
-- Jack Kerouac
Eduardo M KALINOWSKI
edua...@kalinowski.com.br
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: build problem
On Ter, 02 Mar 2010, kolaloka wrote: Looking into the repository for an actual class bal...@black:~/.m2/repository/com/oracle$ (for i in `find . -type f|grep jar$`; do unzip -l $i; done) |grep STRUCT 5985 06-16-04 11:33 oracle/sql/STRUCT.class 2830 07-31-09 19:31 oracle/sql/JAVA_STRUCT.class 11087 07-31-09 19:31 oracle/sql/STRUCT.class seems to be there. Well, two of the STRUCT might be a problem if it once finds it... others are not duplicated: bal...@black:~/.m2/repository/com/oracle$ (for i in `find . -type f|grep jar$`; do unzip -l $i; done) |grep JGeoRaster 10378 08-01-09 10:53 oracle/spatial/georaster/JGeoRaster.class 27539 08-01-09 10:53 oracle/spatial/georaster/JGeoRasterMeta.class It's not enough to have the jar's in your repository, you must list them in the pom.xml file so they are used during compilation. -- We cannot do everything at once, but we can do something at once. -- Calvin Coolidge Eduardo M KALINOWSKI edua...@kalinowski.com.br - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: XML Files in Maven Jar
On Qua, 24 Fev 2010, Thomas Sundberg wrote: Hi! Where are the xml files located in your project? They will be included automatically if you place them in src/main/resources He's probably converting an existing project to use Maven, and so it's not layed out in Maven's preferred structure. -- Little else matters than to write good code. -- Karl Lehenbauer Eduardo M KALINOWSKI edua...@kalinowski.com.br - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Slow deployment to JBoss when Maven is used
I'm facing a strange problem. Before Maven, JBoss took about 20-30s to deploy our .ear (including some EJBs, one .war and a few library .jars). Now that we are using maven, the same operation is taking about 1m20s, despite the file being smaller (since only the dependencies that are actually used are now included). This happens both with the .ear generated with maven alone, and with the .ear generated by eclipse (using m2eclipse and WTP integration). Does anyone have an idea of the cause and things that can be done? -- Love your neighbour, yet don't pull down your hedge. -- Benjamin Franklin Eduardo M KALINOWSKI edua...@kalinowski.com.br - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Slow deployment to JBoss when Maven is used
On Qui, 04 Fev 2010, Eduardo M KALINOWSKI wrote: I'm facing a strange problem. Before Maven, JBoss took about 20-30s to deploy our .ear (including some EJBs, one .war and a few library .jars). Now that we are using maven, the same operation is taking about 1m20s, despite the file being smaller (since only the dependencies that are actually used are now included). This happens both with the .ear generated with maven alone, and with the .ear generated by eclipse (using m2eclipse and WTP integration). Forgot to mention: what takes most time is deploying the Web application. The EJBs are loaded almost instantly, before and after maven. -- Yesterday upon the stair I met a man who wasn't there. He wasn't there again today -- I think he's from the CIA. Eduardo M KALINOWSKI edua...@kalinowski.com.br - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Compile what can be compiled, ignore sources with errors
Is there a way to configure Maven to ignore source files that present errors during compilation, and compile everything that is possible (that is, has no error)? I've set maven-compiler-plugin's failOnError option to false, and the build is considered successful despite the errors. However, no classes are generated. Our jar file is even created, but it has nothing except the META-INF directory. I believe the problem happens because it's a big project (229 source files as of now). I created a simple project with two sources, and even without failOnError=true the source with no errors was compiled. But when I created a lot more sources with errors, nothing was generated. Apparently after some number of errors Maven gives up and does not try to compile anything else. Is that assumption correct? I couldn't find any information on that. One possible way to solve the problem would be to manually list the files to be excluded, and remove them from the list as they get fixed. But this is tedious and error-prone, so I wonder if there is a better way. -- Eduardo M KALINOWSKI edua...@kalinowski.com.br - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Compile what can be compiled, ignore sources with errors
On Sex, 29 Jan 2010, Christoph Kutzinski wrote: The obvious counter question is: Why do you want to do this? Why not just fix the compile errors? To make a long story short: we received this project from another company, and we have to fix it and complete the parts that are missing. We are doing this in incremental steps, naturally. Sometimes we make changes that break other parts of the project. For example, a method name may be changed. This will break everywhere that calls the method. This gets fixed in the parts that we are currently working on, but in other parts, we ignore them for now. When work is started on those parts, they'll have to get fixed. It's true that in the end everything will have to compile without errors. But at this moment, we need the parts that are OK to be compiled, so that the application (it's a web application) can be run and those parts be tested. As for what's still with errors, they at the moment aren't being called. Naturally, if they were called, a run-time error would show up. That's OK by now. I hope this clears up the reasons. I know it's a weird request, but this situation is not permanent. As the project progresses, this will simply not be necessary anymore. -- You're being followed. Cut out the hanky-panky for a few days. Eduardo M KALINOWSKI edua...@kalinowski.com.br - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Compile what can be compiled, ignore sources with errors
On Sex, 29 Jan 2010, Christoph Kutzinski wrote: Sounds to me like you should modularize the application, make a multi-module project of it (if not already) and then add only those modules on which you're working currently to the modules section of the parent POM and leave out all the others for the moment. Just a quick idea from the top of my head. It is already a multi-module application. Some modules are OK, but the problems I'm referring to happen in only one of the modules (well, two actually). The alternative you mentioned - try to compile everything and just hope at runtime that all currently needed functionality is working - sounds inherently dangerous to me. Yes, it is dangerous. But it works fine when building with Eclipse. Apparently Eclipse does just that, compiling what can be compiled and including that in the final war (or whatever else is being generated). -- Your mileage may vary. Eduardo M KALINOWSKI edua...@kalinowski.com.br - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
